Nach Prognosen von Experten wird der weltweite Luftverkehr in der Zeit um die Jahrtausendwende beständig zunehmen, die ge- samte Luftfahrtbranche kann mit erheblichen Zuwachsraten rechnen. Die Flughäfen müssen sich diesem Trend durch effek- tive Nutzung ihrer Anlagen unter Einsatz modernster System- technik stellen. Hierbei gilt es, bereits vorhandene Ressour- cen 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 Einwei- sung und Abfertigung an vorgegebenen Dockingstationen notwen- dig, damit ein Flugzeug ohne jegliche Kollisionsgefahr von dem Luftraum bis an eine Andockstation und von dort auch wie- der 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 Kontroll- person zu übermitteln. Diese Methode hat sich jedoch als äu- erst aufwendig erwiesen, da hierbei in der Bodenkontrollsta- tion 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 be- schreibt 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 Koor- dination 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 ei- nem 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 ver- wiesen: 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, Doku- ment-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 Sy- stem", 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. gemein- sam 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, Zaventem, Brüssel AP.01.810e, Sonderdruck zur Ausstel- lung Inter Airport 1995. Hier beschriebene, mit am Boden an- geordneten Sensoren arbeitende Systeme dienen dazu, eine Op- timierung des Flughafenverkehrs bei einer Erhöhung der Start- und Landekapazität eines Flughafens unter allen Wetterbedin- gungen bei grö tmöglicher Sicherheit zu gewährleisten. Zu diesem Zweck arbeitet ein derartiges Leitsystem mit Erfas- sung, integrierter Verarbeitung und bildlicher Darstellung der relevanten, insbesondere der sicherheitsrelevanten Posi- tionen und Bewegungen von Flugzeugen und gegebenenfalls Fahr- zeugen auf dem Flughafengelände (Start- und Landebahn, Roll- bahnen, 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 Bodenkon- trollzentrums dargestellt werden, damit darüber die operatio- nelle Leitung des Bodenverkehrs vorbereitet werden und erfol- gen 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 einzuhal- ten. Nach dem Touchdown bewegt sich das Flugzeug auf dem ris- kantesten 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 vorgegebe- ne Parkposition leitbar ist und die eine Videoeinrichtung, mittels der das Flugzeug bei seiner Annäherung an das Flug- hafenterminal erfa bar ist und eine Auswerteeinheit aufweist, mittels der ihr von der Videoeinstellung zugeführte, die Ge- stalt und die Bewegung des Flugzeugs betreffende Daten aus- wertbar sind. Aus der DE 40 09 668 Al 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 Leitsy- stemen können zwar die jeweiligen Phasen einer Flugzeugbewe- gung von dem zuständigen Personal optimal begleitet werden.

Nach wie vor bereitet jedoch die Übergabe der Weisungsbefug- nis 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 compu- tergestützten Systeme derart miteinander zu koppeln, da der Übergang der Zuordnung eines Flugzeugs von einem weisungsbe- fugten 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 Sy- stem zur Koordination der Kontrolltätigkeit des Flugsiche- rungspersonals, 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 Radarinforma- tionen 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 aktu- ellen 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 Auf- forderungssignal 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 zu- ständige Personal gemeinsam in einem Raum des Towers unterge- bracht ist oder an verschiedenen Orten, da eine direkte Kom- munikation 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 mitein- ander kommunizieren. Hierfür können einerseits neben den Mo- nitoren 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 mit- tels Touchscreen.

Weiterhin hat es sich als günstig erwiesen, da das/die Sy- stem(e) für die Zuordnungsänderung Möglichkeiten zur Rückmel- dung 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 er- fährt sofort, da die neu zuständige Stelle ihre Verantwor- tung 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 Aus- tausch aktueller Informationen, insbesondere von Flugzu- stands-, Positions-, Bewegungs-, Richtungs-, Radar- und/oder Videoinformationen zwischen den Systemen a) bis c), insbeson- dere bei einer Zuordnungsänderung. Bei den eingangs erwähn- ten, computerunterstützten Leitsystemen ist es teilweise mög- lich, charakteristische, aktuelle Informationen auf dem be-

treffenden Bildschirm einzublenden und dadurch das Bedienper- sonal mit den notwendigen Informationen über den aktuellen Zustand der verschiedenen Flugzeuge zu versorgen. Diese In- formationen können auf den unterschiedlichsten Wegen gewonnen werden, bspw. durch Antwort eines in einem Flugzeug angeord- neten Transponders auf ein Radarsignal, durch Mikrowellen- oder 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, Bewegungs- richtung, Geschwindigkeit, usf. eines Flugzeugs zu errechnen.

