This section will present more details about the previously mentioned three steps for each type of disruption. Currently the system is capable of handling six basic types of disruptive events: new demands, patient goes ``sour'', delay mission, cancel mission, aircraft breakdown, and airfield closed. For each type of disruption, there is a set of assumptions that corresponds to the underlying model on which the system is based. These assumptions are used to implement a set of primitives actions used by the model update phase of the solution. The external disruptions map into a set of primitive update actions: delay mission-leg and cancel mission-leg. During the execution of these update actions, conflicts are identified and signaled. After the conflict analysis, conflict-solution primitives are executed until the system is in a consistent state. The conflict solution primitives are schedule patient, unschedule patient, and add mission-leg. The action of the conflict-solution primitives can also introduce new conflicts that will be identified and solved in a similar way. The problem solving cycle will stop when the solution is in a state in which all missions and scheduled patients have valid and no-conflicting routes: there are no gaps and no time overlaps in the routes and patients have the required support facilities added to their itinerary. Figure 5.1 summarizes the relation between external disruptions, model-update primitives, and problem-solving primitives.
Figure 5.1: Disruption Summary
The detailed behavior for each type of disruption is presented in the following paragraphs:
New Patients Introduced
New patients are added to the system by loading a file containing all the patient information. After the file has been loaded, the fact that there are unscheduled requests in the system will trigger the problem-solving control cycle. The system will try to allocate patients using the set of existing missions. Each scheduled patient will have an itinerary composed of mission-legs, that correspond to the allocation on airplanes, and medical treatments, that correspond to allocations in ASFs and MTFs. The general allocation behavior is: if there are feasible missions, patients are allocated on these; if not, and the new patients are ``urgent'', routine patients are ``bumped'' off their existing itineraries/flights to make room; if no other solution is possible, new (one-leg) missions are created. Existing missions are not modified. The new missions introduced by the system will take the patient from its origin to a destination with the required medical facility. If the user does not want the added missions, they can all be cancelled or cancelled on a case by case basis. The itineraries of the ``bumped'' patients are dealt with on a case by case basis. Rest-over-night on ASFs are introduced in the patient itinerary after the patient has flown a certain number of hours.
Figure 5.2 shows the system just after new patients have been loaded. All missions are empty and patients are unscheduled.
Figure 5.3 shows the system after patients have been scheduled. The patients use the aircraft capacity and the system indicates that some patients are late by using different colors to represent late patients.
Patient Goes ``Sour'' During Flight
The patient is removed from the plane (and from the system) at the next stop. We assume that the time the patient goes sour is specified. If the patient goes sour in the last leg of its itinerary, nothing will happen - the patient will go to the medical facility as a regular patient. No conflict is generated and no reaction is performed by the system when a patient goes sour. Figure 5.4 shows what happens when a patient goes sour during an intermediate leg and figure 5.5 shows what happens when it is the finale leg.
Figure 5.6 shows the graphical display for a patient's itinerary before she/he goes sour. Figure 5.7 shows the itinerary of the same patient after she/he goes sour. Notice that the part of the itinerary after the start time of the event is removed from her/his route.
We assume we know in advance the start time and expected duration of the delay. This type of event is translated into a set of delayed mission legs. The unconditional behavior of delaying a mission is that all legs starting after the beginning of the delay will have their start times shifted beyond the end of the delay. The legs that have a start time before the beginning of the delay are not changed. Mission delay will only introduce conflicts on the patient itineraries. Depending on the size of the delay, some patients will probably lose their connections. The system identifies all patients that would lose connecting flights and generates for each patient a new itinerary starting from the airfield she/he lost the connection. No complete rescheduling of patients will occur unless requested by the user. Figure 5.8 shows the general behavior for delaying a mission.
We assume we know in advance the cancellation start time. The unconditional behavior is that all remaining legs of the mission are canceled. A mission leg that starts before but ends after the cancellation time, is also cancelled. The cancellation will always generate an event to tell the system that a mission has an inconsistent itinerary. If no patients have been scheduled in the legs cancelled, no other conflict is generated and no problem-solving is needed besides the legs cancellation. If there are patients scheduled, the itinerary of each patient allocated to the legs cancelled will have a gap or will be incomplete. In this case, the system will also signal the inconsistency on patient's itineraries. If the mission is cancelled with a leg already in process, as for example when the destination airfield is closed, the analysis process will identify the need of correcting the leg in-process and a problem-solving method will be triggered to fix the mission leg. The default strategy in this case is to reroute the leg to an airfield closer to the previous destination. The correction of the mission leg takes precedence over the correction of patient's itinerary. After the mission has been fixed, the conflicts concerning patients will be analyzed and the itineraries will be fixed. Figure 5.11 shows schematically the cancelling of a mission when the leg is not in process and figure 5.12 shows the cancelling of a mission with the leg already in process.
Figure 5.13 shows the mission before cancellation and figure 5.14 shows the mission after cancellation. All legs after the start time of the cancellation are removed from the mission and patients are rescheduled later.
All affected mission legs are either delayed or canceled, the missions are repaired, and patient itineraries are repaired on a case by case basis. Several special cases exist for mission repair: (1) If the affected airfield is an intermediate stop on a mission, the legs flying into and out of this airfield are unconditionally canceled. A conflict will be generated and the analysis process will identify that there is a gap in the itinerary of the mission. A problem solving method will be executed to fix the mission. The default behavior in this case is to add one new leg to fill the gap. In this way, the closed airfield will be bypassed. The patients scheduled on the removed mission legs will be allocated in the new added leg. After the mission has been fixed, the patients itinerary will be fixed. Figure 5.15 shows the closing of an intermediate airfield.
(2) If the closed airfield is the final destination of a mission, the last leg is unconditionally cancelled; if the leg is already in progress, the analysis process will identify the problem and a problem solver will be called to fix the mission. The default behavior in this case will be to add a new leg having as destination an airfield closer to the closed airfield. All patients in the cancelled leg will be allocated in the new leg. After the mission is fixed, patients itineraries will be analyzed and fixed if necessary. Figures 5.18 and 5.19 show the closing of an airfield that is the final destination: in the first case, the mission-leg is not in process so no mission fixing is required. Patients' itinerary will need corrections. In the second case, the last leg is already in process: the leg is cancelled, a new leg is added, all patients are in the new leg.
(3) If the closed airfield is the first one on a mission, the entire mission is delayed until the airfield opens again. This is the same behavior as delaying. Figure 5.20 shows the mission delay when the origin airfield is closed.
The default behavior implemented in each particular case can be change by specifying different strategies. For example, we could establish that we want a new stop instead of bypassing a closing intermediate airfield or that we want the aircraft to return to its last departure airfield when the final destination gets closed with the mission in progress.
Aircraft Breakdown Introduced
This is similar to mission delay. If the problem occur during the execution of a leg, the aircraft lands at the correct destination of the in-process leg, after which all legs are delayed (again we assume the existence of a duration estimate for the problem). Patient itineraries are repaired on a case by case basis. An alternative behavior will be to add a new stop to the mission. The aircraft problem is presented in figure 5.21.
After the introduction of disruptive events and their translation to the internal problem representation a set of conflicts exists (e.g. patients missing their connection because of a delayed flight etc.). The problem-solving architecture is called to repair the schedule (i.e., to resolve these conflicts). The problem-solving architecture is also responsible for ensuring that all missions are temporally and causally consistent (for example, a leg cannot depart before the previous leg has arrived, and can only depart from the airfield where the previous leg ended). Mission fixing takes precedence over patient's itinerary fixing because the patient scheduler assumes that all mission in the system are consistent. As was mentioned before, the solution state update after a disruption and the subsequent problem solving techniques used are based on our assumptions of the model. It is easy to change the default behavior to comply to more accurate user requirements or more refined models.
All disruptions introduced are signaled, even if they do not introduce any changes in the solution. The system keeps track of all disruption events and changes caused by them. Reports summarizing the disruptions and affected objects can be generated at any time.