TECHNISCHE UNIVERSITÄT BERLIN Institut für Luft- und

TECHNISCHE UNIVERSITÄT BERLIN Institut für Luft- und Raumfahrt

Sekretariat F 3 Marchstraße 12

10587 Berlin Prof. Dr. M. Fricke

Zwischenbericht an die Deutsche Forschungsgemeinschaft

Forschergruppe:

MENSCH-MASCHINE-INTERAKTION IN KOOPERATIVEN SYSTEMEN DER

FLUGSICHERUNG UND FLUGFÜHRUNG

Teilprojekt 1: Management von

potentiellen Luftfahrzeugkonflikten durch einenkooperativen Planungsprozeß

Management von potentiellen Luftfahrzeugkonflikten durch einen kooperativen Planungsprozeß TP 1

INHALTSVERZEICHNIS

1-2

INHALTSVERZEICHNIS

1 EINLEITUNG...........................................................................................................5

1.1 Ziele und Stand des Vorhabens...................................................................................5 1.2 Einbindung im Rahmen der Forschergruppe ..............................................................8 1.3 Mitarbeiter...................................................................................................................9 1.4 Abweichungen vom Antrag an die DFG.....................................................................9

2 STAND DER FORSCHUNG.................................................................................10

3 KONZEPTION .......................................................................................................13

4 IMPLEMENTIERUNG .........................................................................................14

4.1 Die ODS Toolbox .....................................................................................................14 4.2 Aufbau des Simulationssystems ...............................................................................16 4.3 Der Sektorlotsenarbeitsplatz SIMCO .......................................................................16 4.3.1 Datenquellen .........................................................................................................17 4.3.2 Das Radarbild........................................................................................................22 4.3.3 Funktionen zur Steuerung des Arbeitsplatzes.......................................................24 4.3.4 Flugzieldarstellung................................................................................................29 4.3.5 Das Etikett.............................................................................................................29 4.3.6 Elektronische Flugplanstreifen .............................................................................30 4.3.7 Das Strip Window.................................................................................................32 Funktionen für Experimente / Protokollfunktionen..................................................................33 4.3.9 Kommunikation mit dem modellierten Fluglotsen – MoFL.................................35 4.4 Der Multi-Sektor-Planer-Arbeitsplatz SIMFLOW ...................................................39 4.4.1 Einspeisung der Daten ..........................................................................................39 4.4.2 Das Radarbild........................................................................................................40 4.4.3 Funktionen zur Steuerung des Arbeitsplatzes.......................................................41 4.4.4 Vorschau – Simulation..........................................................................................41 4.4.5 Schneller Vorlauf ..................................................................................................43 4.4.6 Konflikterkennungs- und -lösungsprogramm .......................................................44 4.5 Der Pseudo – Piloten – Arbeitsplatz .........................................................................45 4.5.1 Benutzerschnittstelle .............................................................................................45 4.5.2 Abfrage aktueller Flugparameter ..........................................................................46 4.5.3 Steuerung der virtuellen Luftfahrzeuge ................................................................46

5 ZUSAMMENFASSUNG UND AUSBLICK.........................................................47


INHALTSVERZEICHNIS

1-3

5.1 Verbleibende Arbeitspakete bis 30.09. .....................................................................48 5.2 Neue Fragestellungen................................................................................................48 5.3 Verknüpfung der Arbeit mit anderen Teilprojekten .................................................49

6 LITERATUR...........................................................................................................50

7 TAGUNGEN UND EIGENE VERÖFFENTLICHUNGEN...............................50


ABKÜRZUNGSVERZEICHNIS

1-4

ABKÜRZUNGSVERZEICHNIS

ADS Automatic Dependent Surveillance AFL Actual Flight Level ASD Aircraft Situation Display CARD Conflict And Risk Display CFL Cleared Flight Level CNS/ATM Communication, Navigation, Surveillance /Air Traffic Manage-

ment COTS Commercial Off The Shelf CZW Conflict Zoom Window FAA Federal Aviation Administration FANG Future Air Traffic Management/Next Generation FCM Flow Control Message FFAS Free Flight Airspace FIR Flight Information Region FMS Flight Management System GATS Generic Air Traffic Simulation HAW Horizontal Aid Window ICAO International Civil Aviation Organisation ILR Institut für Luft- und Raumfahrt LAT Look Ahead Time LOTEC (LOng TErm Conflict prediction and solution analysis) MAS Managed Airspace MoFL Modell der Fluglotsenleistungen MPA Multisector - Planning - Area NATS National Air Traffic Services ODS Operational Display Systems RFL Requested Flight Level SIMCO Sophisticated Interface for Monitoring, Controlling & Organizing SIMFLOW Sophisticated Interface for the Management of FLOW Control UDP User Datagram Protocol UIR Upper Information Region UMAS Unmanaged Airspace VAW Vertical Aid Window


EINLEITUNG

1-5

1 EINLEITUNG Das Teilprojekt 1 repräsentiert innerhalb der Forschergruppe die technische Seite der boden-seitigen Flugsicherung. Seine Aufgaben umfassen neben der Konzeption innovativer Flugsi-cherungsverfahren gemeinsam mit den übrigen Teilprojekten die Entwicklung der hierfür er-forderlichen Systemkomponenten und Algorithmen für die operationellen und strategischen Instanzen der Flugsicherung. Dies beinhaltet die Erstellung der Mensch – Maschine – Schnitt-stellen für die im ATM-Konzept verankerten Arbeitsplätze für den Sektorlotsen und den Mul-ti–Sektor–Planer sowie deren softwaretechnische Integration in ein Luftverkehrssimulations-system.

1.1 Ziele und Stand des Vorhabens

Ziele

In Zusammenarbeit mit den anderen Teilprojekten wird das Teilprojekt 1 ein zukünftiges, flugphasenübergreifendes Air Traffic Management Konzept entwerfen und in gemeinsamen Simulationsläufen die Durchführbarkeit und den Nutzen des Konzeptes demonstrieren. Wäh-rend der Experimente werden die Auswirkungen neuer Assistenzsysteme und Kontrollverfah-ren auf die beteiligten Operateure untersucht.

Die im laufenden Antragszeitraum erarbeiteten Konzepte und die in einer Basisversion ent-wickelten technischen Systeme werden in der kommenden Phase der Forschergruppe überar-beitet und weiterentwickelt. Das geschaffene Simulationssystem soll derartig perfektioniert werden, daß extensive Experimente mit Lotsen und Piloten unter realistischen Bedingungen vorgenommen werden können, so daß deren Ergebnisse auf optimalen Voraussetzungen beru-hen. Einschränkungen der Simulationszenarien, wie beispielsweise stark reduzierte Verkehrs-lasten oder nicht echtzeitfähige Kommunikationsabläufe, die aufgrund unzureichender Rech-ner- beziehungsweise Netzwerkleistungen vorgenommen werden mußten, sollen eliminiert werden.

Das Teilprojekt 1 wird die zusätzliche Planungsinstanz des Multi Sektor Planers vollständig in das bodenseitige Simulationssystem integrieren. Es wird ein Abbild des konzipierten Multi –Sektor–Planungs-Gebietes („Multisector - Planning – Area“, MPA) erstellt, in dem mehrere Sektorlotsenteams in Zusammenarbeit mit dem Multi-Sektor-Planer konfliktfreie Flugprofile untereinander und mit der Bordseite aushandeln. Es sollen mindestens zwei vollständig aus-gearbeitete Sektorlotsenarbeitsplätze und ein Pseudo - Lotsenarbeitsplatz zum Einsatz kom-men.

Eine wichtige Rolle spielt hierbei die zentrale Verwaltung der Flugplandaten, die, je nach Verhandlungsstatus, unterschiedliche Aktualität und unterschiedlich präzise Vorhersagege-nauigkeit besitzen. Hierfür ist die Nutzung einer professionellen Datenbank vorgesehen, die in Zusammenarbeit mit TP1 von dem am Institut für Luft- und Raumfahrt ansässigen Projekt des


EINLEITUNG

1-6

"Profile Negotiation Manager" nach den Kriterien des Verhandlungskonzeptes der Forscher-gruppe entwickelt und demnächst verfügbar sein wird. Diese Datenbank spielt die zentrale Rolle bei der Bestimmung und Adressierung der bodenseitig beteiligten Verhandlungspartner.

Wie bereits im ursprünglichen Antrag anvisiert, wird eine Ausweitung auf die Anflugphase stattfinden. Hierfür erforderliche Funktionalitäten werden, im kommenden Antragszeitraum von TP3 mit Unterstützung durch TP 1 vorbereitend für die dritte Projektphase entwickelt. Hierdurch soll es den zukünftigen Teilprojekten 1 und 2 ermöglicht werden, in dieser Phase direkt zu Untersuchungen innerhalb des Anflugbereichs überzugehen.

Es ist sicherzustellen, daß die zu entwickelnden Funktionalitäten sich in das Gesamtkonzept der Forschergruppe eingliedern. Dazu gehören unter anderem die zu entwickelnden Algorith-men zur Konflikterkennung und -lösung für den Anflugbereich. Das bisherige Teilprojekt 1 verfügt bereits über Algorithmen zur Konflikterkennung und -lösung für Flugprofile des Streckenbereichs, die bei den laufenden Untersuchungen zum Einsatz kommen. Es wird daher eine enge Zusammenarbeit zwischen TP1 und TP3 bei der Konzeption der neuen Algorithmen stattfinden, da dies eine wichtige Voraussetzung für eine reibungslose Fortführung der Unter-suchungen am Lotsenarbeitsplatz innerhalb der Anflugphase darstellt.

Stand des Vorhabens

Im ersten Antragszeitraum sollte ein bestehender Multi-Sektor-Planer-Arbeitsplatz, das Air-craft Situation Display (ASD), an das zu erstellende Simulationssystem angeschlossen wer-den. Nach Konzeption des Simulationssystems stellte sich jedoch heraus, daß eine leistungs-fähige Kommunikation miteinander vernetzter Rechner langfristig nur über eine TCP/IP – Socketverbindung zu realisieren ist. Aufgrund der veralteten "File-Kommunikation" des ASD, bei der der Informationsaustausch mit peripheren Rechnern über Ablage und Auslesen von Dateien erfolgt, wäre ein Anschluß an das Simulationssystem nur über unverhältnismäßig ho-hen, nicht lohnenden Aufwand zu realisieren gewesen. Eine Portierung des ASD vom DOS – Betriebssystem auf das UNIX – System wäre zu einem späteren Zeitpunkt ohnehin notwendig gewesen, da eine zügige Weiterentwicklung des Systems mit der ODS Toolbox erfolgen wird, welche auf dem UNIX – System aufbaut.

Aus diesem Grunde wurde von vornherein damit begonnen, den Multi–Sektor–Planer–Arbeitsplatz mit der ODS Toolbox zu entwickeln. In Anlehnung an den zur Simulation gehö-renden Sektorlotsenarbeitsplatz SIMCO wird der Arbeitsplatz des Multi–Sektor–Planers SIM-FLOW genannt, da dieser im wesentlichen Verkehrsflußsteuerung betreibt. Eine erste lauffähige Version, die gegen Ende des laufenden Bewilligungszeitraumes zur Verfügung ste-hen wird, soll im kommenden Antragszeitraum mit allen notwendigen Funktionen zur Beur-teilung der prognostizierten Verkehrssituation und zur Kommunikation mit den Sektoren der ihr unterstellten "Multisector – Planning – Area" sowie den data-link-fähigen Luftfahrzeugen implementiert werden.


EINLEITUNG

1-7

Die Simulation des Luftverkehrs im betrachteten Luftraum geschieht durch Auslesen einer Datenbank, in der eine reduzierte Anzahl repräsentativer Flugpläne des verkehrsreichsten Ta-ges des Jahres 1993, dem 17. September, abgelegt sind1. Die Generierung des Verkehrs wird am ILR durch das BMBF – Projekt "Profile Negotiation Manager" übernommen und nennt sich GATS (Generic Air Traffic Simulation).

Für eine realistische Simulation ist eine alleinige Animation der Flugprofile, so wie sie in der Datenbank abgelegt sind, nicht ausreichend. Aufgrund der Interaktionen der Fluglotsen muß eine Änderung jeder einzelnen Trajektorie zu jedem Zeitpunkt möglich sein. Praktisch gese-hen bedeutet dies, daß es jemanden geben muß, der die Anweisungen, die die Lotsen den Pilo-ten geben, an das Simulationssystem weitergibt. Diese Aufgabe übernimmt in der Simulation der Forschergruppe ein Pseudo – Pilot, der über eine simulierte Sprechfunkverbindung mit den Lotsen in Verbindung steht, deren Anweisungen bestätigt und die entsprechenden Modi-fikationen über eine Bedienoberfläche eingibt. Der von TP 1 entwickelte Pseudo – Pilotenar-beitsplatz wurde während der laufenden Bewilligungsphase vollständig implementiert und wird in Kapitel 4.5 ausführlich beschrieben.

Der Stand der bis zum gegenwärtigen Zeitpunkt entwickelten Systeme ist folgender:

SIMCO

SIMCO ist der entwickelte Sektorlotsenarbeitsplatz. Die bis heute verfügbaren Funktionalitä-ten sind in diesem Zwischenbericht ausführlich dokumentiert. Hier besteht an einigen Stellen noch Bedarf zur Nachbearbeitung. Beispielsweise arbeitet die Einsortierung der elektroni-schen Flugplanstreifen in das Strip Window noch nicht fehlerfrei. Weiterhin sind die genauen Zeitpunkte der Unterbrechungen der Simulation zur Lotsenbefragung noch in das System zu integrieren. Dies kann jedoch erst geschehen, wenn die Konstruktion der Verkehrsszenarien durch das jetzige Teilprojekt 4 der Forschergruppe abgeschlossen ist, da diese Zeitpunkte hiervon unmittelbar abhängen. Eine weitere Aufgabe, deren Bearbeitung noch erforderlich ist, besteht in der Vervollständigung des durch TP 4 spezifizierten Inhalts der Protokolldateien, die während der Simulationsläufe automatisch erstellt werden.