Diese berechneten Daten können bei der oben beschriebenen Zu- ordnungsänderung gleichzeitig mit übergeben werden und er- scheinen somit auf dem Bildschirm der nachfolgend zuständigen Kontrollperson. Da hierbei gleichzeitig der Einflu bereich des vorhergehenden Lotsen endet, kann das Flugzeug ein- schlie lich der darauf bezogenen Daten in dessen Bildschirm- liste ausgetragen bzw. von dessen graphischer Bilddarstellung gelöscht werden. Diese Daten begleiten die Darstellung des Flugzeugs somit von Kontrollstelle zu Kontrollstelle und kön- nen durch die unterschiedlichsten Sensorinformationen in re- gelmä 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 aufwei- sen. Dies ist der Normalfall, wo die Verantwortung über die einzelnen Bereiche des Flughafens - Luftraum und Start- bzw.

Landebahn, Rollbahnen und Vorfeld, Andockstationen - auf meh- rere Personen des Kontrollpersonals aufgeteilt ist. Eine der-

artige Konfiguration empfiehlt sich bei allen Gro - oder Re- gionalflughäfen während der Betriebszeiten mit normalem Ver- kehrsaufkommen, so da bei unvorhergesehenen Ereignissen kei- ne kritischen Situationen ausgelöst werden können.

Andererseits besteht die Möglichkeit, da die Informations- darstellung zweier oder aller Systeme a) bis c) zumindest zeitweise, insbesondere während Phasen mit niedriger Ver- kehrsdichte, auf demselben Monitor erfolgt. Hierbei kann bspw. in verkehrsarmen Nachtstunden die Einweisung sporadisch eintreffender Flugzeuge aus dem Luftraum bis zu der betref- fenden Andockstation einem einzigen Fluglotsen übertragen werden, der in umgekehrter Reihenfolge auch während der ge- samten 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 eingeblen- det werden.

Die Übergabe eines einfliegenden Flugzeugs aus dem Einflu be- reich 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 Ra- darabtastung gemeldet werden. Diese Information wird auf der Bildschirmdarstellung des Fluglotsen sichtbar gemacht und zeigt diesem an, da er nun die Kontrolle über dieses Flug- zeug an die Bodenkontrollstation abgeben kann. Ein entspre- chender Tastendruck und eine Bestätigung der Gegenseite be- siegeln 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 gelei- tet, und durch eine Positionserfassung, bspw. mit einem Bo- denradar, erhält der zuständige Bedienstete des Kontrollzen- trums 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 an- hand 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 Be- diensteten 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 Weisungsbe- fugnis von der Bodenkontrollstation, und nachdem alle sonsti- gen 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 Grundsy- stem, 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 insbe- sondere für Gro flughäfen geeignet ist. Auf dieser Basis las- sen sich die Applikationssoftware und die Datenbank gemä Er- findung 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 Be- dingungen und sonstigen Schnittstellen erforderlich ist.

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

Grundsätzlich kann das erfindungsgemä e Flughafenkoordinati- onssystem als eigenständiges System effizient betrieben wer- den. 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 Flughafenverwal- tungssystem, bspw. dem an sich bekannten ITOS, stattfinden.

Dieses Verwaltungssystem ist eine auf Unix basierende Anwen- dung zur Abrechnung und Verwaltung der Flugbewegungen an Flughäfen. Die Anwendung verfügt über eine (Motif-)Schnitt- stelle 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 Flugbe- wegungen oder angekündigter Flugbewegungen ausgetauscht wer- den und die dann automatisch weiterverarbeitet werden können.

Zur Lösung der Erfindungsaufgabe wird bei einem Flughafenko- ordinationssystem mit den eingangs genannten Merkmalen im Rahmen der allgemeinen erfinderischen Idee ferner vorgeschla- gen, da es die Koordination des ankommenden und des abgehen- den 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 Radardatenverarbei- tungssystem bereitgestellt, das vorzugsweise über ein LAN (local area network) und/oder ein WAN (wide area network) verbunden ist und wobei zwischen einem Server des Flughafen- koordinationssystems 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 Grundkonzep- tes 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 erfindungsge- mä en Flughafenkoordinationssystem und weiteren Datenverar- beitungssystemen sind vor allem die Anforderungen für den Da- tenaustausch, die wechselseitige Verbindung der beiden Syste- me 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 Flughafenko- ordinationssystem mit einer Rufzeichenzuordnung zu einem SSR- Code arbeitend ausgebildet sein. Dies ermöglicht eine leich- tere Identifikation des Objekts innerhalb des Radardatenver- arbeitungssystems. Insbesondere kann eine Rufzeichenanforde- rung mit Darstellung nach Eintritt eines Flugzeuges in einen bestimmten Kontrollraum automatisch erfolgen.

