WO1998022922A1

WO1998022922A1 - System zur koordination der tätigkeit des flugzeugleitpersonals eines flughafens

Info

Publication number: WO1998022922A1
Application number: PCT/DE1997/002696
Authority: WO
Inventors: Alexander Koch; Peter Bartsch; Klaus-Dieter ZÜHLKE; Herbert Hess; Lothar Becker; Robert Castor
Original assignee: Siemens Aktiengesellschaft
Priority date: 1996-11-15
Filing date: 1997-11-17
Publication date: 1998-05-28
Also published as: EP0939946A1; WO1998022923A1

Abstract

System zur Koordination oder Tätigkeit des Flugzeugleitpersonals eines Flughafens, mit einem System (TECOS) für die Kontrolle der im Luftraum sowie ggf. auf den Start- und Landebahnen befindlichen Flugzeuge, einem System (GMCS) für die Leitung der auf dem Boden verkehrenden Flugzeuge, einem System (DS) für die Einweisung der andockenden Flugzeuge, sowie einem oder mehreren Systemen für die Änderung der Zuordnung der Kontrollverantwortung eines Flugzeugs zu einem der Kontrollsysteme (TECOS, GMCS, DS), das ein oder mehrere, im Bereich der Kontroll-Arbeitsplätze angeordnete Eingabemöglichkeit(en) für ein Aufforderungssignal (60) zur Zuordnungsänderung aufweist und ein derartiges Signal (60) zu dem betreffenden System (TECOS, GMCS, DS) weitermeldet.

Description

Beschreibung

System zur Koordination der Tätigkeit des Flugzeugleitpersonals eines Flughafens

Die Erfindung richtet sich auf ein System zur Koordination der Kontrolltätigkeit des Flugsicherungspersonals, der Leitstelle für den Bodenverkehr sowie des Personals für die Einweisung und Abfertigung von Flugzeugen an vorgegebenen Dock- ingstationen.

Nach Prognosen von Experten wird der weltweite Luftverkehr in der Zeit um die Jahrtausendwende beständig zunehmen, die gesamte Luftfahrtbranche kann mit erheblichen Zuwachsraten rechnen. Die Flughäfen müssen sich diesem Trend durch effektive Nutzung ihrer Anlagen unter Einsatz modernster Systemtechnik stellen. Hierbei gilt es, bereits vorhandene Ressourcen noch effektiver auszunutzen und dennoch ein Höchstmaß an Sicherheit sowohl in dem Luftraum oberhalb eines Flughafens als auch auf den Lande-, Start- und Rollbahnen sowie auf dem Vorfeld zu gewährleisten. Zu diesem Zweck ist eine optimale Zusammenarbeit des Flugsicherungspersonals mit der Leitstelle für den Bodenverkehr sowie mit dem Personal für die Einweisung und Abfertigung an vorgegebenen Dockingstationen notwen- dig, damit ein Flugzeug ohne jegliche Kollisionsgefahr von dem Luftraum bis an eine Andockstation und von dort auch wieder bis zum Abflug gelotst werden kann.

Zu diesem Zweck war es bislang bekannt, handgeschriebene Kon- trollstreifen zu erstellen und dieselben bzw. deren Inhalt manuell oder über Telefon an die nächste zuständige Kontrollperson zu übermitteln. Diese Methode hat sich jedoch als äußerst aufwendig erwiesen, da hierbei in der Bodenkontrollstation und/oder im Tower eine größere Anzahl von derartigen Kontrollstreifen im Umlauf sind und gerade in zeitkritischen

Situationen erst gesucht werden müssen.

Andererseits sind in der Flughafentechnik seit einer gewissen Zeit sog. Flughafenkoordinationssysteme bekannt. Das Konzept eines derartigen, universellen Koordinationssystems beschreibt der Prospekt der Fa. Siemens AG „TECOS Terminal Coordination System" vom Februar 1996. Darin wird eine auf dem Betriebssystem „Windows" und der Client-Server-Architek- tur basierende Datenbankanwendung beschrieben, die zur Koordination und Verwaltung des ankommenden und abfliegenden Luftverkehrs in Flughäfen eingesetzt werden kann. Als Clients werden Personalcomputer verwendet, während der Server eine auf UNIX basierende Hardware-Plattform erfordert. Aktuelle Implementierungen laufen auf einem DEC-ALPHA-SERVER unter dem Betriebssystem OSF/1. Die notwendigen Flugpläne werden in einem Datenbanksystem verwaltet. Der Zugriff auf diese Flugpläne erfolgt über einen oder mehrere Client-Personalcomputer. Zusätzlich verfügt das System über verschiedene Schnittstel- len zu externen Systemen wie beispielsweise zur Radardaten- Verarbeitung oder zum AbrechnungsSystem ITOS für Flughäfen. Wegen weiterer Einzelheiten wird auf den genannten Prospekt sowie folgende weitere Fundstellen zum Stand der Technik verwiesen: TECOS-Systemanforderungen, Siemens AG, Versionen 2.00 vom 10.10.94 und 3.01 vom 01.04.95, Dokument-Nr. 100; TECOS- Grobspezifikationen, ISO GmbH Nürnberg, Versionen 2.00 vom 18.01.95 und 2.01 vom 25.01.95, Dokument-Nr. 400; TECOS- Feinkonzept (Client), ISO GmbH Nürnberg, Version 2.00, Dokument-Nr. 500; TECOS-Feinkonzept (Server), ISO GmbH Nürnberg, Version 01.00, Dokument-Nr. 510; CCD-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. Ein derartiges Koordinationsprogramm unter- stützt die Flugsicherung, indem aktuelle Daten ankommender und abfliegender Flugzeuge auf einem Bildschirm, ggf. gemeinsam mit einem Radarbild, dargestellt werden.

Andererseits sind bereits Flughafen-Bodenverkehrs-Leitsysteme bekannt, so z.B. aus der Druckschrift BRITE II der N.V. ADB S.A, Zavente , Brüssel AP.01.810e, Sonderdruck zur Ausstellung Inter Airport 1995. Hier beschriebene, mit am Boden angeordneten Sensoren arbeitende Systeme dienen dazu, eine Op- timierung des Flughafenverkehrs bei einer Erhöhung der Start- und Landekapazität eines Flughafens unter allen Wetterbedingungen bei größtmöglicher Sicherheit zu gewährleisten. Zu diesem Zweck arbeitet ein derartiges Leitsystem mit Erfassung, integrierter Verarbeitung und bildlicher Darstellung der relevanten, insbesondere der sicherheitsrelevanten Positionen und Bewegungen von Flugzeugen und gegebenenfalls Fahrzeugen auf dem Flughafengelände (Start- und Landebahn, Rollbahnen, Vorfeld) und im relevanten Flughafenluftraum (CTR) von der Erfassung durch zumindest ein Radar zwischen Flugbe- wegung und Stillstand in Parkposition, wobei die relevanten

Daten in konzentrierter Form auf einem Monitor des Bodenkontrollzentrums dargestellt werden, damit darüber die operationeile Leitung des Bodenverkehrs vorbereitet werden und erfolgen kann. Während des Fluges sind die Flugzeuge gegen Kolli- sionen durch bodengestützte Navigationshilfen geschützt. Auch in ihrem endgültigen Anflug helfen ihnen nichtoptische und optische Anflughilfen, den vorgegebenen Gleitpfad einzuhalten. Nach dem Touchdown bewegt sich das Flugzeug auf dem riskantesten Teil seines Weges . Die meisten Unfälle geschehen erwiesenermaßen am Boden. Hier hilft das Leitsystem weiter, mit dem ununterbrochen überwacht und geführt wird.

Schließlich kennt der Stand der Technik auch Dockingsysteme für Flughafenterminals, mit einer Positioniervorrichtung, mittels der ein Flugzeug in eine für seinen Bautyp vorgegebene Parkposition leitbar ist und die eine Videoeinrichtung, mittels der das Flugzeug bei seiner Annäherung an das Flughafenterminal erfaßbar ist und eine Auswerteeinheit aufweist, mittels der ihr von der Videoeinstellung zugeführte, die Gestalt und die Bewegung des Flugzeugs betreffende Daten auswertbar sind. Aus der DE 40 09 668 AI ist eine Vorgehensweise bekannt, bei der mittels einer Videokamera ein zweidimensio- nales Bild erfaßt wird, welches in die Auswerteeinheit einge- geben wird.

Mit derartigen, computergestützten Navigations- und Leitsystemen können zwar die jeweiligen Phasen einer Flugzeugbewegung von dem zuständigen Personal optimal begleitet werden. Nach wie vor bereitet jedoch die Übergabe der Weisungsbefugnis von einem Mitarbeiter des Flughafenpersonals auf den nächst Zuständigen größere Schwierigkeiten, da hierbei nach der altbewährten Kontrollstreifenmethode verfahren werden muß. Aus diesem Nachteil des bekannten Stands der Technik re- sultiert das die Erfindung initiierende Problem, diese computergestützten Systeme derart miteinander zu koppeln, daß der Übergang der Zuordnung eines Flugzeugs von einem weisungsbefugten Mitarbeiter des Flughafenpersonals zu einem anderen in einer definierten Weise abläuft, ohne daß dabei Zeit vergeu- det werden muß, bspw. für das Suchen von Kontrollstreifen.

Zur Lösung dieses Problems sieht die Erfindung bei einem System zur Koordination der Kontrolltätigkeit des Flugsicherungspersonals, der Leitstelle für den Bodenverkehr sowie des Personals für die Einweisung und Abfertigung von Flugzeugen an vorgegebenen Dockingstationen folgende Elemente vor:

a) ein System für die Kontrolle der im Luftraum sowie ggf. auf den Start- und Landebahnen befindlichen Flugzeuge, das auf Flugplandaten sowie aktuellen An-, Abflug- und/oder Radarinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; b) in System für die Leitung der auf dem Boden verkehrenden Flug- und/oder Fahrzeuge, das auf Flugplatzdaten sowie aktuellen Positions-, Bewegungs- und/oder Radarinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; c) in System für die Einweisung sowie ggf. Abfertigung der andockenden Flugzeuge, das auf Flugzeugdaten sowie aktuellen Bewegungs-, Richtungs- und/oder Videoinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; d) in oder mehrere Systeme für die Änderung der Zuordnung der Kontroll-/Leitungs- /Einweisungsverantwortung und/oder -befugnis bezüglich eines Flugzeugs zu einem der Systeme a) bis c) , das eine oder mehrere, im Bereich der Darstellungsorte der aktuellen Daten und/oder Infor- mationen angeordnete Eingabemöglichkeit (en) für ein Aufforderungssignal zur Zuordnungsänderung aufweist und ein derartiges Signal zu dem betreffenden System a) bis c) weitermeldet .

Diese Maßnahmen greifen ineinander wie die Zahnräder eines

Getriebes und gewährleisten einen reibungsfreien Übergang der Weisungsbefugnis und Verantwortung von einem Systembereich zum nächsten. Hierbei ist es überhaupt nicht relevant, ob das für die Flugsicherung, für die Leitung des Bodenverkehrs und für die Einweisung der Flugzeuge an bestimmten Terminals zuständige Personal gemeinsam in einem Raum des Towers untergebracht ist oder an verschiedenen Orten, da eine direkte Kommunikation zwischen den einzelnen Mitarbeitern möglich ist. Hierbei kann definitiv ein Flugzeug mitsamt dem aktuellen Da- tensatz ausgewählt und sodann über eine Anfrage bei der als nächstes zuständigen Kontrollperson in deren Obhut übergeben werden. Der Austausch eines Kontrollstreifens ist nicht mehr notwendig, sondern die betreffenden Personen können bequem von ihrem Sitzplatz aus mittels elektrischer Signale miteinander kommunizieren. Hierfür können einerseits neben den Monitoren befindliche Tasten, Schalter, Lämpchen oder sonstige Anzeigenverwendet werden, bevorzugt kann diese Kommunikation jedoch direkt über die einzelnen Monitore erfolgen, bspw. über besondere Kommunikationsfenster . Die Auswahl der zu übergebenden Flugzeuge sowie der als nächstes zuständigen Kontrollstelle kann dabei über Mausklick erfolgen oder mittels Touchscreen.

Weiterhin hat es sich als günstig erwiesen, daß das/die System (e) für die Zuordnungsänderung Möglichkeiten zur Rückmeldung eines Bestätigungssignals hinsichtlich der Übernahme der Kontroll- /Leitungs-/Einweisungsverantwortung eines Flugzeugs aufweist. Durch diese Maßnahme ist ein definierte Übergabese- quenz gewährleistet, und eine abgebende Kontrollstelle erfährt sofort, daß die neu zuständige Stelle ihre Verantwortung erkannt hat . Es kann daher kein Verantwortungsvakuum entstehen, in welchem ein Flugzeug „übersehen" werden könnte. Auch das Bestätigungssignal kann bevorzugt von Monitor zu Mo- nitor übertragen werden.

Das erfindungsgemäße System bietet weiterhin die Möglichkeit einer Kopplung zwischen den Systemen a) bis c) für den Austausch aktueller Informationen, insbesondere von Flugzu- Stands-, Positions-, Bewegungs-, Richtungs-, Radar- und/oder

Videoinformationen zwischen den Systemen a) bis c) , insbesondere bei einer Zuordnungsänderung. Bei den eingangs erwähnten, computerunterstützten Leitsystemen ist es teilweise möglich, charakteristische, aktuelle Informationen auf dem be- treffenden Bildschirm einzublenden und dadurch das Bedienpersonal mit den notwendigen Informationen über den aktuellen Zustand der verschiedenen Flugzeuge zu versorgen. Diese Informationen können auf den unterschiedlichsten Wegen gewonnen werden, bspw. durch Antwort eines in einem Flugzeug angeordneten Transponders auf ein Radarsignal, durch Mikrowellenoder Infrarotsensoren, durch Lichtschranken, Druckdosen oder Induktionsschleifen sowie durch Videoaufnahmen, GPS-Daten u.v.m. All diese Daten können verwendet werden, um auf ver- schiedenen Wegen aktuelle Parameter über Standort, Bewegungsrichtung, Geschwindigkeit, usf. eines Flugzeugs zu errechnen. Diese berechneten Daten können bei der oben beschriebenen Zuordnungsänderung gleichzeitig mit übergeben werden und erscheinen somit auf dem Bildschirm der nachfolgend zuständigen Kontrollperson. Da hierbei gleichzeitig der Einflußbereich des vorhergehenden Lotsen endet, kann das Flugzeug einschließlich der darauf bezogenen Daten in dessen Bildschirmliste ausgetragen bzw. von dessen graphischer Bilddarstellung gelöscht werden. Diese Daten begleiten die Darstellung des Flugzeugs somit von Kontrollstelle zu Kontrollstelle und können durch die unterschiedlichsten Sensorinformationen in regelmäßigen Abständen aktualisiert werden. Andererseits ist es auch möglich, derartige Flugzeugdaten an einer zentralen Stelle zu speichern, so daß eine gleichzeitige Darstellung an mehreren Bildschirmen möglich ist, damit ggf. Behinderungen auch von nicht zuständigen Koordinationsstellen frühzeitig erkannt und bei ihren Weisungen berücksichtigt werden können.

