Proposed Modifications to CRSMAS

Abdul Samad Shibghatullah 137 30052008 The Nature of UE The longer the period of a UE, the more difficult it is to find a match. For example, the matching rate for a delay event 80 to 180 minutes - that is very long is very low compared to lateness or short period unavailability events. The reason is that during the long period there has to be more than one rescheduling and the distribution of duties varies from hour to hour. If, in all the hours, the number of duties are large then there is no problem in finding matches although it has to go through many rounds of rescheduling. One way to solve this problem may be to divide long periods into a few short periods and then do rescheduling to all the parts.

6.3.2 Rescheduling Speed

The rescheduling speed is measured as the time taken to perform the rescheduling process. Based on the results, the average time taken for a single event is 1.59 seconds and for multiple events is 1.31 seconds see Table 6.3. The average for Single Event is higher than Multiple Event. One of the reasons for this is that in Single Event there is more than one round of rescheduling and so it takes more time. This average time is considered quick for real-time environments. The analysis in Chapters Four and Five shows that the speed is dependant on the size of schedules; the larger it is, the longer it takes to perform rescheduling. The reason is all the agents have to negotiate with each other and so it takes more time when the number of agents crewsduties is large. Based on this evaluation it can be concluded that CRSMAS is capable of performing quick rescheduling in real-time. Table 6.3: Rescheduling Times of the Two Experiments Single Event Multiple Events Total Number of Events 486 6664 Total Time Taken s 366.35 8740 Average Time s 1.59 1.31

6.4 Proposed Modifications to CRSMAS

The previous section mentioned the weaknesses and limitations of CRSMAS, crew schedules and the nature of UE, that cause the percentage of matches generally to be low, and the section also suggested some improvements that may reduce the Abdul Samad Shibghatullah 138 30052008 weaknesses and limitations. In this section some modifications to CRSMAS are proposed, based on the analysis and evaluation in the previous section. The propositions are not tested. The details of the proposition are discussed below. CRSMAS is not capable of performing rescheduling in more than one round. More than one round of rescheduling is necessary when the period of UE is long, such as in a delay event. In the Single Event experiments more than one round of rescheduling was applied, but it was done manually which is slow and prone to error. The solution is either to automate the manual procedure or to add searching capability to the DA so it can find the next match the manual way is explained in detail in Section 4.2.2. In this research to proposition to solve this problem is to automate the manual way. Figure 6.2 shows the data flow diagram for the rescheduling process that incorporates more than one round of rescheduling. The process starts with the matching process, if there is no match then it will go to the next process, which is “Find Nearest Match”, otherwise the process will stop. In the “Find Nearest Match” process the user can specify how many times the system can go through the same process again L = looping, X=maximum number of loops. Otherwise, if there is no nearest match, then the loop will not stop until it reaches the maximum number of loops that was set by the user. Figure 6.3 illustrates the sequence of messages when there is no match and more than one round of rescheduling is required. It starts when a DA needs a driver crew to take its duty because the original driver is late or not available. The DA sends messages to all the CAs requesting a driver reqDriver message. In return, CAs will respond back to the DA respond message. Then the DA sends a detailed specification of the duty detailsSpec message. CAs that are available in this case CA2 and CAn for the duty will respond and matching will start beginMatching message. Neither of them CA2 and CAn will satisfy the requirements of DA. Since there is no match, the DA starts to find a nearest match findingNearestMatch message. If the CA matches to the nearest requirement then DA will put CA into reserve reserved message. DA will continue the matching process with the next CA and put the CA into reserve if it fulfils the nearest requirement. After all the negotiation, the DA will make a decision to choose the best one, which in this case is CAn, and it will receive an acceptance message from DA acceptMatch message. Abdul Samad Shibghatullah 139 30052008 Start Matching process Any match? Stop Find nearest match if L = X then match = Yes Yes Any match? Yes No No Figure 6.2: The Matching Process for More than One Round of Rescheduling One of the limitations of MAS is that it cannot simulate different types of event at the same time, because in different events there are different rules. In MAS, agents can only negotiate with one set of rules at a time. One way to deal with this is to run the CRSMAS in different windows for different events. However, there is a problem that multiple matches with the same crew may occur. So to control this we propose adding one attribute to CA, that is “Status”, that tells the user the current status of a particular crew. When there is a match the status is updated to “Not Available” in real time. As a result it will stop any matching processes for the particular crew which has turned to “Not Available” in other running windows. Abdul Samad Shibghatullah 140 30052008 DA CA1 CA2 CAn reqDriver reqDriver reqDriver respond respond respond detailsSpec detailsSpec detailsSpec beginMatching beginMatching noMatch noMatch findingNearestMatched noMatch findingNearestMatched reserved acceptMatch Figure 6.3: The Sequence of Messages for More than One Round of Rescheduling

6.5 Potential Beneficiaries of the System