WO1998022923A1 - Terminal co-ordination system for airports - Google Patents

Abstract

In a terminal co-ordination system, the data required for the flight safety personnel to carry out their control activities, taking into account the flight schedule data for handling actual arrivals, departures and crossings, as well as all flight movements, are displayed on at least one monitor. The system is designed with a client-server technology. Servers (1) and clients (2) are interconnected by a LAN (6) (local area network) or WAN (wide area network). The disclosed system is designed as a multilayered system with a graphic interface. An object-oriented relational data bank which transmits to the monitor detailed time-related data is associated to a basic system based on flight schedule data and actual arrival, departure and radar information.

Description

description

Terminal coordination system for airports

The invention relates to a terminal coordination system

Representation of the data required for the control activity of the air traffic control personnel, including flight plan data for handling the current landings, take-offs and flights as well as all flight movements on at least one monitor, the system being designed in the form of client-server technology and server and client are connected by a LAN (Local Area Network) or WAN (Wide Area Network).

Terminal coordination systems have long been known in airport technology. The concept of a universal terminal coordination system is described in the brochure from Siemens AG "TECOS Terminal Coordination System" with the identification number 02963.0 from February 1996. It describes a database application based on the "Windows" operating system and the client-server architecture, which is used for coordination and administration of arriving and departing air traffic can be used in airports. Personal computers are used as clients, while the server requires a UNIX-based hardware platform. Current implementations run on a DEC-ALPHA-SERVER under the operating system OSF / 1. The necessary flight plans are managed in a database system. These flight plans are accessed via one or more client personal computers. The system also has various interfaces to external systems such as radar data processing or the ITOS accounting system for airports. For further details, reference is made to the brochure mentioned as well as the following further references on the prior art : TECOS system requirements, Siemens AG, versions 2.00 from 10.10.94 and 3.01 from 01.04.95, document no. 100; TECOS rough specifications, ISO GmbH Nürnberg, versions 2.00 from 01/18/95 and 2.01 from 01/25/95, document no. 400; TECOS detailed concept (client), ISO GmbH Nürnberg, version 2.00, document no. 500; TECOS, detailed concept (server), ISO GmbH Nürnberg, version 01.00, document no. 510; CCDS-SRDP Interface Control Document "Specification for the connection of Radar Data Prossesing System to the LATCC Code / Callsign Distribution System", Civil Aviation Authority London, August 1991, CAA Document No. 521.

It is an object of the invention to optimally design the system described in the Siemens brochure TECOS, identification numbers 02963.0, or similar, possibly small systems and special details of these systems and to make them applicable with particularly suitable technology. The special safety requirements of air traffic should be taken into account.

To solve the problem, it is proposed according to the invention in the context of the general inventive idea according to a first alternative of the invention in a terminal coordination system with the features mentioned at the outset that this is constructed as a multilayer system with a graphical user interface, a basic system based on flight plan data and current arrival and departure and Based on radar information, an object-oriented, relationally working database is assigned, which is designed to output time-related detailed data on the monitor. This lays the foundation for an apprenticeship on the detailed hardware and software design of an optimized, generally applicable terminal coordination system, which is particularly suitable for large airports. On this basis, the application software and the database can be Realize invention. Furthermore, the requirements for the hardware and software environment can be developed. An overview of the data flow that is necessary due to the conditions and other interfaces can be created.

In addition to flight movements according to instrument flight rules (IFR), flights according to visual flight rules (VFR) make up a significant proportion of traffic. In this regard, an advantageous embodiment of the terminal coordination system according to the invention is that it is designed to coordinate the flight movements according to all flight rules (IFR, VFR, Y, Z, etc.).

According to another embodiment of the invention, the synchronization and the data exchange take place with the aid of a signal queue, a cyclical query taking place in connection with client applications and an update of the display and the data content taking place in connection with changes to a flight plan. This opens up the possibility that the terminal coordination system according to the invention automatically outputs the flight plan data distribution and the updated display on the client's user interface.

In order to continuously provide the operator with an overview of upcoming flight plans, after a further training in the terminal coordination system according to the invention, all flight plans of an airport are stored (RPL-repetitive flight plan). Flight schedules can be carried out cyclically, in particular daily, weekly, weekly on certain days, etc. It is expedient that individual details such as the planned landing time, the planned docking time, the planned departure time or the like can be inserted with their details at any time in the flight plans to be processed and displayed. In order to there is always the possibility for the operator to update the data processing processes relating to the airport's flight plans.

According to another embodiment of the terminal coordination system according to the invention, flight plans and flight plan follow-up messages that are generated by other systems such as e.g. be sent to a preferably higher-level flight plan processing system or an AFTN (Aeronautical Fixed Telecommunication Network), processable and data relevant to the flight course that are entered during flight plan processing or arise as a result of the flow, e.g. Arrival and departure data, can be sent to connected air traffic control systems for further processing. In this way, the operator can save himself any other communication effort, such as telephoning or the like. An adaptation of the sending and receiving processes regarding flight plans and flight plan-oriented coordination messages to the standard AFTN or the standard CIDIN (Co mon ICAO Data Interchange Network) is advisable. The same applies to the OLDI standard with regard to flight plan-oriented coordination messages such as Takeoff time, landing time, SLOTS etc.

According to a further embodiment of the invention, aircraft-specific performance data can be stored and called up in a database table as part of the terminal coordination system. Among other things, this enables the advantage of facilitating the creation of new flight plans for VFR flights without an ICAO flight plan.

Assignments between the aircraft registration, the associated aircraft type and the associated weight class are particularly easy to record in the database if they are self-learning and self-maintaining over selectable time intervals. According to an embodiment of the invention, assignments between destination airports in normal spelling and the associated abbreviation can be stored both in the ICAO code (4 characters) and in the IATA code (3 characters) in a database table and called up in the system as well be maintainable.

In principle, the terminal coordination system according to the invention can be operated efficiently as an independent system. However, it is provided with interfaces to other systems, which increases the performance of all systems involved in a variety of ways. In particular, data relevant to arrival and departure is exchanged with an airport management system, in particular the ITOS, which is known per se. This management system is a Unix-based application for accounting and management of flight movements at airports. The application has a (Motif) interface as a graphical user interface. The flight plans and the required master data are stored and managed in a relational database system (Ingres, Oracle, Informix). ITOS also has various interfaces to external systems through which data from current flight movements or announced flight movements are exchanged and which can then be automatically processed.

This results in the further task of the invention, to design the terminal coordination system described in the Siemens brochure TECOS, identification number 02963.0, or similar, or even smaller systems, in such a way that they can also be used to manage an airport. The special accounting requirements of air traffic should be taken into account. To solve this problem, it is proposed according to the invention in a terminal coordination system with the features mentioned at the outset that it is used for data exchange with a system for business management, in particular billing, administration and planning of aircraft movements and / or supplies, is suitably trained at airports. The flight plans and the required master data can be saved and managed using an object-oriented relational database. It is particularly expedient if, after a further training, the terminal coordination system according to the invention is designed to work with times of use.

In connection with the Siemens TECOS brochure mentioned above, the cornerstone has been laid to fix in every detail a lesson for detailed hardware and software design of an optimal, generally applicable accounting system, which is particularly suitable for large airports. The teaching according to the invention can serve as the basis for the implementation of the respective interface in the terminal coordination system and in the airport management system. The data structures can then also be defined in detail. The main components of the interface are: Requirements for data exchange; Communication protocol; Input data.

According to a special embodiment of the invention, flight plans are created in the terminal coordination system according to the invention from data of the coupled (business) accounting system, which can then be further processed by the operator in the terminal coordination system. Conversely, the data received from the terminal coordination system can be used for billing in the airport management system.

To solve the problem of the invention, it is further proposed in a terminal coordination system with the features mentioned at the outset in the context of the general inventive idea that that it is designed to enable the coordination of incoming and outgoing traffic. In general, in generalizing the previously discussed alternative of the invention in connection with the airport management system mentioned, it is particularly efficient if the terminal coordination system has interfaces in order to be able to receive information about flight plan data from external systems. To this end, it is particularly advantageous to provide data from at least one radar data processing system, which is preferably connected via a LAN / WAN and between a server of the

Terminal coordination system and radar data processing. Call signals in the form of the (known) SSR code can be transmitted (SSR: secondary surveillance radar). The foundation stone has thus been laid in connection with the aforementioned TECOS brochure, identification number 02963.0

To put into practice the teaching of detailed hardware and software design of an optimal, generally applicable terminal coordination system, which is particularly suitable for large airports. This includes in particular the interface between the terminal coordination system according to the invention and a radar data processing system. The concept for this must be as flexible as possible in order to be able to be used in the different environments of different radar data processing systems. It is also important that the requirements for the interface implementation can be implemented for a wide range of basic hardware components. Additional interface requirements may arise in the future, and it must be possible to integrate them without changing the basic concept. In this regard, an embodiment of the invention consists in that the terminal coordination system can be configured in a wide range (relating to "timeouts" or error waiting times and supported services), specifically in With regard to the different interface requirements of different radar data processing systems.