SIMCO wird bis Ende dieses Antragszeitraums komplett fertiggestellt werden, um im kom-menden Bewilligungszeitraum nur noch geringfügige Adaptionen vornehmen zu müssen, die aus den Erfordernissen der Experimente resultieren. Bis zum Ende des laufenden Bewilli-gungszeitraum müssen noch die erforderlichen Funktionalitäten zur Kommunikation der Sek-torlotsen untereinander, zur Kommunikation des SIMCO mit dem Multi–Sektor–Planer (Sze-

1 Im Rahmen dieses Vorhabens wurden von Teilprojekt 1 insgesamt 3 Datensätze (Maastricht, ZKSD, Karlsruhe) mit allen bei der DFS aufgegeben Flugplänen des 5. September 1997 beschafft. Diese Daten sind jedoch in einem derart speziellen Format abgelegt, daß ein Auslesen ohne vorherige Aufbereitung ohne Weiteres nicht möglich ist. Aus personellen Gründen war diese Aufbereitung bisher nicht möglich. Ein entsprechender "Schlüssel" zur Dekodierung der Daten durfte der TU aus urheberrechtlichen Gründen nicht übermittelt werden.


EINLEITUNG

1-8

nario 1) sowie zur Übermittlung von Flugsicherungsanweisungen (Szenario 2) per Data Link entwickelt werden.

SIMFLOW

SIMFLOW ist der Arbeitsplatz des Multi–Sektor–Planers. Aufgrund der oben beschriebenen Vorgehensweise der unmittelbaren Entwicklung des Systems unter UNIX konnte dieser Ar-beitsplatz bisher nur in einer Basisversion realisiert werden. Die graphische Benutzerschnitt-stelle mit ihrer wichtigsten Funktion zur Visualisierung des geplant – prognostizierten Ver-kehrsgeschehens ist umgesetzt worden (siehe dazu auch 4.4.2). Die Portierung des Konfliktlö-sungmoduls LOTEC ist ebenfalls erfolgt. Zum gegenwärtigen Zeitpunkt ist dagegen die An-zeige der von LOTEC gefundenen Konflikte und deren Lösung noch nicht implementiert. Auch die Schnittstellen zur Kommunikation mit der Bordseite und mit SIMCO müssen noch programmiert werden.

PSEUDO – PILOT

Die Entwicklung des Pseudo – Piloten – Arbeitsplatzes ist abgeschlossen. Bei sich ergebenden Unzulänglichkeiten während der Simulationsläufe besteht jedoch die Notwendigkeit zur Fehlerbeseitigung.

1.2 Einbindung im Rahmen der Forschergruppe

Die Aufgabenbereiche des Teilprojektes 1 sind in ganz besonderem Maße eng mit den übrigen Teilprojekten der Forschergruppe verknüpft: bei der Gestaltung der Lotsenarbeitsplätze ist nahezu zu jedem anderen Teilprojekt eine direkte Schnittstelle vorhanden, da hier im wesent-lichen die Abbildung der entwickelten Simulation erfolgt und das konstruierte System somit greifbar wird.

Neben der Einspeisung eines umgebenden Verkehrs, der exakt auf die Erfordernisse der hu-manwissenschaftlichen Untersuchungen abgestimmt ist, müssen die Positions- und Flugplan-daten der am Institut für Luft- und Raumfahrt ansässigen Scientific Research Facility (SRF) verarbeitet werden. Diese Einrichtung ist ein softwaretechnisches Abbild der modernen Bord-seite (Flight Management System des A340/330) und wird vom Teilprojekt 2 um die Funktio-nen zur Flugplanverhandlung erweitert.

Während die Einspeisung der Positionsdaten des Luftverkehrs für das Radarbild über ein si-muliertes Sekundärradar erfolgt, geschieht der Austausch von Flugplänen zwischen der Bord- und der Bodenseite über ein von Teilprojekt 3 entwickeltes Modul, das die Übertragungscha-rakteristiken eines Mode-S-Datenlinks nachbildet.

Die Schnittstelle zu den humanwissenschaftlichen Teilprojekten ist sowohl technischer als auch konzeptioneller Art, da die Untersuchung kognitiver Aspekte der Fluglotsentätigkeit so-wohl über die Auswertung von Experimenten mit Lotsen, als auch durch Anbindung eines im Rechner implementierten Modells der Fluglotsentätigkeit (MoFL) an den von Teilprojekt 1


EINLEITUNG

1-9

entwickelten Sektorlotsenarbeitsplatz geschieht. Zur Auswertung der Experimente ist die Im-plementierung zahlreicher Dokumentationsfunktionen durchzuführen. Diese werden von Teil-projekt 4 spezifiziert. Es handelt sich hierbei um Funktionen zur Befragung der Operateure während der laufenden Simulation, zur Zeitmessung bei deren Beantwortung, zur Kaschie-rungstechnik bestimmter Parameter sowie zur Erstellung detaillierter Protokolldateien.

Desweiteren soll das Modell MoFL in der Lage sein selbst als fiktiver Lotse in das Verkehrs-geschehen einzugreifen. Hierfür ist die Programmierung der Schnittstelle auf der Simco-Seite notwendig, da der MoFL bereits in dem DFG – Forschungsprojekt Ey 4/16-2 entwickelt wur-de und zu Beginn der Förderung der Forschergruppe bereits existierte.

Das Teilprojekt 5 erörtert im wesentlichen den Einfluß des Automatisierungsgrades auf die Repräsentation des Flugverkehrs durch den Fluglotsen. Grundlage für dessen Arbeit bilden daher die von Teilprojekt 1 realisierten Assistenzsysteme zur Konflikterkennung und –lösung sowie zur digitalisierten Kommunikation des Multi-Sektor-Planers mit seiner Umwelt.

1.3 Mitarbeiter

Im Teilprojekt 1 waren tätig:

Dipl.-Ing. Niels-H. Stark wissenschaftlicher Mitarbeiter 20 Monate

Cand.-Ing Thorsten Jeschke stud. Mitarbeiter (techn. Informatik) 20 Monate

Im Teilprojekt 1 erstellte Qualifikationsarbeiten:

Cand.-Ing. René Sutorius Diplomarbeit (Luft- und Raumfahrt)

1.4 Abweichungen vom Antrag an die DFG

Die Zielsetzung des Teilprojekt 1 bleibt weiterhin in der Entwicklung und Evaluation boden-seitiger, auf den kooperativen Planungsprozeß eines zukünftigen Air Traffic Management ab-gestimmter (Betriebs-) Verfahren/Algorithmen bestehen. Grundlage hierfür ist auch künftig die 4D-Profilprädiktion durch die Flugsicherung und darauf aufbauend die Konflikterken-nung, -klassifizierung und -lösung.

Im Hinblick auf den angestrebten Planungshorizont von 60 Minuten und unter Beachtung lau-fender nationaler und internationaler Projekte, werden von vornherein die sektorübergreifende Konfliktlösung und Flugprofilerstellung wesentliche Elemente im bodenseitigen Planungspro-zeß darstellen.

Abweichend von der angestrebten Untersuchung aller Flug- und Rollphasen war innerhalb des ersten Bewilligungszeitraumes vorerst nur der EnRoute-Bereich Gegenstand der Betrachtung. Hierfür wurde ein Lotsenarbeitsplatz für die Sektorkontrolle unter Beachtung der ODID-Spezifikationen unter Verwendung der ODS Toolbox, einer gemäß Antrag angeschafften


STAND DER FORSCHUNG

1-10

Entwicklungsumgebung für ODS-Anwendungen (Operational Display Systems), entwickelt. Die Funktionalität dieser Mensch-Maschine-Schnittstelle zeichnet sich gegenüber heutigen Lotsenpulten durch ihre zusätzlichen Komponenten zur Flugplanverhandlung und zum digita-len Datenaustausch Bord/Boden und Boden/Boden aus.

Parallel zur Entwicklung des Simulationssystems wurden die teilweise bereits vorhandenen Algorithmen zur 4D-Profilprädiktion und zum Konfliktmanagement auf die UNIX – Ebene portiert. Unter Berücksichtigung der Erkenntnisse, die sich aus den ersten Simulationen erge-ben, müssen diese noch erweitert werden.

Die Komponente der Multi–Sektor–Planung sollte in dieser Phase durch eine am Institut vor-handene Flow Management Position (ASD - Aircraft Situation Display) repräsentiert werden. Das ASD sollte dazu an das entwickelte Simulationssystem zur direkten Kommunikation mit dem geschaffenen Sektorlotsenarbeitsplatz angeschlossen werden. Zur Vermeidung von Dop-pelarbeit und aus Kompatibilitätsgünden zum Simulationssystem wurde jedoch von vornher-ein damit begonnen, diesen Lotsenarbeitsplatz mit Hilfe der ODS Toolbox zu entwickeln.

Zusätzlich zu den im Antrag formulierten Arbeiten wurde die technische Anbindung des men-talen Modells der Fluglotsentätigkeit (MoFL) an den entwickelten Lotsenarbeitsplatz und der notwendige Pseudo – Piloten – Arbeitsplatz realisiert.

Im folgenden Antragszeitraum wird die Multi–Sektor–Funktionalität in den Vordergrund rük-ken. Die zuvor entwickelte Bedienoberfläche stellt dann die Voraussetzung für die Flugplan-verhandlung zwischen Multi–Sektor–Planer und Sektorlotse dar.

2 STAND DER FORSCHUNG In den verkehrlichen Ballungsgebieten Europas wird im Hinblick auf die prognostizierten Verkehrssteigerungen der Einsatz derzeitiger Technologie und Verfahren allein nicht mehr ausreichen. Neben den laufenden Bemühungen zur Optimierung der vorhandenen Luftraum-struktur (Sektorgröße, Routen, flexible Luftraumnutzung) ist überdies die Entwicklung neuar-tiger Technologien und Flugsicherungsverfahren notwendig (EUROCONTROL, 1994b). Ei-nen vielversprechenden Ansatz zur Erhöhung der operationellen Produktivität des Gesamtsy-stems Luftverkehr, stellt die Einführung der Multi-Sektor-Planung, einer sektorübergreifenden Planungsinstanz dar (EUROCONTROL, 1997b).

Im heutigen Luftverkehrssystem klafft eine Planungslücke zwischen dem strategischen Air Traffic Flow Management (ATFM) und der taktischen Planung des Planungslotsen eines Ra-darsektors. Während das ATFM Steuerungsmaßnahmen mit einer Vorlaufzeit im Bereich von Stunden bevor das Luftfahrzeug tatsächlich in den Sektor einfliegt vorsieht, steht dem Lotsen-team des jeweiligen Luftverkehrs – Kontrollsektors lediglich ein Planungshorizont von ca. 20 Minuten mit wenig verläßlichen Daten zur Verfügung. Ein Multi–Sektor–Planer kann an die-ser Stelle mittelfristige, sektorübergreifende Steuerungsmaßnahmen anbieten, die genau auf


STAND DER FORSCHUNG

1-11

die jeweilige Komplexität der Verkehrssituation zugeschnitten sind (EUROCONTROL, 1997b).

Das Potential einer solchen Planungsinstanz, zusätzliche Kapazitäten freizusetzen, ist mittlerweile unumstritten. Es ergeben sich jedoch eine große Anzahl auftretender Fragestellungen bezüglich der notwendigen Abstimmungsvorgänge und der Zuweisung der Verantwortlichkeiten zwischen den beteiligten Instanzen (Multi–Sektor–Planer, Sektorlotse, Luftfahrzeug).

• Wieviele Sektoren kann eine „Multisector – Planning – Area“ umfassen ?

• Wie können „Multisector – Planning – Areas“ untereinander koordiniert werden ?

• Bei welcher Instanz liegt zu welchem Zeitpunkt die Verantwortung für eine Maß-nahme ?

• Welche Aufgaben hat der Multi–Sektor–Planer genau ? Soll er alle Konflikte lö-sen oder kann er sich die Konflikte selbst nach seiner persönlichen Einschätzung auswählen ?

• Welches ist die optimale Vorausschau – Zeit (LAT = Look Ahead Time)?

• Wie lange dauern die Kommunikationsprozesse bis zur Einigung auf eine Maß-nahme an ?

• Wie kann das System so kalibriert werden, daß möglichst viele Abstimmungen er-folgreich enden ?

• Wie groß darf die maximale Abweichung der Luftfahrzeugposition vom verein-barten Flugprofil sein, bevor das System Alarm schlägt, sein ?

• Wie werden Luftfahrzeuge, deren Ausrüstung nicht dem benötigten Standard ent-spricht, in die Planung miteinbezogen ?

• Programmierung von Offsets (Standard Sets of Tactical Operational Solutions)

Ein bedeutendes Forschungsprogramm Europäischer Flugsicherungsinstitutionen, das sich mit Konzepten für ein zukünftiges Luftverkehrsmanagement beschäftigt, ist das "Programme for Harmonised ATM Research in EUROCONTROL" (PHARE). Im PHARE – Programm kommt der Aktualität der verfügbaren Information eine zentrale Bedeutung zu: es muß sicher-gestellt werden, daß zu jedem Zeitpunkt an Bord und am Boden identische, aktuelle Informa-tionen vorliegen (EUROCONTROL, 1997a) und diese an Bord der Luftfahrzeuge in den Flight Management Systemen zur Unterstützung der Piloten genutzt werden sowie am Boden über geeignete Assistenzsysteme (Konfliktmanagement) die Lotsen unterstützen. Ausgereifte Kommunikationsmedien sollen den beiderseitigen Austausch von Informationen gewährlei-sten.


