EP1552446A1

EP1552446A1 - Method for loading flight schedule modifications

Info

Publication number: EP1552446A1
Application number: EP03760062A
Authority: EP
Inventors: Dietmar OFFICE MEDITERRANEEN DE BREVETS FAUSER; Edouard OFFICE MEDITERRANEEN DE BREVETS HUBIN; Renaud OF. MEDITERRANEEN DE BREVETS ARNOUX-PROST
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2002-06-18
Filing date: 2003-06-13
Publication date: 2005-07-13
Also published as: AU2003255699B2; AU2003255699A1; JP2005530243A; CN1662915A; US20050209896A1; US8069069B2; WO2003107229A1; BR0311873A; CA2488194A1; ZA200410128B; CA2488194C

Abstract

The invention concerns a method for loading flight schedule modifications in an air travel computerized reservation system, wherein: the flight schedule database is updated; the reservations concerned by the flight schedule modifications are reassigned to update the reservation inventory database. Said method for loading flight schedule modifications comprises the following steps: receiving at least one lot of modifications containing flight schedule modification data, retrieving individual modifications contained in the lot and storing in a register in the form of records for future scheduling, simulating reassignment of the reservations concerned by the flight schedule modification, by accessing with the reservation distribution server both the records and the flight schedule database, final updating of the flight schedule databases and of the reservation inventory. The invention is useful for updating databases during flight schedule modifications in computerized reservation systems.

Description

"Method for loading changes to flight schedules"

The present invention relates to a method for loading changes to flight schedules into a computerized air transport reservation system.

The changes of schedules in such systems require very important manipulations on the database of existing schedules. A flight plan describes how the air network is used by planes. The schedules are calculated in order to optimize the connections between flights, the use of airplanes and the occupancy of seats. The changes to be made to an existing schedule are therefore generally non-isolated changes which have a possible impact on connections with other flight operations.

Currently, flight schedules are subject to more and more reorganization given the increased competition, the need for agreement between the airlines and the sophistication of the IT resources used to establish the schedules. Usually, airlines apply schedule changes one after the other. During these changes, the person responsible for applying the changes has no knowledge of the existing seat reservations on the flights he is modifying. The air reservation inventory system applies changes to the planning database without being able to comprehend, overall, the number of changes and modifications that this entails. The current method of applying the changes in schedules one after the other has a first drawback which consists in the fact that the reservations already made are generally changed more often than necessary. This situation occurs in particular if the passengers are moved to another flight and the latter is subsequently subject to a change. In the latter case, the passenger's reservation must still be modified.

Changes to passenger reservations are costly as they involve manual intervention by travel agents, network and IT processing costs. Another disadvantage of the methods currently implemented is that the significant changes to be made to an existing planning database can take a considerable time since the repercussions on passenger reservations must be analyzed manually and on a case-by-case basis. The object of the invention is to provide a solution to the problem of flight planning modifications in a computerized air transport reservation system.

To achieve this, it proposes a new process in which the flight planning database is updated and the reservations concerned by the flight planning changes are reallocated for updating the inventory database. of reservation, in a particular way.

A first advantage of the invention is to deal with a plurality of flight planning changes in a global manner, which makes it possible to envisage reallocations of passenger reservations taking into account all of these changes, whatever the order of changes in the schedule modification file.

Furthermore, according to the invention, the schedule changes are applied by means of a simulation without final activation, which avoids the risk of disruption of the existing database before complete finalization and validation of the update.

To provide a global choice in the reassignment of passenger reservations, the invention allows the server to access both the existing database and new records corresponding to the future schedule that should be applied.

It will be noted that the efficiency gains of the invention are particularly significant, especially given the generally massive nature of the schedule modifications to be made. As an example, we can distinguish different types of schedule change procedures:

- seasonal changes which present massive schedule changes varying in size from 2000 to 8000 lines and which generally require validation by several bodies in the management organization of the computerized air transport reservation system,

- readjustments. Generally, these are changes affecting flights near a date of departure and for which the reallocation of reservations is particularly important and requires special consideration. - regular changes which can be made very automatically given their nature.

The present invention allows the loading of such changes whatever their nature and also makes it possible to manage a set of parameters for automating the updates to be carried out. In this context, we can easily adjust the level of manual control to operate for the changes to be taken into account.

Other objects and advantages will appear during the following description of a preferred embodiment of the invention which is not, however, limiting. The present invention relates to a method for loading changes to flight schedules into a computerized air transport reservation system, in which:

- the flight planning database is updated; - the reservations concerned by the flight schedule changes are reassigned for the updating of the reservation inventory database, characterized in that it comprises the following stages: - reception of at least one batch of changes containing flight schedule change data, extraction of individual changes contained in the batch and storage in a register as future planning records - simulation of reassignment of the reservations affected by the schedule changes, by access to the reservation distribution server both to the recordings and to the flight planning database, final updating of the flight planning and reservation inventory databases.

This process is advantageously presented according to the variants set out below and according to which:

- a graphical user interface is used to check the changes extracted from the change batch. - a graphical user interface is used for the validation of reservation reallocations.

- a characteristic suffix (SL) is assigned to the changes to be stored as future planning records (FSR).

- an argument (FSR is published) is assigned to each record (FSR) indicating whether this record (FSR) is made accessible to the reservation distribution server.

- for each change checked out: the flight periods in the flight planning database affected by the change are opened; - if the said period has not already been affected by a change whose argument (FSR is published) is positive, the said period is duplicated and the suffix (SL) is assigned to the duplicated period; we send a schedule change message to integrate the change into the duplicate period it affects; we indicate that the change is a record accessible to the reservation distribution server by putting its argument (FSR is published) in the positive state.

- during the reassignment simulation, the dependencies between records are updated, knowing that an A record depends on a B record if and only if the reassignment of the passengers during the application of the A record is made towards the future planning described in record B.

- in the event of a cyclical dependency between several records, during the execution of the reassignment operations in the reservation system, only one and only one modification is made to each reservation concerned by all of these reassignments.

- the records (FSR) are deleted after final updating of the flight planning and reservation inventory databases. The attached drawings are given by way of examples and are not limitative of the invention. They represent only one embodiment of the invention and will make it easy to understand it.

FIG. 1 schematically illustrates the configuration of different computer means able to be used to implement the invention. Figures 2 and 3 are block diagrams of various successive steps of the present invention.

Referring to FIG. 1, it has been illustrated that the method presented here can use an SLS schedule change server able to receive a batch of schedule change tasks to be operated. In addition, this SLS change server is accessible to a user such as an analyst or a supervisor via a GUI graphical user interface, in particular for checking the changes extracted from the change file constituting the batch of change tasks and for the validation of reservation reallocations. A part of the steps of the method of the invention can also be implemented in the distribution part of the reservation system at the level of the distribution server CS and of the existing database db1 comprising the inventory database of the reservations and the flight planning database. At the level of the SLS schedule change server, when a batch of changes arrives, it is possible at first, to check the integrity of the changes and any conflict problems, to test the automation rules and make the data accessible through the GUI graphical user interface.

At this stage, different automation criteria can be assigned to each batch of changes to be made. In particular, the automation criteria relate to the automation of schedule changes and the automation of reservation reallocations. Depending on the value of these parameters, the changes can be processed manually or automatically or even present certain manual steps and certain automatic steps.

Preferably, analyst speakers proceed to a validation step according to the processing and automation parameters which have been planned.

If necessary, a supervisor can also carry out a verification afterwards. These validation steps which lead to a signature of the analysts and the supervisor are shown in Figure 2.

At the end of these steps, it is possible to produce future planning records which can be used by the central system at the level of the distribution server CS. To this end, the various changes extracted from the batch of changes received in the form of future FSR planning records are stored in a register.

FSR future planning records are made accessible by the CS distribution server in the form of a publication. We describe a possible procedure provided for this purpose: we first determine the list of schedule changes that must be published as future FSR schedule records. In this way, we remove all changes that have no impact on the reallocation of reservations, in particular changes that only concern service updates such as the provision of meals on board aircraft. for each of the schedule changes in the list, we operate as follows:

• each FSR record is assigned a suffix SL which makes it possible to characterize it as a future FSR schedule record in relation to the other data accessible by the distribution server CS,

- an argument is assigned to each FSR record, for example called "FSR is published" indicating whether this FSR record has been made accessible to the reservation distribution server CS or not. If the argument “FSR is published” is true, it means that the FSR record is accessible,

- we note, in the existing schedule, the flight periods which are affected by the change in question. "for each of these periods concerned, we search if it is already concerned by a change of planning which would have an argument" FSR is published "placed in the true state. If this is not the case, we duplicate this period in assigning the suffix SL to it. If the argument "FSR is published" is already true for a previous change, it means that this period has already been duplicated. At this stage, the central system therefore has a duplicate of the current schedule with the suffixes SL.

• we then send a schedule change message for the data with the suffix SL, this message describing how the future schedule should be. The central system then has future schedules perfectly described in the periods considered to have the suffix SL.

- for this change of planning, the argument “FSR is published” is placed in the true state. These different operations are then repeated for all of the planning changes contained in the batch until they all have an argument "FSR is published" placed in the true state.