Es hat sich als günstig erwiesen, daß die Systeme a) bis c) jeweils eigene Monitore zur Informationsdarstellung aufweisen. Dies ist der Normalfall, wo die Verantwortung über die einzelnen Bereiche des Flughafens - Luftraum und Start- bzw. Landebahn, Rollbahnen und Vorfeld, Andockstationen - auf mehrere Personen des Kontrollpersonals aufgeteilt ist. Eine der- artige Konfiguration empfiehlt sich bei allen Groß- oder Regionalflughäfen während der Betriebszeiten mit normalem Verkehrsaufkommen, so daß bei unvorhergesehenen Ereignissen keine kritischen Situationen ausgelöst werden können.

Andererseits besteht die Möglichkeit, daß die Informationsdarstellung zweier oder aller Systeme a) bis c) zumindest zeitweise, insbesondere während Phasen mit niedriger Verkehrsdichte, auf demselben Monitor erfolgt. Hierbei kann bspw. in verkehrsarmen Nachtstunden die Einweisung sporadisch eintreffender Flugzeuge aus dem Luftraum bis zu der betreffenden Andockstation einem einzigen Fluglotsen übertragen werden, der in umgekehrter Reihenfolge auch während der gesamten Abflugphase zuständig ist. Dieser hat hierbei die Mög- lichkeit, wahlweise eines der mehreren Leitsysteme auf seinen Bildschirm zu holen und dadurch das Flugzeug während dessen gesamter Bewegungsphase optimal zu überwachen und zu lotsen. Die Umschaltung zwischen einzelnen Computerleitsystemen kann hierbei allein durch Software erfolgen, jedoch kann auch ein Videobild von einer Andockstation in analoger Form eingeblendet werden .

Die Übergabe eines einfliegenden Flugzeugs aus dem Einflußbereich eines Fluglotsen erfolgt bevorzugt mit dem Zeitpunkt des Aufsetzens auf der Landebahn. Dieser Zeitpunkt wird bei nahezu allen Flugzeugen mit Sensoren erfaßt und kann sodann über einen integrierten Transponder als Antwort auf eine Radarabtastung gemeldet werden. Diese Information wird auf der Bildschirmdarstellung des Fluglotsen sichtbar gemacht und zeigt diesem an, daß er nun die Kontrolle über dieses Flugzeug an die Bodenkontrollstation abgeben kann. Ein entsprechender Tastendruck und eine Bestätigung der Gegenseite besiegeln die Übergabe. Nun werden von der Bodenkontrollstation aus durch entsprechende Befeuerung der für das Flugzeug vor- gesehenen Rollbahnen dessen Piloten bis in das Vorfeld geleitet, und durch eine Positionserfassung, bspw. mit einem Bodenradar, erhält der zuständige Bedienstete des Kontrollzentrums eine Rückmeldung, wann das Flugzeug die Position zur Übernahme durch das Andocksystem erreicht hat. Nun erfolgt ein Handshake mit dem Andock-Koordinator , und dieser kann anhand der Videoeinrichtung an dem betreffenden Terminal das Flugzeug in die exakte Parkposition einweisen.

In umgekehrter Reihenfolge wird dieser Koordinator zunächst die Loslösung des betreffenden Flugzeugs von diesem Terminal in die Wege leiten und sodann die Kontrollgewalt an einen Bediensteten der Bodenkontrollstation übergeben, sobald das Flugzeug sich weit genug von dem Terminal entfernt hat. Nun ist die Bodenkontrollstation zuständig, bis das Flugzeug die Startbahn erreicht hat und dort auf die Startfreigabe durch den Tower wartet. Dieser übernimmt zunächst die Weisungsbefugnis von der Bodenkontrollstation, und nachdem alle sonstigen Voraussetzungen erfüllt sind, kann die Startfreigabe er- folgen und der Fluglotse verfolgt nun die weiteren Bewegungen des startenden Flugzeugs auf seinem Radarschirm.

Das erfindungsgemäße System kann relativ einfach aufgebaut sein, wenn die einzelnen Systemkomponenten über genormte Da- tenschnittstellen verfügen. Dies kann erreicht werden, indem das Flughafenkoordinationssystem als mehrschichtiges System mit graphischer Oberfläche aufgebaut ist, wobei ein Grundsystem, das auf Flugplandaten sowie aktuellen An- und Abflug- sowie RadarInformationen basiert, eine objektorientierte, re- lational arbeitende Datenbank zugeordnet ist, die uhrzeitbe- zogene Detail-Daten auf dem Monitor ausgebend ausgebildet ist . Damit ist der Grundstein für eine Lehre zur detaillierten

Hard- und Softwareausgestaltung eines optimierten, allgemein einsetzbaren Flughafenkoordinationssystems gelegt, das insbesondere für Großflughäfen geeignet ist. Auf dieser Basis lassen sich die Applikationssoftware und die Datenbank gemäß Erfindung realisieren. Ferner lassen sich die Anforderungen an die Hard- und Softwareumgebung entwickeln. Es läßt sich ein Überblick über den Datenfluß schaffen, der aufgrund der Bedingungen und sonstigen Schnittstellen erforderlich ist.

Nach einer anderen Ausbildung der Erfindung erfolgt die Synchronisation und der Datenaustausch mit Hilfe einer Signalschlange, wobei im Zusammenhang mit Client-Applikationen eine zyklische Abfrage, und im Zusammenhang mit Änderungen an ei- nem Flugplan eine Aktualisierung der Anzeige und des Dateninhalts stattfinden. Damit ist die Möglichkeit eröffnet, daß das erfindungsgemäße Flughafenkoordinationssystem die Flug- plandatenverteilung und die aktualisierte Anzeige auf der Anwenderoberfläche der Clientmonitore automatisch ausgibt.

Grundsätzlich kann das erfindungsgemäße Flughafenkoordinationssystem als eigenständiges System effizient betrieben werden. Bevorzugt ist es mit Schnittstellen zu anderen Systemen versehen, wodurch die Leistung aller beteiligten Systeme in vielfältiger Weise erhöht ist. U.a. kann auch ein Austausch an- und abflugrelevanter Daten mit einem Flughafenverwaltungssystem, bspw. dem an sich bekannten ITOS, stattfinden. Dieses VerwaltungsSystem ist eine auf Unix basierende Anwendung zur Abrechnung und Verwaltung der Flugbewegungen an Flughäfen. Die Anwendung verfügt über eine (Motif- ) Schnittstelle als graphische Bedienoberfläche. Die Flugpläne sowie die erforderlichen Stammdaten werden in einem relationalen Datenbanksystem (Ingres, Oracle, Informix) gespeichert und verwaltet. ITOS verfügt ferner über verschiedene Schnittstel- len zu externen Systemen, über welche Daten aktueller Flugbewegungen oder angekündigter Flugbewegungen ausgetauscht werden und die dann automatisch weiterverarbeitet werden können.

Zur Lösung der Erfindungsaufgabe wird bei einem Flughafenkoordinationssystem mit den eingangs genannten Merkmalen im Rahmen der allgemeinen erfinderischen Idee ferner vorgeschlagen, daß es die Koordination des ankommenden und des abgehenden Verkehrs ermöglichend ausgebildet ist. Dabei ist es - in Verallgemeinerung der zuvor erörterten Erfindungsalternative im Zusammenhang mit dem genannten Flughafenverwaltungssystem - besonders effizient, wenn das Flughafenkoordinationssytem Schnittstellen aufweist, um Informationen über Flugplandaten von externen Systemen empfangen zu können. Beispielsweise werden dazu Daten von zumindest einem Radardatenverarbeitungssystem bereitgestellt, das vorzugsweise über ein LAN (local area network) und/oder ein WAN (wide area network) verbunden ist und wobei zwischen einem Server des Flughafenkoordinationssystems und der Radardatenverarbeitung Rufsigna- le in Form des (an sich bekannten) SSR-Codes übermittelbar sind.

Zu dem erfindungsgemäßen Konzept gehört insbesondere die Schnittstelle zwischen dem Flughafenkoordinationssystem und weiteren Datenverarbeitungssystem. Das Konzept dafür muß so flexibel wie möglich sein, um in unterschiedlichen Umgebungen verschiedener Datenverarbeitungssysteme eingesetzt werden zu können. Zudem ist es von Bedeutung, daß die Anforderung an die Schnittstellenimplementierung bei einem weiten Bereich an Hardware-Grundbausteinen erfüllt sind. Die erfindungsgemäße

Kopplung bringt weitere Schnittstellenanforderungen mit sich, und es muß möglich sein, diese ohne Änderung des Grundkonzeptes integrieren zu können. In dieser Hinsicht besteht eine Ausbildung der Erfindung darin, daß das Flughafenkoordinati- onssystem in einem -weiten Bereich konfigurierbar ist, und zwar im Hinblick auf die unterschiedlichen Schnittstellen- Anforderungen verschiedener Datenverarbeitungssysteme .

Das Schnittstellen-Design auf der Basis der Erfindung ist auf die allgemeinen Anforderungen zugeschnitten. Hauptkomponenten zur Beschreibung der Schnittstelle zwischen dem erfindungsgemäßen Flughafenkoordinationssystem und weiteren Datenverarbeitungssystemen sind vor allem die Anforderungen für den Da- tenaustausch, die wechselseitige Verbindung der beiden Systeme und das Kommunikationsprotokoll sowie Eingabe-/Ausgabe- Werte . Die detaillierten Datenstrukturen kann der Fachmann bei der Implementierung ohne weiteres herleiten. Vorliegende Erfindung schafft hierfür bzw. für die Implementierung der Schnittstelle in beiden/allen Systemen die Basis.

Zur Identifikation einzelner Flugzeuge kann das Flughafenkoordinationssystem mit einer RufZeichenzuordnung zu einem SSR- Code arbeitend ausgebildet sein. Dies ermöglicht eine leich- tere Identifikation des Objekts innerhalb des Radardatenverarbeitungssystems. Insbesondere kann eine Rufzeichenanforderung mit Darstellung nach Eintritt eines Flugzeuges in einen bestimmten Kontrollraum automatisch erfolgen.

Es liegt im Rahmen der Erfindung, daß das Flughafenkoordinationssystem eine Kontrollraumüberwachung aufweist, die zwischen ankommenden, abfliegenden und überfliegenden Objekten, also zwischen relevanten und nicht relevanten Objekten, unterscheidet .

Mit Vorteil ist das erfindungsgemäße Flughafenkoordinations- system derart ausgebildet, daß mit ihm zu entsprechenden SSR- Codes flugplanbezogene Daten übermittelbar sind. Dadurch wird die Möglichkeit eröffnet, andere Kommunikationswege oder -

Systeme zu entlasten oder ganz zu vermeiden.

In Ausgestaltung der Erfindung ist vorgesehen, daß in die Er- fassung und operationeile Leitung Fahrzeugbewegungen auf dem Flughafengelände einbezogen sind, z.B. mit Hilfe von Trans- ponderabfragen oder Squittern von Transpondern oder über ID- Tags und drahtlose Kommunikationsmittel, die auch zur Übertragung von Anweisungen genutzt werden können. So wird die Kollisionssicherheit in Bezug auf den Bodenverkehr, der bisher besonders im Vorfeld-Bereich weitgehend unkontrolliert abläuft, entscheidend erhöht. Es ist weiterhin vorgesehen, daß in die Erfassung und operationeile Leitung die Flugbewegungen im Anflug- und Abflugbereich einbezogen sind. So er- gibt sich eine Optimierung der Bodenbewegungsplanung und gleichzeitig die Erhöhung der Sicherheit durch frühzeitige Erkennung von Abweichungen des realen Zustandes des Verkehrs von dessen geplantem Zustand, z.B. daß eine Rollbahn noch belegt ist, die bereits geräumt sein sollte.

Eine besondere Erhöhung der Sicherheit ergibt sich durch die Benutzung sowohl mindestens eines Primär- als auch mindestens eines Sekundärradars , wobei das Primärradar der Ortung auf dem Flughafengelände und das Sekundärradar vorzugsweise im An- und Abflugbereich unter Transponderbenutzung zur Identifikation dient. Die Identifikation am Boden wird erfindungsgemäß durch Übernahme der Identifikation vom Anflugradar (Sekundärradar) bei laufendem Verkehr bzw. vom Docking Guidance System beim startenden Verkehr und Beibehaltung der Identifikation durch Tracking der Ziele des Primärradars durchgeführt. Zur weiteren Erhöhung der Sicherheit und Zuverlässigkeit werden erfindungsgemäß Squitter von Transpondern der Flug- und gegebenenfalls mit Transpondern ausgerüsteten Fahrzeuge am Boden detektiert und durch Multilateration der SignaleintreffZeitpunkte die exakte Position bei gleichzeitiger Identifikation ermittelt. So ist eine jederzeitige, redundante Identifizierung der Flugzeuge und ggf. auch sonstigen Fahrzeuge im Verkehrsbereich eines Flughafens möglich.

Es ist dabei vorgesehen, daß das erfindungsgemäße System eine Rollbewegung-Planungskomponente aufweist, mit der es möglich ist, der Bodenkontrollstation Rollführungsrouten vorzuschlagen und diese auf Kollisionsfreiheit automatisch zu überprü- fen. Die Planungskomponente und die Überprüfung der Kollisionsfreiheit erfolgt durch eine fest installierte Software, der die entsprechenden Sicherheitsfeatures eingegeben sind. Durch diese wird auch die Einhaltung der Mindestabstände unter den verschiedenen Witterungsbedingungen besorgt. Diese Planungssoftware enthält auch Zwischenstop-Positionen für die Flugzeuge, die eine kollisionsfreie Bewegung auch im Vorfeld- Bereich garantieren. Grundlage der Planungen bilden vorteilhaft die Flugpläne. Auf Großflughäfen erfolgen die Start- und Landebewegungen nicht spontan, sondern werden flugplangerecht geplant, ebenso die Gatebelegung. Weiterhin kann die Befeuerung der Rollbahnen insbesondere hinsichtlich ihrer Ansteue- rung programmtechnisch in das erfindungsgemäße Flugzeugleitsystem eingebunden und/oder an dieses angekoppelt sein.

Es ist vorgesehen, daß in dem Flughafen-Bodenverkehrs-Leit- system die notwendigen Anzeigen auf einem Monitor des Lotsen über ein an sich bekanntes Videosubsystem (Processing) ausgegeben werden. Derartige Radarvideosubsysteme werden z.B. von der Fa. HITT zur Verfügung gestellt, ein Beispiel zeigt die Annonce aus der Fachzeitschrift „Jane 's Airport Review, Sept.

1995, Volume 7, Issue 7, Seite 46".

In dem Radarvideo erfolgt eine Anzeige entsprechend den Angaben des BRITE II-Systems mit höherer Datenkonzentration und detaillierten Angaben, als sich aus der Kombination des bekannten BRITE II-System und des bekannten Radarvideos der Firma HITT ergeben würden. Es ist vorteilhaft vorgesehen, daß die Anzeigen auf dem Monitor, z.B. das reale Radarvideo oder ein synthetisches Radarbild und/oder ein synthetisch gebildetes Abbild der Verkehrswege des Flughafens, mit Fenstern mit Statusanzeigen, Übergabezeilen und Quittierungszeilen etc. sowie mit den Schaltzuständen der Rollbahn-Befeuerungsabschnitte, der Stopbars etc. auf einem Monitor gemeinsam dar- stellbar sind. Diese Konzentration erfolgt in Abhängigkeit von dem jeweiligen Verkehrsaufkommen des Flughafens, so ist z.B. bei Nacht nur ein Controllerplatz zu besetzen, während am Morgen mit steigendem Verkehrsaufkommen weitere Controllerplätze gebildet werden. Entsprechend erfolgt dann eine Aufteilung der Verantwortung auf die einzelnen Lotsen der Bodenkontrollstation oder im Tower.