STAND DER FORSCHUNG

1-12

Die Entwicklung der technischen Systeme und Funktionen fand in mehreren Iterationsschrit-ten statt, die von drei größeren Demonstrationen (PD/1, PD/2, PD/3) begleitet wurden. Wäh-rend sich PD/1 und PD/2 auf Untersuchungen der EnRoute – Problematik konzentrierten, wird sich die "PHARE – Demonstration 3" im Laufe dieses Jahres verstärkt mit der Thematik der Multi–Sektor–Planung befassen (EUROCONTROL, 1994b, 1995).

Das PD/3 – Konzept sieht jedoch keine direkte Flugplanverhandlung zwischen dem Multi–Sektor–Planer und dem taktischen Planungslotsen eines Sektors vor, sondern es herrscht eine zeitliche Aufteilung der Planungsautorität zwischen beiden. Dennoch notwendige Abstim-mungsmaßnahmen finden über "co-ordination proposals" statt. Innerhalb eines ersten Simula-tionslaufs ergaben sich wichtige Fragestellungen, die derzeit noch unbeantwortet sind. Diese betreffen beispielsweise divergierende Planungsaktivitäten bei sich überlagernden Zuständig-keiten, Abstimmungsmöglichkeiten benachbarter Multi–Sektor–Planer untereinander oder die Integration der „nicht-Data Link fähige“–Luftfahrzeuge.

Die Einführung satellitengestützter Überwachung und Kommunikation wird von der interna-tionalen Zivilluftfahrtbehörde ICAO im Rahmen ihres CNS/ATM – Konzeptes favorisiert und gefördert. Ein Teil dieses Konzeptes ist die "Automatic Dependent Surveillance" (ADS), de-ren Ziel darin besteht, die in den bordseitigen Navigationssystemen verfügbaren Daten über Flugzeugposition, den geplanten Flugweg und andere relevante Informationen auch in den ozeanischen Gebieten und in Gebieten ohne Radarüberdeckung durch automatische Übertra-gung per Data Link verfügbar zu machen.

Die nationale Flugsicherungsbehörde Großbritanniens, die National Air Traffic Services (NATS), steht mit ihren "ADS–Trials", die bereits während kommerzieller Linienflüge statt-finden, an erster Stelle der Beiträge zum CNS/ATM – Konzept der ICAO. An den Versuchen nimmt eine Boeing 747-400 teil, deren Daten aus dem FMS über eine ADS–Einheit an Bord extrahiert und via Satellitenkommunikation an die Bodenstation der NATS gesendet werden. Auf diese Art weiß der Lotse am Boden genau, wie das FMS zur Führung des Luftfahrzeugs programmiert wurde. Der Lotse hat die Möglichkeit, sich zusätzlich zu regelmäßigen Positi-onsmeldungen Warnungen für den Fall ausgeben zu lassen, daß einer der von der Flugsiche-rung angewiesenen Werte nicht eingehalten wird. Abgesehen von den rein technischen Aspek-ten erfolgt bei NATS auch eine Evaluation von ADS in operationeller Hinsicht. Hierfür wurde eigens ein Simulator entwickelt und installiert, der die Entwicklung neuer ATM–Techniken unter Nutzung von ADS erlaubt. Die Simulationen laufen parallel zu den Live–Versuchen, so daß deren Ergebnisse sofort in diese Simulationen einfließen können.

Im Rahmen der Data Link – Forschungsaktivitäten der amerikanischen Federal Aviation Ad-ministration (FAA) ist das Projekt FANG ( Future Air Traffic Management / Next Generati-on) zu nennen. Dieses in enger Zusammenarbeit mit der Industrie geführte Projekt befaßt sich mit der Integration der Computersysteme der Luftfahrzeuge, der Fluggesellschaften und der Flugsicherung auf Basis von Data Link. Es werden hier Anwendungen für den Flughafennah-


KONZEPTION

1-13

bereich und den Streckenflug untersucht, die sich im EnRoute – Bereich auf den automati-schen Frequenzwechsel vor Sektoreinflug, den Uplink von Korrekturmaßnahmen bei Abwei-chung vom vorgesehenen Flugprofil sowie auf die Übermittlung von Steueranweisungen nach Art und Zeitpunkt bei Überholvorgängen erstrecken. Der Einsatz kooperativer Flugplanver-handlung und die damit verbundene Mensch – Maschine – Interaktion wird jedoch nicht er-forscht.

3 KONZEPTION Der Entwurf der Forschergruppe für ein kooperatives Air Traffic Management wurde unter Einbeziehung der Trends internationaler Forschungsprojekte und den Erfahrungen aus voran-gegangenen Forschungsprojekten der TU Berlin entwickelt. Hierbei liegt das Hauptgewicht auf der kooperativen Komponente. Aus diesem Grund sieht dieses Konzept ein Höchstmaß an Integration der FMS – Funktionalitäten und der bordseitigen Intentionen in die Planungen der bodengebundenen Flugsicherung vor. Die Cockpit Crew wird über das FMS direkt in den Prozeß der Flugplanverhandlung einbezogen. Damit sind am Abstimmungsprozeß drei unter-schiedliche Instanzen, nämlich das Luftfahrzeug, ein Multi–Sektor–Planer und die Sektorlot-sen beteiligt, von denen jede Instanz das Recht zur Ablehnung von vorgeschlagenen Flugpro-filen besitzt.

Für die Flugplanverhandlung wurde ein detaillierter Verhandlungsablauf festgelegt, in dem alle Möglichkeiten der Annahme oder Ablehnung von Vorschlägen berücksichtigt sind (vgl. teilprojektübergreifender Teil des Zwischenberichtes). Grundlage der Flugplanverhandlung ist das Multi–Sektor–Planungs-Konzept, das die sektorübergreifende Konflikterkennung und –lösung für langfristige Planungskonflikte von zentraler Stelle aus zur Entlastung der Lotsen-teams der Kontrollsektoren vorsieht.

Der Aufbau der bodenseitig entwickelten Komponenten ist maßgeblich durch das genannte Kommunikationskonzept und die unterschiedlichen ATM – Szenarien vorgegeben. Weiterhin ist die Implementierung bestimmter Funktionalitäten der bodenseitigen Mensch – Maschine – Schnittstellen durch die Art der Experimente mit Lotsen determiniert.

