SAREX (Swissair Aircraft Reassignmnets Expert System)
SAREX (Swissair Aircraft Reassignmnets Expert System)
Customer Swissair
Objectives
Development Status Developed and delivered a prototype in KEE on a TI-Explorer, during 1988

Highlighted features

1. INTRODUCTION

In an Airline all aircraft are under strict maintenance regulations with lead times in excess of a year. However, unexpected aircraft down-time is inevitably perturbing the maintenance schedules for both the affected and replacement aircraft. In rescheduling an airline fleet it is important, on the other hand, to maintain an even flow of aircraft through the hanger and on the other hand to maximise the potential use of the aircraft.
After a thorough analysis of Swissair Operations Control problems entitled UNISYS to build a prototype to solve this problem of reassigning aircraft within DC 10 fleet.

2. PROBLEM DESCRIPTION

The experts at the Operations Center (OPS) use as daily tool a table of the monthly assignments for the various fleets. The unexpected events that constitute the problems can be: delays, not planned maintenance requests, flight requests to service foreign carrier's commercial flights, and aircraft type changes within Swissair flights due to freight or other reasons.
The solutions of the experts must:
- find a replacement to the unassigned flights due to a delay or a failure in order to provide the continuous service and recover from delays;
- find the best way to reschedule the rest of the fleet in order to disturb the least the original planning and bring back the aircraft to the original rotations.

3. RESTRICTIONS FOR SOLUTIONS

The experts at OPS have restrictions that constrain the solutions found to a limited set. The main restrictions are:
- all flights should be departing in time
- no maintenance schedule violations should occur.
- the aircraft has to be brought back to the original rotation/assignments, as soon as possible.
- time to find a solutions is limited.

4. PROTOTYPE DESCRIPTION

4.1.Communication to host

The communication between SAREX and Swissair data-bases is carried through an IBM PC XT-286. This solution was taken as a temporal one. The communication with the IMSP 3270 terminal protocols, and a program written in BASIC to perform the emulation of manual transactions.

4.2. Knowledge bases

Besides the communications KB three other were built as a result of the knowledge representation structure decided.
The FLIGHTS KB contains the basic structure for units to be the parents of all flights and legs, included foreign carriers flights, being performed by Swissair during a specified time period. Each leg unit has properties as the airports of departure and arrival, times in GMT convention, duration of the leg, ground-time preparation for the flight, and some other information relevant to the obtention of the solution.
The REASS-FLEET KB contains all the fleets with their special properties and under the DC10 fleet we have all DC10s being considered in this pilot project. The properties of the aircrafts refer to their status and maintenance incidences. Information about passengers, freight, crew etc.., is also structured but not used yet.
The REASSIGNMENT KB contains some of the internal units needed in the reasoning to obtain solutions. The airports and all their characteristics are in this KB. The airport description will be used in later extension of the project when mixing different aircraft fleets within a solution will be considered.

4.3. User interface

The main user interface is the electronic work-sheet, which is a computer screen version of the work-sheet the experts are using today showing monthly flight assignments (Figure 1). Experts can retrieve information or perform certain actions via mousable images.
When entering a request 2 additional windows panes pop-up (Figure 2): a window to specify details of the request - requested aircraft, location, start and end dates and times; and a window for tracing the inference and asking questions to expert. The results -different schedule alternatives- can be examined in a listing or in the work-sheet, which then indicates changes with different font.

4.4 Procedure to find solution

As a result of an unexpected event some of the activities that originally were assigned to the exception aircraft will become unassigned.
The procedure searches for suitable, ready at the right place in right time, aircrafts to perform these unassigned flights. During this search the possible aircrafts are ordered according to principles applied by the experts. This ordering procedure determines the order in which the possibilities are explored. An example of a resolution path in one sample problem is shown in figure 3, where each node represents change in flight assignments.
The procedure is a depth-first search, that can remember path explored and determined possible, not-possible or abandoned because of constraints. A resolution path is determined possible if no legs remain to be assigned and no maintenance or other constraints have been violated. If by the end of the finding process the system did not arrive to a possible solution, the earlier abandoned path is pursued to see if a possible solution can thus be derived.

5. IMPLEMENTED FUNCTIONALITIES

The following functionalities have been implemented:

  • flights can be swapped within the appropriate fleet type
  • aircrafts are brought back to original rotations as soon as possible
  • no maintenance violations are allowed
  • user can control limitations like number of days involved, number of aircrafts involved, number of modifications to ground times
  • extra requests and current delays are treated
  • flight hour and cycle differences are calculated for each aircraft
  • asks user if type change DC10-30 <-> DC10-ER is allowed
  • ask user if DC10-ER is required to special flights
  • uses reduced ground times if allowed
  • after arriving to each solutions asks user if  he wants: to display the solution, to continue for next solution, to end the process
  • displays and prints out the solutions
  • normally finds the Expert's solution and others.

6. FUNCTIONALITIES TO BE IMPLEMENTED

The following functionalities are to be implemented

  • delays within the schedule
  • automatic changes in ground times under the minimum - the user has to specify the flights and the ground time
  • changes between different long-hole fleets
  • postponing the maintenance sessions
  • cancelling of flights

7. CONCLUSION

The following is a summary of conclusions for the first phase of this project:

  • The goals defined for this phase of the project have been achieved successfully within the work of 25 Unisys consultant weeks.
  • The system reschedules the DC-10 fleet when unexpected events occur, offering in most cases several solutions which the OPS experts can analyse, This provides an additional perspective for making decisions in the OPS center.
  • Results have been approved by the experts.
  • The knowledge base systems technology has proven to be suitable.
    • object oriented procedures were applied to find possible solutions
    • heuristic rules can be applied to the set of solutions to recommend the best one according expert's and other's criteria.

The project to realise a full production system will be started summer 1989 first by implementing separate systems to each long-hole fleet, and after by implementing swapping between different fleets


Sample Screens

Fig.1: The electronic work-sheet
Fig.1: The electronic work-sheet
Shows the assignments of Swissair DC-10 fleet. The swappings due to the requests are displayed in italic

 

[ TBD ]

 

 

Fig.2: Request information inserted and a simple trace of reassignments

 

 

[ TBD ]

 

 

Fig.3: Part of the resolution path searched while looking for solution



Return to the index