Es liegt im Rahmen der Erfindung, da das Flughafenkoordina- tionssystem eine Kontrollraumüberwachung aufweist, die zwi- schen ankommenden, abfliegenden und überfliegenden Objekten, also zwischen relevanten und nicht relevanten Objekten, un- terscheidet.

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 operationelle 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 Über- tragung von Anweisungen genutzt werden können. So wird die Kollisionssicherheit in Bezug auf den Bodenverkehr, der bis- her besonders im Vorfeld-Bereich weitgehend unkontrolliert abläuft, entscheidend erhöht. Es ist weiterhin vorgesehen, da in die Erfassung und operationelle Leitung die Flugbewe- gungen 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 be- legt 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 Identi- fikation dient. Die Identifikation am Boden wird erfindungs- gemä durch Übernahme der Identifikation vom Anflugradar (Sekundärradar) bei laufendem Verkehr bzw. vom Docking Gui- dance System beim startenden Verkehr und Beibehaltung der Identifikation durch Tracking der Ziele des Primärradars durchgeführt. Zur weiteren Erhöhung der Sicherheit und Zuver- lä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 gleichzeiti- ger Identifikation ermittelt. So ist eine jederzeitige, red- undante 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 vorzuschla- gen und diese auf Kollisionsfreiheit automatisch zu überprü- fen. Die Planungskomponente und die Überprüfung der Kollisi- onsfreiheit erfolgt durch eine fest installierte Software, der die entsprechenden Sicherheitsfeatures eingegeben sind.

Durch diese wird auch die Einhaltung der Mindestabstände un- ter 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 vorteil- haft die Flugpläne. Auf Gro flughäfen erfolgen die Start- und Landebewegungen nicht spontan, sondern werden flugplangerecht geplant, ebenso die Gatebelegung. Weiterhin kann die Befeue- rung der Rollbahnen insbesondere hinsichtlich ihrer Ansteue- rung programmtechnisch in das erfindungsgemä e Flugzeugleit- system 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) ausge- geben 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 Anga- ben des BRITE II-Systems mit höherer Datenkonzentration und

detaillierten Angaben, als sich aus der Kombination des be- kannten 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 gebilde- tes Abbild der Verkehrswege des Flughafens, mit Fenstern mit Statusanzeigen, Übergabezeilen und Quittierungszeilen etc.

sowie mit den Schaltzuständen der Rollbahn-Befeuerungsab- schnitte, 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 Control- lerplätze gebildet werden. Entsprechend erfolgt dann eine Aufteilung der Verantwortung auf die einzelnen Lotsen der Bo- denkontrollstation oder im Tower.

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

Eine besonders vorteilhafte Durchführung der vorstehend ge- schilderten Abläufe ist möglich, wenn ein gro er Flachbild- schirm für die Darstellung der einzelnen Fenster, des Radar- videos etc. verwendet wird, insbesondere in Ausführung als Touchscreen. Bei einem derartigen Touchscreen kann sowohl ei- ne Schaltung durch Berühren der jeweiligen Punkte, z.B. der Stopbars oder Rollbahn-Abschnitte auf dem gebildeten synthe- tischen 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 durch- geführten Schaltvorgänge wie auch ähnlich ablaufender Überga- besequenzen.

Zur notwendigen Datenkonzentration ist vorgesehen, da zu- nä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 aufge- geben.

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 Unsicher- heit 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 Zei- lenkameras.

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 Flughafenge- lände verteilt angeordneten Befeuerungsanlagen und die in de- ren Stromkreis eingeschleiften Sensoren, insbesondere Positi- onssensoren definiert anzusprechen und/oder abzufragen und dadurch einerseits die für die Lotsung des betreffenden Flug- zeugs relevanten Befeuerungen in Betrieb zu nehmen und ande- rerseits die von den einzelnen, adressierbaren Sensoren er- zeugten 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 Sensorkorre- lation eingeführt werden und umgekehrt. Wenn dies unter Be- rücksichtigung der Parkpositionspläne erfolgt, diese also ebenfalls in die Bodenverkehrsplanungen mit einbezogen wer- den, erhöht sich die Sicherheit weiter.

Schlie lich verfügen moderne Docking-Programme über eine Aus- werteeinheit, 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 Identi- fizierung mit den Umri abschnitten eines sich dem Flughafen- terminal 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 Positionier- vorrichtung hat sich eine Graubildkamera erwiesen.

Die Objektivbrennweite der Videoeinrichtung sollte vorteil- hafterweise 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 Flughafenga- tes, 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 Auswerteein- heit 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 ei- ne 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 Um- ri 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 Flughafenter- minal annähernden Flugzeugs können durch die zeitliche Filte- rung der Grauwertbilder ermittelte Trajektorien der Schablo- nen bzw. markanten Umri abschnitte der Flugzeugkontur einge- setzt werden.