Die Übergabe der Verantwortung erfolgt vorteilhaft nach einer Übergabequittierung in Fensterdarstellung auf dem Monitor oder auf Hilfsmonitoren, damit eine sichere Arbeitsplatzverteilung gewährleistet ist. Hiermit läßt sich eine streifenlose Organisation eines Towers realisieren.

Eine besonders vorteilhafte Durchführung der vorstehend ge- schilderten Abläufe ist möglich, wenn ein großer Flachbildschirm für die Darstellung der einzelnen Fenster, des Radarvideos etc. verwendet wird, insbesondere in Ausführung als Touchscreen. Bei einem derartigen Touchscreen kann sowohl eine Schaltung durch Berühren der jeweiligen Punkte, z.B. der Stopbars oder Rollbahn-Abschnitte auf dem gebildeten synthetischen Video erfolgen als auch durch Anklicken mit einer Maus oder durch das Bedienen von Schaltpunkten auf dem Rand des Monitors. So ist eine vorteilhafte Konzentration aller Schaltpunkte, die bisher in gesonderten Pulten, sogenannten Keyboards, erfolgte, im Sichtbereich des Controllers möglich.

Entsprechend erhöht sich die Sicherheit der Bedienung mit der Möglichkeit der direkten Kontrolle und Bestätigung der durchgeführten Schaltvorgänge wie auch ähnlich ablaufender Überga- besequenzen.

Zur notwendigen Datenkonzentration ist vorgesehen, daß zunächst alle Daten digitalisiert werden, also auch die analog vorliegenden Radardaten. Hierzu ist die plot-extraction vor- teilhaft unter Zuhilfenahme der Datenfusion und Einbeziehung der Sensorkorrelationsdaten besonders hilfreich. Alle Daten werden auf ein einheitliches Format gebracht, und dann dem Radarvideo oder einem vollständigen synthetischen Bild aufgegeben .

Zur Erhöhung der Planungssicherheit und zur Berücksichtigung von Notfällen ist vorgesehen, daß das System mit Daten der Flugzeugbewegungen im weiteren Luftraum, ggf mit durch GPS, insbesondere durch Differential-GPS, ermittelten Anflug- und Abflugpositionen, Positionen auf dem Rollfeld und ggf im

Parkbereich versorgt wird. Die Verwendung von GPS erhöht in diesem Zusammenhang die Sicherheit, da so eine zusätzliche Positionsinformation zur Verfügung steht. Wegen der Unsicherheit der GPS-Funktion, insbesondere im Terminalbereich, ist diese Ausführung jedoch nur zur Erhöhung der Sicherheit, d.h. als Zusatzfunktion, vorgesehen. Die eigentliche Führung des Verkehrs erfolgt durch die sicheren Radardaten und weitere bodengestütze Sensoren sowie durch Sichtkontrolle der Lotsen. Derartige Sensoren können auch optische Sensoren sein, insbe- sondere im Dockingbereich, hier in Form von Lasern oder Zeilenkameras .

In diesem Leitsystemteil kann ein Programmabschnitt enthalten sein, der es erlaubt, von dem betreffenden Bedienpult aus oder gar von demselben Monitor aus die über das Flughafengelände verteilt angeordneten Befeuerungsanlagen und die in deren Stromkreis eingeschleiften Sensoren, insbesondere Positionssensoren definiert anzusprechen und/oder abzufragen und dadurch einerseits die für die Lotsung des betreffenden Flugzeugs relevanten Befeuerungen in Betrieb zu nehmen und andererseits die von den einzelnen, adressierbaren Sensoren erzeugten Meldungen einzulesen und dadurch den ordnungsgemäßen Weg des Flugzeugs zu überwachen. Ein derartiger Informations- austausch sowie die hierzu geeigneten Endgeräte sind bspw. in der US-Patentschrift 5,584,151 offenbart.

In Bezug auf das Dockingsystem ergibt sich eine vorteilhafte Erhöhung der Sicherheit, wenn die von dem Dockingsystem ge- lieferten Positionsdaten in die Datenfusion und Sensorkorrelation eingeführt werden und umgekehrt. Wenn dies unter Berücksichtigung der Parkpositionspläne erfolgt, diese also ebenfalls in die Bodenverkehrsplanungen mit einbezogen werden, erhöht sich die Sicherheit weiter.

Schließlich verfügen moderne Docking-Programme über eine Auswerteeinheit, die zur Erkennung unterschiedlicher Flugzeug- Bautypen auf jeweils charakteristische Bildschablonen dieser Flugzeuge zurückgreifen kann, welche bspw. fünf markanten Um- rißabschnitten eines Flugzeugs entsprechen und zwecks Identifizierung mit den Umrißabschnitten eines sich dem Flughafenterminal nähernden Flugzeugs vergleichbar sind. Ein genaues Erfassen des Bautyps des sich dem Flughafenterminal nähernden Flugzeugs ist auch dann gesichert, wenn nicht die gesamte Kontur des anrollenden Flugzeugs mittels der Videoeinrichtung erfaßbar ist, bspw. deshalb, weil sich Hindernisse auf dem Parkfeld bzw. dem Vorfeld des Flughafenterminals befinden. Als besonders geeignete Videoeinrichtung zur Verwirklichung des erfindungsgemäßen Dockingsystems bzw. dessen Positioniervorrichtung hat sich eine Graubildkamera erwiesen.

Die Objektivbrennweite der Videoeinrichtung sollte vorteilhafterweise etwa 16 bis 25 mm betragen.

Eine ausreichende Erfassung des sich an das Flughafenterminal annähernden Flugzeugs wird gewährleistet, wenn die Videoein- richtung etwa fluchtend mit der Mittellinie des Flughafengates, vorzugsweise in ca. 9 m Höhe, angeordnet ist.

Eine mit einem vergleichsweise geringen Aufwand durchführbare Erfassung des Bautyps des sich dem Flughafenterminal annä- hernden Flugzeugs ist erreichbar, wenn in die Auswerteeinheit eine Sequenz von durch die Graubildkamera erzeugter Grauwertbilder einlesbar ist, die einzelnen Grauwertbilder räumlich filterbar sind, um Grauwertkanten zu extrahieren, die Sequenz von Grauwertbildern zeitlich filterbar ist, um Bewegungsbilder zu erzeugen, und aus den Bewegungsbildern eine Maske erzeugbar ist, die Bereiche für eine nachfolgende Segmentierung festlegt.

Zur zeitlichen und räumlichen Filterung der Grauwertbilder sollte die Auswerteeinheit zweckmäßigerweise einen Sobel-

Filter aufweisen.

Als für die Flugzeugkontur jedes Bautyps besonders markante Umrißabschnitte haben sich zwei Triebwerke, das Windshield und zwei Fahrwerke erwiesen, wobei diese fünf markanten Umrißabschnitte bzw. Bildschablonen zweckmäßigerweise einen Schablonensatz bilden, der für den jeweiligen Flugzeugtyp festgelegt und in der Auswerteeinheit abgespeichert ist. Zur aktuellen Positionsbestimmung des sich dem Flughafenterminal annähernden Flugzeugs können durch die zeitliche Filterung der Grauwertbilder ermittelte Trajektorien der Schablonen bzw. markanten Umrißabschnitte der Flugzeugkontur einge- setzt werden.

Bei vollständiger Verwirklichung und Installation des erfindungsgemäßen Dockingsystems, insbesondere von dessen Positioniervorrichtung, ist es möglich, sämtliche beim Andocken des Flugzeugs erforderlichen Arbeitsvorgänge, insbesondere das

Andocken der Brücke an das Flugzeug, automatisch ablaufen zu lassen. Hierbei ist es möglich, daß die Videoeinrichtung lediglich eine Videokamera aufweist.

In besonders vorteilhafter Weise kann die vorstehend beschriebene Bildelementverarbeitung sowie die Auffindung des Bautyps des sich an das Gate des Flughafenterminals annähernden Flugzeugs bei einem Dockingsystem für Flughafenterminals zum Einsatz kommen, das je Gate eine Dockingeinheit hat, die über ein Kommunikationsnetzwerk mit einer zentralen Steuereinrichtung in Verbindung steht, ein Flugfeldsituationsüber- wachungs- und -Verarbeitungssegment, zumindest ein Informati- ons- und Leitanzeigesegment, ein Daten- und Statusweiterlei- tungssegment mit zumindest einer Videokamera je Mittellinie des Gate, und ein Gatebetriebssteuersegment aufweist, und der eine Eingabeeinheit zugeschaltet sein kann, mittels der Flugzeugmuster und das Gate betreffende Informationen in sie eingebbar sind.

Zweckmäßigerweise verfügt die Dockingeinheit je Mittellinie ihres Gate über ein Informations- und Leitanzeigesegment.

Eine besonders vorteilhafte Ausgestaltung dieses Informati- ons- und Leitanzeigesegment wird erzielt, wenn ein Mikropro- zessor vorgesehen ist, der die Anzeigeelemente steuert und

Anzeigebefehle in Anzeigen der Anzeigeelemente umwandelt.

Eine apparativ und konstruktiv wenig aufwendige Ausgestaltung der erfindungsgemäßen Dockingeinheit bzw. des erfindungsgemäßen Dockingsystems wird erreicht, wenn das Daten- und Statusweiterleitungssegment der Dockingeinheit auf derselben Hardware läuft wie das Flugfeldsituationsüberwachungs- und - Verarbeitungssegment und die Kommunikation zwischen der Dock- ingeinheit und der zentralen Steuereinrichtung über das Kommunikationsnetzwerk bewerkstelligt wird sowie die Vorgänge innerhalb der Dockingeinheit mittels des Daten- und Status- weiterleitungssegments koordiniert werden.

Bei einer Weiterbildung des erfindungsgemäßen Dockingsystems können das Daten- und Statusweiterleitungssegment und das Flugfeldsituationsüberwachungs- und -Verarbeitungssegment der Dockingeinheit in einem Gehäuse angeordnet sein.

Bevorzugt können das Daten- und Statusweiterleitungssegment und das Flugfeldsituationsüberwachungs- und verarbeitungsseg- ment auf einer Hardware-Basis aus einem PC-Motherboard und der Videosignalverarbeitungsausrüstung laufen. Sofern bei der Konzeption der Dockingeinheit des erfindungsgemäßen Docking- Systems eine Anordnung des Daten- und Statusweiterleitungs- segments sowie des Flugfeldsituationsüberwachungs- und - verarbeitungssegements außerhalb des eigentlichen Gate vorgesehen ist, so ist es möglich, zusätzlich das Informationsund Leitanzeigesegement mit in dem für die beiden vorgenann- ten Komponenten gemeinsamen Gehäuse anzuordnen.

Bei einer weiteren speziellen Ausführungsform eines derartigen Dockingsystems ist die Dockingeinheit so ausgebildet, daß Informations- und Leitanzeigen von ihr auf einen Bildschirm im Cockpit eines sich an das Gate annähernden Flugzeugs übertragbar sind. Diese Betriebsweise kann an die Stelle des Betriebs des Informations- und Leitanzeigesegments treten oder zusätzlich zum Betrieb dieses Informations- und Leitanzeigesegments vorgesehen sein.

Es ist auch möglich, das Flugfeldsituationsüberwachungs- und -verarbeitungssegment in einem Gehäuse mit der Videokamera anzuordnen.

Zur Übertragung von Daten zwischen dem Flugfeldsituationsüberwachungs- und -Verarbeitungssegment und dem Daten- und Statusweiterleitungssegment der Dockingeinheit ist es zweckmäßig, dem Flugfeldsituationsüberwachungs- und -verarbei- tungssegment einen Digitalsignalprozessor zuzuordnen, in welchem die ursprünglich analogen Videosignale in digitale Signale umgewandelt werden, bevor sie in die Eingabeleitung zum Daten- und Statusweiterleitungssegment eingegeben werden.

Die Eingabeeinheit, die der Dockingeinheit des erfindungsgemäßen Dockingsystems zugeordnet ist, hat vorzugsweise eine Flugzeugmusterausgabe, ein Gateeinrichtungschema, eine Kalibriereinheit und eine Validations- und Diagnoseinheit.

Vorteilhafterweise ist das Kommunikationsnetzwerk eines derartigen Dockingsystems als Hochgeschwindigkeitsnetz mit asynchronem Übertragungsmodus ausgebildet, mittels dem ursprünglich digitale Signale und zu digitalen Signalen gewandelte, ursprünglich analoge Signale, z.B. Videosignale, übertragbar sind.

Das ATM-Hochgeschwindigkeitsnetz kann vorteilhafterweise zumindest einen als SICAN ATMax 155-PM2 ausgebildeten Netzwerkadapter aufweisen. Zweckmäßigerweise ist die Dockingeinheit in ein Bodenüberwa- chungs- und -verarbeitungssegment, ein Gatesteuersegment , ein

Gateprogrammsegment und ein Gatedatenweiterleitungssegment gegliedert .

Vorteilhaft weist das Bodenüberwachungs- und -verarbei- tungssegment eine Flugfeldüberwachung und einen Flugfeldsituationsprozessor auf, der mittels eines Interface an das Ga- teprogrammsegment angeschlossen ist.

Das Gatesteuersegment der Dockingeinheit hat eine Flugfeldbodenbeleuchtung, eine Informations- und Leitanzeige, eine Gatebetriebssteuerung, ein Luxometer und einen Gateprozessor, der auf einer PC-Plattform läuft, an welche die Flugfeldbo- denbeleuchtung, die Informations- und Leitanzeige, die Gatebetriebssteuerung und das Luxometer angeschlossen sind, und der mittels eines Interface an das Gateprogrammsegment angeschlossen ist.

Das Gatedatenweiterleitungssegment sollte eine Kalibrierhilfe und eine Festdatenweiterleitung aufweisen, die auf einer PC- Plattform laufen und mittels jeweils eines Interface an das Gateprogrammsegment angeschlossen sind.

Das Gateprogrammsegment der Dockingeinheit hat ein Gatemanagement und eine Überwachung.

Weitere Einzelheiten, Merkmale, Wirkungen und Vorteile auf der Basis der Erfindung ergeben sich aus der folgenden Be- Schreibung einiger bevorzugter Ausführungsformen der Erfindung sowie anhand der Zeichnung. Diese zeigt in:

FIG 1 eine schematische Darstellung der Komponenten eines Koordinationssystems für die Flugkontrolle; FIG 2 ein Schaubild mit einem Überblick über die Software eines derartigen Koordinationsprogramms ; FIG 3 eine Bildschirmdarstellung auf dem Monitor eines Flugkoordinators ; FIG 4 eine schematische Darstellung der Komponenten einer Station zur Leitung des Bodenverkehrs; FIG 5 ein verallgemeinertes Blockschaltbild eines Bodenver- kehrskontrollsystems ; FIG 6 eine graphische Darstellung, wie sie auf dem Bildschirm eines Arbeitsplatzes der Bodenkontrollstation sichtbar ist; FIG 7 ein Schaubild, welches die Aufgaben und Vernetzungen eines derartigen Bodenleitsystems wiedergibt; FIG 8 eine schematische Darstellung der Komponenten eines An- docksystems im Bereich eines Flughafen-Gates;