The interface design based on the invention is tailored to the general requirements. Nevertheless, it is particularly suitable for the known radar data processing system "Watchkeeper-AP 100" (Siemens Plessey systems). The AP 100 system runs on a UNIX-based architecture (MOTIF application). It receives radar signals from different radar sources (up to two synchronously) and assigns the respective SSR codes (secondary radar signals) to the objects shown It can receive additional information for identifying the object from external sources such as the terminal coordination system according to the invention, on the other hand, this additional information is possible for external systems in the AP 100 system The main components for describing the interface between the terminal coordination system according to the invention and the radar data processing system are above all the requirements for data exchange, the mutual connection of the two

Systems and the communication protocol as well as input / output values. The person skilled in the art can easily derive the detailed data structures during the implementation. The present invention provides the basis for this or for the implementation of the interface in both systems.

According to an embodiment of the invention, the terminal coordination system is designed to work with a call character assignment to an SSR code. In other words, the communication between the radar data processing system and the terminal coordination system is mainly used to assign a callsign to an SSR code received by the radar data processing system. This enables easier identification of the object within the radar data processing processing system. In particular, a call sign request can be made automatically after an aircraft has entered a certain control room. In addition, some services for the system control (restart, free status) are necessary.

It is within the scope of the invention that the terminal coordination system has a control room monitoring system which differentiates between arriving, departing and passing objects, that is to say between relevant and irrelevant objects.

The terminal coordination system according to the invention is advantageously designed in such a way that it can be used to transmit schedule-related data for corresponding SSR codes. This opens up the possibility of relieving or completely avoiding other communication channels or systems.

Further features, details, advantages and effects based on the general inventive idea result from the following description of preferred exemplary embodiments of the invention and from the drawings. These show in:

1 shows a block diagram of the client-server model for the terminal coordination system according to the invention, FIGS. 2 and 3 each show a structural diagram of the software for the server or the client of the terminal coordination system according to the invention, FIG. 4 shows a data flow diagram as an overview of processing processes in the invention Terminal coordination system FIG 5 schematically the automatic reading procedure of the flight plan from the RPL (seasonal flight plan) 6 shows a top view of the work place mask for the operator screen of the terminal coordination system, FIG. 7 shows a representation of the work place mask corresponding to FIG. 6 with dynamically faded in fields FIG. 8 shows schematically the interface and the communication structure between the terminal coordination system and the radar data processing system,

1 shows the system architecture of the terminal coordination system with a division of the application into a server (service provider) 1 and a client part (service requester) consisting of several workstations 2. The configuration is preferably such that the server 1 exists exactly once in the system, while the client with its several workstations 2 can run several times. The same functionality is available on every client or workstation 2. The distribution of tasks between client 2 and server 1 and the synchronization of requirements is application-dependent and is explained in detail in the description of the processes. The system printer 3 shown is entered as a network printer, but can also be connected to one of the clients / workstations 2 or the server 1 via different configuration of the system software used (Pathworks, possibly Windows for workgroups) and then can still be addressed as a network printer. The server 1 for the terminal communication system according to the invention provides, among other things, the following services or interfaces: database server, internal services of the terminal coordination system for synchronization and for data exchange with the clients / workplaces 2, interface to an ITOS airport management system 4 (see FIG 1), interface to a radar data processing system 5 "Watchkeeper AP 100", creation of lists with all Guided flight plans of a day, time server. The tasks of the client workstations 2 in the terminal coordination system include the following: presentation of current and previously announced flight plans (arrival, departure, crossing), entry of new and modification of existing flight plans, implementation of status transitions in flight plans and updating of all displays after operator input, time synchronization with the Server. A LAN (Local Area Network) 6 can serve as the communication system between server 1, clients / workplaces / workplaces 2, system printer 3, ITOS airport management system 4 and radar data processing system 5. This can be based on Ethernet or TCP / IP.

According to FIG 2, the software structure of the server 1 comprises the following components: OSF / 1 (UNIX operating system), TCP / IP (network communication, part of UNIX), Oracle (RDBMS), TECOS (general server processes) and a time server. The corresponding keywords or abbreviations are noted in Figure 2.

According to FIG. 3, the software structure of a client comprises the following components: MS-DOS (operating system), MS-Windows (GUI), TCP / IP (communication), SQL / Net (Oracle database interface), ODBC (open database interface), TECOS ( Client application) and a time service requester. Corresponding notes are entered in FIG 3.

The following system is used for the server hardware: DEC 3000 model 300 LX APX with at least 64 MB main memory, at least 1 GB hard disk, 3.5 '' floppy disk drive, console, keyboard, Ethernet connection (for ISO: ThinWire), CD-ROM drive, DCF receiver assembly and tapedrive. The described expansion largely corresponds to the requirements of level 1. Only the CD-ROM drive is additionally required, since many system software packages are only delivered on CD-ROM. For further expansion stages, extensions may have to be made. The hardware described serves as the basis for the system acceptance.

The structure of the server with 64 MB of main memory is required for the required performance. If other applications such as e.g. the radar workstation AP100 expire, the main memory expansion must be at least 128 MB. The expansion of the hard disk capacity must also be adjusted.

IBM-compatible personal computers with the following configuration are used as client hardware: CPU 486 DX 2, at least 66 MHz, at least 8 MB main memory, mouse, keyboard, monitor (17 '' color monitor or 10, 4 '' TFT flat screen) , Resolution at least 640 x 480 dots), hard disk (optional), 3.5 '' floppy disk drive (optional), Ethernet card (for ISO: ThinWire).

According to the embodiment, the terminal coordination system is a server system based on the UNIX operating system, e.g. B. the operating system Digital UNIX with the network communication TCP / IP and the database Oracle working. The following software is required for the runtime system on the server: UNIX (DEC OSF / 1), Oracle Server, (consisting of RDBMS, SQLPLUS, PL / SQL, SQL / Net for TCP / IP). In addition to the runtime software, the following development tools are needed on the development system: C compiler,

C ++ compiler, precompiler C (Pro C) for Oracle.

According to a preferred embodiment of the terminal coordination system, the clients under MS Windows are with the Operating system MS-DOS ^" or Windows NT or Win 95 working. In detail, the client's runtime system requires, for example, the following software: MS-DOS, MS-Windows, TCP / IP (FTP OnNet), SQL / Net (TCP / IP) for Windows, ODBC driver for Oracle. In addition, a precompiler C and an MS Visual C ++ are expediently used for the development system. When developing workstation applications, it is advantageous to ensure that a simple migration to WIN95 ( 32-bit architecture).

With regard to data security, the measures available from the operating system are considered sufficient; special protection against viruses does not necessarily have to be implemented. Measures to protect against unauthorized software or against intrusion of computer viruses via the server (floppy disk, modem, other external interfaces) must be carried out using suitable additional measures through the type of installation (access protection). Special configuration and programming measures ensure that no other applications can be started on the client apart from the terminal coordination system application, which starts automatically when it is started. So the clients are limited to terminal coordination applications, whereby the terminal coordination user interface starts automatically when starting.

FIG. 4 shows an overview of an exemplary process model for the terminal coordination system according to the invention, it being possible for the required processes to be implemented both on the server and on the client. Out