Bei vollständiger Verwirklichung und Installation des erfin- dungsgemä en Dockingsystems, insbesondere von dessen Positio- niervorrichtung, 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 le- diglich eine Videokamera aufweist.

In besonders vorteilhafter Weise kann die vorstehend be- schriebene Bildelementverarbeitung sowie die Auffindung des Bautyps des sich an das Gate des Flughafenterminals annähern- den Flugzeugs bei einem Dockingsystem für Flughafenterminals zum Einsatz kommen, das je Gate eine Dockingeinheit hat, die über ein Kommunikationsnetzwerk mit einer zentralen Steuer- einrichtung 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 Flug- zeugmuster und das Gate betreffende Informationen in sie ein- gebbar 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 Status- weiterleitungssegment der Dockingeinheit auf derselben Hard- ware läuft wie das Flugfeldsituationsüberwachungs- und - verarbeitungssegment und die Kommunikation zwischen der Dock- ingeinheit und der zentralen Steuereinrichtung über das Kom- munikationsnetzwerk 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 vorge- sehen ist, so ist es möglich, zusätzlich das Informations- und Leitanzeigesegement mit in dem für die beiden vorgenann- ten Komponenten gemeinsamen Gehäuse anzuordnen.

Bei einer weiteren speziellen Ausführungsform eines derarti- gen 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 über- tragbar sind. Diese Betriebsweise kann an die Stelle des Be- triebs des Informations- und Leitanzeigesegments treten oder zusätzlich zum Betrieb dieses Informations- und Leitanzeige- segments 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 zweck- mä ig, dem Flugfeldsituationsüberwachungs- und -verarbei- tungssegment einen Digitalsignalprozessor zuzuordnen, in wel- chem die ursprünglich analogen Videosignale in digitale Si- gnale umgewandelt werden, bevor sie in die Eingabeleitung zum Daten- und Statusweiterleitungssegment eingegeben werden.

Die Eingabeeinheit, die der Dockingeinheit des erfindungsge- mä en Dockingsystems zugeordnet ist, hat vorzugsweise eine Flugzeugmusterausgabe, ein Gateeinrichtungschema, eine Kali- briereinheit und eine Validations- und Diagnoseinheit.

Vorteilhafterweise ist das Kommunikationsnetzwerk eines der- artigen Dockingsystems als Hochgeschwindigkeitsnetz mit asyn- chronem Übertragungsmodus ausgebildet, mittels dem ursprüng- lich digitale Signale und zu digitalen Signalen gewandelte, ursprünglich analoge Signale, z.B. Videosignale, übertragbar sind.

Das ATM-Hochgeschwindigkeitsnetz kann vorteilhafterweise zu- mindest einen als SICAN ATMax 155-PM2 ausgebildeten Netzwer- kadapter 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 Flugfeldsi- tuationsprozessor auf, der mittels eines Interface an das Ga- teprogrammsegment angeschlossen ist.

Das Gatesteuersegment der Dockingeinheit hat eine Flugfeldbo- denbeleuchtung, eine Informations- und Leitanzeige, eine Ga- tebetriebssteuerung, ein Luxometer und einen Gateprozessor, der auf einer PC-Plattform läuft, an welche die Flugfeldbo- denbeleuchtung, die Informations- und Leitanzeige, die Gate- betriebssteuerung und das Luxometer angeschlossen sind, und der mittels eines Interface an das Gateprogrammsegment ange- schlossen 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 Gatemana- gement 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 Erfin- dung sowie anhand der Zeichnung. Diese zeigt in: FIG 1 eine schematische Darstellung der Komponenten eines Ko- ordinationssystems für die Flugkontrolle;

FIG 2 ein Schaubild mit einem Überblick über die Software ei- nes derartigen Koordinationsprogramms; FIG 3 eine Bildschirmdarstellung auf dem Monitor eines Flug- koordinators; 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 Informa- tionsflusses innerhalb einer Andockstation; FIG 12 ein Blockschaltbild einer Andockstation mit deren Schnittstellen; FIG 13 einen Signalflu graphen, der den Informationsflu zwi- schen 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 Flughafenkoordinati- onssystems mit einer Aufteilung der Applikation in einen Ser- ver (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 vor- handen. Auf jedem Arbeitsplatz 2 steht die gleiche Funktiona- lität zur Verfügung. Die Verteilung der Aufgaben auf Arbeits- plätze 2 und Server 1 sowie die Synchronisation der Anforde- rungen 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 Flughafenkoordinations- systems zur Synchronisation und zum Datenaustausch mit den Client-Arbeitsplätzen 2, Schnittstelle zu einem ITOS-Flug- hafenverwaltungssystem 4, Schnittstelle zu einem Radardaten- verarbeitungssystem 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 Flughafen- koordinationssystem unter anderem folgende: Darstellung aktu- eller und vorangekündigter Flugpläne, (Ankunft, Abflug, Über- flug), Eingabe neuer sowie Modifikation bestehender Flugplä- ne, Durchführen von Zustandsübergängen bei Flugplänen sowie Aktualisierung aller Displays nach einer Bedienereingabe, Uhrzeitsynchronisation mit dem Server.

Als Kommunikationssystem zwischen dem Server 1, den Arbeits- plä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 Elemen- ten 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 Radar- arbeitsplatz 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), Festplat- te (optional), Diskettenlaufwerk (optional), Netzwerkan- schlu .

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

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

