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:
Figure 5.2: New Patients in the System
Figure 5.3: New Patients Scheduled
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.
Figure 5.4: Patient Goes Sour During Intermediate Leg
Figure 5.5: Patient Goes Sour During Final Leg
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: Patient before going sour
Figure 5.7: Patient after going sour
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.
Mission Delayed
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.
Figure 5.9: Mission Before Delay
Figure 5.10: Mission After Delay
Figure 5.9 shows a mission before the delay and 5.10 shows the same mission after the delay. Notice how the mission-legs are right shifted and all patients are kept in the legs.
Figure 5.11: Cancel Mission - Leg not in process
Figure 5.12: Cancel Mission - Leg in process
Mission Canceled
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: Mission Before Cancellation
Figure 5.14: Mission After Cancellation
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.
Figure 5.15: Intermediate Airfield Closed
Airfield Closed
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.
Figure 5.16: Mission before closing an intermediate airfield
Figure 5.17: Mission after closing an intermediate airfield
Figure 5.16 shows a mission leg that uses an intermediate airfield. After the closing of the airfield and fixing the mission, figure 5.17 shows that the mission now bypasses the closed airfield.
Figure 5.18: Final Destination Airfield Closed - Leg not in process
Figure 5.19: Final Destination Airfield Closed - Leg in Process
(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.
Figure 5.20: Mission Origin Airfield Closed
(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.
Figure 5.21: Aircraft Breakdown with Mission in Process
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.
Figure 5.22: Mission before aircraft breakdown
Figure 5.23: Mission after aircraft breakdown
Figure 5.22 and 5.23 presents the mission before and after the aircraft problem.
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.