Following these steps, the central system, and particularly the CS distribution server, is able to access the records of FSR future schedules in order to find the best flight alternatives when booking re-allocations.

It is this stage which is then operated.

It will be described below in more detail in a preferred embodiment.

When it is finished and the update of the databases is final, it will be possible to erase the records of future FSR schedules.

A description will now be given more precisely of the steps for simulating the reallocation of reservations which precede the final updating of the flight and reservation planning databases.

The reservation system automatically chooses a reassignment option (for each change of schedule requiring it). This option is chosen from the FSR future schedules or the current schedules (for flights not affected by the current batch).

Once the reassignment options are automatically evaluated, the system checks them using the reassignment automation rules. Reallocations not satisfying these rules are subject to validation by an operator (who can then modify the options calculated automatically by the system).

When all reassignments have been confirmed, the actual application of the batch of changes in the reservation system can begin.

To this end, it should first be noted that the reassignment of passengers poses problems of dependence between flights. By dependence between two planning changes is meant the need, in order to make a change (S1 for example) concerning an F1 flight, to reassign certain passengers of the F1 flight to a future S2 planning concerning an F2 flight.

On the other hand, one can encounter cyclical dependency issues in which the dependence of flights is reciprocal.

In this context (for example suppose 2 schedule changes S1 and S2 concerning the flights F1 and F2 implying the reassignment of the reservations of F1 towards the future planning of F2 and the reassignment of the reservations of F2 towards the future planning of F1), it is advisable , during the execution reallocations in the reservation system, to modify each reservation only once and only once in the context of a batch of schedule changes (in order to avoid in our example that passages are reassigned to the future schedule of F2 then again to the future F1 schedule).

When executing the batch of schedule changes, the planning database is first updated.

The system then allocates a unique “I” operation identifier characterizing the current batch. The reservation system then receives all of the reassignment instructions as well as the operation identifier “I”. He must then guarantee the uniqueness of modification of each reservation in the context of operation "I".

A preferred embodiment of this constraint consists, for each modification of a reservation, of: - checking that this reservation does not have the "I" mark, in this case modifying the reservation then marking the modified reservation with the identifier "I". As reassignments are made, the inventory database is also updated. The three databases (inventory, reservation and planning) are then up to date and the FSR records can be deleted.

REFERENCES

SLS: schedule change server CS: db1 distribution server: existing database GUI: graphical user interface

Claims

1. Method for loading data relating to changes in flight schedules into a computerized air transport reservation system, in which:

- the flight planning database is updated;

- the reservations concerned by the flight schedule changes are reassigned for the updating of the reservation inventory database, characterized in that it comprises the following stages: reception of at least one batch of changes containing flight schedule change data, extracting the change batch from the changes it contains and storing in a register as future planning records (FSR) linking the future planning recording register (FSR) and the reservation distribution server, simulation of reassignment of reservations affected by schedule changes, by accessing the reservation distribution server both to the recordings (FSR) and to the flight planning database, final updating of the flight planning and reservation inventory databases.

2. Method according to claim 1 characterized in that a graphical user interface is used for checking the changes extracted from the batch of changes.

3. Method according to claim 1 or claim 2 characterized in that a graphical user interface is used for the validation of reservation reallocations.

4. Method according to any one of claims 1 to 3 characterized in that a characteristic suffix (SL) is assigned to the changes to be stored as future planning records (FSR).

5. Method according to any one of claims 1 to 4 characterized in that an argument (FSR is published) is assigned to each record (FSR) indicating whether this record (FSR) is made accessible to the reservation distribution server .

6. Method according to claims 4 and 5 in combination characterized in that for each change extracted: the flight periods of the flight schedule database affected by the change are opened; if the said period has not already been affected by a change whose argument (FSR is published) is positive, the said period is duplicated and the suffix (SL) is assigned to the duplicated period; we send a schedule change message to integrate the change into the duplicate period it affects; we indicate that the change is a record accessible to the reservation distribution server by putting its argument (FSR is published) in the positive state.

7. Method according to any one of claims 1 to 6 characterized in that during the reassignment simulation, each record is assigned a degree of dependence depending on the number of other cascading records for which an application of said record results a reassignment of reservations on said other records.

8. Method according to claim 7 characterized in that in the event of a cyclical dependency between several records, during the execution of the reassignment operations in the reservation system, each reservation concerned is modified only once and only once. by all of these reassignments.

9. Method according to any one of claims 1 to 8 characterized in that the records (FSR) are deleted after final updating of the flight planning and reservation inventory databases.