Durch besondere Konfigurations- und Programmierma nahmen wird erreicht, da au er der Flughafenkoordinationssystem-Anwen- dung, 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 Flughafenko- ordinations-Anwendungen beschränkt, wobei die Flughafenkoor- dinations-Benutzeroberfläche beim Starten automatisch an- läuft.

In FIG 2 ist ein Überblick über ein beispielhaftes Prozessmo- dell 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 ei- nem Steuerungs- und Controlling-Interface implementiert, ein- schlie 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 exter- ne Schnittstellen wie z.B. die AP100-Schnittstelle (Daten- austausch mit dem Radardatenverarbeitungssystem AP100), die ITOS-Schnittstelle (Datentaustausch mit ITOS-Flughafen) und/ oder eine Schnittstelle zum Bodenleitsystem ausgetauscht wer- den.

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. Si- gnale 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 Datenbank- tabellen: RPL-Table (Saisonflugplan); Printtable; Stammdaten- tabellen, Fehlerliste; ITOS-Queue (gemeinsame Daten mit Flug- hafenverwaltungsprogrammen), 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 ,,FpllnStore" 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 ei- ner verketteten Liste hinterlegt, aus denen die Reihenfolge der Flugpläne in der Datenbanktabelle "FplInUse"(bzw. inner- halb 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 wer- den.

Die Tabelle ,,PrintTable" dient dazu, einen Druckerserver zu starten, der in Abhängigkeit von der Auftragsart/Auftrags- nummer 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- tInfoTable, 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 selb- ständig nach einer Neueingabe durch den Bediener gespeichert hat (selbstlernender Teil der Datenbank).

In der Tabelle "StatInfoTable" werden Informationen gespei- chert, die im statischen Infofeld (FIG 3) angezeigt werden sollen.

Die Tabelle "Usertable" dient zur Verwaltung der zulässigen Benutzer für einen Arbeitsplatz am Flughafenkoordinationssy- stem.

Die Tabelle ,,LocalSsrCodeTable" wird vom Flughafenkoordinati- onssystem dazu verwendet, für die Flugpläne ohne SSR-Code ei- nen 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 einge- tragen. Grundsätzlich kann jedoch jeder Proze einen erkann- ten Fehler dort eintragen.

In den beiden Tabellen "ITOS-Queue" (Flughafenverwaltungs- system-Schlange) und ,,RDP-Queue" (Radardatenverarbeitungs- Schlange) werden vom Dispatcher-Proze bei Bedarf die Flug- plandaten 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 ei- ner RPC-Schnittstelle (remote procedure call) ausgegangen.

Durch die Verwendung dieses Standards ist gewährleistet, da die unterschiedlichen Systeme vollkommen unabhängig voneinan- der 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 Kontrollsy- stemen 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, ablau- fen können. Eine Änderung in der Software ist dafür nicht er- forderlich. 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 implemen- tiert werden. Der RPC-Client ist nur für diejenigen externen Schnittstellen erforderlich, für die das Flughafenkoordinati- onssystem als Datenquelle dient.

Für jede externe Schnittstelle, über die das Flughafenkoordi- nationssystem Daten empfangen soll, ist ein eigener RPC- Server des Flughafenkoordinationssystems erforderlich. Da- durch 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 Ruf- signal zurückzuübermitteln. Wenn dieses vorhanden ist, quit- tiert das Flughafenkoordinationssystem die Anforderung aus- drücklich und sendet das Rufsignal zurück. Wenn ein zugeord-

netes Rufsignal nicht vorhanden ist, sendet das Flughafenko- ordinationssystem 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 Radardatenverarbei- tungssystem ist entweder positiv (die Änderung wurde akzep- tiert) 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 zu- zuweisen, müssen diese lokalen Codes für die nächste Verwen- dung freigegeben werden, sobald sie nicht mehr benötigt wer- den. 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 Flughafenkoordinationssy- stem, diese lokalen SSR-Codes zu verwalten und zu garantie- ren, da sie nicht zur gleichen Zeit zweimal benutzt werden.