FIG 9 einen Ausschnitt aus dem Vorfeld eines Flughafens mit einem ankommenden Flugzeug kurz vor der Andockphase; FIG 10 ein Ablaufdiagramm zur Ermittlung der Position des Flugzeuges während der Andockphase, FIG 11 eine vereinfachte Darstellung eines Teils des Informationsflusses innerhalb einer Andockstation; FIG 12 ein Blockschaltbild einer Andockstation mit deren

Schnittstellen; FIG 13 einen Signalflußgraphen, der den Informationsfluß zwi- sehen den verschiedenen Kontroll- und Leitsystemen in der Phase zwischen dem Landeanflug und dem Andocken eines Flugzeugs wiedergibt; sowie FIG 14 eine der FIG 13 entsprechenden Darstellung, welche den Informationsfluß bei einem Flugzeugstart darstellt.

In FIG 1 ist die Systemarchitektur des Flughafenkoordinationssystems mit einer Aufteilung der Applikation in einen Server (Diensterbringer) 1 und einen Kliententeil (Dienstan- forderer) , bestehend aus mehreren Arbeitsplätzen 2, darge- stellt. Vorzugsweise ist die Konfiguration so, daß der Server

1 genau einmal im Flughafenkoordinationssystem existiert, die Client-Arbeitsplätze 2 sind dagegen bevorzugt mehrfach vorhanden. Auf jedem Arbeitsplatz 2 steht die gleiche Funktiona- lität zur Verfügung. Die Verteilung der Aufgaben auf Arbeitsplätze 2 und Server 1 sowie die Synchronisation der Anforderungen ist applikationsabhängig. Der abgebildete Systemdruk- ker 3 ist als Netzwerkdrucker angeschlossen.

Der Server 1 des Flughafenkoordinationssystems stellt unter anderem folgende Dienste bzw. Schnittstellen zur Verfügung: Datenbank-Server, interne Dienste des Flughafenkoordinationssystems zur Synchronisation und zum Datenaustausch mit den Client-Arbeitsplätzen 2, Schnittstelle zu einem ITOS-Flug- hafenverwaltungsSystem 4, Schnittstelle zu einem Radardatenverarbeitungssystem 5, bspw. „Watchkeeper AP 100", Erstellung von Listen mit allen durchgeführten Flugplänen eines Tages, Uhrzeitserver .

Die Aufgaben der Client-Arbeitsplätze 2 sind beim Flughafenkoordinationssystem unter anderem folgende: Darstellung aktueller und vorangekündigter Flugpläne, (Ankunft, Abflug, Überflug) , Eingabe neuer sowie Modifikation bestehender Flugpläne, Durchführen von Zustandsübergangen bei Flugplänen sowie Aktualisierung aller Displays nach einer Bedienereingabe, Uhrzeitsynchronisation mit dem Server.

Als Kommunikationssystem zwischen dem Server 1, den Arbeitsplätzen 2, dem Systemdrucker 3, dem ITOS-Flughafenverwal- tungssysem 4 und dem Radardatenverarbeitungssystem 5 kann ein

LAN (Local Area Network) 6 dienen. Dieses kann auf Ethernet oder TCP/IP basieren. Für die Serverhardware kann ein System mit folgenden Elementen verwendet werden: Computer-Zentraleinheit mit wenigstens 64 MB Hauptspeicher, Festplatte, Diskettenlaufwerk, Konsole, Tastatur, Netzwerkanschluß, CD-ROM-Laufwerk, DCF-Empfänger- baugruppe und Bandlaufwerk.

Falls auf dem Server weitere Anwendungen wie z.B. ein Radararbeitsplatz ablaufen, muß der Hauptspeicherausbau mind. 128 MByte betragen. Der Ausbau der Festplattenkapazität ist eben- falls anzupassen.

Als Client-Hardware werden IBM-kompatible Personalcomputer mit folgendem Ausbau verwendet: CPU 486 DX 2, Taktfrequenz wenigstens 66 MHz, mindestens 8 MByte Hauptspeicher, Maus, Tastatur, Monitor (17 '' -Farbmonitor oder 10 , 4 ' ' -TFT-Flach- bildschirm, Auflösung mindestens 640 x 480 Punkte) , Festplatte (optional), Diskettenlaufwerk (optional), Netzwerkanschluß.

Die Softwarestruktur des Servers 1 kann folgende Komponenten umfassen: USF/1 (UNIX-Betriebssystem), TCP/IP (Netzwerkkommunikation, Bestandteil von UNIX) , Oracle (RDBMS) , TECOS (allgemeine Serverprozesse) sowie einen Uhrzeit-Server.

Die Softwarestruktur eines Client-Arbeitsplatzes 2 kann folgende Komponenten umfassen: MS-DOS (Betriebssystem), MS- Windows (GUI) , TCP/IP (Netzwerkkommunikation) , SQL/Net (Oracle Datenbankschnittstelle) , ODBC (offene Datenbankschnittstelle) , TECOS (Client-Applikation) sowie einen Uhr- zeit-Dienstanforderer .

Durch besondere Konfigurations- und Programmiermaßnahmen wird erreicht, daß außer der Flughafenkoordinationssystem-Anwendung, die beim Starten automatisch anläuft, keine anderen An- Wendungen auf den Client-Arbeitsplätzen 2 gestartet werden können. Also sind die Client-Arbeitsplätze 2 auf Flughafenkoordinations-Anwendungen beschränkt, wobei die Flughafenkoor- dinations-Benutzeroberflache beim Starten automatisch an- läuft.

In FIG 2 ist ein Überblick über ein beispielhaftes Prozessmodell für das Flughafenkoordinationssystem dargestellt, wobei die erforderlichen Prozesse sowohl auf dem Server als auch auf dem Client implementiert sein können.

Auf den Client-Arbeitsplätzen 2 ist der Prozess TECOS mit einem Steuerungs- und Controlling-Interface implementiert, einschließlich graphischer Bedienoberfläche; ein Eventhandler (Verwaltung und Koordination von Datenbank-Ereignissen) ;

Luftfahrzeug-Rollen-Bearbeitung; Prozeß zum Auslesen der Uhr- zeit vom zugeordneten Server-Uhrzeitprozess .

In dem Prozeß „Dispatcher", können bei Bedarf Daten über War- teschlangentabellen (Radardatenverarbeitungs-Schlange-RDP-

Queue; ITOS-Queue zum Flughafenverwaltungssystem) über externe Schnittstellen wie z.B. die APlOO-Schnittstelle (Datenaustausch mit dem Radardatenverarbeitungssystem AP100) , die ITOS-Schnittstelle (Datentaustausch mit ITOS-Flughafen) und/ oder eine Schnittstelle zum Bodenleitsystem ausgetauscht werden.

Der Datenaustausch zwischen Prozessen erfolgt im allgemeinen über Datenbanktabellen. Ein Prozeß, der Daten zur Verfügung stellen möchte, trägt einen entsprechenden Datensatz in eine Tabelle der Datenbank ein, und die Prozesse, die diese Daten benötigen, lesen diese aus der Datenbank-Tabelle wieder aus. Die Synchronisation der Prozesse bzw. die Information über die Existenz neuer oder geänderter Daten erfolgt über Daten- bank-Events, die vom Datenbank-System verwaltet werden.

Hierfür stehen entweder Signale oder Pipes zur Verfügung. Signale werden vom Datenbanksystem direkt an die für das Signal angemeldeten Prozesse weitergegeben, während bei der Synchro- nisation über Pipes der Prozeß selbständig die Existenz neuer Daten in der Pipe prüfen muß. Jeder Prozeß bekommt außerdem die Funktionalität, sich über einen speziellen Datenbank- Event bzw. Pipeeintrag beenden zu lassen (entweder mit oder ohne Bestätigung durch den Anwender) . Alle Änderungen an Flugplänen werden in eine spezielle Signal-Queue eingetragen. Diese wird von den Client-Applikationen zyklisch abgefragt. Bei Änderungen an einem Flugplan kann daraufhin die Anzeige und der Dateninhalt aktualisiert werden.

Das Flughafenkoordinationssystem benötigt folgende Datenbanktabellen: RPL-Table (Saisonflugplan); Printtable; Stammdatentabellen, Fehlerliste; ITOS-Queue (gemeinsame Daten mit Flughafenverwaltungsprogrammen) , RDP-Queue (gemeinsame Daten mit Radarprogramm) .

Im RPL (Saisonflugplan) werden alle Flugpläne gespeichert, die zyklisch (täglich, wöchentlich, wöchentlich an bestimmten Tagen) durchgeführt werden. Aus dieser Tabelle werden die demnächst zu aktivierenden Flugpläne gelesen und in die Ta- belle „FplInUse" mit dem Zustand „FplInStore" eingetragen.

Die Tabelle FplInUse enthält alle Flugpläne, die der Bediener aktuell an der Bedieneroberfläche in einem der Bereiche „Approach" ( Preannounced App List, Approaching List, Landing List), „Departure" (Preannounced Dep List, Departing List, Airborne List) oder „Crossing List" angezeigt bekommt (Fig. 3) . Außerdem sind alle Flugpläne enthalten, die vom Zustand „FplInStore", „FplCancelled" oder EndOfUse" sind. In der Tabelle „FplSeqTable" werden Informationen in Form einer verketteten Liste hinterlegt, aus denen die Reihenfolge der Flugpläne in der Datenbanktabelle „FplInUse" (bzw. innerhalb der Teillisten im FplInUse) erzeugt werden kann, da die- se aus den zur Verfügung stehenden Zeiteinträgen allein nicht eindeutig ist, sondern auch vom Bediener beeinflußt wird.

In der Tabelle „WriteQueue" werden von den angeschlossenen Client-Applikationen des Flughafenkoordinationssystems die geänderten Flugplandaten eingetragen. Von hier aus können die Daten über den Prozeß „Client-Writer" weiterverarbeitet werden.

Die Tabelle „PrintTable" dient dazu, einen Druckerserver zu starten, der in Abhängigkeit von der Auftragsart/Auftragsnummer aus einer Tabelle die Daten extrahiert, diese zum Drucken aufbereitet und an einen Drucker sendet.

Zur Anpassung der Funktionalität des Flughafenkoordinations- Systems an die örtlichen Gegebenheiten des Flughafens sowie für alle anderen administrativen Zwecke werden verschiedene Stammdatentabellen verwendet, insbesondere: LfzRolle, Star- tlnfoTable, Usertable, LocalSsrCodeTable .

In der Luftfahrzeugrolle (LfzRolle) wird die Zuordnung

„Callsign" (Rufsignal) zu dem Luftfahrzeugtyp (LfzTyp) und Gewichtsklasse verwaltet. Zusätzlich sind in dieser Tabelle alle Typ-/Callsignzuordnungen enthalten, die das System selbständig nach einer Neueingabe durch den Bediener gespeichert hat (selbstlernender Teil der Datenbank) .

In der Tabelle „StatlnfoTable" werden Informationen gespeichert, die im statischen Infofeld (FIG 3) angezeigt werden sollen. Die Tabelle „Usertable" dient zur Verwaltung der zulässigen

Benutzer für einen Arbeitsplatz am Flughafenkoordinationssystem.

Die Tabelle „LocalSsrCodeTable" wird vom Flughafenkoordinationssystem dazu verwendet, für die Flugpläne ohne SSR-Code einen lokalen (temporären) Code zu vergeben. Der Code bleibt solange gültig, bis der Flugplan in den Zustand „FplInUse" kommt oder (bei Anbindung an ein Radardatensystem) bis der Code als nicht mehr benutzt gemeldet wird.

In der Tabelle „Timertable" sind Informationen über Zeitpunkt und notwendige Aktion für den Timerprozeß gespeichert.

Die Tabelle „Fehlerliste" beinhaltet die Fehlermeldungen 2. und 3. Ordnung. In FIG 2 sind aus Übersichtlichkeitsgründen nicht alle Prozesse als Datenquelle für diese Tabelle eingetragen. Grundsätzlich kann jedoch jeder Prozeß einen erkannten Fehler dort eintragen.

In den beiden Tabellen „ITOS-Queue" (Flughafenverwaltungssystem-Schlange) und „RDP-Queue" (Radardatenverarbeitungs- Schlange) werden vom Dispatcher-Prozeß bei Bedarf die Flugplandaten eingetragen, die an das entsprechende Remote-System übertragen werden müssen.

Gemäß dem erfindungsgemäßen Konzept werden die externen Schnittstellen beim Flughafenkoordinationssystem so weit wie möglich offen und unabhängig von der verwendeten Umgebung realisiert. Um dies zu erreichen, wird grundsätzlich von einer RPC-Schnittsteile (remote procedure call) ausgegangen. Durch die Verwendung dieses Standards ist gewährleistet, daß die unterschiedlichen Systeme vollkommen unabhängig voneinander realisiert werden können. Der Realisierungsaufwand wird durch die für nahezu alle HW-Plattformen verfügbaren Tools zur RPC-Programmierung minimiert. Insbesondere im Hinblick auf die Schnittstellen zu anderen Leit- und/oder Kontrollsystemen erreicht man durch RPC eine Maschinenunabhängigkeit. Dies bedeutet, daß die beiden Systeme sowohl gemeinsam auf einer Maschine als auch (z.B. aus Performancegründen) auf zwei getrennten Systemen, die über LAN verbunden sind, ablaufen können. Eine Änderung in der Software ist dafür nicht erforderlich. Für jede externe Schnittstelle können eigene Pro- zeduren realisiert sein.

Aufgabe einer Prizedur TecosRpcClient ist es, Daten, die an externe Systeme geschickt werden sollen, aus der Datenbank auszulesen und an den Empfänger zu transferieren. Hierfür muß auf der Empfängerseite ein geeigneter RPC-Server implementiert werden. Der RPC-Client ist nur für diejenigen externen Schnittstellen erforderlich, für die das Flughafenkoordinationssystem als Datenquelle dient.

Für jede externe Schnittstelle, über die das Flughafenkoordinationssystem Daten empfangen soll, ist ein eigener RPC- Server des Flughafenkoordinationssystems erforderlich. Dadurch wir die Parallelität bei der Bearbeitung verschiedener RPC-Aufrufe an den verschiedenen Schnittstellen gewährlei- stet.

Wenn im Radardatenverarbeitungssystem ein Luftfahrzeug dedek- tiert wird, ihm kein Rufsignal zugeordnet ist, und dieses sich innerhalb eines als interessierend definierten Gebiets (area of interest) befindet, wird eine Anforderung an das

Flughafenkoordinationssystem gesendet, ein zugeordnetes Rufsignal zurückzuübermitteln. Wenn dieses vorhanden ist, quittiert das Flughafenkoordinationssystem die Anforderung ausdrücklich und sendet das Rufsignal zurück. Wenn ein zugeord- netes Rufsignal nicht vorhanden ist, sendet das Flughafenkoordinationssystem eine negative Antwort zurück. Als „interessierender Bereich" (area of interest) wird ein Kreis um das Zentrum des Arbeitsraumes des Radardatenverarbeitungs- Systems verwendet und entsprechend innerhalb dieses Systems definiert. Sowohl bei Annäherung als auch beim Abflug eines Luftfahrzeugs wird die Rufsignalanforderung gesendet.