In einem ersten Szenario (Szenario 0) soll der Ist – Zustand der heutigen Flugsicherung simu-liert werden. Die Instanz des Multi–Sektor–Planers existiert in dieser Phase nicht. Als Refe-renz für die Erstellung des Sektorlotsenarbeitsplatzes wurde das DERD-XL – System der Re-gionalkontrollstelle Berlin – Tempelhof gewählt, da dieses bereits für das Programmsystem EnCoRe (DFG – Projekt Flugsicherung als Mensch – Maschine – System, En-Route Control-ler's Representation ENCORE) die Grundlage darstellte. Außerdem legt das in diesem Zusam-menhang entstandene Modell des Fluglotsen MoFL die in DERD-XL verfügbaren Funktiona-litäten zugrunde. Zusätzlich verfügen jedoch die Lotsen am SIMCO über einen zweiten Bild-schirm mit elektronischen Flugplanstreifen. Auch dies ist eine Spezifikation, die durch En-CoRe vorgegeben ist.


IMPLEMENTIERUNG

1-14

Bei der Entwicklung der Oberfläche des SIMCO wurden die Empfehlungen der ODID – Gruppe der EUROCONTROL eingearbeitet (EUROCONTROL, 1994a). Der Sektorlotsenar-beitsplatz verfügt folglich über die wesentlichen Funktionalitäten des Tempelhofer Systems, die dem Lotsen über die Oberfläche eines ODID – Arbeitsplatzes zur Verfügung gestellt wer-den. Der Sektorlotsenarbeitsplatz wird für das Szenario 1 mit den Funktionen zur Flugplan-verhandlung und für das Szenario 2 mit Assistenzfunktionen zur Übermittlung von kurzfristi-gen Anweisungen via Data Link ausgestattet.

Die Gestaltung des Arbeitsplatzes des Multi–Sektor–Planers (SIMFLOW) ist vom Umfang ihrer Funktionalitäten her an das Kommunikationskonzept gebunden. Dieses sieht Kommuni-kationsschnittstellen zu Sektorlotsen der „Multisector – Planning – Area“ (MPA) und zu den an der Flugplanverhandlung teilnehmenden Luftfahrzeugen vor. Ferner muß die Oberfläche Funktionalitäten aufweisen, die die übersichtliche Darstellung mehrerer Kontrollsektoren zu-läßt. Aus diesem Grunde kann der Lotse hier frei den Bildausschnitt einstellen und Zusatzfen-ster bei Bedarf ein- und ausblenden sowie diese dort positionieren, wo sie keine relevanten Informationen verdecken. Gemäß seiner Aufgabe, die zukünftige Verkehrssituation zu beur-teilen, soll der Lotse die Möglichkeit haben, sich den prognostizierten Verkehr darstellen zu lassen. Desweiteren sollen über ein Assistenzmodul Planungskonflikte automatisch erkannt und auf Befehl zur Anzeige gebracht werden. Die für jeden Konflikt generierten Lösungsvor-schläge sind die Basis für den nachfolgenden Verhandlungsprozeß. Diese Vorschläge müssen demnach aufbereitet und an die betreffenden Stellen (Sektorlotse, Luftfahrzeug) per Data Link übertragen werden.

4 IMPLEMENTIERUNG

4.1 Die ODS Toolbox

Aufgrund der großen Dynamik der sich ändernden Anforderungen an die Funktionalitäten bei der Entwicklung von Flugsicherungssystemen verschwinden die speziell auf einen Kunden zugeschnittenen Systementwicklungen immer mehr. Stattdessen kommen zunehmend soge-nannte COTS – Produkte (Commercial Off – The – Shelf) zum Einsatz, die auf Standard – Betriebssystemen (Unix/Linux/WindowsNT) installierbar sind und sich durch eine offene, er-weiterbare Systemarchitektur auszeichnen.

Als typisches COTS – Produkt entspricht die ODS Toolbox vollkommen den ODID/CWP – Richtlinien der EUROCONTROL (EUROCONTROL, 1994a) und ist mittlerweile zum Stan-dard neuer Europäischer ATM – Projekte geworden. Es handelt sich hierbei um ein spezielles Programmierwerkzeug für die softwaretechnische Entwicklung von operationellen Anzeigesy-stemen (ODS = Operational Display Systems) zur Visualisierung dynamischer Objekte, auf die über die grafische Benutzerschnittstelle interaktiv zugegriffen werden kann.


IMPLEMENTIERUNG

1-15

Das Programm erlaubt die Erstellung von Applikation über die Vorgehensweise des Rapid Prototyping. Das Rapid Prototyping erlaubt ein schnelles Erstellen lauffähiger Applikationen, so daß diese sofort getestet und laufend verbessert werden können. Im Folgenden sollen knapp einige der wichtigsten Funktionen, die dieses Rapid Prototyping ermöglichen, vorgestellt wer-den.

Ausgehend vom "Interface Editor System" (siehe Abbildung 1) ist das Erzeugen von Fenstern, Menüs, Tabellen, Dialogboxen, Sammelboxen mit Druckknöpfen und Schaltern möglich. Über diese Knöpfe können Funktionen entweder direkt aus der C – Ebene heraus aufgerufen werden, oder es können kürzere Algorithmen aus der "Rule – Language", einer Toolbox – in-ternen Regelsprache, zur Ausführung bestimmter Steueraktionen aktiviert werden.

Abbildung 1: Interface Editor System der ODS Toolbox

Die Konfiguration von aufwendigen Radarbilddarstellungen mit der luftraumspezifischen In-frastruktur ist über den "Map Editor" möglich. Dieser Editor stellt eine spezielle Schnittstelle zum Einlesen von Daten im EUROCONTROL – Format (RASCAL) oder Jeppessen – Daten zur Verfügung, so daß die Genauigkeit der Kartendarstellung auch bei nicht – professionellen Anwendungen dem internationalen Standard entspricht. Über die Zuordnung bestimmter Kar-tenelemente zu fest definierten Farbebenen ("Layern") können diese Elemente auf einfache Weise aktiviert oder deaktiviert und damit sichtbar oder unsichtbar werden.

Die ODS Toolbox bietet die Möglichkeit der Fernbedienung anderer Rechner über einen Client – Server – Prozeß. Für den Operateur bedeutet dies, daß seine Eingabemedien (Maus, Tastatur) bei Erreichen einer benutzerdefinierten Bedingung (wie etwa dem Überstreichen be-stimmter Bildschirmbereiche mit dem Cursor) in das Display des Remote – Rechners über-wechseln und dort Druckknöpfe ansteuern oder die Eingabe von Daten über die Tastatur vor-nehmen können. Dieses Merkmal, "Interoperability" genannt, ist bei Flugsicherungsanwen-dungen besonders wertvoll, wenn die Darstellung der elektronischen Flugplanstreifen getrennt von der Radarbilddarstellung erfolgen soll, die Bedienung jedoch über eine Tastatur und eine Maus gewünscht ist (vgl. Abbildung 2).


IMPLEMENTIERUNG

1-16

Abbildung 2: Interoperability

Über das Modul "Recording & Replay" ist die Aufzeichnung aller Interaktionen des Opera-teurs während seiner Arbeit mit der erstellten Applikation möglich. Diese Aufzeichnung kann zu einem späteren Zeitpunkt zur Analyse wiedergegeben werden. Unterbrechungen und der Quereinstieg an anderer Stelle ist jederzeit möglich. Zusätzlich ist die Erstellung von "Logfi-les" zur schriftlichen Dokumentation der Simulationsläufe möglich.

4.2 Aufbau des Simulationssystems

Abbildung 3 veranschaulicht die Komponenten, die am Institut für Luft- und Raumfahrt das Luftverkehrssimulationssystem konstituieren. Es soll an dieser Stelle nur eine Übersicht über die verfügbaren Soft- und Hardwarekomponenten und deren Vernetzung in Form dieser Ab-bildung gegeben werden, um die im Folgenden beschriebenen bodenseitigen Module des Sy-stems besser in den Gesamtkontext einordnen zu können. Eine ausführliche Beschreibung des Simulationssystems befindet sich im allgemeinen Teil dieses Zwischenberichtes.

Abbildung 3: Komponenten des Simulationssystems am ILR

4.3 Der Sektorlotsenarbeitsplatz SIMCO

Der innerhalb des Simulationssystems realisierte Arbeitsplatz für den Sektorlotsen wird SIM-CO ("Sophisticated Interface for Monitoring, Controlling & Organizing") genannt. Dies ent-

A330/A340 FFS Verkehrssimulation DC-9 Trainer

DIS

SSR Mode S

Bodennetz

SIMCOSIMFLOW Zentrale Daten-


IMPLEMENTIERUNG

1-17

spricht seiner Zielsetzung, durch eine übersichtliche Luftraumdarstellung die Überwachung der Verkehrssituation und eine taktische Planung zu ermöglichen.

4.3.1 Datenquellen

• Luftraumkarte:

Die Darstellung der Luftraumstruktur erfordert die Verfügbarkeit von Daten über Flughä-fen, Navigationseinrichtungen, Luftstraßen und deren Kreuzungspunkte, Pflichtmelde-punkte, Grenzen von Flight- und Upper Information Regions (FIR, UIR), Kontrollzonen, Gefahren- und Verbotszonen sowie von den DFS – spezifischen Grenzen der Sektorkon-trolle. Basis für diese Infrastrukturdaten bildet eine Europa – Datenbank der Firma Jeppes-sen, die der Forschergruppe zu diesem Zwecke zur Verfügung gestellt wurde. Die Exakt-heit der Daten entspricht somit dem internationalen Standard. Da die ODS-Toolbox über eine spezielle Schnittstelle zum Import von Jeppessen – Daten verfügt, wurde diese Da-tenquelle gewählt.

Die Darstellung der Luftraumkarte und des Luftverkehrs erfolgt über eine stereografische Projektion mit Berührpunkt und Ursprung bei 8° 30' 00" östlicher Länge und 49° 30' 00" nördlicher Breite. Als Koordinatensystem kommt ein kartesisches System mit der Einheit Kilometer zum Einsatz. Diese Werte wurden gewählt, um die in diesem Format am Institut für Luft- und Raumfahrt vorliegenden Flugplandateien von Anfang an nutzen zu können.

Die Daten der Grenzen der Radarsektoren des deutschen Luftraums wurden von der Deut-schen Flugsicherung GmbH zur Verfügung gestellt. Die Sektorgrenzen liegen als Poly-gonzüge vor, deren Eckpunkte als geographische Koordinaten angegeben sind (vgl. Abbildung 4). Neben dem Namen des Sektors (hier "NR 1") befindet sich die Angabe über dessen vertikale Ausdehnung (hier "CTA – FL245"), darunter folgen die LAT– /LON– Koordinaten der einzelnen Punkte des Polygonzuges. Diese Daten mußten jedoch manuell in die Kartenprojektion eingegeben werden.


IMPLEMENTIERUNG

1-18

Abbildung 4: Sektordatensätze der DFS

• Radardaten

Die Verkehrsinformationen werden von einem Radar – Programm des Simulationssystems in Form von UDP – Paketen über das Netzwerk zum Lotsenarbeitsplatz SIMCO geschickt. In-nerhalb eines Programmzyklus fragt SIMCO mehrmals pro Sekunde den vereinbarten Port ab und liest die ankommenden Daten ein, sofern diese dort anliegen. Zur Kommunikation zwi-schen dem Radar – Simulationsprogramm und SIMCO ist es einerseits notwendig, daß deren Portadressen übereinstimmen, anderseits muß das Radar – Simulationsprogramm mit der Netzwerkadresse des Zielrechners, auf dem der SIMCO läuft, als Argument aufgerufen wer-den. Bei dieser Verbindungsart werden die Datenpakete vom Radar direkt zu der Adresse des Zielrechners gesendet, unabhängig davon, ob SIMCO empfangsbereit ist oder nicht.

Neue Datenpakete werden nur einmal gesendet, es besteht keine Kontrolle über deren erfolg-reiche Übermittlung an den Zielrechner. Eventuell verlorengegangene Pakete haben jedoch keinen Einfluß auf den störungsfreien Programmablauf. Liegen kurzfristig keine Daten am Port an, so arbeitet SIMCO dessenungeachtet ohne Unterbrechung weiter, da das Vorhanden-sein der Informationen kein notwendiges Kriterium zur Programmfortsetzung darstellt. Das Hauptaugenmerk dieser Übertragungsart gilt hier einer möglichst verzögerungsfreien Über-mittlung der Daten.

Der Aufbau der UDP-Pakete für den SIMCO ist folgender: am Anfang steht die Paket – ID, die zur eindeutigen Identifizierung der relevanten Pakete dient. Daran anschließend folgen das Callsign, der SSR-Code, die Position in geographischen Koordinaten, die Flughöhe in Fuß und abschließend die Simulationszeit, die zur Synchronisation des Lotsenarbeitsplatz mit dem Traffic dient (vgl. Abbildung 5).


IMPLEMENTIERUNG

1-19

Abbildung 5: Aufbau eines UDP-Paketes für SIMCO

Innerhalb des SIMCO – Programms werden aus diesen Informationen Flugzeugobjekte er-zeugt, die sich aus einem ODS – spezifischen und einem C – spezifischen Teil zusammenset-zen. Abbildung 6 auf der nächsten Seite zeigt die Struktur eines solchen Flugzeugobjektes.

Zu jedem Luftfahrzeug existieren Informationen, die nicht in den UDP-Paketen enthalten sind, die zur vollständigen Flugzieldarstellung jedoch benötigt werden. Diese können entwe-der dynamisch berechnet oder aus der zum jeweiligen Flug zugehörigen Flugplandatei einge-lesen werden. Sich ständig ändernde Parameter des Flugprofils werden so umgehend der Be-nutzeroberfläche zugeführt. Zu diesen Parametern gehören die Steig- und Sinkgeschwindig-keit, die Geschwindigkeit und der Kurs über Grund, die Umrechnung der lateralen und longi-tudinalen Koordinaten in die Kartenprojektion des SIMCO – Radarbildes sowie einige spezi-fische Variablen, die der Kommunikation mit dem modellierten Fluglotsen MoFL dienen (siehe dazu Kapitel 4.3.7).

Paket-ID Callsign SSR-Code Position-Lateral

Position-Longitudinal Altitude Simulations-

Zeit


IMPLEMENTIERUNG

1-20

Abbildung 6: Programmtechnische Struktur eines Luftfahrzeugobjektes

Name Typ Herkunft Objekttyp BeschreibungCallsign char [8] UDP-Paket ODS

Ground-Speed float

berechnet aus ∆Position pro

∆Zeit ODS

Vertical-Speed float

berechnet aus ∆Höhe pro

∆Zeit ODSSSR-Code char [6] UDP-Paket ODS

X-Position intberechnet aus

Position-Lateral ODS Projektionspunkt-Lat: 49´30´´00´´

Y-Position int

berechnet aus Position-

Longitudinal ODS Projektionspunkt-Lon: 8´30´´00´´Heading float berechnet ODSAltitude float UDP-Paket ODS

Departure char [6] Flugplan ODSDestination char [6] Flugplan ODS

Aircraft-Type char [6] Flugplan ODSEntry-Point char [6] Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegt

ETO-Entry-Point int Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegtSroute-Point char [6] Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegt.

ETO-Sroute-Point int Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegtExit-Point char [6] Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegt

ETO-Exit-Point int Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegtCleared-FlightLevel int Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegt

Requested-FlightLevel int Flugplan ODS wenn das Luftfahrzeug durch WR2 fliegt

Old Time int UDP-Paket CSimualtionszeit für die letzte Aktualisierung der Daten

Real Old Time int gesetzt CEchtzeit für die letzte Aktualisierung der Daten

Old Flight Lat float gesetzt C letzte Position des LuftfahrzeugesOld Flight Lon float gesetzt C letzte Position des Luftfahrzeuges

Old Altitude float gesetzt C letzte Höhe des LuftfahrzeugesOld VS float gesetzt C letzte Ground-Speed des LuftfahrzeugesOld GS float gesetzt C letzte Vertical-Speed des Luftfahrzeuges

Flight_Transmit_to_Zmms int gesetzt C Flag für die Übertragung von Daten an MOFL

mofl x int berechnet CX-Koordinate des Luftfahrzeuges in Bezug auf die Bildschirmauflösung

mofl y int berechnet CY-Koordinate des Luftfahrzeuges in Bezug auf die Bildschirmauflösung

pred x int berechnet CX-Koordinate des Predictors des Luftfahrzeuges in Pixel

pred y int berechnet CY-Koordinate des Predictors des Luftfahrzeuges in Pixel

CDI int berechnet C Climb-Descent-Indicator (1,0,-1)


IMPLEMENTIERUNG

1-21

Für die Umrechnung der lateralen und longitudinalen Koordinaten in die X- und Y-Koordinaten der stereografischen Projektion ist die Definition eines Referenzpunktes notwen-dig. Für die Verkehrssimulation und die Luftraumkarte in SIMCO befindet sich dieser Refe-renzpunkt in der Nähe von Offenbach (N 49°30'00" / E 8°30'00").

Entsprechend der Umlaufzeit des simulierten Radarstrahls erfolgt eine Aktualisierung der Po-sitionsdaten und der übrigen Flugdaten alle vier Sekunden. Erhält ein Luftfahrzeugobjekt während drei Radarumläufen keine neuen Positionsdaten, so geht SIMCO davon aus, daß sich dieses Luftfahrzeug nicht mehr in der Verkehrssimulation befindet und löscht das entspre-chende Objekt aus dem Speicher. Das Flußdiagramm in Abbildung 7 verdeutlicht den Pro-grammablauf. Das Beenden der Simulationsumgebung ist per Mausklick über die grafische Oberfläche von SIMCO möglich. Dabei wird über "Prozeßhandling" direkt die in Abbildung 7 dargestellte Endloschleife verlassen.


IMPLEMENTIERUNG

1-22

Abbildung 7: Datenabfrage aus der Verkehrssimulation und Anbindung an MoFL

4.3.2 Das Radarbild

Abbildung 8 zeigt das Radarbild, so wie es dem Lotsen während seiner normalen Kontrolltä-tigkeit zur Verfügung steht.

LiegenSIMCO-

spezifische Traffic -Daten am UDP-

Socketan ?

Ja

Luftfahrzeugobjekt wirderzeugt und

Simulationszeit wirdgesetzt

Existiert das Luftfahrzeug

bereits ?Nein

Ja

Daten desLuftfahrzeugobjekteswerden aktualisiert

Nicht empfangeneDaten des

Luftfahrzeugobjekteswerden berechnet

Öffnen der TCP/IP-Verbindung zu MOFL,

wenn MOFLempfangsbereit

relevanteLuftfahrzeugobjektdaten

werden an MOFLgesendet

Besteht eineVerbindung zu

MOFL ?

Ja

Besteht eineVerbindung zuMOFL u. liegen

Anfragen am TCP-Socket an ?

Ja

Ermitteln der Daten undErgebnisse an MOFL

senden

Benutzereingaben,Bildschirmausgaben,

entsprechendeLuftfahrzeugobjekte

zerstören, ...

Nein

Nein

Nein


IMPLEMENTIERUNG

1-23

Abbildung 8: Radarbild des SIMCO

Bei der Gestaltung der Oberfläche mußten zahlreiche Randbedingungen berücksichtigt wer-den. So entsprechen die verfügbaren Funktionalitäten zur Radarbildsteuerung und zur Infor-mationsgewinnung im wesentlichen dem DERD-XL – System der Deutschen Flugsicherung GmbH, das sich in der Berliner Regionalkontrollstelle im Einsatz befindet. Dies ist erforder-lich, da das Modell der Fluglotsenleistungen MoFL des Teilprojektes 4 auf das im DFG – Pro-jekt "Flugsicherung als Mensch-Maschine-System" entwickelte EnCoRe-PluS – System zuge-schnitten ist, welches wiederum auf dem DERD-XL – Standard aufsetzt. Eine sinnvolle Eva-luierung des Rechnermodells MoFL in Zusammenarbeit mit Teilprojekt 1 ist daher nur durch eine konsequente Anlehnung an das Berliner Lotsensystem möglich.

Aufgrund der nicht vorhandenen Möglichkeit einer humanwissenschaftlichen Unterstützung bei der Erstellung der Benutzeroberfläche, wurde bei der Konzeption des Bildschirmaufbaus auf die im ODID IV – Bericht der EUROCONTROL (1994a) festgeschriebenen Standards zurückgegriffen. Einige Funktionen wurden auf die speziellen Erfordernisse des Simulations-systems der Forschergruppe angepaßt. Die Fortführung des ODID - Programms unter dem Namen "Human Machine Interface for EATCHIP Phase III" fand besonders bei der Farbge-bung Beachtung.


IMPLEMENTIERUNG

1-24

Die ODS-Toolbox bietet dem Benutzer einen großen Freiraum bei der Gestaltung der Karten-symbole. Ein Bitmap – Editor erlaubt das Erstellen völlig freier Formen. Aus diesem Grunde wurden die im Radarbild sichtbaren Elemente des Luftraums der Symbolik internationaler Luftfahrtkarten angepaßt. Wo dies nicht sinnvoll war (z. B. bei der Darstellung der Ausrich-tung der Landebahnen internationaler Verkehrsflughäfen), wurde auf den Standard des DERD-XL – Systems zurückgegriffen. Es folgt eine Übersicht über die verwendeten Karten-symbole:

Abbildung 9: Symbole der Kartendarstellung des Radarbildes

4.3.3 Funktionen zur Steuerung des Arbeitsplatzes

Funktionen zur allgemeinen Konfiguration des Bildschirms sind über die folgenden Buttons erreichbar:

Abbildung 10: Buttons zum Aufruf von Bildschirmfunktionen

Bei Aktivierung einer Funktion wird der zugehörige Button grün eingefärbt. Die oben darge-stellten Buttons werden im Folgenden von links nach rechts beschrieben:

• Kartenelemente: Der Lotse hat die Möglichkeit, nur die für ihn notwendigen Kartenele-mente darstellen zu lassen und die übrigen zu unterdrücken. Das Menü zur Einstellung dieser Elemente ist über den "MAP" – Button zu erreichen wird in folgender Abbildung dargestellt:

VOR – Funkfeuer

NDB – Funkfeuer

Terminal - Waypoint

Significant - Waypoint

Airport

Runway


IMPLEMENTIERUNG

1-25

Abbildung 11: Menübox zur Wahl der sichtbaren Kartenelemente

Die in dieser Abbildung aktivierten Elemente entsprechen der Standardeinstellung bei

Beginn der Simulation. Über die Buttons "All On" bzw. "All Off" können alle Elemente gleichzeitig aktiviert bzw. deaktiviert werden. Ferner besteht die Möglichkeit, Voreinstel-lungen zu speichern und wieder zu laden. Bei Druck auf den "Init Center" – Knopf wird der Bildschirm so eingestellt, daß der komplette Kontrollsektor sichtbar ist. So wird ein langwieriges Wiederherstellen der Bildschirmparameter nach Veränderungen des Bild-ausschnittes vermieden.

• Range – Bearing – Vector: dieser Vektor erlaubt die ständige Anzeige der Entfernung und der Richtung eines Punktes zu einem anderen. Diese Punkte können sowohl statischer als auch dynamischer Natur sein. Das heißt, es kann sowohl der sich ändernde Abstand und die Richtung eines Luftfahrzeuges zu einem Punkt oder zu einem anderen Luftfahr-zeug angezeigt werden. Nach Anwahl dieses Funktionsbuttons wählt der Lotse durch Mausklick auf die entsprechenden Kartenelemente die gewünschten Punkte. Zur Gewähr-leistung der Genauigkeit ist hierbei eine Funktion integriert, die bei Mausklick in die Nähe eines Objektes den Vektor automatisch in dessen Zentrum positioniert. Der Abstand wird in Nautischen Meilen, die Richtung als Kursangabe vom ersten angewählten Punkt zu dem zweiten angezeigt. Die folgende Abbildung zeigt beispielhaft einen solchen Range – Bea-ring – Vector:


IMPLEMENTIERUNG

1-26

Abbildung 12: Range – Bearing - Vector

• LAT / LON – Gitter: nach Anwahl dieses Buttons wird über das Radarbild ein Gitter aus Längen- und Breitengraden gelegt. Die Gitterlinien haben einen Abstand von 1°.

• Ein- / Ausblenden der Radarziele: mit diesem Button kann die Darstellung der Radar-ziele unterdrückt werden.

• Kompassrose: nach Anwahl dieser Funktion wird in der Mitte des Radarbildes eine Kurs-rose eingeblendet, die den Lotsen bei der Zuweisung von Kursen an die Luftfahrzeuge un-terstützt.

• Konfiguration des Etiketts:

Abbildung 13: Konfiguration des Etiketts

Hier kann der Lotse einstellen, welche Angaben das Etikett ("Label") neben dem Radar-ziel enthalten soll. Abbildung 13 zeigt das Konfigurationsmenü und darunter das zur ge-wählten Einstellung korrespondierende Label eines Radarziels.

Über "LABEL" kann das Etikett komplett ausgeblendet werden. Über "XPDR" kann aus-gewählt werden, ob nur der Transponder – Code (Squawk), nur das Rufzeichen (Call-sign), beide Angaben oder keines von beidem angezeigt werden soll. "TYPE" erlaubt die Anzeige des Luftfahrzeugtyps im Label.


IMPLEMENTIERUNG

1-27

• Vergangenheitssymbole: hier kann die Anzahl der Vergangenheitssymbole (History Dots) eingestellt werden. Die mögliche Anzahl liegt zwischen null und sechs.

• Kartenskalen: über diesen Button können die am Rande des Bildschirms sichtbaren Kar-tenachsen, die mit einer Skala mit der Einheit "Nautische Meilen" versehen sind, ein- und ausgeblendet werden.

Folgende weitere Funktionen zur Konfiguration der Radarbilddarstellung stehen dem Lotsen zur Verfügung:

• Zooming: Veränderung der Größe des Bildausschnitts. Es kann über einen Schieberegler ("Slider", s. Abbildung 14) stufenlos zwischen einem sichtbaren Bereich von einer Nauti-schen Meile (NM) und 500 Nautischen Meilen gewählt werden. Drei Voreinstellungen sind über Pushbuttons abrufbar: 120, 144 und 220 NM.

Abbildung 14: Slider zur Zoom-Einstellung

Die Werte der verfügbaren Voreinstellungen können den Gegebenheiten des betrachteten Kontrollsektors entsprechend optimiert werden.

• Panning: Veränderung der Position des Bildausschnitts. Das Zentrum des Kartenaus-schnitts kann über die horizontale und vertikale Bildlaufleiste (s. Abbildung 8) eingestellt werden. Diese Funktion wird für die Lotsenexperimente deaktiviert, da sie aufgrund des statischen Bildausschnitts des Programmsystems EnCoRe-PluS nicht verfügbar war.

• Leveling: Wählen des vertikalen Ausschnitts der Radarzieldarstellung. Radarziele, die sich außerhalb des gewählten Bereiches befinden, werden abgedunkelt dargestellt. Die Einstellung "Lower" bestimmt, ab welcher Mindesthöhe die Radarziele nicht mehr abge-dunkelt dargestellt werden, mit dem Regler "Upper" wird die Obergrenze eingestellt. Die Angabe erfolgt als Flight Level. Angezeigt wird die Mode C – Höhe das heißt die Bezugs-fläche ist abhängig von der Höhenmessereinstellung des Flugziels (entweder Mean Sea Level oder die Standard - Druckfläche 1013,25 hPa).

Abbildung 15: Regler zur Wahl des vertikalen Bildausschnitts


IMPLEMENTIERUNG

1-28

• Geschwindigkeitsvektor: der Geschwindigkeitsvektor extrapoliert auf Basis der berech-neten Geschwindigkeit und des Kurses über Grund die Position des Luftfahrzeugs in vor-eingestellten Zeitabständen. Diese Zeitabstände können im Minutenintervall zwischen null und sechs Minuten eingestellt werden.

Abbildung 16: Dialogbox zur Einstellung der Länge des Geschwindigkeitsvektors

• Etikettenüberlappung: bei hoher Verkehrslast besteht die Gefahr der Überlappung ein-zelner Labels. Zur Vermeidung dieser Überlappung kann die Ausrichtung der Labels kol-lektiv oder selektiv modifiziert werden. Zur kollektiven Änderung genügt ein Mausklick auf den entsprechenden Radiobutton der folgenden Dialogbox:

Abbildung 17: Dialogbox zur Ausrichtung des Etiketts

Die Bezeichnungen "N,NE,E, etc." entsprechen den Himmelsrichtungen der Kursrose. Wird beispielsweise der Button "NE" angewählt, werden die Etiketten schräg rechts oberhalb ihrer zugehörigen Radarziele angeordnet. Ein automatisches Etiketten – Anti – Überlappungsprogramm ist vorgesehen, zum gegenwärtigen Zeitpunkt jedoch noch nicht realisiert. Dieses Programm kann dann zukünftig mit dem "Off" – Radiobutton aktiviert werden.

Zur selektiven Ausrichtung einzelner Etiketten wird mit der linken Maustaste in das Symbol des Radarziels geklickt und die Maus an die gewünschte Position bewegt. Dort kann das Etikett durch Klick auf die mittlere Maustaste positioniert werden. Während der Verschiebung wird der Rahmen des Etiketts stilisiert angezeigt.

• Bildschirmwechsel: die Taste "JUMP" erlaubt dem Lotsen, seinen Mauszeiger auf dem benachbarten Bildschirm mit den elektronischen Kontrollstreifen zu positionieren, um dort Einträge vornehmen zu können (s. Kap. 4.1, Interoperability). Diese Taste wird in einer Weiterentwicklung von SIMCO nicht mehr vorhanden sein, da dann der Bildschirmwech-sel automatisch bei Berührung des Mauszeigers mit einem Bildschirmrand erfolgen wird.

• Vollbildschirm: mit der Taste "Full Screen" werden die Bildlaufleisten und die Konfigu-rationsleiste ausgeblendet. Zusätzlich zur Radarkarte ist dann nur noch das Uhrzeitfenster sowie eine Taste, die die Rückkehr in den nicht - Vollbildschirm – Modus ermöglicht, zu sehen.


IMPLEMENTIERUNG

1-29

4.3.4 Flugzieldarstellung

Die von der Radarsimulation eingespielten Flugziele werden entsprechend den heute üblichen Radarzieldarstellungen angezeigt (siehe Abbildung 18).

Abbildung 18: Darstellung eines Radarziels

4.3.5 Das Etikett

Die Normaldarstellung des Etiketts ("Label") beinhaltet das Rufzeichen des Luftfahrzeuges, dessen Flughöhe als Flugfläche und seine Geschwindigkeit über Grund (vgl. Abbildung 18). Konfigurationsmöglichkeiten zur Erweiterung der verfügbaren Informationen sind in Kapitel 4.3.3 beschrieben.

Callsign

Ground Speed

Flight Level

History Dots Speedvector


IMPLEMENTIERUNG

1-30

Berührt der Lotse ein Radarziel mit dem Mauszeiger, so erscheint für dieses Ziel ein vergrö-ßertes Label:

Abbildung 19: Erweitertes Etikett2

Bei der Gestaltung des erweiterten Labels wurden Entwürfe der Phare – Demonstrations 2 (PD/2) eingearbeitet. Die Informationen sind in Spalten angeordnet, unter den aktuellen Flug-parametern werden die dazugehörigen, vom Lotsen freigegebenen Werte angezeigt. Das Eti-kett nimmt wieder seine normale Darstellung ein, sobald der Mauszeiger das erweiterte Etikett oder das Radarziel verläßt.

4.3.6 Elektronische Flugplanstreifen

Da elektronische Kontrollstreifen bereits vor der Entwicklung von SIMCO in das Modell der Floglotsentätigkeit MoFL eingearbeitet wurden, mußten für eine zweckmäßige Anbindung von MoFL an SIMCO diese elektronischen Streifen von Anfang an auch in den SIMCO inte-griert werden.

In internationalen Forschungsprojekten sind elektronische Flugplanstreifen Gegenstand inten-siver Untersuchungen. Ihr Einsatz bei zukünftigen Lotsenarbeitsplätzen ist jedoch gewiß, da er zahlreiche Vorteile mit sich bringt. Vorteilhaft ist beispielsweise die Einfachheit, mit der Ein-tragungen vorgenommen werden können, die dann umgehend vom System erfaßt und weiter-verarbeitet werden können. Ihr Einsatz birgt jedoch auch Risiken. Problematisch gestaltet sich zum Beispiel die Frage, wie dem System der Urheber einer Eintragung vermittelt werden kann oder wie bei Ausfall des Systems die Informationsversorgung der Lotsen sichergestellt werden kann.

2 Weitere Daten, wie zum Beispiel der Zielflughafen, die Wirbelschleppenkategorie oder der Ausrüstungsstan-dard des Luftfahrzeuges werden zukünftig zusätzlich im Label erscheinen. Dies konnte bis zum jetzigen Zeit-punkt noch nicht realisiert werden.

Callsign

Aircraft Type

Cleared Flight Level

Actual Flight Level Actual Rate of Climb

Cleared Rate of Climb

Actual Ground Speed

Cleared Ground Speed Actual Heading Cleared Heading Squawk


IMPLEMENTIERUNG

1-31

Die elektronischen Flugplanstreifen in SIMCO haben vorerst hauptsächlich informativen und weniger interaktiven Charakter. Sie werden auf einem separaten 17 – Zoll – Monitor darge-stellt, der sich auf der rechten Seite neben dem Radarbildschirm befindet. Die Streifen bieten Informationen sowohl über Plandaten als auch über aktuelle Flugparameter. Aus dieser Tatsa-che ergibt sich die Schwierigkeit, daß diese Streifen sowohl mit Daten aus der zentralen Flug-plandatei, als auch mit aktuellen Flugparametern aus der laufenden Simulation versorgt wer-den müssen. Besondere Aufmerksamkeit muß hier der systeminternen Zuordnung der ver-schiedenen Datenströme zu den einzelnen Flugobjekten gewidmet werden, da die Sortierung der Streifen im Strip Window sehr anfällig gegen Vertauschen ist.

Abbildung 20: Elektronischer Kontrollstreifen

Die nachfolgende Abbildung enthält die Erklärungen zu den einzelnen Feldern des Streifens aus Abbildung 20:

Entry Level Entry Time

Entry Point A/C-Type Squawk Wake Category

Estimated Time Over

Sort Point Departure Ground Speed

Heading

Desti nation Callsign

Exit Level Ausflug-

zeit Exit Point

Requested FL Actual Flight-

Level Cleared FL

Abbildung 21: Eintragungen im elektronischen Kontrollstreifen

Die Streifen sind folgendermaßen aufgebaut: ein Flugplanstreifen enthält drei Zeilen. Auf der linken Seite befinden sich Angaben über die Route des Luftfahrzeuges durch den Sektor: der Eintrittspunkt mit der dazugehörigen geplanten Einflugzeit, der Sortierungspunkt mit Über-flugzeit in der mittlere Zeile und der Austrittspunkt in der unteren Zeile.

Um das zentrale Symbol des Luftfahrzeuges gruppieren sich Plandaten und aktuelle Flugzu-standsdaten. Hinter dem Luftfahrzeug steht der ICAO 4 – Letter – Code des Startflughafens, vor ihm ist der Zielflughafen eingetragen. Die Flugzustandsdaten sind durch eine bläuliche Farbgebung von den übrigen Informationen abgehoben und werden bei jedem Umlauf der Ra-darantenne aktualisiert, sofern sich ihr Wert geändert hat. Befindet sich das Luftfahrzeug im Steig- oder Sinkflug, so wird dies durch einen aufsteigenden beziehungsweise abfallenden Pfeil in der Nähe des Symbols signalisiert.

Die örtliche Anordnung auf dem Streifen erfolgte entsprechend ihrer Bedeutung sinngemäß um das Symbol herum: vor der Luftfahrzeugnase steht der Kurs, unter dem Luftfahrzeug die aktuelle Flughöhe, hinter ihm befindet sich der Geschwindigkeitswert. Neben der aktuellen


IMPLEMENTIERUNG

1-32

Flughöhe befinden sich Angaben über die laut Flugplan beantragte Flughöhe (RFL) und die vom Lotsen freigegebene (CFL) Höhe. Stimmen CFL oder RFL mit der aktuellen Flughöhe überein, so werden deren Werte komplett ausgeblendet. Das Rufzeichen wurde absichtlich weit aus der Vielzahl der übrigen Daten nach rechts herausgezogen und vergrößert dargestellt, um das schnelle Auffinden im Strip Window zu erleichtern.

Bei der Festlegung der Inhalte der Flugplanstreifen wurden sowohl die Ergebnisse (WELCHE ?) von Forschungsprojekten als auch die Erfordernisse von MoFL berücksichtigt. Wie bereits erwähnt, haben die Streifen in SIMCO vorerst lediglich informativen Charakter. Die Eingabe der Werte von Flugsicherungsanweisungen durch den Lotsen zur Aktualisierung des Systems ist jedoch geplant. Aus Abbildung 20 ist zu erkennen, daß mit der Erstellung einer Eingabe-möglichkeit für die Ausflughöhe aus dem Sektor bereits begonnen wurde. Diese kann über einen sogenannten "Poptext" in den Streifen eingegeben werden, die Einflughöhe des nachfol-genden Sektors wird dadurch zukünftig automatisch aktualisiert.

4.3.7 Das Strip Window

An den meisten Lotsenarbeitsplätzen wird derzeit noch mit den herkömmlichen Papierstreifen gearbeitet, die vor dem Radarschirm, sortiert nach Funkfeuern oder Luftstraßenkreuzungen, in ein Tableau eingeschoben werden. Überfliegt ein Luftfahrzeug mehrere Sortierungspunkte im Sektor, so wird für jeden Punkt ein gesonderter Streifen angelegt. Ein Luftfahrzeug kann folg-lich durch mehrere Streifen im Tableau repräsentiert werden.

Das aus dem analogen Kontrollstreifensystem bekannte Tableau wird auf dem Monitor nach-gebildet. Für jeden Sortierungspunkt existiert eine Tabelle, in die die Flugplanstreifen automa-tisch eingeschoben werden. Die Reihenfolge der Auflistung wird durch die Überflugzeit über den Sortierungspunkt bestimmt. Befinden sich mehr Streifen in der Tabelle als dort Platz ist, so können die verdeckten Streifen über die vertikale Bildlaufleiste in den sichtbaren Bereich verschoben werden (vgl. ). Die Möglichkeit zur aktiven Löschung eines Streifen wird noch programmiert werden, derzeit verschwindet ein Streifen in dem Moment, in dem das Luftfahr-zeug den simulierten Verkehr verläßt.

Im betrachteten Sektor West Radar 2 (WR2) werden die Flugrouten der Luftfahrzeuge über vier Sortierungspunkte sortiert. Diese heißen Bestu, Nensa, Gotem und Saren. Saren befindet sich zwar außerhalb von WR2, da dieser Punkt jedoch vor der Umstrukturierung der Sektor-grenzen noch innerhalb des Sektors lag, ist er als Sortierungspunkt geblieben. Das "Strip Window" präsentiert sich dem Lotsen wie folgt:


IMPLEMENTIERUNG

1-33

Abbildung 22: Bildschirm mit elektronischen Flugplanstreifen

4.3.8 Funktionen für Experimente / Protokollfunktionen

Fragen während der laufenden Simulation

Zur Bewertung der Auswirkungen des Multi–Sektor–Planungs-Konzeptes auf die mentale Repräsentation des Verkehrsgeschehens durch den Sektorlotsen sind spezifische Experimente geplant, die Unterbrechungen der Simulation zu fest definierten Zeitpunkten vorsehen. Für die Eingabe der Zeitpunkte steht ein Dialogfenster zur Verfügung, so daß diese Zeiten auch kurz-fristig vor der eigentlichen Simulation angepaßt werden können.


IMPLEMENTIERUNG

1-34

Abbildung 23: Eingabefenster für die Zeitpunkte zur Simulationsunterbrechung

Bei Eintritt dieser Zeitpunkte während der Simulation werden ohne vorherige Ankündigung bestimmte Luftfahrzeuge für 200 Millisekunden erhellt dargestellt. Daran anschließend wird der Radarbildschirm ausgeblendet und es erscheinen nacheinander zwei Fragen. Die erste Fra-ge dient der Einschätzung des zeitlichen Verlaufs der Konflikterkennung (Kategorie 1), die zweite Frage zielt auf die Bewertung des Inhalts des "pictures" des Lotsen ab (Kategorie 2).

Abbildung 24: Frage der Kategorie 1

Abbildung 25: Frage der Kategorie 2

Die Beantwortung der Fragen erfolgt mittels Tastatur über die Funktionstasten 1 – 5 bezie-hungsweise über die Tasten "Alt" und "AltGr". Die Zeit, die zwischen Einblendung und Be-antwortung einer Frage vergeht wird gemessen und in Millisekunden im Logfile protokolliert.


IMPLEMENTIERUNG

1-35

Die Häufigkeit, mit der diese Fragenpaare während der Simulation eingeblendet werden, hängt vom jeweiligen Simulationsszenario (Verkehrsart, Dauer der Simulation) ab.

Protokolldateien (Logfiles)

Während der Simulationsläufe ist es möglich, Protokolldateien durch das System anfertigen zu lassen. In diesen Logfiles werden alle wesentlichen systeminternen Vorgänge, etwa die Ausführung eines Makros, aber auch Bildschirmereignisse, wie zum Beispiel das Öffnen oder Schließen eines Fensters, festgehalten. Der für die kognitionspsychologische Auswertung er-forderliche Inhalt der Logfiles wurde von den Mitarbeitern des bisherigen Teilprojektes 4 der Forschergruppe spezifiziert und von Teilprojekt 1 berücksichtigt. Folgende Aktionen der Lot-sen müssen mit Zeitstempel in die Protokolldateien eingetragen werden:

• Eingabe der Eintrittsflugfläche

• Eingabe des Austrittsfluglevels

• Abbruch der Eingabe einer neuen Flughöhe

• Abbruch derEingabe einer neuen Geschwindigkeit

• Eingabe einer neuen Geschwindigkeit

• Erstmalige Darstellung eines Streifens

• Löschung eines Streifens

• Kollision

• Ende des Experiments

4.3.9 Kommunikation mit dem modellierten Fluglotsen – MoFL

zeigt die Schnittstellen zwischen MoFL und SIMCO und den Datenfluß zwischen beiden Modulen. Im Gegensatz zur Kommunikation des SIMCO mit dem Radarprogramm handelt es sich bei der SIMCO – MoFL – Kommunikation um eine TCP/IP – Verbindung, bei der MoFL den Server und SIMCO den Client darstellt. Nach dem Start von MoFL wartet dieser auf die Anbindung von SIMCO. SIMCO seinerseits versucht direkt nach dem Start eine TCP/IP-Verbindung zu MoFL aufzubauen. Falls MoFL nicht aktiv ist, wird der SIMCO ohne Anbin-dung an MoFL hochgefahren. Auch für diese Kommunikation wird ein Port und eine feste Netzwerkadresse festgelegt.


IMPLEMENTIERUNG

1-36

Abbildung 26: Kommunikation MoFL – SIMCO

Direkt nach der erfolgreichen Anbindung von SIMCO an MoFL, sendet MoFL ein Register. Dieses Register verarbeitet SIMCO zur Bestätigung des gelungenen Verbindungsaufbaus und es besteht nun die Möglichkeit, Daten an MoFL zu senden. In SIMCO vorhandene oder neu hinzukommende Flugzeugobjekte werden sodann in einem MoFL – spezifischen Format an MoFL gesendet (s. Abbildung 27).


IMPLEMENTIERUNG

1-37

Abbildung 27: MoFL – Datenformat für Luftfahrzeugobjekte

Nachdem alle existierenden Luftfahrzeugobjekte gesendet wurden, wird die Initialisierung durch die Übertragung eines Register an MoFL beendet. Im Laufe des folgenden Simulations-betriebes in SIMCO erzeugte (zur Simulation hinzukommende) Luftfahrzeugobjekte werden analog dazu an MoFL gesendet.

Aufgrund der ursprünglich statischen Bildschirmauflösung von MoFL sind die X- bzw. Y-Position in diesem Falle MoFL – spezifische Bildschirmkoordinaten. Die Positionskoordina-ten der Luftfahrzeuge in SIMCO beziehen sich jedoch auf das festgelegte, geographische Ko-ordinatensystem. Die Pixel – Position eines Radarziels auf dem Bildschirm ist daher zusätz-lich zu der geographischen Position des Luftfahrzeuges abhängig von dem gewählten Karten-ausschnitt sowie von dem aktuell gewählten Zoomfaktor. Aus diesem Grunde erfolgt in SIM-CO eine Umrechnung der Koordinaten in das MoFL – Format unter Beachtung der vorge-nannten Parameter. Die Positionen der sichtbaren Radarziele werden daher als Pixel – Werte an MoFL übergeben. Befindet sich ein Radarziel außerhalb des sichtbaren Bereichs, so wer-den die Werte X = –1 und Y = –1 gesendet.

Der Parameter "Near" signalisiert dem MoFL, ob sich in der Nähe des Objektes, dessen Daten gerade gesendet werden, andere Luftfahrzeuge befinden. Hierfür analysiert SIMCO einen vor-definierten Bereich (einen Kreis mit dem Radius 100 Pixel) um dieses Luftfahrzeugobjekt herum und setzt "Near" = 1, wenn sich ein oder mehrere Luftfahrzeuge innerhalb des definier-ten Bereichs befinden. Befinden sich keine anderen Objekte in diesem Bereich, ist "Near" = 0.

Auch bei der MoFL-Kommunikation wird der vereinbarte Port bei jedem Durchlauf nach an-kommenden Daten überprüft, wobei die hier festgelegte Portnummer, wie auch die Portnum-mer der Radarkommunikation, nicht anderweitig vergeben sein darf. Bei den Datenpaketen, die von MoFL an SIMCO gesendet werden, handelt es sich um Anfragen zu bestimmten Pa-rametern der existierenden Luftfahrzeugobjekte. Dabei wird zwischen drei verschiedenen An-fragen unterschieden:

• ask-1: Mit einem solchen ask werden bestimmte Parameter eines einzelnen Luftfahr-zeugobjektes erfragt.

• ask-2: Dieses ask dient dazu, zu erfragen, welche Luftfahrzeugobjekte sich in einem von neun Sektoren auf dem Radarschirm befinden. Dabei entspricht ein Sek-tor nicht dem Kontrollsektor des Luftraums, sondern einem rechteckigen Neuntel des Bildschirms.

• ask-3: Über diese Anfrage wird MoFL mitgeteilt, welche Luftfahrzeugobjekte sich innerhalb eines bestimmten, kreisförmigen Bereichs des Radarbildschirms be-

tell( Callsign, X-Position, Y-Position, Altitude, Near )\r\n\r\n


IMPLEMENTIERUNG

1-38

finden. Dieser Kreis ist festgelegt durch die Pixelwerte der x- und y-Koordinate für den Kreismittelpunkt mit dem dazugehörigen Radius in Pi-xeln.

Folgende Parameter können von MoFL über das ask-1 erfragt werden:

• ACT_FL: die momentane Flughöhe

• CLR_FL: die freigegebene Flughöhe

• ACT_SPD: die momentane Fluggeschwindigkeit

• CDI: der Climb-Descent-Indicator (1 = Climb, -1 = Descent)

• PRED_X: der x-Anteil der momentanen Richtung

• PRED_Y: der y-Anteil der momentanen Richtung

• X: die aktuelle x-Koordinate auf dem Radarbildschirm in Pixeln

• Y: die aktuelle y-Koordinate auf dem Radarbildschirm in Pixeln

• NEAR: das Näheflag, das angibt, ob in einem vom Simulationssystem vorgegebenen Radius um das Luftfahrzeug andere Objekte vorhanden sind

Diese asks kommen bei SIMCO als Datenpakete an. Dort werden sie analysiert, die erfragten Informationen werden berechnet und MoFL-spezifisch formatiert. Anschließend werden die Daten als "reply" an MoFL zurückgeschickt. Zu jedem ask existiert ein entsprechendes reply, das die angeforderten Informationen enthält. Abbildung 28 illustriert die Kommunikation zwi-schen SIMCO und MoFL.

Weiterführende Informationen hierüber sind im Internet auf der Seite

"http://www.zmms.tu-berlin.de/~sandro/MoFL/Kommunikation.html"

abrufbar.

http://www.zmms.tu-berlin.de/~sandro/mofl/Kommunikation.html


IMPLEMENTIERUNG

1-39

Abbildung 28: Kommunikation MoFL – SIMCO

4.4 Der Multi-Sektor-Planer-Arbeitsplatz SIMFLOW

Der innerhalb des Simulationssystems realisierte Arbeitsplatz für den Multi–Sektor–Planer wird SIMFLOW ("Sophisticated Interface for the Management of FLOW Control") genannt. Diese grafische Benutzerschnittstelle hat zum Ziel, die gesamte „Multisector – Planning – Area“ mit den angeschlossenen Einzelsektoren in übersichtlicher Form darzustellen. Weiter-hin stellt sie die notwendigen Funktionen und Displays zur animationsartigen Darstellung des geplant – prognostizierten Verkehrsgeschehens und zur Kommunikation mit den Sektorlotsen zur Verfügung.

4.4.1 Einspeisung der Daten

Das Einlesen der Daten wird analog zu SIMCO vollzogen. Basis der Informationen sind hier ebenfalls aktuelle Radardaten und die Flugplandatenbank. Je nach Betriebsmodus des SIM-FLOW gelangen entweder die Echtzeit – Daten der Luftverkehrssimulation oder die Flug-plandaten zur Anzeige auf das Display. Der Abgriff der Radardaten ist in 4.3.1 bereits erläu-tert worden.

Simco

Kommunikation

Startphase

Zustandsfrage

Reihenfolgenicht fest

Überschneidung

aktives Ereignis

Zeit

A)

B.1)