Deshalb ist es notwendig, da das Radardatenverarbeitungssy-

stem eine "Freigabe-Code"-Nachricht an das Flughafenkoordina- tionssystem ü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 dahin- gehend interpretiert, da der SSR-Code in dem vom Radardaten- verarbeitungssystem abgedeckten Bereich nicht mehr in Ge- brauch 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 vor- bestimmte 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 ei- ne 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 Radardatenverarbei- tungssystems.

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 Da- tenaustausch 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 Hardwareplattfor- men 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 Modi- fikationen an der Schnittstelle sind leicht in die existie- renden 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 da- bei 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 einge- tragen. Fehlermeldungen 1. Ordnung werden nicht in die Daten- bank 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 Fehlerbe- dingung. 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 protokol- liert. Um dem Bediener auch nach dem Quittieren einer Überwa- chung die Liste der aktuell vorliegenden Überwachungsmeldun- gen 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 folgen- des ausgeführt: Die Schnittstelle für Datenflu und Kommuni- kation zum bzw. mit dem Bediener wird durch eine MS-Windows- Applikation gebildet. Diese Applikation verfügt über eine di- rekte Schnittstelle zur Flughafenkoordinationssystem-Daten- bank 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 automa- tisch 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 Daten- bankeinträ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öri- ge 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 erhal- ten 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 quit- tierter Fehler) erzeugt werden.

Ein Fluplan-Infofeld wird nur in bestimmten Situationen dar- gestellt und enthält alle Informationen über den aktuell aus- gewä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 an- deren 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- dungen 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, wo- bei ü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 über- sichtlich dargeboten werden. Auf diesem Monitor können ferner die weiter unten beschriebenen Übergabemeldungen eingeblendet werden, deren Einbindung bevorzugt von dem Flughafenkoordina- tionssystem mit übernommen wird.

In FIG 4 bezeichnet 11 das Flughafen-LAN (local area net- work). 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 Mo- nitortechnik 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 not- wendige 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 Senso- ren 20 verbunden, die relativ beliebig ausgestaltet und über

das gesamte Flugplatzgelände verteilt sein können. Wie darge- stellt, befinden sich die BRITE-Einheiten in einem Serien- kreis, um für alle Lampen-Einheiten gleiche Helligkeit si- cherzustellen. 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 inte- grierten Controller-Arbeitsplatzes, vorteilhaft auf X-Windows und offener Architektur basierend. Hier kann aus dem Rohvideo (reales Darstellungsvideo) eine synthetische Darstellung zu- sammen mit Landkarten, Objektdaten, Konfliktmeldungen, Flug- plandaten, 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 er- ster Linie verschiedenen Radarsystemen. Die Sensordaten wer- den fusioniert, um eine nahtlose Überwachung zu gewährlei- sten.

Die Datenverarbeitung erfolgt über ein Multisensor-Tracking und Labelling mit einer Korrelation der Sensordaten mit Flug- plandaten, Befeuerungs- und Docking/Gatebelegungsdaten. Auf dieser Basis erfolgt dann die Steuerung des Flughafenver- kehrs, insbesondere des Bodenverkehrs auf Rollbahnen und Vor- feld.

In FIG 5 bezeichnet 21 einen Block mit Sensordaten zur Über- wachung, 22 bezeichnet die Vorgänge, die zur Überwachung die- nen, 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. Sei- tens 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 Infor- mationen ü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 er- gibt eine komplette Information über den Flughafenverkehr.

In FIG 6 bezeichnet 30 eine Start- und Landebahn und 31 Roll- bahnen. Auf den Rollbahnen 31 befinden sich Stopbars 32 o.ä.

sowie weitere, aus Gründen der Vereinfachung nicht näher ge- zeigte Befeuerungs- und Hinweiseinrichtungen. FIG 6 zeigt ein ausgeführtes synthetisches Video in einfacher Form, das er- findungsgemä e Videobild kann detaillierter ausgebildet sein.

33 bezeichnet eine Fensterdarstellung des Flugplans, 34, 35 und 36 sowie 37 bezeichnen weitere Flugplan- und Zuordnungs- fenster, bspw. auch Fenster mit Übergabemeldungen. Es ver- steht 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 aufge- führt, die das synthetische Video enthält. 41 zeigt die bei- den Arten von Sensoren, die auf unterschiedlichster Basis ar- beiten können. Am wichtigsten sind die kooperativ arbeitenden Sensoren, die gleichzeitig die Flugzeugidentifikation verifi- zieren. 42 zeigt die Grundzüge des Verkehrslenkungsystems, 43 die Hilfsfunktionen, die insbesondere bei besonderen Vorfäl- len 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, Mikrowel- lenempfä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 klei- neren Flughäfen mit nur wenigen Parkpositionen, ganz verzich- tet wird.