Fliegt ein Luftfahrzeug vom Flughafen ab und erscheint im Ra- dardatenverarbeitungssystem, so wird für diesen Flug ein

Flugplan (und ein Rufsignal) im Flughafenkoordinationssystem vorhanden sein.

Eine Änderung des Rufsignals wird vom Flughafenkoordinations- System zum Radardatenverarbeitungssystem übermittelt. Es schließt sowohl das Rufzeichen als auch den zugehörigen SSR- Code als Parameter ein. Die Anwort vom Radardatenverarbeitungssystem ist entweder positiv (die Änderung wurde akzeptiert) oder negativ, was bedeutet, daß der SSR-Code im Radar- datenverarbeitungssystem nicht verfügbar war.

Nach einer anderen Ausbildung sind mit dem erfindungsgemäßen System lokale SSR-Codes aus einem SSR-Code-Speicher unter Verwaltung abrufbar . Da das Flughafenkoordinationssystem die Eigenschaft hat, SSR-Codes aus einem lokalen Code-Vorrat zuzuweisen, müssen diese lokalen Codes für die nächste Verwendung freigegeben werden, sobald sie nicht mehr benötigt werden. Diese lokalen SSR-Codes werden für Flugpläne verwendet, die nicht von einem zentralen Koordinationsbüro verwaltet sind oder die keinen zentralisierten SSR-Code bekommen. Es ist die Aufgabe der Anwendung im Flughafenkoordinationssystem, diese lokalen SSR-Codes zu verwalten und zu garantieren, daß sie nicht zur gleichen Zeit zweimal benutzt werden. Deshalb ist es notwendig, daß das Radardatenverarbeitungssy- stem eine „Freigabe-Code"-Nachricht an das Flughafenkoordinationssystem übermittelt, wenn (nach einem timeout bzw. einer Fehlerwartezeit) ein SSR-Code im interessierenden Bereich des Radardatenverarbeitungssystems nicht mehr empfangen wird. Diese Nachricht wird vom Flughafenkoordinationssystem dahingehend interpretiert, daß der SSR-Code in dem vom Radardatenverarbeitungssystem abgedeckten Bereich nicht mehr in Gebrauch ist. Wenn der signalisierte SSR-Code aus dem lokalen Vorrat stammt, wird er für die weitere Verwendung freigege- ben . Also wird beim Ausbleiben von AntwortSignalen eine vorbestimmte Zeit abgewartet, bevor ein Fehlersignal ausgegeben wird.

Die Fehlerwartezeit innerhalb des Radardatenverarbeitungssy- stems ist notwendig, um zu gewährleisten, daß das Signal nicht nur wegen schlechter Radarbedingungen vorübergehend verlorengegangen ist. Im Flughafenkoordinationssystem ist eine spezielle Maßnahme dafür zu treffen, daß jeder verwendete, lokale SSR-Code erst nach einer Fehlerwartezeit freigegeben wird wegen einem möglichen Ausfall des Radardatenverarbeitungssystems .

Die Kommunikation zwischen verschiedenen Systemen basiert auf der Prozedur RPC (remote procedure call) . Das bedeutet, daß für jeden Dienst eine separate Prozedur auf dem RPC-Server abläuft, welche von einem RPC-Client aufgerufen wird. Der Datenaustausch auf RPC-Basis ergibt folgende Vorteile: Sichere Datenübertragung unter Verwendung der LAN-Kommunikation; die lokale Datendarstellung ist von der externen Datendarstellung unabhängig, RPC-Tools sind für die meisten Hardwareplattformen und Betriebssysteme verfügbar; die reale Systemverteilung ist gegenüber den Anwendungen verdeckt (was beispielsweise bedeutet, daß verschiedene Leit- und/oder Kontrollprogramme auf dem gleichen oder auf verschiedenen Systemen ohne Modifi- kation der Anwendung laufen können) ; Erweiterungen und Modifikationen an der Schnittstelle sind leicht in die existierenden Systeme zu integerieren.

Für die RPC-Kommunikation ist ein RPC-Server vorhanden, der einen wohldefinierten Dienst (Prozedur) zur Verfügung stellt. Dieser Dienst wird von einem RPC-Client aufgerufen. Die von der Prozedur benötigten Eingangsdaten werden vom Client zur Verfügung gestellt. Die Rückwerte der Prozedur werden vom Server zur Verfügung gestellt. Die Fehlerbehandlung (wenn beispielsweise kein Server für einen angeforderten Dienst existiert) wird von der unterlegten Software durchgeführt, welche entsprechende Werte übergibt .

Das Flughafenkoordinationssystem kann eine Fehlerüberwachung weiterer externer Systeme (z.B. Bodenleit- und/oder Docking- systeme) vornehmen, um Fehler zu erkennen. Fehler werden dabei hinsichtlich ihres Ursprungs in verschiedene Kategorien (1. Bis 3. Ordnung) eingeteilt.

Alle Fehler außer Fehler 1. Ordnung werden von dem Prozeß, der den Fehler erkennt, in die DB-Tabelle Fehlerliste eingetragen. Fehlermeldungen 1. Ordnung werden nicht in die Datenbank eingetragen. Durch einen entsprechenden Eintrag in die SignalQueueDB Trigger werden die Client-Arbeitsplätze 2 über die Fehler informiert . Über einen eigenen Menüeintrag kann die Liste aller anstehenden Felder 2. oder 3. Ordnung sowie der Überwachungen angezeigt werden.

Überwachungen werden ebenfalls in die Fehlerliste eingetragen und wie Fehler 3. Ordnung behandelt mit der Ausnahme, daß diese nicht aus der Fehlerliste gelöscht werden. Das bedeutet insbesondere, daß das Auftreten des Fehlers wie ein Fehler 3. Ordnung angezeigt wird. Das Löschen aus der Fehlerliste er- folgt durch den Überwachungsprozeß bei Wegfall der Fehlerbedingung. Um dem Bediener dies anzuzeigen, wird der Wegfall der Fehlerbedingung als Fehler 3. Ordnung behandelt. Sowohl das Eintragen als auch das Löschen einer Überwachung in der Fehlerliste wird automatisch auf dem Systemdrucker protokolliert. Um dem Bediener auch nach dem Quittieren einer Überwachung die Liste der aktuell vorliegenden Überwachungsmeldungen anzeigen zu können, steht im Management-Menü ein eigener Eintrag zur Verfügung, über den alle Einträge in der Fehler- liste vom Typ Überwachung aufgelistet werden.

Zu dem Problembereich Mensch-Maschine-Interface wird folgendes ausgeführt: Die Schnittstelle für Datenfluß und Kommunikation zum bzw. mit dem Bediener wird durch eine MS-Windows- Applikation gebildet. Diese Applikation verfügt über eine direkte Schnittstelle zur Flughafenkoordinationssystem-Datenbank und kann Daten, die vom Bediener eingegeben werden, auf dem Server ablegen. Da bei dem Flughafenkoordinationssystem mehrere Anwender gleichzeitig auf einer Datenbank arbeiten und insbesondere Daten ändern können, verfügt die Applikation über Mechanismen, über welche die angezeigten Daten automatisch aktuell gehalten werden können (SignalQueue) .

Um Bedienaktionen mit dem Flughafenkoordinationssystem- Arbeitsplatz durchführen zu können, muß der Benutzer sich in das System einloggen. Hierfür muß vor Beginn der Arbeit eine gültige Kombination Username/Password eingegeben werden.

Im ausgeloggten Zustand zeigt der Flughafenkoordinationssy- stem-Arbeitsplatz und hält diese aktuell. Das bedeutet, daß in diesem Zustand stets die aktuellen Einträge im FplInUse dargestellt werden und somit ein gültiges Abbild der Datenbankeinträge sichtbar ist. Eine Bedienung ist nicht möglich. Die einzige Aktion, die erlaubt ist, ist das Login. Es wird lediglich die Anzahl der noch nicht quittierten Fehler 3.

Ordnung/Überwachungen dargestellt, nicht jedoch der zugehörige Fehlertext. D.h., es werden keine Fehlerausgaben gemacht.

Die aktuell in Bearbeitung befindlichen Flugpläne werden in der Flughafenkoordinationssytem-Arbeitsplatzmaske (Abbildung in FIG 3) in sieben Listen dargestellt und an allen Client- Arbeitsplätzen 2 laufend aktuell gehalten. Die Listen erhalten einen Scrollbar, um Blättern zu ermöglichen.

Ein statisches Infofeld enthält allgemeine Informationen, die zum Teil aus der Datenbank (InfoTable, Fehlerliste) gelesen werden und zum Teil dynamisch (Uhrzeit, Anzahl nicht quittierter Fehler) erzeugt werden.

Ein Fluplan-Infofeld wird nur in bestimmten Situationen dargestellt und enthält alle Informationen über den aktuell ausgewählten Flugplan.

Ausgabefelder für Fehlermeldung: Fehlermeldungen 1. Ordnung werden in einem Popup-Window in der Mitte des Bildschirms eingeblendet. Diese müssen über einen OK-Button quittiert werden, bevor eine weitere Bearbeitung möglich ist. Alle anderen Fehlermeldungen werden in einem separaten Fenster (Popup) angezeigt, in dem der aufgetretene Fehler angezeigt wird. Das Fenster wird über den Bereich des statischen In- fofeldes gelegt. Zum Schließen des Fensters muß der OK-Button gedrückt werden, allerdings kann trotz eines solchen Fehlers weitergearbeitet werden. Das Anzeigen der anderen Fehlermel- düngen erfolgt abhängig von der lokalen Parametereinstellung.

In der Menüleiste werden 12 Funktionstasten dargestellt. Ihre Bedeutung ist entweder direkt einer Aktion zugeordnet oder es wird ein entsprechendes Auswahlmenü (Pull Down Menü oder Scrolled Liste) aufgeblendet. Bei einem Auswahlmenü ist die

Bedienung wie bei einem üblichen MS-Windows-Menü (Selektion invertiert, Defaultbelegung programmierbar, Auswahl über Hot

Key, Wegblenden über Mausaktion, insensitive Darstellung nicht auswählbarer Zustände) . In manchen Fällen kann auch ein mehrstufiges Menü erforderlich sein.

U.a. kann mit diesen Tasten die Art des Anflugs oder Abflugs (Instrumentennavigation, Sichtflug), eine zugeordnete Start- /Landebahn, usf. über Menüs ausgewählt werden.

Weiterhin kann ein Lotsenarbeitsplatz geschaffen werden, wobei über eine datenmäßige Verbindung zu den RadarSystemen des Flughafens eine integrierte Darstellung eines Radarbildes und von Informationen des Flughafenkoordinationssystems auf einem Monitor (synthetische Darstellung) möglich ist, damit den Fluglotsen jeweils sämtliche, notwendigen Informationen übersichtlich dargeboten werden. Auf diesem Monitor können ferner die weiter unten beschriebenen Übergabemeldungen eingeblendet werden, deren Einbindung bevorzugt von dem Flughafenkoordinationssystem mit übernommen wird.

In FIG 4 bezeichnet 11 das Flughafen-LAN (local area network) . 12 bezeichnet den Monitor eines Lotsenplatzes und 13 den Monitor sowie 14 den Drucker des Service- und Maintenan- cerechners . Der Monitor 12 ist entweder in herkömmlicher Monitortechnik oder als Flatpanel-Screen, insbesondere in Touchscreen-Ausführung, ausgebildet; 15 bezeichnet PLC's und 16 den BRITE-PC, der erfindungsgemäß in den ATC-Tower-Monitor integriert wird. Die zur Bedienung des BRITE-II-Systems notwendige Software befindet sich im BRITE-Master 18 und bewirkt in den BRITE-Einheiten 19 die gewünschten Schaltzustände, bspw. Befeuerung ein/aus. Die BRITE-Einheiten sind mit Sensoren 20 verbunden, die relativ beliebig ausgestaltet und über das gesamte Flugplatzgelände verteilt sein können. Wie dargestellt, befinden sich die BRITE-Einheiten in einem Serienkreis, um für alle Lampen-Einheiten gleiche Helligkeit sicherzustellen. Bei dieser Anordnung ist eine datenmäßige Ver- bindung zu den Radarsystemen des Flughafens nicht vorgesehen.

Es besteht jedoch die Möglichkeit zur Schaffung eines integrierten Controller-Arbeitsplatzes, vorteilhaft auf X-Windows und offener Architektur basierend. Hier kann aus dem Rohvideo (reales Darstellungsvideo) eine synthetische Darstellung zusammen mit Landkarten, Objektdaten, Konfliktmeldungen, Flugplandaten, Stopbar- und Befeuerungsdaten vorgenommen werden, in der auch die weiter unten beschriebenen Übergabemeldungen eingeblendet werden können.

Im Rahmen der Integration ist eine Sensorik vorgesehen, die eine Kombination von verschiedenen Sensoren darstellt, in erster Linie verschiedenen RadarSystemen. Die Sensordaten werden fusioniert, um eine nahtlose Überwachung zu gewährlei- sten.

Die Datenverarbeitung erfolgt über ein Multisensor-Tracking und Labelling mit einer Korrelation der Sensordaten mit Flugplandaten, Befeuerungs- und Docking/Gatebelegungsdaten. Auf dieser Basis erfolgt dann die Steuerung des Flughafenverkehrs, insbesondere des Bodenverkehrs auf Rollbahnen und Vorfeld.

In FIG 5 bezeichnet 21 einen Block mit Sensordaten zur Über- wachung, 22 bezeichnet die Vorgänge, die zur Überwachung dienen, 23 stellt den Bezug für den Controller, den Piloten etc. dar. 24 bezeichnet ein Hochgeschwindigkeitsdatennetzwerk (Airport LAN) , das als fehlerfreies, ausfallsicheres System ausgebildet ist. In dieses fließen auch noch die Informatio- nen aus dem Block 25, d.h. von peripheren Diensten ein. Seitens des Flughafenpersonals erfolgen die Kontrollen, die im Block 26 dargestellt sind, ebenso die hierfür notwendigen Eingaben. Block 27 schließlich bezeichnet die wesentlichen Systemkomponenten, die verwendet werden.

Ein Bodenradar bildet die Basis der verwendeten Sensorik. Das Sensorsystem übermittelt Daten über die Position, ggf. auch der Geschwindigkeit, der Richtung und der Identitätsnummer aller Flugzeuge und Fahrzeuge. Weiterhin gibt es auch Informationen über stationäre Objekte und ihre relative Lage zu den angezeigten Positionen von Flugzeugen und Fahrzeugen. Das Radarvideo wird ergänzt durch die Angaben von stationären Sensoren, was insbesondere für Gebiete mit Radarabschattung wichtig ist. Die Kombination aller vorgenannten Sensoren ergibt eine komplette Information über den Flughafenverkehr.