B.2)

B.3)

tell

tell

tell

tell

register

reply

reply

register

ask

ask

i

i

i

i

Kommunikationsaufbau

MoFl


IMPLEMENTIERUNG

1-40

Die Anzeige von Plandaten geschieht über die Flugplandatei. Hierfür wird eine zweite Datei angelegt, in der die für jedes Luftfahrzeug die berechnete Position zu einem bestimmten Zeit-punkt eingetragen wird. Für die Darstellung des zukünftigen Zustands des Luftverkehrs muß nur ein Zeiger auf der gewünschten Uhrzeit positioniert werden um dort die Koordinaten aus-zulesen. Die Animation der Flugwege erfolgt über sequentielles Positionieren dieses Zeigers und Anzeigen der Positionen.

4.4.2 Das Radarbild

Abbildung 29: Graphische Benutzeroberfläche des SIMFLOW

Bei der Gestaltung des Sektorlotsenarbeitsplatzes SIMCO und des Multi–Sektor–Planer–Arbeitsplatzes SIMFLOW wurde großer Wert auf ein einheitliches Erscheinungsbild gelegt. Bei der Erstellung der Oberflächen wurde zuerst ein Prototyp für beide Arbeitsplätze erstellt, der nach vollständiger Implementierung aller notwendigen Grundfunktionen zur Steuerung und Konfiguration des Radarbildes als Grundsystem für die anschließende parallele Weiter-entwicklung beider Controller Working Positions genutzt wurde.

