PUNCTUALITY FORECASTING AND BOTTLENECK IDENTIFICATION AT KLM AIRCRAFT SERVICES
Paul Adriaansen S257389
April 2009
Thesis submitted in partial fulfillment of the requirements for the degree in Master of Science in Operations Research & Management Science
Supervised by: Dr. J.P.C. Blanc, Department of Econometrics & Operations Research, Tilburg University, and: Ir. M. Bovenkerk, KLM Aircraft Services THESIS PAUL ADRIAANSEN –APRIL 2009 ii Pablo Ruiz y Picasso
1881 - 1973
THESIS PAUL ADRIAANSEN –APRIL 2009 iii THESIS PAUL ADRIAANSEN –APRIL 2009 iv MANAGEMENT SUMMARY
Context and research goals
KLM Aircraft Services (AS) is responsible for the turnarounds of aircrafts. A turnaround is the time in between two flights in which the aircraft is cleaned, fuelled, reloaded with catering supplies, reloaded with fresh water and prepared for the next flight. Since many aircrafts are handled at the same time and all turnarounds must be performed within limited time, AS needs to make the allocation of resources (equipment and staff) as efficient as possible. When the aircraft is not ready for departure at the moment it is supposed to leave according to the timetable, the aircraft is delayed. Punctuality is an important KPI for the KLM management, as well as the management of AS and its departments. But instead of measuring punctuality afterwards, KLM AS would rather have a tool for forecasting the consequences in punctuality of decisions in resource allocation and to facilitate scenario analysis for trading off costs and punctuality.
The number of resources available during the day for aircraft handling is currently based on the workload during the day, based on the timetable. The Operational Check (OPC) is performed half a year in advance and tests the proposed timetable on feasibility for all AS processes. This test is performed by minimizing the number of resources needed to perform all jobs according to the timetable, with deterministic norms for the job durations. Since the timetable is assessed in a deterministic way, it is impossible to take punctuality forecasting into account in the OPC.
Forecasting punctuality is especially interesting if the processes responsible for the delay can be identified. Altogether, the main goal of the project as assigned by KLM Aircraft Services is: 1. to evaluate definitions of punctuality in the context of KLM Aircraft Services, 2. to perform quantitative analysis on the measurement and forecasting of punctuality and the identification of bottlenecks in the platform operation, and 3. to find a way in which any form of punctuality forecasting can be included in the OPC.
THESIS PAUL ADRIAANSEN –APRIL 2009 iii Simulation model
The third goal as stated above implicitly incorporates the first two goals and was met by developing a simulation model (called Picasso), based on the inputs of the OPC. The Picasso simulation model was based on the existing OPiuM simulation model (programmed in Java with the DSOL simulation package). OPiuM is used for forecasting punctuality of flights by simulating deviations from the timetable, based on historical data of flight and ground time durations.
The discrete-event simulation model that is used for this thesis combines the concept of job shop scheduling in a stochastic environment with the concept of a queuing network. These two concepts interact as follows: Aircrafts arrive and need different jobs (in prescribed order) before they can depart These jobs are performed by resources that are unique for the process the job belongs to When a resource is assigned to a certain job, it first needs to drive to the aircraft before it can start. Both driving and processing takes some stochastic period of time However, these resources are scarce which means jobs often need to queue within a process In order to minimize delays and waiting time (idle time of resources which eventually leads to delays as well) the system uses intelligent tools to allocate resources in an efficient way and give priority to jobs that are about to cause delays
As described, the OPC minimizes the number of resources needed to be able to perform all platform operations according to the (deterministic) timetable. Picasso, on the other hand, does exactly the opposite: it minimizes delays (defined as lateness of departure) subject to performing all platform operations with a given number of resources. The arrival moments of aircrafts are subject to uncertainty (simulated by OPiuM) and the job durations are stochastic as well, based on historical data. The number of resources available for each process during the day in the Picasso model is taken equal to the output of the OPC trajectory: the minimal number of resources needed to perform a deterministic timetable (at 100% punctuality) with deterministic job durations.
The lateness of a departure is measured in minutes, but in order to take the size of the aircraft into account, the delay is multiplied with the number of passengers in the aircraft, which results in the punctuality measure of Passenger Delay Minutes (PDM). By means of an allocation rule, based on “fairness principles”, the total PDM of a flight is assigned to one or more processes that are responsible for the delay. By adding up these PDM per process, bottlenecks in the operation (processes with too little resources) can be identified for every moment of the day.
Results, conclusions and recommendations
Since Picasso is only a prototype of a simulation model that could be used in the OPC, the emphasis of the process was not on the quality of the programming. Therefore some imperfections exist in producing multiple independent runs and replications which turns out to be troublesome when performing statistical analysis. However, by making some assumptions about independence based on the output data, it turned out to be possible to compare different scenario’s on their input parameters. Although absolute values in the output showed strong deviations from expected numbers, due to various reasons, the relative differences in the output numbers did provide useful results. A lot of significant results were found by using the Welch approximation for constructing Confidence Intervals with the two-sample t-test.
Due to the elaborate nature of performing an OPC, KLM did not have the possibility to perform more than one OPC trajectory for the Picasso project. Without having multiple sets of capacity levels as the output of an OPC trajectory it was not possible to test different timetables on their performance. The one timetable that was examined (timetable of summer 2007) has been tested on several aspects to test its validity and to proof the usefulness of Picasso as a punctuality forecasting tool. The results of these tests include (apart from verification and validation): In general, the cleaning and security check processes (and to a lesser extent the fuelling process) are the main causes of delay according to Picasso
THESIS PAUL ADRIAANSEN –APRIL 2009 iv The problems with these processes (bottlenecks in the operation) mainly occur during the wide morning peak between 7.00 and 9.00 (bottleneck: cleaning) and during the high evening peak between 18.30 and 19.30 (bottleneck: security check). Other peaks are much less problematic During the sensitivity analysis it became clear that there exists a strong positive correlation between delays in fuelling and pushback en between delays in cleaning and security check. This correlation means that a shortage of capacity in one process, can induce problems at another process as well During the early morning (5.00 to 6.00) many long delays are caused by multiple reasons. Scenario analysis with Picasso shows that a small investment in extra capacity can easily solve most delays in this early morning peak
The second and fourth result presented above are in line with a more general notion in the conclusion of this thesis: The current analyses in the OPC pay too much attention to the height of a peak in the workload, while they should focus more on its domain during the day. In the day-to-day operation numerous sources of uncertainty shift workload back and forth in time, so that peaks are truly unpredictable. A workload forecasting tool that takes punctuality (and thus uncertainties) into account should be robust in its results instead of precise in its predictions.
This last conclusion introduces the most important recommendation following from this thesis: it is possible to implement an improved and extended version of Picasso as a punctuality forecasting tool in the OPC trajectory. The fact that Picasso has not yet proved to be able to test different timetables on their punctuality performance is no impediment to that, since this thesis shows Picasso is capable of providing valid and significant results in comparing scenario’s. However, the most important notion to this recommendation is that the whimsicalities of the day-to-day operation should never be forgotten when trying to model uncertainties. Modeling uncertainties is necessary when forecasting punctuality, but the simulation model itself is not necessarily getting more realistic by it.
THESIS PAUL ADRIAANSEN –APRIL 2009 v TABLE OF CONTENTS
PREFACE AND ACKNOWLEDGEMENTS xi
CHAPTER I –INTRODUCTION 1
1.1 Project description 1
1.2 Research question and requirements 2
1.3 Importance and use of the project 3
1.4 Outline research approach and content of chapters 4
CHAPTER II –DETAILED PROBLEM DESCRIPTION 6
2.1 The organization 6
2.1.1 KLM Royal Dutch Airlines 6 2.1.2 Ground Services 7 2.1.3 Aircraft Services 7
2.2 Processes 7
2.3 Ground Time Specifications 8
2.3.1 Timetable and building blocks 8 2.3.2 Time windows for AS 10
2.4 Control of operations 12
THESIS PAUL ADRIAANSEN –APRIL 2009 vi 2.5 Operational Check 12
2.5.1 Goals of the OPC 12 2.5.2 The OPC Trajectory 12 2.5.3 The check week 14
2.6 OPiuM 15
2.6.1 Building block simulation 15 2.6.2 Measuring Punctuality 16 2.6.3 Limitations and shortfalls 16
CHAPTER III –RESEARCH APPROACH 17
3.1 Choice of technique: simulation 17
3.1.1 Why simulation? 17 3.1.2 The alternative of regression analysis 18 3.1.3 Implications of the choice for simulation 18
3.2 Important choices in the simulation study 19
3.2.1 General remarks on the simulation study 19 3.2.2 The use of OPiuM 20 3.2.3 Level of detail 20 3.2.4 Project focus 21
3.3 View on OPC 21
3.4 Literature 22
CHAPTER IV –PUNCTUALITY 23
4.1 Working with punctuality 23
4.1.1 Deadlines and durations 23 4.1.2 Seven levels of punctuality 24 4.1.3 Levels of responsibility 25
4.2 Management Key Performance Indicators 27
4.2.1 Delay codes and performance meetings 27 4.2.2 Other data on performance 27
4.3 View on punctuality 28
4.3.1 Measuring punctuality 28 4.3.2 Identification of delay causes 28 4.3.3 Calculation of the PDM weights 30
THESIS PAUL ADRIAANSEN –APRIL 2009 vii CHAPTER V –CONCEPTUAL MODEL 33
5.1 Model Lay-out 33
5.1.1 The pre-Picasso trajectory: OPC and OPiuM 33 5.1.2 The conceptual layout of Picasso 35
5.2 Objects in the model 37
5.2.1 Aircrafts 37 5.2.2 Processes and resources 39 5.2.3 Jobs 41
5.3 The flow of jobs 42
5.3.1 Processing a job in seven steps 42 5.3.2 The need for scheduling 44 5.3.3 Flow charts 46 5.3.4 Queues and priority 47
5.4 Intelligence in Picasso 48
5.4.1 Time windows and EBD calculation 48 5.4.2 Intelligent scheduling 50 5.4.3 Smart priority 53
CHAPTER VI –QUANTITATIVE MODEL 56
6.1 Programming Picasso 56
6.1.1 OPiuM for Picasso 56 6.1.2 Run length and replications 57 6.1.3 Random numbers 57
6.2 The Picasso time gap 58
6.3 Structure of the program 59
6.4 Input data for capacities 59
6.4.1 Raw numbers from the OPC 59 6.4.2 Corrections in the workload schedules 61
6.5 Input data for probability distributions 62
6.5.1 Data collection 62 6.5.2 Triangular distributions 63 6.5.3 Fitting triangular distributions 63 6.5.4 Fuel distributions 64
6.6 Verification of the model 65
6.6.1 Six phases in building Picasso 65 6.6.2 Tracing objects 66
THESIS PAUL ADRIAANSEN –APRIL 2009 viii CHAPTER VII –RUNS AND RESULTS 67
7.1 Input and output of the simulation model 67
7.1.1 Input parameters 67 7.1.2 Output report 68 7.1.3 Independence of output from different runs 72 7.1.4 The Welch approach 73
7.2 Runs 74
7.2.1 Basic run 74 7.2.2 Validation scenario’s 76 7.2.3 Unlimited resources 77 7.2.4 Sensitivity analysis per resource 77 7.2.5 Tests of intelligent decision making in Picasso 79 7.2.6 Priority setting 80 7.2.7 Early morning correction 81
7.3 Interpretation of the results 82
7.4 Conclusions from Picasso 83
7.4.1 General conclusions 84 7.4.2 Interdependencies in PDM allocation 78 7.4.3 Other conclusions 88
CHAPTER VIII –CONCLUSIONS AND RECOMMENDATIONS 91
8.1 The Picasso simulation model 91
8.2 Conclusions and recommendations on punctuality forecasting 92
8.3 Conclusions and recommendations on bottleneck identification 93
8.4 Punctuality in the OPC 93
8.4.1 Conclusions and recommendations 94 8.4.2 Recommendations for the OPC 94 8.4.3 Evaluating a timetable 95
8.5 Recommendations for further research 96
8.5.1 Improvements of OPiuM for Picasso 96 8.5.2 Improvements of Picasso 97 8.5.3 Ground time distributions 98
8.6 Other recommendations 98
REFERENCES 100
THESIS PAUL ADRIAANSEN –APRIL 2009 ix APPENDICES 110
1.A Abbreviations and terminology 110
2.A Overview of AS processes 104
2.B Example of AIS: turnaround of 737-400 107
2.C Control of operations 109
3.A List of interviewees 112
4.A Different forms of punctuality 113
4.B Delay codes and performance meetings 116
5.A Picasso 119
5.B Overview of KLM fleet 120
5.C Flow charts 121
6.A Java and DSOL 140
6.B Structure of the program 142
6.C Corrected workload 145
6.D Process duration distributions 151
7.A Control panels 162
THESIS PAUL ADRIAANSEN –APRIL 2009 x PREFACE AND ACKNOWLEDGEMENTS
In 2007, the airline industry was growing at high pace, new destinations and aircrafts were introduced at KLM and politicians were arguing and squabbling about a sixth runway for Schiphol Airport. At that time, the subject of my thesis, punctuality management in relation to capacity planning, was put in a fully different perspective than it is at present, after air-taxes and credit crunches. However, innovation is never going backwards and economies always recovered, so at the end of the day, this thesis may contribute to a more efficient world.
This thesis is the result of my internship at KLM Aircraft Services, preceding my graduation in the master of Operations Research & Management Science in Spring 2009. Altogether, the full trajectory of graduation took me quite some time, but this time is still amply in proportion with all the things I learned during this period.
First I would like thank the persons that were of great importance to my project in the first half of its duration: Hans Blanc for continuously reading and correcting my analyses and texts; Mark Bovenkerk for explaining me the full KLM operation, showing me around at Schiphol and guiding me through my project; Charlotte Elpers for her ongoing help and patience with my Java mess. And of course all my colleagues at KLM and K3, my roommates Ir Wei, Mark, Martin, Oscar, Tonnie, Marian, Elizabeth, Johan and Daniëlle and Charlotte again for their great company. I had a really good time working with you!
I also would like to thank the persons that were of importance to my graduation during the second half of it: my friends for deliberately (not) mentioning the S-word, my parents for ongoing (financial) support and of course I would like to thank Marloes for her patience, support, affection and harsh deadlines.
If anyone, academic or KLM employee, reading this thesis, is considering to get in contact with me, I warmly invite you to do so. You can reach me using the contact information mentioned below.
Paul Adriaansen –Rotterdam, April 2009
Nieuwehaven 187 3011 VN Rotterdam 06-26658919 [email protected] http://www.linkedin.com/in/pauladriaansen
THESIS PAUL ADRIAANSEN –APRIL 2009 xi CHAPTER I
INTRODUCTION
This thesis describes the activities and results of the project “Punctuality indicators and bottleneck identification at KLM Aircraft Services”. This project served as the basis of my internship at Royal Dutch Airlines –Koninklijke Luchtvaart Maatschappij (KLM) –and graduation in the Master of Science degree in Operations Research and Management Science at Tilburg University.
This chapter starts with a project description to introduce the topic and background of the project. The research question is stated in Section 1.2 and the importance of the project is discussed in Section 1.3. The chapter ends with a chapter-by-chapter description of the thesis, based on the introduction of the research approach.
In this thesis a lot of abbreviations and KLM specific words are used. All abbreviations and KLM specific terminology are explained when they are mentioned for the first time. Furthermore all abbreviations and terms can be found in an explanatory list in Appendix 1.A. Literature referencing is according the Harvard standards; all figures and tables are numbered continuously per chapter.
1.1 Project description
KLM Aircraft Services (AS) is responsible for the turnarounds of aircrafts. A turnaround is the time in between two flights in which the aircraft is cleaned, fuelled, reloaded with catering supplies, reloaded with fresh water and prepared for the next flight. AS uses different resources for these processes (operators and equipment), which are all scarce. Since many aircrafts are handled at the same time and all turnarounds must be performed within limited time, AS needs to make their resource allocation as efficient as possible. The time available for handling is defined in the timetable. When the aircraft is not ready for departure at the moment it is supposed to leave according to the timetable, the aircraft is delayed. The scarcity of AS resources can be a reason for this delay.
Dispunctuality of aircraft movements is a significant source of costs in the aviation industry and therefore many OR related research has been carried out on aircraft turnarounds (Wu and Caves, 2004). Because of these high costs, punctuality forms an important Key Performance Indicator for KLM. Management decisions are to a large extent based on punctuality figures measured in the operation. The problem with these figures is that the consequences of certain management decisions only become clear afterwards. Ideally, KLM would have a tool for forecasting the consequences in
THESIS PAUL ADRIAANSEN –APRIL 2009 1 punctuality of certain decisions to facilitate scenario analysis for comparing costs, punctuality and other KPI’s.
When looking at AS, two important decisions influence the level of punctuality: the workload (given by the timetable) and the number of resources that is available for handling aircrafts during the day. The number of resources needed for handling the aircrafts according to the timetable is determined by the Operational Check (OPC). This check is used to assess the timetable on feasibility. In total, the OPC trajectory takes about two months and is performed in the fifth to the third month before the start of the associated season (winter or summer). However, punctuality is no issue in this check.
This thesis examines the possibilities to include a form of punctuality forecasting in the assessment of the timetable during the OPC. The chosen technique for this is discrete-event simulation, which means that the main focus of this thesis lies in describing and justifying the development process of the simulation model.
1.2 Research question and requirements
This section concentrates on describing the project assignment according to the research goals stated by KLM Aircraft Services (AS). These goals are translated into slightly more concrete goals that include the building of a tool for forecasting punctuality in the OPC. Also some basic requirements that need to be met are described.
As described in Section 1.1, the project is about the punctuality of departing aircrafts. The AS department Operations Support (SPL/K3) and the Ground Services department Operations Support (SPL/ST) are jointly responsible for evaluating proposals for timetables on different aspects, but currently perform no analysis on punctuality. Both departments are interested in including any form of punctuality forecasting in the operational check, but never looked for a method to do so. Furthermore, identifying the bottlenecks in the resources that cause dispunctuality, allows for efficient investments in the quality of the airline service. Therefore, the main goal of the project as assigned by KLM Aircraft Services is: 1. to evaluate definitions of punctuality in the context of KLM Aircraft Services, 2. to perform quantitative analysis on the measurement and forecasting of punctuality and the identification of bottlenecks in the platform operation, and 3. to find a way in which any form of punctuality forecasting can be included in the operational check.
The project aims at understanding the nature of punctuality as a result of all kinds of uncertainties. This understanding can be a first step in developing a punctuality forecasting tool that supports management in evaluating the consequences of decisions, as mentioned in the previous section. Therefore, this project can be seen as a preparatory study on fully integrating punctuality forecasts in the operational check, next to forecasts on capacities and costs. This integration of punctuality forecasts is in itself a small step in achieving a long term objective: building a ‘virtual airport’ that allows for simulation on all kinds of scenarios. The project focuses on Aircraft Services, but insights obtained can be useful for similar operations across Ground Services, since other departments perform operational checks as well.
The research questions following from the goal of the project as stated above could be translated into a more concrete set of goals that can be quantified a bit easier. The goals of this project fall apart in three levels; the higher levels contain the ideas and results of the lower levels: 1. First level: Develop a view on whether and how the concept of punctuality can be integrated in the OPC 2. Second level: Develop quantitative methods and concepts in order to assess the punctuality of a timetable and to be able to identify bottlenecks in the operation 3. Third level: Construct an instrument (software application) that is capable of assessing a timetable according to the methods and concepts developed in the second level
THESIS PAUL ADRIAANSEN –APRIL 2009 2 The concepts and instruments mentioned above should meet some basic requirements: The idea of measuring punctuality in the OPC is to assess the quality of a timetable, so it should be possible to compare timetables with each other. The instrument should incorporate one or more definitions of punctuality that refer to interpretable results. Preferably, existing AS Key Performance Indicators (KPI’s) on punctuality are part of these definitions. The definitions and the instrument need to fit in the operational check. This means they cannot be based on information that is not yet available during the OPC. The instrument is only useful when it is possible to perform all kinds of scenario analysis with it. The identification of bottlenecks should be based on some principles of ‘fairness’.
1.3 Importance and use of the project
Apart from the ‘higher level’ purpose mentioned in the last section, it is possible to indicate the value of the project in a more concrete way: the ability to predict punctuality (as a function of operational decision making) more precisely, creates the possibility to allocate resources more efficiently, since buffers in time and capacity can be reduced. In other words: by knowing more precisely what will happen in a specific situation, it is possible to assign less staff and equipment than there would have been assigned for that situation, without increasing the risk of underperformance. In this description the implicit assumption is made that the management of AS minimizes costs subject to reaching a certain level of punctuality with a certain probability. The consequence of this assumption is illustrated by a simplified example.
Assume that punctuality is positively correlated with the variable costs of operation and follows a normal distribution (with the extra constraint that punctuality cannot exceed 100%). It is possible to forecast the expected punctuality level as a function of budget but suppose the actual punctuality that is reached is subject to a standard deviation of 2 percent points. When forecasting punctuality ‘more precisely’, the correlation with the budget level does not change but the standard deviation drops to 1 percent point.
In both situations the minimum cost level needed to achieve 80% punctuality with 95% confidence is calculated. The minimal cost scenarios are illustrated in Figure 1.1 for both situations. The punctuality goal of 80% is reached with 95% confidence, but when one is able to forecast more precisely, it is possible to aim for a lower level of expected punctuality. Since expected punctuality is correlated with costs, costs are saved by being able to forecast punctuality more precisely.
In the example above, the cost/punctuality ratio remains unchanged. The punctuality is lowered in order to save cost, without violating the 80% punctuality constraint. In fact, the most ideal situation would be to have no uncertainty, since in that case it is possible to lower the ‘forecasted’ punctuality to exactly 80%: costs are minimized and underperformance never occurs. This strategy is based on the assumption that over-performance is worthless: there is no incentive to strive for higher punctuality, so costs are minimized.
THESIS PAUL ADRIAANSEN –APRIL 2009 3 y t i s n e d
y
t Original i l i forecast b a b o r
P More precise forecast
Target: 80% Punctuality Figure 1.1: Punctuality forecast at minimal cost
1.4 Outline research approach and content of chapters
When trying to determine sub-goals in order to reach the main goal as stated above, a “path of development”for the project can be built. This path of development actually presents the outline of this thesis and the content of the different chapters. A graphical overview is in Figure 1.2, followed by a point by point explanation of the content of the chapters. Although this figure is not returning in the text of the thesis, it does provide a good overview of the structure of this thesis.
Chapter 2 contains a detailed description of the background situation of the problem. Not only the platform operations are discussed, also the issues in ground time management, the OPC trajectory and OPiuM are introduced. Chapter 3 explains why simulation is used for the punctuality measurement. Furthermore some important choices are made that form the basis of the research project. Also a short overview of the use of literature is provided.
In Chapter 4 the real work begins with the development of ideas about punctuality. The most important part of this chapter is the explanation of the method that is used to allocate delays among the responsible processes. The fifth chapter combines all these insights into a conceptual model.
THESIS PAUL ADRIAANSEN –APRIL 2009 4 Input for the system Developed by analysis
Description platform Research approach operations & modelling choices H3
Description OPC Conceptual Ideas about H2 trajectory model punctuality
H5 H4 Description OPiuM Ideas about simulation tool allocating delays
Data on platform Quantitative Java programming H6 operations model skills and support H6
H6
Output from the system
Punctuality reports & Design of sensitivity analysis alternative scenarios Experiments H7 H7 Bottleneck H7 Statistical identification reports techniques
Conclusions and recommendations
H8
Figure 1.2: Overview of the research approach and content of chapters
Chapter 6 describes how this conceptual model has been translated into a quantitative model, programmed in Java (the simulation tool). The seventh chapter is important since it contains all the experiments and their results. The outcomes of all relevant runs are presented, including conclusions based on statistical analysis.
Although a part of the conclusions is already drawn in Chapter 7, most of the conclusions are presented in Chapter 8. In this chapter, the results from the experiments and the ideas that follow from qualitative analysis are combined to answer the research question.
THESIS PAUL ADRIAANSEN –APRIL 2009 5 CHAPTER II
DETAILED PROBLEM DESCRIPTION
This chapter gives a detailed problem description that serves as the context of this thesis. This chapter only summarizes known and available information; it does not yet provide new ideas or concepts. It starts with the AS organization and Aircraft Services departments and then an important discussion on Ground Time specifications follows. After that the control of operations at different levels is discussed and thereafter an outline of the Operational Check trajectory is provided. The chapter ends with a description of OPiuM, the Operational Performance Management tool.
2.1 The organization
This short section gives an introduction to KLM, Ground Services and Aircraft Services. All numbers that are mentioned are based on the period of April 1, 2007 to April 1, 2008.
2.1.1 KLM Royal Dutch Airlines
The Koninklijke Luchtvaart Maatschappij (KLM) merged with Air France in 2004 and together they form one of the largest airline companies of the world. Together with their Skyteam partners they fly passengers and cargo from Amsterdam to over 250 destinations worldwide. The KLM Group itself transported 23.4 million passengers and 657.000 tons cargo last year. KLM has a fleet of 195 aircrafts, and over 31.000 people (FTE) work at the KLM Group, of which 90% in the Netherlands. An overview of the KLM fleet is presented in Appendix 5.A.
Transavia and KLM Cityhopper are 100% subsidiaries of the KLM Group and KLM holds shares in Martinair (50%, about to become 100%) and Kenya Air (26%). The revenues last year were over 8 billion Euros, of which 620 million was earned by providing Engineering & Maintenance to the aircrafts of over a hundred other airlines. The operational result was 751 million Euros and the profit amounted to 291 million Euros.
One of the special things about KLM, and the basis of its ongoing success since World War II, is the focus on using Schiphol as a hub for transfer passengers. The Dutch airline market is not big enough for KLM since 70% of all passengers are transfer passengers. The merging with Air France makes it possible to extent this philosophy to a two-hub system by using both Schiphol and Charles de Gaulle for transferring passengers. This is also the reason why KLM is partial owner of the High Speed Alliance, the railway company that builds a high speed connection between Amsterdam and Paris.
THESIS PAUL ADRIAANSEN –JANUARY 2009 2.1.2 Ground Services
Ground Services (GS) is with over 5000 employees one of the largest departments of the Passenger Business. It is responsible for handling more than 50.000 passengers and another 50.000 pieces of luggage each day on average. Ground Services provides various services to KLM flights, flights from subsidiaries and Skyteam partners and to over 30 other airline companies.
The main GS departments are: Hub Control Centre, responsible for managing all GS daily operations. Passenger services, responsible for all passenger flows on the airport. Baggage and Turnaround services, responsible for the baggage cellar handling and for transporting, loading and unloading baggage and cargo. Aircraft Services, responsible for relocating and preparing aircrafts for flight. Customized Ground Handling, responsible for diverse tasks.
2.1.3 Aircraft Services
The Aircraft Services (AS) department has two main divisions: the “Relocation & Flight Support” division and the “Preparation processes” division. The first one consists of the Towing department and performs de-icing on icy winter days. The second division is much bigger and is responsible for all other processes, such as water and toilet services, catering, cleaning and board supply and fuelling. All these processes are described in the next section.
The very small (16 FTE) third division of AS is called Operational Support (OS, K3) and provides all kinds of services to the two operational divisions. Training, monitoring and feedback, platform data analysis and creating rosters are the main tasks of OS. Furthermore they support the AS management with all kinds of ad-hoc analyses and calculations.
2.2 Processes
This section presents an overview of all processes of Aircraft Services. In Appendix 2.A all these processes can be found per department or organizational unit, in this section only a brief summary of that information is presented (see Table 2.1). Also some processes outside AS are described.
Processes Description Towing Towing aircrafts between hangars, gates and buffer positions Pushback Pushing an aircraft onto the platform just before departure Hydrant fuel Fuelling an aircraft by connecting its tank on the hydrant fuel wells at Schiphol Non-hydrant fuel Fuelling an aircraft by pumping fuel from a fuel truck Prefuel Fuelling an aircraft (mostly hydrant) before its destination is approved Water Filling or changing the (drinking) water supplies of the aircraft Toilet Changing and cleaning the toilet tank of the aircraft Cleaning Cleaning the interior of the aircraft Security Check Checking the interior of the aircraft on unsecure objects or unsafe situations Catering Changing the catering supplies of the aircraft Board Supply Changing and distributing the non-food supplies of the aircraft (cushions etc.) Passage Non-AS Process: Boarding and deboarding of the aircraft Baggage Non-AS Process: Loading and unloading baggage on the aircraft Technical Non-AS Process: Performing technical checks and small repairs Table 2.1: Overview of AS processes
THESIS PAUL ADRIAANSEN –APRIL 2009 7 2.3 Ground Time specifications
Before it is possible to focus on ground time specifications, we first need to know what determines the ground time. In fact this is a simple question: all periods of time an aircraft is not flying or in maintenance, is ground time. We need to take a look at building blocks first, before we can focus on the time frames in which the AS processes are performed. Finally we will address some issues in ground time distributions.
2.3.1 Timetable and building blocks
This section gives an idea about how the KLM timetable is created and which role Building Blocks play in this process. The timetable is primarily a commercial oriented product. The KLM Network department constructs a long term vision on the network, based on four pillars: Market, Financial Performance, Operational Performance, Capabilities. In this discussion, priorities are set accordingly: Market conditions are most important, current capabilities are least important. From this long term vision, destinations are chosen for a horizon of five to ten years and only small adjustments are possible in this portfolio. When destinations are available and Sales Management has estimated which seats to sell, a Fleet Allocation Plan is launched. This plan is the input for the timetable that is actually developed according to the ‘IATA slot conference’, an international meeting in which airport connections are established.
The basic idea of the timetable is now fixed, but when it comes to details a lot of adjustments are still possible. These adjustments can result from all kinds of problems, faced at different levels in the organization. Some of the main topics are: Fleet allocation: which aircraft is performing which flights? Maintenance schedule: which aircraft receives maintenance at which moment? Flight crew: which cockpit and cabin crew is assigned to which flights? Cargo stations: when is cargo loaded on shared flights? Gate capacity: is the timetable feasible with the given gate space? Ground capacity: is the timetable feasible with the capacities at ground handling?
The building block structure that is presented in this section is based on the operational philosophy of KLM. The building blocks give the Network Design division of KLM the opportunity to build a highly efficient timetable that satisfies all minimal operational requirements. These requirements, of which you find examples above, are set mainly by three Capacity & Service Providers: Assembly team Flight: the division that provides flight staff and In-flight Services. Assembly team Ground: the division that provides all ground processes such as passenger and baggage flows and Aircraft Services. Assembly team Aircraft Availability: this is the Engineering & Maintenance division that provides fleet availability.
The Building Block (BB) structure is best made clear with a diagram (see Figure 2.2) (Jacobs et al, 2005). In this diagram, BB1 is associated with Flight and BB3 is associated with Maintenance (also called aircraft lay-over, since also idle time is included in BB3). BB5, BB6 and BB7 are associated with passenger (pax) and baggage (bax) flows that will not have our attention. The important building blocks are BB2 and BB4 since they are the working area of Aircraft Services. Also BB3 will turn out to be important for us for two reasons: 1. Sometimes idle time in BB3 is used by AS. 2. Much more often there exists no BB3 and BB2 and BB4 merge into a new type of building block (that is only known within AS): BB2/4, which is essential for operational efficiency.
THESIS PAUL ADRIAANSEN –APRIL 2009 8 BB1: BB2: BB3: Idle / BB4: BB1: Flight Unloading Maintenance Loading Flight
BB5: Transfer of Pax and Bax
BB6: Arrival of BB7: Departure of Pax and Bax Pax and Bax
Figure 2.2: Seven Building Blocks (Jacobs et al., 2005)
The network of flights is now composed by accumulating the building blocks, which all have a minimum throughput time. In the puzzle, a set of capacity restrictions must be met, of which the most important are: air-capacity (fleet and staff), runway capacity of Schiphol, baggage handling capacity, number of gates at Schiphol and a relatively new one: security-measures. Note that the capacity restrictions of Aircraft Services (staff and equipment) are not even close to playing a role in the network composition.
Figure 2.3: Example of timetable (fragment)
THESIS PAUL ADRIAANSEN –APRIL 2009 9 An example of a fragment of the resulting timetable is given in Figure 2.3. This figure shows flights (yellow lines) for four days and 18 aircrafts (5 Boeing 747-400 and 13 Boeing 747-combis). The red dotted lines labeled with “#A” and “TO” are planned maintenance blocks. The purple dotted lines labeled with “RS” indicate planned idle time for an aircraft. The gaps in between the lines are the BB2 and BB4 time windows for unloading and loading the aircraft.
2.3.2 Time windows for AS
As mentioned above, the number of gates is an important factor in the construction of the timetable. In fact, it is easy to notice that on the peak hours of the day, not enough gate positions will be available to leave all aircrafts at gates during their ground time. Therefore a towing schedule is constructed, in which gates are freed for new aircrafts by towing the preceding aircrafts to buffer positions. This limits the time available for AS processes since in principle aircrafts are not serviced on the buffer. The length of BB3 is not restricted but BB2 and BB4 always have a minimum length (depending on the type of the aircraft), according to the actions that need to be performed in an arrival or departure block.
As mentioned before, a BB3 sometimes not exists, which means a BB2 (an arrival) and a BB4 (a departure) are merged to a BB2/4 (a turnaround). In general the minimum length of a BB2/4 can be much shorter than the sum of BB2 and BB4, since arrival and departure processes are combined and intertwined. The standard document in which all processes are defined on a time scale for all types of aircrafts is called the handling guide (AIS, Afhandelings Instructie Schiphol). In about 100 pages a BB2, BB4 and BB2/4 is described for the 14 aircraft types KLM operates at the moment, an example of a turnaround for the 737-400 can be found in Appendix 2.B.
Now it is time to introduce some definitions for arrival and departure times. The times that are generally accepted within KLM as leading, are called “Time of Arrival” (TA) and “Time of Departure” (TD). Ground Services however is using another norm as leading: “time of Block Arrival” (BA, also called “on-blocks”)and “time of Block Departure” (BD, also called “off-blocks”). The reason for this is that although there might not be a flight in the timetable, there is a BD at the end of BB2, and a BA at the start of BB4. These four times come in three flavors: Scheduled (STD, SBD, STA and SBA): conform the timetable. Estimated (ETD, etc.): when the schedule turns out not to be valid anymore. Actual (ATD, etc.): the actual time is registered when the arrival or departure has passed.
Note that an Estimated time is not unique, this can be changed several times back and forth. There also exist two levels of communication for Estimated times: within KLM (available via Firda) and outside KLM (also available to the passenger).
Apart from the block arrivals and departures, a special group of measures exist for Ground Services: “Any Door Open” (ADO) and “All Doors Closed” (ADC). These are always "actual" since they are measured electronically. An overview of several (actual) times of arrival and departure is given in Figure 2.4.
Flight Taxi to gate Blocks Bridge BB2: unloading Towing to buffer (5 to 20 min.) (2 min.) (2 min.) According to AIS
Touch-down ATA ABA ADO ABD
Towing from buffer BB4: loading Bridge & blocks Pushback Taxi to runway Flight According to AIS (2 to 5 min.) (2 to 5 min.) (5 to 20 min.)
ABA ADC ABD ATD Take-off (AOP) Figure 2.4: Overview of different arrival and departure times
THESIS PAUL ADRIAANSEN –APRIL 2009 10 When focusing on the AIS, you can recognize the above definitions for arrival and departure times. Apart from the time scale, also A+ (Arrival oriented) and D–(Departure oriented, sometimes V–from the Dutch “vertrek”) times for all processes are provided in the AIS. These are constructed by summing the norm durations of preceding processes (in case of A+) or succeeding processes (in case of D–). With these A+ and D–time windows it is possible to fill in the BB2, BB4 and BB2/4 in the timetable. This leads to a time frame for every single process, since it is now known when a process can start and when it must be finished. The four time instants that define the maximum time frame for a process are: EST, Earliest Starting Time = { TA (Time of Arrival) } + { “A+”-time } LST, Latest Starting Time = { TD } –{ “D–“-time } –{ norm duration of process } EET, Earliest Ending Time = { TA } + { “A+”-time } + { norm duration of process } LET, Latest Ending Time = { TD } –{ “D–“-time }
When looking at the minimal turnaround time for a certain aircraft (according to AIS norms), a critical path exists. This is a path of processes for which EST = LST and EET = LET, which means that the time window for all processes on this path is fixed and equal to their norm duration. For the processes that are not on the critical path, there exists slack: the time window is larger than the norm duration. The actual size and position of the available time window depend on the starting and ending times of other processes in the path. To illustrate this with an example, the minimal turnaround of some fictional aircraft is shown in Figure 2.5.
Scenario 1: Refuelling Deboarding Pushback Cleaning Check Boarding Slack
time
0 5 10 15 20 25 30 35 40
Scenario 2: Refuelling Deboarding Pushback Cleaning Slack Check Slack Boarding
In this minimal turnaround schedule, the path deboarding –refuelling –pushback is critical.
On the critical path, EET = LET and EST = LST, time windows are not flexible
When slack exists, time windows can be shifted and slack can be allocated flexible
Figure 2.5: Example of two possible ways to divide slack in a turnaround
When the available time to perform the turnaround is increased from 40 to, say, 45 minutes, all paths of processes contain slack, which means there no longer exists a unique critical path. These 5 minutes of slack can be used to decouple processes, which can be efficient when working with unknown durations. When the duration is not deterministic (like in Figure 2.4) but equal to a sample from some probability distribution, slack can be used to decrease the probability of processes waiting for a preceding process to end. One of the challenges is to divide the available slack among all processes in order to minimize idle time (resources waiting for preceding processes to end) without causing departure delays.
THESIS PAUL ADRIAANSEN –APRIL 2009 11 2.4 Control of operations
Since this section is not vital for the understanding of the operational environment of this project, the descriptions of different “control entities” are presented in Appendix 2.C. The most important entities are: 1. Operations Control Centre (OCC): responsible for the full day-to-day operation concerning flights and fleet availability 2. Hub Control Centre (HCC): responsible for the platform operation at Schiphol airport 3. Dispatcher: operational leader of resources on the platform
2.5 Operational check
In Section 2.3.1 the construction of the timetable on the main features was explained using the philosophy of Building Blocks. In the section that followed, the specific time windows for AS were introduced that follow from these Building Blocks. These time windows play a crucial role in the Operational Check (OPC), since they are the main restriction in optimizing the workload schedules. In this section the goals and techniques of the Operational Check are explained.
2.5.1 Goals of the OPC
The OPC is a feasibility check of the timetable for the AS departments. It is performed twice a year, around January (to check the summer timetable) and around July (for the winter timetable), and it takes about two months. In the essence, the “feasibility check”means that every department needs to check whether they have enough capacities (in both staff and equipment) to produce the timetable as suggested. The goals of the OPC are: To investigate the expected workload per AS department in order to foresee any problematic peaks in the timetable. To give a “no-go response” in the timetable acceptance trajectory to the Network department on behalf of AS when one or more of these peaks turn out to be unsolvable for one or more of the AS departments. To create commitment from all AS departments to the operational plan that follows from the timetable when it is finally accepted.
As was showed earlier, the capacity of AS is not an important factor in the construction of the timetable. Therefore it is unlikely that comments of AS will force the Network department of KLM to overthrow the whole timetable. Only small adjustments will be made when AS shows that it is truly impossible to perform the timetable without causing delays. The equipment capacities of AS are flexible on a tactical level, the staff capacities are even flexible on an operational time scale. This means that the OPC trajectory is mainly used to feed the (partially political) discussion on investments and budgeting for the coming period, rather than the pure feasibility check that would lead to the answer “yes” or “no”.
2.5.2 The OPC Trajectory
Every operational division of KLM performs some kind of OPC and for the Ground Services departments, the OPC is started at the “ST”department of GS. The first phase of the OPC is the development of workload schedules and is executed by ST, the second phase is the feasibility and budget check based on these workload schedules and is performed by AS itself. In total, the OPC trajectory takes about two months and is performed in the fifth to the third month before the start of the associated season (winter or summer).
The input for the first phase consists of: 1. The proposed timetable 2. Information on gate availability 3. Norms about the durations of the different AS processes 4. Rules about the order and allocation of processes and resources
THESIS PAUL ADRIAANSEN –APRIL 2009 12 5. Information about the working hours and shifts that are valid for the coming season, based on the collective labor agreement
Now the workload schedules are calculated on the following process: 1. First, a towing schedule is created, based on the timetable and gate availability, using a software program called GatePlanning. 2. After the towing schedule is created, the time windows for the AS processes are fixed for every individual aircraft. Now another software tool, PlanControl, is used to accumulate workload for every AS department, based on the allocation rules and norms of durations. Several algorithms are used to minimize the maximum workload within some fixed time horizon. 3. The efficient workload is used to create a working shifts covering as tight as possible. The shift-schedule with minimum costs (in terms of FTE) can again be found with PlanControl.
When this efficient shift-schedule is handed over to AS the second phase starts. AS checks the following issues: Is the efficient workload schedule valid and what is the origin of workload peaks that are still present in the schedule? What is the best way to translate the schedules found to the specific needs of the different AS departments? Is it possible to create feasible working rosters per department within the budget?
Apart from this, all kinds of analyses are performed on available ground time, minimum throughput time, handling peaks, contract violations with suppliers and other ad-hoc topics. At the end of the OPC there is a capacity planning and an operational plan that contain the solutions to the issues raised above. The whole trajectory of the OPC is described in Figure 2.7. An example of a workload schedule with a shift-schedule can be found in Figure 2.8. In Figure 2.8 the actual workload is represented by the sum of the colored areas. The blue line shows the number operators that are present at every moment of the day (this is the shift-schedule). Most of the time the number of operators is enough to handle the workload, but at some moments, this is not the case (for example around 5:00 in the morning).
Timetable Gate availability Duration norms Allocation rules Working shifts input
GatePlanning: develop efficient towing schedule
the algorithms used here create PlanControl: develop efficient efficient schedules workload schedules by minimizing peaks in the accumulated workload PlanControl: develop tight shift-schedules Phase 1: ST
Phase 2: AS
feasible working validation and peak translation of rosters investigation timetable specifics
Capacity planning Operational plan output
Figure 2.7: The OPC trajectory
THESIS PAUL ADRIAANSEN –APRIL 2009 13 werkdrukte file 12/12/06
40
38 overigdelta's 36 MP HV 34 general 32 werkdruk opkomsten 30 Confidential
28
26
24
22
20 18
16
14
12
10
8
6
4
2
0 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 maandag Figure 2.8: Example of a workload schedule with tight shift-schedule (blue line)
A last comment that must be made on the OPC is about the “norm discussion”. Every season the norms that are used for the OPC are reviewed on realism; for instance by performing time measurements on the platform. Since budgets are involved, these norms are “politically”influenced. Another problem is the difference in interpretation of various types of norms. In general it is possible to distinguish three types of norms with three different goals: 1. First there is the AIS, which is based on old, less realistic norms. But this is not a problem, since the AIS is mainly used to define the A+ and D–times. 2. Second, PlanControl uses the planning-norms most of the time. These norms are ample since they include all kinds of extra operational tasks and buffer mark-up times. 3. Finally, CHIP mostly uses handling-norms. These norms are more realistic and based on the real job throughput time, excluding all the mark-up times.
However, the way a norm is build up (including or excluding mark-up and buffer times) is subject to continuous debate. Since departments are responsible for reporting their own norms, it is impossible to use a single definition for a planning-norm or a handling-norm. Therefore, different types of norms are used inconsequently throughout all kinds of analysis, including the OPC and CHIP.
2.5.3 The check week
Since performing an OPC is quite a lot of work, the responsible parties decided that the OPC is only performed for a single week each season. The choice of this week is important since it forms the basis of all capacity analyses. The idea is to choose a week that is one of the busiest of the season and at the same time it should be the most representative week of the season’sbusy period. For the summer timetable this usually means a week is chosen that is a few weeks away from the overall summer peak: the weekend in which the highest number of flight movements is reached. For 2007 the check week was week 37: the 10th to the 16th of September.
Since the OPC becomes a bit vulnerable by using a single week as representative for a whole season, also other methods are used to investigate capacity problems. First of all there exist two small OPC’s halfway both seasons, in which an evaluation is made of the original OPC. This evaluation is based on comparing forecasted and realized workloads. Secondly, AS works with a rolling planning horizon system of four weeks in length. This means every week a quick review is made of the validity of the forecasted workload. When the situation has changed, four weeks is enough to take measures (e.g. roster or shift changes) in order to avoid capacity problems.
THESIS PAUL ADRIAANSEN –APRIL 2009 14 2.6 OPiuM
The Operational Performance Model (OPiuM) is a computer simulation model that is used by KLM to evaluate the performance and robustness of a proposed timetable. It was developed by the Decision Support Department (KLM/QO) to support the development of operational plans when the timetable is handed over from the Network department to the OCC (Jacobs et al., 2005). The first versions of OPiuM were built from 2002 on, in the simulation package Arena. When new applications of OPiuM were desired, QO decided to build a totally new and more advanced version of OPiuM in DSOL, a simulation library within the Java programming language. This OPiuM II project represents the leading position of KLM in building innovative decision making tools. OPiuM has been presented on a conference on OR within Airlines (AGIFORS) in 2006 and at the 2005 Winter Simulation Conference.
2.6.1 Building block simulation
Basically, OPiuM simulates the four Building Blocks that were introduced in Section 2.3 for each aircraft in the timetable. The input for this simulation is the timetable and historical data on the length of the different building blocks. The length of a building block depends on: The type of the aircraft The destination and/or origin of an aircraft in BB4, BB1 and BB2 The necessary maintenance per aircraft in BB3
This would be a rather straightforward exercise, if it was not that OPiuM also simulates the operational measures OCC takes in disturbance situations. When the performance of the timetable is threatened by aircraft delays, the OCC can take several measures to restore the performance of the timetable. The idea is to anticipate on delays by flexibly using fleet availability buffers in the timetable. This can be done by the following measures: 1. Swap flights between aircrafts of the same type 2. Swap flights between aircrafts of different types 3. Reduce the length of a planned maintenance 4. Delay the departure of a flight 5. Cancel a flight
The OPiuM Problem Solver looks at the available options and weighs these options according to sanctions, measured in delay minutes. Swapping flights is often possible without causing any delays, but a swap can have heavy and lasting consequences. In that case a swap is only performed when the sanction of the swap is lower than the initial delay.
The decision to use some measure to avoid delays must be taken some time in advance (just as in reality). Swaps and maintenance break are no longer performed when the delayed aircraft is already in its turnaround. Since OPiuM regards the start of BB4 as the start of a flight, any swaps must be performed before that time. When BB4 is started, only cancellation is an option, but of course the sanction of a cancellation is very high. Note also that aircrafts can leave earlier than planned in OPiuM, for example when a BB4 starts on time and turns out to be shorter than planned. A schematic description of OPiuM is presented in Figure 2.8 (Jacobs et al., 2005).
Timetable Punctuality report Problem solver
Distributions process Activities Report on time activities measures used
Figure 2.9: A schematic description of the OPiuM simulation model (Jacobs et al., 2005)
THESIS PAUL ADRIAANSEN –APRIL 2009 15 2.6.2 Measuring Punctuality
As can be seen in Figure 2.8 two types of output follow from OPiuM: first of all the punctuality measurement and secondly the measures used to reach this punctuality. Since OPiuM simulates the duration of BB2 and BB4, historical data about the performance of AS is included in this punctuality analysis. The throughput times of BB2 and BB4 are based on data about the lengths of TA’s, ARR’s and DEP’sin the past, but the different causes are no longer recognizable in the data. In general, there is only one correlation that can be shown clearly: when the available ground time becomes shorter, the risk of a delay increases.
An example of the output of an OPiuM run can be found in Figure 2.10. The columns D0, D5 and D15 give the percentages of aircrafts departed at or before STD, STD + 5 and STD + 15, respectively, in percentages per aircraft type. The same is true for the A0 and A15 times, compared to the STA. AcAv means aircraft availability, ADC means All Doors Closed and the column “Ground” indicates the percentage of turnarounds finished within the prescribed time. Note that also the performance of the outstations is included in the OPiuM analysis.
(%) AMS OUT
AcType AcAv Ground ADC D0 D5 D15 A0 A15 ADC D0 D5 D15
332 96 45 44 35 Confidential47 68 61 83 71 59 67 78 733 93 54 52 40 59 84 55 88 60 48 65 82 734 92 53 50 38 57 80 56 86 57 43 58 79 738 95 44 42 27 47 76 57 88 50 36 52 76 739 92 54 51 34 49 74 59 84 53 39 57 78 744 81 32 25 15 25 38 46 65 50 34 41 52 74E 79 51 41 27 35 53 51 66 51 30 42 57 772 85 58 49 56 68 83 49 75 58 63 71 86 M11 88 45 41 19 29 52 40 61 58 41 48 59 Totals 95 73 71 65 74 86 75 90 76 69 77 87
Figure 2.10: Example of OPiuM output (fragment)
2.6.3 Limitations and shortfalls
Although OPiuM is a valuable tool for the evaluation of timetables, I would like to state some limitations and shortfalls that are specifically problematic for AS: The duration of a BB4 is randomly drawn from a three-parameter Gamma distribution (with location, shape and scale parameter). These distributions have been fit on the available data for each aircraft type and destination group. However, the duration of a BB2 is deterministically chosen to be equal to one-third of the mean total turnaround time. This is quite an arbitrary choice, since departure delay can also be caused by a long BB2 (due to cleaning for instance). In relation to this, OPiuM fails to combine the separate BB2 and BB4 into one combined BB2/4. Therefore the OPiuM analysis becomes worthless for AS, since AS does not automatically split turnaround times into a BB2 and BB4. Most of the tasks that AS performs in a BB4, can already be done before the BB4 officially starts. For AS, it would be preferable to have probability distributions for a BB4, that are conditional on the available ground time. For the other departments this is not a relevant issue. OPiuM does not include any restrictions on airport facilities or capacities of the different KLM departments. In this way, OPiuM looks at departure delay as a natural phenomenon, rather than an event with an avoidable cause. OPiuM is not able to distinguish the different events and problems that can cause delays, since the building block data is all merged into a single probability distribution.
THESIS PAUL ADRIAANSEN –APRIL 2009 16 CHAPTER III
RESEARCH APPROACH
This chapter describes the research approach, which means I make some important choices about topics, techniques and focus. I start with introducing my choice for the technique of simulation. After that some important choices are described and discussed. The third section deals with the view of the OPC that I use in this thesis, which can be seen as the basic idea of the simulation model. Finally, I describe the search for and the use of literature in this thesis.
3.1 Choice of technique: simulation
Since it is now clear what the background of the problem looks like and what requirements KLM AS sets for the solution, we have enough information to choose for simulation as the best technique to analyze the problem. I introduce this issue directly after presenting and explaining the problem and research question, so it is possible to be more specific in describing choices and ideas in following sections of this thesis. In this section I first explain why simulation is the best choice for this situation and furthermore I show that the relevant alternative of regression analysis is inferior to simulation. Finally, I state some important implications that result from the choice for simulation.
3.1.1 Why simulation?
The OPC as described earlier in this thesis is a fully deterministic analysis. In the OPC every aircraft arrives and departs exactly in time and all the durations of AS jobs are equal to the predefined norms. Analyzing punctuality only becomes interesting when you need to deal with uncertainty. In the processes that were described earlier, AS deals with two forms of uncertainty: 1. Exogenous uncertainty: the source of uncertainty lies outside the responsibility of AS 2. Endogenous uncertainty: the source of uncertainty lies within the responsibility of AS
When looking at exogenous uncertainty there is nothing more you can do, besides taking it into account. Endogenous uncertainty, on the other hand, asks for dynamic decision rules in the system, since it can be influenced by management. Altogether, this forms a complex system of stochastic variables that influence each other over time. The punctuality of processes and flights forms an important group of these variables, as they are the ‘goal variables’ we are interested in.
THESIS PAUL ADRIAANSEN –JANUARY 2009 Analyzing and optimizing a goal function in a complex system of stochastic variables that are subject to decision variables and evolves over time is par excellence the environment in which simulation is the superior technique (Law and Kelton, 2000). Some important advantages of simulation: Virtually every situation can be modeled in every preferred level of detail Decision rules can be implemented easily Scenario analysis is easy and provides you with lots of data that can be used for statistical analysis on the goal variables. Multiple runs provide information about sensitivity and confidence of the output
Disadvantages of simulation: Modeling in detail takes a lot of time and expertise Simulation will never provide exact outcomes Large simulation models can take a lot of computation time
3.1.2 The alternative of regression analysis
Since there is a lot of data available about the platform operations, we could choose to use regression analysis: explaining punctuality numbers from historical data, and use the relations found to forecast punctuality for new timetables. Although this could be a useful analysis, we expect to face some difficulties: Since punctuality can never exceed 100%, we expect a non-linear relation, which makes regression analysis heavier. The availability of data is enormous, but most of the data is only related to a small part of comparable situations (based on conceptual arguments). In this way the punctuality of the total set of flights (the timetable) becomes the weighted average of punctualities of subsets of the timetable. These subsets result from subsets in the data of which the elements differ per process, airline company, aircraft type, etc. When we do not split the datasets into smaller subsets, we will find ‘general’ conclusions, but it becomes impossible to identify the causal relations, which makes the analysis useless.
Here we face a dilemma: When defining the dependent and explanatory variables on increasingly smaller subsets, the conceptual relevance of the analysis increases, but the quantitative reliability decreases very fast. However, this is not the only information we lose by segmentation of the data into subsets: Also the dependencies between the explanatory variables for the different subsets are lost. We could fix this by assuming explanatory relations between the different dependent variables. This means that every dependent variable has, besides the original explanatory variables, all the other dependent variables as input for the model. This leads to an enormous system of interdependent dependent variables and we now need to solve a linear system of regression equations.
I performed a quick scan on the number of subsets we would need to analyze, and according to a (quite conservative) estimation we would have at least 76 subsets. This number is too much to build a regression model in which the dependent variables have useful meanings. Of course we should not forget that we would also need to take at least hundreds of explanatory variables into account.
Apparently, the problem is too complex to find a solution with (segmented) regression analysis. It is impossible to include all the segmented situations into a model that is also able to explain the interdependencies.
3.1.3 Implications of the choice for simulation
In general, using a simulation study forces you to restrain the disadvantages as mentioned in Section 3.1.1. It can be hard to build a model that gives realistic and reliable output within manageable time. But in this section we list some implications that are specific to our situation.
An important difference between regression and simulation lies within an important dependent variable: the departure punctuality of aircrafts. In a regression model this variable is used in the model itself to find a correlation, based on historical data. Within a simulation study we only use these dependent variables as output. Afterwards we can validate the model by comparing the punctuality
THESIS PAUL ADRIAANSEN –APRIL 2009 18 output we found with the available punctuality data, but this will only be possible when the simulation results are reliable enough. Furthermore it will be hard to find the errors in the model.
The issue above introduces another important implication of a simulation study: we need very well prescribed definitions for every number we use. When we are unable to calculate the punctuality exactly how it is done in the management data, validation becomes useless. This is in fact true for all definitions we use; in a simulation study we create our own ‘fictional data’, which can only be compared to real data when we use equivalent definitions and interpretations.
3.2 Important choices in the simulation study
This section aims at explaining some important choices that had to be made before it was possible to build the simulation model. First some general remarks are stated, mainly about validation, the other three section deal with specific issues that need to be addressed in the case of the AS simulation model.
3.2.1 General remarks on the simulation study
The simulation model that is used for this thesis is based on discrete-event simulation. This means that events happen at specific points in time and the state of the system only changes at these specific points in time. This is a logical choice since the processes that are simulated resemble a job shop scheduling environment, which is discrete by nature.
Most of the data that was gathered for building the simulation model finds its origin in all kinds of sources within AS and ST. Where the source is relevant, it is specifically mentioned in the text. Otherwise, numbers and facts are taken from the standard documents and guides that are in use at AS. Examples of this are “Afhandelings Instructie Schiphol”, “Handboek OPC”, and several operational guides that are used within AS or AS departments. All the missing information was completed by interviewing the managers, shift leaders and dispatchers involved in a specific case (for a list with interviewees, see Appendix 3.A). The durations of processes and related topics has been distracted from ReportControl. ReportControl is an advanced database that contains measurements of all relevant platform operation events. This is a very extensive database, but a major disadvantage is that it takes an advanced course in database query programming (which I was not able to follow) to be able to distract the relevant information from it. Furthermore, the data is poisoned with all kinds of visible and invisible errors, so doing analysis with it as a layman is a difficult operation.
Validation of the model has been performed continuously during the modeling phase. Since there was no project demarcation at all, a lot of choices had to be made. First of all, the width (in operations and in time) and the depth (level of detail) had to be discussed. The choices made were mainly based on consultations with Mark Bovenkerk. An important milestone in this discussion was the choice to use OPiuM as the leading backbone for my simulation study (see next subsection). This choice was discussed with Charlotte Elpers (AMS/QO) and Mark again. In modeling the platform operations, several people from AS were able to assess my assumptions on validity. Apart from Mark, Martin van der Gugten, Ir Wei Wu and Elisabeth Brunsting judged most of the assumptions and modeling choices. Besides expert validation, also platform visits and sanity checks played an important role in validation.
While programming the simulation model, several applications in Java provided the possibility of running parts of the model in a closed environment. Although this was mainly used for verification of the model, validation by sanity checks and checking the logical structure of the program are by definition a part of this. All technical backup during the programming phase was provided by AMS/QO. Finally, the output was validated by comparing it to existing system performance measures. This process is further described in Chapter 7.
A last notion on validation is about the assumptions document. I did maintain an assumptions document during modeling and building, but it is not presented in this thesis. The main reason for that is all the relevant assumptions are described in Chapter 4, 5 and 6, so it would make no sense to
THESIS PAUL ADRIAANSEN –APRIL 2009 19 restructure a document of more than 20 pages and translate it from Dutch. I did check however that all the assumptions mentioned in the assumptions document are presented in the text of this thesis.
3.2.2 The use of OPiuM
Without discussing details about OPiuM or the way it is used in my simulation model (this is done in Chapter 5 and 6), I would like to state the arguments for using OPiuM: 1. Since OPiuM provides very detailed simulation about the flights of any timetable that is uploaded, it is a good starting point for my model. By using OPiuM, the uncertainty in the timetable is taken into account in the best possible way. And it saved me the work of building a flight simulator myself. 2. Another argument is that it provided a logic package of modeling decisions. Most choices about width and depth that I had to make for my own model were already made in OPiuM and in a very consistent way. The level of detail of OPiuM, for instance, resembled the level I planned for my own model 3. Although the original idea was to program an Excel-based simulation model, modeling processes and decisions would ask for a more object-oriented approach. By using OPiuM, I already had an object-oriented structure in Java to start with. An important related argument for using OPiuM and Java was that I would receive technical support from the AMS/QO department. 4. Using OPiuM could improve the credibility of my own model in terms of management implications. Managers that currently use OPiuM would understand my model faster and might be more willing to take its conclusions into account. 5. One of the goals of this thesis was to explore the possibilities of modeling AS (and eventually other GS) operations into a large-scale simulation model. It would therefore be wise to make use of existing simulation infrastructure in order to avoid double work.
The most important implications of using OPiuM were the dependency on the Java programming language (which resulted in quite some difficulties) and the impossibility to include other aircrafts than KLM (although eventually also KLC was included).
3.2.3 Level of detail
The fact that we use OPiuM has an important implication on the level of detail for the simulation model. Since OPiuM simulates the flow of individual aircrafts and their one-to-one mapping with flights, this dictates the central entity of the model: the individual aircraft. Another requirement to the simulation model that asks for a certain level of detail follows from punctuality measuring. In Section 1.2 we stated that it should be possible to compare the results of the model with the available Key Performance Indicators on Punctuality. As is shown in Chapter 4, current measurements of punctuality are based on production numbers. These production numbers concern individual tasks, performed on individual aircrafts. This also dictates a level of detail for the simulation model: we need to take all individual entities into account; otherwise we are unable to define similar KPI’s on the fictional data that is the output of the simulation model. The individual entities are for example: The earlier mentioned aircrafts and flights Jobs like fuelling, cleaning and boarding Resources for each task: (teams of) operators and equipment
One of the major advantages of this much detail is that is becomes possible to model decision making on scheduling, job priority, resource allocation, etc. This makes the simulation model much more realistic and advanced, since it then includes some of the techniques that are used in PlanControl to optimize workload.
THESIS PAUL ADRIAANSEN –APRIL 2009 20 3.2.4 Project focus
This section describes at which topics my project focuses. I make important choices in how the topic is approached and where the emphasis of this thesis lies. I focus on: Proper descriptions and accurate modeling of relevant processes, suitable approximations for less important processes. Flexibility in the use of policies, controlling rules and scenario analyses. Extensive analysis of the output and the choices for specific statistical techniques.
I pay less attention to: The accuracy and realism of parameters and its distributions. A lot of data about processes is available in all different qualities. Since I use simplified interpretations of processes in the simulation model, I need to manipulate this data to be able to use it (in some cases no data exist at all). Collecting and constructing accurate datasets and fitting optimal distributions would take months, therefore I accept a lower quality level. The implication is that validation of the simulation result becomes harder since the quality of the output will be questionable as well. Difficult details within process descriptions that result from operational habits and settlements. On the platform, a lot of ‘rules of thumb’exist for controlling processes and to settle delicate situations between operators. Most of the time these agreements deal with dividing workload and extra breaks equally. These rules and habits are based on practical experience, they differ per shift leader/dispatcher and they cannot be found in any manual. I decide to ‘stick with the book’, although this might be less realistic. A user friendly graphical interface on the simulation tool. Since my simulation model presents a simplified prototype of a possibly larger simulation tool, it is not meant to be used in practice. Building a GUI takes lots of time and know-how, which I do not have.
The most important idea of this thesis is to show the possibilities of punctuality forecasting by simulating turnaround operations. My simulation tool can be used to explore the possibilities in the field of punctuality. It is not an end-product for direct use, it should be regarded as the starting point of simulation-based forecasting at Aircraft Services or other departments within Ground Services. To show how valuable this analysis can be in practice I decided to link my simulation model to the OPiuM tool that is used throughout KLM.
3.3 View on OPC
This section describes one of the most important choices I made in developing my simulation model. In fact, it strengthens the arguments to use simulation and to what extent this creates new opportunities for the OPC trajectory.
As described in Chapter 2, the OPC is a feasibility check on the timetable. According to deterministic rules and norms and the deterministic timetable, an efficient workload schedule is created for each department which provides insight in the number of resources needed to perform the proposed timetable. To create an efficient schedule, PlanControl is used, which actually performs the following optimization:
Min Resources needed s.t. - performing all turnaround actions according to the timetable - deterministic norms for process durations
This has two major differences compared to the optimization I perform with my analysis:
Min Delays of departing aircrafts s.t. - performing all turnaround actions given available resources - stochastic timetable and stochastic process durations
First of all, I minimize delays instead of capacities. Given the capacities by the PlanControl analysis of the timetable, I start executing the timetable as well as possible. The second difference is what makes
THESIS PAUL ADRIAANSEN –APRIL 2009 21 this analysis interesting: I’m not working with the fixed norms and deterministic timetable PlanControl uses: in my model, uncertainty in flight times and norms creates delays.
When no uncertainty would exist, my analysis would give no delays at all, since the OPC is about making a deterministic timetable feasible: it would just have rebuilt the PlanControl schedule. But by making the timetable and all norms stochastic, the problem becomes much more realistic: on the day- of-operation, AS also has to react on uncertainties in the schedule, while the number of resources is limited.
This is how I link the concept of OPC, in which punctuality is no issue at all, to the stochastic nature of the platform process on the day-of-operation: 1. Use the results of the OPC (an efficient workload schedule) as fixed capacities 2. Simulate the timetable (arrivals) based on historical data 3. Simulate the platform processes according to realistic decision rules 4. Measure the punctuality of departing flights
This approach is the basis of my simulation study and is further explained in Chapter 5.
3.4 Literature
The use of scientific literature was not a goal in itself in my research project. Although I did perform some searches on relevant topics about simulation of turnaround processes, platform operations at airports and simulation of stochastic job-shop models, I hardly found any relevant articles. Most of the literature I found was written by the OR department of KLM (AMS/QO), of which I already received most of the interesting papers. So, when it comes to using up-to-date literature on the specific topic of simulating timetables, I am pretty sure of covering all relevant findings. Since every simulation study is different in its own details and properties, it is in general hard to find relevant literature.
Since the main part of this thesis it about simulation, the book “Simulation Modeling and Analysis” by Law and Kelton (2000) played a central role. For information about the statistical operations, the book “Introduction to Probability and Mathematical Statistics” by Bain and Engelhardt (1992) was used. All the theoretical insights that are used from these titles are discussed in the relevant sections throughout this thesis. Since the theory about simulation and statistics used in this thesis is not very complicated, not very specific and quite fragmented, I decided not to include a specific chapter on theory.
Most of the sources I used concern internal publications, guides and handbooks of KLM and theses of other interns. The theses and handbooks that were used to obtain insights, ideas and data are mentioned in the reference list.
THESIS PAUL ADRIAANSEN –APRIL 2009 22 CHAPTER IV
PUNCTUALITY
In this chapter the concept of punctuality and its use in this thesis is explained. The first section shows the difficulties with this concept, since it turns out to be quite hard to find the responsible process(es) for a delay. The second section describes the Key Performance Indicators that the management of AS and the HCC are currently using. The last section introduces the concept of PassengerDelayMinutes (PDM) and shows how this can be used to allocate different parts of the total delay among the responsible processes.
4.1 Working with punctuality
In this section we will look at what punctuality means and how we can work with it. After we introduced the difference between deadlines and durations, an overview is presented in which seven levels of punctuality are discussed.
4.1.1 Deadlines and durations
In general, people refer to “punctual” as promptness: an event happening at the appointed time. This is in fact a Boolean variable: true or false for a certain event. Although it is possible that an event happens too early, in this thesis we regard an event as punctual when it happens before some predefined deadline or due date. Another form of being “in time” can be to perform some action within its norm duration. In this case we are not particular interested in the deadline, but we assess the duration of some process according to predefined norms. The combination of these concepts turn out to be crucial in determining punctuality measurement within the AS departments.
In Appendix 4.A an elaborate example is presented about how deadlines and durations relate to each other. It also shows the complexity of defining and measuring punctuality and the difficulty of comparing punctuality at different levels throughout an organization. After reading the example, typical questions one might have are: Which events are deadline related and when should we look at durations? How should we relate the delay of a passenger to the turnaround performance? What is the exact deadline for the departure of a flight and how is it achieved? Is there a difference in departure delay when we view it from AS, GS or KLM level? How can we describe causalities in different delay events?
THESIS PAUL ADRIAANSEN –JANUARY 2009 Do we take the difference between actual ending point and the deadline (positive or negative) into account? Who are responsible for the departure delay? How fair is it to blame these parties?
To illustrate the concepts of duration and deadline, Figure 4.1 shows two scenarios in performing a cleaning job.
Cleaning duration = 34 Flight
Latest Starting Time (due to norm) LET STD cleaning
Case 1: Cleaning duration too long, but job ended before LET (Latest Ending Time) deadline: punctual
Minimal norm: Cleaning duration = 26 STD - LET Flight
Latest Starting Time (due to norm) LET STD cleaning
Delay = 4
Case 2: Cleaning duration within norm, but job ended too late: Delay = 4
The norm duration of a cleaning job is 28
Figure 4.1: Illustration of duration and deadline for a cleaning job
4.1.2 Seven levels of punctuality
In this section we introduce an overview of seven levels of punctuality that answers some of the questions raised in the previous section. First we describe the seven levels in Figure 4.2; in the following section we take a look at the links with operational and organizational departments within KLM.
As we saw earlier, a job is the smallest entity we look at, so the first level is formed by the duration and Latest Ending Time (LET, recall Section 2.3) of a job. There exist three flows, of which we are particularly interested in the Aircraft flow. We therefore define the duration of a flow and the time that it is finished as the second level. Note that we do not put the pushback into the aircraft flow, this becomes clear later on. The three flows (and the E&M processes) together form the total turnaround, which of course has a duration and an ending time. We refer to the turnaround as the third level.
The permitted duration of a turnaround depends on the available ground time. The time between the instant the first door opens (ADO) and the “Scheduled All Doors Closed” event, dictates the actual available time for the turnaround (excluding the pushback). This can be (much) more than the minimal turnaround time, but also less. This can for example be the result of an arrival delay. We now say that the permitted duration of a turnaround (the norm) is equal to the difference between ADO and Scheduled ADC, but always at least equal to the norm for the minimal turnaround as presented in the AIS.
After the All Doors Closed event, pushback should start. As described in Section 2.2.1, pushback consists of two parts. The first part (rigging and inspection) can already be done in the turnaround
THESIS PAUL ADRIAANSEN –APRIL 2009 24 procedure (before ADC), so after ADC, the pushback itself should start. This means that in the optimal situation, only a few minutes of time pass between ADC and ABD (Actual Block Departure). However, there are some things that can frustrate the pushback process to a large extent: 1. First of all the towing truck can be late (due to a capacity problem or something else) or too slow in its preparation. 2. The pilot can be late (or unprepared) which takes some extra time or he can discover technical problems during preparation, which were not found earlier. 3. The “Tower”(AAS) can decide to delay or skip the original take-off slot, so the aircrafts receives no permission to enter the taxi lanes (this especially happens when the aircrafts is already late).
This difference between ADC and ABD allows us to separate the turnaround (which is primarily controlled by Ground Services) from the pushback process (which is influenced by several exogenous factors). So we define the Actual Block Departure as the fourth level.
The fifth level is a simple one: it consists of the taxiing time (duration) from the gate to the take-off runway (including queuing). The measure we use as the deadline of this interval is the actual take-off. The sixth level is the flight itself. The flight has a clear duration and we can see the touchdown as the arrival moment.
Finally, the aircraft taxies to the gate, a passenger leaves the aircraft and walks through the airport of arrival (the KLM outstation), waits for his baggage, queues for customs control (in case of a non- Schengen destination) and leaves the airport. This whole process influences the punctuality perception of this passenger but is not within the control span of KLM. Therefore the seventh and last level, the arrival of a passenger at the outstation, is important to recognize but not very helpful for our analysis.
4.1.3 Levels of responsibility
The levels at which punctuality is measured follow in general the organizational hierarchy. When we take the management of Aircraft Services as the starting point and look down the ladder, we see the different departments for which the AS management is responsible. These departments in itself are responsible for their operators. Upward in the hierarchy, we see that the AS management reports to the management of Ground Services. Ground Services in itself is only one of the many divisions that carry responsibility for the operational performance (we have, for instance, Engineering&Maintenance, In-flight Services, Crew planning, Fleet availability, OCC, etc.). We also have to deal with stakeholders outside KLM: Amsterdam Airport Schiphol (AAS) and Air Traffic Control (ATC). All these levels together determine the performance of the KLM timetable. Now we place the customer (as a group, or even as an individual) on top of this hierarchical structure. Since this is the end user of KLM’s product, he or she is the ultimate assessor of the punctuality performance.
The overview distinguishes between organizational and operational responsibility. On the organizational side, the Operational Manager and Shift leader have no direct control over individual actions on the platform. On the operational side, the distinction becomes less clear in the higher echelons, since this is not what we are interested in. Furthermore, the two columns with seven boxes on the right show we differentiated between a focus on deadlines and a focus on durations. The gray areas are the most interesting. These show that the focus shifts from duration-oriented (in the lower levels) to deadline-oriented (from the turnaround level on). This coincides with the Building Block theory presented in Chapter 2: a punctual block departure means a punctual end of BB4 (or BB24).
AS is only one of the flows of level 2, which makes that AS has not much power in the level 3 punctuality (the turnaround). Other flows (pax and bax) and E&M influence the performance to a large extent. However, since pushback is a level 4 operation (technically it belongs to the flight Block) AS is involved up to this level. Therefore I focus on the first four levels in this thesis and I am specifically interested in the role of dispatchers in preventing delays by controlling the LET deadlines of individual jobs.
THESIS PAUL ADRIAANSEN –APRIL 2009 25 y t i l i b i s n o p s e r
f o
s l e v e l
n e v e S
: 2 . 4
e r u g i F
THESIS PAUL ADRIAANSEN –APRIL 2009 26 4.2 Management Key Performance Indicators
The seven levels model answered the question about how subsequent management levels (like AS, GS and KLM as a whole) look at punctuality. In this section we look at the Key Performance Indicators (KPI’s) and performance meetings that are used to control the punctuality from a management perspective on different levels. In general there are three relevant levels: 1. The highest level is the Punctuality Analysis Tool (PAT) of the OCC, this collects data on Building Block level (flights). 2. Ground Services has the Ground Performance Meeting (GPM) which deals with the different GS flows (AS, Pax and Bax). 3. Aircraft Services has the Unit Performance Meeting (UPM) that assesses the performance of all AS departments.
4.2.1 Delay codes and performance meetings
The OCC is the highest operational authority and has the power to assign delay codes to every departing aircraft. A delay code is a number (from 0 to 99) corresponding to a certain KLM department or delay cause and the length of the delay in minutes is always attached to it. Per departure, a maximum of two codes can be assigned, where the responsible department or cause with the “longest” code is considered the main cause of delay. More information and punctuality numbers can be found in Appendix 4.A. In that appendix also the most important performance meetings are described.
Throughout KLM, a delay is always given one of four labels: “ICA < 15min.”, “ICA >= 15min.”, “EUR < 5 min.” and “EUR >= 5min.”. This categorization is used to summarize the data and indicates the importance of some “acceptance bound” for short delays (where “short” depends on whether the flight is EUR or ICA). I also use this distinction in my punctuality measurements.
4.2.2 Other data on performance
One of the deficits of the PAT is that it is only a rough instrument to register delays. It is used for management purposes on a high level, while the HCC would want to have more detailed delay information. The UPM monitor is useful, but it is still based on the delay codes assigned by the OCC, that correspond to punctuality level 3 and 4. These delay codes give no opportunity to take more delicate questions into account that need information about punctuality in level 1 and 2 (durations and deadlines). It would be desirable to have more tools to analyze the performance of AS departments on individual job durations and jobs exceeding their LET.
Since AS delays form only a small portion of the total delays and delays caused by AS are short compared to other delays, there is a big chance that small AS delays are overshadowed by other, larger delays. For instance, a towing truck arriving five minutes late is never registered as a possible delay cause when the flight needs to wait 25 minutes for a missing passenger. This means that it is quite a random process whether a long duration or exceeding a LET eventually leads to a delay code assigned to AS.
We do have a lot of information and data about all the processing times and durations of jobs, possibly multiple LET’s based on subsequent EBD’s, etc., since this is all stored in the CHIP ReportControl database. The challenge is to make this information accessible through intelligent queries on this database, but this is frustrated by the incompleteness of the data and the complex nature of the platform processes. In the next section I present some ideas about new punctuality measures specifically for AS, since I did not face these problems with the output from my simulation model.
THESIS PAUL ADRIAANSEN –APRIL 2009 27 4.3 View on punctuality
The measurement of punctuality in the simulation model is rather straightforward and follows the same rules as currently used within KLM. This is described in Subsection 4.3.1. The interesting part follows in Subsection 4.3.2 where definitions are developed to allocate delay minutes between different AS and non-AS processes in a fair way. The last subsection deals with the exact calculation of these definitions for each process.
4.3.1 Measuring punctuality
Chapter 5 explains how the simulation model works, but the definitions in this section can be used independently of the simulation itself. We just assume the following about the output of the simulation: 1. We simulate the arrival and departure of aircrafts according to the timetable and register eventual departure delays. 2. All jobs and actions performed on a specific aircraft are registered, which means the starting and ending times of driving and processing are recorded.
As showed in Subsection 4.2.1 the UPM works with four complementary punctuality measures: Within the categories WiBo and NaBo a distinction is made between all delays (count all delays with a positive length) and “long” delays (only count delays with a length equal to or greater than 15 minutes for WiBo and 5 minutes for NaBo). The only deviation I made to this rule is that I additionally split the NaBo group in two: NaBo (only containing 737 types) and KLC (the Fokker types). Note that the length of a delay is not known: the punctuality measure is defined as the number of delays as a percentage of the total number of aircrafts.
It would be preferable to have some sort of general measure that summarizes the six measures introduced above. It would also be a good idea to take the specific length of a delay into account, since currently two NaBo delays of 6 and 60 minutes are weighed equally. The resulting measure is called “Passenger Delay Minutes” (PDM) and is defined as:
PDM length of delay number of passengers all delayed aircrafts
This measure is based on the following assumptions: 1. The weight of a delay is linear to its duration, and starts at 0. So there is no “initial cost” for a delay, and the distinction between short and long delays disappears. 2. The number of passengers can be estimated for each separate flight, or just taken equal to some fixed value depending only on the aircraft type. It is also possible to adjust this number to the percentage of business class passengers. 3. The weight of a delay does not depend on the length of the flight. One could argue that the passengers’sensitiveness to a delay of 5 minutes decreases with the length of the flight. On the other hand, long flights are often performed by large aircrafts and a 5 minute delay of a large aircraft has more impact on the stability of the operation. Both effects are discarded. 4. An early departure is not valued positively, there is no such thing as negative delay.
Note that PDM’s are only calculated for departing aircrafts. The underlying assumption is that AS has no influence whatsoever on the arrival delay of passengers flying to Amsterdam.
4.3.2 Identification of delay causes
For each departing aircraft the PDM is calculated when it is delayed. In the current situation the OCC would appoint a responsible process and assign its corresponding department a delay code. When two processes are found responsible (this happens in almost 30% of all cases), the length of the delay is divided quite arbitrarily. In an ideal situation, one would assign the PDM to processes according to the following concept: 1. Divide the PDM among all processes that were involved in causing the delay. This includes indirect causes in the early stages of a turnaround.
THESIS PAUL ADRIAANSEN –APRIL 2009 28 2. Use some scheme of proportional allocation of the DPM based on some principle of fairness. The idea is to divide the burden among the responsible processes in a fair way.
The “principle of fairness” could be based on hundreds of different (exotic) ideas about how a delay is caused and who is responsible for it. Another way is to look for a usable model from game theory and apply it to the situation. Since the game theory option turned out to be very difficult to implement (due to the evolvement of time), I decided to base the fair PDM allocation on the following non-exotic rules: 1. When an aircraft arrives late, this should be accounted for within the PDM allocation, especially when the turnaround time left (STD –ABA) is shorter than the norm duration of the turnaround. 2. Every process has a LET, based on the STD of the aircraft. In principle, crossing the LET could lead to a delay and therefore a process crossing its LET is accessory to an eventual delay. The weight of this process in the PDM allocation should be equal to the LET overrun. 3. An addition to rule 2) is made when by the time of scheduling a process, the remaining ground time for this process turns out to be shorter than the maximum path of norm durations of processes that still need to be performed. The LET should then not be based on the STD, but on the EBD at the time of scheduling (for details, see Section 5.4.1). 4. An exception to rule 2) and 3) is made for processes that arrived on time at the gate (before the LST based on the EBD) but were not able to start because any preceding process was not yet finished. These processes are in principle not responsible for any delays. 5. An exception to rule 4) is made for processes whose LET overrun is larger than their LST overrun (the time this process had to wait for a preceding process). This means that these processes exceeded their norm duration. These processes are responsible for an eventual delay and the weight should be equal to the overrun of the norm duration.
These five rules together look somewhat complicated, but in general it boils down to the following questions: 1. Was the process ready in time? 2. If not, did the process have enough ground time? 3. If not, did the resource arrive at the gate on time?
The weight of a certain process in the total delay is equal to the number of minutes that this process would have been finished earlier when it performed according to “the norm”. Performing to “the norm” means that the process did not exceed its norm duration and arrived at the aircraft on time (before the LST according to the maximum of STD and EBD). Note that a late arrival can also be caused by a driving duration above norm, which is weighted equally.
In general, the sum of “responsible minutes” over all processes responsible for a certain delay will exceed the actual delay duration. Therefore the PDM per process is linearly scaled down. When we now sum up the PDM per process for each delayed aircraft in some predefined time window, we have a weighted overview of all the delay causes for each period of the day. In Figure 4.3 an example is presented of the total PDM as the sum of the PDM of eight processes per half hour. For clarity reasons, this example is restricted to a single morning and eight processes only, but this technique can be extended to many more processes and a long time period. In the figure also the number of flights and delayed flights are added. In this way the original way of measuring punctuality (the fraction of flights delayed) can be combined with the PDM methodology.
THESIS PAUL ADRIAANSEN –APRIL 2009 29 50000 20 s t
45000 18 h g i l F
40000 16 f o
s r e e t
35000 14 b u n m i u M
30000 12 N y a l e 25000 10 D kluhcleaning r e
g 20000 8 kluhcheck n e
s fuelnonhydrant
s 15000 6 a fuelhydrant P 10000 4 boarding bax 5000 2 asitocleaning 0 0 asitocheck 4:30 5:30 6:30 7:30 8:30 9:30 10:30 11:30 12:30 Flights Time Delayed flights Figure 4.3: Example of punctuality report
It is necessary to make an important comment on how the PDM is assigned to a specific time window. I decided to assign all the delay minutes caused during the turnaround of an aircraft to the time window of the STD of that aircraft. The reason for this is that it would become extremely difficult to assign the delay minutes to the time window in which they were created. Delay can originate from the start of a process (e.g. late arrival at the gate or low capacity), somewhere at the end (exceeding the norm duration) or both. Furthermore the delay minutes should then be spread over up to three time windows. Investigating this for every single process that is responsible for a delay would be far too elaborate. The consequence of this decision is that a low capacity in the Asito cleaning teams at 7:55 and a long duration of a Pushback at 10:20, could both lead to PDM assigned to the associated aircraft with an STD of 9:40.
4.3.3 Calculation of the PDM weights
In this section an in-depth look is taken in the calculation of PDM weights per process. The fundament of this calculation is the “dynamic time window calculator”. This is an Excel based computer program that calculates all the A+ and D–times for all processes and all aircrafts in the output of the simulation model. This is done by constructing paths of succeeding processes of which the duration is taken equal to their norm. This is quite straightforward, but an extra feature is that it can calculate all A+ and D–times at any point in time. So this makes it possible to evaluate the A+ and D–times of processes in the future, based on some current situation halfway the turnaround. This is used to forecast the EBD times with a retrospective effect, and this EBD can be used to calculate the LET of every single process at any point in time. This procedure was already introduced in Section 2.3.2 and will again return in Section 5.4.
The A+ and D–times lead to the Latest Starting Time (LST) and Latest Ending Time (LET) which are used in the five PDM allocation rules, together with the norm durations. Now it is possible to exactly calculate the delay minutes assigned to every process which forms the weights in the PDM allocation.
To clarify this, take a look at the examples in Figure 4.4. The green lines underlining the processes take at most the length of the norm duration. The excess to the norm is colored red. The length of the scheduled turnaround is 70 minutes, while the norm duration of the turnaround is only 60. In Case 1 you can see that this 10 minute slack can be used by processes overrunning their norm duration, without causing delay. As long as there is no delay, processes do not experience any negative effects for overrunning their norm or crossing their LET. The process of interest is a fuelling job called “fuelhydrant”.
THESIS PAUL ADRIAANSEN –APRIL 2009 30 In Case 2 the LST and LET of fuelhydrant (the process of interest in these examples) shift with the delay of the aircraft. Since the LET is not crossed, fuelhydrant is not responsible (according to rule 1 and 3). In Case 3 fuelhydrant overruns its LET with 6 minutes, so the 8 minute norm excess is not important here (use rule 2 and 3). The aircraft arrival (a process that is called “Flight”, see Chapter 5 for details) crosses its LET by 4, since there exists 10 minutes slack (rule 1). In Case 4 fuelhydrant is not blamed for any delay because it performs under or equal to its norm, and it arrived on time (rule 4). In the final case (Case 5) rule 5 is not applicable since fuelhydrant did not arrive before its LST. The PDM is allocated according rule 1, 2 and 3. Note that in all cases it is assumed that the fuelhydrant was scheduled at the beginning of the first preceding process (after the arrival process Flight).
THESIS PAUL ADRIAANSEN –APRIL 2009 31 Case 1: The scheduled ground time is 70. The norm for the turnaround is 60 according to the norm durations of the processes in the maximum path. The succeeding processes take too long, but there is no delay.
preceding processes fuelhydrant succeeding processes
0 10 20 30 40 50 60 70 time STA STD LST LET
Case 2: The aircraft arrives 16 minutes late. All the processes take their norm durations. The Flight process is 100% responsible for the delay of 6 minutes. All LET times shift 6 minutes.
preceding processes fuelhydrant succeeding processes
0 10 20 30 40 50 60 70 time STA ATA STD ATD LST LET
Case 3: The aircraft arrives 14 minutes late. The fuelhydrant process overruns its norm with 8 minutes. Both the preceding and succeeding processes perform under their norm duration. Fuelhydrant takes 60% (since the LET was overrun with 6) of the responsibility, Flight the resting 40%. The total delay is only 8 minutes, not 10.
preceding processes fuelhydrant succeeding processes
0 10 20 30 40 50 60 70 time STA ATA STD ATD LST LET
Case 4: The aircraft arrives 8 minutes late. The fuelhydrant process arrives at the gate in time (at its LST) but is not able to start since the preceding processes overrun their norm. Fuelhydrant crosses it LET, but the preceding processes are to blame (100%) for the 4 minute delay.
preceding processes fuelhydrant succeeding processes
0 10 20 30 40 50 60 70 time STA ATA STD LST LET ATD
Case 5: The aircraft arrives 2 minutes late (Flight gets 20%). The fuelhydrant process arrives 4 minutes late at the gate and overruns it norm with 2 (gets 60%). The preceding processes are not on the critical path (because fuelhydrant arrives late), but did cross their LET, so they take the last 20% of responsibility.
preceding processes fuelhydrant succeeding processes
0 10 20 30 40 50 60 70 time STA STD ATA LST LET ATD
Figure 4.4: Five cases in PDM allocation
THESIS PAUL ADRIAANSEN –APRIL 2009 32 CHAPTER V
CONCEPTUAL MODEL
This chapter is by far the most important chapter when one wants to understand in detail what the discrete-event simulation system of the project looks like. In this chapter, all observations of the platform processes, my view on the OPC and the ideas about punctuality and allocating delays among the responsible processes are combined. It starts with the overall lay-out of the model and a description of all objects that appear in the actual simulation program. The third section describes how these objects interact and how the flow of a job looks like. The last section introduces different types of intelligent decision making tools that are integrated in the simulation system. This chapter also forms the birth of “Picasso”, since “Picasso” is the name that I gave to my simulation model; the background behind this name can be found in Appendix 5.A.
5.1 Model lay-out
In this section the lay-out of the Picasso model is explained by presenting diagrams that contain all components concerning input, simulation and output. Since quantitative issues are discussed in the next chapter, I will mainly focus on the components of the simulation model. In some cases the exact description of certain objects is omitted, but this will be done in the following sections. This is also the section where we start making modelling assumptions. Of course I try to justify every assumption as clearly as possible.
5.1.1 The pre-Picasso trajectory: OPC and OPiuM
Figure 5.1 presents the layout of the pre-Picasso trajectory. It describes how the input for the OPC, the input for OPiuM and the additional data from ReportControl lead to the input for Picasso. In this section this diagram is reviewed and the special role of OPiuM in Picasso is described.
THESIS PAUL ADRIAANSEN –JANUARY 2009 Input from ground processes
Control Handling Handling Data from rules procedures norms practice manuals AIS & AIS & CHIP ReportControl HCC & OCC manuals
External input PlanControl CLA1
Operational Check Timetable
Workload schedules Current OPC OPiuM trajectory BB information Building Block Simulation
Output from OPC trajectory and 1. Aircraft 2. Priority 3. Process 4. Resource 5. Norms, OPiuM simulation arrival preferences control; rules capacities distributions & is input for information & procedures probabilities Picasso simulation
1. Collective Labour Agreement (CAO in Dutch)
Figure 5.1: Input from ground processes leads to input for Picasso via OPC and OPiuM
We start with the input from the ground processes: Handling procedures: this is the information that follows from the AIS and the additional rules that are used by the departments to control the daily operation. It contains all information about the jobs an aircraft needs, precedence relations between processes, time windows and the use of resources. Control rules: these are the rules that come on top of the handling procedures and are used by the OCC and HCC to control the hub performance. The rules that are used within PlanControl and the OPC are: VOP allocation and towing, process and resource scheduling and ground time specifications (mainly HCC). The rules that OPiuM uses deal with Building Block allocation and Fleet Availability (mainly OCC). In Picasso also OCC rules on priority setting are used. Handling norms: The norms in AIS, CHIP and PlanControl differ for almost every job, but the norms in PlanControl are based in large part on the first two. Data from practice: In the OPC a lot of empirical data from ReportControl is used to interpret the workload figures. In Picasso also ReportControl is used to construct distributions of job durations and estimate certain probabilities.
The OPC trajectory is already described in Section 2.5 so it is only touched briefly here. Apart from the input mentioned above it obviously needs the timetable and some information on the CLA (work and shift hours). As stated in Section 3.3, Picasso uses the workload schedules as input for the simulation. Therefore I performed the whole OPC trajectory myself, using the exact timetable and data input I am going to use for the Picasso simulation. When it is now assumed that the timetable is deterministic, norm durations are deterministic and scheduling is performed optimally, then the obtained workload schedules exactly represent the resource capacities needed to perform all requested jobs. These resource capacities are used in Picasso, although some correction and rescaling is necessary.
In Figure 5.1, the numbered boxes 2 to 5 provide input information for Picasso that can be calculated in advance. This information follows directly from manuals, from statistical calculations on empirical data or from the OPC trajectory using PlanControl. Although it would have been possible to model the “Aircraft arrival information” in the same way, I chose to do it differently. In the Picasso simulation model, a special version of OPiuM (called “OPiuM for Picasso”) runs simultaneously with Picasso to be able to simulate the building blocks “in real time”. At the end of a BB1and at the beginning of a
THESIS PAUL ADRIAANSEN –APRIL 2009 34 BB4 OPiuM sends a message to Picasso. This message contains all the information about the associated flight and this leads to the creation of an aircraft entity in Picasso. Therefore the box with Aircraft arrival information is filled by OPiuM during the simulation run and the OPiuM building block simulation is part of the Picasso simulation itself (this is more correctly depicted in Figure 5.2).
However, using OPiuM next to the OPC trajectory requires assumptions about what time frame is available for ground handling. To assure consistency in the results, I decided to use the “PlanControl Towing norm” (270 minutes) as leading for splitting the groundtime into building blocks. This norm looks at the time between two flights, and creates a building block 3 when it exceeds 270 minutes. This means that the turnaround action is split in an arrival action (BB2), an idle time period (BB3) and a departure action (BB4). In PlanControl the sum of BB2 and BB4 stays equal to 270 minutes, where one third of this time (90 minutes) is used for the arrival handling and the rest (180 minutes) is used for departure. Because OPiuM is used for simulation it is possible to divide ground time between arrival, departure and idle time more realistically.
The choice to use OPiuM has some important implications. Since OPiuM is used as a forecasting tool rather than an analyzer of historical data, it is difficult to load “old” timetables. Every season (summer and winter) OPiuM is revised to meet new standards and properties of the new timetables. I therefore chose to work only with the OPiuM settings for the timetable of the season “Summer 2007” (S07) and chose not to try older timetables. The other reason for this is that performing the whole OPC trajectory multiple times asks for a lot of time and effort of several people within Ground Services (at ST and K3). Therefore I chose to use the original check week of the S07 timetable (week 37: 10th to 16th of September, 2007) and disregard the possibility of comparing different timetables to each other. The reason for choosing a summer timetable (the Winter 2007-2008 timetable was also available) is two- fold: firstly, the summer is a busier period, which means more peaks that lead to significant delays, and secondly, the OPiuM settings for the summer do not take the de-icing operation into account. De- icing is a process that frustrates the operation in an unpredictable way, so measuring in the summer gives more reasonable results.
5.1.2 The conceptual layout of Picasso
Figure 5.2 gives the layout of Picasso. I will describe all the components in the diagram briefly, since all of them are described in more detail in the rest of this chapter. I used icons in the layout to simplify the explanation. These icons will be used in some of the following diagrams as well.
The first part of the diagram represents the input of Picasso. It is possible to recognize the five boxes from Figure 5.1, that all lead to one or more input components. From left to right there are: aircrafts, a “list” component, processes with queues, a scheduling component, a priority calculator and two types of resources: unlimited and capacity-restricted resources. All these represent imaginable components, except for the “list” function. This is an administrative component that is one-to-one connected with an aircraft. Every aircraft has a list attached to it that has three functions: 1. It contains all the necessary information about the processes the aircraft needs and the precedence relations between them. From these precedence relations also the scheduling diagram follows, which is explained in Section 5.3. 2. Other information that is present at the list from the start (the arrival of the aircraft induces the creation of the associated list) concerns the norms, process duration distributions and all kinds of probabilities. 3. The third group of information about the aircraft is collected during the simulation itself. The list keeps track of all the virtual movements of the aircraft and all the jobs that are performed, including the exact moments in time of these events. For every aircraft a logbook is maintained that is directly linked to the aircraft.
THESIS PAUL ADRIAANSEN –APRIL 2009 35 Input for Picasso Simulation model
1. Aircraft 5. Norms, 3. Process 2. Priority 4. Resource arrival distributions & control; rules preferences capacities information probabilities & procedures
Picasso Simulation model
Control environment
OPiuM for Picasso Platform environment Process environment
Output from Picasso Simulation model
Aircraft Database
Individual Turnaround + analyzer
View on punctuality Punctuality Analyzer
Punctuality report Identification of bottlenecks
… % … % … %
Figure 5.2: Overview of Picasso simulation model with input and output description
The Picasso simulation model roughly consists of four environments: 1. OPiuM for Picasso: this is the component that initiates all actions. OPiuM creates aircrafts according to its own simulation engine and hands these aircrafts over to the core of Picasso. In this transition also the list of the aircraft is created. 2. Control: the control environment is where the decision making takes place. It has mainly two functions: scheduling events (this is represented by the scheduling icon) and setting priorities (represented by the “prio” calculator icon). It controls allfunctionalities of the following two environments, since it manages all the entities in the system.
THESIS PAUL ADRIAANSEN –APRIL 2009 36 3. The platform: this environment represents the physical interpretation of the platform operation. It contains aircrafts and resources that are modelled in such a way that they could have been real aircrafts and trucks driving across the platform, performing all kinds of actions. These aircrafts and trucks can only have a location and status that corresponds to a real situation on the platform. 4. The process environment: this is the virtual counterpart of the platform. It consists of processes (workstations) with servers (the counterparts of resources) and queues containing jobs and it is modelled as a queuing network.
The three environments in the core of Picasso (excluding OPiuM) are strongly connected and communicate which each other. For instance, a “server” of a certain process corresponds to a “truck” on the platform, while they both represent a single “resource”. The function of the “server” and the “truck” is different though; splitting both environments in a “job-shop part” and a “queuing network part” makes the model more logical and clear, without creating much more objects (and thus maintaining efficiency). The control environment is responsible for managing all entities and it uses the list of the aircraft to commission assignments. Every environment has “read and write” rights to certain parts of the list of an aircraft and communicates with other environments via these lists.
The last part of the Picasso model in Figure 5.2 deals with the output. At the end of the simulation model all the aircrafts that have been created and the corresponding lists are put into a database. This database has a record for each aircraft that has existed during the simulation and this record contains a large part of the information (logbook) from the list. With the “individual turnaround analyzer” it is possible to read this record and interpret it in relation to the timetable and the norms. But the most interesting information about the simulation run is created in the “Punctuality analyzer”. This tool calculates all kinds of measures and indicators that follow from the “view on punctuality”, as formulated in Chapter 4. Eventually it produces two reports: one on the punctuality performance of the timetable and one on the specific processes that caused delays.
5.2 Objects in the model
In this section I focus on the three main elements of the platform process: the aircrafts, the resources and the interaction between these two: the jobs. It is described how an aircraft, resource or job looks like: what are the properties and features of it. In fact the complex real-life descriptions from Chapter 2 are translated into simplified and structured objects that can be used in the simulation model.
5.2.1 Aircrafts
Everything starts with the aircrafts. As earlier explained, aircrafts enter the system via OPiuM. An aircraft is presented as an object that requests certain services, depending on mainly two arguments: its action and its type. Four different actions are distinguished: 1. Turnaround (TA): The aircraft lands, taxis to the gate, receives services, is pushed back, taxis to the runway and departs. 2. Arrival (ARR): The aircraft lands, taxis to the gate, receives services and is towed to a hangar or buffer position. 3. Departure from the hangar (DEPH): The aircraft is towed from a hangar to a gate, receives services, is pushed back, taxis to the runway and departs. An aircraft can be in a hangar for weeks. 4. Departure from a buffer position (DEPB): Same, but now the aircraft comes from a buffer, where it has only been a few hours. The origin of a departing aircraft (buffer or hangar) influences the package of services needed.
These four actions are a simplification of what happens in practice and have two important consequences: firstly, I disregard the possibility of “handling on the buffer”. Handling on the buffer is a possible fallback for some departments (mainly cleaning and catering) in busy periods. I disregard this option for two reasons: firstly it is difficult to model and secondly it is disregarded in the OPC as well. The OPC asks for acting “according to the textbook”, which prescribes handling only at the gate. The second consequence is that “nightly stop-over’s” are seen as two split actions, an ARR and DEPB,
THESIS PAUL ADRIAANSEN –APRIL 2009 37 when the total ground time exceeds some threshold value (270 minutes in general). In practice, the aircraft probably never leaves the gate and can be serviced all night long.
As explained in Chapter 2, the different departments of Aircraft Services have different client portfolios. For AS altogether, roughly 50% of all work follows from KLM and another 25% follows from KLM Cityhopper (KLC). KLM and KLC are uniquely serviced by AS; the other 25% is formed by airlines that only purchase parts of their services at AS. The original OPiuM software only includes the KLM aircrafts; the special “OPiuM for Picasso” edition (which is discussed in Chapter 6) also covers KLC. The aircrafts of other airlines (of which Martinair, Transavia, Air France, Northwest and Kenya Air are the most important) could not be implemented in OPiuM and are therefore left out of the model. This has one major disadvantage: the model is incomplete since it covers only 75% of all platform activities. The advantages though, justify the choice for KLM and KLC operations only: first, using OPiuM makes the analysis much more realistic; second, there is not much information available about the aircraft types other airlines fly with; third, other airlines have totally different rules and ground time distributions that are difficult to model along KLM rules; fourth, since other airlines only partially use AS handling, insight in the causality in delays between the different departments of AS may be lost.
Nine aircraft types are modeled in OPiuM (all 110 KLM aircrafts, except the three 747 Cargo aircrafts, since these have very irregular flight schemes and often long ground times). These nine types are divided in two main groups: the Wide Body (WiBo or WB) aircrafts (74E, 744, 772, M11 and 332) and the Narrow Body (NaBo or NB) aircrafts (739, 738, 734 and 733). The adjusted OPiuM version for the model also includes a third main group: the three types of Fokker commuter aircrafts of KLC (55 in total; 100, F70 and F50). An overview of these aircrafts and their specific properties can be found in appendix 5.B.
Apart from the action and type of an aircraft, some other information is given of each aircraft: Origin and destination; this is given by the IATA three letter code of the Airport, e.g. AMS (for Schiphol), CDG (for Paris, Charles de Gaulle) or JFK (for New York, John F. Kennedy). When the destination of an aircraft is AMS, this means the aircraft goes to a hangar or buffer and the action is referred to as ARR. When the origin of an aircraft is AMS, it comes from a buffer (DEPB) or hangar (DEPH). Actual Time of Arrival (ATA); in the simulation model, this is the instant an aircraft is “created”: OPiuM simulates the end of a Building Block 1, which means the aircraft arrives at a gate position and BB2 (or BB2/4) starts. When we deal with a BB4, the ATA is taken equal to the Actual Block Arrival after towing, also called AOP (Aircraft On Position). Scheduled Time of Departure (STD); this is the instant the aircraft should depart according to the timetable. The STD differs one or two minutes from the Scheduled Block Departure (which is the theoretical end of the ground time), but this is largely omitted. When we deal with a BB2, the STD is equal to the Scheduled Block Departure according to a decision rule in OPiuM. In the model, this is referred to as the Scheduled Time of End of Arrival (STendARR).
Finally, one remark is important to make. Although both OPiuM and the Picasso model depict an action (TA, etc.) as the physical movement of an aircraft, it is in practice referred to as a “flight” (e.g. KL1149) rather than an “aircraft” (i.e.registration, e.g. PHBVA). OPiuM manages the assignment of flights to aircrafts, so by the time a flight enters the system, it is already clear which aircraft is performing that flight. The flight number and the date (which is also known in the system), form a unique link with the timetable. From the timetable the origin, destination and STD follows, while the aircraft type is added by OPiuM. The communication between OPiuM and Picasso is the subject of Subsection 6.1.3.
From now on I refer to an aircraft as the predefined combination of a flight with an action, together with all other available information introduced above. I write it in Italic and look at it as an entity entering the system, rather than a physically existing flying object. The same is true for some other terms that receive their definition in this chapter: action, type, resource, process, queue and job. When I use control I refer to the decision making environment that manages all entities in the simulation model.
THESIS PAUL ADRIAANSEN –APRIL 2009 38 5.2.2 Processes and resources
On the platform, mainly two types of resources exist: equipment and operators. In the OPC, both are considered limited and both could be binding in a particular situation. However, equipment will only be binding in the highest peaks, while you can have a shortage of operators anytime. In practice, shortage of equipment only occurs through multiple breakdown events. I therefore do not take this into account, since it cannot be predicted half a year in advance (which the OPC aims at). In the Picasso model, equipment and associated operator(s) are regarded as an unbreakable combination, a fixed entity of a certain resource.
The choices to take certain processes into account are based on the available resources rather than the needs of a certain aircraft. The processes are created in such a way that it is possible to construct a one-to-one mapping between a process and a resource: every process uses one type of resource uniquely. In some cases this leads to forced name-giving, but it is very convenient for modelling. In terms of queuing theory it is possible to look at a process as a counter or workstation with a number of servers equal to the number of resources. Within a process lots of different jobs exist, depending of the type and action of the associated aircraft. This means that within a certain process, the same resource can be allocated to different jobs, according to the needs of an aircraft.
In the Picasso model sixteen different processes (and thus resources) are distinguished. These sixteen processes are split in two groups: nine capacity-restricted processes (also inconsistently called AS processes) and seven capacity-unrestricted processes (also called non-AS processes). The capacity-restricted processes are (in brackets is the process name as I will use them throughout this thesis): 1. The toilet change operation by the Aqua department (toilet) 2. The water change, drain and refill operations by the Aqua department (water) 3. The fuel dispenser operation (including prefuel) by the Fuel Department (fuelhydrant) 4. The fuel tank truck operation by the Fuel Department (fuelnonhydrant) 5. The cleaning operation by Asito (asitocleaning) 6. The security check by Asito (asitocheck) 7. The cleaning operation by Klüh (kluhcleaning) 8. The security check by Klüh (kluhcheck) 9. The pushback operation by the Towing Department (pushback)
The capacity-unrestricted processes are: 10. The towing actions from and to hangars or buffers (towing) 11. Catering change or (un)loading (catering) 12. Boarding of passengers (boarding) 13. Deboarding of passengers (deboarding) 14. Baggage handling (bax) 15. Technical operations or line maintenance (tech) 16. Flight, an artificial process (flight)
The first group of processes is the most important group since these processes are represented as workstations with limited (and varying) capacity (the number of servers). This means that queues can arise: some platform processes need to wait for available servers and this may eventually lead to delays. This also raises the issue of priority setting in the queues since this can be an appropriate instrument to diminish total delays in departing aircrafts.
The second group mainly consists of processes that are not under the control of AS. Since the OPC does not take the available resources of other departments into account, it makes no sense to include their capacities in the Picasso study. Furthermore, available resources of other departments are sometimes hard to model or to calculate (e.g. baggage handling) and sometimes there doesn’t even exist a clear relation between the availability of resources and the handling progress (e.g. technical and passage operations).
THESIS PAUL ADRIAANSEN –APRIL 2009 39 In the second group, three processes need a closer look. Although catering is one of the most important AS processes, it is not modelled in the group of capacity-restricted processes. The reason for this is threefold: 1. The process is extremely difficult to model: the number of handling actions on an aircraft depends on the type, origin and destination. Furthermore, the smaller aircrafts are often simultaneously serviced in groups of two to four by one catering vehicle (resource). 2. An important part of the delays caused by catering, the board-supply delays, could be modelled much more easily within the asitocleaning process. This is explained later on. 3. The job dispatching of catering resources is performed by KCS at a different location. There is communication between KCS and HCC, but the KCS dispatchers do not use CHIP and are not under direct control of the DHM (the highest operational manager of the HCC).
The disadvantage of this decision is that delays resulting from a lack of capacity at catering are not modelled and catering delays only result from excessive durations in the process.
The second process that strictly speaking does not belong to the second group is towing. Apart from the fact that this process is also very hard to model, the actual reason that its capacity is omitted is that OPiuM is used to model all the towing decisions. OPiuM decides which aircrafts are towed to or from hangar or buffer positions according to the same rules that would have been used in the Picasso simulation system. The only difference is that OPiuM does not take capacity constraints into account and does not induce delays due to a shortage in towing trucks. It is possible to calculate the demand in resources afterwards and evaluate the levels, but it remains impossible to translate this into late AOP’s or delayed pushbacks since OPiuM makes decisions in an earlier stage and at a higher level. Therefore I split the processes of towing and pushback, and take only the latter as a capacity- restricted process.
The third strange process in the second group is flight. This artificial process creates a time gap between OPiuM and Picasso that is used for two goals: allowing Picasso to anticipate on information from OPiuM and allowing Picasso to simulate small deviations from the arrival times OPiuM communicates in order to increase realism. This time gap is discussed in Chapter 6.
Regarding the nine resources in the first group it is necessary to make some assumptions about how resources are modelled in order to link them to the real life situation: A resource is an unbreakable combination of a fixed amount of staff and equipment that is capable of performing all different jobs within one single process. The states in which a resource can be are: idle, driving, processing and waiting. The state “waiting” can have an argument: the reason a resource has to wait. The creation or deletion of a resource can happen at any time, induced by a decision of control. When a resource is created, it is directly available for executing jobs. When a resource is deleted, it first finishes its job, before it disappears. In executing a specific job, all resources of a certain type have identical properties and identically distributed processing times. A resource starts executing a job when all boundary conditions are met and finishes this job within a finite amount of time. A specific resource is not bound to working hours or shift hours. All resources within a process are regarded as a “joint pile”, rather than as individual entities. At the creation of a resource the pile is increased by one, at the deletion of a resource the pile is decreased by one (when no idle resource exists, the first one that ends its task is deleted).
Apart from these general assumptions, it is necessary to add some assumptions that only apply to specific resources: The cleaning and security check resources use teams of operators. In practice, these teams often vary in size and capabilities, depending on the properties of the aircraft. Furthermore, shift leaders can decide to split or merge teams to deal with sudden events on the platform. All team sizes are assumed to be equal per process and disregard splitting and merging, to keep the model in line with OPC decision making. The processes towing and pushback are split but we the different vehicles are not taken into account. I assume that all aircrafts can be handled by all towing trucks, while in fact smaller aircrafts are often handled by smaller trucks that cannot pushback large aircrafts. This is also true for some of the smaller tank trucks.
THESIS PAUL ADRIAANSEN –APRIL 2009 40 Some of the processes work with “surplus-teams” or “flexible assistance operators” that can provide extra capacity in case of incidents or a sudden high workload. I leave these out of this study since I do not want the model to take unlikely events into account.
In Chapter 6, all these resources in the simulation model are quantified and then it is also discussed how to deal with the assumptions made above.
5.2.3 Jobs
In this thesis I consider a job to be a specific action of a resource on an aircraft within the corresponding process. This is subject to some boundary conditions, since not every combination is valid. A unique job exists based on three dimensions: the associated process (16 in total), the action of the aircraft (TA, ARR, DEPH or DEPB) and the main group of the type of the aircraft (WiBo, NaBo or KLC). Of the 192 (16 x 4 x 3) possible combinations, 115 are valid jobs and another 15 are regarded as artificial jobs (this will be explained in Chapter 7). The remaining 62 combinations are invalid, for instance, boarding does not take place during an ARR (arrival) action. In Table 5.3 an overview is provided of which processes and actions give valid combinations for every main type group and how the job can be linked to the platform operations introduced in Section 2.2.
TA ARR DEPH DEPB
toilet change change change water change drain refill refill fuelhydrant final fuel prefuel final fuel final fuel fuelnonhydrant final fuel final fuel final fuel asitocleaning cleaning cleaning board supply board supply asitocheck secur. check secur. check secur. check kluhcleaning cleaning cleaning board supply board supply kluhcheck secur. check secur. check secur. check pushback pushback pushback pushback
towing artificial towing artificial artificial catering change unloading loading loading boarding boarding boarding boarding deboarding deboarding deboarding bax change unloading loading loading tech technical technical technical technical flight artificial artificial artificial artificial
WiBo NaBo KLC
Table 5.3: Overview of valid and artificial jobs with their practical interpretation
For all jobs (valid and artificial) mentioned in Table 5.3 the following notes are true: Every job has a positive and finite duration and this duration is stochastic. The distribution of the duration depends on the type of the aircraft. A general restriction for all jobs is that the aircraft concerned needs to be susceptible for the job. This means that the aircraft is available and often one or more preceding jobs need to be finished before the job can start. For every type of aircraft a precedence list exists that prescribes in which order jobs can be performed.
For some jobs additional restrictions or probabilities exist: The job “prefuel” (for WiBo ARR’s) is not always performed. It is performed with some probability depending on the type of the aircraft. The job “final fuel” for NaBo (in TA’s, DEPH’s and DEPB’s) can be performed within the process fuelhydrant or fuelnonhydrant. With some probability, depending on the type of the
THESIS PAUL ADRIAANSEN –APRIL 2009 41 aircraft, one of them is selected. The other process is skipped, since every aircraft receives a “final fuel” only once. The distribution of the duration of “final fuels” for WiBo (in TA’s, DEPH’s and DEPB’s) depends on the destination of the departing flight. When the distance is longer, the aircraft needs more fuel and the processing time will be longer. The “cleaning” jobs of Asito (asitocleaning in TA’s and ARR’s) consist of two parts. The first part is the job itself (cleaning processing time), the second part is a possible waiting time caused by late board supply delivery by KCS. This waiting time occurs with some probability and the distribution of this waiting time depends on the available ground time and the moment of processing. The “security check” jobs (asitocheck and kluhcheck in TA’s, DEPH’s and DEPB’s) consist of three parts. The first part is the unrestricted part of the check, which has no precedence relation with other jobs. Therefore it is included in the driving time of the resource. The second part is the job itself (security check processing time) which has precedence relations. The third part is a possible waiting time caused by late cabin crew attendance, since the check team needs to have a handshake with them. This waiting time occurs with some probability and the distribution of this waiting time depends on the moment and duration of processing. The “pushback” job also consists of three parts. The first part is an unrestricted part of the pushback (called rigging, see Subsection 2.2.1), which has no precedence relation with other jobs and is again included in the driving time of the resource. The second part is the job itself (pushback processing time) which has precedence relations. The third part is a possible waiting time caused by the lack of runway capacity. The AAS tower can impose take-off delays when an aircraft lost its take-off slot. This waiting time occurs with some probability that depends on the current delay in departure and has a positive stochastic duration (often long).
By now, quite a detailed demarcation of the study is made: it is defined which AS jobs are modelled and which interactions with processes outside AS are taken into account. Of all AS jobs, only the rare or unpredictable jobs are left out of the model: de-icing, flex tasks, extra fuels and defuels. Out of all non-AS processes, only the most important ones are picked to include in the model: passage, baggage and technical operations. In general, AS jobs are modelled in depth, while non-AS processes are touched roughly. This difference is further illustrated by setting capacity restrictions on AS processes and omitting capacity outside AS. The two violations to this rule are the towing and catering processes, but I belief these choices can be justified by the arguments introduced earlier. By taking board supply delivery, cabin crew attendance and AAS take-off delay into account within other processes, three originators of delays are added to the model, without creating additional processes. The relation between all processes is the subject of the next section.
5.3 The flow of jobs
This section deals with the relations between jobs. In the first subsection an in-depth look is taken at what a job looks like. Then the reason for scheduling jobs ahead is discussed. This leads to the presentation of flow charts that summarize all the information about precedence relations and scheduling per combination of action and main type. Finally it is explained how to deal with queues and priority setting in Picasso.
5.3.1 Processing a job in seven steps
In this section, a close look at jobs within AS processes using a capacity-restricted resource is taken. These jobs need to pass seven steps from creation to deletion, which is presented in Figure 5.4. In this diagram the three environments (control, platform and process) from Section 5.1 return, as well as the icons for the different components of the model. In the diagram, also the concept of job scheduling is introduced which is the topic of the next subsection. The seven steps are:
1. Scheduling The creation of the job is scheduled by control at some future point in time. It does not exist yet but it is on the event-list of the simulator.
THESIS PAUL ADRIAANSEN –APRIL 2009 42 2. Add to queue When the job is created, it arrives at the associated workstation (process). When a queue already exists, the job is added to the queue. When no queue exists, but no server (resource) is available either, a queue is created with this job as the only entity in it. In both cases the job has to wait for an available resource. When at least one server is available, the job is assigned to a server, and it enters the next step.
Control environment Platform environment Process environment
Step 1 Scheduling
Step 2 Add to queue
Queue? Y: Wait for server N: Server free? Y: Go tostep 3 N: Wait for server
Step 3 Start driving
Step 4 Arrival at aircraft
Aircraft present? N: Wait for aircraft Y: All preceding processes done? N: Wait for these processes Y: Go tostep 5
Step 5 Start processing
Scheduling succeeding processes
Step 6 End of processing / Wait for extra delay Does any after-process delay occur? Y: Wait for this extra delay N: Go to step 7
Step 7 Release resource
Figure 5.4: Processing a job in seven steps
3. Start driving When a server accepts a job in the (virtual) process environment, it sends a message to the connected resource on the (physical) platform environment (remember that every server is one-to-one connected with a resource entity). The resource (truck) jumps from the state “idle” to “moving” and starts driving to the gate of the associated aircraft. This driving time is stochastic and depends on the type of resource. For some processes this driving time already
THESIS PAUL ADRIAANSEN –APRIL 2009 43 contains a pre-processing part of the actual job, this is true for the processes asitocheck, kluhcheck and pushback (see Subsection 5.2.3).
4. Arrival at aircraft When the truck arrives at the aircraft, it can only start processing when the aircraft is susceptible: the aircraft needs to be present and precedence restrictions may not be violated. When any of the conditions does not hold, the resource switches to “waiting” and waits for a signal that it can start. When all conditions are met, the job enters the next step.
5. Start processing The job can now be started, which means it sends the resource a message to start processing. This means the state of the resource switches to “processing”. The processing time is stochastic and depends on the process and type and action of the aircraft. At the start of the job, control also checks whether succeeding jobs for the same aircraft need to be scheduled. The scheduling of a new job (step 1) always originates from the start of some preceding job (step 5).
6. End of processing / Wait for extra delay When the resource is finished with processing, it needs to meet an extra condition for some processes. The processes asitocheck and kluhcheck enter the “wait for cabin crew attendance” part, the process asitocleaning enters the “wait for board supply lateness” part and pushback enters the “wait for AAS delay” part. These post-processing parts give delays with some positive probability depending on some parameters, and have a stochastic duration. When a delay occurs, the resource switches to “waiting” for the length of the delay. After that, the job enters the next step. In any other case, the job proceeds to the next step immediately.
7. Release resource The resource is done with the aircraft: in the platform environment, the resource switches to “idle”. In the process environment, the job is released from the process (and leaves the system) and the server is available for a next job.
5.3.2 The need for scheduling
Since the availability of resources and the susceptibility of aircrafts are unpredictable even in the near future, it is impossible to plan the start of certain job ahead. Therefore it is also impossible to assign this job to a specific resource since it is not known in advance which resource will be available. On the other hand, it is requested to anticipate on the susceptibility of an aircraft for a certain job, since a resource needs time to drive to the aircraft. In other words: When we plan all jobs for a certain aircraft ahead and already assign them to specific resources, there is a high risk of disturbance of this schedule. Some resources will already arrive when the aircraft is not yet present or some preceding jobs still need to be finished. This is not efficient, since the next jobs of this resource need to wait, which probably causes delays. When we plan nothing ahead and wait for a resource to be available and the aircraft to be susceptible, delays will be created for certain as well. The time needed to drive to the aircraft is lost, which means that aircrafts with a short turnaround time will certainly be delayed.
Therefore a compromise should be found between: 1) having some schedule to allow resources to arrive at an aircraft in time, and 2) making this schedule as flexible as possible, to be able to anticipate on every possible disturbance and by that, minimize the waiting time of resources at an aircraft. Therefore the Picasso scheduling module in control is based on the following rules: 1. Schedule the creation of a job as late as possible to maximize the available information about disturbances. 2. When scheduling, take the available ground time of the aircraft into account. 3. Only assign a job to a resource when it is available.
To start with the last rule: this one is clear and simple. It is already taken care of by the queuing system that is used. A job is in a queue for a process and when a server comes available, the first job
THESIS PAUL ADRIAANSEN –APRIL 2009 44 in line is picked by the server and processed by the associated resource. The second rule is explained in detail in Section 5.4.
The first rule looks simple, but is in fact quite hard to solve since it is necessary to take all kinds of uncertainties into account. Let us first look at the deterministic version of this rule in a simplified example: one aircraft and four processes. The available information: The current timeis t= 0,the aircraft is present. Process A: driving duration: 1, process duration: 5, creation of job at t = 1. Process B: driving duration: 2, process duration: 1, creation of job at t = 4. Process C: driving duration: 1, process duration: 3, creation of job at t = 3. Process D: driving duration: 2, process duration: 1. Precedence conditions: Before process D can start, process B and C need to be finished, and before process B can start, process A needs to be finished. The question is to determine the latest possible time at which it is possible to schedule the job for process D.
Process A Driving time
Process B Processing time
Process C
Process D 2
0 2 4 6 8 t
We look for the process with the latest starting time before t = 6
Figure 5.5: Selecting the scheduling moment in a deterministic example
When process A ends (at t = 7), the resource for process B is already there (though this is not efficient). Process B will be done at t = 8 and process C ends at t = 7. Therefore process D can start at t = 8, and the resource for this job should start drive at t = 6. New jobs are only scheduled at step 5 of preceding jobs (the “start processing” step), so the job for process D is scheduled at the start of process C, since process B starts too late. This example is illustrated in Figure 5.5.
For this deterministic example it would have been possible to schedule the start of the job for process D at the start of process A. But when uncertainties are taken into account, we see that at the start of process C (somewhere around t = 4) it is likely to have information about the start of process A (somewhere around t = 2), while this is not true the other way around. This is why scheduling a job as late as possible is convenient.
However, taking uncertainties into account also blurs our view at the likeliest starting times of processes. Sometimes there exists a probability that the driving time of the job that is about to be scheduled exceeds the processing time of the job at which beginning it was scheduled. It is then possible that the aircraft is left idle or is even delayed. This could have been prevented by scheduling the job in question at the beginning of some earlier job. But then the information about the scheduling and driving time of that later job is lost, which can result in a long waiting time due to precedence conditions. In the end it is always a trade-off between efficient resource scheduling and preventing departure delays.
In general I chose the start of a direct preceding process as the best scheduling moment for a job (the “process C option” in the example). Only when the probability of a late arrival would exceed 10% (by rule of thump) I picked an earlier process (the “process A option” in the example).
THESIS PAUL ADRIAANSEN –APRIL 2009 45 Notice that the efficiency in using resources is only interesting for resources with limited capacity. For the non-AS processes, no scheduling is necessary and of the seven steps for AS jobs, only step 5 and 6 are relevant. Every non-AS process starts immediately when the conditions are met (since resources are always available it is possible to avoid driving times) and ends after some stochastic duration.
5.3.3 Flow charts
Now a description is presented of the list component that was introduced in the first section of this chapter. It is already explained that it is one-to-one connected to an aircraft and it contains information about precedence relations, scheduling moments and information on norms, duration distributions and probabilities. The precedence relations and scheduling moments are put together on a flow chart. This chart describes which processes follow each other and when new processes are scheduled.
Apart from some minor details, it is possible to assign every aircraft to one out of twelve different flow charts. A flow chart is constructed for each combination of action (TA, ARR, DEPH and DEPB) and main group of type (WiBo, NaBo and KLC). The flow chart for WiBo turnarounds is in Figure 5.6 and a description of the other eleven charts (in table format) can be found in appendix 5.C. All the elements of the flow chart are explained in Figure 5.7. The black DT and OT and blue QT, WTB and WTA boxes represent the different phases of a job, corresponding to the seven steps explained earlier. The black lines represent precedence relations, the red lines indicate scheduling moments.
The only elements that need some extra attention are the “event and probability” boxes. The difference between the two originates from the choices I made in modelling these occurrences. The situations board supply lateness and AAS take-off delay occur with some probability and when they occur they always lead to extra waiting time. The cabin crew attendance is modelled as an event scheduled at the beginning of the turnaround and always occurs. A second event of this type that wasn’t mentioned earlier is the event start bax loading. Although baggage loading is a non-AS process, the model is improved by taking into account that the earliest starting time of this process depends on the STD of the flight: passengers will not deliver their luggage earlier when the turnaround time is longer. These events are modelled to occur at “STD –x“, where x is stochastic and depends on the type of aircraft. The security check resource can only be released after the cabin crew attendance event, and bax can only start after the start bax loading event.
Step 1: scheduling
Step 2: add to queue QT Queueing Time Precedence relation: Step 3: start driving one process needs DT / Driving Time to be ended before DT * * includes process part the next one can Step 4: arrival at aircraft start WTB Waiting Time before Scheduling moment: processing at the beginning of Step 5: start processing one process, the OT Processing other is scheduled. Time Step 6: end of processing / wait for extra delay WTA Waiting Time after processing Step 7: release resource Event Occurs always and may lead to extra waiting time in a process
Probability Occurs with some probability and always leads to extra waiting time in a process
Figure 5.7: Legend and explanation of flow charts
THESIS PAUL ADRIAANSEN –APRIL 2009 46 Non-AS Processes Events and Toilet Water Cleaning & Check Fuel Pushback probabilities board supply
Flight QT QT
DT DT
WTB WTB
OT OT Tech Deboarding QT QT
DT DT
WTB WTB
OT OT Catering Board supply late WTA QT
Start bax DT* Bax load loading WTB
OT
Crew WTA attendence
Boarding
QT
DT*
WTB
OT AAS take- off delay WTA
Actual Block Departure
Figure 5.6: Flow chart of WiBo turnaround
5.3.4 Queues and priority
The process environment is modelled as a queuing network, which means that jobs (created according to the list of the aircraft) flow through the system and are queuing in line for workstations to wait for an available server. Although this model is convenient to use, it is somewhat too simple to approximate the real situation. In reality, the OCC (and HCC to a lesser extent) make decisions about giving specific aircrafts priority in handling for all kinds of reasons. They do this by intervening in the schedules of the different processes. In this way they can prevent delays, or reallocate delay minutes from one flight to another. These priority decisions can be based on: The size of the aircraft: ICA flights always come first, then the NaBo aircrafts and finally the commuter aircrafts The airline company: Air France and NorthWest are evenly important as KLM. Then the other partners follow, such as Kenya Airways. After that, the non-Skyteam clients have priority above the low-cost carriers such as Transavia (although this is a 100% KLM subsidiary).
THESIS PAUL ADRIAANSEN –APRIL 2009 47 The destination: flights to Paris Charles de Gaulle (CDG), KLM’s partner Hub, always come first since most passengers have to make transfers in CDG. Some evening flights to African destinations cannot depart late, since these airports are closed during the night.
The decision to give some aircraft priority can be taken in advance, and then it becomes a “star-flight” (e.g. all flights to CDG). When priority is given during the turnaround, this decision is often based on its arrival time. When an aircraft arrives late, the OCC tries to turn it around faster than planned, to minimize its departure delay. By doing this, other flights might be delayed instead, so therefore a complex trade-off needs to be made in every decision. These complex decisions cannot be modelled in Picasso, but I tried to include this priority setting in the simulation model as well as possible.
Since I only take KLM and KLC aircrafts into account, the airline company is not a relevant parameter. The size and destination are, though, as well as the time left to perform a turnaround. The properties of the aircraft are used to calculate a priority value for each job in a certain queue. This calculation is performed each time when a server (resource) of the associated process becomes available and after that, the server selects the job with the highest priority value. The priority calculator is an instrument of the control environment to influence the occurrence and length of delays. The queue itself is therefore not based on a FIFO regime, or any other time-order related system, so is in fact an unordered queue. The precise calculation steps of the priority calculator are explained in the next section.
5.4 Intelligence in Picasso
In the last sections the concepts of scheduling and priority setting are explained, but how these decisions were made and what calculations are needed to make these decisions in an intelligent way, was omitted. In this section the goal is to imitate the decision making process by the OCC and HCC, in order to model this realistically. First, I focus again on the topic of time windows and EBD calculation, which was introduced in Chapter 2. Then the scheduling decisions and priority setting are modelled step by step.
5.4.1 Time windows and EBD calculation
Scheduling a job is in fact deciding when the associated resource should start to drive to the aircraft. The best time of arriving at an aircraft is the exact instant the aircraft becomes susceptible for the process. I try to approximate this instant by taking the A+ and D–time windows into account (see Section 2.3 for background on this topic). Although all driving and processing durations are stochastic, it is possible to predict the aircraft availability instant by looking at the known distributions of these durations. By adding and comparing the durations of the preceding processes that are needed before the process can start, it is possible to calculate the availability instant at any point in time. Some intuitively good prediction methods would be: calculating the maximum likelihood of the availability instant (mode) calculating the expected value of the availability instant (mean) calculating the availability instant based on the medians of the distributions
In the Picasso model I chose for using the medians of the distributions for the following reasons: 1. Since Triangular distributions are used for a lot of durations (see Chapter 6), the maximum likelihood method gives unreliable results. 2. Most distributions have a right-skewed distribution, which means that the expected value assigns a heavier weight to the higher values. I found this less desirable since in general a Triangular distribution tends to slightly overestimate high values. So by choosing the median instead of the mean, this effect is compensated to some extent. 3. Using the medians has the additional advantage that the median can be compared to other percentiles of the distribution, which I will use in the scheduling module.
An important assumption that is made in these calculations is that processes that succeed each other do so without waiting time or delay due to a lack of resources. This also holds for driving times, which means that under the “median duration” assumption, every resource arrives exactly at the instant the aircraft becomes available for servicing. Of course this assumption is not only unrealistic but also
THESIS PAUL ADRIAANSEN –APRIL 2009 48 biased, since waiting times always have a positive duration. However, this effect turns out to be small since using the medians of distributions does not induce much waiting time.
Now that a method is obtained to predict the starting and ending times of each process in a turnaround we can attach time instants to all the events in the flow chart presented in Figure 5.6. These predictions can be made at any point in time, based on the information that is available up to that time. Predictions that are further away in time will be less reliable since they are the result of summing up more predicted median durations and events. An example of a simplified flow chart with predicted A+ and D–times is given in Figure 5.8.
Time scale (minutes)
Process: 0 5 10 15 20 25 30 35
Flight C Deboarding
Catering
Toilet A
B Cleaning G
Check
Fuel D Boarding E Pushback
Crew attendence Actual Prediction F STD t = tnow
Driving time Processing time Waiting time
Figure 5.8: Example of predicted A+ and D–times at t = 10
In Figure 5.8 several issues (indicated with a capital letter) need some explanation: A. The actual duration of the toilet job is 5 min., the prediction of following processes is performed at t = 10. After the time barrier of t = 10 all processes are predicted. B. Until the time barrier of t = 10, all A+ and D–times are actual, measured times. In this situation also waiting times can occur, as is the case for toilet and cleaning. After the t = 10 time barrier no waiting time occurs since driving instants are planned according the (known) predicted A+ and D–times. C. The predicted length (median) of deboarding is 4. Because the current job duration is already 5, the job is regarded as finished at t = tnow. This does not mean that the job is finished in reality, but for the prediction of the following processes the deboarding job behaves as being finished right away. The succeeding jobs (cleaning and catering) can start right away. D. The predicted driving duration for fuel is 4. The fuel resource is already on its way for 1 minute, so the remainder is 3 minutes. E. This is an example of a precedence relation: Pushback can only start after boarding and fuelling are finished. So the predicted start of pushback looks at the maximum of both times. F. The crew attendance event is scheduled back from the STD. It might have been a good idea to schedule it back from the EBD, but this would result in a circular calculation (since the EBD can only be known after scheduling the crew attendance event). Furthermore it is realistic that
THESIS PAUL ADRIAANSEN –APRIL 2009 49 the crew arrives based on the STD, rather than the EBD, unless the difference becomes really large, which is rare. G. The security check can only start after cleaning and catering are finished. But it also has to take its handshake with the cabin crew into account. Therefore it starts 2 minutes later, in order to end their job exactly when the crew arrives. In this case the “earliest starting time” (EST) of t = 21 is binding for the security check.
As suggested in point F. the Expected Block Departure (EBD) of an aircraft is itself predictable in this way, since it is the predicted start of the pushback process plus the median of the duration of the pushback (EBD: t = 33 in the example). For scheduling purposes it is impossible to use the EBD, since it is only known after all predictions. But the predicted EBD will be of use when priorities are set or the origin of delays is reconstructed as explained in Chapter 4.
5.4.2 Intelligent scheduling
The calculation of a “scheduling moment” as discussed in Subsection 5.3.2 is primarily based on the predicted A+ and D–times introduced in the last subsection. The scheduling moment needs to be set as late as possible in order to predict the aircraft availability reliably, but early enough for the resource to arrive in time at the aircraft (according to the medians of the distributions). In the example of Figure 5.8 the starting and ending times of all processes are predicted at the end of the toilet job. In Picasso, scheduling moments are calculated at the start of a certain process and this is done only once, according to the flow chart. When looking at the flow charts in Figure 5.6 and Appendix 5.C, one can see that every AS process is scheduled at the start of one of its directly preceding processes, so there are no processes in between (this “parallel property” turns out to be convenient).
By now it is explained how and why a job is scheduled as late as possible, but we did not yet take the available ground time into account, as desired earlier. This is done by calculating the predicted A+ and D–times in five scenarios, from optimistic to pessimistic. An optimistic scenario is chosen when we have to deal with a late or delayed aircraft. A pessimistic scenario is used when there is plenty of time to service the aircraft. The result is that when using an optimistic scenario, there is a bigger chance on making up the arrear. When one or more preceding jobs are done early, the next process can already start when the corresponding resource is present yet. This gives the possibility of gaining on the schedule of a delayed aircraft. On the other hand it will cost more resource capacity since the resource is more likely to stay idle for a while. In the pessimistic scenario the opposite is done. Since there is no need to rush the schedule, the resource is send to the aircraft late deliberately, in order to avoid idle time of the resource.
The following path is used when scheduling a process: 1. Calculate the AvailableGroundTimeFactor. 2. Choose one out of five scenarios (from very optimistic to very pessimistic) according to this AvailableGroundTimeFactor (AGT-factor). 3. Predict the ending times of all the preceding processes that are needed before our process can start, according to the chosen scenario. 4. Take the maximum of these predicted ending times and the “earliest starting time” if appropriate. 5. The resulting scheduling moment is the maximum of step 4. diminished with the median of the driving time of the corresponding resource. This needs to be some instance in the future, if not, schedule the job right away.
Every step is reviewed in detail: 1. The definition of the AGT-factor is the following: the available ground time for the process divided by the ground time needed for the process. In a formula it becomes:
STD "D-" time tnow AGT - factor Processing Time (median) Driving Time (median)
Of course the STD depends on the aircraft, and the processing and driving times depend on both the process and aircraft. The “D–“time is the duration of the longest path of succeeding processes (based on median durations) after the process that is about to be scheduled, and
THESIS PAUL ADRIAANSEN –APRIL 2009 50 depends on both the process and aircraft as well. The symbol “tnow”is used for the “current system time” during the simulation. Note that the ratio can have very small and even negative values when the aircraft is delayed.
2. According to the AGT-factor one of five scenarios in selected. A percentile is attached to each of five scenarios (see Table 5.9).
Scenario: AGT-factor values: Percentile: Very optimistic lower than 0.8 0.2 Optimistic between 0.8 and 1.05 0.35 Neutral between 1.05 and 1.35 0.5 Pessimistic between 1.35 and 2.0 0.65 Very pessimistic higher than 2.0 0.8 Table 5.9: Scheduling percentiles according to value of AGT-factor
This percentile is used in the next step to determine the durations of different paths of processes. We calculate these paths to be able to predict the ending times of processes, which is used to schedule efficiently. As explained earlier in this section, we take an optimistic or pessimistic view on this duration, based on which outcome we anticipate on. So, in a very optimistic scenario, we anticipate on a duration x that is the solution of the equation F( X < x ) = 0.2, with F(X) the cumulative probability distribution of the duration. In the very pessimistic scenario, we solve x from F( X < x ) = 0.8. This idea is further illustrated in Figure 5.10.
1.0 CDF
0.8
0.65
0.5
0.35
0.2
0 x
Duration x
Optimistic Pessimistic
Figure 5.10: Explanation of duration determination in different scenarios
3. Now the fact is used that all preceding processes are parallel (and not “in series”). Of each preceding process it is possible to calculate the scenario-percentile of the distribution and it is not necessary to take the percentiles of summed distributions (which could become an elaborate task). But some other problem is faced though. It is known that one of the preceding
THESIS PAUL ADRIAANSEN –APRIL 2009 51 processes is about to start, since it is the process that triggered the scheduling module. However, it is necessary to determine the status of the other preceding processes in order to predict their ending times. Some assumptions are made about every possible status: a. The process is already finished: this is no problem since the precedence relation is already met. b. The process has the status “processing”: add the median of the processing time distribution to the (known) starting time of the process. c. The process has the status “waiting for aircraft availability”: assume that the aircraft becomes susceptible for the process immediately and that the process starts. Add the calculated duration (based on the chosen percentile) of the processing time to tnow. d. The process has the status “driving”: add the calculated duration (based on the chosen percentile) of the processing time and the mean of the driving time distribution to the (known) time the resource started driving and assume no further waiting time. e. The process has the status “waiting in queue for resource”: assume the job is assigned immediately and faces no waiting time. Add the calculated duration (based on the chosen percentile) of the processing time and the mean of the driving time distribution to tnow. f. The process has the status “not yet scheduled” (this is very uncommon, but could happen theoretically): add the calculated duration (based on the chosen percentile) of the processing time and the mean of the driving time distribution to tnow. The exact calculation methods for deriving the percentile of some distribution are explained in Chapter 6.
4. Now we take a look at the EST of certain processes. An EST boundary exists for five out of the nine AS processes (see Table 5.11).
Process: Cause of EST: Calculation of EST: Asitocheck Crew attendance STD –Median crew attendance – Kluhcheck Crew attendance Median check duration Fuelhydrant Final fuel STD –Final fuel norm (40 min.) – Fuelnonhydrant Final fuel Median fuel duration Pushback No early runway use STD –65th percentile of distribution pushback duration Table: 5.11: Cause and calculation method of the EST value for relavant processes
Note that the distributions of the crew attendance and pushback, check and fuel durations depend on the type of the aircraft. The calculations are always based on the STD because of the risk of circular references and because the EST is unlikely to cause any delay when the when the aircraft is already delayed. To receive the requested result, the maximum is calculated of all the predicted ending times of the preceding processes and the EST together.
5. The driving time associated to our process still needs to be subtracted from the above result. Of course the resulting scheduling moment should be in the future, while otherwise the resource will probably arrive late at the aircraft, which could cause delays.
Altogether, the scheduling module uses two decision making rules in order to combine delay anticipating scheduling with efficient use of resources. The first rule, using A+ and D–times to create a floating schedule, can be compared to the functionality of CHIP in the daily operation. The second rule, anticipating on short or long processing times in order to reduce delays and dispatch efficiently, can be compared to the role of the dispatchers at the HCC. There is one important difference though: dispatchers are human beings that are intelligent, are able to improvise and even more important: they have a Porto phone to push the operators to hurry up. Picasso is just a computer model trying to simulate all these decisions.
THESIS PAUL ADRIAANSEN –APRIL 2009 52 5.4.3 Smart priority
Scheduling a job in time gives no guarantee that it is also performed in time, this depends largely on the availability of resources. As explained in Subsection 5.3.4, the priority calculator assigns priority values to all jobs in the unordered queue and then picks the most urgent job. The priority value is the sum of three separate values: 1. The star-flight number 2. The aircraft type number 3. The time priority value
The first two are straight forward. A star-flight receives some value x, all the other flights a 0. During the simulation runs, I always used the value x = 1. The aircraft type number is assigned according to the main type of aircrafts: KLC, NaBo and WiBo, in increasing order. In the description of simulation runs in Chapter 7,I assign values to these three types. The time priority value is what really makes the difference since it takes the available ground time into account. The time priority value is modelled in such a way that its range is limited from -1 to 1.
To construct the time priority value, first some medians and predictions are calculated: 1. The EBD of the aircraft is predicted. Here, the same technique is used as described in Subsection 5.4.1 and assume that the crew attendance and final fuel events are not binding (to avoid circular references). Medians are used for all durations and the durations in all the paths are summed, including the path containing the process we are setting priorities for. 2. The D–time for our process is calculated (based on the median durations of the longest path of succeeding processes), the median processing time and the median driving time. These all depend on the type of the aircraft of course. 3. Now the following definitions are stated:
Time Available = EBD –tnow Latest Starting Time (LST) = EBD –“D-“time –median processing time –median driving time Time to LST = Time Available + LST –EBD = LST –tnow
Now the resulting time priority value is defined by:
-1 * Time to LST for Time to LST 0 Time to LST median Driving & Processing Time priority value Time to LST for Time to LST 0 Time to LST median Driving & Processing
To illustrate how this priority value evolves over time, Figure 5.12 presents an example of three aircrafts that are waiting for fuelhydrant. The corresponding data describing the properties of these three aircrafts is in Table 5.13. In the column “basic priority level” the star-flight number and the aircraft type number are summed up. Note that the Time priority value equals zero in { Time to LST = 0 } and in this point the Priority value is equal to the “basic priority level”.
THESIS PAUL ADRIAANSEN –APRIL 2009 53 3
2.5
2 e u l a V
1.5 y t i r o i r P 1 NaBo, EBD: 8:30 WiBo, EBD: 9:50 0.5 NaBo (to CDG), EBD: 11:10
0 6:00 6:30 7:00 7:30 8:00 8:30 9:00 9:30 10:00 10:30 11:00 11:30 Time Figure 5.12: Priority values for fuelhydrant of three different aircrafts as a function of time
Aircraft type Star-flight Basic priority EBD D–time Median Median priority level (min.) Driving (min.) Processing (min.)
NaBo 0 1.2 8:30 15 5 45 WiBo 0 1.6 9:50 30 5 60 NaBo 1 (to CDG) 2.2 11:10 15 5 45 Table 5.13: Data of three aircrafts in example Priority value
In the example the priority values of three aircrafts are given on the time span of 5.5 hours. In practice this would not be a relevant discussion since NaBo turnarounds tend to take no longer than an hour. This means that the priority value of such a job is already high when it is scheduled.
Another important issue that is not represented in the example is the fact that the EBD can be changed over time. Therefore, take a look at the second example in Figure 5.14, in which the first NaBo aircraft of the first example (with EBD 8:30) is compared to an identical aircraft with EBD 8:40. Both are waiting for fuelhydrant, and since the first aircraft has a nearer EBD it has a slightly higher priority value. Now consider the following case: Between 7:00 and 8:30 there is only one kluhcleaning team available, which should service both our aircrafts. Normally, the kluhcleaning team would pick the first aircraft first, since it has higher priority (because of its nearer EBD). However, because the second aircraft arrives 15 minutes early, kluhcleaning starts with servicing the second aircraft first. At 7:40, the LST (Latest Starting Time) of the kluhcleaning job for the first aircraft expires but the kluhcleaning team is still busy at the second aircraft. Between 7:40 and 8:10 the EBD of the first aircraft is pushed forward since the aircraft needs to wait for kluhcleaning. At 8:10 the EBD is no longer shifted since the kluhcleaning job has started.
THESIS PAUL ADRIAANSEN –APRIL 2009 54 2
1.8
1.6
1.4
e 1.2 u l a V
1 y t i r o
i 0.8 r P
0.6 NaBo, EBD: shifting from 8:30 to 9:00 0.4 NaBo, EBD: 8:40 0.2
0 6:00 6:30 7:00 7:30 8:00 8:30 9:00 Time Figure 5.14: Second example of Priority values: shifting the EBD
The effect of this EBD shift is clearly visible in Figure 5.14: the second aircraft has a higher priority for the fuelhydrant job from 7:50 on. The logic behind this is very convenient since it ranks aircrafts flexibly according to expected departure time. After the first aircraft is delayed due to late kluhcleaning, it also loses its priority for fuelhydrant since it makes no sense to fuel the first aircraft first when it cannot depart after all due to some other process. This property of the priority calculator links priority choices between processes (or departments, in reality), which makes it a valuable and consistent tool, comparable to the instruments the OCC uses to set priorities between aircrafts (although on a different level). The “departmental consistency property” in priority setting is a policy that is not yet formalised within the HCC, but it is to a large extent present in the intuitive decision making by dispatchers and the DHM.
THESIS PAUL ADRIAANSEN –APRIL 2009 55 CHAPTER VI
QUANTITATIVE MODEL
In this chapter all the technical specifications of the simulation model are explained. The first section deals with the programming environment of Picasso, including a discussion on random numbers. The second section describes the time gap that made it possible for Picasso to anticipate on information from OPiuM. The third section describes the full program, by giving descriptions of all 47 classes in Picasso. The fourth and fifth section deal with input data: capacities and distributions. The last section describes the process of verification.
6.1 Programming Picasso
This section introduces the technical environment in which Picasso was created. Some technical specifications of Java and DSOL can be found in Appendix 6.A. The most important specifications of OPiuM are highlighted in this section and the issues of replication parameters and random numbers are discussed.
6.1.1 OPiuM for Picasso
The KLM/QO department developed a special version of OPiuM specifically for the Picasso project: “OPiuMfor Picasso”. The adjustments that were made are: It became possible to add new aircraft types to the timetable. Initially the KLC types (100, F70 and F50) were not recognized by OPiuM, but these types are essential for the workload of AS. The principle of the merged BB2/4 was introduced (a turnaround). This was not earlier used in OPiuM, since OPiuM simulates the BB2 and BB4 separately. The rule whether to merge BB2 and BB4 is that the difference STD –ATA (the available ground time) is less than 270 minutes. The parameters of the towing actions (end of BB2 and start of BB4) were chosen in such a way that the resulting regime exactly copies the towing behavior of PlanControl which is used to develop the workload schedules during the OPC. Opium for Picasso has some specific communication objects for sending messages to Picasso. This aircraft arrival information was earlier described in Section 5.1.1.
THESIS PAUL ADRIAANSEN –JANUARY 2009 6.1.2 Run Length and replications
In a normal run of OPiuM, one chooses both the run length and the number of replications. The run length is measured in weeks (the timetable is similar for every week) and always needs one warm-up week in which no data is collected. With every new replication, the seed number of the Random Number Generator stream is different in order to create an independent run. Since there exists no synchronization or information sharing between succeeding runs, creating one long replication with an equal total number of weeks would to a large extent produce the same output.
Picasso works with its own streams for random numbers, so the best situation would be to perform multiple replications (5 to 10) of multiple weeks (5 to 10) and regard these results as “Independent and Identically Distributed”. The problem however, is that due to programming limitations in OPiuM for Picasso, it was impossible to simulate multiple replications. Picasso would overwrite the output files of the first replication when storing the output of the second replication. This would not have been a problem if it was not the case that, due to memory restrictions of the computers I used, also simulating more than 12 to 13 weeks was impossible. I therefore chose to simulate a maximum of 11 weeks (1 warm-up week and 10 data points). The computation time of a single replication with 11 weeks is about 50 to 60 minutes on a PC with 512MB memory.
A solution to these problems would have been to manually adjust the chosen streams in OPiuM and Picasso. This should be possible for me in Picasso, since I developed it myself. The randomization object in OPiuM, however, was programmed as a black box, inaccessible for unauthorized programmers (this is one of the “benefits” of hierarchy in Java). As a result, I was only able to produce 5 to 10 fully IID weeks in the simulation model. This has some serious implications on the choice of statistical techniques in Chapter 7.
6.1.3 Random Numbers
According to Law and Kelton (2000), two important issues need to be addressed when it comes to random numbers: first the choice of the Random Number Generator (RNG) and second, the choice whether or not to use Common Random Numbers (CRN).
The choice of the RNG is prescribed by using DSOL, since DSOL uses the standard RNG of Java which is called Java2Random. This is a Linear Congruential Generator with the recursive definition:
X n1 aX n cmodm where a, c and m are chosen according to the Hull and Dobell Theorem for full period (Law and Kelton, 2000). The size of m and thus the according period of the LCG is about 1014. Java has also the much more advanced RNG’s “DX120”and the “Mersenne Twister”available with respective periods of about 101120 and 106000 but using these has a high cost in computation time. Picasso has about thirty sources of randomness and uses in total about 700,000 random numbers for 11 weeks of simulation (per replication).
The choice not to use CRN in Picasso depended on the following consideration: OPiuM for Picasso is, as a stand-alone program, fully “CRN proof”since it uses different streams for different variables and no alternative system configurations are used. However, with thirty sources of randomness in Picasso, exact synchronization of all streams becomes extremely hard. For each source it should be investigated what the influence is of a certain alternative system configuration on the order and quantity of random numbers. Finally, because of the impossibility of performing multiple replications with OPiuM, desynchronizing the random numbers in Picasso is the only way to get more than 10 data points. However, these series of data points are not independent, since they are all based on a single OPiuM replication.
Another programming imperfection in Picasso should be explained as well. Since I was not able to adjust the streams in Picasso manually, I decided to waste one hundred numbers each time when performing a new replication in order to create different results. At first sight this works very well, but the main disadvantage is that 99.98% of the stream is reused for every succeeding replication. In
THESIS PAUL ADRIAANSEN –APRIL 2009 57 simulation theory this makes it impossible to perform solid statistical analysis since too much unpredictable correlation exists between the series of data points. In Chapter 7 I explain why this decision turns out to give a technical problem in the independence between different runs. Here I already defend my choice for using this data for statistical analysis: Wasting one hundred numbers assures that the first one hundred draws result in different outcomes. In any case, at least twenty out of the thirty sources of randomness have different starting values. Now it is useful that all these thirty sources of randomness use the same stream, since the first one hundred draws shuffle the order in which the following sources of randomness are assigned their values. The probability that one of the sources is assigned a value that shifted exactly 100 positions is very small and this event is in itself not even harmful. The probability that all thirty sources are assigned values that all shifted exactly 100 positions in the same order and at the same time is negligible. When this extremely rare event would accidentally happen, this can be seen from the simulation output right away. Since all sources use the same stream, the output would be fully identical from some point in time.
6.2 The Picasso time-gap
All the issues about the scheduling of jobs and events in the future were already discussed in Chapter 5. Chapter 3 already introduced the discrete nature of Picasso. Apart from that, Picasso is terminating simulation model with a fixed run length, since the system that is simulated has a clear start and end. The only thing that needs to be discussed concerning the evolvement of time in Picasso is the artificially created 45 minutes time-gap between OPiuM and Picasso.
All the objects and entities in Picasso live in a world that shows a 45 minutes delay to the world of OPiuM. OPiuM simulates the arrival of aircrafts but when the “BB2 start” message (ARR action in Picasso) is send from OPiuM to Picasso, the associated aircraft is still in the air for another 45 minutes according to the time in Picasso. The reason for this is that Picasso needs time to anticipate on the arrival of an aircraft. The toilet and water resources, for instance, start driving before the actual arrival of the aircraft, in order to be present at the gate on the block arrival of the aircraft. This would not be possible when OPiuM and Picasso work in the same time-zone. So the arguments for scheduling jobs ahead in Section 5.3.2 also apply to the time-gap invention.
Another reason for using the time-gap is that OPiuM does not simulate disturbances in the start of a BB4. As long as the associated aircraft is available, OPiuM considers the AOP (Aircraft on Position, the start of a BB4) as a deterministic event. Picasso now uses the time-gap to put uncertainty on the AOP instant, by deviating from the norm duration of 45 minutes.
The same technique is also used to simulate the arrival of KLC aircrafts. Since KLC aircrafts were initially not programmed in OPiuM, there is no building block data available about KLC flights. Therefore OPiuM regards the KLC part of the timetable as deterministic. Picasso now uses the time- gap to put uncertainty upon the arrival instant of the KLC aircrafts, comparable to the AOP simulation but now for the start of a BB2.
In Section 5.2.2 the artificial job flight and semi-artificial job towing were introduced. The reason for this will now be clear: allowing Picasso to anticipate on events and also making the arrival instants of aircrafts more realistic. Of course the event times Picasso registers need to be corrected with 45 minutes in order to compare them to the timetable for instance. This is done by the output generator, at the end of the replication. The choice for a gap of 45 minutes was quite arbitrarily based on the principle of EBA-R. The EBA-R is a special version of the Estimated Block Arrival, given by the cockpit crew exactly 45 minutes before the very value of that EBA-R. Strange enough, the EBA-R turns out to be the most accurate EBA of all, including later released EBA times, based on more actual information (Schiebaan, 2002).
THESIS PAUL ADRIAANSEN –APRIL 2009 58 6.3 Structure of the program
The source of the Picasso code contains 47 classes that are grouped in seven categories (packages). For each category, a subsection describes the most important elements. The .java files contain approximately 11.000 lines of syntax, the full Picasso program (including input data and .jar files) takes about 54 MB. A description of these classes and hierarchical structure can be found in Appendix 6.B.
6.4 Input data for capacities
In this section the actions are described that were needed to get usable input for the capacity levels of the AS processes during the simulation. The whole process from the OPC trajectory to Picasso input is described.
6.4.1 Raw numbers from the OPC
KLM/ST used PlanControl to produce workload schedules based on the timetable (check week of S07) that was chosen for the Picasso simulation study. The methods and parameters he used were exactly equal to the standard OPC procedure; the timetable itself differed of course since Picasso only takes KLM and KLC aircrafts into account. KLM/ST delivered both the pure workload as well as the most efficient work-shift schedule that was fitted on the workload. A “work-shift schedule” is defined as the accumulation of all shifts of all operators that are needed to cover the workload of some day. To simplify the analysis, some restrictive assumptions were made: The workload was taken equal per half hour to the maximum workload in that half hour, to avoid fluctuations each minute. A small buffer for driving time is included in the workload schedule. No buffers are included for compensating uncertainties. Only 8 hour shifts were used for the work-shift schedule and these shifts could start each hour. The half hour lunch break was left out of this analysis.
An example of such a workload schedule covered by work-shifts can be found in Figure 6.1. This figure is in fact a simplification of the real workload schedule, of which an example was presented in Figure 2.7. This figure is based on the OPC results from the Monday of the check week for the fuelnonhydrant resource. As you can see in this figure, the work-shift schedule can have high peaks during low workload periods (e.g. from 12:00 to 16:00). These peaks result from overlap in different shifts that are needed to cover peaks earlier or later on the day. Since labor is more costly in the early morning or evening, these peaks tend to arise around the early afternoon.
THESIS PAUL ADRIAANSEN –APRIL 2009 59 Workload schedule covered by workshift schedule 16
14 Workshift schedule Workload schedule s
e 12 c r
u 10 o s e r
f 8 o
r
e 6 b m
u 4 n
2
0 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 time (hours) Figure 6.1: Workload and work-shift schedule for fuelnonhydrant on Monday in check week
When evaluating the OPC results, the work-shift schedules rather than the workload schedules should be the actual input for the Picasso punctuality analysis. Some first simulation runs were based on the work-shift schedules, which is the most realistic possibility. However, the large difference between these two made me decide to overthrow this idea. One could easily see that it would make no sense to measure aircraft delays due to a lack of fuelnonhydrant resources around 14:00, since the capacity is more than twice what is needed. Therefore I decided to work with the workload schedule instead, but only after adding some scaled margin upon the original workload to avoid too much trouble from low capacity levels. There is one main disadvantage of this choice: the analysis looses a bit of its connection to reality. Since in reality work-shift schedules are used in the OPC, the resulting punctuality will be higher in the afternoon, because of the peaks in work-shifts. The following arguments however, justify the choice made: 1. The workload that was calculated by SPL/ST, was based on the normal PlanControl procedure, and is therefore a realistic estimation. The shift schedule is far less realistic since only 8 hour shifts were used and lunch breaks and all other kinds of specific features were left out of the analysis. The shift schedule is therefore not that realistic at all. 2. The main reason however, is that Picasso looks for correlation between properties of the timetable and the resulting punctuality. Using the work-shift schedule troubles the view on these correlations. By measuring the punctuality as a direct consequence of some workload schedule (including some correction margin), one is able to evaluate a timetable much more directly.
The reason for using a correction margin is that Picasso is much more inefficient with assigning resources to jobs due to all kinds of uncertainties. These uncertainties play no role in PlanControl, but waiting time, long job durations and resource idle time do have a large effect within Picasso and should therefore be corrected for. Figure 6.2 shows how the workload from Figure 6.1 leads to the corrected workload that will be used in Picasso. The calculations behind this correction are explained in the next section.
THESIS PAUL ADRIAANSEN –APRIL 2009 60 Original and corrected workload schedules Corrected workload for Picasso 14 Original workload
12 s
e 10 c r u o
s 8 e r
f o
r 6 e b m
u 4 n 2
0 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 time (hours) Figure 6.2: The corrected workload schedule for fuelnonhydrant is used for Picasso
6.4.2 Corrections in the workload schedules
Two major corrections had to be made to the raw data from the OPC: first, the uncertainty buffer upon the original workload as announced in the last section. Second, the workload schedules of some of the resources are indicated as the sum of operators in a team, where sometimes different team sizes are used simultaneously. But before that, two minor corrections are explained: The Monday morning data is incorrect since shifts that are started Sunday in the evening were not taken into account. This was corrected manually in the data sets. I decided to have at least one unit of every resource available through the whole night, even if there is no workload for hours. This is to avoid extreme delays caused by aircrafts waiting for handling a whole night, while they should have left the evening before.
Now the team size corrections are performed first. In Picasso each resource that executes a job is seen as a single entity. However, for the cleaning and security capacity, PlanControl sums the individual operators within the teams that are needed. This would not be a problem when these teams have equal size for each aircraft type, for example, in the case of asitocleaning teams always consist of 9 operators. This is also true for kluhcheck which is always performed by 2 operators. But for the asitocheck and kluhcleaning processes, these teams have different sizes for different aircraft types. In Table 6.3 the team sizes can be found for these processes per aircraft type. This table also shows how the weighted average team size was found. This weighted average was used to divide the original workload, in order to get the number of teams that is most likely to be needed at a certain point in time. Note that when, according to the timetable, four F70’s need cleaning, kluhcleaning only has (4 * 3) / 3.85 = 3.12 3 resources available for this.
THESIS PAUL ADRIAANSEN –APRIL 2009 61 Asitocheck Type 744 Other types Result # of operators 4 2 # of flights per week 38 425 Average job duration 22.03 20.11 Share in total 8.92% 91.08% Weighted average 2.18
Kluhcleaning Type 739 Type F50 & F70 Other types Result # of operators 5 3 4 # of flights per week 107 839 1369 Average job duration 28.98 12.10 24.35 Share in total 6.7% 21.8% 71.6% Weighted average 3.85
Table 6.3: Calculation of average team size for Asitocheck and Kluhcleaning
The uncertainty buffer that is put upon the original workload is a linear function of this workload. Since just adding a fixed number of resources to the original level seems inappropriate, I decided to use only a factor to multiply the original level with. Choosing this factor is in itself part of creating the model, since it has enormous effects on the results. Since I had no reference for choosing the factors, I manually adjusted the levels to create credible results. An important assumption in this process was that the factor should be equal for all processes. After multiple trial and error iterations I needed to loosen this assumption for the asitocheck and kluhcheck processes. To estimate the difference in mark-up factor between the check processes and other processes, I used the productivity ratio in the original workload. The general productivity (workload divided by shift hours) for AS processes is 55.9%, while the productivity for the security check processes is only 34.2%. The capacity mark-up is defined by ( 1 / productivity ) –1, so the ratio between the AS processes and security check processes for the mark-up value is:
1 34.2% 1 2.44 1 55.9% 1
A general mark-up value that turned out to give good and credible results was 40% for all processes except for the check processes. The check processes were assigned a mark-up value of 40% * 2.44 = 97.6%. So, the original workload numbers were increased with 40% for all AS processes, excluding asitocheck and kluhcheck for which the workload numbers were doubled. In Figure 6.2 one can see what the 40% effect looks like for fuelnonhydrant. In appendix 6.C, the corrected workload schedules are presented for all processes and all weeks.
6.5 Input data for probability distributions
In this section the construction of input probability distributions is discussed. The problems with data collection were one of the reasons for using triangular distributions for all durations in the Picasso model. Fitting these triangular distributions was done by using a simple Ordinary Least Squares approach. The durations of fuelhydrant and fuelnonhydrant were modeled a bit more sophisticated, which is also explained in this section.
6.5.1 Data collection
It is important to clarify the process of data collection, since different levels of precision were reached for different variables. Some general problems that hampered the process of data collection are: Some data was hard or impossible to collect. Especially data on the durations of processes outside the AS responsibility. This was for example the case with data on deboarding. Some data problems originated from modeling assumptions. In Picasso several processes were generalized or accumulated into a single “process” that was easy to use from a modeling
THESIS PAUL ADRIAANSEN –APRIL 2009 62 perspective, but could not be compared to any real process of which data is available. This was for example true for the tech process that was created in Picasso to lump all kinds of different E&M processes into a single process. A problem that was especially applicable to data of AS processes (mainly from ReportControl) is that sometimes too much data was available. This yields two issues: first of all, all kinds of different definitions are used to describe special cases (for example different kinds of setup times for fuel processes), which can only be decoded by someone that knows all the different cases and definitions. Secondly, collecting data from ReportControl requires advanced knowledge of this database system (for programming queries), which I did not have. But in the end, this is only a minor problem compared to having no data at all.
In general, the probability distributions for durations of AS processes in Picasso were based on data from ReportControl. Probability distributions for durations of other processes were mainly based on norms, expert judgments and statistics from earlier research (Van den Boom, 2003). Apart from the process durations, the distributions of driving durations were all found using data from ReportControl. In the cases of kluhcheck, asitocheck and pushback this meant that some aggregate distribution for the driving duration was constructed, since these driving durations contain parts of the actual process (see Section 5.2.3). Finally, probabilities for the events 737-fuelhydrant, WiBo-prefuel, AAS delay and late Board Supply delivery and the distributions for durations of Crew Attendance and AAS delay were based on both ReportControl and expert judgments on norms.
6.5.2 Triangular distributions
Law and Kelton (2000) describe the Triangular distribution, noted TRIA(a, m, b), as a last resort when no other distribution is applicable or no data is available. For several reasons, the Triangular distribution was used for all duration distributions in this thesis, also in cases where fitting for instance a Gamma distribution would have been possible: 1. For cases where no data is available, the Triangular distribution is generally accepted as a good way of constructing a distribution based on expert judgments. 2. In the cases where data was available (mainly the AS processes) the Triangular distribution turned out to fit quite well, in almost every case. 3. One of the advantages of using a Triangular distribution is the possibility of setting a minimum and maximum duration. These boundaries are set manually and can be based on all kinds of assumptions and arguments. One of the arguments to use a limited duration (by setting a maximum) is that a Gamma distributed variable can result in very long durations that could lead to an extremely high PDM-value (PassengerDelayMinutes) for a single flight. This single flight could then influence the total PDM to an extent that is unrealistic and undesirable. 4. This argument on high PDM’s is not only valid from a modeling point of view, but also from a reality perspective. Extremely high durations (say, two to three times the norm or more) will never occur, since the OCC will take measures in such a case. The length of any process can be controlled (in contrast with weather conditions for example) to some extent and in the case of some fatal break-down, the aircraft will be replaced. 5. A final argument has to do with the project focus stated in Chapter 3. Finding well fitted duration distributions has no priority in this thesis, since other, more drastic assumptions have already violated the realism of the study. Furthermore it is less time consuming to choose a single type of distribution and apply it to all the durations.
6.5.3 Fitting triangular distributions
As explained above, I decided to set the minimum and maximum values of the triangular distributions myself. In general, the minimum was based on two-third of the handling norm for a certain duration. A handling norm contains no mark-ups for driving, (un)loading, or other tasks that cannot directly be assigned to a certain aircraft, but it does contain a small buffer to take uncertainty into account. Only when data from ReportControl gave reason to adjust this two-third rule, I changed the minimum upward or downward.
The maximum was chosen somewhere between two or three times the norm (depending on the flexibility of the process). Again, in some cases data from ReportControl gave reason to adjust this
THESIS PAUL ADRIAANSEN –APRIL 2009 63 maximum. In several cases a downward adjustment was made (down to 1.5 times the norm) for processes that had a very stable duration (for example toilet and pushback, where the pushback duration only concerns the driving part of the operation).
Since the minimum and maximum are now set, the only parameter that needs to be estimated is the mode of the triangular distribution. In Kotz and Van Dorp (2004) all kinds of methods are provided for finding the Maximum Likelihood Estimator for the Triangular distribution. They also show that when the minimum and maximum are known, the mode can be found by using Ordinary Least Squares on the available data. So after discarding all the data that was not in the domain (minimum, maximum) the mode was approximated (numerically) with OLS by using a simple Excel sheet. The resulting durations are in Appendix 6.D.
For the non-AS processes where no data was available, the mode was taken equal to the AIS norm. In some cases, these distributions were manipulated because of modeling assumptions. For the catering process for example, the maximum duration was increased to a level that is higher than the sum of norm durations of processes on parallel paths (for example asitocleaning plus asitocheck). Otherwise this process would never lead to any delay. The modes and maximums of the triangular distributions for the processes catering, bax, boarding, deboarding and tech were based on the desired probability that this process would exceed the duration of parallel paths. This is not the most realistic solution for these distributions but its importance is not that high either, since I focused on AS.
6.5.4 Fuel distributions
A special case in the construction of input distributions is formed by the probability distributions for the durations of fuelhydrant and fuelnonhydrant. I paid more attention to finding well fitting distributions for the fuel processes because of three reasons: 1. A lot of quite reliable data about the fuelling process was available in ReportControl, and the data showed a tail on the right that could not be neglected and did not fit into a simple triangular distribution. 2. The duration of fuelling can have a significant influence on the departure delay of an aircraft. Especially since it is an inflexible process that cannot be sped up. 3. The duration of fuelling depends on the destination of the aircraft, so I had to investigate these durations much better anyway, since no standard norms are available.
I did use Triangular distributions, however, to find a well fitting distribution. The solution was based on the following assumptions: The minimum and maximum (of the tail in this case) can be determined manually. The resulting distribution is formed by adding up two downscaled Triangular distributions that have a joint area of 1.
The first Triangular distribution, TRIA(a1 , m1, b1 ) , contains the “body” of the distributionand is
symmetrical, a1 is equal to the minimum.
The second Triangular distribution, TRIA(a2 , m2 ,b2 ) , contains the “tail”of the distribution and
is defined by a2 m1 , m2 b1 and b2 is equal to the maximum.
Now m1 is the only unknown parameter and of course the weight of both distributions still needs to be chosen. Again OLS was used, varying m1 manually and finding the OLS value by using the goal-seek function in Excel. It was not hard to find the optimal m1 at which the OLS value is minimal, and by that the full distribution was determined. This technique was used for all fuelhydrant and fuelnonhydrant durations. An example of this can be found in Figure 6.4. In Picasso the duration of a fuel job was simulated by first flipping a biased coin on the probability of ending up in the “tail” distribution (mostly between 10% and 15%). Then the actual duration was drawn from the “body” or“tail” distribution.
THESIS PAUL ADRIAANSEN –APRIL 2009 64 histogram of data total area + equals 1
body
tail
min m1 = a2 b1 = m2 max
Figure 6.4: Example of fitting two triangular distributions on fuel duration data
A second specialty with the fuel distribution was already introduced: it depends on the destination of the aircraft. When an aircraft has a far destination, it needs more fuel and the fuel job takes longer. After investigating this, only fuelhydrant clearly showed this relation for WiBo aircrafts flying to ICA destinations. Fuelnonhydrant is only used for NaBo and KLC aircrafts with EUR destinations. The duration of a fuelnonhydrant job is far less depending on the number of kilos kerosene that is needed, since (de)coupling and administration takes relatively more time.
For each aircraft type, the ICA destinations were split in two groups: short and long flights. For the 744, 74E, 772 and M11 types this threshold was set at 6000 KM, for the Airbus 332, it was set at 4800 KM. The available data was split and distributions were fitted for both groups separately. Since OPiuM included the destination of a flight in the aircraft information, Picasso can easily select the right distribution to draw from.
6.6 Verification of the model
As in any simulation study, the process of verifying the program is an essential step. Since Picasso is quite a large computer program the verification process was an enormous job. All the applications build in Picasso could be summarized in six phases, which are discussed in the first subsection. The second subsection deals with the most used verification technique: tracing entities.
Verifying the program consisted of two tasks: getting the program to run without errors (debugging), and checking whether the program does the right things (the actual verification). In total, writing the program cost about ten to twenty percent of all programming time (approximately four months). Both debugging and verification took about thirty to forty percent and the rest of the time was spent on preparing the input data.
6.6.1 Six phases in building Picasso
Picasso was built in six steps, which can be seen as separate projects. These steps were: Phase 1: Programming aircraft, process, flow and queue objects to behave and interact correctly. Phase 2: Adding driving delays, extra waiting events, extra after-process delays and uncertain resource events (like prefuels) to the flow paths of phase 1. Phase 3: Implementing stochastic behavior in the durations and probabilities of all objects. This includes programming Picasso to read .txt input files. Phase 4: Constructing the link with OPiuM for Picasso; from now on all aircrafts are created in OPiuM and have stochastic arrival times. Phase 5: Implementing variable capacities for AS processes and creating .txt output modules. Phase 6: Adding intelligence to the scheduling module and priority setting (constructing the EBD calculators etc.).
THESIS PAUL ADRIAANSEN –APRIL 2009 65 At the end of any of these six phases, all the functions, paths and object interactions were fully verified with the help of a Java expert (Charlotte Elpers from Decision Support). No new applications were added before Picasso was fully checked on the correctness of earlier features. In only two situations an error slipped through this “end-of-phase” verification: In phase 5 a capacity leak for pushback was discovered, that actually should have been found in verifying the first phase. In phase 6 an error was discovered in the information (destination of the aircraft) that OPiuM sent to Picasso (this was not found in the verification of phase 4).
Only from phase 4 on, aircrafts are created by OPiuM. In phase 1 to 3 Picasso used aircrafts that were created in the experiment file. All properties of these aircrafts could be set manually in order to test all possible paths of the system.
6.6.2 Tracing objects
One of the important advantages of using an object oriented programming language is the possibility of tracing objects through the simulation system. All objects have a name and a memory location, which makes them identifiable over time. By using the print-to-screen(
An example of an error that was solved by tracing aircrafts concerns the “clone statement”in the control object. This function was cloning aircrafts in order to give other functions outside control the possibility of checking some specific arguments of the aircraft, without giving these functions the power to change them. The idea was that this clone would be discarded after the pushback process, when the original aircraft was stored in the output module. What actually happened was that the clone itself took over the place of the original aircraft. This was not detected since the clone is identical to the original aircraft and did not lead to strange results. The original aircraft however, was not discarded at all and stayed alive in the system as a ghost aircraft, occupying resources. This was only found after tracing the memory locations of the original aircrafts that switched with the cloned ones.
THESIS PAUL ADRIAANSEN –APRIL 2009 66 CHAPTER VII
RUNS AND RESULTS
In this chapter all the runs are described that are executed with the Picasso simulation model. The first sections gives some information on the input and output of the model, as well as some statistical background. The second section describes the runs itself. In the last two sections the results are interpreted and some conclusions are drawn from the observations.
7.1 Input and output of the simulation model
In this section the preparation for running the simulation is discussed. The first section deals with the input parameters: what can be changed and what not? Picasso gives .txt files as output that can be loaded in the punctuality analyzer. The run reports that this analyzer gives are the topic of the second section. The next two sections introduce some statistical procedures that are needed during the analyses in Section 7.2.
7.1.1 Input parameters
To streamline the process of run execution a “run administration” was developed. Running the model was only started after all debugging and verification was done. At some point the model is just finished, which means that no further improvements, repairs or changes are needed. It is necessary to finalize the model before you can start executing runs, since now every change to the system is taken into account when comparing the output of consecutive runs. Changing the input parameters is of course interesting in order to compare alternative system configurations. However, any improvement to the model is now an experiment in itself. This means that some basic situation should be chosen that can be used as a starting point for comparing alternative system configurations.
The run administration is used to keep track of all the settings and changes relative to the basic run. Every experiment is assigned a number and a “Control panel”. Every setting that is not explicitly described in the Control panel is assumed to be equal to the basic run. An example of the Control panel for the first basic run can be found in Figure 7.1.
THESIS PAUL ADRIAANSEN –JANUARY 2009 Control Panel Run no: 18 Run name: Basic 1
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 1 WIBO 1.6
Other manually changed settings or comments: none
Figure 7.1: Control Panel for the first basic run (“run 18”)
The capacity settings in the basic run conform to the discussion in Section 6.4.2. The number “A” represents an absolute mark-up to the capacity level, while the number “B” gives the factor with which the original workload is multiplied. The number of weeks is always five or ten plus the warm-up week. The “R.N. spill” indicates the number of random numbers spilled before the simulation starts using the default stream of random numbers. The control panel of all runs that were used in this thesis can be found in Appendix 7.A.
7.1.2 Output report
The output of a run consists of several .txt files that are edited in an Excel based program. This Excel based program can be seen as a “punctuality analyzer”: a tool that calculates punctuality measures from the raw data in the .txt files for each consecutive run. This tool uses all the rules and ideas that were introduced in Chapter 4 and provides a run report for every week, separate for TA and DEP departures. The run reports of maximum five weeks can be stored in one file, because of memory restrictions in Excel. These five weeks (ten reports) are then summarized in an output report, containing all interesting values of the run reports. The output that is provided covers for every week: The total PDM including and excluding the Network/Flight delays (delays that were caused by late arrival) The number of delays at D0 and D5/15, comparable to OCC or UPM data The number of delays at D0 and D5/15 per time window caused by AS processes The PDM per resource and per time window (in half hours) The PDM per resource for every main group of aircraft types (KLC, NABO and WIBO) The “waiting time minutes”per resource per cause of waiting The scheduling percentiles per resource (recall Table 5.9)
An example of an output report for the first basic run (run 18) from Figure 7.1 is provided in Table 7.2 to Figure 7.10. This is the only full output report that is shown in this thesis, for giving an example of how the output looks like when presented in tables and graphs. From the output reports of further runs, only some relevant parts are presented. Note that sometimes numbers are given for a certain time window. In that case the time window represents the sum of the seven days in that week. In all figures averages are taken over the five weeks that were tested.
Week 1 Week 2 Week 3 Week 4 Week 5 Average
No. of departures 2091 2091 2092 2081 2093 2090
PDM incl. Network (x1000) 4129 4150 4895 4591 3877 4328 PDM excl. Network (x1000) 3656 3548 3528 3409 3413 3511 No. of Delays (0 min.) 1153 1142 1143 1115 1127 1136 No. of Delays (5 / 15 min.) 778 781 739 744 756 760
Table 7.2: Departures, PDM and delays per week
THESIS PAUL ADRIAANSEN –APRIL 2009 68 250
# flights STD AS delay, 0 min. AS delay, 5/15 min. 200
150
100
50
0 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00
Figure 7.3: The number of departed aircrafts and delays caused by AS at D0 and D5/15 per time window
900 crewattendence
800 boardsupply water towing 700 toilet tech 600 pushback kluhcleaning kluhcheck 500 fuelnonhydrant fuelhydrant 400 deboarding catering
300 boarding bax asitocleaning 200 asitocheck
100
0 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00
Figure 7.4: PDM (x 1000) caused per process and per time window
THESIS PAUL ADRIAANSEN –APRIL 2009 69 Shares of processes in total AS delay according to Picasso
Water 0.8% 0.5% Toilet 1.9% 4.3% 4.0% Catering 0.0% 3.1% 0.4% 1.5% Asitocleaning 0.2% 3.6% Asitocheck 8.8% 9.6% Kluhcleaning Kluhcheck 5.0% Fuelhydrant Fuelnonhydrant Pushback 13.0% 10.9% Towing Bax Boarding Deboarding Tech 32.4% Boardsupply Crew Attendance
Figure 7.5: The proportions per process in the total PDM
Shares of processes in delay per main aircraft type
1800 Crew Attend. 1600 Board supply Tech 1400 Deboarding Boarding 1200 Bax Towing ) 0
0 1000 Pushback 0 1 x
( Fuelnonhydrant
M 800 Fuelhydrant D P Kluhcheck 600 Kluhcleaning Asitocheck 400 Asitocleaning Catering 200 Toilet Water 0 WiBo NaBo KLC
Figure 7.6: The PDM proportions per resource per main group of aircraft type
THESIS PAUL ADRIAANSEN –APRIL 2009 70 Process Reason of waiting WIBO NABO KLC SUM
Asitocheck Asitocleaning 161 161 Asitocheck Catering 174 174 Asitocheck Crew attendance 511 511 Asitocleaning Deboarding 156 156 Asitocleaning Board Supply 2095 2095 Fuelhydrant Deboarding 73 38 111 Fuelnonhydrant Deboarding 18 3 21 Kluhcheck Kluhcleaning 523 194 716 Kluhcheck Catering 64 64 Kluhcheck Crew attendance 936 823 1760 Kluhcleaning Deboarding 114 70 185 Pushback Boarding 71 379 450 Pushback Tech 116 124 240 Pushback Bax 157 143 300 Pushback Fuelhydrant 249 452 701 Pushback Fuelnonhydrant 19 86 105 Toilet Flight 109 168 203 479 Water Flight 195 205 207 607
Total: 8835
Table 7.7: Total waiting times in precedence relations in minutes
Waiting time as percentage of capacity 6.00% 5.00% 4.00% 3.00% 2.00% 1.00% 0.00% k g t t k g k t r c in n n c in c ile e e n ra ra e n a o t h a d d h a b t a c le y y c le h w ito c lh h h c s s o e n lu h u a it u o k u p s f ln l a e k fu
Figure 7.8: The waiting time as percentage of capacity per AS resource
THESIS PAUL ADRIAANSEN –APRIL 2009 71 Waiting time caused per process
2% 12% 8% asitocleaning kluhcleaning 8% fuelhydrant fuelnonhydrant 1% tech 3% bax 3% 24% deboarding boarding 5% catering crew attendance 5% boardsupply
3% flight / netw ork
26%
Figure 7.9: The proportion of total waiting time caused per source of delay
100% 90% asitocheck 80% asitocleaning 70% fuelhydrant 60% fuelnonhydrant 50% kluhcheck 40% kluhcleaning 30% pushback 20% 10% toilet 0.8 0% 0.65 water 0.5 0.35 0.2
Figure 7.10: Proportions of scheduling percentiles per resource
7.1.3 Independence of output from different runs
In Section 7.2.1 the full basic run consisting of 35 weeks will be described (run 18, on which the above figures are based, contains only the first five weeks of this basic run). The programming problems described in Section 6.1.4 and 6.1.5 give reason to question the independence within these 35 weeks. The consecutive weeks within a single run are IID by definition, since they were modeled as IID. However, equally numbered weeks could show dependence over different runs due to two reasons:
THESIS PAUL ADRIAANSEN –APRIL 2009 72 First, OPiuM simulates the arrival instants equally every run. Furthermore, a large part of the single stream Picasso uses, is reused in equally numbered weeks over different runs, since only the first 100 random numbers are spilled.
This last effect was claimed to be neutralized by the desynchronized nature of the model in section 6.1.4. Although it would have been better to waste much more random numbers (or just work with separate streams), its is unlikely that much dependence follows from this effect, because the thirty sources of randomness ask for random numbers in completely different orders, for completely different probabilities or durations.
The first effect is more worrying though, since there are no statistical techniques available to test the effects of existing dependencies on the output data. To be able to say something about the output data we need to assume that this effect is limited. Another notion that we take from this problem, is that taking the OPiuM effects into account in analysis of the output data should be avoided as much as possible. So we do use the effects of all kinds of uncertainties that OPiuM creates, but we try to eliminate these effects as much as possible when we look at the output data (PDM for example). This is the main reason for looking at PDM excluding Network and Flight delays, since these are fully depending on the stochastic processes in OPiuM.
7.1.4 The Welch approach
In the following sections all kinds of alternative system configurations will be compared to the basic run. To be able to say something about the significance of the differences between scenarios, confidence intervals should be created for the differences of interesting observations. Two classical methods are known for this analysis (Bain and Engelhardt, 1992): 1. The paired-t confidence interval This method can be used for two equally sized samples, that need not be independent and both means and variances can be unknown. The confidence interval is based on the differences between paired observations, and is therefore especially useful for analyzing systems with natural dependence between the observations or systems that used Common Random Numbers. 2. The Two-sample-t confidence interval This method for creating confidence intervals does not require the sample sizes to be equal. However, this method does require that the sample observations are independent. Furthermore, it assumes that the variances of both samples are equal. Especially this last assumption is in general a problem for all simulation systems.
Since running Picasso cost a lot of computation time and manual administrative work, only the basic run consists of 35 observations. The alternative configurations only contain five data points. Throwing away 30 observations of the basic run in order to be able to use the paired-t test is not improving the quality of the test. The independence between the two samples is something that we have already assumed, but the assumption of equal variances makes it impossible to use the two-sample-t method either. Therefore it might be interesting to take a look at the Welch approach that is an approximation of the two-sample-t test without the assumption of equal variances. One of the underlying assumptions however is that the observations are normally distributed, which is hard to test for small samples, therefore normality is assumed. This assumption can be justified by the fact that a PDM observation is the sum of thousands of random variables. However, we still need to keep in mind that normality is not proven, so there is no guarantee that the Welch approach can be applied. For now we assume it does and the Welch approach works as follows (Bain and Engelhardt, 1992):
n 1 2 1. Calculate the sample mean X (n) and sample variance S 2 X X (n) for both n 1 i i1 samples. 2 S 2 (n ) n S 2 (n ) n 2. Calculate the estimated degrees of freedom: fˆ 1 1 1 2 2 2 2 2 2 2 S1 (n1 ) n1 (n1 1) S 2 (n2 ) n2 (n2 1)
THESIS PAUL ADRIAANSEN –APRIL 2009 73 3. Determine the two nearest integer values l and u for fˆ, and interpolate between the two resulting values for t and t from a table with t-statistics. Call the result t . l,12 u,12 fˆ,12 S 2 (n ) S 2 (n ) 4. Now the interval X (n ) X (n ) t 1 1 2 2 is an approximate (1) 1 1 2 2 fˆ,1 2 n1 n2 confidence interval for the difference of the means of both systems.
This confidence interval will be used often throughout the following sections. In general, we call a difference between two means significant if 0 is not in the confidence interval.
Now an important remark must be made about the significance of the tests ran with the Welch approach. Since we are testing multiple output parameters with one experiment, the Bonferroni Inequality should be respected. The Welch Intervals are applicable to the tested output variables, but only when you look at them one at a time. The Bonferroni Inequality states that the Type 1 error of a joint statistical test for n variables is smaller than or equal to n times the significance used to construct the Confidence Intervals for the individual variables. This means that the power of a statistical test is strongly diluted when a statement needs to be made about more than one variable simultaneously.
7.2 Runs
In this section all the runs are described that were performed. Including the validation process, about 40 runs were made, of which 21 are described in this section. First the basic run is explained and then the validation process is illustrated. Finally all the alternative system configurations of interest are reviewed.
7.2.1 Basic run
Run 18 that was introduced at the start of this chapter was the first of five basic runs. Run 19 and 20 had both a length of ten weeks. Run 21 and 22 had a length of five weeks, just as run 18. Although the tables and figures in Section 7.1 are only based on five out of these 35 runs, they provide good insight in how the results of the basic run looks like. For the basic run, independency is assumed, based on the argumentation in Section 7.1.3, therefore we can consider the 35 observations of run 18 to 22 as one set of 35 independent observations of the system in the basic configuration.
Based on this data it is also possible to show the influence of Network/Flight delays on the variance of the PDM. The sample means and variances of the PDM including and excluding Network (and Flight) delays were used to construct probability density functions under the assumption of normality (see Figure 7.12). The data itself is in Table 7.13. Because the variance of the PDM excluding Network delays is much lower and unwanted effects of the OPiuM randomization are in the Network delays, we will use this PDM in our further analyses.
THESIS PAUL ADRIAANSEN –APRIL 2009 74 PDM incl. Network PDM excl. Network y t i s n e d
y t i l i b a b o r P
3 3.2 3.4 3.6 3.8 4 4.2 4.4 4.6 4.8 5 5.2 5.4 PDM (x1 mln)
Figure 7.12: Probability density of PDM incl. and excl. Network/Flight delays under normality
In the following sections, alternative system configurations will be compared to this basic run. However, the means and variances that are used to build Welch Confidence Intervals are based on only 30 out of 35 runs. All alternative system configurations were based on runs which started with spilling 101 random numbers. The first five weeks of run 19 were also based on this starting point, so to avoid any risk of dependence between the samples (which would violate the assumptions underlying the Welch approximation), these five weeks are discarded from the dataset. Therefore we use the remaining 30 observations for the comparison with alternative configurations. The results of the full basic run with sample size 30 are in Table 7.13 and 7.14. The sample mean of the PDM over these 30 runs was 3525 (x1000) minutes (the PDM will be stated in thousands of minutes, to decrease the length of the numbers). Under the assumption of normality, all the resources have a significant contribution to the total PDM, when using a two sided t-test with significance level 0.05. Unless stated otherwise, PDM refers to Passenger Delay Minutes caused by AS and non-AS processes excluding Network and Flight delays.
Mean Standard deviation
No. of departures 2089.1 6.8
PDM incl. Network (x1000) 4370 356 PDM excl. Network (x1000) 3525 141 No. of Delays (0 min.) 1132 16.0 No. of Delays (5 / 15 min.) 762 19.0 Table 7.13: Mean and standard deviation of flights, PDM and delays
THESIS PAUL ADRIAANSEN –APRIL 2009 75 Process Allocated PDM (x1000) St. dev. (x1000) Percentage of total asitocheck 375.9 45.5 10.7% asitocleaning 129.5 23.2 3.7% bax 54.8 8.0 1.6% boarding 151.5 11.3 4.3% catering 11.6 3.0 0.3% deboarding 0.5 0.2 0.0% fuelhydrant 372.7 62.6 10.6% fuelnonhydrant 183.9 36.4 5.2% kluhcheck 1129.5 41.5 32.0% kluhcleaning 432.9 26.8 12.3% pushback 294.1 52.1 8.3% tech 51.7 10.4 1.5% toilet 104.1 22.1 3.0% towing 3.5 1.2 0.1% water 145.3 17.7 4.1% boardsupply 63.9 14.9 1.9% crewattendance 20.0 4.9 0.6% Table 7.14: Mean and standard deviation of allocated PDM and PDM as percentage of total
7.2.2 Validation scenarios
One part of the model validation was already performed before any decision was made on the basic run. This part concerned finding the mark-ups that were put on the workload schedule in order to get valid capacity levels (see Section 6.4). The 40% mark-up was found by increasing the capacity levels with steps of 10% until a level was found at which no more than half of all departing flights was delayed. This goal was almost reached (at a mark-up of 40%, 54 percent of all departing aircrafts gets a D0 delay). Of course this procedure of “validation the other way around” is not very sophisticated, but rescaling the model was the only way to get credible results in the basic run.
The part of the validation that was based on the basic run consisted of three runs: 1. Increasing the capacity of some resource in order to look what happens with the total delays and the PDM of this resource (run 23). 2. Decreasing the capacity of some other resource and again look at the PDM distribution (run 24). 3. Choosing a time frame in which one resource is completely unavailable: look what happens with the departure delay and the PDM distribution (run 25).
In the first scenario the capacity of kluhcleaning was increased overall with one (an increase of the total kluhcleaning capacity with 12.3%). The mean of the total PDM dropped from 3525 (x1000) to 3157 (-10.4%) and at a two-sided alpha of 0.05 the Welch confidence interval for the difference is (- 495, -242), so this decrease is significant. Also the number of delays (both D0 and D5/15) dropped significantly. The PDM allocated to kluhcleaning nearly disappeared (from 433 to 17). Also kluhcheck showed a significant drop in PDM of 10%. On the other hand, the PDM allocated to pushback increased with 35% as a result. None of the other processes gave a significant reaction. Since kluhcheck and pushback are the only succeeding processes of kluhcleaning, this result is according to what we could expect to happen.
In the second scenario the capacity of fuelhydrant was decreased with one (9.5% in total). The total PDM increased with 343 (9.7%) of which 297 is directly allocated to fuelhydrant (almost doubled). Again pushback takes a large part of the blame, with an increase in PDM of 31%. All other processes give no significant results. Again this result gives not much reason to doubt the model, although the increase in pushback PDM has no clear reason. The change in allocation of PDM can be found in Table 7.16, since this run was used for the sensitivity analysis as well.
In the last validation run, the water resource was discarded for two hours between 12:00 and 14:00. The result was a non-significant increase in total PDM of 3%, which is quite low. The number of
THESIS PAUL ADRIAANSEN –APRIL 2009 76 delayed aircrafts did increase significantly with 4%. The PDM allocation of water increased with 43%, but this increase was hardly significant. It is clear however, that these PDM increases all resulted from delay in the early afternoon, since water is a necessary process in every turnaround.
In general it is possible to conclude that the measured effects of varying input variables point in the right direction and are logical in size. However, due to the small sample size and the innumerable interdependencies between variables, it might be hard to get significant results from the simulation model.
7.2.3 Unlimited resources
The run with “unlimited resources”for the AS processes is another interesting validation scenario. It would be nice to test whether and to what extent delays occur when there are an unlimited number of resources available for every process at any point in time. In this way, the AS processes are likely to behave comparably to the non-AS processes, since the latter have unlimited availability by definition. A dramatic fall in PDM is expected, but at the same time there will always be PDM caused by AS processes since there is still the possibility of durations exceeding the maximum time available due to the length of a turnaround.
The results of this run are in Table 7.15. These results can be compared to the results in Table 7.2 in order to see which part of the PDM is caused by the stochastic nature of the duration of the processes, and which part follows from a lack of capacity.
Week 1 Week 2 Week 3 Week 4 Week 5 Average
No. of departures 2094 2102 2091 2091 2091 2094
PDM incl. Network (x1000) 1061 1723 1505 1225 854 1273 PDM excl. Network (x1000) 223 206 218 211 199 211 No. of Delays (0 min.) 356 352 352 339 316 343 No. of Delays (5 / 15 min.) 42 45 26 48 47 42
Table 7.15: Departures, PDM and delays per week for run “unlimited resources”
7.2.4 Sensitivity analysis per resource
The validation experiment of run 24 (decreasing the capacity of fuelhydrant by one) is also a form of sensitivity analysis: what happens to the total PDM and the allocation of PDM per resource when the capacity of one of the AS processes is decreased by one? This question is answered for all nine AS resources in table 7.16. This table gives the percentage of change in delays and (allocated) PDM for the nine runs in which capacity was decreased for one of the resources. The average changes in PDM are based on an experiment of five weeks for every resource, compared to the results from 30 weeks of the basic run. In this table also the significance of each effect is indicated at two different levels for significance (see legend in table). The significance is again tested with the Welch procedure.
THESIS PAUL ADRIAANSEN –APRIL 2009 77 Sensitivity asito- asito- fuel- fuelnon- kluh- kluh- pushback toilet water analysis for: check cleaning hydrant hydrant check cleaning
Effect: PDM (x1000) 20% 6% 10% 1% 37% 21% 14% 9% -1%
Delays 0 m. 1% 1% 2% 0% 25% 2% 1% 3% 0% Delays 5/15 m. 6% 2% 4% 1% 32% 8% 3% 6% 0% asitocheck 217% 33% -9% -8% -2% 0% -4% -2% -6% asitocleaning -14% 50% -8% 1% -8% -12% -14% -8% -12% bax -2% -1% -12% -8% 6% 4% 21% 0% 1% boarding 8% 8% -3% -6% 18% 9% 3% 3% 1% catering -9% -20% 1% -13% -15% -14% -22% -34% -20% deboarding -8% -7% -5% -6% -12% 4% -41% -42% 38% fuelhydrant -7% -5% 79% -2% 2% 2% 13% 11% 0% fuelnonhydrant -15% -9% -4% 139% -5% 1% -12% -4% -10% kluhcheck 2% 4% 0% -6% 117% 15% 3% 1% -1% kluhcleaning -7% 1% 1% -14% 5% 143% 5% -16% 0% pushback -31% -8% 31% -10% -13% -19% 127% 4% -4% tech 18% 10% 12% 1% -6% 16% -4% -28% -7% toilet -14% 7% -2% -7% 1% 6% 15% 349% 7% towing 36% 41% 23% 4% 5% 28% 30% 8% -23% water -3% 0% -4% -14% 6% 5% 6% 0% 15% boardsupply 61% -5% 8% -6% -17% -18% 9% 15% -5% crewattendance -8% -9% -18% 2% -22% -19% 1% 7% -3%
Legend: Significant at alpha is 0.01 Significant at alpha is 0.05 Direct effect of capacity decrease on own PDM
Table 7.16: Sensitivity analysis of PDM allocation for decrease in AS resources
When looking at Table 7.16 it is important to keep in mind that some of these processes are very minor sources of delay (recall Table 7.5). This means that only a handful of delay events within this process could easily lead to a strong increase or decrease in terms of percentage. Especially the processes deboarding, towing, crewattendance and catering suffer from this. The effects measured in Table 7.14 corresponding to these processes should therefore be used with care. Since we try to calculate the level of significance for a lot of variables at the same time, while the sample size is quite small, we expect the Bonferroni Inequality to strike hard on these results as well. This means that the indicated significance of a measurement becomes subject to uncertainty itself.
Keeping this in minds, the following observations can be made from Table 7.16: All the effects that are found to be significant have a positive effect on the total PDM and number of delays. This is in accordance with what is expected. In general, the largest effects of a decrease in capacity are caused to the PDM allocated to the resource itself. This is in line with the expectations as well, since this is regarded as fair. The processes asitocleaning, fuelnonhydrant and water do not seem to have any significant effect on the delays. The fact that they are only minor sources of delay may point out that there is some level of overcapacity in these processes: These processes may cause delays at some specific moment on the day, but in general it is not harmful to decrease the number of resources in this process. Although toilet is also a minor source of delay in absolute terms, it has much more impact on the total effect and PDM. So it turns out that toilet is a much more critical process, something that could only be concluded after performing this sensitivity analysis. Pushback is a process that is quite vulnerable for changes in the capacities of other resources. Asitocheck and fuelhydrant are both processes that precede pushback, but a drop in the capacity of these resources has two totally different effects. When decreasing the capacity of asitocheck, the PDM allocation to pushback drops. This could be seen as a form of “substitution effect”: PDM that would have been allocated to pushback is now allocated to asitocheck, because the latter is more critical. A decrease in fuelhydrant leads to an increase of PDM allocation to both fuelhydrant and pushback; a “complementary effect”: a part of the
THESIS PAUL ADRIAANSEN –APRIL 2009 78 total PDM increase is caused by a positive correlation between capacity problems in the fuelhydrant process and problems as a result of that in the pushback process.
The last observation states an alarming effect. Negative correlations between PDM allocations of two processes are seen quite often. Positive correlations however, are a bit much rarer, but also much more harmful to the punctuality of the operation. In Section 7.4.2 a better look is taken at this effect.
7.2.5 Tests of intelligent decision making in Picasso
In Section 5.4 two types of intelligent decision making were introduced: scheduling the moment a job is added to the queue and calculating the priority of jobs in that queue. Both these techniques can be switched off which means that the more complex heuristic is replaced with some less advanced rule that performs well in general. In this section we evaluate the performance of the system without these intelligent heuristics.
Switching off the “intelligent scheduling” heuristic means that every job is assigned the scheduling quantity 0.5: the model uses the medians of distributions as their most likely outcome and does not anticipate on the length of available ground time. Note that a large part of the intelligence in this heuristic is still there: anticipation on the expected duration of preceding processes is in itself quite an intelligent rule. Also remember that in this experiment the “smart priority” heuristic is still working. Two interesting variables need to be measured: the effect on PDM and delays and the effect on waiting time (idle time of resources waiting for preceding processes). One of the ideas of intelligent scheduling was that waiting time would be reduced by not driving to an aircraft too early when enough time is available. The results are in Table 7.17.
T-test for effect of intelligent Basic run (n=30) Alternative Difference in Welch Confidence scheduling (alpha = 0.05) scenario (n=5) means Interval (2-sided) Mean St.dev. Mean St.dev. Abs. % lower upper
PDM excl. Network (x1000) 3525 141 3789 122 264 7.5% 116 411
No. of Delays (0 min.) 1132 16.0 1162 35.1 30.7 2.7% -12.7 74.1 No. of Delays (5 / 15 min.) 762 19.0 786 17.7 23.2 3.0% 1.9 44.6
Total waiting time (min.) 8818 2039 10930 734 2112 24.0% 1852 2372
Table 7.17: Results of simulation without “intelligent scheduling” heuristic
The effect of intelligent scheduling on PDM is significant at alpha is 0.05, but the results are not very convincing. The same is true for the number of delays: the “0 minutes” delay number shows no significant increase, while the “5 / 15 minutes” delay number increase is only just about significant. Of course these results suffer from the low sample size. The total waiting time however, shows a very clear and significant increase of 24%. It would be interesting to know what the effect of this 24% would be on the PDM when there would only be an “extra waiting time” effect. Then we can distinguish (roughly) the effect of intelligent scheduling on PDM as a direct effect by subtracting the “extra waiting time” effect from the total effect.
The fact that the total waiting time as a percentage of total available capacity (a weighted average over all resources) increases from 1.77% to 2.20% corresponds to a decrease in available capacity of 0.26 “resource units” on average. When comparing this to the PDM effects in Table 7.16, an increase in PDM of 3.4% would be expected when the average resource is decreased with 0.26 units. This means that of the 7.5% PDM effect of intelligent scheduling, about one half is a direct effect of intelligent scheduling and the other half concerns PDM as a result of extra waiting time.
The second intelligent part of Picasso is the “smart priority” heuristic. The simplified method that is used when switching off this heuristic is a FIFO method: the order in which aircrafts enter the queue of some process is also the order in which they are processed. Again remember that the “intelligent scheduling” heuristic is switched on in this experiment, so the jobs enter the queues in a way that
THESIS PAUL ADRIAANSEN –APRIL 2009 79 already anticipates on the length of the available ground time. As soon as some job is scheduled, the concerning process is no longer taking extra information about long process durations into account when assigning resources to jobs. The results of this experiment are in Table 7.18. T-test for effect of smart Basic run (n=30) Alternative Difference in Welch Confidence priority (alpha = 0.05) scenario (n=5) means Interval (2-sided) Mean St.dev. Mean St.dev. Abs. % lower upper
PDM excl. Network (x1000) 3525 141 4155 193 630 17.9% 395 865
No. of Delays (0 min.) 1132 16.0 1080 24.3 -51.2 -4.5% -80.6 -21.7 No. of Delays (5 / 15 min.) 762 19.0 758 27.6 -4.3 -0.6% -37.8 29.3
Table 7.18: Results of simulation without “smart priority” heuristic
Table 7.18 clearly shows that switching off the “smart priority” heuristic is strongly (and significantly) increasing the PDM. However, the total number of delayed aircrafts is actually decreasing. This means that the 17.9% increase in PDM is fully caused by aircrafts that were already delayed for at least 5 or 15 minutes. The FIFO system doesn’t allow delayed aircrafts to jump the queue. A positive effect of this is that these delayed aircrafts are not occupying resources that can now be used for handling the aircrafts that were not already delayed. This means that the “smart priority” heuristic is spreading less delay minutes over more aircrafts. This trade-off is arguable, but since Picasso uses the PDM measure as its most important output variable, the “smart priority” heuristic clearly has a positive effect on the punctuality performance.
7.2.6 Priority setting
One of the parameters in the smart priority heuristic is the priority number assigned to the main type of the aircraft (WiBo, NaBo or KLC). Of course it might be interesting to see what happens when these numbers are chosen differently. The differences between the priority values of the three categories were roughly based on average passenger numbers, so the ratios are kept equal. The experiment tests whether WiBo aircrafts are given more priority (and thus cause less PDM) when the differences between the categories are doubled. This means that priority resulting from aircraft size becomes more important compared to priority resulting from available ground time left. The original priority settings were KLC: 1, NaBo: 1.2 and WiBo: 1.6, so the new priority settings are now: KLC: 1, NaBo: 1.4 and WiBo: 2.2. The results of this experiment are in Table 7.19.
T-test for effect of priority Basic run (n=30) Alternative Difference in Welch Confidence setting (alpha = 0.05) scenario (n=5) means Interval (2-sided) Mean St.dev. Mean St.dev. Abs. % lower upper
PDM excl. Network (x1000) 3525 141 3646 141 121 3.4% -51 292
No. of Delays (0 min.) 1132 16.0 1139 11.7 7.7 0.7% -6.6 22.0 No. of Delays (5 / 15 min.) 762 19.0 761 12.2 -1.4 -0.2% -16.5 13.6
PDM WiBo total 869 78 775 54 -93 -10.7% -159 -27 PDM NaBo total 1604 83 1583 105 -20 -1.3% -148 107 PDM KLC total 1051 30 1285 49 236 22.5% 176 296
Table 7.19: Results of simulation with doubled priority differences between main types
The total number of PDM is slightly higher in the alternative scenario, but this effect is not significant at alpha is 0.05. However, the allocation between PDM among the three main type categories does show a significant difference. When doubling the differences between the priority numbers, WiBo aircrafts are causing less PDM at the cost of KLC aircrafts.
THESIS PAUL ADRIAANSEN –APRIL 2009 80 7.2.7 Early morning correction
The last alternative configuration that was simulated was designed to test a possible solution to the large PDM score in the early morning. As can be seen in Figure 7.3 and 7.4, there is a large peak in the PDM between 5:00 and 5:30. Almost all the 100 flights that should leave every week in this time frame are delayed with on average 40 minutes each. Of course this is not a realistic number, so it would be interesting to look for a solution for this strange outlier. When looking at the timetable, the capacity tables and the probability distribution for arrivals in OPiuM, it is possible to distinguish three reasons for the peak in PDM: 1. Some over-night stopping aircrafts are in PlanControl partially serviced during the night. This means that for example a water job is already performed, while in Picasso this water job can only be started some hours before the aircraft leaves. 2. It is very common that WiBo aircrafts arriving from the west (United States mostly) arrive much earlier than scheduled (up to one hour). In practice the aircraft is towed away right after unloading (without cleaning etc.) although the actual ground time available exceeds 270 minutes. This means that PlanControl calculates a turnaround with quite some ground time (since the scheduled ground time is less than 270 minutes) while Picasso performs a separate (and urgent) ARR and DEP action. This does not only result in more workload, but especially workload in a timeframe that is not expected: up to one hour earlier than the original arrival of the aircraft. At that time there is not enough capacity of the associated resources, which means that the whole pipeline is obstructed also for other resources and aircraft types. 3. Since PlanControl optimizes the shift hours tightly according to planned workload, the resource capacities start to increase just in time to process all jobs according to their norm durations. There is no slack at all, which means that as soon as one job exceeds its norm duration, this resource will cause a delay at some point in time. This effect is catalyzed by the right-skewed nature of the duration distributions and the waiting time that results from precedence relations.
It is not totally clear what part of the peak can be assigned to each of these three reasons. Reason 1 and 2 are “modeling errors” and are therefore less interesting. The third reason however, is a problem that is also seen in practice. Most departing aircrafts have a lot of available ground time before they depart, but this time is not used because of the tight shift scheduling rules. So, by advancing the starting time of the early shifts by one hour, it is possible to solve capacity problems later on (including the 5:00 peak). All resources that are scheduled to start between 4:30 and 6:30 start one hour earlier, which corresponds to an increase of the total capacity of 3% on average for all resources. The result of this “early morning correction” is in Table 7.20 and Figure 7.21.
T-test for effect of early Basic run (n=30) Alternative Difference in Welch Confidence morning corr. (alpha = 0.05) scenario (n=5) means Interval (2-sided) Mean St.dev. Mean St.dev. Abs. % lower upper
PDM excl. Network (x1000) 3525 141 1686 135 -1839 -52.2% -2003 -1676
No. of Delays (0 min.) 1132 16.0 872 20.7 -259.9 -23.0% -285 -235 No. of Delays (5 / 15 min.) 762 19.0 454 13.8 -307.9 -40.4% -325 -291 Table 7.20: Results of simulation with early morning correction
THESIS PAUL ADRIAANSEN –APRIL 2009 81 400 crewattendence boardsupply 350 water towing
300 toilet tech pushback 250 kluhcleaning kluhcheck fuelnonhydrant 200 fuelhydrant deboarding catering 150 boarding bax 100 asitocleaning asitocheck
50
0 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00
Figure 7.21: PDM per resource and per time window after early morning correction
The effect of the early morning correction is enormous: the PDM drops with more than 50% and also the decrease in delays is strongly significant. In Figure 7.21 the early morning peak has shrunk to minor proportions and also the rest of the early morning is almost free of delays.
7.3 Interpretation of the results
It is possible to say that the level of realism of a simulation model depends on two factors: first the realism in assumptions underlying the input and the model, and second the credibility of the output. Especially when the simulation model aims at imitating the working of some existing system, the credibility of the output can be used to validate the model. When it comes to Picasso, the first factor (realism in assumptions) is fulfilled much better than the second factor (credibility of output).
Some examples of assumptions underlying the input and the model which are realistic: The timetable simulation by OPiuM The towing decisions by OPiuM (as realistic as they are in PlanControl) The available information about different types of aircrafts The interactions between jobs: precedence relations and waiting for end-of-job The interactions between aircrafts: priority settings in queues Anticipation on ground time: job scheduling and time gap The distributions of the process durations, although exact estimation is not always possible
Examples of parts which are less realistic: The processes that are selected as AS processes: catering and towing are left out The unlimited capacity of non-AS processes The assumptions regarding fuelling (prefuels, NaBo hydrant choices, length of duration) are quite rough The capacity numbers of AS resources: the 40% correction mark-up is an admission of weakness
THESIS PAUL ADRIAANSEN –APRIL 2009 82 Some thoughts about the credibility of the output: In general, the measured PDM is far from reality. Compared to the basic run, Picasso simulates five to ten times the PDM that is realistic for a busy week (when only looking at AS processes). The same is true for the number of delays caused by AS processes) However, the total number of delays and the total PDM (including flight / Network delays and delays caused by non-AS processes) is quite near reality. Picasso totally focuses on AS processes, which justifies the emphasis on AS delays to some extent (although a factor 10 is just not realistic). The distribution of PDM among the different AS processes is quite realistic (Kluh processes are in reality quite a big source of disturbance). Also the spread of PDM over the day is realistic since delays especially occur during peak moments. The time that resources need to wait for preceding processes is actually quite low in Picasso. In practice this can be much more, especially since non-AS processes can cause extreme delays which heavily disturb the schedules of AS resources. These non-AS processes all behave moderately in Picasso, since lack of resources or extreme cases were not simulated for these processes.
The last argument mentioned above introduces the “iceberg”-argument which can explain some part of the large difference in PDM between Picasso and reality. You could say that in reality a large part of the AS delays simulated in Picasso does really occur. However, they are not noticed as “AS delay” since a lot of non-AS processes cause delays as well. So the AS delays that are really recorded as “AS delay” in the UPM are in fact only the “top of the iceberg”. The total amount of PDM caused by AS processes is in fact much bigger (the part that is under water) but this is concealed by all the other delay causes. When now all these other delay causes are modeled very conservatively, have unlimited resources and behave very moderately, a much larger part of the iceberg becomes visible.
This effect is even strengthened by the fact that AS processes can be partially blamed for delays that would normally only be ascribed to a non-AS process. For instance, when deboarding takes 10 minutes too long, the kluhcleaning resource is 5 minutes late and the final delay of the aircraft is 10 minutes, Picasso assigns 3.33 minutes to kluhcleaning (depending on the circumstances) while in reality, according to the current OCC measurement, deboarding would take the full 10 minutes.
As a conclusion it is clear that, although there are some mitigating arguments and explanations, the absolute values of the outcomes of the Picasso simulation study are not realistic. However, they do say something about the punctuality of AS processes in a turnaround, especially when comparing different scenarios: The per cent allocation of PDM among processes is valuable The distribution of PDM over the day is relevant, especially when keeping the effect of the early morning correction in mind The PDM effects per process in the sensitivity analysis are relevant when measured as a percentage of total PDM The indirect PDM effects in the sensitivity analysis are especially interesting since they show the relation in punctuality between processes The waiting times as the result of precedence relations are relevant The differences in PDM allocation between main aircraft types are interesting since they show the impact of priority setting on delays
7.4 Conclusions from Picasso
In this section, conclusions are attached to the observations stated earlier in this chapter. This chapter does not intent to answer the main questions stated in Chapter 1, but it translates the full set of observations into useful conclusions. In the first subsection the general results are compared to known numbers from UPM and OCC reports. The second subsection focuses on the interdependencies between processes. The last subsection states some other conclusions based on observations described earlier in this chapter.
THESIS PAUL ADRIAANSEN –APRIL 2009 83 7.4.1 General conclusions
Keeping in mind the reservations stated in the previous section, it is possible to compare some of the results found to the OCC and UPM numbers presented in Section 4.2. In Table 7.22 some relevant values are put next to each other. Apart from the AS share in total delay, the numbers are quite comparable. Recall the earlier observation that the PDM score becomes much more reliable when the Flight / Network delays are left out. However, to be able to compare data with the PAT report of OCC this Flight / Network delay should be included since it is included in the PAT as well.
Picasso OCC PAT UPM Delays 0 min % 54.2% 67.8% - Delays 5/15 min. % 36.5% 41.8% - Share AS in total delays 72.5% 3.4% - Average duration of delay 15.6 min. n/a 11.1 min.2 % of delay caused by Flight / Network 19.3% (PDM) 16.7%1 n/a 1. As a percentage of the total delay causes 2. Based on AS processes only
Table 7.22: Some numbers from different performance reports
With the arguments introduced in the previous section we can assume that the relative sizes of the PDM assigned to AS processes are still valid. Therefore it is interesting to put the causes of AS delays in a diagram comparable to Figure 4.4 and 4.6; the result is in Figure 7.23. Note that although catering and towing are included in Figure 7.23 they do not belong to the AS processes as modeled in Picasso.
Shares of processes in total AS delay according to Picasso 0.1% 4.5% Water 9.2% 3.3% 0.3% Toilet 5.8% 4.1% Catering
11.8% Asitocleaning 11.7% Asitocheck Kluhcleaning Kluhcheck Fuelhydrant 13.6% Fuelnonhydrant Pushback Towing 35.4% Figure 7.23: shares of AS processes in total AS delay according to Picasso
Figure 7.23 shows that Picasso predicts much more delay caused by cleaning and especially security check than UPM has measured. One explanation for this could be that security check is not a category on its own in the UPM. The security check is a relatively new process which is not taken into account in the AIS. It is therefore possible that OCC is more accommodating in assigning delay codes to the cleaning companies that perform the security check. An obvious conclusion is that AS should pay attention to the process of the security check. Although the security check is quite flexible in its time slot (it can already start when cleaning is still busy), two pitfalls are dangerous when it comes to the security check: 1. It is tempting to adjust the speed of work to the progress of the cleaning team. When walking right behind the cleaning team, a lot of valuable time is lost. The security teams are supposed to check an aircraft much faster than it is cleaned.
THESIS PAUL ADRIAANSEN –APRIL 2009 84 2. The duration of a check job is extremely vulnerable to the crew attendance instant. It would help the planning of the security teams when there is information available about the expected arrival of the cabin crew at the aircraft.
Compared to the Klüh processes, Asito performs quite well. This could be related with the fact that WiBo aircrafts have priority in the queues of other processes which means WiBo aircrafts suffer less delays and the starting moment of the cleaning job can be predicted more precisely.
One of the most important benefits of Picasso is that it is possible to foresee punctuality problems on certain moments of the day. In the timetable of summer 2007, six workload peaks can be recognized. The peaks are clustered around the times: 5:00, 7:30, 10:30, 13:00, 15:30 and 18:30. Of these peaks, the first, second and sixth are facing problems with punctuality (recall Figure 7.4). As is shown by the early morning correction, the problems in the first peak are easy to solve. Therefore Picasso shows what the most vulnerable time periods of the day are: The wide morning peak between 7:00 and 9:00. This peak is the widest of all peaks and difficulties can occur when there is still some workload left from the first peak. We noticed that a large part of the problem is caused by early ICA arrivals in the early morning. The process that is the major cause of the delays is kluhcleaning. The second largest cause is fuelhydrant, followed by asitocheck and kluhcheck. The high evening peak between 18:30 and 19:30. This peak is the highest of all peaks and delays tend to occur at the very end of the peak. This might be caused by some similar effect as the early morning peak: when the ends of work shifts are scheduled too tight to the timetable, a minor delay can start a chain reaction in delays. Delays at the end of the day mean that workload is still at a high level at the moment that most work shifts end: this could lead to some extreme delays. The major causes of delay in this peak are kluhcheck and pushback.
Another way to look at these peaks is to take the available ground time in the timetable of Summer 2007 into account. Since ground time needed differs per aircraft type, the available ground time is presented as a percentage of the minimal ground time needed. The results are in Figure 7.24. For every action (TA, ARR or DEP) in the timetable the scheduled duration is calculated and divided by its minimal norm. The action then falls into one of the four categories (Minimum, low, medium or high) and its weight is equal to the minimal norm duration for that action, normalized over all actions in the timetable. The value for this action is then assigned to the time slot (per half hour) in which its STD or scheduled End of Arrival falls. The sum of the four stacks can be seen as the total workload associated with aircrafts departing in that half an hour. When the average available ground time percentage becomes lower, this means that a larger part of the workload actually needs to be performed in that time slot (lower flexibility).
Another representation of this result is in Figure 7.25. In this figure the average available ground time per action is presented as a factor of the minimum ground time for that action (not weighed for aircraft type). The line in Figure 7.25 indicates the average slack (the factor presented minus one) that is available on certain moments on the day. The lower the slack, the more difficult the operation will be, due to the loss in flexibility and buffer time. Although Figure 7.24 has more information in it, Figure 7.25 presents the same message in an easier way: look how the available ground time evolves over the day in order to foresee difficulties.
Now we face an interesting difference in the available information. When we look at the peaks around 8:00 and 19:00 in Figure 7.4, we would expect to find an explanation for these peaks in Figure 7.24 and Figure 7.25. This works for the peak around 19:00, since the number of actions with minimum ground time is high at 19:00 (and the average ground time factor drops below 1.5). The peak around 8:00 however, does not coincide with a low available ground time factor, or very short turnarounds. This indicates that the morning peak is much more a problem caused by a lack of resources, while the evening peak is to a large extent the result of short turnaround times. The peak in PDM around 19:00 is caused by a high number of short turnarounds just after the very busy period between 18:00 and 19:00. Also note that the evening peak consists of almost only departures, while the morning peak is a combination of arrivals and departures.
THESIS PAUL ADRIAANSEN –APRIL 2009 85 Number of turnaround actions per category of available ground time
90
80
70 t n 60 e l a v i u q 50 e n o i t c
a 40 d n u o r 30 a n r u t
d 20 e t h g i e w 10
0 0 0 0 0 0 0 : : 0 0 0 3 : 0 4 : 0 0 5 : 0 0 6 0 : 0 7 : 0 0 8 : 0 0 9 0 : 0 0 : 0 0 1 : 0 0 1 2 0 : 0 1 3 : 0 0 1 4 : 0 0 1 5 : 0 0 1 6 : 0 0 1 7 : 0
Minimum: <105% 0 1 8 : 0 1 9 : 0 1 0 : 1 1 2 2
Low: 105 - 120% 2 2 Medium: 120 - 160% High: >160% Figure 7.24: Distribution of available ground time
Average available ground time per action
4 400
Number of actions n 3.5 350 o i t Average ground time factor c a
r 3 300 e p
r s o n t o
c 2.5 250 i t a f c
a e f
m 2 200 o i
t r d e n b u m o 1.5 150 r u g N
e l
b 1 100 a l i a v
a 0.5 50
0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 :0 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1 1 1 1 1 1 1 1 1 1 2 2
Figure 7.25: Average available ground time per action (as a factor of minimum ground time)
THESIS PAUL ADRIAANSEN –APRIL 2009 86 7.4.2 Interdependencies in PDM allocation
In this section we draw conclusions from the sensitivity analysis presented in Section 7.2.4 and the corresponding numbers in Table 7.16. There are two levels of observations in this analysis: 1. If the capacity of some resource is reduced with one, is there any effect (and how large is it) on total PDM, the number of delays and the PDM allocated to this specific resource? We observed that the first two effects are existent for six out of nine processes. Direct effects on own PDM allocation are significant for seven out of nine processes. 2. What are the effects of the capacity decrease on the PDM allocation to other processes? What does it mean when two processes have a positive or negative correlation?
Substitution effects (negative correlation) Object1 Subject2 Effect Possible explanation asitocheck pushback -31% The most likely explanation for this effect is that peaks in the workload of pushback are spread over a larger time frame. Some of the WiBo aircrafts that would have been delayed by pushback during the pushback-peak are now already delayed by the security check. When they ask for pushback a while later, the pushback-peak is over and pushback performs in time. fuelnonhydrant kluhcleaning -14% These processes are scheduled parallel to each other, so the explanation of this effect is quite straightforward. When kluhcleaning has less capacity, kluhcleaning is delaying aircrafts more often. Some of these extra delayed aircrafts would have been delayed by fuelnonhydrant, but since kluhcleaning is even later, fuelnonhydrant is less blamed for it. pushback asitocleaning -14% This effect is less obvious since pushback and asitocleaning do not meet very often: WiBo turnarounds are rare and in a Departure asitocleaning only performs the boardsupply. The most probable explanation is that pushback takes over parts of the delay that was caused by asitocleaning during boardsupply. toilet kluhcleaning -16% For these processes the “parallel scheduling”-argument of fuelnonhydrant and kluhcleaning is valid again. Especially the aircraft types 733 and 734 will contribute to this since they have quite a long toilet duration. toilet tech -28% Tech is a process that is constantly parallel with all other processes. It is actually quite strange that only toilet gives a significant negative correlation. water asitocleaning -12% Also for these processes the “parallel scheduling”-argument of fuelnonhydrant and kluhcleaning is valid. All the WiBo aircrafts have quite long water jobs, also in Departures. 1. Object: this is the process of which the capacity is decreased with 1 2. Subject: this is the process that is facing the change in allocated PDM
Complementary effects (positive correlation) Object Subject Effect Possible explanation asitocheck boardsupply 61% Although this is one of the largest and most significant indirect effects in the sensitivity analysis, I did not manage to find out how this positive correlation is created. At first sight one would expect a negative relation. Asitocheck does not influence boardsupply (which has no resources, it is only a source of waiting) and asitocheck would take a larger share of the PDM when boardsupply would have caused a delay. fuelhydrant pushback 31% This is a very clear example of positive correlation due to the nature of the process scheduling. The fuelhydrant process should at least be ended when boarding is finished. After that, the pushback can start immediately. When fuelhydrant lacks capacity, a larger part of the aircrafts will be fuelled later than requested. Together with the sometimes long tails of the duration distribution (recall that fuelling durations follow a Triangular distribution with an extra tail) this can lead to the situation that pushback capacity is wasted. A pushback truck will always start driving to an aircraft on time, so this resource needs to wait a long time when the fuelhydrant process is causing delay. The lack of pushback capacity that is created will lead to delay at other aircrafts. kluhcleaning kluhcheck 15% This is another good example of a positive correlation. The main reason is probably the steep decrease in kluhcheck capacity just after the morning peak between 7:00 and 9:00. When kluhcleaning lacks capacity, the pipeline of NaBo and KLC aircrafts is obstructed. By the time all these aircrafts are ready for kluhcheck, the capacity of kluhcheck has been decreased (since its scheduled peak is over). These already delayed aircrafts face another delay since they need to wait for the security check. pushback bax 21% Just as in the relation between asitocheck and boardsupply I could not find a logical explanation for this effect. Bax is a process with unlimited resources, which means that the only explanation for this positive effect would be a (calculation) error.
Table 7.26: Positive and negative correlations between processes
THESIS PAUL ADRIAANSEN –APRIL 2009 87 The second question refers to the introduction of “substitution effects” following from negative correlation, and “complementary effects” following from positive correlation. These concepts were introduced in Section 7.2.4 and in Table 7.26 all the relevant interdependency effects are stated. The effects are considered as relevant when they are significant at an alpha of 0.01 and have large enough absolute value. The latter means that effects on the processes deboarding, towing, crewattendance and catering are excluded since their PDM allocation is too insignificant.
The interesting results from Table 7.26 are obviously the two well explained positive correlation effects between fuelhydrant and pushback and between kluhcleaning and kluhcheck. It is clear that these process dependencies should be handled with extra care when planning or scheduling jobs or resource capacities.
7.4.3 Other conclusions
This chapter ends with two last conclusions that can be drawn from the Picasso observations. The first one is about the early morning correction and the second one deals with the priority setting of small aircrafts.
In section 7.2.7 the early morning correction was suggested as a solution for the extreme peak in PDM around 5:00 in the morning. The solution was: advance all shifts between 4:30 and 6:30 with one hour. It is not clear what proportion of the initial PDM peak around 5:00 originates from the “realistic” cause: the shift hours that were scheduled too tight. The other two reasons were more or less modeling errors, so the “real” decrease in PDM will be lower than the dramatic 52% mentioned in Section 7.2.7. Nevertheless it is fascinating that a 3% increase in capacity can lead to such a result. The lesson that should be learned from this is clear: when the resource capacities are planned too tight around the workload, even the smallest interference can start a chain reaction of delays. The system will always find the weakest link and from that moment on that process is the main bottleneck. This is not only true for a start-up period, like the start of the early morning peak; too tight capacity planning can also lead to problems at the end of a peak. When, for some reason, the pipeline of a certain process is not yet empty at the end of a peak, the capacity starts dropping while the process has still jobs in the queue. These last jobs will now face long delays, an example of that is the kluhcheck delay in Table 7.26. The summary of this conclusion is in Figure 7.27.
Timetable situation
Scheduled workload
Planned capacity
Actual situation
Many short delays Actual workload Some very long delays Planned capacity
Delay area
Catch-up area
Figure 7.27: Explanation of delays around a workload peak
THESIS PAUL ADRIAANSEN –APRIL 2009 88 Another conclusion that can be drawn from the Picasso observations is about the priority of WiBo aircrafts over NaBo aircrafts and NaBo aircrafts over KLC aircrafts. Larger aircrafts face much more restrictions on runway use, timetable sensitivity, crew planning etc., so this priority setting lies outside the management span of AS. However, from an AS point of view, it is interesting to see what the effect of this priority setting is on the PDM performance. When evaluating priority setting, two parameters are relevant: 1. The relative priority of WiBo over NaBo and NaBo over KLC. In Picasso these parameters were taken fixed, roughly based on the average number of passengers for the corresponding aircrafts. 2. The relative importance of the size of the aircraft compared to other variables in priority setting, as for instance the available ground time
In the priority setting experiment of Subsection 7.2.6, the relative importance of the aircraft size was doubled in order to test the effect on PDM. The observation was clear: the overall effect was not significant, but the breakup showed a significant shift from large aircraft delays to small aircraft delays (see Figure 7.28). The question we would like to answer is: “What is, given the relative priorities between WiBo, NaBo and KLC, the optimal relative importance of the size of an aircraft for AS?” When we know this optimal relative importance, AS can minimize the PDM by steering priority setting as much as possible within the margins set by OCC.
The current two measurements of the PDM effect, which do not even differ significantly, are not enough to find this optimum. I was not able to run simulations in order to find this optimum, but an experiment to do so would be based on trial and error with different factors of the relative priority chosen in the basic run. It is possible to plot the resulting PDM as a function of this factor. Assuming that the optimum exists, there are three possible scenarios (see Figure 7.29). Especially the first scenario is interesting since it includes the possibility of a negative factor: the optimal relative importance is then a negative number which means that smaller aircrafts should actually have priority over larger aircrafts. The probability of this possibility cannot be estimated with the available data, but the option is serious enough to devote some additional research to priority setting and the possible effects on the PDM allocation of AS processes. An example of a possible outcome is given in Figure 7.30.
PDM effect of doubling relative importance of aircraft size
3643 3525
1051 1285 KLC NaBo WiBo 1604 1583
869 775
Original priority setting from basic run Doubled relative importance of aircraft size
Figure 7.28: PDM effects of doubling the relative importance of aircraft size in priority setting
THESIS PAUL ADRIAANSEN –APRIL 2009 89 Scenario 1 Scenario 2 Scenario 3
PDM PDM PDM
3525 3643 3525 3643 3525 3643
1 2 factor 1 2 factor 1 2 factor Figure 7.29: Three scenarios in finding the optimal relative importance of aircraft size
PDM as a function of relative importance of aircraft size
3470 3350 3420 3525 3643
KLC NaBo WiBo
Factor -2, double priority Factor -1, priority for Factor 0, no importance of Factor 1, basic run Factor 2, doubling for smaller aircrafts smaller aircrafts aircraft size
0.8 0.4 0.2 0.4 -0.2 -0.4 -0.4
-0.8 Relative importance of WiBo over NaBo Relative importance of NaBo over KLC Figure 7.30: Fictive example of PDM (upper diagram) as a function of relative importance of aircraft size (lower diagram)
THESIS PAUL ADRIAANSEN –APRIL 2009 90 CHAPTER VIII
CONCLUSIONS AND RECOMMENDATIONS
This chapter tries to answer the questions raised in Chapter 1. It starts with a summary of the simulation model and the findings from the runs and results. The fourth section summarizes the final conclusions and recommendations about punctuality in the OPC. The last two sections give suggestions for further research and operational improvements.
8.1 The Picasso simulation model
The Picasso simulation model was build to create a tool that is able to forecast punctuality of departing aircrafts. Picasso simulates the platform operation and focuses at the AS processes within the operation. When an aircraft is delayed, the delay is measured in PassengerDelayMinutes and Picasso assigns fair shares of the delay to the responsible AS and non-AS processes. In this way, bottlenecks in the operation are identified. Picasso uses OPiuM for the simulation of the timetable and the OPC is used to determine the resource capacity levels. This introduces the central idea of the Picasso model in relation to the OPC: In the OPC, the capacity needed to perform a deterministic timetable punctually with deterministic norms is minimized. In Picasso, the total departure delay is minimized by efficiently performing a stochastic timetable with stochastic processes with the available capacities based on the OPC.
It will be clear that for evaluating a timetable with Picasso, a full OPC trajectory must be executed. For this thesis, SPL/ST only had the capacity of performing one OPC as the input for Picasso. The evaluation of the performance of multiple timetables, which was one of the goals of this thesis, was therefore pushed into the background. Since it would not be possible to compare different timetables on their performance, I did not quantitatively research the different properties of a timetable that are relevant for its performance on punctuality.
Instead of the evaluation of different timetables, Picasso was used to determine the effects on punctuality and bottlenecks of all kinds of operational scenarios. The conclusions from these simulation experiments were used to answer the question whether some form of punctuality forecasting should be implemented in the OPC trajectory.
Before these conclusions can be summarized, it is important to review some comments on the limitations of Picasso. The two main limitations of Picasso have a causal relation:
THESIS PAUL ADRIAANSEN –JANUARY 2009 In the construction of Picasso, a lot of assumptions were made. Some of these assumptions are just not realistic and it is unknown to which extent these assumptions influence the results. The credibility of the Picasso output is questionable since the main output variable (total PDM) is far from realistic.
Although the unrealistic assumptions can seriously harm a simulation study (“rubbish in, rubbish out”), understanding of how these assumptions influence your outcome makes a positive contribution to the value of the results. Therefore it is interesting to look at some possible explanations for the large difference between the Picasso results and expectations about the realistic numbers based on the OCC PAT report: First of all, the Picasso model focuses especially on AS processes, which justifies the enlargement of problems, interdependencies and delays within these processes. Furthermore, the other processes that could cause delays are not modeled or modeled very conservatively. This leads to the “iceberg”-argument explained in Section 7.3: a larger part of the potential AS delays becomes visible since other processes are less prominently present. It is probable that the process durations, which were drawn from Triangular distributions during the Picasso simulation, are too long. The data that was used for determining the distributions of process durations was biased in two ways: • In most data, time spend on waiting for preceding processes was included in the processing duration. I tried to repair this bias, but the size of it was unclear. • It is unknown to what extent the duration of a certain job is connected to the available ground time for this job. It can be expected that there exists some conditionality; if work pressure is low, the operator can take its time. When necessary the operator can speed up his work. The impact of this bias can be enormous. The processes are in reality much more flexible than they were modeled in Picasso. When necessary, jobs can be skipped or shortened in order to prevent delays. The dispatchers have much more knowledge, experience and creativity to prevent delays. Picasso is much less flexible since it uses standardized heuristics for job scheduling. The capacities Picasso uses are based on corrected workload schedules instead of shift schedules. Shift schedules have much more slack during off-peak hours that can be used to solve capacity problems due to shifted workload peaks.
8.2 Conclusions and recommendations on punctuality forecasting
This section starts with stating one of the most important conclusions of this thesis that was not mentioned earlier: Picasso shows it is possible to simulate the total platform process on the smallest possible entity level: aircrafts, jobs and individual operators. Some numbers on the size and scope of Picasso: Picasso can simulate 48 different combinations of the 16 available processes At peak moments, over 200 individual operators can work simultaneously and more than 700 jobs can be active In one run, up to 21,000 aircrafts can be handled, resulting in 1.6 million data points For the analysis of these data points 15 Excel files are needed with a joint size of more than 500MB It takes Java about 90 minutes to run an experiment of this size and it takes another 90 minutes to upload and analyze the data in Excel
Compared to the AS delay codes in the PAT report of OCC, the PDM numbers of Picasso are very high. But when we focus on the peaks in PDM during the day, we can draw some interesting conclusions: In the early morning (around 5:00) a lot of delay is caused by the slow start-up of the morning shifts. This whole problem can be solved by advancing the morning shifts by one hour. The second PDM peak in the morning (around 8:00) is probably caused by some inexplicable lack of capacity in some processes. The last peak of the day (in the evening around 18.00) can be explained by looking at the available ground time for the scheduled turnarounds. The aircrafts that are scheduled to
THESIS PAUL ADRIAANSEN –APRIL 2009 92 depart at the end of the peak have very short ground times, which means there is no flexibility to anticipate on problems.
So the solution for the last peak is equal to the solution for the early morning peak: do not plan the starting and ending times of shifts too tight around the scheduled peak. Due to all kinds of circumstances, the actual workload peak can be earlier or later than scheduled. So the recommendations of this section focus on the covering of workload peaks: Do not focus too much on the top of a peak when covering workload with capacity, the basis (or “bulk”) of the workload is evenly important and much more predictable. It is very difficult to forecast the exact location of the actual workload peak, so try to take some margin (of say half an hour) in the planned capacity on both sides of the scheduled peak. Especially at the start of the first peak and the end of the last peak this can be very important. To facilitate an efficient peak covering, it would be helpful to have: • More shifts (i.e. more starting moments of shifts during the day) • Shorter shifts (the length of a shift can than cover for instance exactly two workload peaks) • More flexibility on the day of operation (the possibility to extend or shorten a shift or break shifts in two parts)
8.3 Conclusions and recommendations on bottleneck identification
In Chapter 4 a method was derived to allocate the total PDM among the responsible processes in a fair way. The half an hour stack charts (Figure 7.4 for example) show us which processes are responsible in the different PDM peaks. Although both UPM and OCC have different categories of processes for measuring the relative shares of AS delay causes, we can see that the PDM allocation of Picasso is comparable with these results. The main recommendation that can be derived from these results is that more attention should be given to the process of security check (both Asito and Klüh). The process is very vulnerable to late crew attendance. Since the job duration itself is quite short, the delays from waiting can be a serious problem for the available capacity. As mentioned earlier, it would be good idea to have some form of contact with the crew centre about the exact arrival moment of the crew at the aircrafts.
One of the possibly non-realistic assumptions following from the focus on AS processes is the implicit assumption that waiting time of some AS process is always caused by some other AS process. In reality, there are many more processes that conflict with the ground time for AS processes. But when we try to find interdependencies between processes, this AS focus is very convenient. Two important positive correlations were found: Problems at fuelhydrant lead to problems at pushback. A possible solution may be to change the priority settings in situations where fuelhydrant has a lack of capacity. It might help to give priority to the aircrafts which normally have some slack between the two processes (all the WiBo turnaround actions fall in this category, as well as the 739 fuels). The other types would already face a delay, by extending this delay for some aircrafts, pushback is given some room to breathe and recover. Problems at kluhcleaning lead to problems at kluhcheck. Between these processes hardly ever slack exists. The only solution I can think of would be: foresee the problems 30 to 40 minutes in advance and try to create some extra capacity. At least avoid going to aircrafts that are still being cleaned, since this can cost a lot of time and thus leads to scarcity of kluhcheck capacity.
8.4 Punctuality in the OPC
This section presents the final answer to the main research goals as stated in the introduction: 1. to evaluate definitions of punctuality in the context of KLM Aircraft Services, 2. to perform quantitative analysis on the measurement and forecasting of punctuality and the identification of bottlenecks in the platform operation, and
THESIS PAUL ADRIAANSEN –APRIL 2009 93 3. to find a way in which any form of punctuality forecasting can be included in the operational check.
The first and second question are already answered in the last subsections, the third question aims at the principle of evaluating a timetable on its expected punctuality performance. Before an answer to this question is formulated, conclusions and recommendations concerning Picasso and the OPC are discussed.
8.4.1 Conclusions and recommendations
Running Picasso in addition to the feasibility check in PlanControl can be a valuable addition to the OPC. To implement Picasso successfully in the OPC, two conditions should be met: 1. Try to model the platform operation as detailed as possible and do not forget to include other GS processes that are relevant for the AS operation 2. Accept the limitations of Picasso, especially when it comes to forecasting the absolute value of PassengerDelayMinutes
The value of Picasso (just as the value of the OPC itself) lies in comparing different timetables to each other. For every timetable Picasso can produce a full report containing all details on PDM, number of delays, PDM allocation to responsible processes, PDM distribution over the days, relative proportions of PDM by aircraft type, etc., etc. Comparing these reports to each other provides data on the possible improvements of new versions of the timetable. Since I did not have the disposal of different timetables with corresponding OPC capacity levels, I was not able to prove that it actually works in practice. But the results from other experiments in Picasso convince me that it does.
As mentioned earlier, it is important to remind that all the uncertainties that remain present in the system are blurring the view on the real value of measuring punctuality in the OPC. Although the absolute values of the punctuality measurement are subject to these uncertainties to a large extent, the relative results from the punctuality analysis are not. Compared to the feasibility analysis that does provide realistic absolute values, the punctuality analysis in Picasso is just much more sensitive to the uncertainties in the system. There are two reasons for this: 1. In the simulation of the platform operation, much more variables are taken into account than there are in the feasibility check of the OPC. This is not only because of its stochastic nature, but also because of the dependence relation with other GS processes, or even processes or events outside GS. 2. When it comes to punctuality, successes are achieved at the day of operation. Compared to the deterministic feasibility check, a much larger part of the eventual performance is subject to events and decisions in the day-to-day operation: The quality of the EBD communication is extremely important for the efficiency of the operation. Efficient dispatching is key. Dispatchers should consult each other, in order to avoid waiting time. Peaks in the workload can be handled by looking ahead for a few hours (CHIP is taking care of this). Ask operators for flexibility, commitment and speed in the 5 to 10% of the cases where it is going to be close. Give critical processes (depending on the moment) priority in the allocation of ground time (function of the new DMA). Be willing to adjust the towing schedule for this. Set priorities on GS level: avoid the unnecessary handling of delayed aircrafts during workload peaks.
8.4.2 Recommendations for the OPC
The recommendation to implement Picasso in the OPC should be completed with the notion that the software tool as it is built now will not be useful. Since I am not a Java programmer, the current Picasso tool is inefficient, not user-friendly and laborious to use and probably still contains some errors. Picasso has been built as a prototype of a simulation model that should be developed in a
THESIS PAUL ADRIAANSEN –APRIL 2009 94 more professional environment (AMS/QO for example). So when implementing Picasso in the OPC, the following advice can be useful: Build a totally new properly programmed Picasso, and integrate the output analyzer in the Java program Take all the GS processes into account (so logically SPL/ST would then be the owner of the system) Build in all kinds of user friendly interfaces that allow for various different scenario analyses
Furthermore, since the OPC provides the capacity levels that are the input for Picasso, the quality of Picasso totally depends on the quality of the OPC. Therefore it is interesting to look at some possible improvements of the OPC. One insight that to my opinion is the most important challenge for the OPC is to loosen the focus on the tops of workload peaks. PlanControl is programmed to cover the peaks it found as efficient as possible. The problems with this were already mentioned a few times: in practice, peaks can shift back and forth in time, and too tight workload covering can cause serious delays. Therefore PlanControl is actually giving a false feeling of safety: having peaks covered according to PlanControl is no guarantee at all that you will have enough capacities to avoid delays. Capacities should be based more on the bulk of workload, since the position of that bulk of workload is much more certain. The way to do this is to look at the distribution of available ground times for scheduled turnarounds.
Other suggestions for improvement of the OPC are based on observations outside Picasso: The check week is a difficulty in the OPC. It is chosen quite arbitrarily and especially properties of other timetables that are less obvious to lead to difficulties or delays are easily overlooked. It would be better to have a system that is able to review all weeks on feasibility and punctuality The assumptions underlying the OPC should be realistic. The towing criteria for instance are not robust enough in PlanControl, although their influence on the available ground time is enormous. It is not clear which norms are used for which purpose. Concerning norms, there should be a clear choice for which durations to include and which not (for instance: processing, driving, loading and unloading at home station, refueling of vehicles, administration, etc.). Whatever choice is made, it is important to implement it consequentially for all processes. Furthermore, buffers should not be included in norms when these norms are used for analytical purposes.
8.4.3 Evaluating a timetable
One of the goals of this thesis was to find the most important properties of a timetable that influence punctuality. The idea was to quantify the effect of these properties on punctuality for each and every process, in order to calculate “mark-ups” for the capacity levels that could cancel these delays. This question is in fact still open, although I think that most of the relevant timetable properties were touched in this thesis. The main reason that it was not possible to quantify the effects of different properties was the impossibility to compare different timetables. When this would have been a possibility, the next barriers would have been the unrealistic PDM levels for AS processes (far too high) and high level of uncertainty due to the volatility of process durations.
To find mark-ups for the capacities of processes during the day (mainly peaks), it would be better to use a model that looks more like the current OPC: calculate capacity levels at a 100% punctual performance (the timetable can still be stochastic) instead of calculating delays as the result of low capacity (based on OPC). A comparable model is currently in use at the Bax department of KLM. A possible model could look like this: 1. Calculate the available ground time, based on ATA (simulated by OPiuM for example) and STD. This could be less than the minimum required ground time. 2. Define for every process to what extent it is bounded to the ATA and/or the STD (for example pushback is less flexible than cleaning). 3. Cut the total available ground time into time slots (from EST to LET) for every process. This can be based on AIS for example, but keep in mind the assumptions of step 2. 4. Spread the total workload for a certain process over the available time slot: the weight of the workload at a certain point in time equals the norm duration divided by the length of the
THESIS PAUL ADRIAANSEN –APRIL 2009 95 available time slot. This weight will be less than one when slack exists and more than one when the aircraft is late. 5. All kinds of mark-ups can now be defined in order to assign extra weight and capacity slack to all kinds of difficulties in the operations, for example: Give a workload mark-up for turnarounds shorter than 105% of the minimal turnaround time (or think if some stepwise mark-up function of the available ground time factor) Give extra mark-ups for the water and toilet jobs, since they face the uncertainty of the exact arrival moment of the aircraft Assign extra workload when the total number of jobs starting or ending within a certain period is more than some threshold value Give a mark-up for periods in which many aircrafts of a certain type are scheduled Assign a mark-down to processes that can be performed on the buffer Assign a mark-down to processes that can be skipped when it is busy Etc.
The basic idea of this model is: simulate the available ground time for every aircraft during the day and try to fit in an AIS-based turnaround scheduled as realistically as possible. Some of the advantages of this model are: It is easy to build and it can be programmed in Excel The results are directly interpretable It is easy to play with the different mark-ups: adjust the mark-ups based on platform observations or gut feeling The flexibility of processes is included in the workload (this is quite beneficial) It is easy to simulate the arrivals (for example based on OPiuM or ST data) and give a Confidence Interval for the workload at every minute of the day The model is much more concerned with the “bulk” of the workload (by looking at the available ground time) and not only the peaks
However, there are also some disadvantages that should be taken into account: It is still very difficult to implement a realistic towing schedule There is no longer a form of scheduling in the workload calculation (this is in fact a degeneration compared to the current OPC with PlanControl) The model is very sensitive for errors in the AIS: one wrongly calculated norm can seriously harm the model. The inclusion of buffers becomes a very delicate job, since buffers influence the AIS to a large extent. Assumptions about norms and buffers should be made with great care and be implemented very consistently.
8.5 Recommendations for further research
This section presents some suggestions for further research. The first suggestions focus on possible improvements of OPiuM. Then some recommendations about improving Picasso follow. Finally, some ideas about ground time distributions are presented.
8.5.1 Improvements of OPiuM for Picasso
There exist of course numerous possibilities to improve OPiuM for Picasso in order to get more useful and realistic results. When a new version of Picasso would be built, it would be interesting to improve: 1. The interaction with OPiuM. Currently, OPiuM feeds Picasso with input about flights. It might be interesting to look what happens when the departure of an aircraft in Picasso would be communicated back to OPiuM. OPiuM can then use Picasso to simulate BB2, BB4 and BB2/4 much more realistic. This emphasizes the need to include all turnaround processes (Bax, Pax, etc.) in the Picasso simulation; otherwise this option would make no sense.
THESIS PAUL ADRIAANSEN –APRIL 2009 96 2. The towing decisions in OPiuM: Although OPiuM uses the same towing rules as PlanControl, it would be better to have some GatePlanning tool in OPiuM for Picasso. The towing decisions would then be much more realistic. 3. The possibility of running scenarios in OPiuM. Currently, OPiuM is a black box for Picasso users. It would be a good idea to create the possibility of adjusting some parameters in OPiuM: Running a deterministic timetable instead of using distributions: it might be interesting to see what happens in Picasso (since the influence of early or late arrivals disappears) Running experiments on the towing schedule in OPiuM for Picasso. It may even be possible to model the towing decisions and operation as a real process, like the processes in Picasso Adding flights of other airlines to OPiuM. Air France, NorthWest Airlines, Martinair and Transavia would be logic choices to add. However, these airlines do not have all their service contracts with KLM Aircraft Services. It would therefore be necessary to model other types of operators (competitors of AS) that can partially service these aircrafts (Menzies handling, British Petroleum fuelling, etc.).
8.5.2 Improvements of Picasso
Apart from the improvements mentioned above, a lot of other things could improve the working and realism of Picasso: 1. Model capacities shift wise instead of pile wise. Currently, capacities are modeled as part of a pile. This means that individual operators are not following a shift pattern: four, six or eight hours of work, plus a half hour break in between. Picasso would be much more realistic and informative when all kinds of different scenarios could be run with varying shift starts, shift durations, CAO rules, flexible breaks, etc. It would also be a good idea to model cleaning teams on the level of individual operators (instead of teams) to create the possibility of redividing teams. 2. Model processes more detailed and more flexible. In the current version of Picasso, the assumptions underlying the processes are not very detailed. It would not be too hard to model these processes more detailed. This would include the possibilities that HCC has to solve problems: shorten jobs, skip certain jobs, double capacities for certain jobs, prefuel anticipation, etc. It is important however to keep these details in line with the level of detail in the capacity planning of PlanControl. In the end, the OPC is still half a year in advance, so too much detail is pointless. 3. More precise statistical analysis of input. Especially the job duration distributions are susceptible for errors. Things to keep in mind: What is the best distribution to fit a job duration (obviously, a triangular distribution is probably a bad guess)? What are the minimum and maximum durations that we want to apply to the distribution? How do we exclude all kinds of waiting and idle time from the ReportControl data? Are job durations conditional to the available ground time? Is it possible to speed up a job, just by telling an operator that he needs to speed up the job? If so, would it make sense to model it this way? We could, for instance, give the HCC a “turbo-button” that can be pushed once in every ten jobs. 4. Investigate the priority setting options for AS. In Section 7.4.3 the suggestion was made that giving larger aircrafts priority over small aircrafts, may not be beneficial for the efficient use of resources within AS. 5. Research the possibility to base the “fairness principle” that was used for dividing PDM among responsible departments on existing concepts from cooperative game theory. One of the main problems in this exercise will be the time component: the level of responsibility of a certain process is changing over time, which means it is difficult to “take a photo” of the situation and assign values based on that photo.
THESIS PAUL ADRIAANSEN –APRIL 2009 97 8.5.3 Ground time distributions
One of the main conclusions of this thesis is that the OPC should focus more on ground time distribution. However, this topic is not yet researched very deeply. Some issues that should be addressed further: 1. Investigating the ground time distribution over the day. In Section 7.4.1 an introduction was presented by plotting the number of flights in a certain category of available ground time to the evolvement of time during the day. It is of course interesting to compare these figures with the actual measured ground time in ReportControl. 2. The efficiency of the towing schedule. An analysis comparable to the first one: analyze how well the towing department performed their job, by comparing the scheduled ground time durations with the actual towing jobs. Not only the AOP is important, towing an aircraft too early can frustrate jobs planned on the buffer. 3. CHIP can provide data that allows comparing the actual capacity and actual workload to the originally scheduled capacity and workload from the OPC. It might be interesting to see which processes vary the most, and at what times during the day large differences exist. It would also be nice to run an OPC afterwards: pick a week with a lot of problems and try to find out whether the problems were caused by differences between scheduled and actual capacity. You might find that capacity levels were not the problem, but job durations or waiting time caused the trouble.
8.6 Other recommendations
The following recommendations are only indirectly connected to my project. They could provide some guidance in improving the HCC or AS operations.
When investigating the norm durations of processes, the following should be considered: All interactions with other processes should be “switched off” when measuring a norm Break up a process in parts as detailed as possible, measure all the parts independently Also measure the sideline activities as driving, refilling, unloading and refueling vehicles. Buffers for waiting time, problems in the operation, etc. should only be added afterwards and with a reason. Of course it will be necessary to include all kinds of buffers, but make sure that every buffer is given a description about its origin and nature. This can be very helpful when doing research on job durations. In relation to the previous point: Norms should be regarded as a minimum duration plus a number of buffers instead of an average duration including the buffers. Be careful with taking averages: especially when it comes to buffers. Taking an average over different durations, including outliers, is usually not the best way to deduct norms. Look at medians and percentiles instead and use histograms to investigate the likelihood of norm durations and buffers. It might be helpful to use different kinds of norms (handling norms, planning norms, etc.) for different purposes. However, it should always be clear and logical which buffers are included and which are not. When political arguments play a role in the decision about norms (whether they come from management or labor unions), label the differences between the statistical norm and the “compromise norm” as a “political buffer”. This can be very helpful in later research projects.
A second recommendation concerns advice for efficient dispatching. Most of the ideas were already introduced in Section 8.4.1; the central idea of efficient dispatching is: start a job as soon it is possible to start it, but anticipate on the available ground time of an aircraft. Decouple processes of aircrafts that have plenty of ground time but anticipate on speeding up jobs when aircrafts are late. That is also the reason that the quality of EBD setting is extremely important: EBD should be set as realistic as possible. When an EBD is no longer realistic, it should be adjusted, but avoid “floating EBD’s” (EBD’s that are adjusted with five minutes at a time, every five minutes). The communication of EBD’s should be quick and clear to all users The HCC should use the EBD setting to prioritize between aircrafts in a consistent way.
THESIS PAUL ADRIAANSEN –APRIL 2009 98 REFERENCES
Bain, L.J. and Engelhardt, M. (1992). Introduction to Probability and Mathematical Statistics (second edition). Pacific Grove: Duxbury.
Boom, L. van den (2003). Simulation Tool Insight in Performance Turnaround Boeing 737. Master thesis Faculteit der Ecnomische Wetenschappen en Econometrie, Universiteit van Amsterdam, The Netherlands.
Eckel, B. (2006). Thinking in Java (fourth edition). New Jersey: Prentice Hall.
Jacobs, P.H.M., Mulder, J.B.P. and Verbraeck, A. (2005). Flight Scheduling at KLM. Paper presented to the 2005 Winter Simulation Conference.
Jacobs, P.H.M., Verbraeck, A. and Houten, S.P. van (2006). Mastering D-SOL: A Java based suite for Simulation. Delft: Delft University of Technology.
Kotz, S. and Dorp, J.R. van (2004). Beyond Beta: Other Continuous Families of Distributions with Bounded Support and Applications. Singapore: World Scientific.
Lang, N.A., Jacobs, P.H.M. and Verbraek, A. (2003). Distributed open simulation model development with DSOL services. Proceedings of the 15th European Simulation Symposium, Delft
Law, A.M. and Kelton, W.D. (2000). Simulation Modeling and Analysis (third edition). Boston: Mc Graw Hill.
Schiebaan, H. (2002). Integral Fleet Service Control. Master thesis Stan Ackermans Institute, Eindhoven University of Technology, The Netherlands.
Wu, C-L. and Caves, R. (2004). Modelling and Simulation of Aircraft Turnaround Operations at Airports. Transportation Planning and Technology, 27 (1), 25-46.
Yunita, T. (2008). Managing Effective and Efficient Aircraft Flows. Master thesis Eindhoven University of Technology, The Netherlands.
THESIS PAUL ADRIAANSEN –JANUARY 2009 APPENDIX 1.A
ABBREVIATIONS AND TERMINOLOGY
List of abbreviations and terms (logically ordered, for alphabetical list, see next page):
KLM Koninklijke Luchtvaart Maatschappij (Royal Dutch Airlines) KLC KLM Cityhopper GS Ground Services AS Aircraft Services SPL/K3 Departmental KLM code for Operational Support AS SPL/ST Departmental KLM code for Capacity Planning GS SPL/QO Departmental KLM code for Decision Support KE Fuel department KF Aqua department KG Management department for Catering (KCS) and Cleaning (Klüh and Asito) KN Towing department KCS KLM Catering Services Asito Cleaning company for WiBo aircrafts Klüh Cleaning company for NaBo and KLC aircrafts
E&M Engineering & Maintenance Pax Passenger services Bax Baggage services
TA Turnaround ARR Arrival DEPH Departure from hangar DEPB Departure from buffer
AAS Amsterdam Airport Schiphol ATC Air Traffic Control IATA International Air Transport Association SPL Old IATA code for Schiphol, now location name AMS IATA code for Amsterdam Airport Schiphol CDG IATA code for Paris Charles de Gaulle Airport
NaBo / NB Narrow Body aircraft WiBo / WB Wide Body aircraft
THESIS PAUL ADRIAANSEN –JANUARY 2009 EUR European flight destination ICA Intercontinental flight destination
OCC Operations Control Centre HCC Hub Control Centre VOP Aircraft Positioning Location (Vliegtuig Opstel Plaats) DHM Duty Hub Manager DAM Duty Area Manager DMA Duty Manager Aircraft
STA Scheduled Time of Arrival STD Scheduled Time of Departure SBA Scheduled Block Arrival SBD Scheduled Block Departure ETA Estimated Time of Arrival ETD Estimated Time of Departure EBA Estimated Block Arrival EBD Estimated Block Departure ATA Actual Time of Arrival ATD Actual Time of Departure ABA Actual Block Arrival ABD Actual Block Departure
BB Building Block ADO Any Door Open ADC All Doors Closed AOP Aircraft on Position
OPiuM Operational Performance Management tool Picasso Name of simulation model developed for this project CHIP Tool for planning of and communication with operators on the platform PlanControl Software for efficient workload scheduling GatePlanning Software for efficient gate planning ReportControl Database containing details about AS handling
AIS Aircraft Handling Guide (Afhandelings Instructie Schiphol) OPC Operational Check S07 Timetable for the summer (April to October) of 2007
CLA Collective Labour Agreement CAO Collectieve Arbeidsovereenkomst
UPM Unit Performance Meeting GPM Ground Performance Meeting HPM Hub Performance Meeting PAT Performance Analysis Tool (from OCC)
PDM PassengerDelayMinutes
RNG Random Number Generator CRN Common Random Numbers PDF Probability Density Function CDF Cummulative Density Function CI Confidence Interval
THESIS PAUL ADRIAANSEN –APRIL 2009 101 List of abbreviations and terms (alphabetically ordered):
AAS Amsterdam Airport Schiphol ABA Actual Block Arrival ABD Actual Block Departure ADC All Doors Closed ADO Any Door Open AIS Aircraft Handling Guide (Afhandelings Instructie Schiphol) AMS IATA code for Amsterdam Airport Schiphol AOP Aircraft on Position ARR Arrival AS Aircraft Services Asito Cleaning company for WiBo aircrafts ATA Actual Time of Arrival ATC Air Traffic Control ATD Actual Time of Departure
Bax Baggage services BB Building Block
CAO Collectieve Arbeidsovereenkomst CDF Cummulative Density Function CDG IATA code for Paris Charles de Gaulle Airport CHIP Tool for planning of and communication with operators on the platform CI Confidence Interval CLA Collective Labour Agreement CRN Common Random Numbers
DAM Duty Area Manager DEPB Departure from buffer DEPH Departure from hangar DHM Duty Hub Manager DMA Duty Manager Aircraft
E&M Engineering & Maintenance EBA Estimated Block Arrival EBD Estimated Block Departure ETA Estimated Time of Arrival ETD Estimated Time of Departure EUR European flight destination
GatePlanning Software for efficient gate planning GPM Ground Performance Meeting GS Ground Services
HCC Hub Control Centre HPM Hub Performance Meeting
IATA International Air Transport Association ICA Intercontinental flight destination
KCS KLM Catering Services KE Fuel department KF Aqua department KG Management department for Catering (KCS) and Cleaning (Klüh and Asito) KLC KLM Cityhopper KLM Koninklijke Luchtvaart Maatschappij (Royal Dutch Airlines) Klüh Cleaning company for NaBo and KLC aircrafts KN Towing department
THESIS PAUL ADRIAANSEN –APRIL 2009 102 NaBo / NB Narrow Body aircraft
OCC Operations Control Centre OPC Operational Check OPiuM Operational Performance Management tool
PAT Performance Analysis Tool (from OCC) Pax Passenger services PDF Probability Density Function PDM PassengerDelayMinutes Picasso Name of simulation model developed for this project PlanControl Software for efficient workload scheduling
ReportControl Database containing details about AS handling RNG Random Number Generator
S07 Timetable for the summer (April to October) of 2007 SBA Scheduled Block Arrival SBD Scheduled Block Departure SPL Old IATA code for Schiphol, now location name SPL/K3 Departmental KLM code for Operational Support AS SPL/ST Departmental KLM code for Capacity Planning GS SPL/QO Departmental KLM code for Decision Support STA Scheduled Time of Arrival STD Scheduled Time of Departure
TA Turnaround
UPM Unit Performance Meeting
VOP Aircraft Positioning Location (Vliegtuig Opstel Plaats)
WiBo / WB Wide Body aircraft
THESIS PAUL ADRIAANSEN –APRIL 2009 103 APPENDIX 2.A
OVERVIEW OF AS PROCESSES
In this appendix an overview of all AS processes is presented. These processes are grouped per department, which means that in every subsection several processes are described. Per process the most important properties are described and in addition some planning issues and dilemmas are introduced. The last subsection describes some processes outside Aircraft Services that are important because of their interactions with AS processes.
Towing department
The towing department is responsible for two jobs: transporting empty aircrafts throughout Schiphol (from/to gates, buffers, hangars etc.) and pushing loaded aircrafts away from gates. Towing jobs are performed with two operators; a pushback can be done by a single operator. The preparation of a towing or pushback (rigging the nose wheel and performing some technical assistance) takes about 5 to 10 minutes and can already start while other processes are going on. Moving the aircraft takes another 5 to 10 minutes and can only start after all doors and shutters are closed and airport authorities gave permission to enter taxi lanes. Since it is the last process performed before an aircraft leaves, especially the pushback process is bound to the scheduled or estimated time of departure. Towing an aircraft is a process a bit more flexible. The department code for the Towing department is “KN”.
Fuel department
Apart from performing standard refuels on aircrafts, the fuel department is responsible for three other processes: prefueling, defueling and extra fuels. Due to safety regulations, a standard refuel can only be started after the aircraft is debarred, but boarding while refueling is unfinished is allowed. So a fuel job must be ended before closing all doors. Prefueling is used for two reasons: large aircrafts going to far destinations need more fuel than can be loaded in the standard ground time for a departure and prefuels are also used to anticipate on busy periods during the day. Prefuels are generally only executed on aircrafts for Intercontinental (ICA) destinations and are performed in ground time after arrival.
An important restriction on the starting time of the fuel job is the “final fuel information”. Until 40 minutes before departure, the cockpit crew can change the fuel amount, depending on flight plan, weather conditions or loading criteria. In general, the fuel operator tries to be around 80% percent of the ordered amount of fuel, which of course is already adjusted to the destination, when the “final fuel” amount is confirmed. When the final fuel information is available he can then simply adjust the
THESIS PAUL ADRIAANSEN –APRIL 2009 104 remaining 20% to the wishes of the cockpit crew. When the fuel job is already ended when the fuel amount changes, this results in an extra fuel or defuel; especially defuels are complicated.
Two forms of equipment can be used for fuelling: the Tank truck and the Hydrant cart. Most gate positions at Schiphol contain fuel-wells (called Hydrant positions) that are connected to a subterranean pump system. Hydrant carts provide the pipe to connect these wells with the aircraft, while tank trucks carry fuel themselves. ICA flights are commonly fuelled with a Hydrant cart, while EUR flights can be fuelled in both ways. Flights leaving from the B-platform (mostly KLC) or Cargo positions always need tank trucks (non-hydrant fuelling) since there are no fuel-wells available. The department code for the Fuel department is “KE”.
Aqua Services
This department has several major responsibilities: providing (drinking)water to aircrafts, empty and clean toilet basins, providing anti- and de-icing when necessary and providing different types of flexible tasks, of which providing jet starters, coolers and heaters are the most common (flex-tasks).
In principle, water and toilet tasks are performed after every flight, but in busy periods they are sometimes slipped for the smaller aircrafts. While a toilet task is quite standard, a water task can have several actions: draining after an arrival, filling before a departure, and these two combined (a “water change”) for a turnaround. Furthermore, all KLM aircrafts (not KLM Cityhopper) are provided with drinking water, which brings extra restrictions: aircrafts that have their water and toilet tap points on the same side of the aircraft (all Boeings) cannot receive drinking water and toilet service at the same time, because of hygiene regulation.
De-icing is an enormous operation, but is concentrated on a few days per year, when temperatures go below two degrees Celsius. The de-icing operation is very disturbing for the timetable since there are no time frames available for this operation: it leads to delays immediately. The flex-tasks are a minor part of the aqua services department, and since they operate quite independently of all other processes, I leave them out of this study. The department code for the Aqua department is “KF”.
Cleaning and Security check
KLM has no cleaning department, which means they work with contract companies: Klüh and Asito, two large facility service companies. Asito cleans the large aircrafts (Wide Bodies (WiBo), mostly used for intercontinental (ICA) flights) and Klüh the smaller ones (Narrow Bodies (NaBo), mostly Boeing 737’s for European (EUR) destinations and KLM Cityhopper (KLC) aircrafts, mostly Fokkers). Apart from cleaning, both companies also provide a security check, which is an obligatory operation before aircrafts can take off. This check serves three purposes: the cleaning operation is assessed, some safety checks are performed (concerning life jackets etc.) and the aircraft is searched for unsecured objects (explosives, weapons, etc.). After the security check, the aircraft is secured for departure. No one can enter the aircraft without permission until the cabin crew (purser) has taken the responsibility over the aircraft, this is called the “security handshake”.
Normally, an aircraft is cleaned just after deboarding and the aircraft is checked just before the cabin crew boards. For WiBo aircrafts (Asito tasks) there can be hours in between (for example when an aircraft goes to a buffer position), for NaBo turnarounds (Klüh tasks) the security check is often performed “walking right behind” the cleaning team, since not much time is available. So, the check team can already start when cleaning (and sometimes catering) is still on board. After cleaning has left, they only need another minute for their “handshake” with the cabin crew.
Catering and board supply
KLM Catering Services (KCS) used to be a department of KLM, but now operates as an independent company. So KLM has a contract with KCS to cater all their aircrafts and for the ICA flights KCS also delivers the board supply: blankets, cushions, tax free goods, newspapers, etc. These board supplies are distributed within the aircraft by the cleaning teams of Asito. The amount of board supplies for
THESIS PAUL ADRIAANSEN –APRIL 2009 105 EUR destinations is much less and doesn’t need to be distributed within the aircraft. Therefore, every Klüh cleaning team brings the board supply themselves.
The catering operation consists of unloading the empty trolleys and loading the full ones. Preferably these actions are performed at the same time, because this saves time. The problem for especially ICA flights (which receive a lot more catering supplies) is that the catering goods may only enter the aircraft three hours before leaving (for food safety regulations). Therefore unloading and loading is often done separately.
Another planning issue concerns the Asito board supply distribution. Since used board supplies are collected during cleaning and need to be handed over to KCS and new board supplies are brought by KCS and thereafter distributed by Asito, both companies have to communicate their schedules. In the best case they arrive at an aircraft together: used board supplies are collected, KCS takes them away, and Asito receives new board supplies directly and distributes them. When this is not possible, KCS and Asito need to wait for each other and sometimes even return afterwards.
Processes outside Aircraft Services
There are three main groups of processes outside the AS departments: passage services (pax), baggage services (bax) and technical services. Since the focus of this study lies within AS, these processes are only touched briefly.
Passage Services is concerned with the flows of passengers on the airport. The boarding and deboarding processes, where they meet Aircraft Services, are only minor operations in their portfolio. Boarding takes about three to four times longer than deboarding, since passengers need to look for their seats. Deboarding can start when the first door is opened, boarding can start when the cabin crew is on board and the cleaning teams, security staff, catering teams and aqua services are finished. Passage services is often confronted with late passengers, exceeding hand luggage or other problems, which often leads to short delays.
Baggage Services are divided in two sections: the baggage cellar operations where all baggage is collected and baggage carts are filled and the Aircraft Turnaround Services, which is responsible for (un)loading the aircrafts. Also the (un)loading of cargo is part of their operation. The baggage service department is able to work independently of other departments, but of course the loading of the aircraft can only start after all baggage is collected and the carts are composed. Due to security rules, baggage always needs to fly with the passenger, which means that baggage of a no-show passenger needs to be off-loaded. This often leads to delays.
Technical services mainly concern Line Maintenance, which is unplanned technical service on an aircraft, requested for by the cockpit crew. Normally this is performed within the scheduled ground time, but sometimes E&M (the department of Engineering and Maintenance) gives no permission to fly before some technical problem is solved. Technical problems do not occur very often, but when they do, delays can be very long.
THESIS PAUL ADRIAANSEN –APRIL 2009 106 APPENDIX 2.B
EXAMPLE OF AIS: TURNAROUND OF 737-400
On the next page the AIS scheme for the turnaround of a Boeing 737-400 is presented. Translation of the most important terms:
Afhandelings instructie Handling instruction Afhandelingsnormen Handling norms Normtijden Norm times / durations Positioneren Positioning Wisselen Changing Verwijderen Removing Noodzakelijke tijd Necessary time Extra tijd Extra time (slack) Schuifnorm Flexible norm (slack) Inspannen Rigging
THESIS PAUL ADRIAANSEN –APRIL 2009 107 Confidential
THESIS PAUL ADRIAANSEN –APRIL 2009 108 APPENDIX 2.C
CONTROL OF OPERATIONS
In this appendix we mainly focus on the organizational structure of operation management. We introduce several operational layers and link this to responsibility for platform processes. We also take a brief look at CHIP, the IT system that is used to manage all platform processes of AS.
Operations Control Centre
The Operations Control Centre (OCC) is the highest entity in the KLM organization with responsibility about the day-to-day operation. The OCC controls all flights based on the building block principle. The OCC manages fleet availability and flight crew worldwide, and is the central point for communication with the ATC (Air Traffic Control), AAS (Amsterdam Airport Schiphol), HCC (Hub Control Centre, see Section 2.4.2) and all outstations. Their most important instrument in providing fleet availability is the “registration change”, explained below. They also communicate with Engineering & Maintenance about rescheduling or shortening maintenance tasks for specific aircrafts.
The registration of an aircraft is its “international license”, for Dutch aircrafts a five letter code, starting with “PH”. A registration change means changing the aircraft that is going to perform a certain flight. There exist two kinds of registration changes: within the own aircraft type, or with an aircraft of another type. The first change is easy, since only the aircraft changes. The second change is more difficult, since a cockpit crew can only fly one type, so the crew needs to be changed as well. In most cases, a registration change is not just a swap between two flights, but starts a whole series of changes. Registration changes can take place days before a flight, but also even after the original STD of a flight in case of technical problems. The longer a registration change is known in advance, the easier it is for departments within AS to anticipate.
Hub Control Centre
The Hub Control Centre (HCC) is the heart of all ground operations at Schiphol. The HCC controls the positioning of aircrafts and services for all KLM and KLC aircrafts at Schiphol. For its main partners (Air France, Martinair, Transavia, Northwest Airlines, and Kenya Airways) it also provides parts of these services. The head of the HCC is called the DHM (Duty Hub Manager) and he is assisted by several DAM’s (Duty Area Manager). The DHM communicates with the OCC about fleet availability, gate changes and priority settings in case of a lack of capacity.
THESIS PAUL ADRIAANSEN –APRIL 2009 109 The main functions of the HCC are: 1. VOP allocation: a VOP is an aircraft position; a gate or a buffer. VOP allocation includes planning gate positions, efficient buffer usage, managing the towing schedule and transporting aircrafts from or to hangars. 2. Passenger and baggage services: the part of passenger transport at the platforms (mainly by busses) and baggage (un)loading at aircrafts is managed by dispatchers of the HCC. This includes (small) cargo loads. 3. Dispatching V&VO (aircraft positioning and flight assistance): towing, pushback, flex-tasks and de-icing. These are the AS processes that are performed outside the ground time windows (with closed doors). 4. Dispatching GS (aircraft preparation): cleaning, catering, security check, water and toilet services and refueling. These are the normal AS processes that take place during a turnaround. 5. Keeping contact with OCC, AAS, KCS (the catering contractor), Klüh and Asito (the cleaning contractors), Team Leader Turnaround (TLO, "Team Leider Omdraai"), operators and their shift leaders.
Shift leaders are the “instructional” and “administrative” managers of the operators of a certain department (KE, KN, KF) and Asito, Klüh and KCS work with own shift leaders. The HCC dispatchers are the “operational” managers of all the AS operators (KLM or any other company). Since we are especially interested in the latter form of management, we take a better look at dispatching in the next section.
Dispatching and CHIP
Dispatching a job is assigning a task to a certain resource. This can be done in real time, which means the dispatcher waits until both aircraft and resource are ready, or it can be done in advance, so a schedule is created. A schedule in this situation means that resources have a list of tasks they are going to accomplish in the near future. This is to some extend efficient, since resources always need to drive from one aircraft to another, so valuable time is lost when a resource only starts driving when the aircraft is ready for servicing. On the other hand there exists a continuous flow of information from the OCC and the platform to the HCC about aircrafts arriving earlier or later, resources being ready earlier or later, congestion on the platform, problems in the operation, etc. The dispatcher wants to anticipate on this new information and may want to revise the schedule, which asks for synchronous communication. Therefore AS developed CHIP.
CHIP consists of three components: a planning and scheduling tool at HCC, a communication system using handheld computers at the platform and a statistics database. The planning tool is fed by Firda, an up-to-date version of the timetable, powered by the OCC. CHIP translates all aircraft actions (mainly arrivals, departures, turnarounds and maintenance) into AS tasks and plans these tasks in the available ground time (assigned by OCC, reported by Firda). Optimization tools in CHIP help the dispatchers with efficient job assigning. CHIP calculates planned driving times and operating times and monitors the progress of a job by communicating with the operator on the platform via his handheld. For a simple job these steps of communication may look like:
1. CHIP: Assign job A to operator X 6. Operator finishes operation 2. Operator X accepts job A 7. Operator starts administration 3. Operator starts driving to aircraft 8. Operator finishes administration 4. Operator arrives at aircraft 9. CHIP: job A is finished 5. Operator starts operation 10. Operator X is ready for next job
CHIP automatically records all times associated to the ten steps mentioned above and stores these in a database. This database is accessible via the ReportControl software and provides an enormous source of historical data for all kinds of statistical purposes. Now we can also answer the problem mentioned above concerning anticipation at uncertainty from the CHIP perspective: CHIP maintains a “planning horizon” of 15 minutes in which the schedule for the operator (at maximum one job ahead) is fixed. The rest of the schedule is continuously subject to changes, based on new information, and is therefore not communicated to the operator.
THESIS PAUL ADRIAANSEN –APRIL 2009 110 Future developments
In summer 2008 a new version of CHIP has been implemented containing new scheduling modules and state of the art optimizers. Still, CHIP is only used by Aircraft Services and does not provide communication possibilities with other departments within GS or KLM (for example communication Confidential with Line Maintenance would be helpful). One of the main developments in ground time management is a new HCC officer: the Duty Manager Aircraft (DMA) (Yunita, 2008). The idea behind this function is to manage aircraft ground time from a “horizontal” perspective (see Figure 2.5). The DMA can overrule actions of a department in order to distribute conflicting ground time between departments more efficiently or more fairly. An important change in managing ground time is that the towing department no longer dictates the available ground time, but is given a more facilitating role to other departments. In this role, the DMA provides a counter balance to the power of departments in the game of mutual “ground time snatching”.
BB2 BB3 BB4 Pax & Bax AS E&M main- AS buffer Pax & Bax AS operaton handling tenance handling operaton handling
Towing Towing
Aircraft 1 Traditional Ground Time Management: - Efficient job Aircraft 2 dispatching - Gate planning - Towing Aircraft 3 schedule is leading - Conflicting ground time Aircraft 4
New DMA function: - creates counter balance to power of Manage full ground time to give departments all departments the ground time - leads to more flexible ground time they are entitled to. - towing becomes facilitating
Figure 2.5: Four scenarios in ground time distribution between Pax, Bax, AS and E&M.
THESIS PAUL ADRIAANSEN –APRIL 2009 111 APPENDIX 3.A
LIST OF INTERVIEWEES
Name Position Topic Mark Bovenkerk Process Manager AS Process management AS CHIP and platform control Charlotte Elpers Consultant AMS/QO OPiuM and Java Programming in DSOL Martin van der Gugten Process Analyst AS Aqua services and Fuelling Towing and Pushback Ir Wei Wu Process Analyst AS Cleaning and catering processes ReportControl Marian van Ruitenbeek Monitoring & Feedback AS UPM, GPM and OCC PAT management KPI’s Elizabeth Brunsting Process Analyst AS EBD setting and norm durations OPC Roderick van der Haagen Manager Operations Support AS AS priorities punctuality and use of management KPI’s Joke de Jong Manager SPL/ST Interests of SPL/ST in project Picasso Wiro Keijer Resource planner AS Process workload figures Ricardo & George Consultants SPL/ST Project STIPT (L. van den Boom) Raymond Kortenbach Consultant SPL/ST GatePlanning en PlanControl OPC and Picasso numbers Nico Lommerse Contract manager AS HCC and dispatching Contact with shiftleaders Melanie van Rosmalen Contract manager AS, Klüh Cleaning process Claartje Verhorst Contract manager AS, Asito Cleaning process
THESIS PAUL ADRIAANSEN –APRIL 2009 112 APPENDIX 4.A
DIFFERENT FORMS OF PUNCTUALITY
This appendix presents a case study that shows how different forms of punctuality can play a different role in delaying an aircraft.
To give an idea about the different levels of punctuality KLM has to deal with, we look at two persons being at Schiphol Airport at October 3, 2007, around 14:00. Person A is a passenger traveling from Minneapolis to Stockholm, person B is an operator at the Fuel Department of KLM, fuelling a B737- 400 with destination Paris Charles de Gaulle.
Consider the viewpoint of a single KLM passenger, with baggage, traveling from Minneapolis to Stockholm, with Amsterdam as a hub (see Figure 4.A.1 and Figure 4.A.2 for the flight schedules). What are the interests of this passenger? In general this passenger wants two things (apart from having a safe, comfortable flight with tasty meals): Arriving on time at the airport in Stockholm (Arlanda, ARN) Finding his baggage on the belt in Stockholm
The actual landing and take-off times of his aircraft in Minneapolis and Amsterdam are not important for him (apart from not spending the night at Schiphol behind customs control). Since baggage performance is not the subject of this thesis, we assume that baggage always makes the transfer when the passenger is on time to make the transfer. In principle, the Scheduled Time of Arrival (STA) of 16:35 in Stockholm is the only hard deadline for our passenger. The duration of the flight AMS – ARN is 2:00 hours. Since the passenger only needs a minimum transfer time of 45 minutes to catch his flight, the aircraft from Minneapolis needs to land at least at 13:50. This means that the flight MSP –AMS can have a delay of 7:20 hours without frustrating the flight plan of this particular passenger. When we assume that the flight duration can be shortened in case of extreme delay, the actual “departure delay” at Minneapolis Airport can even be more than 7:20 hours. This gives an idea about the way a passenger is experiencing punctuality.
Now we take a look at person B, the operator at the KLM Fuel Department. He is assigned a fuelling job at gate C07 for a flight to Paris Charles de Gaulle. The scheduled time of departure (STD) for this flight is 14:10, pushback starts at 14:00 and fuelling takes 20 minutes.
In Section 4.1.3 we show that there exists a connection between the punctuality of a platform operator (lowest level) and the punctuality of a passenger (highest level). But how does this work in practice? We show this by connecting person A and B in the case above.
THESIS PAUL ADRIAANSEN –APRIL 2009 113 The fuel operator arrives at 13:40 (just on time, no slack) at gate C07 in his fuel truck. He cannot enter the platform since a Kluh Cleaning van is parked right in the path of the fuelling truck. He needs to wait five minutes before someone from Kluh removes their van. The operator reports this five minute delay to his dispatcher, but the dispatcher fails to communicate this with the towing-dispatcher. The operator starts fuelling the B737-400, destination Paris CDG, but experiences difficulties with connecting the fuel tube to the aircraft; this gives another 10 minutes delay. Again the operator calls his dispatcher to report the delay. This time the delay is discussed with the towing-dispatcher (and VOP’er), but the towing truck already arrived at the gate, so it decides to wait for the fuelling job. In the end, flight KL1237 departs with a delay of 20 minutes. Since the towing truck had to wait for the fuel operator, and the towing department works at full capacity, he arrived 20 minutes late at its next job: the pushback of flight NW8397 to Stockholm. This aircraft, with our passenger from Minneapolis on board, misses out on its take-off slot, and is placed back in the queue another 30 minutes. After all, our passenger has a delay on departure of 45 minutes, of which 10 minutes are compensated by speeding up the flight to Stockholm.
So now we are confronted with the following questions: How should we describe the ‘punctuality’ of flight NW8397 to Stockholm? Is there a difference in the delay of the aircraft from the Schiphol perspective or from the passenger perspective? Which actions are performed “on time” and which are not? Who is responsible for the delay of flight NW8397? And who is actually blamed for it?
Schiphol local time Wednesday 03 October 2007 10:23.
Date Scheme Flight Airport Status Actual 03/10 14:35 NW 8397 Stockholm Airline Hall Desk Gate Type Northwest Airlines 2 13,14,15 D77 738 +31 (0)20 - 474 7747
Schiphol local time Wednesday 03 October 2007 10:26.
Date Scheme Flight Airport Status Actual 03/10 14:10 KL 1237 Paris de Gaulle Airline Hall Desk Gate Type KLM Royal Dutch Airlines 2 13,14,15 C07 734 +31 (0)20 - 474 7747
Schiphol local time Wednesday 03 October 2007 10:28.
Date Scheme Flight Airport Status Actual 03/10 06:30 KL 6042 Minneapolis Arrived 06:08 Airline Hall Desk Gate Type KLM Royal Dutch Airlines 2 333 +31 (0)20 - 474 7747
Figure 4.A.1: Flight status of relevant flights
THESIS PAUL ADRIAANSEN –APRIL 2009 114 $1580.29 Total Price KLM 6042 Tue, Oct 9 3:15pm Depart Minneapolis/St. operated by 8hr 15min Paul (MSP) NORTHWEST AIRLINES -- NW 42 6:30am Arrive Amsterdam (AMS) Booking Class: B / Economy Ticket Designator: Approximate Distance: 4154 Meal: Dinner miles Plane Change Equipment: 333
KLM 1115 Wed, Oct 10 2:35pm Depart Amsterdam 2hr 0min (AMS) Booking Class: B / Economy 4:35pm Arrive Stockholm Ticket Designator: (ARN) Meal: Meal Equipment: 737 Approximate Distance: 709 miles
Figure 4.A.2: Flight schedule Minneapolis –Stockholm
THESIS PAUL ADRIAANSEN –APRIL 2009 115 APPENDIX 4.B
DELAY CODES AND PERFORMANCE MEETINGS
The Performance Analysis Tool (PAT) is a daily report containing all delays of all flights (AMS and outstations) of KLM, KLC and all subsidiaries, partners and clients (nearly all airline companies at Schiphol). Some important categories within the PAT are Operations Control, fleet and crew availability, weather conditions and of course Ground Services. Four of the 100 codes are for AS: catering (KG-KCS), towing and pushback (KN), cleaning and security check (KG-Klüh and KG-Asito) and fuelling (KE). The aqua department (KF) has no own delay code. In Table 4.B.1 the PAT is presented for KLM ICA and EUR (unfortunately not for KLC) for the summer period in 2007. Delays are distinguished between “short” and “long”, for which the threshold value depends on the destination. A short delay (of at least one minute) is indicated with the expression “0 min.”, while long delays are indicated with “5 min.” for EUR flights and “15 min.” for ICA flights, when the delay is greater than or equal to 5 or 15 minutes respectively. In Figure 4.B.2 a breakup is given of the delay codes assigned to AS.
Performance Analysis Tool Both delay codes Longest delay code KLM departures EUR ICA EUR & ICA Summer 2007 (OP2) 0 min. 5 min. 0 min. 15 min. 0 min. 5/15 min.
Departures # 15778 6526 22304 Delayed # 9967 6982 5153 2341 15120 9323 Delayed % 63.2 44.3 79.0 35.9 67.8 41.8 Flights with one delay code # 7894 4988 3427 1139 Flights with two delay codes # 2073 1994 1726Confidential1202
Total number of codes # 12040 8976 6879 3542 15120 9323 Pax handling % 19.2 14.7 29.4 13.7 17.2 10.2 Bax handling and ATS % 6.1 4.8 13.9 6.6 6.2 3.4 AS handling % 3.8 2.9 6.0 3.1 3.4 2.0 HCC % 3.0 2.5 6.9 3.9 3.3 2.3 Outstation management % 0.7 0.6 1.9 1.0 0.8 0.5 Cockpit crew % 3.6 2.9 3.3 1.9 2.7 1.9 In-flight services % 1.6 1.2 3.2 1.3 1.5 0.8 Technical services % 2.9 2.7 9.7 7.9 4.3 3.7 Cargo % 0.2 0.1 3.4 1.6 0.8 0.4 OCC % 10.3 9.2 10.0 7.4 8.2 6.7 Air Traffic Management (AAS) % 24.8 15.3 17.8 5.9 19.5 9.9 Total of percentages1 % 76.3 56.9 105.4 54.3 67.8 41.8
1. The percentages sum up to the number of delay codes as a percentage of the departed flights. For 0 min. delays at ICA flights, this means that there were more delay codes than departing flights. This is possible since a single flight can be assigned two delay codes. The percentages in the table show the percentage of departing flights that was delayed by the corresponding delay cause.
Table 4.B.1: PAT output for KLM departures
THESIS PAUL ADRIAANSEN –APRIL 2009 116 A quick look in the table shows that more than XXX% of all departing KLM flights are assigned at least one delay code (at 0 min. after STD). Less than XXX % of all flights is assigned a delay code of AS departments as its main cause of delay. We will return to this data when we have output of the simulation model.
Shares of processes in total AS delay according to PAT
23.4% 31.1% Confidential
Catering Cleaning 9.1% Check 1.1% Refuelling Pushback & Towing
35.1%
Figure 4.B.2: Shares of processes in total AS delay according to PAT
Performance Meetings
At KLM, three performance meetings exist: the Hub Performance Meeting (HPM), the Ground Performance Meeting (GPM) and the Unit Performance Meeting (for AS) (UPM). These are weekly meetings where the responsible persons from the organizational and operational side meet. For now we are mainly interested in the reports (monitors) that are presented at these meetings. The HPM monitor is a small version of the PAT and contains hardly any further information. The GPM monitor is more interesting, the main components are: For every flow the weekly performance is measured and the critical processes are lifted out (these are cleaning and catering for AS). The relations with Engineering & Maintenance (E&M) and the crew are discussed The performance of the towing department is reviewed separately, with a focus on the Aircraft On Position (AOP) performance.
However, the most important meeting for AS is the UPM. The UPM monitor contains information about all individual AS delays that were registered during the week (sometimes up to a 100 in total). The following information is stored about a delay: The concerned department and the specific job The date, flight and registration of the aircraft and whether it is a EUR or ICA flight The length of the delay (this does not always correspond to the PAT delay code) The cause and responsible person of the delay, together with a description
Furthermore there exists an internal coding system for AS delays: in the UPM 14 different codes can be used to describe the reason of a delay. The main reasons are: wrong job execution, job wrongly dispatched, equipment shortage or breakdown, staff shortage and high workload. The last two together form the type of delays we are interested in, these represent about XXX % of all AS delays (average over all departments). An example of an UPM monitor can be found in Table 4.B.3, this table contains the data for the year report 2007/2008. Figure 4.B.4 presents the shares of departments in the total AS delay, Figure 4.B.5 gives a breakdown of delays to the reason for the delay (internal coding), both based on the UPM year report. Note that the UPM gives an overview of all production, including handling of other airline companies. KLM and KLC together represent about XXX % of the total production, but this figure differs per department.
THESIS PAUL ADRIAANSEN –APRIL 2009 117 Department / Production (#k)2 Delays (#) Delays as % Share in AS process EUR ICA Total EUR ICA Total of production delays (%) Aqua –water 97 31 129 298 48 346 0.14 12.9 Aqua –toilet 97 28 125 Aqua –jet starters 6 1 7 75 9 84 1.13 3.1 Catering 40 17 57 342 223 565 0.99 21.0 Cleaning & check1 84 19 102 578 Confidential156 734 0.72 27.3 Refueling 113 32 145 244 141 385 0.27 14.3 Pushback 70 22 92 380 135 515 0.56 19.2 Towing 7 13 21 24 32 56 0.27 2.1 Total 514 164 678 1941 744 2685 0.39 100.0 1. Including board supply 2. Production is measured in “handling actions”; this is not equivalent to flights
Table 4.B.3: UPM monitor, data from year report 2007/2008
Shares of processes in total AS delay according to UPM
2.1% 12.9% 19.2% 3.1% Confidential Aqua - water & toilet Jetstarters Catering Cleaning & check 21.0% Refuelling 14.3% Pushback Towing
27.3%
Figure 4.B.4: Shares of processes in total AS delay according to UPM
Breakdown of delay causes for AS delays according to UPM
17.3% 23.7%
Confidential Capacity problem Execution error Dispatching error 0.8% Incidents or accidents 6.3% Equipment breakdown 26.4% Priority setting HCC Other 10.9%
14.5% Figure 4.B.5: Breakdown of delay causes for AS delays according to UPM
THESIS PAUL ADRIAANSEN –APRIL 2009 118 APPENDIX 5.A
“PICASSO”
Picasso is the name of the computer simulation model that was written for this thesis. Strictly spoken, Picasso is not the abbreviation of some longer name, but one could find the first characters of the words “Aircraft”, “Services”, “Operations”, “Punctuality”, “Indicators” and “Simulation” in it. Although the blue colors, used for the famous paintings of Pablo Picasso’s blue period, do not match the blue color from the KLM logo, it is interesting to keep in mind that the painter Picasso did use a lot of opium during these days of his life.
And for the sake of completeness, Elizabeth, this is how “Guernica” is supposed to look like:
THESIS PAUL ADRIAANSEN –APRIL 2009 119 APPENDIX 5.B
OVERVIEW OF KLM FLEET
On the following two pages the KLM fleet is presented. The overview dates from 2008 which means it already contains the new 777-300 aircrafts, which were not in service in the summer of 2007.
THESIS PAUL ADRIAANSEN –APRIL 2009 120 THESIS PAUL ADRIAANSEN –APRIL 2009 121 THESIS PAUL ADRIAANSEN –APRIL 2009 122 APPENDIX 5.C
FLOW CHARTS
In the two tables presented in this appendix, all dependencies and scheduling moments are given for every combination of aircraft type and turnaround action. The first table gives the scheduling moments, the second table (starting 4 pages from this page) the dependencies are presented.
Scheduling moments
Action Type At the start of … the following water this process:… processes are deboarding scheduled:… TA 744 fuelhydrant flight asitocleaning toilet Asitocleaning water asitocheck deboarding Boarding fuelhydrant pushback asitocleaning TA 332 asitocleaning Flight asitocheck toilet boarding water pushback Deboarding TA 74E fuelhydrant flight asitocleaning toilet Asitocleaning water asitocheck deboarding Boarding fuelhydrant pushback asitocleaning TA M11 asitocleaning Flight asitocheck toilet boarding water pushback Deboarding TA 772 fuelhydrant flight asitocleaning toilet Asitocleaning
THESIS PAUL ADRIAANSEN –APRIL 2009 123 asitocheck flight Boarding toilet pushback water TA 739 kluhcleaning flight Deboarding toilet fuelnonhydrant water Kluhcleaning kluhcleaning kluhcheck deboarding TA F70 fuelhydrant flight fuelnonhydrant toilet kluhcleaning water kluhcheck kluhcleaning boarding deboarding pushback fuelnonhydrant TA 738 kluhcleaning flight kluhcheck toilet TA F50 water flight kluhcleaning toilet deboarding water fuelhydrant kluhcleaning fuelnonhydrant deboarding kluhcleaning fuelnonhydrant kluhcheck kluhcleaning boarding kluhcheck pushback ARR 744 TA 734 flight flight toilet toilet water water deboarding kluhcleaning fuelhydrant deboarding asitocleaning fuelhydrant ARR 74E fuelnonhydrant flight kluhcleaning toilet kluhcheck water boarding deboarding pushback fuelhydrant TA 733 asitocleaning flight ARR 772 toilet flight water toilet kluhcleaning water deboarding deboarding fuelhydrant fuelhydrant fuelnonhydrant asitocleaning kluhcleaning ARR 332 kluhcheck flight boarding toilet pushback water TA 100 deboarding
THESIS PAUL ADRIAANSEN –APRIL 2009 124 asitocleaning DEPB 74E ARR M11 asitocleaning flight asitocheck toilet towing water water deboarding fuelhydrant fuelhydrant asitocleaning asitocleaning boarding ARR 739 pushback flight DEPB 772 toilet asitocleaning water asitocheck kluhcleaning towing ARR 738 water flight fuelhydrant toilet asitocleaning water boarding kluhcleaning pushback ARR 734 DEPB 332 flight asitocleaning toilet asitocheck water towing kluhcleaning water ARR 733 fuelhydrant flight asitocleaning toilet boarding water pushback kluhcleaning DEPB M11 ARR 100 asitocleaning flight asitocheck toilet towing water water kluhcleaning fuelhydrant ARR F70 asitocleaning flight boarding toilet pushback water DEPB 739 kluhcleaning catering ARR F50 kluhcheck flight towing toilet water water fuelhydrant kluhcleaning fuelnonhydrant DEPB 744 kluhcleaning asitocleaning boarding asitocheck pushback towing DEPB 738 water catering fuelhydrant kluhcheck asitocleaning towing boarding water pushback fuelhydrant
THESIS PAUL ADRIAANSEN –APRIL 2009 125 fuelnonhydrant DEPH 74E kluhcleaning asitocleaning boarding asitocheck pushback towing DEPB 734 toilet catering water kluhcheck fuelhydrant towing asitocleaning water boarding fuelhydrant pushback fuelnonhydrant DEPH 772 kluhcleaning asitocleaning boarding asitocheck pushback towing DEPB 733 toilet catering water kluhcheck fuelhydrant towing asitocleaning water boarding fuelhydrant pushback fuelnonhydrant DEPH 332 kluhcleaning asitocleaning boarding asitocheck pushback towing DEPB 100 toilet catering water kluhcheck fuelhydrant towing asitocleaning water boarding fuelnonhydrant pushback DEPB F70 DEPH M11 catering asitocleaning kluhcheck asitocheck towing towing water toilet fuelnonhydrant water DEPB F50 fuelhydrant catering asitocleaning kluhcheck boarding towing pushback water DEPH 739 fuelnonhydrant catering DEPH 744 kluhcheck asitocleaning towing asitocheck toilet towing water toilet fuelhydrant water fuelnonhydrant fuelhydrant kluhcleaning asitocleaning boarding boarding pushback pushback DEPH 738
THESIS PAUL ADRIAANSEN –APRIL 2009 126 catering fuelhydrant kluhcheck fuelnonhydrant towing kluhcleaning toilet boarding water pushback fuelhydrant DEPH 100 fuelnonhydrant catering kluhcleaning kluhcheck boarding towing pushback toilet DEPH 734 water catering fuelnonhydrant kluhcheck DEPH F70 towing catering toilet kluhcheck water towing fuelhydrant toilet fuelnonhydrant water kluhcleaning fuelnonhydrant boarding DEPH F50 pushback catering DEPH 733 kluhcheck catering towing kluhcheck toilet towing water toilet fuelnonhydrant water
Dependencies
Action Type Before this …these processes asitocleaning process can must be finished: boarding start:… TA 744 toilet deboarding water flight catering toilet asitocheck flight pushback water bax flight tech bax fuelhydrant flight boarding tech TA 74E flight deboarding fuelhydrant flight deboarding toilet catering flight deboarding water asitocleaning flight deboarding bax asitocheck flight
THESIS PAUL ADRIAANSEN –APRIL 2009 127 tech toilet flight flight fuelhydrant water deboarding flight catering bax deboarding flight asitocleaning tech deboarding flight asitocheck fuelhydrant asitocleaning deboarding boarding catering toilet deboarding water asitocleaning catering deboarding asitocheck asitocheck pushback asitocleaning bax boarding tech toilet fuelhydrant water boarding catering TA 772 asitocheck deboarding pushback flight bax toilet tech flight fuelhydrant water boarding flight TA M11 bax deboarding flight flight tech toilet flight flight fuelhydrant water deboarding flight catering bax deboarding flight asitocleaning tech deboarding flight asitocheck fuelhydrant asitocleaning deboarding boarding catering toilet deboarding water asitocleaning catering deboarding asitocheck asitocheck pushback asitocleaning bax boarding tech toilet fuelhydrant water boarding catering TA 332 asitocheck deboarding pushback flight bax
THESIS PAUL ADRIAANSEN –APRIL 2009 128 tech kluhcleaning fuelhydrant deboarding boarding kluhcheck TA 739 kluhcleaning deboarding boarding flight toilet toilet water flight catering water kluhcheck flight pushback bax bax flight tech tech fuelhydrant flight fuelnonhydrant fuelhydrant boarding deboarding TA 734 fuelnonhydrant deboarding deboarding flight catering toilet deboarding flight kluhcleaning water deboarding flight kluhcheck bax kluhcleaning flight boarding tech toilet flight water fuelhydrant catering deboarding kluhcheck fuelnonhydrant pushback deboarding bax catering tech deboarding fuelhydrant kluhcleaning fuelnonhydrant deboarding boarding kluhcheck TA 738 kluhcleaning deboarding boarding flight toilet toilet water flight catering water kluhcheck flight pushback bax bax flight tech tech fuelhydrant flight fuelnonhydrant fuelhydrant boarding deboarding TA 733 fuelnonhydrant deboarding deboarding flight catering toilet deboarding flight
THESIS PAUL ADRIAANSEN –APRIL 2009 129 water toilet flight water bax catering flight kluhcheck tech TA F70 flight deboarding fuelhydrant flight deboarding toilet fuelnonhydrant flight deboarding water catering flight deboarding bax kluhcleaning flight deboarding tech kluhcheck flight kluhcleaning fuelnonhydrant boarding deboarding toilet catering water deboarding catering kluhcleaning kluhcheck deboarding pushback towing bax bax tech tech fuelhydrant fuelnonhydrant fuelnonhydrant boarding boarding kluhcheck TA 100 kluhcleaning deboarding boarding flight toilet toilet water flight catering water kluhcheck flight TA F50 bax deboarding flight flight tech toilet flight flight fuelnonhydrant water deboarding flight catering bax deboarding flight kluhcleaning tech deboarding flight towing fuelnonhydrant bax deboarding tech catering fuelnonhydrant deboarding boarding kluhcleaning kluhcheck deboarding kluhcleaning towing boarding bax
THESIS PAUL ADRIAANSEN –APRIL 2009 130 tech towing fuelnonhydrant toilet boarding water kluhcheck bax kluhcleaning tech boarding fuelhydrant toilet catering water asitocleaning catering ARR 772 kluhcheck deboarding ARR 744 flight deboarding toilet flight flight toilet water flight flight water bax flight flight bax tech flight flight tech fuelhydrant flight deboarding fuelhydrant catering deboarding deboarding catering asitocleaning deboarding deboarding asitocleaning towing deboarding toilet towing water toilet bax water tech bax fuelhydrant tech catering fuelhydrant asitocleaning catering ARR 332 asitocleaning deboarding ARR 74E flight deboarding toilet flight flight toilet water flight flight water bax flight flight bax tech flight flight tech catering flight deboarding fuelhydrant asitocleaning deboarding deboarding catering towing deboarding toilet asitocleaning water deboarding bax
THESIS PAUL ADRIAANSEN –APRIL 2009 131 tech flight catering toilet asitocleaning flight ARR M11 water deboarding flight flight bax toilet flight flight tech water flight flight catering bax deboarding flight kluhcleaning tech deboarding flight towing fuelhydrant toilet deboarding water catering bax deboarding tech asitocleaning catering deboarding kluhcleaning towing ARR 734 toilet deboarding water flight bax toilet tech flight fuelhydrant water catering flight asitocleaning bax ARR 739 flight deboarding tech flight flight toilet catering flight deboarding water kluhcleaning flight deboarding bax towing flight toilet tech water flight bax catering tech deboarding catering kluhcleaning kluhcleaning deboarding ARR 733 towing deboarding toilet flight water toilet bax flight tech water catering flight kluhcleaning bax ARR 738 flight deboarding tech
THESIS PAUL ADRIAANSEN –APRIL 2009 132 flight bax catering tech deboarding catering kluhcleaning kluhcleaning deboarding ARR F50 towing deboarding toilet flight water toilet bax flight tech water catering flight kluhcleaning bax ARR 100 flight deboarding tech flight flight toilet catering flight deboarding water kluhcleaning flight deboarding bax towing flight toilet tech water flight bax catering tech deboarding catering kluhcleaning kluhcleaning deboarding DEPB 744 towing water toilet towing water bax bax towing tech tech catering towing kluhcleaning fuelhydrant ARR F70 towing deboarding catering flight towing toilet asitocleaning flight towing water asitocheck flight asitocleaning bax boarding flight water tech catering flight asitocheck catering pushback deboarding bax kluhcleaning tech deboarding fuelhydrant towing boarding toilet DEPB 74E water water
THESIS PAUL ADRIAANSEN –APRIL 2009 133 towing towing bax fuelhydrant towing towing tech catering towing towing fuelhydrant asitocleaning towing towing catering asitocheck towing asitocleaning asitocleaning boarding towing water asitocheck catering asitocleaning asitocheck boarding pushback water bax catering tech asitocheck fuelhydrant pushback boarding bax DEPB M11 tech water fuelhydrant towing boarding bax DEPB 772 towing water tech towing towing bax fuelhydrant towing towing tech catering towing towing fuelhydrant asitocleaning towing towing catering asitocheck towing asitocleaning asitocleaning boarding towing water asitocheck catering asitocleaning asitocheck boarding pushback water bax catering tech asitocheck fuelhydrant pushback boarding bax DEPB 739 tech water fuelhydrant towing boarding bax DEPB 332 towing water tech towing towing bax fuelhydrant towing towing tech fuelnonhydrant
THESIS PAUL ADRIAANSEN –APRIL 2009 134 towing towing catering fuelnonhydrant towing towing kluhcleaning catering towing towing kluhcheck kluhcleaning kluhcleaning towing boarding kluhcheck water kluhcleaning catering boarding kluhcheck water pushback catering bax kluhcheck tech pushback fuelhydrant bax fuelnonhydrant tech boarding fuelhydrant DEPB 738 fuelnonhydrant water boarding towing DEPB 733 bax water towing towing tech bax towing towing fuelhydrant tech towing towing fuelnonhydrant fuelhydrant towing towing catering fuelnonhydrant towing towing kluhcleaning catering towing towing kluhcheck kluhcleaning kluhcleaning towing boarding kluhcheck water kluhcleaning catering boarding kluhcheck water pushback catering bax kluhcheck tech pushback fuelhydrant bax fuelnonhydrant tech boarding fuelhydrant DEPB 734 fuelnonhydrant water boarding towing DEPB 100 bax flight towing bax tech tech towing fuelnonhydrant fuelhydrant boarding
THESIS PAUL ADRIAANSEN –APRIL 2009 135 water catering towing kluhcheck bax DEPH 744 towing toilet tech towing towing water fuelnonhydrant towing towing bax catering towing towing tech boarding towing water fuelhydrant catering towing kluhcheck catering DEPB F70 towing flight asitocleaning bax towing tech asitocheck fuelnonhydrant asitocleaning boarding boarding water toilet towing water bax catering towing asitocheck tech pushback towing bax fuelnonhydrant tech towing fuelhydrant catering boarding towing DEPH 74E boarding toilet water towing catering water kluhcheck towing DEPB F50 bax flight towing bax tech tech towing fuelnonhydrant fuelhydrant boarding towing water catering towing towing bax asitocleaning towing towing tech asitocheck towing asitocleaning fuelnonhydrant boarding towing toilet catering water towing catering boarding asitocheck water pushback
THESIS PAUL ADRIAANSEN –APRIL 2009 136 bax asitocheck tech pushback fuelhydrant bax boarding tech DEPH 772 fuelhydrant toilet boarding towing DEPH M11 water toilet towing towing bax water towing towing tech bax towing towing fuelhydrant tech towing towing catering fuelhydrant towing towing asitocleaning catering towing towing asitocheck asitocleaning asitocleaning towing boarding asitocheck toilet asitocleaning water boarding catering toilet asitocheck water pushback catering bax asitocheck tech pushback fuelhydrant bax boarding tech DEPH 332 fuelhydrant toilet boarding towing DEPH 739 water toilet towing towing bax water towing towing tech bax towing towing fuelhydrant tech towing towing catering fuelhydrant towing towing asitocleaning fuelnonhydrant towing towing asitocheck catering asitocleaning towing boarding kluhcleaning toilet kluhcleaning water kluhcheck catering kluhcleaning
THESIS PAUL ADRIAANSEN –APRIL 2009 137 boarding fuelnonhydrant toilet towing water catering catering towing kluhcheck kluhcleaning pushback kluhcleaning bax kluhcheck tech kluhcleaning fuelhydrant boarding fuelnonhydrant toilet boarding water DEPH 738 catering toilet kluhcheck towing pushback water bax towing tech bax fuelhydrant towing fuelnonhydrant tech boarding towing DEPH 733 fuelhydrant toilet towing towing fuelnonhydrant water towing towing catering bax towing towing kluhcleaning tech kluhcleaning towing kluhcheck fuelhydrant kluhcleaning towing boarding fuelnonhydrant toilet towing water catering catering towing kluhcheck kluhcleaning pushback kluhcleaning bax kluhcheck tech kluhcleaning fuelhydrant boarding fuelnonhydrant toilet boarding water DEPH 734 catering toilet kluhcheck towing pushback water bax towing tech bax fuelhydrant towing fuelnonhydrant tech boarding towing DEPH 100 fuelhydrant flight towing bax
THESIS PAUL ADRIAANSEN –APRIL 2009 138 tech fuelnonhydrant fuelnonhydrant towing boarding catering toilet towing towing boarding water toilet towing water bax catering towing kluhcheck tech DEPH F50 towing flight fuelnonhydrant bax towing tech catering fuelnonhydrant towing boarding boarding toilet toilet towing water water catering towing kluhcheck bax DEPH F70 towing flight tech bax towing tech fuelnonhydrant fuelnonhydrant towing boarding catering toilet towing towing boarding water toilet towing water bax catering towing kluhcheck tech towing
THESIS PAUL ADRIAANSEN –APRIL 2009 139 APPENDIX 6.A
JAVA AND DSOL
Java and object oriented programming
Java is a general-purpose programming language developed by Sun during the nineties and based on the language C++ (Eckel, 2006). Java is widely used for different kinds of applications, including simulation. It is an object-oriented programming language which means that all elements of the system have similar properties: Objects can have a constructor, which can be used to produce multiple entities and/or versions of the specified object. Objects can have arguments, which are properties of the object specified per version. Objects can have methods, which induce interaction with other objects. Objects make distinction between private variables, that can only be viewed and changed by its own methods, and public variables that can also be viewed by other objects. Objects are constructed within a certain level in a hierarchy. This means that less detailed objects are less useful in a particular case, but more often applicable in general. The principle of hierarchy is used to reuse programming code for other environments. Java is a fully open- source language, which means it is possible to copy code from one program to another, and a lot of high level programmed objects are available on the Internet. Objects answer to the property of inheritance. This means it is possible to extent higher level “parent” objects to lower level “children”. These children copy all the arguments and methods of its parent, but can also have their own arguments and methods in addition. This is very efficient is modeling different versions of the same object.
Simulation with DSOL
DSOL is a simulation library for Java developed by the Technical University of Delft (Jacobs et al., 2006). It consists of packages with objects that facilitate the building of discrete-time simulation models without losing any of the flexibility of Java. It offers the possibility of using a Graphical User Interface and several 2D and 3D animation possibilities. But the most important features are in the predefined, high level simulation objects: The Simulator class object, this object is responsible for the communication between the specific DSOL objects. The Experiment object, this object defines the arguments of a run: replications, run length, which streams to use, etc. The Replication object, this object manages the stream and seed settings. The EventScheduler, this object is responsible for the evolvement of time, and the scheduling of events in the future.
THESIS PAUL ADRIAANSEN –APRIL 2009 140 There exist also lower level objects, for example the objects process, resource, seize, delay and release. These are comparable to the equally named modules or actions in Arena (Law and Kelton, 2000). The same is true for the eventListenerInterface that can be compared to the hold function in Arena. DSOL does not yet provide a standardized graphical modeling environment, as Arena does, so it takes knowledge of Java to be able to build a simulation model with DSOL. DSOL has been presented on the 2002 Winter Simulation conference and the 15th European Simulation Symposium and Exhibition in 2003 (Lang et al., 2003).
THESIS PAUL ADRIAANSEN –APRIL 2009 141 APPENDIX 6.B
STRUCTURE OF THE PROGRAM
In this section a full description of the Picasso computer program is presented. Five types of files are used to construct the program: .jar files, .java files, .xml files .xls files and .txt files: The .jar files are used to import full Java applications from other programs into the program that is constructed. In Picasso, the files dsol.jar and opiumforpicasso.jar import the upper two levels in the Picasso hierarchy as black boxes. The .xml files are files that answer to a predefined format and are therefore useful to import input parameters. The most important file is experiment.xml that contains all the experiment settings (replications, run length, streams, etc.) The .xls and .txt files are used to upload data tables and lists in the program. The .java files contain the actual syntax of the program; therefore they are described in more detail in the rest of this section.
Main category
This is by far the most important package, since it contains all the large, important classes that define the main elements of Picasso: Control is the object that is the centre of the simulation model. All other objects communicate with Control in order to centralize decision making. Control manages all other objects and is the only object that schedules events in time. It is also the only object with “intelligence”, since Control controls all the actions of other objects. One of the most important objects that are managed by Control is the Aircraft class. The Aircraft class is used to construct aircrafts according to the input delivered by OPiuM. The DataContainer class is the largest of all, since it contains methods and variables to store and request all data that is used in the program. The DataContainer is used as a gateway for data, since it decides which objects are entitled to certain parts of data. The two Model classes are used to startup the simulation program. It uploads the data and experiment file and then initiates the construction of the Control class. There are two versions: an OPiuM based Model class and a stand-alone Model class. The latter can be used to produce small verification runs.
Processes
The processes package contains:
THESIS PAUL ADRIAANSEN –APRIL 2009 142 A ProcessInterface that is needed for communication with the Process class in DSOL, and a ProcessAS class that extends the predefined process from DSOL to a specific process that can be used within Picasso. Then, sixteen classes are created for the sixteen processes that are modeled (both AS and non-AS processes). The most important function of these sixteen “children” of theProcessAS class is to define the StationInterface objects (such as seize, delay and release functions) and attach a specific order in which these stations should be visited (for instance: seize a resource, delay for driving, delay for processing, release the resource).
Flows
The stations mentioned in the last section are objects themselves and therefore need to be constructed within a specific class; therefore the package Flow is constructed: The first class is the SeizeAS class. In this class the seize station is created as an AS specified child of the DSOL seize class. The original idea behind this was that it should be possible to request a certain number of resources per seize station, depending on the parameters of the Process and Aircraft. DelayAS is an important class. With this class the actual processing is simulated, since the seized resource is assigned to a specific aircraft. DelayDriving is comparable to the DelayAS class, since it simulates the driving time of a resource to the Aircraft. Then there exist four process specific delay classes: DelayCabinSupply, DelayHandshake, DelayAAS and DelayWaitingBax. These four classes are special forms of delay that are associated to the extra sources of delay introduced in Section 5.2.3. Finally, the ReleaseAS class is a child of the DSOL release class, again designed to release a certain number of resources at once. Although it works, it was never used in the final version of Picasso model in the end.
Calculators
The Calculators package contains five classes that are obviously built to be called by other objects, needing some standardized calculation: The CalculateEBD object calculates the EBD of a certain aircraft at a certain moment in time. It searches through the EventTimesMap of the Aircraft looking for the most up-to-date information about the status of all processes. Then it calculates the expected length of all paths and returns the expected length of the maximum path. The CalculateLST object is similar to the CalculateEBD object. It uses norm durations to estimate the LST instant for a certain Aircraft and a certain job. The TriaDistQuant object calculates the inverse of the Triangular distribution in order to return the value at which the CDF of the triangular distribution would give the predefined quantile as the probability that F ( X < x ). The HighestPriorityComparator picks the job with the highest priority from the unsorted list with jobs, just after all the priorities have been calculated. The ConstructAverages object returns the mean of a random variable with some Triangular distribution, but this object was abandoned after deciding to use medians in stead of means.
Input
The Input package contains files that are programmed to read one or more .txt input files. Some files are invoked at the creation of the experiment; others are run as part of the construction of the Control object. Most of the readers that are used have names that explain what is read: ReadCapacities reads the capacity table of 7395 rows for each of 16 processes. ReadDependencies, this object turns an .xml file into precedence relations (that are stored in the DataContainer). ReadSchedulingMoments, this object also reads an .xml file, containing the scheduling relations.
THESIS PAUL ADRIAANSEN –APRIL 2009 143 ReadLongDestinations, used for distinguishing long fuelhydrant durations for far destinations. ReadDistributions, this objects stores all distributions for all processes (for every aircraft type and action), about 1200 in total. The ReadLSTESTMinutes object was initially used for importing the A+ and D–times, but eventually the whole dynamic AIS was imported (including all norm durations, etc.). FindDistribution returns the appropriate distribution when a process and aircraft are the arguments.
Stats
This is a statistical package, partially copied from another Java project of KLM. It has the following classes: ProbabilityDistribution is a class that contains a function that returns a draw from some probability distribution with some probability, and zero otherwise. This is for example used to draw the length of a prefuel job. The DistributionParser is used to find the associated distribution for ever continuous or discrete distribution, based on the first four characters of the first argument of the distribution. Picasso only uses TRIA, which obviously stands for triangular, while DETM returns a constant. The DistTriangularPicasso extents the DistTriangular class in DSOL in order to be able to read the individual parameters from any triangular distribution used.
Output
The Output package contains four classes that are used together to print .txt files with all possible relevant data: StatisticsObject is a class that is used to store all aircrafts that virtually left the system. At the end of the simulation run all arrived and departed aircrafts are read on interesting data one by one. At maximum, almost 27000 aircrafts are stored together in this “database”. The FileOutput class is downloaded from an open source Java weblog. It contains all kinds of writers that can be easily invoked by other objects. Picasso mainly uses its function to open existing non-empty .txt files, jump to the last entry of the last row, and start writing again on the next row. The OuputTextFile class is an enormous class creating objects that read all the relevant information of all aircrafts in the StatisticsObject, translates this into strings and writes these strings in a predefined format into .txt files. Exactly 73 strings are printed for each individual aircraft. With run length of 10 weeks, this makes almost 2 million strings (mostly 64-bit 16 digit doubles), creating in total 22MB of .txt files per run.
THESIS PAUL ADRIAANSEN –APRIL 2009 144 APPENDIX 6.C
CORRECTED WORKLOAD
In this table all the capacity levels are given for all the 9 AS processes and every half hour during a whole week. The numbers represent the corrected workload.
Time asitocheck asitocleaning fuelhydrant fuelnonhydrant kluhcheck kluhcleaning pushback toilet water
Monday 0:00 1.0 1.0 1.0 1.0 1.0 2.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 2.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 2.0 6.0 5.0 1.0 2.0 2.0 3.0 3.0 5:30 1.0 8.0 8.0 6.0 3.0 3.0 2.0 6.0 13.0 6:00 1.0 11.0 7.0 4.0 7.0 4.0 4.0 8.0 10.0 6:30 1.0 11.0 8.0 6.0 13.0 5.0 7.0 6.0 10.0 7:00 4.0 10.0 7.0 6.0 7.0 6.0 11.0 6.0 8.0 7:30 4.0 8.0 7.0 6.0 7.0 7.0 7.0 9.0 10.0 8:00 1.0 11.0 15.0 11.0 7.0 17.0 7.0 12.0 11.0 8:30 1.0 10.0 17.0 13.0 17.0 19.0 7.0 14.0 11.0 9:00 9.0 7.0 15.0 11.0 13.0 16.0 15.0 14.0 10.0 9:30 9.0 7.0 17.0 10.0 7.0 14.0 15.0 8.0 10.0 10:00 6.0 6.0 14.0 3.0 7.0 5.0 18.0 6.0 8.0 10:30 1.0 7.0 8.0 4.0 7.0 6.0 7.0 8.0 8.0 11:00 2.0 7.0 13.0 6.0 7.0 9.0 7.0 8.0 8.0 11:30 4.0 6.0 13.0 11.0 11.0 11.0 8.0 11.0 10.0 12:00 7.0 7.0 13.0 10.0 7.0 11.0 10.0 11.0 10.0 12:30 7.0 6.0 11.0 10.0 7.0 8.0 10.0 8.0 10.0 13:00 7.0 6.0 13.0 7.0 5.0 8.0 13.0 8.0 10.0 13:30 1.0 6.0 13.0 8.0 5.0 11.0 10.0 9.0 10.0 14:00 9.0 6.0 14.0 8.0 17.0 13.0 6.0 9.0 10.0 14:30 11.0 4.0 14.0 7.0 9.0 12.0 17.0 11.0 8.0 15:00 1.0 4.0 11.0 7.0 5.0 7.0 17.0 5.0 7.0 15:30 1.0 4.0 4.0 6.0 1.0 5.0 8.0 5.0 6.0 16:00 1.0 4.0 6.0 8.0 3.0 8.0 4.0 8.0 6.0 16:30 2.0 4.0 8.0 10.0 5.0 9.0 4.0 11.0 8.0 17:00 7.0 4.0 8.0 10.0 7.0 9.0 6.0 8.0 8.0
THESIS PAUL ADRIAANSEN –APRIL 2009 145 17:30 9.0 4.0 10.0 8.0 7.0 8.0 6.0 8.0 8.0 18:00 1.0 3.0 7.0 6.0 7.0 7.0 13.0 6.0 7.0 18:30 1.0 4.0 10.0 6.0 7.0 9.0 7.0 8.0 7.0 19:00 1.0 4.0 10.0 11.0 7.0 16.0 4.0 9.0 7.0 19:30 4.0 3.0 13.0 11.0 11.0 17.0 4.0 11.0 7.0 20:00 6.0 3.0 13.0 13.0 19.0 20.0 17.0 11.0 8.0 20:30 2.0 1.0 13.0 13.0 17.0 18.0 27.0 11.0 8.0 21:00 1.0 1.0 1.0 6.0 3.0 4.0 18.0 5.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 3.0 2.0 3.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 5.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 5.0 2.0 5.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 4.0 2.0 5.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0
Tuesday 0:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 3.0 6.0 6.0 1.0 2.0 2.0 3.0 3.0 5:30 1.0 8.0 8.0 6.0 3.0 3.0 2.0 5.0 10.0 6:00 1.0 11.0 7.0 4.0 7.0 4.0 4.0 6.0 10.0 6:30 1.0 11.0 7.0 4.0 13.0 5.0 7.0 6.0 10.0 7:00 4.0 10.0 7.0 6.0 7.0 6.0 11.0 8.0 8.0 7:30 4.0 8.0 7.0 8.0 7.0 7.0 7.0 9.0 8.0 8:00 1.0 8.0 17.0 11.0 7.0 17.0 7.0 12.0 11.0 8:30 1.0 8.0 17.0 13.0 17.0 20.0 7.0 12.0 13.0 9:00 9.0 8.0 18.0 11.0 15.0 17.0 15.0 12.0 11.0 9:30 11.0 8.0 18.0 10.0 9.0 12.0 14.0 9.0 11.0 10:00 6.0 8.0 17.0 3.0 7.0 5.0 18.0 8.0 7.0 10:30 1.0 6.0 8.0 6.0 7.0 4.0 7.0 8.0 7.0 11:00 2.0 6.0 11.0 8.0 7.0 9.0 7.0 8.0 8.0 11:30 6.0 6.0 11.0 10.0 13.0 9.0 8.0 8.0 10.0 12:00 6.0 6.0 13.0 10.0 7.0 9.0 10.0 11.0 8.0 12:30 7.0 6.0 11.0 10.0 7.0 9.0 8.0 8.0 10.0 13:00 6.0 6.0 13.0 7.0 5.0 9.0 13.0 8.0 8.0 13:30 1.0 6.0 11.0 7.0 5.0 11.0 10.0 8.0 8.0 14:00 7.0 4.0 13.0 7.0 17.0 11.0 4.0 9.0 8.0 14:30 9.0 4.0 14.0 7.0 11.0 12.0 17.0 11.0 8.0 15:00 4.0 3.0 11.0 6.0 5.0 8.0 17.0 5.0 7.0 15:30 1.0 3.0 7.0 6.0 1.0 6.0 10.0 5.0 6.0 16:00 1.0 3.0 6.0 10.0 3.0 7.0 4.0 5.0 6.0 16:30 2.0 4.0 8.0 10.0 5.0 8.0 4.0 8.0 7.0 17:00 6.0 4.0 8.0 10.0 7.0 8.0 6.0 9.0 7.0 17:30 7.0 4.0 8.0 10.0 7.0 9.0 6.0 8.0 8.0 18:00 1.0 3.0 6.0 6.0 7.0 8.0 11.0 8.0 4.0 18:30 1.0 3.0 8.0 7.0 7.0 8.0 7.0 5.0 6.0 19:00 1.0 3.0 10.0 11.0 7.0 16.0 4.0 11.0 8.0 19:30 4.0 1.0 11.0 14.0 11.0 18.0 4.0 12.0 8.0 20:00 6.0 1.0 11.0 13.0 17.0 19.0 15.0 11.0 7.0 20:30 2.0 1.0 11.0 13.0 17.0 16.0 27.0 9.0 7.0 21:00 1.0 1.0 3.0 4.0 3.0 4.0 18.0 3.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 3.0 2.0 3.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 3.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 3.0 2.0 5.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 6.0 2.0 5.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0
THESIS PAUL ADRIAANSEN –APRIL 2009 146 Wednes- day 0:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 1.0 4.0 6.0 1.0 2.0 2.0 2.0 1.0 5:30 1.0 7.0 8.0 6.0 3.0 3.0 2.0 6.0 8.0 6:00 1.0 8.0 7.0 6.0 7.0 4.0 4.0 6.0 8.0 6:30 1.0 11.0 7.0 6.0 13.0 5.0 7.0 6.0 8.0 7:00 4.0 8.0 6.0 7.0 7.0 6.0 11.0 9.0 10.0 7:30 4.0 7.0 7.0 8.0 7.0 7.0 7.0 8.0 10.0 8:00 1.0 8.0 14.0 11.0 7.0 17.0 7.0 14.0 11.0 8:30 1.0 8.0 18.0 11.0 17.0 17.0 7.0 12.0 11.0 9:00 11.0 8.0 20.0 11.0 13.0 17.0 15.0 12.0 13.0 9:30 13.0 8.0 20.0 11.0 7.0 14.0 15.0 9.0 13.0 10:00 7.0 8.0 17.0 4.0 7.0 5.0 20.0 9.0 11.0 10:30 1.0 8.0 10.0 6.0 7.0 5.0 7.0 8.0 8.0 11:00 2.0 7.0 11.0 6.0 7.0 9.0 7.0 8.0 8.0 11:30 4.0 7.0 11.0 8.0 11.0 10.0 8.0 11.0 8.0 12:00 7.0 7.0 11.0 11.0 7.0 9.0 10.0 11.0 8.0 12:30 7.0 7.0 11.0 10.0 7.0 9.0 10.0 8.0 10.0 13:00 6.0 7.0 11.0 8.0 5.0 9.0 13.0 9.0 8.0 13:30 1.0 6.0 11.0 7.0 5.0 11.0 10.0 9.0 8.0 14:00 7.0 6.0 13.0 8.0 17.0 13.0 4.0 9.0 8.0 14:30 9.0 3.0 14.0 7.0 9.0 13.0 17.0 9.0 8.0 15:00 1.0 3.0 11.0 7.0 5.0 8.0 17.0 5.0 6.0 15:30 1.0 4.0 4.0 6.0 1.0 6.0 8.0 5.0 6.0 16:00 1.0 4.0 7.0 8.0 3.0 8.0 4.0 9.0 7.0 16:30 2.0 3.0 10.0 10.0 5.0 8.0 4.0 9.0 8.0 17:00 7.0 3.0 11.0 10.0 7.0 8.0 6.0 8.0 8.0 17:30 7.0 3.0 10.0 10.0 7.0 8.0 6.0 8.0 8.0 18:00 1.0 3.0 8.0 6.0 7.0 7.0 11.0 6.0 4.0 18:30 1.0 4.0 10.0 8.0 7.0 9.0 6.0 6.0 6.0 19:00 1.0 4.0 11.0 11.0 7.0 17.0 4.0 11.0 8.0 19:30 7.0 3.0 14.0 11.0 11.0 17.0 4.0 11.0 10.0 20:00 11.0 3.0 14.0 11.0 15.0 19.0 17.0 12.0 10.0 20:30 2.0 1.0 14.0 11.0 17.0 16.0 29.0 11.0 8.0 21:00 1.0 1.0 3.0 4.0 3.0 4.0 18.0 3.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 2.0 2.0 3.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 5.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 3.0 2.0 5.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 4.0 2.0 5.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0
Thurs- day 0:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 2.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 3.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 1.0 6.0 6.0 1.0 2.0 2.0 5.0 3.0 5:30 1.0 7.0 10.0 7.0 3.0 3.0 2.0 6.0 10.0
THESIS PAUL ADRIAANSEN –APRIL 2009 147 6:00 1.0 13.0 10.0 6.0 7.0 4.0 4.0 6.0 10.0 6:30 1.0 13.0 8.0 6.0 13.0 5.0 7.0 8.0 8.0 7:00 2.0 10.0 8.0 8.0 7.0 6.0 11.0 5.0 8.0 7:30 4.0 10.0 8.0 8.0 7.0 7.0 4.0 12.0 8.0 8:00 1.0 8.0 14.0 11.0 7.0 17.0 7.0 12.0 13.0 8:30 1.0 8.0 15.0 13.0 17.0 19.0 7.0 12.0 13.0 9:00 11.0 8.0 15.0 13.0 13.0 16.0 15.0 11.0 13.0 9:30 11.0 7.0 17.0 11.0 7.0 13.0 15.0 11.0 13.0 10:00 6.0 7.0 14.0 3.0 7.0 6.0 20.0 8.0 8.0 10:30 1.0 8.0 10.0 4.0 7.0 7.0 7.0 8.0 8.0 11:00 2.0 7.0 11.0 6.0 7.0 9.0 7.0 9.0 8.0 11:30 7.0 7.0 11.0 11.0 11.0 9.0 8.0 8.0 11.0 12:00 6.0 7.0 13.0 11.0 7.0 8.0 10.0 11.0 10.0 12:30 7.0 7.0 13.0 10.0 7.0 9.0 10.0 9.0 10.0 13:00 7.0 6.0 13.0 7.0 5.0 9.0 13.0 8.0 10.0 13:30 2.0 6.0 13.0 7.0 5.0 11.0 10.0 9.0 10.0 14:00 7.0 6.0 14.0 8.0 17.0 13.0 7.0 9.0 10.0 14:30 9.0 4.0 15.0 7.0 9.0 13.0 17.0 11.0 10.0 15:00 2.0 3.0 11.0 7.0 5.0 7.0 17.0 6.0 7.0 15:30 1.0 3.0 4.0 6.0 1.0 5.0 10.0 5.0 4.0 16:00 1.0 3.0 6.0 10.0 3.0 8.0 4.0 9.0 6.0 16:30 2.0 3.0 7.0 10.0 5.0 8.0 4.0 8.0 7.0 17:00 4.0 4.0 7.0 10.0 7.0 9.0 6.0 8.0 7.0 17:30 7.0 4.0 8.0 10.0 7.0 9.0 6.0 8.0 7.0 18:00 1.0 3.0 6.0 6.0 7.0 5.0 10.0 6.0 6.0 18:30 1.0 3.0 10.0 10.0 7.0 8.0 7.0 9.0 6.0 19:00 1.0 4.0 11.0 13.0 7.0 17.0 4.0 9.0 8.0 19:30 6.0 4.0 13.0 11.0 11.0 19.0 4.0 11.0 8.0 20:00 7.0 3.0 14.0 11.0 19.0 20.0 17.0 11.0 8.0 20:30 2.0 1.0 14.0 11.0 17.0 15.0 28.0 9.0 8.0 21:00 1.0 1.0 1.0 6.0 3.0 5.0 18.0 5.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 3.0 2.0 5.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 3.0 1.0 22:30 1.0 1.0 1.0 1.0 1.0 5.0 2.0 5.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 4.0 2.0 5.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0
Friday 0:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 3.0 6.0 4.0 1.0 2.0 2.0 3.0 1.0 5:30 1.0 8.0 7.0 6.0 3.0 3.0 2.0 5.0 11.0 6:00 1.0 13.0 7.0 6.0 7.0 4.0 4.0 6.0 11.0 6:30 1.0 13.0 7.0 6.0 13.0 5.0 7.0 6.0 10.0 7:00 4.0 10.0 7.0 6.0 7.0 6.0 11.0 6.0 8.0 7:30 4.0 10.0 7.0 7.0 7.0 7.0 7.0 9.0 8.0 8:00 1.0 7.0 15.0 13.0 7.0 17.0 7.0 12.0 10.0 8:30 1.0 8.0 15.0 13.0 17.0 20.0 7.0 12.0 11.0 9:00 9.0 7.0 17.0 11.0 15.0 16.0 15.0 12.0 11.0 9:30 11.0 8.0 17.0 10.0 7.0 14.0 14.0 11.0 11.0 10:00 7.0 7.0 15.0 4.0 7.0 4.0 18.0 6.0 7.0 10:30 1.0 7.0 10.0 3.0 7.0 5.0 7.0 8.0 8.0 11:00 2.0 7.0 13.0 7.0 9.0 9.0 7.0 8.0 10.0 11:30 4.0 7.0 13.0 11.0 11.0 10.0 10.0 9.0 11.0 12:00 7.0 8.0 14.0 11.0 7.0 10.0 11.0 12.0 11.0 12:30 7.0 7.0 14.0 11.0 7.0 9.0 10.0 8.0 10.0
THESIS PAUL ADRIAANSEN –APRIL 2009 148 13:00 6.0 4.0 13.0 8.0 5.0 9.0 13.0 9.0 8.0 13:30 2.0 7.0 11.0 8.0 5.0 11.0 10.0 9.0 8.0 14:00 9.0 7.0 13.0 8.0 17.0 15.0 6.0 9.0 8.0 14:30 11.0 4.0 13.0 8.0 11.0 12.0 17.0 11.0 8.0 15:00 1.0 4.0 11.0 7.0 5.0 6.0 17.0 5.0 6.0 15:30 1.0 4.0 3.0 6.0 1.0 6.0 8.0 6.0 6.0 16:00 1.0 4.0 7.0 10.0 3.0 9.0 4.0 6.0 8.0 16:30 2.0 4.0 10.0 10.0 5.0 8.0 4.0 9.0 8.0 17:00 7.0 4.0 10.0 8.0 7.0 9.0 6.0 8.0 8.0 17:30 7.0 3.0 8.0 10.0 7.0 8.0 6.0 8.0 7.0 18:00 1.0 3.0 7.0 6.0 7.0 7.0 11.0 6.0 4.0 18:30 1.0 4.0 11.0 7.0 7.0 8.0 6.0 8.0 7.0 19:00 1.0 4.0 11.0 11.0 7.0 17.0 4.0 11.0 10.0 19:30 7.0 3.0 14.0 13.0 11.0 19.0 4.0 11.0 10.0 20:00 11.0 3.0 14.0 14.0 17.0 22.0 18.0 11.0 10.0 20:30 2.0 1.0 13.0 13.0 17.0 15.0 29.0 12.0 8.0 21:00 1.0 1.0 3.0 4.0 3.0 4.0 18.0 3.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 3.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 5.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 3.0 2.0 6.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 6.0 2.0 3.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0
Saterday 0:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 3.0 4.0 6.0 1.0 2.0 2.0 2.0 1.0 5:30 1.0 7.0 6.0 6.0 3.0 3.0 2.0 6.0 8.0 6:00 1.0 8.0 6.0 4.0 7.0 4.0 4.0 6.0 10.0 6:30 1.0 10.0 6.0 6.0 11.0 5.0 7.0 6.0 10.0 7:00 4.0 8.0 6.0 6.0 7.0 6.0 10.0 9.0 10.0 7:30 4.0 8.0 7.0 10.0 7.0 7.0 7.0 9.0 10.0 8:00 1.0 8.0 15.0 11.0 7.0 19.0 7.0 11.0 11.0 8:30 1.0 10.0 17.0 11.0 15.0 16.0 7.0 12.0 11.0 9:00 11.0 8.0 15.0 11.0 13.0 13.0 14.0 12.0 10.0 9:30 11.0 8.0 17.0 10.0 7.0 12.0 15.0 8.0 8.0 10:00 6.0 6.0 15.0 4.0 7.0 6.0 18.0 8.0 7.0 10:30 1.0 6.0 8.0 6.0 7.0 7.0 7.0 8.0 8.0 11:00 2.0 7.0 10.0 6.0 9.0 7.0 7.0 8.0 8.0 11:30 7.0 7.0 11.0 10.0 11.0 9.0 10.0 8.0 8.0 12:00 7.0 7.0 14.0 10.0 7.0 9.0 11.0 11.0 10.0 12:30 7.0 7.0 13.0 8.0 7.0 9.0 10.0 8.0 10.0 13:00 7.0 6.0 13.0 7.0 5.0 8.0 13.0 8.0 8.0 13:30 1.0 6.0 13.0 7.0 5.0 8.0 10.0 9.0 8.0 14:00 7.0 6.0 13.0 7.0 15.0 13.0 6.0 9.0 8.0 14:30 9.0 4.0 13.0 7.0 11.0 10.0 14.0 9.0 8.0 15:00 4.0 4.0 10.0 6.0 5.0 5.0 15.0 8.0 7.0 15:30 1.0 4.0 6.0 4.0 3.0 5.0 10.0 5.0 4.0 16:00 1.0 4.0 6.0 6.0 3.0 7.0 4.0 6.0 6.0 16:30 2.0 4.0 7.0 6.0 5.0 7.0 4.0 8.0 6.0 17:00 7.0 4.0 7.0 4.0 7.0 7.0 6.0 8.0 6.0 17:30 11.0 4.0 8.0 1.0 7.0 7.0 6.0 6.0 6.0 18:00 1.0 3.0 7.0 1.0 7.0 7.0 8.0 6.0 6.0 18:30 1.0 4.0 7.0 8.0 7.0 7.0 6.0 6.0 6.0 19:00 1.0 4.0 11.0 11.0 7.0 13.0 4.0 9.0 6.0 19:30 4.0 3.0 11.0 10.0 11.0 15.0 4.0 11.0 6.0
THESIS PAUL ADRIAANSEN –APRIL 2009 149 20:00 6.0 3.0 11.0 10.0 19.0 17.0 17.0 12.0 6.0 20:30 2.0 1.0 13.0 10.0 17.0 9.0 27.0 11.0 6.0 21:00 1.0 1.0 3.0 6.0 3.0 4.0 18.0 3.0 3.0 21:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 2.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 3.0 2.0 2.0 1.0 23:00 1.0 1.0 1.0 1.0 1.0 4.0 2.0 2.0 1.0 23:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0
Sunday 0:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 0:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 2.0 1.0 1:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 1:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 2:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 3:30 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:00 1.0 1.0 1.0 1.0 1.0 1.0 2.0 1.0 1.0 4:30 1.0 1.0 1.0 3.0 1.0 1.0 2.0 1.0 1.0 5:00 1.0 1.0 7.0 6.0 1.0 2.0 2.0 2.0 1.0 5:30 1.0 7.0 10.0 4.0 3.0 3.0 2.0 6.0 8.0 6:00 1.0 10.0 8.0 6.0 7.0 4.0 4.0 6.0 8.0 6:30 1.0 11.0 8.0 6.0 13.0 5.0 7.0 6.0 10.0 7:00 2.0 11.0 7.0 6.0 7.0 6.0 11.0 8.0 8.0 7:30 4.0 10.0 7.0 7.0 7.0 7.0 4.0 9.0 10.0 8:00 1.0 13.0 14.0 10.0 7.0 15.0 7.0 12.0 11.0 8:30 1.0 11.0 18.0 10.0 17.0 19.0 7.0 12.0 11.0 9:00 11.0 11.0 18.0 10.0 15.0 18.0 15.0 12.0 11.0 9:30 13.0 10.0 18.0 8.0 7.0 12.0 15.0 9.0 10.0 10:00 7.0 7.0 15.0 3.0 7.0 4.0 20.0 8.0 8.0 10:30 1.0 7.0 10.0 6.0 7.0 4.0 7.0 6.0 7.0 11:00 2.0 7.0 10.0 6.0 9.0 9.0 7.0 8.0 8.0 11:30 2.0 7.0 11.0 8.0 11.0 10.0 10.0 8.0 10.0 12:00 6.0 7.0 11.0 8.0 7.0 9.0 11.0 11.0 10.0 12:30 7.0 6.0 11.0 10.0 7.0 8.0 8.0 8.0 10.0 13:00 6.0 6.0 10.0 7.0 5.0 8.0 13.0 8.0 10.0 13:30 2.0 6.0 11.0 8.0 5.0 11.0 10.0 9.0 8.0 14:00 7.0 6.0 13.0 7.0 17.0 12.0 6.0 9.0 8.0 14:30 9.0 4.0 13.0 8.0 9.0 11.0 15.0 9.0 8.0 15:00 1.0 4.0 10.0 8.0 5.0 7.0 17.0 6.0 6.0 15:30 1.0 4.0 4.0 7.0 1.0 5.0 10.0 5.0 7.0 16:00 1.0 3.0 8.0 8.0 3.0 7.0 4.0 6.0 7.0 16:30 2.0 4.0 10.0 8.0 5.0 8.0 4.0 8.0 7.0 17:00 7.0 4.0 10.0 10.0 7.0 7.0 6.0 8.0 7.0 17:30 9.0 4.0 10.0 8.0 7.0 8.0 6.0 8.0 7.0 18:00 1.0 3.0 8.0 4.0 7.0 7.0 11.0 6.0 7.0 18:30 1.0 4.0 8.0 11.0 7.0 7.0 6.0 8.0 7.0 19:00 1.0 4.0 11.0 11.0 7.0 15.0 4.0 11.0 7.0 19:30 6.0 1.0 13.0 14.0 11.0 20.0 4.0 11.0 8.0 20:00 9.0 1.0 11.0 13.0 17.0 21.0 18.0 11.0 8.0 20:30 2.0 1.0 13.0 11.0 17.0 18.0 28.0 11.0 8.0 21:00 1.0 1.0 3.0 4.0 3.0 4.0 18.0 3.0 3.0 21:30 1.0 1.0 1.0 4.0 1.0 1.0 2.0 3.0 1.0 22:00 1.0 1.0 1.0 1.0 1.0 3.0 2.0 3.0 1.0 22:30 2.0 1.0 1.0 1.0 1.0 3.0 2.0 3.0 1.0 23:00 1.0 1.0 1.0 1.0 3.0 4.0 2.0 3.0 1.0 23:30 1.0 1.0 1.0 1.0 3.0 1.0 3.0 2.0 1.0
THESIS PAUL ADRIAANSEN –APRIL 2009 150 APPENDIX 6.D
PROCESS DURATION DISTRIBUTIONS
This table presents the distributions of the process durations, per process, action and aircraft type. Also the resulting A+ and V- times are given. Mind that the V- time is given as the LET in minutes from the start of the action (so actually as a A+ time, instead of a V- time).
ALL BLANCO DUE TO CONFIDENTIALITY
Times in minutes PROCESS Triangular Distribution action:type A+ time V- time min mod max mean (LET from A+)
THESIS PAUL ADRIAANSEN –APRIL 2009 151 APPENDIX 7.A
CONTROL PANELS
This appendix provides an overview of all control panels of the runs that are performed. The panels are ordered on their run number, first the basic runs, second the validation runs, third the minus-one- effect runs (sensitivity analysis), fourth the Intelligence runs, fifth the infinite resources run, sixth the early morning correction and seventh the Priority difference run.
Control Panel Run no: 18 Run name: Basic 1
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 1 WIBO 1.6
Other manually changed settings or comments: none
Control Panel Run no: 19 Run name: Basic 2
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 10 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel
THESIS PAUL ADRIAANSEN –APRIL 2009 152 Run no: 20 Run name: Basic 3
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 10 Priority TRUE NABO 1.2 R.N. spill: 201 WIBO 1.6
Control Panel Run no: 21 Run name: Basic 4
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 301 WIBO 1.6
Control Panel Run no: 22 Run name: Basic 5
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 401 WIBO 1.6
Control Panel Run no: 23 Run name: Validatie 1
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 1 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Other manually changed settings or comments: Kluhcleaning +1
THESIS PAUL ADRIAANSEN –APRIL 2009 153 Control Panel Run no: 24 Run name: Validatie 2
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 -1 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Other manually changed settings or comments: Fuelhydrant -1
Control Panel Run no: 25 Run name: Validatie 3
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Other manually changed settings or comments: Water at 0 between 12 and 14
Control Panel Run no: 26 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A -1 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 27 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 -1 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
THESIS PAUL ADRIAANSEN –APRIL 2009 154 Control Panel Run no: 29 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 -1 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 30 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 -1 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 31 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 -1 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 32 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 -1 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
THESIS PAUL ADRIAANSEN –APRIL 2009 155 Control Panel Run no: 33 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 -1 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 34 Run name: minusOneEffect
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 -1 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 35 Run name: scheduling off
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling FALSE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 36 Run name: priority off
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority FALSE NABO 1.2 R.N. spill: 101 WIBO 1.6
THESIS PAUL ADRIAANSEN –APRIL 2009 156 Control Panel Run no: 37 Run name: all 999
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 999 999 999 999 999 999 999 999 999 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Oscar Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Control Panel Run no: 38 Run name: early morning correction
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Tonnie Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.2 R.N. spill: 101 WIBO 1.6
Other manually changed settings or comments: Additional resources between 4:30 and 6:30
Control Panel Run no: 39 Run name: PrioDiff
Capacity settings: Asitocheck Asitocleaning Fuelhydrant Fuelnonhydrant Kluhcheck Kluhcleaning Pushback Toilet Water A 0 0 0 0 0 0 0 0 0 B 2 1.4 1.4 1.4 2 1.4 1.4 1.4 1.4
Run settings: Intelligence settings: Priority settings: PC name: Moens Scheduling TRUE KLC 1 # weeks: 1 + 5 Priority TRUE NABO 1.4 R.N. spill: 101 WIBO 2.2
THESIS PAUL ADRIAANSEN –APRIL 2009 157