In FIG 6 bezeichnet 30 eine Start- und Landebahn und 31 Rollbahnen. Auf den Rollbahnen 31 befinden sich Stopbars 32 o.a. sowie weitere, aus Gründen der Vereinfachung nicht näher gezeigte Befeuerungs- und Hinweiseinrichtungen. FIG 6 zeigt ein ausgeführtes synthetisches Video in einfacher Form, das erfindungsgemäße Videobild kann detaillierter ausgebildet sein. 33 bezeichnet eine Fensterdarstellung des Flugplans, 34, 35 und 36 sowie 37 bezeichnen weitere Flugplan- und Zuordnungsfenster, bspw. auch Fenster mit Übergabemeldungen. Es versteht sich, daß auf einem großen Flachbildschirm diese und weitere Angaben in ausreichender Größe und in übersichtlicher Anordnung dargestellt werden können. Ein Flachbildschirm emp- fiehlt sich, um z.B. eine niedrige Gebrauchshöhe zu erreichen und den Einbau anderer Systeme zu ermöglichen bzw. Platz für andere Systeme zu schaffen. In FIG 7 sind bei 40 die wesentlichen Einzelheiten aufgeführt, die das synthetische Video enthält. 41 zeigt die beiden Arten von Sensoren, die auf unterschiedlichster Basis arbeiten können. Am wichtigsten sind die kooperativ arbeitenden Sensoren, die gleichzeitig die Flugzeugidentifikation verifizieren. 42 zeigt die Grundzüge des Verkehrslenkungsystems , 43 die Hilfsfunktionen, die insbesondere bei besonderen Vorfällen wichtig werden. In 44 sind die Komponenten angegeben, mit denen die aktuelle Führung der Flugzeuge auf der Start- und Landebahn 30 und den Rollbahnen 31 sowie im Vorfeldbereich erfolgt, und bei 46 die Dockingautomatisierung, die mit den verschiedensten Sensoren, (Laser, Zeilenkameras, Mikrowellenempfänger, D-GPS etc.) erfolgen kann, jedoch bevorzugt mit einer Grauwertkamera vorgenommen wird. In 45 ist schließlich die Verkopplung und/oder Integration der unterschiedlichsten Daten, die in dem System zusammenfließen, angedeutet.

Es versteht sich, daß von dem erfindungsgemäßen System auch Gebrauch gemacht wird, wenn nicht alle der hier beschriebenen einzelnen Komponenten im System integriert sind, sondern als Stand-alone-System betrieben werden, oder wenn auf einzelne Komponenten, etwa automatische Dockingsysteme, z.B. auf kleineren Flughäfen mit nur wenigen Parkpositionen, ganz verzichtet wird.

Ein wie in FIG 8 prinzipiell gezeigt in ein Flughafennetzwerk

51 einbezogenes Flughafenterminal 52 ist mit einem Dockingsystem ausgerüstet, mittels dem über eine Brücke eine Verbindung mit dem Innenraum eines Flugzeugs 53 herstellbar ist.

Um das Flugzeug 53 für den Andockvorgang am Flughafenterminal

52 korrekt zu positionieren, sind allen Gates 54 des Flughafenterminals 52 jeweils Positioniervorrichtungen zugeordnet, mittels der das zur Andockung vorgesehene Flugzeug 53 in eine für seinen Bautyp vorgegebene Stop- bzw. Parkposition 55 leitbar ist.

Hierzu hat die Positioniervorrichtung eine als Graubildkamera ausgebildete Videoeinrichtung 56, mittels der das Flugzeug 53 bei seiner Annäherung an das Gate 54 des Flughafenterminals

52 erfaßbar ist, eine Auswerteeinheit 57, mittels der ihr von der Videoeinrichtung 56 zugeführte, die Gestalt und die Bewegung des Flugzeugs 53 betreffende Daten auswertbar sind, und ein Anzeigedisplay 58, mittels dem einem Piloten des Flugzeugs 53 Informationen vermittelbar sind, die zum Fahren des Flugzeugs 53 in die vorgegebene Parkposition 55 wesentlich sind.

Da die Parkposition 55 je nach Bautyp des sich nähernden

Flugzeugs 53 unterschiedlich ist, muß seitens der Positioniervorrichtung zunächst ermittelt werden, um welchen Bautyp es sich bei dem sich annähernden Flugzeug 53 handelt. Hierfür werden durch die Videoeinrichtung 56 Grauwertbilder erstellt, auf denen sich das dem Gate 54 annähernde Flugzeug 53 abgebildet ist. Mittels der Videoeinrichtung 56 wird eine Sequenz von Grauwertbildern, auf denen das sich an das Gate 54 annähernde Flugzeug 53 in unterschiedlichen Positionen dargestellt ist, in die Auswerteeinheit 57 eingelesen. Durch Aus- wertung dieser Sequenz von Grauwertbildern innerhalb der Aus- werteeinheit können sich bewegende Kanten erfaßt werden, welche dem Umriß des sich an das Gate 54 annähernden Flugzeugs

53 entsprechen. Hierzu dient zunächst eine Raumfilterung, mittels der räumlichen Kanten in den einzelnen Grauwertbil- dern aufgefunden werden. Mittels der Zeitfilterung werden zeitlich bewegte Kanten extrahiert, so daß bewegte von unbewegten Gegenständen unterschieden werden können. Hierdurch ist es erleichtert, aus den Grauwertbildern einen Flugzeugumriß zu ermitteln. Jeder Bautyp von Flugzeugen hat einen be- stimmten Flugzeugumriß, der seinerseits markante Umrißabschnitte bzw. Schablonenbilder, sogenannte Templates aufweist, wobei sich durch die Auswahl geeigneter Templates ein Template-Satz bilden läßt, der für die jeweiligen Bautypen von Flugzeugen exemplarisch ist. Dieser Template-Satz kann drei oder vorzugsweise fünf einzelne Templates enthalten.

Für jeden Bautyp von Flugzeugen ist innerhalb der Auswerteeinheit 57 ein Template-Satz abgespeichert. Die für das sich an das Gate 54 annähernde Flugzeug 53 ermittelte Flugzeugkontur bzw. der daraus sich ergebende Template-Satz wird nunmehr mit den innerhalb der Auswerteeinheit abgespeicherten Template-Sätzen verglichen, wobei als Ergebnis dieser Verleichsope- ration der Bautyp des sich dem Gate 54 des Flughafenterminals 52 annähernden Flugzeugs 53 ermittelt wird. Diesem Bautyp ist eine spezielle Parkposition 55 zugeordnet. Auf dem Anzeigedisplay 58 werden nunmehr Angaben abgebildet, die den Flugzeugführer bzw. Piloten in die Lage versetzten, sein Flugzeug 53 in diese Parkposition 55 zu stellen.

Mittels des in FIG 10 prinzipiell dargestellten Verfahrens erfolgt die Positionierung der Flugzeugkontur. Hierbei wird vorausgesetzt, daß das sich dem Gate 54 des Flughafenterminals 52 nähernde Flugzeug 53 spätestens bei einem vorgegebe- nen Mindestabstand zur Parkposition im Bereich des Gates 54 eingebogen ist und sich der Flugzeugführer bzw. Pilot hierbei ungefähr an der Zentrallinie dieses Gate 54 orientiert. Hierfür wird eine Fangposition auf dieser Zentrallinie definiert. Um diese Fangposition wird ein Suchbereich definiert, in dem die die Flugzeugkontur bzw. den Flugzeugtyp festgelegten

Merkmale gesucht werden. Wie groß dieser Fangbereich zu definieren ist, hängt von der tolerierten lateralen Abweichung des sich dem Gate 54 nähernden Flugzeugs 53 ab. Die den Template-Satz eines Flugzeugtyps bildenden einzelnen

Templates müssen so ausgewählt werden, daß sie nicht invariant gegenüber Verschiebungen sind und ferner einen hohen Kontrast in der Sequenz von Grauwertbildern aufweisen. Außerdem müssen die ausgewählten Merkmale bzw. Templates eine hohe Toleranz gegenüber äußeren Einflüssen, wie z.B. Beleuchtung und Witterung, aufweisen. Daher wurden für die bisher in Form von Template-Sätzen aufgenommenen Flugzeutypen folgende Merkmale bzw. einzelne Template ausgewählt:

Die beiden Triebwerke, das Windshield und die zwei Fahrwerke. Für jeden Flugzeugtyp wird mittels dieser einzelnen Templates ein individueller Template-Satz erstellt.

Um die im Vorfeld definierte Position wird das Flugzeug 53 nun gesucht. Da es sich beim Flugzeug 53 um einen starren Körper handelt, kann eine feste Anordnung der ausgesuchten Merkmale vorgegeben werden, die nur durch die Lage des Flugzeugs 53 zur Videoeinrichtung 56 verzerrt erscheinen können.

Aus dem in FIG 11 dargestellten Datenflußdiagramm geht hervor, wie einzelne Funktionskomponenten des erfindungsgemäßen Dockingsystems mit anderen Funktionskomponenten desselben sowie mit außerhalb des eigentlichen Dockingsystems vorliegen- den weiteren Funktionskomponenten einer Flughafensteuerung kommunizieren. Da viele in den Figuren aufgeführten Begriffe sinnvoll lediglich englischsprachig ausdrückbar sind, wird auf eine Übersetzung einzelner in den im folgenden beschriebenen Figuren aufretender Begriffe verzichtet, wobei jedoch die wesentlichen Komponenten der Erfindung im folgenden Text deutschsprachig ausgedrückt und mit den englischsprachigen Ausdrücken bzw. Abkürzungen in Zusammenhang gebracht sind. In FIG 11 ist eine zentrale Steuereinrichtung (Central Wor- king Position, CWP) eines Flughafens dargestellt, die an das erfindungsgemäße Dockingsystem angeschlossen ist und ihrerseits über ein zentrales Beobachtungs- und überwachungssyste- minterface (Central Monitoring and Surveillance Systeminterface, CMSI) und ein Anwenderinterface (User Defined Interface, UDI) in die Steueranlage des Flughafens einbezogen ist.

Das erfindungsgemäße Dockingsystem gliedert sich bei der DarStellung in FIG 11 in mehrere Funktionseinheiten. Zunächst ist dort eine Funktionseinheit aus Daten- und Statusweiterleitung (Docking Status/Data Handler, DSH) und Calibrierhilfe (Calibration Support, CS) vorgesehen. Diese Funktionseinheit erhält von der CWP zentrale Steuerungssignale (central con- trol) , Datenbasisaktualisierungen (database Updates) sowie das jeweilige Gate betreffende Beobachtungs- und Überwachungsdaten (gate i CMS data) Die CWP erhält von dieser Funktionseinheit DSH, CS Statusangaben bezüglich des jeweiligen Gates (gate i statuses) , Livevideosignale von diesem Gate (gate i live video) und dieses Gate betreffende zentrale Beobachtungs- und Überwachungsdaten (gate i CMS data) .

Das erfindungsgemäße Dockingsystem DGS hat, wie sich aus FIG 12 ergibt, im Prinzip drei Teilbetriebssysteme, nämlich eine Dockingeinheit (Docking Station Subsystem, DSS) , eine zentrale Steuereinrichtung (Controller Working Position Subsystem, CWPS) und ein Kommunikationsnetzwerk (Communication Network Subsystem: CNWS) . Die DSS enthält alle diejenigen Systemsegmente, die an den Gates angeordnet sind. Die CWPS besteht aus einem auf einer Workstation basierenden Display- und Steuersystem, das in einem zentralen Kontrollraum des Flughafens vorgesehen ist. Das CNWS ist das Netzwerk, das diese beiden Untereinheiten miteinander verbindet, um Daten zwischen diesen Untereinheiten zu übermitteln. Die DSS steht mit der Flugfeldsituation (Airfeld Situation) einerseits sowie mit Wartungspersonal (Maintainer) , Kalibrierpersonal (Calibrator) , Brückenpersonal (Bridge Person- nel) , Bodenpersonal (Ground Personnel) , (Co-) Piloten und der Flugfeldbeleuchtung (Airfield Ground Lighting, AGL) andererseits in Verbindung. Über die Schnittstelle AuxS kann die Gateausgestaltung (Gate Specifier) , Installationspersonal

(Installation Personnel) und die Entwicklungsabteilung

(Reasearch) mit der DSS in Verbindung treten.

Die CWPS des Dockingsystems ist einerseits in Verbindung mit der Verwaltung (Administrator) , der Wartung (Maintainer) , der Überwachung (Supervisor) und der Aufsicht (Controller) ; andererseits besteht eine Verbindung zum zentralen Beobachtungs- und UberwachungsSystem (Central Monitoring and Surveillance System) , zur Flughafendatenzentrale (Airport Database) , zu benutzerdefinerten Gatesystemen (User Defined Gate Systems) , zur Befeuerung (Airfield Ground Lighting, AGL) , zu Zeitbezugssystemen (Time Reference Systems) und zu einem Oberflä- chenbewegungsleit- und -Steuersystem (Surface Movement Guidance and Control System, SMGCS) . Die CWPS kann (zu verkehrsarmen Zeiten) mit anderen Systemen (bspw. TECOS und/oder einem Bodenleitsystem) auf demselben Monitor betrieben werden.

Die DSS hat vier unterschiedliche Segmente: Das Flugfeldsituationsüberwachungs- und verarbeitungssegment (Airfield Situation Monitoring and Processing Segment, ASMPS) ; das Informations- und Leitanzeigesegment (Advisor and Guidance Display Segment, AGDS) ; falls zwei voneinander abhängige Zentraloder Mittellinien vorliegen, kann, je nach Konfiguration bzw. Anordnung der Zentral- oder Mittelllinien am Gate, ein zweites AGDS erforderlich sein. Das AGDS beinhaltet einen integrierten Mikroprozessor, der die Anzeigeelemente steuert und Anzeigebefehle in -Anzeigen umformt; das Daten- und Statusweiterleitungssegment (Data and Status Handler Segment, DSHS) mit einer oder zwei Videokameras je Zentral- oder Mittelinie; die Anzahl der Videokameras je Zentral- bzw. Mittelinie hängt davon ab, welche Flugzeugtypen an dem jeweiligen Gate andok- ken dürfen; das DSHS läuft auf derselben Hardware wie das ASMPS . Es bewerkstelligt die Kommunikation zwischen der DSS und der CWPS über das CNWS und koordiniert die Vorgänge innerhalb der DSS; das Gatebetriebssteuerungssegment (Gate Ope- rator Panel Segment, GOPS) ist ein mikroprozessorbasiertes

System mit einer kleinen Tastatur und einem Flüssigkristalldisplay LCD, das ausschließlich die Eingabedaten zum DSHS überträgt und die Daten vom DSHS am LCD ausgibt .

Als Interface zwischen dem DSHS und den GOPS 1 bis 4 oder dem AGDS 2 können Schnittstellen des Typs RS 232, RS 422, RS 485 oder auf optischen Verbindungen basierende Schnittstellen eingesetzt werden. Als Interface zwischen dem DSHS und dem AGDS kann eine Schnittstelle vom Typ RS 232 eingesetzt wer- den .

Das CNWS kann als ATM-Netzwerk verwirklicht sein, bei dem zumindest eine Schalteinheit realisiert werden kann. Zur Si- gnalgebung sollte ein UNI 3.1 oder UNI 4.0 verwendet werden. Abhängig von den Bandweitenanforderungen können 155 Mbit/s- oder 25 Mbit/s-Adapter verwendet werden. Die erreichbaren Distanzen hängen vom Transportmedium ab: Monomodefaser für mittlere Distanzen oder verdrillte Doppelleitung für kurze Distanzen.

Die Vorteile eines solchen Hochgeschwindigkeits-ATM-Netzwerks liegen darin, daß große Distanzen möglich sind, keine elektromagnetischen Störungen auftreten, eine galvanische Isolierung vorliegt, eine garantierte Bandbreite zwischen zwei Da- tenendstellen und "eine garantierte Verzögerung zwischen zwei

Datenendstellen gewährleistet sind.

