EP0939946A1 - Systeme de coordination des activites d'un terminal d'aeroport - Google Patents

Systeme de coordination des activites d'un terminal d'aeroport

Info

Publication number
EP0939946A1
EP0939946A1 EP97949942A EP97949942A EP0939946A1 EP 0939946 A1 EP0939946 A1 EP 0939946A1 EP 97949942 A EP97949942 A EP 97949942A EP 97949942 A EP97949942 A EP 97949942A EP 0939946 A1 EP0939946 A1 EP 0939946A1
Authority
EP
European Patent Office
Prior art keywords
flight
data
server
time
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP97949942A
Other languages
German (de)
English (en)
Inventor
Alexander Koch
Peter Bartsch
Klaus-Dieter ZÜHLKE
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
AIRSYS GESELLSCHAFT FUER AIR TRAFFIC MANAGEMENT SY
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Publication of EP0939946A1 publication Critical patent/EP0939946A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0017—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information
    • G08G5/0026—Arrangements for implementing traffic-related aircraft activities, e.g. arrangements for generating, displaying, acquiring or managing traffic information located on the ground
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/88—Radar or analogous systems specially adapted for specific applications
    • G01S13/91—Radar or analogous systems specially adapted for specific applications for traffic control
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01S—RADIO DIRECTION-FINDING; RADIO NAVIGATION; DETERMINING DISTANCE OR VELOCITY BY USE OF RADIO WAVES; LOCATING OR PRESENCE-DETECTING BY USE OF THE REFLECTION OR RERADIATION OF RADIO WAVES; ANALOGOUS ARRANGEMENTS USING OTHER WAVES
    • G01S13/00—Systems using the reflection or reradiation of radio waves, e.g. radar systems; Analogous systems using reflection or reradiation of waves whose nature or wavelength is irrelevant or unspecified
    • G01S13/88—Radar or analogous systems specially adapted for specific applications
    • G01S13/91—Radar or analogous systems specially adapted for specific applications for traffic control
    • G01S13/913—Radar or analogous systems specially adapted for specific applications for traffic control for landing purposes
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
    • G08G5/0043—Traffic management of multiple aircrafts from the ground