Ein wie in FIG 8 prinzipiell gezeigt in ein Flughafennetzwerk 51 einbezogenes Flughafenterminal 52 ist mit einem Dockingsy- stem ausgerüstet, mittels dem über eine Brücke eine Verbin- dung 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 Flug- hafenterminals 52 jeweils Positioniervorrichtungen zugeord- net, 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 Bewe- gung des Flugzeugs 53 betreffende Daten auswertbar sind, und ein Anzeigedisplay 58, mittels dem einem Piloten des Flug- zeugs 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 Positio- niervorrichtung 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 abge- bildet 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 darge- stellt 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, wel- che 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 unbe- wegten Gegenständen unterschieden werden können. Hierdurch ist es erleichtert, aus den Grauwertbildern einen Flugzeugum- ri zu ermitteln. Jeder Bautyp von Flugzeugen hat einen be-

stimmten Flugzeugumri , der seinerseits markante Umri ab- schnitte bzw. Schablonenbilder, sogenannte Templates auf- weist, 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 Auswerte- einheit 57 ein Template-Satz abgespeichert. Die für das sich an das Gate 54 annähernde Flugzeug 53 ermittelte Flugzeugkon- tur bzw. der daraus sich ergebende Template-Satz wird nunmehr mit den innerhalb der Auswerteeinheit abgespeicherten Templa- te-Sätzen verglichen, wobei als Ergebnis dieser Verleichsope- Station 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 Anzeige- display 58 werden nunmehr Angaben abgebildet, die den Flug- zeugfü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 Flughafentermi- nals 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. Hier- fü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 defi- nieren 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 invari- ant gegenüber Verschiebungen sind und ferner einen hohen Kon- trast in der Sequenz von Grauwertbildern aufweisen. Au erdem müssen die ausgewählten Merkmale bzw. Templates eine hohe To- leranz 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 Flug- zeugs 53 zur Videoeinrichtung 56 verzerrt erscheinen können.

Aus dem in FIG 11 dargestellten Datenflu diagramm geht her- vor, wie einzelne Funktionskomponenten des erfindungsgemä en Dockingsystems mit anderen Funktionskomponenten desselben so- wie 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 beschrie- benen 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 ihrer- seits über ein zentrales Beobachtungs- und überwachungssyste- minterface (Central Monitoring and Surveillance Systeminter- face, CMSI) und ein Anwenderinterface (User Defined Inter- face, UDI) in die Steueranlage des Flughafens einbezogen ist.