Das CWPS kann auf einem PC-System mit dem Windows NT-Be- triebssystem laufen. Darüber hinaus werden als Hardware- Komponenten vorzugsweise ein Video-HW-ProVisionBusiness und ein ATM-Adapter ATMax 155-PM2 der SICAN GmbH eingesetzt.

Das CNWS sorgt für die Kommunikation zwischen dem CWPS und den DSS an den unterschiedlichen Gates und umgekehrt. Es überträgt Befehle, Daten und komprimierte Videobilder; die letzteren werden nur auf spezielle Anforderung übertragen.

Soll im Rahmen der vorliegenden Erfindung eine Arbeitsplat- zumleitung des CWPS für verkehrsarme Zeiten möglich sein, so ist auch die Kopplung zu den (umgeleiteten) Arbeitsplätzen und/oder an ein Netzwerk derselben nach den obigen Schnitt- stellenparamtern auszulegen.

Die Hauptaufgaben des CWPS sind: Anzeige der geplanten und tatsächlichen Gatebelegung, Anzeige des Status eines Andockvorgangs für das Personal der Zentrale, Eingabe von Gateausgestaltungen eines speziellen Gate, Eingabe neuer Flugzeugmuster, Datenaustausch mit umgebenden Systemen, z.B. Wartung, Flugplandaten, geplante Gatebelegungen. Zu jeder Zeit kann die geplante und die tatsächliche Belegung von Gates graphisch dargestellt werden. Das globale Bild kann in mehrere kleine Bereiche aufgeteilt werden. Eine Tafel aller besetzten Gates mit den zugehörigen Aufrufzeichen ist dargestellt. Das Zentralpersonal kann ein spezielles Gate und eine Livevideo-

Übertragung wählen. Die geplanten Daten sind in einem speziellen Blockdiagramm dargestellt. Die geplante Belegung kann bei Bedarf geändert bzw. modifiziert werden. Das CWPS sorgt dafür, daß eine Änderung Gaterestriktionen nicht verletzt, daß beispielsweise Flugzeugtypen nicht einem Gate zugeteilt werden, welches für derartige Flugzeugtypen nicht geeignet ist. An den Monitoren des CWPS können auch die weiter unten beschriebenen Übergabemeldungen eingeblendet werden.

Wie im Rahmen der Figuren 1 bis 12 bereits erläutert, verfügen die verschiedenen Bereiche eines Flughafenkontroll- und - leitsystems - Flugsicherungssystem, bspw. TECOS, Bodenleitsystem GMCS sowie Andocksystem DS - über verschiedene Schnitt- stellen zum Anschluß an weitere Flughafenabteilungen, insbesondere Radarstation, Wartung, Verwaltung, usf. Erfindungsgemäß ist vorgesehen, die Leit- und Kontrollsysteme untereinander, bspw. über vorhandene Anschlußmöglichkeiten, miteinander zu verknüpfen, so daß sich etwa eine Anordnung gemäß den Fi- guren 13 und 14 ergibt. Hierbei ist es einerseits möglich, an Flughäfen mit bereits bestehenden, getrennten Fluglotsen- und Bodenkontroll- sowie Dockingstationen diese über eigene Leitungen miteinander zu vernetzen, oder aber ein bereits bestehendes, flughafeninternes Datennetz zu verwenden oder gar beim Aufbau neuer Anlagen die verschiedenen Systeme oder Teile derselben im Rahmen einer einzigen Client-Server-Applikation miteinander zu verknüpfen.

Unabhängig von der konkreten Realisierung ist jedoch wichtig, daß verschiedene Informationen und/oder Daten über Flugzeugbewegungen, insbesondere Positions- und Bewegungsdaten sowie Kontrollnummern etc. von den einzelnen Systemen in möglichst einheitlichem Format verwendet werden, um bei Übergabe der Weisungsbefugnis und Verantwortung von einem System zu einem anderen auch die jeweils aktuellen Daten eines Flugzeugs weitergeben zu können.

Erfindungsgemäß existieren insbesondere Kommunikationsmöglichkeiten zwischen dem Flugsicherungssystem und dem Boden- leitsystem GMCS einerseits und zwischen dem Bodenleitsystem

GMCS und einer oder mehreren Dockingstationen DS andererseits, und zwar vorzugsweise in jeweils bidirektionalen Richtungen, da die Weisungsbefugnis und Verantwortung bei der An- kunft eines Flugzeuges 53 hinsichtlich der Flugplatzstruktur hierarchisch abwärts weitergegeben wird, während bei dem Start eines Flugzeuges 53 die entsprechenden Befugnisse in umgekehrter Richtung übertragen werden müssen.

Erfindungsgemäß läuft die Übergabe der Weisungsbefugnis und Verantwortung nach einer Art Handshake ab: Sobald ein Flugzeug 53 den überwachten Bereich eines Systems erreicht und im Begriff ist, diesen zu verlassen, fragt der entsprechende Operator - Fluglotse, Bodenkontrolleur oder Dockingkoordina- tor - bei der jeweils nachfolgend zuständigen Systemstation an 60. Sobald der dortige Bedienstete diese Anfrage registriert hat und zur Übernahme der Weisungsbefugnis und Ver- wantwortung bereit ist, bestätigt 61 er die Anfrage 60, und sobald dies geschehen ist, werden die aktuellen Daten dieses Flugzeugs an den Bildschirm des nun zuständigen Bediensteten übertragen 62, sofern diese dort nicht bereits durch eigene Sensoren, bspw. ein Bodenradar, oder durch eine routinemäßige Abfrage zentral gespeicherter Flugzeugdaten vorhanden sind. Gleichzeitig erlöschen die Daten auf dem Bildschirm des bis- her zuständigen Bediensteten.

Die Kommunikation zwischen den einzelnen Systemen - Anfrage 60 und Bestätigung 61 - kann mittels Schalter, Taster, Si- gnallämpchen oder sonstiger Signaleinrichtungen bewerkstel- ligt werden, bevorzugt erfolgt diese Handover-Sequenz jedoch von Bildschirm zu Bildschirm, d.h. , durch eine spezielle Funktions-, Steuer- oder Menütaste, durch einen Mausklick oder durch Berührung eines Touchscreens wird die entsprechende Mitteilung - Anfrage oder Bestätigung - abgesendet und auf dem empfangenden Bildschirm an einem hierfür vorgesehenen Ort oder Fenster sichtbar gemacht.

Die Übergabe zwischen den einzelnen Systemen findet dann statt, wenn ein betreffendes Flugzeug die Grenze zwischen den Einflußbereichen der unterschiedlichen Systeme überschreitet. Die betreffende Grenze zwischen dem Flugsicherungssystem und dem Bodenleitsystem ist bei einer Landung mit dem Verlassen des Luftraums, also dem Aufsetzen auf der Landebahn gleichzu- setzen, ggf auch mit dem Erreichen einer normalen Fahrgeschwindigkeit, bei einem Start dagegen mit dem Erreichen einer Startposition an einem Ausgangspunkt der Startbahn.

Der Einflußbereich der Dockingstationen beginnt in einem Ab- stand von etwa 50 bis 100 m vor dem betreffenden Gate. Die zwischen diesen beiden Grenzen liegenden Bereiche - Vorfeld und Rollbahnen - unterliegen der Weisungsbefugnis der Bodenleitstation. Da das Übergabekriterium in den meisten Fällen durch die Position des Flugzeugs, ggf auch durch dessen Ge- schwindigkeit gebildet wird, ist die ständige Erfassung der Flugzeugpositionen für die erfindungsgemäße Systemverkoppelung besonders wichtig. Hierbei kann die Positionsbestimmung einerseits durch einen Bodenradar erfolgen, andererseits auch durch im Bereich des Flugplatzes verteilte Sensoren wie Druckdosen, Induktionsschleifen, Lichtschranken, Infrarotsensoren, Mikrowellensensoren, wie sie im Rahmen des Bodenleitsystems zumeist an einen gemeinsamen Schaltkreis angeschlossen sind, und darüber hinaus auch durch Videokameras, wie sie im Rahmen der oben beschriebenen Dockingssysteme verwendet werden. All diese Informationen können zu einer lückenlosen oder gar redundanten Positionsinformation verarbeitet werden.

Die Geschwindigkeit des Flugzeugs wie auch die Unterscheidung zwischen Roll- und Flugphase kann vorzugsweise von in dem Flugzeug integrierten Meßgeräten über Transponder an die

Flugplatzeinrichtung übertragen werden oder aber durch zeitliche Differenzierung eines Positionssignals gewonnen werden, das von einer Radarinformation und/oder von verschiedenen Po- sitionssensoren abgeleitet werden kann.

Schließlich ist es auch möglich, daß das Erreichen von Übergabekriterien hinsichtlich Position, Geschwindigkeit, usf. an einem Monitor als ein besonders Signal angezeigt wird, damit das Personal auf die bevorstehende Übergabe aufmerksam gemacht wird.

In Phasen mit geringem Flugaufkommen, bspw. von Mitternacht bis zum Tagesanbruch, ist es möglich, die verschiedenen Leit- und Kontrollsysteme von einem einzigen Arbeitsplatz aus zu steuern. Zu diesem Zweck kann die Bildschirmausgabe aller Systeme auf einem einzigen Monitor erfolgen, wobei die Übergabesequenz mit einem Wechsel der Bildschirmdarstellung von einem System in das andere gleichgesetzt werden kann. Um hier- bei unvorhergesehen eintretende Ereignisse sofort weiterzu- melden, kann vorgesehen sein, daß von im Hintergrund laufenden (Programm- ) Systemen bei Bedarf Alarm- oder sonstige Meldungen erzeugt und auf dem Bildschirm ausgegeben werden. Auch ist es möglich, die jeweils nicht angewählten Systeme im Rah- men eines verkleinerten Fensters einzublenden und hierdurch besondere Ereignisse sichtbar zu machen.

Nimmt nach Tagesanbruch der Flugverkehr wieder zu, werden weitere Stationen personell besetzt und die Verantwortung zwischen den einzelnen Systembereichen wieder aufgetrennt.

Claims

Patentansprüche

1. System zur Koordination der Kontrolltätigkeit des Flugsicherungspersonals, der Leitstelle für den Bodenverkehr sowie der Abfertigung von Flugzeugen an vorgegebenen Dockingstatio- nen, g e k e n n z e i c h n e t d u r c h a) ein System (TECOS) für die Kontrolle der im Luftraum sowie ggf. auf den Start- und Landebahnen befindlichen Flugzeuge, das auf Flugplandaten sowie aktuellen An-, Abflug- und/oder Radarinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; b) ein System (GMCS) für die Leitung der auf dem Boden verkehrenden Flug- und/oder Fahrzeuge, das auf Flugplatzdaten sowie aktuellen Positions-, Bewegungs- und/oder Radarinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; c) ein System (DS) für die Einweisung sowie ggf. Abfertigung der andockenden Flugzeuge, das auf Flugzeugdaten sowie ak- tuellen Bewegungs-, Richtungs-, Sensor- und/oder Videoinformationen basiert und diese Daten und/oder Informationen auf einem Monitor darstellend ausgebildet ist; d) ein oder mehrere Systeme für die Änderung der Zuordnung der Kontroll-/Leitungs-/Einweisungsverantwortung eines Flugzeugs zu einem der Systeme a) bis c) , das ein oder mehrere, im Bereich der Darstellungsorte der aktuellen Daten und/oder Informationen angeordnete Eingabemöglichkeit (en) für ein Aufforderungssignal zur Zuordnungsänderung (60) aufweist und ein derartiges Signal zu dem be- treffenden System a) bis c) weitermeldet.

2. System nach Anspruch 1, d a d u r c h g e k e n n -z e i c h n e t , daß das/die Syste (e) für die Zuordnungsänderung Möglichkeiten zur Rückmeldung eines Bestätigungsignals (61) hinsichtlich 'der Übernahme der Kontroll-/Leitungs-/Ein- weisungsverantwortung eines Flugzeugs aufweist.

3. System nach einem der vorhergehenden Ansprüche, g e - k e n n z e i c h n e t d u r c h eine Kopplung zwischen den Systemen a) bis c) für den Austausch aktueller Informationen (62), insbesondere von Flugzustands-, Positions-, Bewegungs-, Richtungs-, Radar- und/oder Videoinformationen, zwischen den Systemen a) bis c) , insbesondere bei einer Zu- Ordnungsänderung.

4. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß die Systeme a) bis c) jeweils eigene Monitore zur Informationsdarstellung aufweisen.

5. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß die Informationsdarstellung zweier oder aller Systeme a) bis c) zumin- dest zeitweise, insbesondere während Phasen mit niedriger

Verkehrsdichte, auf dem selben Monitor erfolgt.

6. System nach einem der vorhergehenden Ansprüche mit Darstellung der für die Kontrolltätigkeit des Flugsicherungsper- sonals erforderlichen Daten unter Einbeziehung von Flugplandaten zur Abwicklung der aktuellen Landungen, Starts und Durchflüge sowie aller Flugbewegungen auf zumindest einem Monitor, wobei das System in Client-Server-Technik ausgebildet ist und wobei Server (1) und Client-Arbeitsplätze (2) durch LAN (Local Area Network) oder WAN (Wide Area Network) miteinander verbunden sind, d a d u r c h g e k e n n z e i c hn e t , daß es als mehrschichtiges System mit graphischer Oberfläche aufgebaut ist, wobei einem Grundsystem, das auf Flugplandaten sowie aktuellen An- und Abflug- sowie Radarin- formationen basiert, eine objektorientierte relational arbei tende Datenbank zugeordnet ist, die uhrzeitbezogene Detail- Daten auf einem Monitor ausgebend ausgebildet ist.

7. System nach Anspruch 6, d a d u r c h g e k e n n z e i c h n e t , daß auf den Client-Arbeitsplätzen (2) Prozeßabläufe mit einem Steuerungs- und Controlling-Interface, einschließlich grafischer Bedienoberflächen sowie ein Eventhandler, uhrzeitbezogen ablaufend, angeordnet sind.

8. System nach Anspruch 7, d a d u r c h g e k e n n z e i c h n e t , daß auf dem Server (1) ein Dispatcher- Prozeß ablauffähig ist, mit dem die Daten bei Bedarf an die externen Schnittstellen verteilt werden können, z.B. zu einer Leitstelle für den Bodenverkehr, zum Radarsystem oder zum Flughafenabrechnungssystem.

9. System nach Anspruch 6, 7, oder 8, d a d u r c h g e k e n n z e i c h n e t , daß es einen Client-Writer-Prozeß durchführend ausgebildet ist, mit dem der asynchrone Zugriff mehrerer Client-Arbeitsplätze (2) auf die Datenbanken des Servers (1) realisiert und überwacht wird.

10. System nach einem oder mehreren der vorhergehenden An- sprüche, d a d u r c h g e k e n n z e i c h n e t , daß die Synchronisation und der Datenaustausch mit Hilfe einer Signalschlange vorgenommen werden, wobei diese bei den Client-Applikationen zyklisch abfragbar sind und die bei Änderungen an einem Flugplan die Anzeige und den Dateninhalt aktualisierend ausgebildet sind.

11. System nach Anspruch 10, d a d u r c h g e k e n n z e i c h n e t , daß es die Flugplandatenverteilung und die aktualisierte "Anzeige auf der Anwenderoberfläche der Client-Arbeitsplätze (2) automatisch ausgebend ausgebildet ist.