Definitions

  • the invention relates to a terminal coordination system
  • 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.
  • 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 1991, versions 2.00 from 01/18/95 and 2.01 from 01/25/95, document no. 400; TECOS detailed concept (client), ISO GmbH 1991, version 2.00, document no. 500; TECOS, detailed concept (server), ISO GmbH 1991, 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.
  • 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.
  • the application software and the database can be Realize invention.
  • 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.
  • 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.).
  • 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.
  • 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.
  • 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.
  • aircraft-specific performance data can be stored and called up in a database table as part of the terminal coordination system.
  • 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.
  • 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.
  • the terminal coordination system 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.
  • 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.
  • 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.
  • 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.
  • the data received from the terminal coordination system can be used for billing in the airport management system.
  • 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.
  • the terminal coordination system has interfaces in order to be able to receive information about flight plan data from external systems.
  • 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.
  • 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.
  • 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
  • the terminal coordination system is designed to work with a call character assignment to an SSR code.
  • 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.
  • a call sign request can be made automatically after an aircraft has entered a certain control room.
  • some services for the system control (restart, free status) are necessary.
  • 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.
  • FIG. 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
  • 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 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.
  • 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.
  • OSF / 1 UNIX operating system
  • TCP / IP network communication, part of UNIX
  • Oracle RDBMS
  • TECOS general server processes
  • time server a time server.
  • 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).
  • 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).
  • the following development tools are needed on the development system: C compiler,
  • the clients under MS Windows are with the Operating system MS-DOS " or Windows NT or Win 95 working.
  • 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.
  • a precompiler C and an MS Visual C ++ are expediently used for the development system.
  • 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.
  • 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-
  • ITOS queue to the airport management system
  • 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.
  • 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.
  • databases events that are managed by the database system.
  • 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).
  • RPL table seasonal flight schedule
  • FplInUse FplSeqTable
  • WriteQueue InUse (not shown); Printtable
  • Master data tables List of errors; ITOS queue; RDP queue.
  • the RPL seasonal flight schedule
  • the RPL 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".
  • 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
  • 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:
  • 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.
  • FplIdString String of all Fpllds that are included in this list in this order
  • FplListe identification of the list.
  • 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,.
  • 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.
  • 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
  • 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.
  • Timertable 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",
  • Error list contains the 2nd and 3rd order error messages.
  • 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.
  • the following attributes are used:
  • 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.
  • 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.
  • 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.
  • 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:
  • a non-cyclic timer is deleted from the table.
  • 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 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.
  • PreRead indicates which period (from the activation period) is always stored in the FplInUseTable
  • Delta indicates the intervals at which the procedure is started.
  • 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).
  • the procedure After filling up the FplInUseFplTable, the procedure creates a new entry in the timetable that starts the procedure again after the delta period.
  • 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".
  • the external interfaces in the terminal coordination system are implemented as openly as possible and independently of the environment used.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • the terminal coordination system After further training, the terminal coordination system carries out a new memory content structure and a call sign structure etc. after a malfunction.
  • 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.
  • the radar data processing system can also decide that the local database is invalid and must be clarified.
  • 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.
  • the radar data processing system 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.
  • RPC remote procedure call
  • 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.
  • 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 RPC program is declared for the RPC server of the terminal coordination system in the following way:
  • This program contains the procedures that are required for the geforder ⁇ th server functionality.
  • 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.
  • 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 RPC program is declared as follows:
  • This program contains the procedures that are required for the required server functionality.
  • 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.
  • the terminal coordination system transmits a request for clarification of the database to the radar data processing system.
  • 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.
  • 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.
  • the exchange of data between the terminal coordination system and the airport management system essentially takes place for the following reasons:
  • 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.
  • the data from the terminal coordination system can be used to create the settlement.
  • a flight plan with an "Estimated Time of Arrival" is entered or changed
  • TMA Trip Miles Out
  • a "First Contact” time is entered or changed for 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.
  • a start-up given time is entered or changed for a flight plan
  • a flight plan is brought into the "FplCancelled" state.
  • 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 "
  • FplApproachData FplDepartureData
  • FplCancel 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.
  • RPC remote procedure call
  • 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 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.
  • error list For the configuration, please refer to the table below:
  • 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:
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • these include input errors, communication errors, local errors (hardware), etc.
  • 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.
  • 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.
  • 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
  • a separate entry is available in the management menu, via which all entries in the "Monitoring" type error list are listed.
  • 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:
  • 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:
  • the ClearanceDeliveredFlag can be set in the following states: PreannouncedDep, FirstContactDep, SUG, OffBlock, ClearedForTakeoff.
  • the ClearanceDeliveredFlag is automatically deleted in the ATD state.
  • sending flight plans you can move a flight plan from one partial list to another partial list. This serves the following purposes in particular:
  • 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.
  • 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 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).
  • the terminal coordination system workstation 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.
  • the system 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
  • 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.
  • the user name "SYSTEM” is automatically created when the database is set up.
  • the default password is "Terminal coordination system”
  • 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.
  • 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:
  • the minimum number of flight plans shown is 4.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • the lists are sorted using a two-level menu according to the following criteria: ATA or ATD (except crossing), callsign, callsign frag ent.
  • ATA or ATD except crossing
  • callsign 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:
  • 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.
  • the option is provided here to change the seasonal flight schedule based on an operator action
  • 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.
  • 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.
  • 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).
  • 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)
  • 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).
  • 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.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • General Physics & Mathematics (AREA)
  • Aviation & Aerospace Engineering (AREA)
  • Electromagnetism (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer And Data Communications (AREA)
  • Radar Systems Or Details Thereof (AREA)
  • Traffic Control Systems (AREA)

Abstract

L'invention concerne un système de coordination des activités d'un terminal impliquant la représentation sur au moins un moniteur des données nécessaires pour les activités de contrôle du personnel de sécurité de l'aéroport, en tenant compte des données de plan de vol pour permettre le déroulement des atterrissages, décollages et passages actuels, ainsi que de tous les mouvements de vol. Le système présenté est conçu selon la technique clients-serveurs, les serveurs (1) et les clients (2) étant reliés par un réseau local (LAN) (6) ou un réseau longue distance (WAN). Selon l'invention, ce système est du type multicouche à surface graphique. A un système de base, dont le fonctionnement est fondé sur les données de plan de vol ainsi que sur les informations radar et relatives aux atterrissages et aux décollages du moment, est affectée une banque de données relationnelle orientée objet qui est conçue pour donner sur le moniteur des données de détail en rapport avec l'heure.
EP97949942A 1996-11-15 1997-11-17 Systeme de coordination des activites d'un terminal d'aeroport Withdrawn EP0939946A1 (fr)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
DE19647371 1996-11-15
DE19647374 1996-11-15
DE19647371 1996-11-15
DE19647372 1996-11-15
DE19647374 1996-11-15
DE19647372 1996-11-15
PCT/DE1997/002697 WO1998022923A1 (fr) 1996-11-15 1997-11-17 Systeme de coordination des activites d'un terminal d'aeroport

Publications (1)

Publication Number Publication Date
EP0939946A1 true EP0939946A1 (fr) 1999-09-08

Family

ID=27216834

Family Applications (1)

Application Number Title Priority Date Filing Date
EP97949942A Withdrawn EP0939946A1 (fr) 1996-11-15 1997-11-17 Systeme de coordination des activites d'un terminal d'aeroport

Country Status (2)

Country Link
EP (1) EP0939946A1 (fr)
WO (2) WO1998022923A1 (fr)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7889133B2 (en) 1999-03-05 2011-02-15 Itt Manufacturing Enterprises, Inc. Multilateration enhancements for noise and operations management
US7782256B2 (en) 1999-03-05 2010-08-24 Era Systems Corporation Enhanced passive coherent location techniques to track and identify UAVs, UCAVs, MAVs, and other objects
US7667647B2 (en) 1999-03-05 2010-02-23 Era Systems Corporation Extension of aircraft tracking and positive identification from movement areas into non-movement areas
US7777675B2 (en) 1999-03-05 2010-08-17 Era Systems Corporation Deployable passive broadband aircraft tracking
US7739167B2 (en) 1999-03-05 2010-06-15 Era Systems Corporation Automated management of airport revenues
US8203486B1 (en) 1999-03-05 2012-06-19 Omnipol A.S. Transmitter independent techniques to extend the performance of passive coherent location
US8446321B2 (en) 1999-03-05 2013-05-21 Omnipol A.S. Deployable intelligence and tracking system for homeland security and search and rescue
US7570214B2 (en) 1999-03-05 2009-08-04 Era Systems, Inc. Method and apparatus for ADS-B validation, active and passive multilateration, and elliptical surviellance
US7908077B2 (en) 2003-06-10 2011-03-15 Itt Manufacturing Enterprises, Inc. Land use compatibility planning software
DE10032433A1 (de) * 2000-07-04 2002-01-17 H A N D Gmbh Verfahren zur Bodenraumüberwachung
US7965227B2 (en) 2006-05-08 2011-06-21 Era Systems, Inc. Aircraft tracking using low cost tagging as a discriminator
US9773421B2 (en) 2015-10-19 2017-09-26 Honeywell International Inc. Aircraft maneuver data management system
CN105355093A (zh) * 2015-12-03 2016-02-24 上海民航华东空管工程技术有限公司 一种塔台电子进程单系统
AT521474B1 (de) * 2018-10-24 2020-02-15 Frequentis Ag Verfahren zur Erkennung von Luftfahrzeugen
EP3848832B1 (fr) * 2020-01-08 2024-05-08 Rohde & Schwarz GmbH & Co. KG Système ainsi que procédé de commande de la circulation aérienne destinés à la surveillance d'un réseau de commande de la circulation aérienne

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5497463A (en) * 1992-09-25 1996-03-05 Bull Hn Information Systems Inc. Ally mechanism for interconnecting non-distributed computing environment (DCE) and DCE systems to operate in a network system
US5504885A (en) * 1993-06-29 1996-04-02 Texas Instruments Incorporated O-R gateway: a system for connecting object-oriented application programs and relational databases
JP3417655B2 (ja) * 1994-05-18 2003-06-16 株式会社東芝 電子運航票管理システムのユーザインタフェース装置
DE69430270T2 (de) * 1994-10-14 2002-11-21 Safegate International Ab, Malmoe Identifikations- und andockungsführungsanlage für flugzeuge
JPH08146130A (ja) * 1994-11-24 1996-06-07 Mitsubishi Electric Corp 空港面地上走行管制システム
SG66213A1 (en) * 1995-01-31 1999-07-20 Mitsubishi Electric Corp Display apparatus for flight control
ES2141598T3 (es) * 1996-02-29 2000-03-16 Siemens Ag Sistema de guia de aeropuerto, especialmente sistema de guia y de control de la circulacion de superficie de un aeropuerto.
DE19635679A1 (de) * 1996-09-03 1998-03-05 Siemens Ag Mensch-Maschine-Schnittstelle (Man-Machine-Interface, MMI) für Flughäfen und Luftverkehrszwecke

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9822923A1 *

Also Published As

Publication number Publication date
WO1998022923A1 (fr) 1998-05-28
WO1998022922A1 (fr) 1998-05-28

Similar Documents

Publication Publication Date Title
EP0939946A1 (fr) Systeme de coordination des activites d'un terminal d'aeroport
DE69225566T2 (de) Rechnersystem
DE10105153B4 (de) System zur automatischen Konfiguration eines tragbaren Gerätes eines Nutzers, wie insbesondere eines tragbaren Computergerätes, Software-Produkt und Verfahren zur automatischen Konfiguration eines Computersystems eines Nutzers und Programmierbares Speichermedium
DE69431784T2 (de) Verfahren und Architektur zur Datenverwaltung
DE69911681T2 (de) Verfahren zum Verfolgen von Konfigurationsänderungen in Netzwerken von Rechnersystemen durch historische Überwachung des Konfigurationsstatus der Vorrichtungen im Netzwerk
DE3752196T2 (de) Vorrichtung für Datenverarbeitungsverteilung über eine Mehrzahl von Steuerungsorten
DE3883733T2 (de) Bedienungsverfahren eines elektronischen Datenverarbeitungssystems zum Dokumententransfer zwischen Endbenutzern.
DE60018803T2 (de) Verfahren und apparat zur verwaltung von information der speicheraktivitäten von datenspeichersystemen
DE69132012T2 (de) Objektorientierte architektur für fabrikverwaltung
DE69518745T2 (de) Überwachungs- und steuerungsvorrichtung und -verfahren für programme mit einem netzwerk
DE60125989T2 (de) Verfahren und apparat für eine verbesserte dateiverwaltung
DE69701510T2 (de) Verfahren und vorrichtung zur hilfe von luftnavigation, die die einführung und kontrolle von flugdaten erleichtern
DE60206741T2 (de) Kommunikationsmodul zur steuerung von betriebsabläufen einer pbx
EP1859340A2 (fr) Procede pour generer des ordres d'impression dans un systeme d'impression, procede pour trier des travaux d'impression dans un systeme d'impression, programme informatique et systeme d'impression pour realiser ces procedes
DE69409142T2 (de) Synchronisationssystem für redundante Aufträge
WO2005050437A2 (fr) Procede pour installer et configurer des composantes logicielles
WO2011032895A1 (fr) Procédé et système d'utilisation de verrous exclusifs temporaires pour des accès parallèles à des moyens d'exploitation
DE202015009289U1 (de) Systeme zur Verzerrung der Aufgabenunterstützung von Autovervollständigungsvorschlägen
EP1373994B1 (fr) Systeme de guidage de processus
DE68905074T2 (de) Datenverarbeitende vorrichtung mit zeitplanungskontrolle.
DE69634953T2 (de) Anpassbare anwenderschnittstelle
DE69916458T2 (de) Automatische Konfiguration eines Internet - artigen Computernetzes
EP0766488B1 (fr) Procédé pour le couplage d'unités de traitement de données, procédé pour la commande d'un central de commutation, unité de traitement de données, dispositif de commande et central de commutation
DE19911699A1 (de) Verfahren zur Überwachung, Steuerung und/oder Optimierung von Prozeß- und/oder Arbeitsprojektplänen
DE10129886A1 (de) Verfahren zum Netzkonfigurationsmanagement und Netzbestandsmanagement eines Netzes und entsprechendes Netzkonfigurationsmanagement- und Netzbestandsmanagementsystem

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 19990612

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT DE ES FR GB GR IT

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: AIRSYS GESELLSCHAFT FUER AIR TRAFFIC MANAGEMENT SY

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030603