In Abbildung 29 ist jedoch gut der wesentliche Unterschied beider Radarschirme zu erkennen: SIMFLOW bietet eine Übersicht über einen sehr großen Ausschnitt des Luftraumes. In der


IMPLEMENTIERUNG

1-41

Mitte der Darstellung ist der innerhalb der DFG – Forschergruppe für die Arbeit des Sektor-lotsen eingehend betrachtete Sektor West Radar 2 (WR2) erhellt dargestellt, die Grenzen der benachbarten Sektoren, allesamt der Regionalkontrollstelle in Berlin – Tempelhof angehörig, sind gestrichelt gezeichnet.

Das in der rechten oberen Hälfte des Radarschirms sichtbare "Conflict and Risk Display" so-wie links unten das "Vertical Aid Window" wurden bereits vorbereitet, sind derzeit jedoch noch ohne Funktion. Diese Fenster können vom Lotsen bei Bedarf ein- und ausgeblendet wer-den oder auch mit der Maus in Bereiche des Bildschirms verschoben werden, in denen sie den Lotsen bei seiner Arbeit nicht behindern.

4.4.3 Funktionen zur Steuerung des Arbeitsplatzes

Aufgrund der gewünschten Kommonalität der beiden entwickelten Lotsenarbeitsplätze ent-sprechen die Funktionen des SIMFLOW zur Bildschirmsteuerung denen des SIMCO. Daher soll hier nur auf abweichende Funktionen und Zusatzfunktionen eingegangen werden, über die der SIMCO nicht verfügt.