12. System nach einem oder mehreren der vorhergehenden An- sprüche, d a d u r c h g e k e n n z e i c h n e t , daß in ihm alle Flugpläne eines Flughafens gespeichert (RPL- Repetitive Flightplan) sind, die zyklisch (täglich, wöchentlichen, wöchentlich an bestimmten Tagen) durchgeführt werden.

13. System nach Anspruch 12, d a d u r c h g e k e n n z e i c h n e t , daß in den zu bearbeitenden und anzeigbaren Flugplänen Einzeldaten wie z.B. vorgesehene Landezeit, vorgesehene Andockzeit, vorgesehene Abflugzeit etc. mit ihren Einzelheiten zu jedem Zeitpunkt einfügbar sind.

14. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß Flugpläne und Flugplanfolgemeldungen, die von anderen Systemen gesendet werden (AFTN, übergeordnetes FDPS) , verar- beitbar sind, und daß für den Flugverlauf relevante Daten, die während der Flugplanbearbeitung eingegeben werden oder als Folge des Datenflusses entstehen (z.B. ATA, ATD, etc.) an angeschlossene Flugsicherungssysteme zur Weiterverarbeitung sendbar sind.

15. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß Flugpläne oder flugplanorientierte Koordinationsmeldungen nach dem Standard AFTN (Aeronautical Fixed Telecommunication Network) emfpangbar und sendbar sind.

16. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß Flugpläne oder flugplanorientierte Koordinationsmeldungen nach dem Standard CIDIN (Common ICAO Data Interchange Network) empfangbar und sendbar sind.

17. System nach einem oder mehreren der vorhergehenden An- sprüche, d a d u r c h g e k e n n z e i c h n e t , daß flugplanorientierte Koordinationsmeldungen (z.B. Startzeit, Landezeit, SLOTs etc.) nach dem OLDI-Standard o.a. empfangbar und sendbar sind.

18. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß flugzeugspezifische Leistungsdaten in einer Datenbanktabelle speicherbar und im System abrufbar sind.

19. System nach einem der vorhergehenden Ansprüche, mit Darstellung der für die Kontrolltätigkeit des Flugsicherungspersonals erforderlichen Daten unter Einbeziehung von Flugdaten zur Abwicklung der aktuellen Landungen, Starts und Durchflüge sowie aller Flugbewegungen auf zumindest einem Monitor, wobei das System in Client-Server-Technik ausgebildet ist und wobei Server (1) und Client-Arbeitsplätze (2) durch ein LAN (Local Area Network) oder WAN (Wide Area Network) miteinander verbunden sind, d a d u r c h g e k e n n z e i c h n e t , daß es zum Datenaustausch zu einem System zur Wirtschaftsfüh- rung, wie Abrechnung, Verwaltung oder Planung von Flugzeugbewegungen und gegebenenfalls Versorgungen, auf Flughäfen geeignet ausgebildet ist.

20. System nach Anspruch 19, d a d u r c h g e k e n n - z e i c h n e t , daß es mit einer Eintragung einer „Actual Time of Arrival"-Zeit arbeitend ausgebildet ist.

21. System nach Anspruch 19 oder 20, d a d u r c h g e k e n n z e i c h n e t , daß es mit einer Eintragung einer „Touch and Go"-Zeit arbeitend ausgebildet ist.

22. System nach einem der Ansprüche 19 bis 21, d a d u r c h g e k e n n z e i c h n e t , daß es mit einer Eintragung einer „Start up Given"-Zeit arbeitend ausgebildet ist.

23. System nach einem der Ansprüche 19 bis 22, d a d u r c h g e k e n n z e i c h n e t , daß es mit einer „Actual Time of Depature"-Zeit arbeitend ausgebildet ist.

24. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß die Kommunikationsschnittstellen nach dem RPC-Verfahren (Remote Procedure Call) arbeitend ausgebildet sind.

25. System nach einem der vorhergehenden Ansprüche, mit Darstellung der für die Kontrolltätigkeit des Flugsicherheits- personal erforderlichen Daten unter Einbeziehung von Flugplandaten zur Abwicklung der aktuellen Landungen, Starts und Durchflüge sowie aller Flugbewegungen auf zumindest einem Monitor, wobei das System in Client-Server-Technik ausgebildet ist, und wobei Server (1) und Client-Arbeitsplätze (2) durch ein LAN (Local Area Network) oder WAN (Wide Area Network) miteinander verbunden sind, d a d u r c h g e k e n n z e i c h n e t , daß es die Koordination des ankommenden und des abgehenden Verkehrs ermöglichend ausgebildet ist, wobei Informationen von externen Systemen bereitgestellt wer- den, insbesondere die Daten von zumindest einem Radardatenverarbeitungssystem, das vorzugsweise über ein LAN/WAN verbunden ist und wobei zwischen Server (1) und der Radardatenverarbeitung Rufsignale in Form des SSR-Codes übermittelbar sind.

26. System nach einem der vorhergehenden Ansprüche, mit einem

Flughafen-Bodenverkehrs-Leitsystem (Ground Movement Control System, GMCS) mit Erfassung, integrierter Verarbeitung und bildlicher Darstellung der relevanten, insbesondere der si- cherheitsrelevanten, Positionen und Bewegungen von Flugzeugen und gegebenenfalls Fahrzeugen auf dem Flughafengelände (Start- und Landebahn, Rollbahnen, Vorfeld) und im relevanten Flughafenluftraum (CTR) von der Erfassung durch zumindest ein Radar zwischen Flugbewegung und Stillstand in Parkpositonen, wobei die relevanten Daten unter Datenkonzentration auf einen Monitor zumindest eines Lotsen in Bildform und/oder Schriftzeichen- bzw. Zahlenform dargestellt sind, damit darüber die operationelle Leitung des Bodenverkehrs vorbereitet werden und erfolgen kann.

27. System nach Anspruch 26, d a d u r c h g e k e n n z e i c h n e t , daß in die Erfassung und/oder operationeile Leitung Fahrzeugbewegungen auf dem Flughafengelände einbezogen sind, z.B. mit Hilfe von Transponderabfragen oder Squittern von Transpondern, über ID-Tags und drahtlose Kommunikationsmittel, die auch zur Übertragung von Anweisungen genutzt werden kann.

28. System nach Anspruch 26 oder 27, d a d u r c h g e - k e n n z e i c h n e t , daß in die Erfassung und/oder operationelle Leitung die Flugbewegungen im Anflug- und Abflugbereich einbezogen sind.

29. System nach einem der Ansprüche 26 bis 28, d a d u r c g e k e n n z e i c h n e t , daß im Rahmen des Bodenver- kehrs-Leitsystems über ein an sich bekanntes Radarvideo oder ein synthetisiertes Bild die Flughafenverkehrswege, die Flugzeug- bzw. Fahrzeugpositonen und gegebenenfalls Geschwindigkeit, sowie Rollrichtungen darstellbar sind.

30. System nach einem der Ansprüche 26 bis 29, d a d u r c h g e k e n n z e i c h n e t , daß im Rahmen des Bodenver- kehrs-Leitsystems die Anzeigen auf einem Monitor konzentrierbar sind.

31. System nach Anspruch 30, d a d u r c h g e k e n n z e i c h n e t , daß der Monitor auch Fenster mit Statusanzeigen und/oder Übergabeanzeigen, insbesondere in Zeilenform und Quittierungszeilen etc. anzeigend ausgebildet ist.

32. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß die im System erfaßten Daten entsprechend des jeweiligen Verkehrsaufkommens des Flughafens auf einen oder auf mehreren Controllerplätze aufteilbar und entsprechend der jeweiligen Verantwortung be- arbeitbar sind.

33. System nach einem der vorhergehenden Ansprüche, d a - d u r c h g e k e n n z e i c h n e t , daß die Übergabe der Verantwortung nach einer Übergabequittierung in Fensterdarstellung auf dem Monitor oder auf Hilfsmonitoren erfolgt.

34. System nach einem der vorhergehenden Ansprüche, d a - d u r c h g e k e n n z e i c h n e t , daß die Übernahme der Verantwortung aus dem Anflugbereich in den Landebahnkontrollbereich und über den Rollbahnkontrollbereich in den Vorfeldkontrollbereich und in umgekehrter Reihenfolge für den Abflug durch Umgruppierung von elektronischen Flugstreifen ( strip less) und Kennzeichnung der jeweiligen Verantwortung in Monitorfenstern erfolgt, gegebenenfalls in Verbindung mit dem Radarvideo oder einer synthetischen Darstellung.

35. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß die Radardaten, insbesondere mit plot-extraction, zusammen mit dem Status der Rol1führungs- , Lande- und Startbahn- lichter sowie weiteren Sensorkomponenten (aber auch von Transpondern) gegebenenfalls mit Hilfe von Datafusion und Sensor-Korrelation zu einem einheitlichen Format verarbeitet, insbesondere vollständig digitalisiert und dann dem Radarvideo aufgegeben oder zu einem vollständigen, synthetischen Bild zusammengesetzt und/oder anderen Monitordarstellungen aufgegeben werden.

36. System nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß das Radarvi- deo, gegebenenfalls Fenster mit Statusanzeigen, Übergabezeilen und Quittierungszeilen etc. auf einem Flachbildschirm mit einer Bildschirmdiagonalen von über 19 Zoll (flat-panel) dargestellt sind, der insbesondere als Touchsreen mit Schaltelementen für die Flughafenbefeuerung, für die Voicekommunicati- on etc. ausgebildet ist.

37. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß das Bodenverkehrs-Leitsystem mit Daten der Flugzeugbewe- gungen im weiteren Luftraum, gegebenenfalls mit durch GPS, insbesondere Differential-GPS, ermittelten Anflug- und Abflugpositionen, Positionen auf dem Rollfeld und gegebenenfalls im Parkbereich versorgt wird.

38. System nach einem oder mehreren der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß es ein Flughafen-Datenübertragungssystem aufweist, das mit Glasfaserübertragungstechnik, Coaxialkabeln und/oder Twi- sted Pair-Kabeln insbesondere in redundanter Ausführung, arbeitet .

39. System nach einem oder mehreren der vorhergehenden An- Sprüche, d a d u r c h g e k e n n z e i c h n e t , daß es ein automatisches Dockingsystem aufweist, das insbesondere mit optischer Erfassung, etwa über Zeilenkameras oder Laserradar, zur Ermittlung der Flugzeugposition arbeitet, gegebenenfalls unter Zuhilfenahme eines Transponderidentifika- tionssystems für die optisch erfaßten Flugzeuge.

40. System nach Anspruch 39, d a d u r c h g e k e n n z e i c h n e t , daß die von dem Dockingsystem gelieferten Positionsdaten in die Datenfusion und Sensorkorrelation ein- geführt werden und umgekehrt.

41. System Anspruch 39 oder 40, d a d u r c h g e k e n n z e i c h n e t , daß die Auswahl-, Belegungs- sowie Statusmeldungen von Parkpositionen flugplanbezogen erfolgen und auf Monitoren angezeigt werden.

42. System nach einem der vorhergehenden Ansprüche, mit einem Dockingsystem für Flughafenterminals, umfassend eine Positioniervorrichtung, mittels der ein Flugzeug in eine für seinen Bautyp vorgegebene Parkposition leitbar ist und die eine Videoeinrichtung, mittels der das Flugzeug bei seiner Annäherung an das Flughafenterminal erfaßbar ist, und eine Auswerteeinheit aufweist, mittels der ihr von der Videoeinrichtung zugeführte, die Gestalt und die Bewegung des Flugzeugs be- treffende Daten auswertbar sind, d a d u r c h g e k e n n z e i c h n e t , daß in der Auswerteeinheit für unterschiedliche Bautypen jeweils ein Template-Satz abgespeichert ist, der zumindest drei, vorzugsweise fünf, für alle Bautypen markante Templates bzw. Umrißabschnitte des betreffenden Bautyps enthält, und daß in der Auswerteeinheit aus den eingegebenen Signalen der Videoeinrichtung die zumindest drei, vorzugsweise fünf, markanten Umrißabschnitte bzw. Templates des sich dem Flughafenterminal nähernden Flugzeugs (53) er- mittelbar und mit den abgespeicherten Template-Sätzen vergleichbar sind.

43. System nach einem der vorhergehenden Ansprüche, mit einer Dockingeinheit (DSS) pro Gate, die über ein Kommunikations- netzwerk (CNWS) mit einer zentralen Steuerinrichtung (CWPS) in Verbindung steht, ein Flugfeldsituationsüberwachungs- und -verarbeitungssegment (ASMPS) , zumindest ein Informationsund Leitanzeigesegment (AGDS) , ein Daten- und Statusweiterleitungssegment (DSHS) mit zumindest einer Videokamera je Mittellinie des Gate, und zumindest ein Gatebetriebssteuersegment (GOPS) aufweist, und der eine Eingabeeinheit (AuxS) zugeschaltet ist, mittels der Flugzeugmuster und das Gate betreffende Informationen in die Dockingeinheit (DSS) eingebbar sind.

44. System nach Ansprüche 43, d a d u r c h g e k e n n z e i c h n e t , daß das Daten- und Statusweiterleitungssegment (DSHS) der Dockingeinheit (DSS) auf derselben Hardware läuft wie das Flugfeldsituationsüberwachungs- und -ver- arbeitungssegment (ASMPS) , die Kommunikation zwischen der Dockingeinheit (DSS) und der zentralen Steuereinrichtung (CWPS) über das Kommunikationsnetzwerk (CNWS) bewerkstelligt sowie die Vorgänge innerhalb der Dockingeinheit (DSS) koordiniert.

45. System nach Anspruch 43 oder 44, d a d u r c h g e k e n n z e i c h n e t , daß die Dockingeinheit (DSS) so ausgebildet ist, daß Inf ormations- und Leitanzeigen von ihr auf einen Bildschirm im Cockpit eines sich an das Gate annähernden Flugzeugs übertragbar sind.

46. System nach einem der Ansprüche 43 bis 45, d a d u r c h g e k e n n z e i c h n e t , daß das Kommunikationsnetzwerk (CNWS) als Hochgeschwindigkeitsnetz mit asynchronem Übertragungsmodus ATM ausgebildet ist, mittels dem ursprünglich digitale Signale und zu digitalen Signalen gewandelte ursprünglich analoge Signale, z.B. Videosignale, übertragbar sind.

47. System nach Anspruch 46, d a d u r c h g e k e n n z e i c h n e t , daß das ATM-Hochgeschwindigkeitsnetz einen oder mehrere Netzwerkadapter aufweist.

48. Verfahren zur Übergabe der Kontroll-/Leitungs-/Einwei- sungsbefugnis bezüglich eines Luftfahrzeugs (53) zwischen einem Fluglotsen, einem Bodenkontrolleur und/oder einem Dock- ingkoordinator, insbesondere unter Verwendung eines Systems nach einem der vorhergehenden Ansprüche, d a d u r c h g e k e n n z e i c h n e t , daß a) von der die Befugnis abgebenden Person auf elektrischem Weg eine Anfrage zu der die Befugnis übernehmenden Person geschickt wird, b) von dieser die Übernahme auf elektronischem Weg bestätigt wird, c) und daraufhin die relevanten Daten des betreffenden Luftfahrzeugs (53) auf den Monitor der übernehmenden Person übertragen werden .