For reasons of clarity, not all relationships between the database tables and the processes involved can be reproduced in FIG. The following applications are assigned to the client (s ⁾ : The TECOS process as a control and controlling interface including a graphical user interface; Processes with a control and controlling interface, including a graphical user interface, as well as an event handler or aircraft role processing, which run in a time-related manner, are arranged on the client. The following additional application processes are expediently set up on the client: event handlers (administration and coordination of database events) or aircraft role processing; "Time (client)" process for reading out the time from the assigned server time process.

The server requires the following processes for the first stage: "Timer" process, which in particular comprises starting time-controlled actions or procedures such as reading out the seasonal flight plan (RPL - Repetive Flight Plan) or archiving flight plans on ASCII files or changing statuses; Process "Dispatcher" which, if necessary, stores data via waiting queue tables (radar data processing queue-RDP-

Queue; ITOS queue to the airport management system) to external interfaces such as distributes the APlOO interface (data exchange with the radar data processing system AP100) and the ITOS interface (data exchange with ITOS airport); Process "DruckerServer" (processing of print jobs from the database table "PrintTable"); Process "time / server (reading the time from a DCF receiver); "Client Writer" process to serialize and monitor asynchronous access by several clients to a database.

The data exchange between processes generally takes place via database tables. A process that wants to make data available records a corresponding record in a table of the database, and the processes that this data read them from the database table again. The synchronization of the processes or the information about the existence of new or changed data takes place via database events that are managed by the database system. For this purpose, either signals or pipes are available at Oracle. Signals are passed on from the database system directly to the processes registered for the signal, while in the case of synchronization via pipes, the process must independently check the existence of new data in the pipe. Each process also has the functionality to be terminated via a special database event or pipe entry (either with or without user confirmation). Since the synchronization mechanism provided by Oracle does not offer sufficient functionality and performance or performance for all personal computer applications, all changes to flight plans are entered in a special signal queue. This is queried cyclically by the client applications. If changes are made to a flight plan, the display and the data content can then be updated.

According to FIG. 4, the following database tables are created in the terminal coordination system according to the invention: RPL table (seasonal flight schedule); FplInUse; FplSeqTable; WriteQueue; InUse (not shown); Printtable; Master data tables; List of errors; ITOS queue; RDP queue.

Additional database tables are required to implement the applications, but these are of minor importance at the interface level.

The RPL (seasonal flight schedule) stores all flight schedules that are carried out cyclically (daily, weekly, weekly on certain days). From this table the soon to be activated flight plans read and entered in the table "FplInUse" with the status "FplInStore".

The table FplInUse contains all flight plans that the operator is currently shown on the user interface in one of the areas "Approach" (PreannouncedApp, Approaching, Landed), "Departure" (PreannouncedDep, Departing, Airborne) or "Crossing". In addition, all flight plans are included, which are of the state "FplInStore", "FplCancelled" or "EndOfUse".

The following attributes are used:

Fplld key for access to FplInUse FplVersion Number of activation of this Fpl on this

Day Fpllndex Number of arrivals / departures of this Fpl

Note: FplVersion / FplIndex result in the ID number of an Fpl FplState State of the Fpl, here the list is also coded, in which the Fpl is displayed DeliveredFlag If set, Clearance Delivery was from

Operator given ArchivFlag The Fpl has already been transferred to the archive

According to specific application requirements for the system according to the invention, further attributes can be added.

Trigger or trigger conditions result from the following table, whereby an entry in the timer table is created or deleted after entry (insert or update) or delete under the following conditions:

After the "Insert" action, it must be checked whether the specified registration already exists in the aircraft role. If not, a corresponding entry is created. Before an update, it must be ascertained whether a timer may exist for the flight plan concerned The client applications use the following events, among other things, to update the corresponding lists: eOnlnsertFplInUse (parameter: Fplld); eOnUpdateFplInUse (parameter: Fplld); eOnDeleteFplInUse (parameter: Fplld). Default entries: none

The table "FplSeqTable" (see FIG. 4) stores information in the form of a linked list, from which the sequence of the flight plans in the database table "FplInUse" (or within the partial lists in FplInUse) can be generated, since this can be done from the Available time entries are not unique on their own, but are also influenced by the operator.

The following attributes are used: FplIdString - String of all Fpllds that are included in this list in this order; FplListe - identification of the list.

The following events are used by the client applications to update the corresponding lists:

eOnlnsertFplSeqTable (parameter Fplld) eOnUpdateFplSeqTable (parameter Fplld) eOnDeleteFplSeqTable (parameter Fplld)

Default entries: none

In the "WriteQueue" table, the connected client applications of the terminal coordination system changed flight plan data ^' entered. From here, the data can be further processed via the "Client Writer" process. The attributes applicable to "FplInUse" (see above) apply accordingly. Trigger condition or trigger: eOnlnsert- WriteQueue (parameter: Fplld). Default entries: none.

The "PrintTable" table is used to start a printer server that, depending on the job type / job number, extracts the data from a table, prepares it for printing and sends it to a printer. The "Direct printing" job type is used to select a freely selectable one Print text from a process (e.g. error messages). The following attributes are used: Order type - Determination of the type of the pending order (e.g. print out seasonal flight schedule or direct print order); Order number not used; Text - Text to be printed (only for direct print jobs). The event "eOnlnsertPrintTable" is used by the print server to process pending print jobs.

Various master data tables are used to adapt the functionality of the terminal coordination system to the local conditions of the airport and for all other administrative purposes, in particular: LfzRolle, StatlnfoTable, Usertable, LocalSsrCodeTable,.

The assignment "Callsign" (call signal) to the aircraft type (LfzTyp) and weight class is managed in the aircraft role (LfzRolle). In addition, this table contains all type / call sign assignments that the system automatically saved after a new entry by the operator ( self-learning part of the database), in particular the following attributes are used: Callsign, Type, Wtc, Auto-InsertedFlag, LastAccess, and other attributes for administration the role of aircraft. In order to be able to ^"recognize new entries in the role, the client applications use the following event in particular: eOnlnsertLfzRolle (parameters: Callsign, Type, Wtc).

The table: "StatlnfoTable" stores information that is to be displayed in the static information field. The following attributes are used in particular: QnhHpa, QnhHpaFlag, Qnhlnch, QnhlnchFlag, Qfe, QfeFlag, Wv, WvFlag, Rvr, RvrFlag, Tl, TlFlag, Sunrise , SunriseFlag, Sunset, SunsetFlag, Freql, FreqlFlag, Freq2, Freq2Flag, Remark, Rwy- UnUse, RwyllnUseFlag, Rwy2lnUse, Rwy2lnUseFlag The respective flags indicate whether the value is displayed in the static information field or not.

The "Usertable" table is used to manage the permissible users for a workstation on the terminal coordination system. The following attributes are used in particular: username, password. External conditions or triggers and events are not absolutely necessary

Find default entries Usage: Username: SYSTEM, Password: TECOS. The default entry cannot be deleted.

The "LocalSsrCodeTable" table is used by the terminal coordination system to assign a local (temporary) code for flight plans without an SSR code. The code remains valid until the flight plan comes to the "FplInUse" state or (when connected to a radar data system) until the code is reported as no longer used. The following attributes in particular are used: SsrCode, InUseFlag.

Information about the time and the action required for the timer process is stored in the "Timertable" table. Attributes include, in particular, those for managing the timer mer and the associated actions required use. To update the management of the timers, the events "eOnlnsertTimerTable",

"EOnUpdateTimerTable" and "eOnDeleteTimerTable" received by the timer process. In particular serve as default entries

"Generation of archive data" and "Rpl readout in FplInUse".

The table "Error list" contains the 2nd and 3rd order error messages. In Figure 4, not all processes are entered as data sources for this table for reasons of clarity. In principle, however, each process can enter a detected error there. In particular, the following attributes are used:

Process (Id) Name or Id of the entered process Error class Info about the type of error (error 2nd or

3rd order, monitoring) Originator For 2nd order error: Login name of the triggering process Host For 2nd order error: Host name of the triggering process ErrorNumber For process (Id) unique error number Timestamp timestamp, current time as the

Error was detected Text Description of the error

The following events are used in particular: Each new entry must be reported to the client applications together with the total number of entries; For 2nd and 3rd order error messages, a print job must be initiated, which is done using a database procedure; when entering a 2nd order error, a timer has to be started which converts the error into a 3rd order error if necessary; if a 2nd order error is deleted, this timer must be be deleted. Default entries are not absolutely necessary.

In the two tables "ITOS queue" (airport management system queue) and "RDP queue" (radar data processing queue) the dispatcher process enters the flight plan data as required, which must be transmitted to the corresponding remote system. In particular, the attributes named for "FplInUse" are used. Events are: eOnlnsertltosQueue, eOnlnsertRdpQueue. Default entries are not absolutely necessary.

The processes are described in more detail below:

If necessary, initializations for processes are parameterized via .CFG files (UNIX) or .INI files (MS Windows). Configuration files must be in the same directory on the hard disk as the executable and have the same file name with the extension "CFG". Initialization files are generally in the Windows directory and also have the same name as the executable file. Since the same ini- If the file is used, the configuration is identical at each workstation. If there are no initialization entries, the process takes the specified default value. If no default value is defined, the startup of the process is aborted.

For actions that have to be carried out once or in a certain cycle at a certain point in time (absolute), a timer process is implemented that triggers the corresponding actions. The advantage of this method is, among other things, that after a system failure and subsequent restart, actions can be made up for, so they cannot be lost. It is also easily possible to to link controlled actions to the entry in database tables.

Configuration table:

The following should be noted with regard to the interface of the timer process: The timer process distinguishes between two different types of timers: cyclical and non-cyclical. Cyclic timers are those that should trigger an action after a certain time and are then started again should. These are a ^'lso not played after performing the action from the timer table and it is only the time entry, but not the date evaluated. Non-cyclic timers are those that should only execute an action once and that should be deleted afterwards. At the start of the process or after a timer has expired, the timer process always searches for the next timer that will expire due to the execution time. Depending on the type of timer (cyclical or non-cyclical) and the current time, different actions are required:

The same actions are carried out after a change in the timer table (insert, update, delete).

After executing an action, a non-cyclic timer is deleted from the table.

In particular, the following actions are implemented: reading out Fpl's from the RPL for entry in the preannounced list for arrival or departure; Creation of an ASCII file with archive data, automatic maintenance of master and archive data; automatic change of Fpl states; convert a 2nd order error to a 3rd order error.

The following should be noted for the automatic reading of the RPL (seasonal flight schedule): For each entry in the RPLTable there is a (non-cyclical) entry in the TimerTable that contains the Fpl transfers the status to InStore. Then, if necessary, a new timer entry is created if this Fpl has to be activated again (eg the next day).

The following parameters are required to automatically read the Fpl's from the RPL: PreRead, Delta, FplFilledTil. These parameters are included in the corresponding timer entry and are transferred when the action (procedure) is called.

The parameters are set when the system is installed.

5 shows the use of the parameters: PreRead indicates which period (from the activation period) is always stored in the FplInUseTable, Delta indicates the intervals at which the procedure is started. The parameter FplFilledTil is required for the internal administration in order to show the program from which point in time the FplInUseTable has to be filled (important after system failure or restart).

After filling up the FplInUseFplTable, the procedure creates a new entry in the timetable that starts the procedure again after the delta period.

Algorithm in pseudocode: if FplFilledTil <NOW

Begin = NOW ice

Begin = FplFilledTil End = NOW / PreRead / Delta

Select Fpl from RPLTable where

(EOBT> Begin or ETA> Begin) and (EOBT <End or ETA <END) ActivationTime = NOW Delta: CreateNonCyclicTimer (PreRead, Delta, FplFilledTil, ActivationTime)

The generation of archive data and the automatic maintenance of the master data is carried out as follows: With a cyclic timer (delta = 1 hour), flight plans that meet the archiving criteria are transferred to a separate table. The flight plans are archived from this table once a day in an ASCII file. A new archive is created for each day.

Archiving criteria are:

State = EndOfUse and time> = LeaveCtrCross / Onb / EndOfUse + lh, ^•

State = Canceled and time> = cancel + lh State = FplInStore and time> = EOBT / ETA + 12h

It is also checked which flight plans have to be deleted from the FplInUse, InUse. Deletion criteria are:

Condition = EndOfUse / Canceled after 24h

State = FplInStore after transfer to the archive

In addition, it is checked which flight plans were no longer used by the one automatically included in the master data. These are deleted in order not to make the scope of the master data unnecessarily large.

Automatic change of flight plan states: For flight plans in certain states, the change of the state to a subsequent state or the generation of a flight plan with a new index and the saving of the old flight plan in the table FplInUse are carried out by timer-controlled actions. Converting a 2nd order error into a 3rd order error: If a 2nd order error on the client that triggered the error has not yet been acknowledged after a timeout, the entry in the error list is automatically converted into a 3rd order error converted.

A separate process is available for processing print jobs that are initiated on the server and for time-consuming print jobs that are initiated by the client (eg printing out the seasons flight plan). Jobs to the printer server are started by entering the job in the "PrintTable".

Configuration:

The following types of orders are implemented: printing the seasonal flight schedule; Print the lists displayed on the screen (FplInUse without Fpl's in the FplInStore state); "Direct" printing of a text.

According to the concept of the invention, the external interfaces in the terminal coordination system are implemented as openly as possible and independently of the environment used. To achieve this, an RPC interface is generally assumed. The use of this standard ensures that the different systems can be realized completely independently of each other. The implementation effort is minimized by the tools for RPC programming available for almost all hardware platforms. With regard to the interface to AP100 in particular, RPC enables machine independence. This means that the two systems can run both together on one machine and (for performance reasons, for example) on two separate systems that are connected via LAN. A change in the software is not necessary for this. For the implementation of the external interfaces, the processes <SS> Client and <SS> Server are implemented for each external interface at TECOS.

Task of TecosRpcClient is data that stems to external Sy ^¬ to be sent to read from the database and transfer to the recipient. For this, a suitable Rpc server must be implemented on the receiver side. The RPC client is only required for those external interfaces for which TECOS serves as a data source.

General configuration

A separate RPC server of the terminal coordination system is required for each external interface via which TECOS is to receive data. This ensures parallelism when processing different Rpc calls on the different interfaces. General configuration

For the APIOO interface and for data exchange between the terminal coordination system according to the invention and the radar data processing system and for the necessary services between these two systems, the following is carried out:

If an aircraft is detected in the radar data processing system but is not assigned a call signal and is located within an area of interest defined as an area of interest, a request is sent to the terminal coordination system to transmit an associated call signal back. As soon as this is available, the terminal coordination system explicitly acknowledges the request and sends the call signal back. If an associated call signal is not present, the terminal coordination system sends back a negative answer. A circle around the center of the working area of the radar data processing system is used as the "area of interest" and is defined accordingly within this system. Only the radar data processing system requests call signals from the terminal coordination system, not the terminal coordination system from the radar data processing system when the aircraft approaches as well as when it departs, the call signal request is sent. The following cases arise when a call signal request is sent:

An aircraft approaches the control zone of the radar data processing system from the outside. This can either be an approaching aircraft or a cruising / crossing flight. Corresponding SSR codes may be available in the terminal coordination system. If the SSR codes are not available, the call signal service receives a negative answer.

An aircraft flies from the airport and appears in the radar data processing system. For this flight, a flight plan (and a call signal) will (normally) exist in the terminal coordination system.

Since the operator in the terminal coordination system has the option of changing a call sign within a flight plan, this must be signaled to the radar data processing system. A special measure must be carried out in the terminal coordination system if an SSR code has been changed in an existing code / callsign pairing. The change in the call signal is transmitted from the terminal coordination system to the radar data processing system. It includes both the call sign and the associated SSR code as parameters. The response from the radar data processing system is either positive (the change has been accepted) or negative, which means that the SSR code was not available in the radar data processing system. It follows from this that a change of call sign is possible in the terminal coordination system according to the invention, in particular after a change of assignment SSR code / call sign. According to another embodiment, local SSR codes can be called up from an SSR code memory under administration with the system according to the invention. Since the terminal coordination system has the property of assigning SSR codes from a local code pool, these local codes must be released for the next use as soon as they are no longer required. These local SSR codes are used for flight plans that are not managed by a central coordination office or that do not receive a centralized SSR code. It is the job of the application in the terminal coordination system to manage these local SSR codes and to guarantee that they are not used twice at the same time. It is therefore necessary for the radar data processing system to transmit an "release code" message to the terminal coordination system if (after a timeout or an error waiting time) an SSR code is not received in the region of interest of the radar data processing system. This message is sent by the terminal coordination system accordingly interprets that the SSR code in the area covered by the radar data processing system is no longer in use. If the signaled SSR code comes from the local pool, it is released for further use. So if there are no response signals, a predetermined time is waited before an error signal is output.

The fault latency within the radar data processing system is necessary to ensure that the signal has not only been lost due to poor radar conditions. In the terminal coordination system, special measures must be taken to ensure that every local SSR code used is released after a fault waiting time due to a possible failure of the radar data processing system. According to an embodiment of the invention, the terminal coordination system is provided with a cyclical function check, the server and the local network (LAN) being queried cyclically with regard to their function, for example by an insignificant signal. So in order to check the correctness of the communication between the terminal coordination system and the radar data processing system, the systems exchange test requests and responses to check whether the remote system is still available (or to recognize that the remote system is no longer available). . The redundant requests are sent periodically from the terminal coordination system to the radar data processing system.

After further training, the terminal coordination system carries out a new memory content structure and a call sign structure etc. after a malfunction. In the special situation in which the terminal coordination system was restarted or in the event of a communication failure (useless error waiting time or no response), a separate procedure is provided to indicate to the radar data processing system that the code / call signal pairing in the radar data processing system is invalid . The clarification of the database display is sent from the terminal coordination system to the radar data processing system. It contains no additional data. The radar data processing system must clear all code / call signal pairings. Conversely, the radar data processing system will request all missing assignments from the terminal coordination system. In special local situations (eg after a new start), the radar data processing system can also decide that the local database is invalid and must be clarified. In such a case, it will request any missing call signals using the call signal request procedure. When a flight plan is canceled within the terminal coordination system, a delete callsign request is sent to the radar data processing system to indicate that a possible association of a code with a call signal in the radar data processing system is invalid. The same request is sent to the radar data processing system when the operator of the terminal coordination system has changed the SSR code for an existing flight plan. Upon receipt of a request for call signal cancellation, the radar data processing system will normally delete the local code / call signal assignment. If the code is received again by the radar data processing system, it will be requested again.

The following is carried out in particular regarding the interface between the radar data processing system and the terminal coordination system and the communication protocol between the two:

Communication between the two systems is based on the RPC (remote procedure call) procedure. This means that a separate procedure runs on the RPC server for each service, which is called by an RPC client. The RPC-based data exchange offers the following advantages: Secure data transmission using LAN communication; the local data representation is independent of the external data representation, RPC tools (compilers) are available for most hardware platforms and operating systems; the real system distribution is hidden from the applications (which means, for example, that the radar data processing system can run on the same system or on a different system than the terminal coordination system without modification of the application); Extensions and modifications to the Interfaces are easy to integrate into the existing systems.

An RPC server is available for RPC communication, which provides a well-defined service (procedure). This service is called by an RPC client. The input data required by the procedure is provided by the client. The return values of the procedure are made available by the server. Error handling (if, for example, no server exists for a requested service) is carried out by the underlying software, which transfers the corresponding values.

The following table shows the services required for the interface between the terminal coordination system and the radar data processing system and where the service is available:

6 shows the RPC calls within the

Interface between the terminal coordination system TECOS and the radar data processing system RDP is shown.

The following must be carried out for the interface for the server procedures: The RPC program is declared for the RPC server of the terminal coordination system in the following way:

program TECOS_RDP_PROG { Version TECOS_RDP_VERS {

<RPC Server procedures>

} = 1

} = <program number to be agreed later>

This program contains the procedures that are required for the geforder ^¬ th server functionality.

The following must be carried out for call sign requirements: For the radar data processing system, a code / call signal pairing for its local database is desirable. Exists an activated flight plan in the database of the Terminalkoordi ^¬ nation system corresponding to the requested SSR code, the corresponding call signal is returned if availability bar. If a code / call character pairing is not available in the terminal coordination system database, the status returned will indicate this situation. Zeitbedingun ^¬ gen: In the case of "call sign is not available," the request is normally transmitted back from the radar data processing system after a timeout period.

Input parameters Data type Remark

Return values

Status enum (to be defined later - display whether the request) was successful

Call sign pairings char (7) only 7 letters / characters (A ... Z, 0 ... 9) permitted for call signs

No restrictions The following is carried out for the release code: The radar data processing system must release Ssr codes which are in its local database and which are no longer obtained or are outside an area of interest.

Time conditions:

RDP: The Ssr code must lie outside the area of interest within the radar data processing system or is no longer received.

Terminal coordination system: If the Ssr code is not a local code, no action is taken. Otherwise, the Ssr code is returned to the local Ssr code pool after an error waiting time. This error waiting time is configurable between one minute and 32768 minutes.

Restrictions: none. If the lost code is not known within the terminal coordination system, the request is ignored.

The following is carried out on the radar data processing system server for the RPC procedure: On the radar data processing system side, the RPC program is declared as follows:

RDP_TECOS_PROG program {

Version RDP_TECOS_VERS { <RPC Server procedures>

} = 1} = <program number to be agreed later>

This program contains the procedures that are required for the required server functionality.

To request a change in the call sign, the following is carried out: A code / call sign pairing was changed in the terminal coordination system. If the Ssr code is not known in the local database of the radar data processing system, the request is ignored. Otherwise, the new assignment replaces the old entry in the local database of the radar data processing system. Time conditions: none

Restrictions: none

The following is carried out for the redundant request: The terminal coordination system must transmit a redundant request on a cyclical basis. This is used to check the communication interface. The status transmitted back will indicate the status of the line or of the radar data processing system. If the status is a pro- blem indicates, the "Terminal coordination system will generate an appropriate error message (class 3) to inform the operator of the exceptional situation.

Time conditions: The interval for the transmission of redundant requests can be configured in the terminal coordination system in the range from 1 to 32768 minutes. The server must check whether the redundant request is being transmitted. If the redundant request is not received for a fault wait within a (locally defined) period, he will clarify his local database and try to re-establish the connection to the terminal coordination system by sending call sign requests for received Ssr codes.

Restrictions: none.

With regard to the request for clarification of the database, the following must be carried out: In special situations (for example after a restart), the terminal coordination system transmits a request for clarification of the database to the radar data processing system. This means that the local database within the radar data processing system (from the point of view of the terminal coordination system) is invalid and should be deleted. It can in turn be loaded by the radar data processing system by following the procedure for the call sign ^" is used. Time conditions are not absolutely necessary.

Restrictions: none.

With regard to the request for deletion of the call sign, the following is carried out: After the deletion of a flight plan in the terminal coordination system, the deletion of the call sign is requested. If an assignment exists within the local database of the radar data processing system, this assignment is removed. If the Ssr code is received again, it can be requested here from the terminal coordination system. Time conditions are not absolutely necessary.

Restrictions: none.

The following is an explanation of the interface to the ITOS airport management system: The exchange of data between the terminal coordination system and the airport management system essentially takes place for the following reasons: In the terminal coordination system, flight plans can be created from data of the accounting system, which can then be further processed by the operator in the terminal coordination system. In the ITOS airport management system, the data from the terminal coordination system can be used to create the settlement.

The following is an overview of the services that are required between the two systems.

Approach:

A flight plan with an "Estimated Time of Arrival" is entered or changed

"Ten Miles Out (TMO)" is entered in a flight plan

A "First Contact" time is entered or changed for a flight plan.

An "Actual Time of Arrival" is entered or changed in a flight plan.

A "low pass" time is entered or changed in a flight plan.

A "touch and go" time is entered or changed in a flight plan.

An "EndOfUse" time is entered or changed in a flight plan (corresponds to "On Block"). A flight plan is brought into the "FplCancelled" state.

Departure:

A start-up given time is entered or changed for a flight plan

An "Actual Time of Departure" is entered or changed in a flight plan

A flight plan is brought into the "FplCancelled" state.

If one of these trigger conditions occurs, sends the Ter ^¬ minalkoordinationssystem one of the following requirements for the ITOS airport management system: FplApproachData, FplDe- partureData, FplCancel

The requests "FplApproach or" FplDeparture "are used to transfer new or changed flight plan data to ITOS airport. It should be noted here that it is not differentiated whether a flight plan has already been transferred to ITOS airport or whether the flight plan was first sent to ITOS flight A key that is unique from the point of view of the terminal coordination system is used for identification. An FplCancel request is generated by the terminal coordination system when a fluplan of the terminal coordination system database is brought into the state FplCancelled.

The ITOS airport management system sends data to the terminal coordination system under the following conditions: For an entry "in the daily flight schedule one hour before" Scheduled Time "

For an entry in the daily flight schedule one hour before "Estimated Time"

If an entry in the daily flight schedule is deleted, the data of which was previously transferred to the terminal coordination system.

The following requirements are used: FplApproachData, FplDepartureData, FplCancel.

FplApproachData or FplDepartureData is used to transfer new or changed flight plan data to the terminal coordination system. A key is used for this, which is unique from the perspective of ITOS Airport. An FplCancel request is generated by ITOS Airport when a flight plan is deleted from the daily flight plan.

The protocol or the communication between the terminal coordination system and the airport management system is based on the procedure "RPC" (remote procedure call). This means that for each request there is a separate procedure on the RPC server which is called by the RPC client becomes.

The following table provides an overview of the services that are available at the interface between the terminal coordination system and the ITOS airport management system:

Subsequently, the ^"interfaces of the RPC server pro- cedures are described on the side of the ITOS-Flughafenverwal- processing system, the RPC program is declared as follows.:

Program ITOS_TECOS_PROG {version ITOS_TECOS_VERS {

<RPC Server procedure>

} = 1} = <program number to be agreed later>

The following is carried out for the "FplApproachData" service: In the terminal coordination system, an approach flight plan is brought into a state which meets one of the trigger conditions mentioned above and which must therefore be transmitted to the ITOS airport management system.

The following is carried out for the "FplDepartureData" service: In the terminal coordination system, a departure flight plan has been brought into a state which meets one of the trigger conditions mentioned above and which must therefore be transmitted to the ITOS airport management system.

Restriction: none.

The following is carried out for the "FplCancl" service: In the terminal coordination system, a flight plan was brought into a "FplCancelled" state.

Restriction: none, On the terminal coordination system side, the program for the RPC server is declared as follows:

program TECOS_ITOS_PROG {

Version TECOS_ITOS_VERS {

<RPC Server procedures>

} = 1} = <program number to be agreed later>

The following is carried out for the "FplApproachData" service: In the ITOS airport management system, an entry was made in the daily flight schedule that meets one of the trigger conditions mentioned above and which must therefore be transferred to the terminal coordination system.

Restriction: none

The following is stated for the "FplDepartureData" service: An entry in the daily flight schedule was made in the ITOS airport management system that meets one of the trigger conditions mentioned above and which must therefore be transferred to the terminal coordination system.

Restrictions: none.

The following is carried out for the "FplCancel" service: In the ITOS airport management system, an entry was deleted from the daily flight schedule.

Restriction: none

The following requirements are placed on the time used in the terminal coordination system: The time server reads the valid time from additional hardware for receiving the DCF signal and cyclically synchronizes the server's internal clock with the value of the DCF hardware. A conversion to UTC must be carried out beforehand. The client synchronizes its own (local) time with the server during startup and then at configurable intervals. This ensures ensures that all client PCs are provided with the same time and that timestamps for flight plans that were created by different clients still reflect the correct order. In the terminal coordination system, times are always given in UTC.

The following applies to the functionality of the server: The time is read from the DCF77 receiver in cyclical intervals in the server. The hardware clock of the server is adapted to the time read. If errors occur, they are entered in the database (error list) and thus displayed on the client. For the configuration, please refer to the table below:

The following is carried out for the functionality of the client: To synchronize the client with the time of the server, a separate personal computer application is used which cyclically reads the time using the existing TCP software and sets the local time accordingly. The time client reads the current time from the server when it starts. If the time is not available from the server, the client uses his local clock. This error situation is displayed as a 1st order error. The application is started automatically when the application of the terminal coordination system is started. For the configuration, please refer to the table below:

With regard to the application functionality of the terminal coordination system, the following is carried out: In this context, "terminal coordination system application" is always understood to mean the application that runs on the personal computer and that contains the graphical user interface for the operator to manage active flight plans and to carry out corresponding status transitions. In addition, the various tasks for the administration and maintenance of the master data as well as some general functions are included. The clients are limited to the terminal coordination applications, whereby the terminal coordination user interface starts automatically when starting .

So this application (except for a super user) runs exclusively on the client PC, whereby the terminal coordination user interface starts automatically when it is started. When the application is started, the table of active flight plans is read from the database and displayed in the corresponding lists. These lists cannot be closed by the user and cannot be covered. An additional entry in the FplInUse, which defines the order of the entries, ensures that the display of the lists is the same on all client PCs. Reordering or other changes to a table entry lead to an entry in the signal queue, which causes all other active clients to update the lists.

For the configuration, please refer to the table below:

All via entries are structured as follows:

Entry = <RunwaySystem>, <Name>, <Name in opposite direction>, <Alternative in the second lane system>,> Opposite direction in the second lane system>, <Place round identifier> Missing alternatives are parameterized using empty entries.

The following is carried out for error messages and error handling:

In the terminal coordination system there are the following different error data or unusual conditions:

• An error occurred while operating by the operator on the client either locally or on the server

(1st order error)

• An error occurred when processing an order that was initiated by a client and was processed asynchronously on the server (2nd order error)

• An error occurred when processing a job that was not explicitly triggered by an operator (for example when receiving data via an external interface) (3rd order error)

• An error was detected when monitoring an external system (e.g. DCF receiver) (monitoring)

All errors except 1st order errors are entered by the process that detects the errors in the DB table error list. 1st order error messages are not entered in the database. With a corresponding entry in the

SignalQueue informs clients about the errors. With a separate menu entry, the list of all pending the fields 2nd or 3rd ^" order and monitoring are displayed.

1st order errors can occur both on the client side and when executing a client job on the server side. On the client side, these include input errors, communication errors, local errors (hardware), etc. On the server side, these include temporary errors when accessing the database (e.g. readlock set) or communication errors. The occurrence of a 1st order error is displayed because the execution of the triggering job is always synchronous, after detection of the error at the workplace that triggered the misconduct or that affects the misconduct. The display always takes place locally in a pop-up window, which must be acknowledged by the user before further actions are possible.

In contrast to first-order error messages, it is no longer possible to assign the error message to the action to be triggered in the case of second-order error messages because the job that led to the error was carried out asynchronously. This means that the client who initiated the processing can already do other work while his job is being performed on the server. In order not to interrupt the current processing in this case, the occurrence of such an error is displayed below the flight plan lists in the output field for 2nd and 3rd order error messages. The error is deleted from the error list by acknowledging the error (OK button). 2nd order error messages are only displayed on the client that triggered the error. If a 2nd order error is not acknowledged, it is converted to a 3rd order error after a timeout. The entry of a 2nd order error in the error list is automatically logged on the system printer. Third-order error messages are characterized in that the associated errors cannot be directly assigned to operation by the user, but rather arise from an error in an autonomous action in the server. This can be the case, for example, if an error occurs when receiving data at an external interface. The occurrence of such an error is displayed for each client below the flight plan lists. The display of 3rd order errors can be deactivated by local configuration for the duration of a session (login / logout). In this case, only the number of 3rd order errors that have not yet been acknowledged is displayed. Errors that have been acknowledged by an operator (OK button) are deleted from the error list. The display of 3rd order errors can be forced by changing the local configuration. The entry of a 3rd order error in the error list is automatically logged on the system printer.

All errors that do not occur due to an action on an interface or the like, but that can be identified due to a failure (eg hardware) are classified in a "Monitoring" category. In contrast to 3rd order errors, the error cannot be acknowledged here and be deleted because the error situation is only remedied after the failure.

In contrast to monitoring, 3rd order errors correct the error situation at least until a new job of the same type is to be carried out. Monitoring is also entered in the error list and treated as 3rd order error with the exception that it is not deleted from the error list. This means in particular that the occurrence of the error is displayed as a 3rd order error. The deletion from the error list is done by the monitoring process ^" when the error condition disappears. To indicate this to the operator, the removal of the error condition is treated as 3rd order error. Both the entry and the deletion of a monitoring in the error list is automatically logged on the system printer To be able to display the list of currently available monitoring messages after acknowledging a monitoring, a separate entry is available in the management menu, via which all entries in the "Monitoring" type error list are listed.

The following is carried out to process flight plans:

The application in the terminal coordination system knows the following "areas" to which a flight plan (Fpl) can be assigned: Arrival, Depature, Crossing, Fpl's not shown. Accordingly, the content of the DB table "FplInUse" is not divided into the following lists:

Departure:

• Announced Fpl's departure (PreannouncedDepList)

Fpl's before departure (DepartingList)

Fpl's after departure (AirborneList)

Arrival:

• Announced Fpl's approach (PreannouncedAppList)

• Fpl's before arrival (ApproachingList) Fpl's ^" upon arrival (LandedList)

Crossing:

• Overflights (not Low Pass or Touch and Go (CrossingList)

Fpl's not shown

Rest (InStoreList)

The following tables provide an overview of which states are possible and permitted for the Fpl's and in which DB tables an Fpl can be found in the corresponding state.

Generally:

Departure:

Arrivals

Crossing:

The essential functionality in the terminal coordination system is the transition of a flight plan from one state to another. All permitted state transitions are defined in the following chapters:

Every flight plan in FplInUse can be changed from any state to "FplCacelled" by the action "Cancel Fpl". Deleting a flight plan, which is in the state "EndOfUse" is no longer possible. If was the last action on a flight plan, a state change, the "UNDO" Action always leads back to the state in which the flight ^¬ plan was last.

Departure table:

The ClearanceDeliveredFlag can be set in the following states: PreannouncedDep, FirstContactDep, SUG, OffBlock, ClearedForTakeoff. The ClearanceDeliveredFlag is automatically deleted in the ATD state.

Arrivals

Crossing

By "sending flight plans" you can move a flight plan from one partial list to another partial list. This serves the following purposes in particular:

• The operator wants to restore an old state in a flight plan because he incorrectly selected a new state and this cannot be undone by UNDO.

• A flight plan should be moved from one list to another list (e.g. Arrival after Departure) because the flight plan was incorrectly set to the current state.

When a flight plan is sent to another area, the previously collected information from this flight plan is lost and a new flight plan is actually created in the database.

The status of a flight plan can change due to an operator action or controlled by an external event. These changes must be managed and updated by the system. In addition, in many cases the admissibility of an action must be checked or its implementation prevented by suitable measures such as hiding a button. The data structures of the flight plans are designed in such a way that the entire history of the state changes remains traceable using the entered time stamp. Likewise, the last valid state before the current state is saved in the data structures in order to be able to undo the last state transition (UNDO). The following is carried out for the problem area human-machine interface: The interface for data flow and communication to or with the operator is formed by an MS Windows application. This application has a direct interface to the terminal coordination system database and can store data entered by the operator on the server. Since several users can work on a database at the same time in the terminal coordination system and in particular can change data, the application has mechanisms that can be used to automatically keep the displayed data up to date (SignalQueue).

In order to be able to carry out operator actions with the terminal coordination system workstation, the user must log into the system. For this, a valid combination of username / password must be entered before starting work.

When logged out, the terminal coordination system workstation shows the workstation mask and keeps it up to date. This means that the current entries in FplInUse are always displayed in this state and a valid image of the database entries is therefore visible. Operation is not possible. The only action that is allowed is the login. Only the number of 3rd order / monitoring errors that have not yet been acknowledged is shown, but not the associated error text. That no error messages are made.

When logged in, the system distinguishes between two different user groups, which differ in the permitted operations: In the first group are all "normal" users, the user name must not be SYSTEM. The following operations are not allowed in this group:

Exit terminal coordination system, i.e. the normal

User cannot exit the terminal coordination application.

User administration, i.e. the normal user cannot create or delete new users.

The second group contains only one user (username: SYSTEM). After logging in with this user name, all operations of the terminal coordination system workstation are released. In particular, the terminal coordination system application can be ended (after a security question). User management can also be used.

Remarks:

The user name "SYSTEM" is automatically created when the database is set up. The default password is "Terminal coordination system"

The user "SYSTEM" cannot leave the table

UserTable will be deleted. This ensures that at least one valid user is always available in the system who also has the authorization to set up additional users.

After the application is closed, Windows is closed and the system is in MS-DOS. The flight plans currently being processed are displayed in 7 lists in the terminal coordination system workstation mask (illustration in FIG. 7) and are kept up-to-date at all client workstations. The lists are given a scrollbar to enable scrolling.

The space occupied by the lists is influenced by the following factors:

Division of the screen halves according to the settings by the operator.

The minimum number of flight plans shown is 4.

If one list becomes smaller than the space provided on the screen, the other lists are automatically enlarged.

The list of PreannouncedDep flight plans is added to the end of the DepartingList list and may only be visible by scrolling.

The list of PreannouncedApp flight plans is added to the end of the ApproachingList list and may only be visible by scrolling.

The space allocation is chosen so that at least 15 flight plans can be displayed simultaneously on one page.

After selecting a list, the last selected flight plan from this list is automatically selected (or the first one if the list was not yet selected or the last selected flight plan no longer exists in the list). A List without entry is ^" not selectable. The left part of the mask contains all flight plans for the departure, the right part all flight plans for the arrival. The crossing list is only shown if there is an entry. Deviating from Fig. 7 can the crossing list is also shown on the left half of the screen. The icons for editing the status of flight plans in the crossing list are shown below the crossing list. They are hidden if the list is not selected. In addition, the workspace mask contains two separation bars and several information areas. The separation bars can be used to change the size of the displayed lists. In the separation bars the states for the flight plans required for the processing of the flight plans are shown in the form of icons. The information areas are in a general information field that is available at all workplaces is identical, and a user information area in de m only contains information on the current processing at a workstation. The workplace mask as a whole cannot be reduced or enlarged and it cannot be iconized. The layout is aligned to a resolution of 640 x 480 points.

About the . The ini file of the terminal coordination system application can be set which icons are shown in the separation bar. This makes it possible to adapt the functionality to the conditions of an airfield. The configuration is identical for all workplaces. The icons for editing the status of flight plans can also be configured in the CrossingList. States whose icons are not shown in the separation bar cannot be assumed by a flight plan. Certain status icons are displayed in any case (regardless of a configuration). The ^" lists ^" are described in more detail below:

Basically, the order of the flight plans within a list can be determined by the operator. This order is stored in the database and is available to every client. If a flight plan does not yet meet any sort criteria (i.e. the operator has not yet explicitly assigned a position to the flight plan), the flight plan is added to the end of the list after first-in-first-out. In the outbound area the flight plans are shown from top to bottom (oldest time entry above), in the inbound area and in the crossing list the flight plans are displayed from bottom to top (oldest time entry at the bottom).

PreannouncedDepList: This list shows all flight plans with the status PreannouncedDep.

DepartingList: This list shows all flight plans with the states DepartingNoState, FirstContactDep, SUG, OffBlock and ClearedForTakeoff.

AirboneList: This list shows all flight plans with the status PreannouncedApp.

ApproachingList: This list shows all flight plans with the states ApproachingNoState, FirstContactApp, ReportingPoint, HoldPos, DirectApproach, Downwind, Base and ClearToLand.

LandedList: This list shows all flight plans with the state ATA. CrossingList: This list shows all flight plans with the states FirstContactCtr, EnterCtr and LeaveCtrCross.

The static information field contains general information that is partially read from the database (InfoTable, error list) and partially generated dynamically (time, number of unacknowledged errors).

The Fluplan information field is only displayed in certain situations and contains all information about the currently selected flight plan. The Fplinfo field (see Figure 8) is displayed dynamically above the static information field.

Output fields for error messages: 1st order error messages are displayed in a popup window in the middle of the screen. These must be acknowledged with an OK button before further processing is possible. All other error messages are displayed in a separate window (popup) in which the error that has occurred is displayed. The window is placed over the area of the static information field (in the size that the error text requires). To close the window, the OK button must be pressed, but you can continue working despite such an error. The other error messages are displayed depending on the local parameter setting.

In the menu bar (see FIG. 7 and 8) 12 function keys are shown. Their meaning is either directly assigned to an action or a corresponding selection menu (pull-down menu or scrolled list) is displayed. With a selection menu, handling is the same as with normal MS Windows menus (selection inverted, default assignment programmable, selection via hot key, fading away via mouse action, insensitive Representation of states that cannot be selected). In some cases, a multi-level menu may also be required.

FL HELP: A separate window is displayed in which context-sensitive help for the current processing is output. The window must be closed explicitly.

F2 STATUS: A pull-down menu is displayed in which the permitted states (depending on the approach, departure or crossing) of a selected flow plan are displayed. The list can be parameterized implicitly via the configuration of the status icons. Default selection: next logical state of the flight plan.

F3 FPL: The function key is used to edit a selected flight plan. A window is displayed, the type of which is adapted to the flight plan context (approach, departure, crossing) and to the current flight plan status. If a list is empty, F3 is displayed insensitively.

F4 VIA: This is a pull-down menu that can have 4 different versions: 1st departure IFR, 2nd approach IFR, 3rd departure VFR, 4th approach VFR. The entries in the menus can be parameterized (.ini file, Sections VIA ...). The menu is selected depending on the flight rule entered in the selected flight plan.

F5 INT: This function key opens a pull-down menu via which the flight intent (intention) is entered in the selected flight plan. The list of intentions can be parameterized.

F6 TYPE: This function key opens the same dialog as for F3. The cursor is on the Type / WTC field. F7 REMARK: This ^" function key opens the same dialog as for F3. The cursor is on the remark field.

F8 RWY: This function key opens a pull-down menu via which a runway is assigned to the selected flight plan. The list of runways can be parameterized.

F9 LIST: This function key opens a pull-down menu with the following options: LIST ATD: list of all flight plans with an ATD, LIST ATA: list of all flight plans with an ATA, LIST EOBT: list of all as yet unarchived flight plans from FplInUse with an EOBT and status FplInStore, LIST FPL (CTR): List of all not yet archived flight plans from FplInUse that were in the crossing list, SEARCH FPL: List of all flight plans from FplInUse and all callsigns from the flight role. The double display (call sign in FplInUse and LfzRolle) is avoided. Expected a / c: List of all flight plans from FplInUse, whose home identifier is set and for which the last version with the highest index of the flight plan on that day has an ATD but no ATA. List errors: List of all errors that have not yet been acknowledged.

Structure of the lists: See flight plan list below.

The lists are sorted using a two-level menu according to the following criteria: ATA or ATD (except crossing), callsign, callsign frag ent. When sorting by call sign fragment, the user enters only part of the call sign or the entire call sign; the missing characters are treated like wildcards. The list only contains the flight plans whose call sign matches the entered call sign fragment. A call sign is composed of a maximum of 7 alphanumeric characters (0..9, A..Z). Leading wildcards must be generated by the corresponding number of blanks. Wildcards at the end are not allowed can be entered. Wildcards between significant characters are not allowed. Examples of permissible callsign fragments and their meaning:

AB The list contains all the blueprints whose

Callsign begins with AB.

<Blank> AB The list contains all flight plans whose call sign contains an A in the second position and a B in the third position and which then continue with any string (including an empty string).

Examples of invalid call signs or call sign fragments:

A B (blanks between significant characters)

ABCDEFGH (too many characters)

ABS- () (wrong characters)

FlO Options: This function key opens a pull down menu with the following options:

Send: Transfers a flight plan to another list (used after incorrect operation).

Statistics: Level 2

Repetitive Fpl: Used to manage the seasonal flight schedule

A list of all flight plans of the seasonal flight plan is opened to the operator, from which an entry can be selected. Selected entries are copied into input fields in which the operator can then make modifications. When the operator creates a new one

A call sign or Fpl number, a new entry can be added to the seasonal flight schedule. In addition, the option is provided here to change the seasonal flight schedule based on an operator action

Switch from summer to winter time and vice versa.

Fll UNDO: This function key (after confirmation by the operator) cancels the last action. The following actions can be undone: change the status of a flight plan, change the position of a flight plan. After initiating the UNDO function, the system checks whether the flight plan is still in the state or position that the client initiated or whether the flight plan has already been processed by another client. For this, access to the flight plan is blocked for other processes. If the flight plan has already been processed, the UNDO is rejected, otherwise the last status or position is restored after confirmation by the operator. The data record is then released again. UNDO is not possible in the FplInDatabase or FplInStore state.

F12 Management: This function key opens a pull down menu with the following options:

Insert data for static info array: The operator can select which data is displayed in the static info array should. The selection is valid for all client workstations (with the exception of the selection error display).

Print: Either the entire season flight schedule or the content of the FplInUse is printed.

Color management: Color settings for flight plan statuses etc.

Control entries: Output of a list that contains all monitoring messages that have currently occurred.

Remote Terminal: Start an application that allows logging in to the server via a terminal emulation. This makes it possible, for example, to carry out maintenance work or copy the archive data onto a floppy disk on the server. The entry is only available if the corresponding configuration entry exists in the ini file. A terminal emulator is included in the FTP / TCP software from FTP, for example.

Logout terminal coordination system: Logout from the current session, the terminal coordination system application continues to run, but cannot be operated.

Exit terminal coordination system: Exits the terminal coordination system application (only available for Superuser SYSTEM)

In various situations, the operator is given a list of flight plans after input, from which a selection should generally be made (for Search Fpl - see above) or which should give the operator an overview of existing flight plans (for List Fpl - see above). When you enter "Search Fpl", the operator is shown the list of all flight plans that are in FplInUse, together with all entries of the Aircraft roles that are not yet in the FplInUse are offered. The list is sorted alphabetically by callsigns. The relevant flight plan (if available) is selected by entering the desired call sign. The system automatically selects the "closest match" when the first characters of a call sign are entered. When the list, which also has a scrollbar for searching, is displayed, three flight plans are displayed. The size of the list can be changed by the operator. Accordingly, certain actions (changes in state) can be carried out or the flight plan can be edited.

For the entry "ListFpl", reference is made to the explanations given above. In the corresponding lists, the flight plans are given a version number and a sequence number for easier assignment. The version number indicates how often the flight plan has already been activated on that day The sequence number adds up the number of arrivals / departures of this flight plan.

To edit a flight plan, all attributes of the flight plan are displayed in a separate window and the user can make certain entries or changes. The application checks the entries for plausibility. In addition, the fields (when creating a new one) are assigned default values. The "Type" field and the "wtc" field are filled in automatically if the entered call sign is available in the aircraft role. If not and if the user enters a registration, the assignment registration to type / wtc is automatically transferred to the aircraft role when a flight plan is entered.

Claims

claims

1.Terminal coordination system showing the data required for the control activities of the air traffic control personnel, including flight plan data for handling the current landings, take-offs and flights as well as all flight movements on at least one monitor, whereby the system is designed in client-server technology and server (1 ) and clients (2) are connected by a LAN (6) (Local Area Network) or WAN (Wide Area Network), characterized in that it is constructed as a multilayer system with a graphical user interface, with a basic system based on flight plan data and current Arrival and departure as well as radar information is based, an object-oriented relationally working database is assigned, which is designed to output time-related detailed data on the monitor.

2. System according to claim 1, so that the flight movements are coordinated according to all flight rules (IFR - instrument flight rules, VFR - visual flight rules, Y, Z, etc.).

3. System according to claim 1 or 2, d a d u r c h g e - k e n n z e i c h n t that it as a server system on the

Basis of the UNIX operating system, e.g. of the operating system Digital UNIX is working with the network communication TCP / IP and the database Oracle.

4. System according to claim 1, 2 or 3, characterized in that the clients (2) under MS Windows with the operating system MS-DOS or Windows NT or Windows 95 are trained to work.

5. System according to claim 1, 2, 3 or 4, dadurchg ek indicates that the graphical user interface of the clients (2) via an ODBC and SQL / NET level and one of the operating systems MS-DOS with MS Windows or Windows NT or Windows 95, which are linked to each other in a time-related manner, is working.

6. System according to one or more of the preceding claims, that the clients (2) are limited to the terminal coordination applications, the terminal coordination user interface starting automatically when starting.

7. System according to claim 6, d a d u r c h g e k e n n - z e i c h n e t that on the client (2) process flows with a control and controlling interface, including graphical user interface and an event handler, running time-related, are arranged.

8. System according to claim 1, 2, 3, 4, 5, 6 or 7, d a d u r c h g e k e n n z e i c h n e t that on the server (1) a timer process for starting time-controlled actions such as e.g. Reading out flight plans (RPL - Repetive Flight Plan), archiving flight plans or status changes, is in progress.

9. System according to claim 8, characterized in that the timer process cyclic timer functions that trigger an action after a certain time and then be started again, and non-cyclic timer functions that perform an action only once and then deleted again.

10. System according to one ^" or more of the preceding claims, characterized in that in the client (2) for its synchronization with a time of the server (1) a separate user process is set up, which reads out the server time via a communication interface at the start or cyclically and sets its local time accordingly.

11. System according to one or more of the preceding claims, ie that a dispatcher process is executable on the server (1) with which the data can be distributed to the external interfaces if required, e.g. to a radar system or an airport accounting system.

12. System according to one or more of the preceding claims, g e k e n n z e i c h n e t d u r c h external interfaces designed for data reception, each of which is assigned its own server process based on the RPC (RPC = remote procedure call).

13. System according to one or more of the preceding claims, d a d u r c h g e k e n n z e i c h n e t that it is designed to perform a client-writer process with which the asynchronous access of several clients (2) to the databases of the server (1) is realized and monitored.

14. System according to one or more of the preceding claims, that the synchronization and the data exchange with the aid of a

Signal queue can be made, which can be queried cyclically in the client applications and which are designed to update the display and the data content in the event of changes to a flight plan.

15. The system as claimed in one or more of the preceding claims, that a flight plan data distribution and an updated display on the user interface of the client are automatically designed to output.

16. The system as claimed in one or more of the preceding claims, that all flight schedules of an airport are stored in it (RPL - Repetitive Flight Plan), which are carried out cyclically (daily, weekly, weekly on certain days).

17. System according to claim 16, d a d u r c h g e k e n n - z e i c h n e t that in the flight plans to be edited and displayed individual data such as e.g. planned landing time, planned docking time, planned departure time etc. with their details can be inserted at any time.

18. System according to one or more of the preceding claims, characterized in that flight plans and flight plan follow-up messages that are sent by other systems (AFTN - Aeronautical Fixed Telecommunications Network, higher-level FDPS), can be processed and that data relevant to the course of the flight, during the flight plan processing can be entered or arise as a result of the data flow (e.g. ATA, ATD, etc.) can be sent to connected air traffic control systems for further processing.

19. System according to one or more of the preceding claims, characterized by commands, actions, external events, manually controllable icons on a screen workstation mask and / or other functions. onsmodule, by means of which flight plans can be transferred from one state to another state.

20. System according to one or more of the preceding claims, that the flight plans or flight plan-oriented coordination messages according to the AFTN standard (Aeronautical Fixed Telecommunication Network) can be received and transmitted.

21. System according to one or more of the preceding claims, that the flight plans or flight plan-oriented coordination messages can be received and transmitted in accordance with the standard CIDIN (Common ICAO Data Interchange Network).

22. System according to one or more of the preceding claims, that the flight plan-oriented coordination messages (e.g. takeoff time, landing time, SLOTs, etc.) according to the OLDI standard or the like. can be received and sent.

23. The system as claimed in one or more of the preceding claims, that the aircraft-specific performance data can be stored in a database table and can be called up in the system.

24. System according to one or more of the preceding claims, characterized in that the association between the aircraft registration, the associated aircraft type and the associated weight class is self-learning and self-maintaining (over a selectable time interval) can be stored in a database table and can be called up in the system.

25. System according to one or more of the preceding claims, characterized in that assignments between destination airports in normal spelling and the associated abbreviation can be stored both in the ICAO code (4 characters) and in the IATA code (3 characters) in a database table and in the system can be called up and maintained.

26. System according to one or more of the preceding claims, characterized in that the server (1) with a combination of function modules at least from an operating system (OSF / 1), a network communication (6), an object-oriented, relationally working database (Oracle), user-oriented server processes (TECOS) and a time.

27. System according to one or more of the preceding claims, characterized in that the client (2) with a combination of function modules at least from an operating system (MS-DOS), a database interface (SQL / Net), an open database interface (ODBC) , user-oriented client processes (TECOS) and a time.

28. System according to one or more of the preceding claims, g e k e n n e i c h n e t d u r c h database tables, which are designed for data exchange between processing processes.

29. Terminal coordination system, in particular according to one or more of the preceding claims, with a representation of the data required for the control activity of the air traffic control personnel, including flight data for handling the current landings, take-offs and flights as well as all flight movements on at least one monitor, the system stem is designed in client-server technology and server (1) and client (2) are connected by a LAN (Local Area Network) or WAN (Wide Area Network), where it is used for data exchange to a system for business management (4) how billing, administration or planning of aircraft movements and, if necessary, supplies, is suitable at airports and trained to work with usage times.

30. System according to claim 29, that the flight plans and the required master data are stored and managed via an object-oriented relationally working database.

31. System according to claim 29 or 30, so that it is provided that it is provided with a function module that is designed to create flight plans from a billing module within the economic management system.

32. System according to claim 31, at least one input and / or output interface for further processing of the created flight plans by an operator.

33. System according to one or more of claims 29 to 32, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with an entry of a first contact time.

34. System according to one or more of claims 29 to 33, characterized in that it is designed to work with an entry of an actual time of arrival time.

35. System according to one or more of claims 29 to 34, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with an entry of a low-pass time.

36. System according to one or more of claims 29 to 35, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with an entry of a touch and go time.

37. System according to one or more of claims 29 to 36, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with a registration of an end of use time.

38. System according to one or more of claims 29 to 37, that a d u r c h g e k e n n z e i c h n e t that it is designed to work with the status change "canceled".

39. System according to one or more of claims 29 to 38, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with an entry of a start up given time.

40. System according to one or more of claims 29 to 39, d a d u r c h g e k e n n z e i c h n e t that it is designed to work with an actual time of depature time.

41. System according to one or more of claims 29 to 40, d a d u r c h g e k e n n z e i c h n e t that it is designed using the existing functions as trigger conditions.

42. System according to one or more of claims 29 to 41, characterized in that it on the Communication basis of the RPC (Remote Procedure Call) is working.

43. System according to claim 42, so that an RPC server (1) is implemented for RPC clients, and a procedure on the RPC server (1) is assigned to each request of an RPC client.

44. Terminal coordination system, in particular according to one or more of the preceding claims, with a representation of the data required for the control activity of the air traffic control personnel, including flight plan data for handling the current landings, take-offs and flights as well as all flight movements on at least one monitor, the system being a client server -Technology is formed, and wherein servers (1) and clients (2) are connected to each other by a LAN (6) (Local Area Network) or WAN (Wide Area Network), characterized in that it coordinates the incoming and outgoing traffic is designed to enable the information

Flight plan data are provided by external systems, in particular the data from at least one radar data processing system (5), which is preferably connected via a LAN / WAN (6), and wherein call signals between the server (1) and the radar data processing (5) Form of the SSR code can be transmitted.

45. The system according to claim 44, which also means that it is designed to work with a call character assignment to an SSR code.

46. System according to claim 44 or 45, characterized in that a call character request and Displayed automatically after an aircraft enters a certain control room.

47. System according to claim 44, 45 or 46, d a d u r c h g e k e n e z e i c h n e t that it has a control room surveillance that between incoming, departing and overflighting objects, i.e. relevant and irrelevant objects.

48. System according to claim 44, 45, 46 or 47, so that it is designed to enable a change of call sign, in particular after a change of assignment SSR code / call sign.

49. System according to one or more of the preceding claims 44 to 48, d a d u r c h g e k e n n z e i c h n e t that local SSR codes can be accessed with it from an SSR code memory under management.

50. System according to one or more of the preceding claims 44 to 49, d a d u r c h g e k e n n z e i c h n e t that it waits a predetermined time in the absence of response signals before an error signal is issued.

51. System according to one or more of the preceding claims 44 to 50, d a d u r c h g e k e n n z e i c h n e t that it has a cyclical function control, the server (1) and the LAN being cyclically polled for their function, e.g. by a meaningless signal.

52. System according to one or more of the preceding claims 44 to 51, characterized - net that it performs a new memory content structure and a new call character structure etc. after a malfunction.

53. System according to one or more of the preceding claims 44 to 52, which also means that schedule-related data can be transmitted with it at corresponding SSR codes.

54. System according to one or more of claims 44 to 53, d a d u r c h g e k e n n z e i c h n e t that it is designed to work on the communication basis of the RPC (Remote Procedure Call).

55. The system according to claim 54, which also means that an RPC server is implemented for RPC clients, and a procedure on the RPC server is associated with each request from an RPC client.

56. The system of claim 55, so that the RPC client is configured to provide input data for the procedure and the RPC server is configured to provide procedure output data to the RPC client.