• Zusatzfenster:

Abbildung 30: Druckknöpfe zur Aktivierung von Zusatzfenstern

Mit diesen vier Druckknöpfen können (von links nach rechts) das "Conflict Zoom Win-dow", das "Vertical Aid Window", "Horizontal Aid Window" und das "Conflict And Risk Display" ein- und ausgeblendet werden. Diese Fenster sind in ihrer Idee nach dem ODID IV – Konzept entnommen. Ihre inhaltliche Funktion muß noch realisiert werden.

• Flugprofildarstellung: über den Drucknopf "Show Pathes" besteht die Möglichkeit, über das Auslesen der Flugpläne die geplanten lateralen Flugprofile anzeigen zu lassen. Der-zeit werden die Profile aller Luftfahrzeuge simultan dargestellt, die Programmierung zur selektiven Einblendung ist in Bearbeitung. Ist die Anzeige der Flugprofile aktiv, so lautet die Beschriftung des Druckknopfes "Hide Pathes".

4.4.4 Vorschau – Simulation

Unter simulierter oder Simulationszeit ist in diesem Kontext die Vorschauzeit zu verstehen, also eine Uhrzeit, die der aktuellen Systemzeit (Real Time) vorauseilt (Simulationsmodus). Dabei werden die Flugpositionen aus den Flugplandaten errechnet, der Bildschirm fungiert dann als Flugplandisplay. Damit sieht der Multi–Sektor–Planer den Luftraumzustand, wie er sich in der Zukunft aufgrund der Flugpläne darstellen wird. Im Gegensatz dazu steht die An-


IMPLEMENTIERUNG

1-42

zeige der aktuellen Systemzeit (Realmodus). Dies ist die Zeit, in der sich das gesamte Erpro-bungsszenario befindet.

Beide Zeitanzeigen sind in der rechten oberen Ecke plaziert und anhand der Farbgebung der Anzeigen ist erkennbar, welcher Modus, Real- oder Simulationsmodus, aktiviert ist.

Abbildung 31: Anzeige von Realzeit und Vorschauzeit

Abbildung 31 zeigt den Zustand der Zeitanzeigen für die aktive Vorschau – Simulation. Die momentan aktive Zeit wird in schwarz, die inaktive in hellgrau dargestellt. In diesem Beispiel läßt sich der Multi–Sektor–Planer also den geplant – prognostizierten Verkehr für einen Zeit-punkt zeigen, der 23 Minuten in der Zukunft liegt.

Die Einstellung der gewünschten "Look Ahead Time" (LAT) geschieht über die Zeitleiste am unteren Bildschirmrand.

Abbildung 32: Zeitleiste zur Einstellung der Vorschau – Zeit

Den Ursprung dieser dynamischen Skala bildet auf der linken Seite die aktuelle Systemzeit (Realzeit der Luftverkehrssimulation). Mit fortschreitender Zeit muß sich daher auch der Wert am Ursprung der Zeitskala ändern. Folglich bewegen sich die Werte der Skala von rechts nach links.

Die Wahl der Vorschau – Zeit erfolgt durch einfaches Positionieren des Schiebers unterhalb der Zeitleiste unter den gewünschten Wert. Darüber hinaus kann der Schieber über am linken und rechten Rand angeordnete Pfeiltasten jeweils um einen einer Sekunde entsprechenden Wert zurück- bzw. vorgestellt werden. Klickt man in die Schiebeleiste links bzw. rechts neben den Schieber, dann verstellt sich die Zeit um eine Minute. Nach Positionierung des Schiebers zurück an den linken Rand stimmen Systemzeit und Simulationszeit wieder überein.


IMPLEMENTIERUNG

1-43

4.4.5 Schneller Vorlauf

Hierbei handelt es sich um eine "Fast Forward" – Funktion zur Darstellung der geplanten Flugbewegungen im Zeitraffer. Es besteht die Möglichkeit, den Geschwindigsfaktor des Zeit-raffers einzustellen. Der Startzeitpunkt der Animation kann über die Zeitleiste eingestellt wer-den.

Abbildung 33: Einstellung des Fast – Forward – Faktors

Neben dem Schiebebalken befinden sich zwei vertikal angeordnete radiobuttons. Mit dem oberen kann der Zeitfaktor erhöht werden, mit dem unteren wird er verkleinert. Direkt neben der Zeitleiste über dem Schiebebalken wird der aktuell gewählte Vorlauffaktor ange-zeigt. Zur Abschaltung des schnellen Vorlaufs genügt ein Klick auf die Anzeige des Vorlauf-faktors.


IMPLEMENTIERUNG

1-44

4.4.6 Konflikterkennungs- und -lösungsprogramm

Bei den Algorithmen, die dem Multi–Sektor–Planer zur Erkennung und Lösung mittel- bis langfristiger Planungskonflikte zur Verfügung stehen, handelt es sich um das in einer Diplom-arbeit3 entwickelte und später erweiterte4 LOTEC (LOng TErm Conflict prediction and solu-tion analysis). Die Erkennung einer drohenden Staffelungsunterschreitung erfolgt über einen sequentiellen Vergleich aller in der zentralen Flugplandatenbank vorhandenen Flugpläne. Es werden jeweils die Trajektorien zweier Luftfahrzeuge systematisch in festen Zeitabschnitten miteinander verglichen. Bei Erkennung einer Unterschreitung des geforderten Mindestabstan-des werden die folgenden ausführlichen Informationen zum Abruf für den Multi–Sektor–Planer im Speicher bereit gehalten:

Abbildung 34: Beschreibung eines Planungskonfliktes

Zukünftig sollen diese Informationen in aufbereiteter Form von der graphischen Benutzer-oberfläche abrufbar sein. Eine Aufbereitung kann beispielsweise über die Visualisierung auf dem "Conflict And Risc Display" und dem "Conflict Zoom Window" erfolgen.

Zur Lösungsfindung werden Flugparameter (Geschwindigkeit, Steig- / Sinkgradient, etc.) so-lange inkremental modifiziert, in den Flugplan eingetragen und mit den übrigen Flugprofilen verglichen, bis die vorhergesagte Unterschreitung der Staffelungsmindestwerte nicht mehr stattfindet oder aber die Flugparameter außerhalb der fliegbaren Leistungswerte durchschnitt-licher Airliner liegen. Eine Überprüfung auf induzierte Folgekonflikte wird durchgeführt, die zeitliche Länge der Konfliktfreiheit ist, je nach Verkehrsdichte, kalibrierbar.

3 Fricke, H.: Operativ/taktische Maßnahmen zur Konfliktlösung unter flugsicherungstechnischen Randbedingun-gen, Diplomarbeit, Technische Universität Berlin, Institut für Luft- und Raumfahrt, März 1991, Berlin

4 Stark, N.-H,: Bereitstellung und automatische Aktualisierung einer Echtzeit-Lösungsbibliothek für Flugver-kehrskonflikte innerhalb einer kooperativen Schnittstelle zwischen Verkehrsflußsteuerung (ATFM) und Flugver-kehrskontrolle (ATC), Diplomarbeit, Technische Universität Berlin, Institut für Luft- und Raumfahrt, Juli 1996, Berlin


IMPLEMENTIERUNG

1-45

Gefundene Lösungsvorschläge werden in Form einer "Flow Control Message" (FCM) betrof-fenen Sektorlotsen mitgeteilt.

Abbildung 35: Flow Control Message

Die Konflikterkennung und –lösung ist mittlerweile in der UNIX – Umgebung verfügbar und kann über den Druckknopf "Conflicts" aktiviert werden. Eine Visualisierung dieser Rohdaten muß noch erfolgen.

4.5 Der Pseudo – Piloten – Arbeitsplatz

Wie bereits in Kapitel 1.1 einleitend dargelegt, ist für eine realistische Luftverkehrssimulation die Kontaktaufnahme der Lotsen mit den Piloten der virtuellen Luftfahrzeuge notwendig. Die Aufgabe dieser Piloten besteht einerseits darin, den verantwortlichen Sektorlotsen die not-wendige Rückkopplung durch die Entgegennahme und Bestätigung ihrer Anweisungen zu ge-ben, andererseits müssen die Änderungen des Flugzustandes der Verkehrssimulation mitge-teilt werden.

Zu diesem Zwecke wurde eine Schnittstelle programmiert, die es einem "Pseudo – Piloten" erlaubt, mehrere simulierte Luftfahrzeuge zu steuern. Die maximale Anzahl an von einer Per-son steuerbaren Luftfahrzeugen muß während erster Simulationsläufe noch bestimmt werden, so daß der Einsatz eines zweiten Pseudo – Piloten – Arbeitsplatzes durchaus notwendig wer-den kann. Der Aufbau der Oberfläche und die Funktionalitäten werden in den folgenden Kapi-teln erklärt.