Das erfindungsgemä e Dockingsystem gliedert sich bei der Dar- stellung in FIG 11 in mehrere Funktionseinheiten. Zunächst ist dort eine Funktionseinheit aus Daten- und Statusweiter- leitung (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 Überwa- chungsdaten (gate i CMS data) Die CWP erhält von dieser Funk- tionseinheit DSH, CS Statusangaben bezüglich des jeweiligen Gates (gate i statuses), Livevideosignale von diesem Gate (gate i live video) und dieses Gate betreffende zentrale Be- obachtungs- 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 zentra- le Steuereinrichtung (Controller Working Position Subsystem, CWPS) und ein Kommunikationsnetzwerk (Communication Network Subsystem: CNWS). Die DSS enthält alle diejenigen Systemseg- mente, die an den Gates angeordnet sind. Die CWPS besteht aus einem auf einer Workstation basierenden Display- und Steuer- system, das in einem zentralen Kontrollraum des Flughafens vorgesehen ist. Das CNWS ist das Netzwerk, das diese beiden Untereinheiten miteinander verbindet, um Daten zwischen die- sen Untereinheiten zu übermitteln.

Die DSS steht mit der Flugfeldsituation (Airfeld Situation) einerseits sowie mit Wartungspersonal (Maintainer), Kali- brierpersonal (Calibrator), Brückenpersonal (Bridge Person- nel), Bodenpersonal (Ground Personnel), (Co-)Piloten und der Flugfeldbeleuchtung (Airfield Ground Lighting, AGL) anderer- seits in Verbindung. Über die Schnittstelle AuxS kann die Ga- teausgestaltung (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); ande- rerseits besteht eine Verbindung zum zentralen Beobachtungs- und Überwachungssystem (Central Monitoring and Surveillance System), zur Flughafendatenzentrale (Airport Database), zu benutzerdefinerten Gatesystemen (User Defined Gate Systems), zur Befeuerung (Airfield Ground Lighting, AGL), zu Zeitbe- zugssystemen (Time Reference Systems) und zu einem Oberflä- chenbewegungsleit- und -steuersystem (Surface Movement Gui- dance and Control System, SMGCS). Die CWPS kann (zu ver- kehrsarmen Zeiten) mit anderen Systemen (bspw. TECOS und/oder einem Bodenleitsystem) auf demselben Monitor betrieben wer- den.

Die DSS hat vier unterschiedliche Segmente: Das Flugfeldsi- tuationsüberwachungs- und verarbeitungssegment (Airfield Si- tuation Monitoring and Processing Segment, ASMPS); das Infor- mations- und Leitanzeigesegment (Advisor and Guidance Display Segment, AGDS); falls zwei voneinander abhängige Zentral- oder Mittellinien vorliegen, kann, je nach Konfiguration bzw.

Anordnung der Zentral- oder Mittelllinien am Gate, ein zwei- tes AGDS erforderlich sein. Das AGDS beinhaltet einen inte- grierten Mikroprozessor, der die Anzeigeelemente steuert und

Anzeigebefehle in-Anzeigen umformt; das Daten- und Statuswei- terleitungssegment (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 in- nerhalb der DSS; das Gatebetriebssteuerungssegment (Gate Ope- rator Panel Segment, GOPS) ist ein mikroprozessorbasiertes System mit einer kleinen Tastatur und einem Flüssigkristall- display 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 zu- mindest 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 Di- stanzen 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 elek- tromagnetischen Störungen auftreten, eine galvanische Isolie- rung 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 Andock- vorgangs für das Personal der Zentrale, Eingabe von Gateaus- gestaltungen eines speziellen Gate, Eingabe neuer Flugzeugmu- ster, Datenaustausch mit umgebenden Systemen, z.B. Wartung, Flugplandaten, geplante Gatebelegungen. Zu jeder Zeit kann die geplante und die tatsächliche Belegung von Gates gra- phisch dargestellt werden. Das globale Bild kann in mehrere kleine Bereiche aufgeteilt werden. Eine Tafel aller besetzten Gates mit den zugehörigen Aufruf zeichen ist dargestellt. Das Zentralpersonal kann ein spezielles Gate und eine Livevideo- übertragung wählen. Die geplanten Daten sind in einem spezi- ellen 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, Bodenleitsy- stem GMCS sowie Andocksystem DS - über verschiedene Schnitt- stellen zum Anschlu an weitere Flughafenabteilungen, insbe- sondere Radarstation, Wartung, Verwaltung, usf. Erfindungsge- mä ist vorgesehen, die Leit- und Kontrollsysteme untereinan- der, 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 Lei- tungen miteinander zu vernetzen, oder aber ein bereits beste- hendes, flughafeninternes Datennetz zu verwenden oder gar beim Aufbau neuer Anlagen die verschiedenen Systeme oder Tei- le derselben im Rahmen einer einzigen Client-Server-Appli- kation miteinander zu verknüpfen.

Unabhängig von der konkreten Realisierung ist jedoch wichtig, da verschiedene Informationen und/oder Daten über Flugzeug- bewegungen, 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 wei- tergeben zu können.

Erfindungsgemä existieren insbesondere Kommunikationsmög- lichkeiten zwischen dem Flugsicherungssystem und dem Boden-

leitsystem GMCS einerseits und zwischen dem Bodenleitsystem GMCS und einer oder mehreren Dockingstationen DS anderer- seits, und zwar vorzugsweise in jeweils bidirektionalen Rich- tungen, 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 Flug- zeug 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 regi- striert 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 entsprechen- de 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 Fahrge- schwindigkeit, bei einem Start dagegen mit dem Erreichen ei- ner 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 Boden- leitstation. 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 Systemverkoppe- lung besonders wichtig. Hierbei kann die Positionsbestimmung einerseits durch einen Bodenradar erfolgen, andererseits auch durch im Bereich des Flugplatzes verteilte Sensoren wie Druckdosen, Induktionsschleifen, Lichtschranken, Infrarotsen- soren, Mikrowellensensoren, wie sie im Rahmen des Bodenleit- systems zumeist an einen gemeinsamen Schaltkreis angeschlos- sen 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 zeit- liche 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 Über- gabekriterien hinsichtlich Position, Geschwindigkeit, usf. an einem Monitor als ein besonders Signal angezeigt wird, damit das Personal auf die bevorstehende Übergabe aufmerksam ge- macht 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 Sy- steme auf einem einzigen Monitor erfolgen, wobei die Überga- besequenz mit einem Wechsel der Bildschirmdarstellung von ei- nem System in das andere gleichgesetzt werden kann. Um hier- bei unvorhergesehen eintretende Ereignisse sofort weiterzu- melden, kann vorgesehen sein, da von im Hintergrund laufen- den (Programm-)Systemen bei Bedarf Alarm- oder sonstige Mel- dungen 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.