Die Sprechfunkverbindung zwischen Lotsen und Piloten erfolgt über eine spezielle Sprech-funksimulation, die auf Telefon – Standleitungen basiert und hierfür innerhalb der Forscher-gruppe für das ILR entwickelt und realisiert wurde.

4.5.1 Benutzerschnittstelle

Abbildung 36 zeigt die graphische Benutzeroberfläche. Im linken Fenster werden die Rufzei-chen aller Luftfahrzeuge aufgelistet, die von dieser Schnittstelle aus gesteuert werden können, das rechte Fenster dient zur Anzeige und Eingabe von Flugparametern.


IMPLEMENTIERUNG

1-46

Abbildung 36: Eingabeschnittstelle des Pseudo - Piloten

4.5.2 Abfrage aktueller Flugparameter

Die Abfrage aktueller Flugparameter geschieht durch Selektion des entsprechenden Rufzei-chens mit dem Mauszeiger. Dieses wird sodann invers dargestellt (vgl.Abbildung 36, Rufzei-chen "SEGLB") und die zu diesem Luftfahrzeug korrespondierenden aktuellen Flugwerte werden im Fenster "Select" angezeigt.

Folgende Werte werden angezeigt: Geschwindigkeit (True Air Speed, knots)

Höhe (Flight Level, 100 feet)

Höhenfreigabe (Cleared Flight Level, 100 feet)

Steig-/Sinkrate (Vertical Speed, feet/minute)

Steuerkurs (True Heading, degrees)

Nächster Wegpunkt (Next Waypoint, ID)

Transponder – Code (Squawk, 4 digit – code)

4.5.3 Steuerung der virtuellen Luftfahrzeuge

Die konfigurierbaren Werte sind überwiegend als sogenannter "Poptext" ausgeführt. Bei Klick mit der Maus auf einen solchen Poptext öffnet sich ein senkrechter Balken, in dem der aktuel-le Wert in der Mitte zu finden ist, die nächst höheren oder niedrigeren Werte sind darüber be-ziehungsweise darunter angeordnet. Mit gehaltener Maustaste kann nun der gewünschte Wert


ZUSAMMENFASSUNG UND AUSBLICK

1-47

selektiert werden. Bei der freigegeben Höhe werden nur ganze Flugflächen zur Auswahl an-geboten, die Steig- und Sinkrate sind in 100 ft/min – Schritten konfigurierbar.

Der Transponder – Code sowie der nächste Wegpunkt, der gerade angeflogen wird wurden als editierbarer Text ausgeführt ("Edittext"), da ein Poptext an dieser Stelle zu unübersichtlich wäre. Die veränderten Werte werden erst nach Anwahl der "APPLY" – Taste an die Verkehrs-simulation weitergegeben, um Mehrfachmodifikationen zu ermöglichen und versehentliche Fehleingaben reversibel zu halten.

Bis auf die aktuelle Flughöhe kann vom Pseudo – Piloten jeder Wert verändert werden. Möch-te der Pilot steigen oder sinken, so muß er den Wert für die freigegebene Höhe modifizieren. Grund für diese Vorgehensweise ist die Tatsache, daß der Pilot in der Lage sein muß, auf An-frage seine aktuelle Höhe und die Zielhöhe, auf die er gerade steigt oder sinkt, mitzuteilen.

5 ZUSAMMENFASSUNG UND AUSBLICK Das Ergebnis der im laufenden Bewilligungszeitraum durchgeführten Entwicklungsarbeiten ist eine solide Basisversion eines Luftverkehrs – Simulationssystems zur Durchführung der geplanten Experimente der Forschergruppe. Bei der Konzeption und Realisierung der Einzel-module wurde von vornherein versucht, das System möglichst leistungsfähig und flexibel zu gestalten und die zukünftigen Erfordernisse der Forschergruppe zu berücksichtigen und einzu-arbeiten.

Bodenseitig gestalteten sich die Arbeiten zur Integration des Fluglotsenmodells MoFL um-fangreicher als zunächst angenommen. Die Gründe hierfür liegen in der Tatsache, daß sich die Anpassung der bereits bestehenden Schnittstellen des MoFL als schwierig erwies, so daß der Sektorlotsenarbeitsplatz SIMCO mit den adäquaten Schnittstellen wie das zu MoFL gehörige, frühere Programmsystem ENCORE–PLUS ausgestattet werden mußte. Weiterhin mußten zur Informationsversorgung von MoFL Funktionalitäten implementiert werden, die über die eines konventionellen Lotsenarbeitsplatzes hinausgehen (vgl. Kapitel 4.3.8, 4.3.9).

Abweichend von der Definition des Szenario 0 der Forschergruppe, in dem der IST – Zustand des Flugsicherungssystems abgebildet wird, wurden für den Sektorlotsenarbeitsplatz bereits elektronische Flugplanstreifen entwickelt und programmiert, da der modellierte Fluglotse MoFL in seiner bestehenden Form vom Vorhandensein dieser Streifen ausgeht.

Die Erstellung des Multi–Sektor–Planer–Arbeitsplatzes ist derzeit in Arbeit. Aufbauend auf dem unter DOS verfügbaren Programmsystem ASD werden die erforderlichen Grundfunktio-nalitäten mit Hilfe der Entwicklungsumgebung der ODS – Toolbox unter UNIX realisiert. So-bald das Basisprogramm mit diesen Grundfunktionen fehlerfrei lauffähig ist, kann mit der Verknüpfung des Systems mit der Mode S – Simulation und der Bordseite begonnen werden.

Es kann davon ausgegangen werden, daß mit Ende des Bewilligungszeitraumes am 30.09.1998 das System voll verhandlungsfähig ist und erste Versuche zur Flugplanverhand-



1-48

lung durchgeführt wurden. Die hierfür verbleibenden Arbeiten sind im folgenden Kapitel zu-sammengestellt. Dabei handelt es sich im wesentlichen um die Vollendung aller Funktionen des Sektorlotsenarbeitsplatzes SIMCO, der Implementierung einer Basisversion des SIM-FLOW sowie um die Vernetzung aller zum Simulationssystem gehörigen Systeme.

Im kommenden Antragszeitraum wird die Funktionalität der Multi–Sektor–Planung und der Informationsaustausch Bord / Boden im Vordergrund stehen. Besondere Bedeutung erhält hierbei die Verwaltung der Datenströme während der Flugplanverhandlung. Modifikationen am bestehenden SIMCO werden sich auf ein Minimum reduzieren.

5.1 Verbleibende Arbeitspakete bis 30.09.

Bis zum Ende des laufenden Bewilligungszeitraumes sind weiterhin Arbeiten zur Realisierung der Szenarien 1 (Flugplanverhandlung per Data Link, Anweisungen per Sprechfunk) und Sze-nario 2 (Flugplanverhandlung und Anweisungen per Data Link) zu erledigen. Für das Teilpro-jekt 1 der Forschergruppe lassen sich die verbleibenden Aufgaben in folgenden Arbeitspake-ten zusammenfassen:

• Erweiterung von Funktionalitäten der elektronischen Flugplanstreifen. Der Sortierungsal-gorithmus, der für die erstmalige Abbildung, Einsortierung und Löschung der Flugplan-streifen verantwortlich ist, arbeitet noch nicht fehlerfrei. Weiterhin ist noch die Eingabe der Übergabeflugfläche sowie eine Möglichkeit zur manuellen Löschung eines Streifens zu programmieren.

• Weiterentwicklung der Basisversion des Multi–Sektor–Planer–Arbeitsplatzes SIMFLOW. Der Konfliktlösungsgenerator muß über die grafische Benutzerschnittstelle bedienbar sein. Dies beinhaltet die Visualisierung gefundener Konflikte und deren Lösungen sowie die Versendung der Lösungsvorschläge an den SIMCO. Weiterhin sind die Kommunikations-schnittstellen zur Bordseite noch zu entwickeln.

• Implementierung der Funktionalitäten des SIMCO zur Kommunikation mit dem Multi–Sektor–Planer zur Annahme oder Ablehnung von Lösungsvorschlägen.

• Konzeption und Realisierung der Eingabemedien für Flugsicherungsanweisungen an den Piloten am Sektorlotsenarbeitsplatz SIMCO.

• Durchführung der Experimente und Gesamtevaluation des Simulationssystems Bord / Bo-den

5.2 Neue Fragestellungen

Bei der Untersuchung möglicher Konzepte zukünftiger Air Traffic Management Systeme ist die Miteinbeziehung der Free – Flight – Thematik unumgänglich. Im "Operational Concepts Document" (EUROCONTROL, 1997a) ist für das EATMS die Einteilung in Managed Airspace (MAS), Unmanaged Airspace (UMAS) und Free – Flight – Airspace (FFAS) festge-



1-49

schrieben. Bodenseitig ergeben sich in diesem Rahmen eine Reihe interessanter Fragestellun-gen, auf die es in internationalen Forschungsprojekten bisher nur ansatzweise Antworten gibt.

• Wie können die Multi–Sektor–Planung und das Free Flight – Konzept derart in ein Air Traffic Management integriert werden, daß ihr jeweiliger Nutzen sich sinnvoll ergänzt ?

• Auf welche Art und wann findet die Übertragung der Verantwortung für die Separation beim Ein- und Ausflug aus dem FFAS statt ?

• Welche Auswirkungen auf die Lotsentätigkeit hat die Kontrolle dieses Mischverkehrs ?

• Wie kann eine Koordination mehrerer „Multisector – Planning – Areas“ untereinander er-folgen ?

5.3 Verknüpfung der Arbeit mit anderen Teilprojekten

Wie bereits in Kapitel 1.2 angedeutet, besitzt das Teilprojekt 1 nahezu zu jedem anderen Teil-projekt Schnittstellen. Neben der technischen Anbindung an die Bordseite (Teilprojekt 2), ist hier der tägliche Austausch von Informationen zur Konzeption von Verfahren und Schnittstel-len von besonderer Bedeutung. Das Schritt für Schritt vervollständigte Verhandlungskonzept ist das Ergebnis der engen Zusammenarbeit dieser beiden Teilprojekte.

Die Arbeit der humanwissenschaftlichen Teilprojekte 4 und 5 hängt sehr wesentlich vom Fortschritt der Arbeiten im Teilprojekt 1 ab. Die Evaluierung des modellierten Fluglotsen MoFL ist nur möglich, wenn die beiden technischen Systeme beider Teilprojekte kompatibel zueinander sind. Gemeinsame Programmierarbeiten erforderten folglich eine dauerhafte Ko-operation und sind auch im kommenden Antragszeitraum unabdingbar.

Die im Teilprojekt 4 und 5 entwickelten Untersuchungsszenarien haben direkten Einfluß auf die Funktionalitäten der technischen Systeme. Diese Funktionen wurden in die Lotsenarbeits-plätze während des ständigen Dialogs der Ingenieurwissenschaften und der Kognitionspsycho-logie integriert.

Die Verknüpfung des Teilprojekt 1 mit dem Teilprojekt 3 ist durch die technische Anbindung des bodenseitigen Teils des Simulationssystems an die Data Link – Simulation gegeben. Auf-grund der Vorlaufzeit, die die Entwicklung der Systeme in Anspruch nimmt, wird sich die Zu-sammenarbeit hier noch intensivieren.

Die bestehende Kooperation des jetzigen Teilprojekts 1 mit dem bereits mehrfach erwähnten BMBF – Projekt "Profile Negotiation Manager" wird im Rahmen des zukünftigen Bodenteil-projektes "Kapazitätsmanagement und Arbeitsstruktur im kooperativen ATM" noch weiter ausgebaut werden. Dieses Projekt spielt eine wichtige Rolle für das notwendige Informati-onsmanagement des Simulationssystems der Forschergruppe.


LITERATUR

1-50

6 LITERATUR EUROCONTROL (1994a). Experimental Centre,ODID IV Simulation Report. EEC Task

AS08, EEC Report No. 269/94

EUROCONTROL (1994b). PD/1 Operational Scenarios. PHARE/CAA/PD1-7.1/OSD;1, DOC 94-70-28.

EUROCONTROL (1995). PD/3 Demonstration Operational Specification. PHA-RE/CENA/PD3-1.3/OPS;3.1, DOC 95-70-02.

EUROCONTROL (1996). EUROCONTROL Experimental Centre, Introduction to the Tacti-cal Load Smoother. Renaud Choné

EUROCONTROL (1997a). EATMS Operational Concepts Document (OCD), Ed. 1.0. EATCHIP Doc: FCO.ET1.STO7.DEL01.

EUROCONTROL (1997b). PD/3 IOCP PROGRAMME, En-route Multi Sector Planning Procedures. PHARE/EEC/PD3-3.1.3.2.5/SSR;01.

EUROCONTROL (1998), Eurocontrol Experimental Centre (EEC), Capacity Plan 1998. For the European Air Navigation Services, EEC Note No. 3/98.

National Air Traffic Services Ltd. (1997). Satellite Communications and Automatic Depen-dent Surveillance (ADS) Trials. Department of Technical Research and Development.

Bierwagen, T. (1996). Programmsystem EnCoRe – PLuS: Über die Möglichkeiten der pro-grammierbaren Luftraumsimulation. Forschungsbericht 96 –2.

DFS Deutsche Flugsicherung (1996). DERD-XL-Handbuch. DFS.

7 TAGUNGEN UND EIGENE VERÖFFENTLICHUNGEN Hüttig, G., Fricke, H. & Stark N.-H. (1998): Evaluation of advanced ATC Procedures with

Full Flight Simulators in the loop in a Distributed Simulation Environment. In SimTect 98: Advancing Simulation Technology and Training, Proceedings of the Simulation and Training Conference, Glenelg, South Australia, März 1998, The Simulation Indu-stry Association of Australia (SIAA).

Documents

TECHNISCHE UNIVERSITÄT BERLIN Institut für Luft- und