Verordnung (EG) Nr. 2082/2000 der Kommission

vom 6. September 2000

zur Übernahme von Eurocontrol-Normen und zur Änderung der Richtlinie 97/15/EG zur Übernahme von Eurocontrol-Normen und zur Änderung der Richtlinie 93/65/EWG des Rates

DIE KOMMISSION DER EUROPÄISCHEN GEMEINSCHAFTEN -

gestützt auf den Vertrag zur Gründung der Europäischen Gemeinschaft,

gestützt auf die Richtlinie 93/65/EWG des Rates vom 19. Juli 1993 über die Aufstellung und Anwendung kompatibler Spezifikationen für die Beschaffung von Ausrüstungen und Systemen für das Flugverkehrsmanagement(1), insbesondere auf Artikel 3,

gestützt auf die Richtlinie 97/15/EG der Kommission vom 25. März 1997 zur Übernahme von Eurocontol-Normen und zur Änderung der Richtlinie 93/65/EWG des Rates über die Aufstellung und Anwendung kompatibler technischer Spezifikationen für die Beschaffung von Ausrüstungen und Systemen für das Flugverkehrsmanagement(2),

in Erwägung nachstehender Gründe:

(1) Durch die Richtlinie 97/15/EG wurde die Eurocontrol-Norm für den Online-Datenaustausch (OLDI), Ausgabe 1.0, und die Eurocontrol-Norm für die Darstellung des Datenaustauschs in der Flugsicherung (ADEXP), Ausgabe 1.0, übernommen.

(2) Eurocontrol hat eine neuere Fassung der beiden genannten Normen verabschiedet, nämlich OLDI Ausgabe 2.2 und ADEXP Ausgabe 2.0, sowie eine neue Eurocontrol-Norm mit der Bezeichnung Flugdatenaustausch-Schnittstellensteuerungsdokument (FDE-ICD).

(3) Diese Eurocontrol-Normen fallen in den Geltungsbereich der Richtlinie 93/65/EWG und tragen zur Harmonisierung der Flugverkehrsmanagementsysteme der Mitgliedstaaten bei, insbesondere was die Übergabe von Flügen von einer Flugsicherungszentrale zur nächsten (OLDI), die Verkehrsflusssteuerung (ADEXP) und die Kommunikation zwischen den nationalen Systemen (FDE-ICD) betrifft.

(4) Die Ausgaben 2.2 von OLDI und 2.0 von ADEXP treten an die Stelle der früheren Ausgaben, die nach Artikel 1 der Richtlinie 97/15/EG zur Zeit gültig sind; daher muss dieser Artikel aufgehoben werden.

(5) Die Bestimmungen dieser Verordnung stimmen mit der Stellungnahme des gemäß der Richtlinie 93/65/EWG eingesetzten Ausschusses überein -

HAT FOLGENDES VERORDNUNG ERLASSEN:

Artikel 1

Im Rahmen der Richtlinie 93/65/EWG des Rates werden die in den nachstehend aufgeführten Eurocontrol-Normen enthaltenen obligatorischen Teile von Eurocontrol-Spezifikationen übernommen, soweit sie für die Einrichtung eines integrierten, europäischen Flugverkehrsmanagementsystems erforderlich sind:

- Eurocontrol-Norm für den Online-Datenaustausch (OLDI), Ausgabe 2.2 (Eurocontrol-Fundstelle DPS.ET1.ST06-STD), die im Anhang I dieser Verordnung wiedergegeben ist,

- Eurocontrol-Norm für die Darstellung des Datenaustauschs in der Flugsicherung (ADEXP), Ausgabe 2.0 (Eurocontrol-Fundstelle DPS.ET1.ST09-STD), die im Anhang II dieser Verordnung wiedergegeben ist,

- Eurocontrol-Norm für das Flugdatenaustausch-Schnittstellensteuerungsdokument (FDE-ICD), Ausgabe 1.0 (Eurocontrol-Fundstelle COM.ET1.ST12-STD), die im Anhang III dieser Verordnung wiedergegeben ist.

Artikel 2

Artikel 1 der Richtlinie 97/15/EG wird hiermit aufgehoben.

Artikel 3

Diese Verordnung tritt am dritten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Gemeinschaften in Kraft.

Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat.

Brüssel, den 6 September 2000.

Für die Kommission

Loyola De Palacio

Vizepräsident

(1) ABl. L 187 vom 29.7.1993, S. 52.

(2) ABl. L 95 vom 10.4.1997, S. 16.

ANHANG I

ONLINE-DATENAUSTAUSCH (OLDI), AUSGABE 2.2

(Eurocontrol-Fundstelle DPS.ET1.ST06-STD)

INHALTSVERZEICHNIS

>PLATZ FÜR EINE TABELLE>

URHEBERRECHTLICHER HINWEIS

Dieses Dokument ist von der Agentur Eurocontrol erstellt worden.

Das Urheberrecht liegt bei der Agentur Eurocontrol.

Der Inhalt oder jeglicher Teil desselben steht den Vertretern der Mitgliedstaaten somit frei zur Verfügung; jede Abschrift oder Offenlegung an andere bedarf jedoch der vorherigen schriftlichen Einwilligung der Agentur Eurocontrol.

VORWORT

1. Verantwortliches Gremium

Die Eurocontrol-Norm für Online-Datenaustausch (On-line Data Exchange, OLDI), Ausgabe 2.2, wurde erarbeitet vom Direktorat für die Entwicklung (DED) des Programms zur Harmonisierung und Integration der Flugsicherung in Europa (EATCHIP), Eurocontrol, das zugleich für die Aktualisierung dieses Dokuments zuständig ist. Alle diesbezüglichen Stellungnahmen bzw. Anfragen sind an den Generaldirektor, Eurocontrol, Rue de la Fusée, 96, B-1130 Brüssel, zu Händen der Abteilung DED-2, zu richten.

2. Beziehung zum Dokument des EATCHIP-Arbeitsprogramms

Diese Norm ist ein Produkt im Rahmen der Specialist Task DPS.ET1.ST06 des EATCHIP-Bereiches ATM-Datenverarbeitungssysteme (Data Processing Systems Domain, DPS) entsprechend der Festlegung im Dokument des EATCHIP-Arbeitsprogramms (EATCHIP Work Programme Document, EWPD), Ausgabe 2.0, vom 30.09.1994.

3. Genehmigung und Nachträge

Diese Norm wurde den folgenden Genehmigungsverfahren gemäß Richtlinien für die Eurocontrol-Normierung unterzogen:

- Annahme durch das EATCHIP Operational Requirement and ATM Data Processing Team (ODT) per Korrespondenzverfahren;

- Konsultation aller ECAC-Staaten durch deren Vertreter im Managementausschuss bzw. im EATCHIP-Projektausschuss;

- Annahme durch den EATCHIP-Projektausschuss und den Managementausschuss;

- Annahme durch die Ständige Kommission.

Die Festlegungen dieser Norm treten mit ihrer Annahme durch die Ständige Kommission in Kraft.

Im Sinne der Anforderungen an die Entwicklung von Verfahren der Flugverkehrskontrolle (Air Traffic Control, ATC) können über das ODT Zusätze und Nachträge zur Diskussion und eventuellen Annahme vorgeschlagen werden. Diese Anforderungen werden entweder als Nachtrag angefügt oder in eine weitere Ausgabe des Dokuments eingearbeitet und den festgelegten Verfahren zwecks Bestätigung und Annahme unterzogen.

4. Redaktionelle Regeln

Zur Kennzeichnung des Status der einzelnen Aussagen wurde nach folgender Regel verfahren: Normative Elemente erscheinen im Text ohne weitere Hervorhebung. Elemente mit Empfehlungscharakter erscheinen ebenfalls ohne Hervorhebung in Kursivschrift, doch geht ihnen zur Kennzeichnung des Status die Angabe "Empfehlung" voraus.

Bei der Formulierung der Spezifikationen ist nach folgender Regel verfahren worden: Im Zusammenhang mit den normativen Elementen wird im Deutschen meist das Verb "müssen" in der jeweiligen Form verwendet (im Englischen steht an dieser Stelle "shall"). Zur deutlicheren Hervorhebung im Deutschen diesen Sätzen die Abkürzung "NE" (für normatives Element) vorangestellt. Elemente mit Empfehlungscharakter enthalten das Verb "sollte". Sie sind kursiv gedruckt.

Anmerkungen erscheinen in Normalschrift mit vorangestelltem Präfix "ANMERKUNG".

5. Beziehung zur Ausgabe 1 der Eurocontrol-Norm für den Online-Datenaustausch

Dieses Dokument ersetzt die Teile 1 und 2 der Ausgabe 1 der Eurocontrol-Norm für den Online-Datenaustausch. Teil 3, der die zu verwendenden technischen Protokolle beschreibt, wird durch die Eurocontrol-Norm für den Flugdatenaustausch - Interface-Control-Dokument, Teil 1 - ersetzt.

6. Wichtige Änderungen gegenüber Ausgabe 1

Nachstehend die wichtigsten Änderungen und Zusätze gegenüber Ausgabe 1:

1. Einarbeitung folgender komplementärer (nicht-obligatorischer) Meldungen in bezug auf das Grundverfahren:

- Koordinationsabbruchmeldung (MAC);

- Code-Zuweisungsmeldung (COD) des Rundsicht-Sekundärradars (SSR);

- Informationsmeldung (INF).

2. Definition von Inhalt und Format der Meldung zur Unterstützung der Ueberquerung einer Grenze auf einem Kurs, der nicht als ATS-Strecke, jedoch durch Anfangs- und Endpunkt des Streckenabschnitts definiert ist.

3. Einbeziehung eines Dialogverfahrens, das folgendes ermöglicht:

- Ermittlung und Verhandlung nicht normgerechter Übergabebedingungen durch Lotsen mit Planungsfunktion;

- Bereitstellung der Möglichkeit für die übernehmende FS-Stelle, Gegenvorschläge zu den Übergabebedingungen zu unterbreiten;

- Bereitstellung von Leistungsmerkmalen zur Kommunikationsübergabe als Bestandteil des Kontrollübergabeverfahrens.

4. Es wird die Verwendung des in Ausgabe 2 des Eurocontrol-Normendokuments für die Darstellung des Datenaustauschs in der Flugsicherung (ADEXP) beschriebenen Formats eingeführt. Sämtliche für das Grundverfahren festgelegten sowie während der Koordinationsphase des Dialogverfahrens verwendeten Meldungen werden sowohl im Format der Internationalen Luftfahrtorganisation (ICAO) als auch im ADEXP-Format beschrieben. Die im Rahmen des Dialogverfahrens verwendeten Kommunikationsübergabemeldungen werden nur unter Verwendung des ADEXP-Formats beschrieben.

5. Folgende Anhänge der Ausgabe 1 wurden gestrichen:

A: ATC Unit Identification.

B: OLDI Message Structure

(zu allen in Ausgabe 3 beschriebenen Meldungen sind Beispiele angeführt).

D: Historical Overview.

E: Implementation Plan.

F: Compliance by States.

G: Guidelines for Implementation.

H: Guidelines for Evaluation of OLDI.

6. Trennung des Teils 3 - Technische Anforderungen - von der Anwendungsspezifikation.

7. Beziehung zu anderen Dokumenten

Das vorliegende Dokument verweist auf die Verwendung zweier Arten von Feldformaten zur Kompilierung der Meldungen; dabei handelt es sich um die Formate ICAO und ADEXP.

Die ICAO-Feldformate werden im Verweisdokument 1 beschrieben. Sollte Verweisdokument 1 durch ein anderes Dokument ersetzt werden, gilt für die Definition der ICAO-Feldarten die in jenem Dokument vorgenommene Beschreibung.

Die ADEXP-Feldformate werden im Verweisdokument 2 beschrieben.

ANMERKUNG

Die Verweisdokumente sind in Abschnitt 2 aufgelistet.

8. Sprache

Die Originalversion dieses Dokuments wurde in englischer Sprache verfasst.

1. EINLEITUNG

1.1. Zweck

1.1.1. Flüge, die dem Flugverkehrskontrolldienst (ATC-Dienst) unterliegen, werden auf eine Art und Weise, die vollständige Sicherheit gewährleistet, von einer Flugverkehrskontrollstelle an die nächste übergeben. Um dieses Sicherheitsziel zu erreichen, wird in der Regel so vorgegangen, dass das Überfliegen der Grenze zwischen den Zuständigkeitsgebieten beider Stellen im voraus von diesen Stellen untereinander koordiniert und die Flugkontrolle dann übergeben wird, wenn sich der Flug an bzw. nahe dieser Grenze befindet.

1.1.2. Sofern dies per Telefon erfolgt, ist das Weiterreichen von Daten zu den einzelnen Flügen als Teil des Koordinationsprozesses eine wichtige Support-Aufgabe der Flugverkehrskontrollstellen, insbesondere der Bezirkskontrollstellen (ACC). Mit der operationellen Nutzung von Verbindungen zwischen den Flugdatenverarbeitungssystemen (FDPS) der ACC als Ersatz für derartige mündliche "Einschätzungen" (als Online-Datenaustausch (OLDI) bezeichnet), wurde in Europa zu Anfang der achtziger Jahre begonnen.

1.1.3. Zur Erleichterung der praktischen Umsetzung wurden allgemeine Regeln und Nachrichtenformate erarbeitet und zwischen den betroffenen Instanzen vereinbart sowie in die Ausgabe 1 der Eurocontrol-Norm für den Online-Datenaustausch eingearbeitet. Das vorliegende Dokument, Ausgabe 2.2, wurde zur weiterführenden Entwicklung solcher Leistungsmerkmale in Übereinstimmung mit den Anforderungen des EATCHIP-Programms erstellt.

1.2. Geltungsbereich

1.2.1. In diesem Dokument werden die Leistungsmerkmale und Meldungen spezifiziert, die zwischen den FDPS der Flugverkehrskontrollstellen bereitzustellen sind, um folgende Zwecke zu erreichen:

- die erforderliche Koordination, die der Übergabe der Flüge von einer Stelle zur nächsten vorausgehen muss;

- die Übergabe der Kommunikation solcher Flüge.

1.2.2. Dieses Dokument:

- definiert die Nachrichtenformate und die Regeln für deren Inhalt;

- beschreibt die in solchen Stellen benötigten Leistungsmerkmale, die Voraussetzung für die Nutzung des Datenaustauschs zu diesem Zwecke sind.

1.2.3. Diese Norm ist unter den Mitgliedstaaten von Eurocontrol auf internationale OLDI-Leistungsmerkmale zwischen Stellen, die einen ATC-Dienst für ein Gebiet bereitstellen, anwendbar.

1.2.4. Empfehlung

Den Staaten der Europäischen Zivilluftfahrtkonferenz (European Civil Aviation Conference, ECAC) wird die Anwendung dieser Norm auf

- internationale OLDI-Leistungsmerkmale zwischen Stellen, die für ein Gebiet innerhalb des ECAC-Gebiets einen ATC-Dienst bereitstellen;

- OLDI-Leistungsmerkmale zwischen Stellen, die nur innerhalb des betreffenden Staates einen ATC-Dienst für ein Gebiet bereitstellen, empfohlen.

2. VERWEISE

2.1. Die folgenden Dokumente enthalten Bestimmungen, die durch Verweis im vorliegenden Text Bestimmungen dieses Eurocontrol-Normendokuments darstellen.

Zum Zeitpunkt der Veröffentlichung dieses Eurocontrol-Normendokuments waren die für die Verweisdokumente angegebenen Ausgaben gültig.

Jede Überarbeitung der Verweisdokumente der Internationalen Zivilluftfahrt-Organisation (ICAO) gilt unmittelbar als Überarbeitung dieses Eurocontrol-Normendokuments.

Überarbeitungen der anderen Verweisdokumente werden erst zum Bestandteil der Bestimmungen dieses Eurocontrol-Normendokuments, wenn sie formal überprüft und in dieses Eurocontrol-Normendokument eingearbeitet worden sind.

Bei Widersprüchen zwischen den Anforderungen dieses Eurocontrol-Normendokuments und dem Inhalt dieser anderen Verweisdokumente hat dieses Eurocontrol-Normendokument den Vorrang.

2.2. Auf folgende Dokumente wird in diesem Normendokument verwiesen:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services, ICAO-Dokument 4444, Dreizehnte Ausgabe vom 7. Nov. 1996, aktuelle Fassung.

2. Ausgabe 2.0 des Eurocontrol-Normendokuments für die Darstellung des Datenaustausches in der Flugsicherung (ADEXP), Verweis DPS-ET1-ST09-STD-01-00, vom Juni 1998.

3. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN

3.1. Definitionen

Im Sinne dieses Eurocontrol-Normendokuments gelten die folgenden Definitionen.

3.1.1. Übernehmende FS-Stelle: die einen ATC-Dienst bereitstellende Stelle, die die Kontrolle über einen Flug übernehmen soll bzw. übernommen hat, wenn die Übergabe von einer Stelle zur nächsten stattfinden soll bzw. stattgefunden hat.

3.1.2. Bestätigung: Benachrichtigung, dass eine Meldung erhalten und als korrekt verarbeitbar erkannt wurde.

3.1.3. Aktivierung: Vorgang in einer übernehmenden Flugverkehrskontrollstelle, mittels dessen der Flugplan für den betreffenden Flug durch Einbeziehung der von der übergebenden Stelle als Teil des Koordinationsprozesses zwischen beiden Stellen übermittelten Daten aktualisiert wird und in dessen Ergebnis die Daten den Fluglotsen zur Verfügung gestellt werden.

3.1.4. Flughöhe: Die vertikale Entfernung einer Fläche, eines Punktes bzw. eines als Punkt betrachteten Objekts über dem mittleren Meeresspiegel.

3.1.5. Anwendung: Derjenige Teil eines ATS-Teilsystems, der dieser Norm entspricht und die Schnittstelle zu ebensolchen Instanzen in anderen ATS-Systemen darstellt.

3.1.6. Zuständigkeitsgebiet: Ein Luftraum genau festgelegter Abmessungen, innerhalb dessen eine ATC-Stelle Flugverkehrsdienste bereitstellt.

3.1.7. Zuordnung: Ein Verfahren, mit dem ein System eine empfangene OLDI-Meldung mit einer Flugplaneingabe in einer Datenbank verknüpft.

3.1.8. Flugverkehrskontrollstelle: Stelle, die einen Flugverkehrskontrolldienst bereitstellt.

3.1.9. Verfügbarkeit: Wahrscheinlichkeit, dass ein Leistungsmerkmal zu einer gegebenen Zeit einem Nutzer zugänglich ist.

3.1.10. Grenze: Die Ebenen (lateral und vertikal), die das Zuständigkeitsgebiet einer Flugverkehrskontrollstelle abgrenzen.

3.1.11. Freigegebene Flugfläche: Flugfläche, zu der bzw. auf der für einen Flug aktuell die Freigabe durch die Flugverkehrskontrolle erfolgt ist.

3.1.12. Koordinierung, ATC: Der zwischen Flugverkehrskontrollstellen mit unmittelbar benachbarten Zuständigkeitsgebieten ausgeführte Vorgang der gegenseitigen formellen Benachrichtigung über die geplante Grenzpassage eines Fluges, um die Flugsicherheit durch Konsistenz der beabsichtigten Handlungen zu gewährleisten.

3.1.13. Koordinationsmeldung: Oberbegriff für Meldungen, die der ATC-Koordination dienen. Dazu zählt auch die spezifische Meldung CDN, die in Absatz 8.8 beschrieben ist.

3.1.14. Koordinationsphase: In bezug auf einen gegeben Flug die Phase, während der die übergebende und die übernehmende Flugverkehrskontrollstelle die Bedingungen (z. B. Flugfläche, Grenzpunkt) vereinbaren, unter denen ein Flug von der Kontrolle der einen Stelle zur Kontrolle der anderen übergeht.

3.1.15. Koordinationspunkt: Ein Punkt an bzw. nahe der Grenze, der den Flugverkehrskontrollstellen in einer Koordinationssequenz bekannt ist und auf den in Koordinationsmeldungen Bezug genommen wird.

3.1.16. Korrelation: Auf festgelegten Kriterien der Verknüpfung von Flugplandaten und Radarkurs desselben Fluges beruhender Vorgang, üblicherweise zur Darstellung auf dem Monitor eines Lotsen.

3.1.17. Eurocontrol-Norm: Alle Spezifikationen für physische Eigenschaften, Konfiguration, Werkstoffe, Leistung, Personal oder Verfahren, deren einheitliche Anwendung für die Implementierung in ATS-Systemen innerhalb der Eurocontrol-Mitgliedstaaten als wesentlich bestätigt wurde. Eine Eurocontrol-Norm darf nicht im Widerspruch zu ICAO-Normen stehen, sondern sollte letztere gegebenenfalls ergänzen.

3.1.18. Chef-Fluglotse: Ein Flugotse, der unter seiner Kontrolle stehenden Flügen direkt Anweisungen erteilt. Dazu zählen auch diejenigen Lotsen, die für ein Gebiet Radarkontrolldienste erbringen.

3.1.19. Ausflugfläche: Die Fläche, auf der ein Flug der Koordination zufolge einen Kontrollübergabepunkt passieren soll. Eine Ausflugfläche kann zusätzliche Passagebedingungen einschließen, mit denen das Flächenband, in dem sich ein Steig-/Sinkflug befinden wird, festgelegt wird.

3.1.20. Flugplan: Den Flugverkehrsdienststellen bezüglich des beabsichtigten Fluges oder Flugabschnitts eines Luftfahrzeugs gelieferte Informationen. Darüber hinaus Informationen, die aus dem in einem FDPS vorgehaltenen Flugplan eines spezifischen Flugs abgeleitet wurden.

3.1.21. Generieren: In einem Flugverkehrskontrollsystem ablaufender Prozess, bei dem relevante Daten aus der Datenbank bzw. den Datenbanken herausgezogen werden und eine Meldung zur Übersendung an eine übernehmende Flugverkehrskontrollstelle entsteht.

3.1.22. ICAO-Format: Das für die Boden-Boden-Übermittlung von ATS-Meldungen genutzte Format, welches die in Verweis 1 beschriebenen Feldtypen und Staffelungen verwendet.

3.1.23. Fläche: Ein Oberbegriff, der sich auf die vertikale Position eines im Flug befindlichen Luftfahrzeugs bezieht. Wo die Bezeichnung Fläche bzw. Flugfläche im Rahmen dieser Norm verwendet wird, schließt sie die Flughöhe über Meer ein.

3.1.24. Benachrichtigung: Vorgang, bei dem die übergebende Stelle zwecks Aktualisierung des Systems der übernehmenden Stelle in Vorbereitung der Koordinationsphase Daten übermittelt.

3.1.25. Übernehmende Stelle: Diejenige Flugverkehrskontrollstelle, der eine Meldung übermittelt wird.

3.1.26. Verlässlichkeit: Anteilige Zeit der planmäßigen Verfügbarkeit, während der ein Dienst bereitstehen soll.

3.1.27. Angeforderte Flugfläche: Eine vom Flug im Flugplan angeforderte Flugfläche.

3.1.28. Revision: Eine Änderung von Daten, die bereits zuvor von der übergebenden Flugverkehrskontrollstelle an die übernehmende Flugverkehrskontrollstelle gesendet wurden.

3.1.29. Zusätzliche Überflugfläche: Fläche auf oder über bzw. auf oder unter der ein Flug der Koordination zufolge den Kontrollübergabepunkt passieren soll. Die zusätzliche Fläche, sofern gegeben, ist ein Element der Ausflugfläche.

3.1.30. Systemflugplan: Aus dem Flugplan eines spezifischen Fluges, der in einem FDPS vorgehalten ist, abgeleitete Information.

3.1.31. Transaktionszeit: Ein der Einleitung einer Meldung folgendes Zeitintervall, innerhalb dessen Übermittlung, Erstverarbeitung im empfangenden System, Generierung und Übermittlung einer Bestätigungsmeldung sowie deren Identifizierung im übergebenden System stattfinden.

3.1.32. Kontrollübergabepunkt: Ein festgelegter, auf dem Flugweg eines Luftfahrzeugs angesiedelter Punkt, an dem die Verantwortung für die Bereitstellung des Flugverkehrsdienstes für das Luftfahrzeug von einer Flugverkehrskontrollstelle bzw. Kontrollposition an die nächste übergeben wird. Er muss nicht unbedingt mit dem Koordinationspunkt identisch sein.

3.1.33. Übergabephase: Eine auf die Koordinationsphase folgende Flugphase, während der die Kommunikationsübergabe erfolgt.

3.1.34. Übergebende Stelle: Flugverkehrskontrollstelle, die in einer Koordinationssequenz für die Bereitstellung eines Dienstes für einen Flug vor der Grenze zuständig ist und die Koordinationsphase mit der nächsten Stelle einleitet.

3.1.35. Übertragen: Das Kommunizieren einer Meldung von einem System zum anderen.

3.1.36. Stelle: Luftverkehrsdienststelle

3.1.37. Warnung: An einem Lotsenplatz dargestellte Meldung bei Nichtgelingen des automatischen Koordinationsprozesses.

3.2. Symbole und Abkürzungen

Im Sinne dieser Eurocontrol-Norm gelten die folgenden Symbole und Abkürzungen.

ABI Advance Boundary Information Message - Vorabinformationen über die Grenzpassage

ACC Area Control Centre - Bezirkskontrollstelle

ACP Accept Message - Annahmemeldung

ACT Activate Message - Aktivierungsmeldung

ADEXP ATS Data Exchange Presentation - Darstellung des ATS-Datenaustauschs

ATC Air Traffic Control - Flugverkehrskontrolle, Flugsicherung

ATM Air Traffic Management - Flugverkehrsmanagement

ATS Air Traffic Service - Flugverkehrsdienst

CDN Co-ordination Message - Koordinationsmeldung

CNL Flight Plan Cancellation - Flugplanaufhebung

COD SSR Code Assignment Message - SSR-Code-Zuweisung

COF Change of Frequency Message - Frequenzwechsel

COP Co-ordination Point - Koordinationspunkt

DED Directorate of EATCHIP Development, Eurocontrol - Direktorat für die EATCHIP-Entwicklung, Eurocontrol

EATCHIP European ATC Harmonisation and Integration Programme - Programm für die Harmonisierung und Integration der Flugsicherung in Europa

ECAC European Civil Aviation Conference - Europäische Zivilluftfahrt-Konferenz

ETO Estimated Time Over - Geschätzte Zeit über (einem bestimmten Punkt)

ETOT Estimated Take-Off Time - Voraussichtliche Abflugzeit

EWPD EATCHIP Work Programme Dokument - Dokument des EATCHIP-Arbeitsprogramms

FDPS Flight Data Processing System - Flugdatenverarbeitungssystem

FRF Further Route of Flight - Weitere Flugstrecke

HMI Human-Machine Interface - Mensch-Maschine-Schnittstelle

HOP Handover Proposal Message - Hand-Over-Vorschlag

ICAO International Civil Aviation Organisation - Internationale Zivilluftfahrtorganisation

INF Information Message - Informationsmeldung

LAM Logical Acknowledgement Message - Logische Bestätigungsmeldung

LoA Letter of Agreement

MAC Message for the Abrogation of Co-ordination - Koordinationsabbruchmeldung

MAS Manual Assumption of Communications - Manuelle Kommunikationsübernahme

NM Nautical Mile - Seemeile

OLDI On-Line Data Exchange - Online-Datenaustausch

ORCAM Originating Region Code Assignment Method - Methode der Code-Zuweisung zur Ursprungsregion

PAC Preliminary Activate Message - Vorläufige Aktivierung

RAP Referred Activate Proposal Message - Verwiesener Aktivierungsvorschlag

REV Revision Message - Revisionsmeldung

RJC Reject Co-ordination Message - Koordinationsablehnung

ROF Request on Frequency Message - Frequenzanforderungsmeldung

RRV Referred Revision Message - Verwiesene Revision

SBY Stand-by Message - Stand-By-Meldung

SDM Supplementary Data Message - Zusatzdatenmeldung

SSR Secondary Surveillance Radar - Rundsicht-Sekundärradar

SYSCO System Supported Co-ordination - Systemgestützte Koordination

TI Transfer Initiation - Übergabeeinleitung

TIM Transfer Initiation Message - Übergabeeinleitungsmeldung

TWR/APP Tower (aerodrome control) and Approach Control - Flughafen- und Anflugkontrolle

4. ALLGEMEINE ANFORDERUNGEN

4.1. Einführung

Dieser Abschnitt beschreibt die allgemeinen operationellen Anforderungen an die Implementierung eines OLDI-Leistungsmerkmals zwischen Flugverkehrskontrollstellen sowie die Klassifizierung und Leistungsanforderungen der verschiedenen für OLDI genutzten Arten von Meldungen.

4.2. Anforderungen an das Flugdatenverarbeitungssystem (FDPS)

4.2.1. Flugdatenbank

(NE) Stellen, die ein in diesem Dokument beschriebenes Leistungsmerkmal nutzen, erhalten von einem FDPS Daten, die sämtliche für die Anzeige, Verarbeitung und Kompilierung der Meldungen entsprechend den Festlegungen benötigten Informationen enthalten. Die vorrangige Datenquelle für jeden Flug ist der Flugplan, der durch den verantwortlichen Flugzeugführer bzw. in seinem Namen eingereicht wurde. Weitere Daten werden aus der Verarbeitung der Flugpläne im Hinblick auf die Umgebung der betreffenden Stelle gewonnen.

4.2.2. Echtzeit-Operation

Das OLDI-Verfahren beinhaltet Ereignisse in der übergebenden Flugverkehrskontrollstelle, mit denen Funktionen eingeleitet werden, die für die rechtzeitige Darstellung von Daten beim übergebenden Lotsen und die Übermittlung von Koordinationsdaten zur übernehmenden Stelle erforderlich sind. (NE) Zu diesem Zweck muss das FDPS in der Lage sein, Funktionen durch den Vergleich der Koordinierten Weltzeit und anwendbaren Zeitparameter mit Zeiten an festgelegten, aus der Flugdatenbank bestimmten Positionen auf der Flugstrecke zu vergleichen.

4.2.3. Datenkommunikationsfähigkeit

4.2.3.1. (NE) Das FDPS muss in der Lage sein, Flugdaten in dem Format, das auf die Meldung gemäß Festlegung in diesem Dokument anwendbar ist, über ein die OLDI-Funktion unterstützendes Datenkommunikationsmedium zu empfangen und zu übermitteln

4.2.3.2. Empfehlung

Das FDPS sollte über das notwendige Erweiterungspotential verfügen, um neue Meldungen, die in künftigen Ausgaben dieser Norm enthalten sein könnten, aufzunehmen.

4.2.3.3. (NE) Im Rahmen der in diesem Dokument festgelegten Leistungsanforderungen muss das Datenkommunikationsmedium einen schnellen und zuverlässigen Datenaustausch von Anwendung zu Anwendung bereitstellen, und zwar durch:

- Gewährleistung der Integrität der Übermittlung von OLDI-Meldungen;

und

- Überwachung entweder der Punkt-zu-Punkt-Verbindungen oder des Kommunikationsnetzstatus.

4.2.3.4. (NE) Bei Erkennen von Anomalien durch das Daten-Kommunikationssystem muss das FDPS die die Lotsenplätze warnen.

4.2.4. Anwendungsfunktionen

4.2.4.1. (NE) Für die Bereitstellung von OLDI-Leistungsmerkmale genutzte Systeme müssen in der Lage sein, OLDI-bezogene Daten in Echtzeit automatisch zu empfangen, zu speichern, zu verarbeiten, zu extrahieren und zur Anzeige weiterzuleiten sowie zu übermitteln.

4.2.4.2. (NE) Das FDPS muss:

- die laufenden operationellen Daten wiedergeben, die für die OLDI-Funktion gemäß Forderung dieser Norm maßgeblich sind und die entweder automatisch oder durch manuelle Eingabe bzw. eine Kombination von beidem aktualisiert werden;

- fähig sein, solche Elemente aus der Flugplandatenbank zu extrahieren;

- die nächste Flugverkehrskontrollstelle auf der Flugstrecke ermitteln.

4.2.4.3. (NE) Folgendes ist zweiseitig zu vereinbaren:

- Koordinationspunkte (COP);

- Bezugspunkte für Kurs- und Entfernungsnotationen zur Identifizierung des COP auf direkten, vom ATS nicht betreuten Streckenabschnitten (so weit zutreffend).

ANMERKUNG

Die COP brauchen nicht in jedem Fall mit den Kontrollübergabepunkten übereinzustimmen.

4.2.5. Mensch-Maschine-Schnittstelle (HMI)

4.2.5.1. (NE) Die HMI muss in der Lage sein,

- die operationellen Inhalte von OLDI-Meldungen sowie relevante Warnungen in Bezug auf empfangene Meldungen zur unmittelbaren Beachtung anzuzeigen;

- Koordinations- und Übergabemeldungen an die für die Koordination der betreffenden Flüge verantwortlichen Positionen weiterzuleiten.

4.2.5.2. (NE) Dem ATC-Personal muss ein Mittel zur Modifizierung der Daten, aus denen die operationellen Inhalte der Meldungen gemäß Forderung in diesem Dokument abgeleitet werden, zur Verfügung stehen.

4.2.5.3. (NE) Die HMI muss anzeigen, dass die Übermittlung der Meldung im Gange ist bzw. gegebenenfalls erfolgreich abgeschlossen wurde.

4.2.5.4. (NE) Wird innerhalb der Parameterzeit nach Übermittlung einer Koordinations- bzw. Übergabemeldung keine Bestätigung empfangen, muss automatisch eine Warnung oder Benachrichtigung der zuständigen ATC bzw. technischen Position(en) generiert werden.

4.2.5.5. (NE) Eine derartige Warnung bzw. Benachrichtigung muss in einer Form erfolgen, die unmittelbar die Aufmerksamkeit des zuständigen Lotsenplatzes erregt.

4.2.5.6. Empfehlung

Die HMI an ATC-Positionen, die OLDI einsetzen, sollte bei Nichtverfügbarkeit des OLDI-Leistungsmerkmals eine Warnung ausgeben.

4.2.6. Einleitung von Meldungen

4.2.6.1. (NE) Jedes System muss Systemparameter zur Gewährleistung der rechtzeitigen automatischen Einleitung von OLDI-Meldungen enthalten.

4.2.6.2. Empfehlung

Es sollte die Fähigkeit gegeben sein, die Übermittlung einer Koordinationsmeldung bereits vor der kalkulierten Übermittlungszeit manuell einzuleiten.

4.2.6.3. (NE) Das automatische Ereignis muss stets gewährleistet sein für den Fall, dass die manuelle Einleitung nicht ausgeführt wird.

4.2.6.4. (NE) Das System muss Zeitparameter verwenden, um folgendes zu definieren:

- Vorlaufzeit vor Übermittlung, zu der die operationellen Inhalte der Meldungen bei der übermittelnden Stelle angezeigt werden;

- global oder für den einzelnen COP die Vorlaufzeit für die Übermittlung der Meldung (so weit zutreffend);

- Zeitspanne nach Übermittlung einer Meldung, innerhalb derer eine Bestätigung auf der Anwendungsebene eingehen muss (Time-Out).

4.2.6.5. (NE) Die Übermittlung einer Meldung muss unverzüglich erfolgen, wenn die angeforderte Information erst zu einem späteren als dem eigentlich für die Übermittlung vorgesehen Zeitpunkt vorliegt.

Beispiel:

Ein Flug beginnt an einem Punkt nahe der zu durchfliegenden Grenze einen GAT IFR-Abschnitt (Allgemeiner Luftverkehr - Instrumentenflugregeln); die ETO für diesen Punkt wird 8 Minuten vor dem COP übermittelt, wobei die Übermittlung der ACT-Meldung dem/den anwendbaren Zeitparameter(n) zufolge zu diesem Zeitpunkt bereits verspätet ist; die Meldung wird also unverzüglich gesendet.

4.2.7. Empfang von Meldungen

4.2.7.1. (NE) Das Flugsicherungssystem muss in der Lage sein,

- OLDI-Meldungen zu empfangen;

- sie entsprechend dieser Norm automatisch zu verarbeiten;

- Flugdaten in Übereinstimmung mit der empfangenen Meldung auszugeben und im Fall von Ungereimtheiten bei den empfangenen Daten die erforderlichen Warnungen anzuzeigen;

- Bestätigungsmeldungen automatisch auf der Anwendungsebene zu generieren und zu übermitteln.

4.2.7.2. (NE) Eine Bestätigungsmeldung (Logische Bestätigungsmeldung (LAM), Annahmemeldung (ACP) oder Stand-by-Meldung (SBY)) muss generiert und übermittelt werden, wenn die entsprechende Meldung verarbeitet und die Darstellung der Ergebnisse der Verarbeitung je nach Notwendigkeit an der/den zuständigen Position(en) gewährleistet ist.ANMERKUNG

Die genauen Bedingungen für die Generierung einer Bestätigung werden für jede Meldung einzeln festgelegt.

4.3. Aktualisierung anhand Überwachungsdaten

Empfehlung

Um die Genauigkeit von Zeitschätzdaten zu gewährleisten, sollten aus der Kursüberwachung von Flügen durch Radar oder andere Rundsichtmethoden abgeleitete Informationen zur Aktualisierung der Flugplandatenbank genutzt werden.

4.4. Aufzeichnen von OLDI-Daten

4.4.1. Inhalt

(NE) Der Inhalt jeder OLDI-Meldung und die Zeit des Empfangs werden aufgezeichnet.

4.4.2. Leistungsmerkmale

(NE) Für Abruf und Anzeige der aufgezeichneten Daten müssen entsprechende Leistungsmerkmale zur Verfügung stehen.

4.5. Verfügbarkeit, Verlässlichkeit, Datensicherheit und Datenintegrität

4.5.1. Verfügbarkeit

4.5.1.1. (NE) Das OLDI-Leistungsmerkmal zwischen den betreffenden zwei Stellen muss während der Zeiten des normalen und des maximalen Verkehrsaufkommens verfügbar sein.

4.5.1.2. Empfehlung

Das OLDI-Leistungsmerkmal sollte täglich rund um die Uhr verfügbar sein.

4.5.1.3. (NE) Etwaige geplante Abschaltzeiten (und somit die geplante Verfügbarkeit) müssen von den betreffenden zwei Stellen gemeinsam vereinbart werden.

4.5.2. Verlässlichkeit

4.5.2.1. (NE) Die Verlässlichkeit an jedem OLDI-Link muss mindestens 99,86 % (entspricht einer Ausfallzeit von höchstens 12 Stunden, ausgehend von einer Verfügbarkeit rund um die Uhr) betragen.

4.5.2.2. Empfehlung

Wo dies operationell gerechtfertigt ist, sollte eine Verlässlichkeit von mindestens 99,99% (entspricht einer Ausfallzeit von höchstens 52 Minuten pro Jahr, ausgehend von einer Verfügbarkeit rund um die Uhr) gegeben sein.

4.5.3. Datensicherheit

Empfehlung

Methoden der Datensicherung (z. B. Zugriffsrechte, Quellenverifizierung) und, wo zutreffend, des Netzmanagements sollten auf OLDI-Leistungsmerkmale Anwendung finden.

4.5.4. Datenintegrität

(NE) Die Störhäufigkeit auf der Anwendungsebene darf einen Übermittlungsfehler je 2000 Meldungen nicht übersteigen.

4.6. Operationelle Bewertung

4.6.1. Bewertungszeitraum

(NE) Jedes neue OLDI-Leistungsmerkmal, auch ein neues Leistungsmerkmal auf einem bereits vorhandenen Link, muss vor der Betriebsaufnahme zum Nachweis der Datenintegrität, Genauigkeit, Leistungsfähigkeit, Kompatibilität zu sonstigen ATC-Verfahren sowie der allgemeinen Sicherheit einem Bewertungszeitraum unterzogen werden.

ANMERKUNG

Ein Verfahren zur Unterstützung bei der Bewertung eines neuen OLDI-Leistungsmerkmals wird vom OLDI-Sekretariat, Eurocontrol, angeboten.

4.6.2. Datum der Betriebseinführung

(NE) Das Datum der Betriebseinführung ist zwischen den beiden Stellen formell zu vereinbaren, wobei der Bewertungszeitraum abgeschlossen sein muss.

5. KATEGORIEN VON MELDUNGEN

5.1. Allgemein

5.1.1. Zweck

Dieser Abschnitt des Dokuments:

- definiert die Kategorien von Meldungen;

- legt Anforderungen an die Transaktionszeiten für die Kategorien dar;

- legt dar, welche Meldungen obligatorisch und welche komplementär sind;

- weist den Kategorien bestimmte Arten von Meldungen zu.

5.1.2. Kategorien von Meldungen

Den OLDI-Meldungen wurden folgenden Kategorien zugewiesen:

- Kategorie 1: Kommunikationsübergabe;

- Kategorie 2: Koordination;

- Kategorie 3: Benachrichtigung.

5.2. Transaktionszeiten

5.2.1. Bedingungen für Transaktionszeiten

5.2.1.1. Die festgelegten Transaktionszeiten schließen Übermittlung, Erstverarbeitung bei der übernehmenden Stelle, Erstellung einer Bestätigungsmeldung, deren Übermittlung sowie deren Empfang bei der übergebenden Stelle ein. Die automatischen Bestätigungsmeldungen LAM und SBY wurden deshalb keiner Kategorie von Meldungen zugeordnet.

5.2.1.2. (NE) Die maximalen Transaktionszeiten für die verschiedenen Kategorien von Meldungen müssen der Festlegung in Tabelle 5-1 genügen.

Tabelle 5-1

Maximale Transaktionszeiten

>PLATZ FÜR EINE TABELLE>

5.2.1.3. Für jede Kategorie bzw. Art der Meldung ist ein Time-Out-Wert zu definieren.

5.2.1.4. (NE) Wird innerhalb der festgelegten Zeit nach Übermittlung keine Bestätigung empfangen, ist eine Meldung als nicht erfolgreich übermitteln bzw. verarbeitet anzusehen, und es ist eine Warnung wie im diesbezüglichen Abschnitt dieses Dokuments festgelegt auszugeben.

5.2.1.5. Empfehlung

Die Time-Out-Werte für die drei Kategorien sollten 12 Sekunden, 30 Sekunden bzw. 60 Sekunden nicht übersteigen.

5.3. Klassifizierung und Kategorisierung von Meldungen

5.3.1. Klassifizierung von Meldungen - obligatorisch und komplementär

5.3.1.1. In diesem Dokument beschriebene Meldungen sind entweder als obligatorisch oder als komplementär eingestuft.

5.3.1.2. (NE) Wird eine Meldung als obligatorisch (mandatory, M) für die Übermittlung (transmission, TX) beschrieben, muss der Verarbeitungsprozess unter anderem in der Lage sein, derartige Meldungen zu versenden.

5.3.1.3. (NE) Wird eine Meldung als obligatorisch für den Empfang (reception, REC) beschrieben, muss der Verarbeitungsprozess unter anderem in der Lage sein, auch empfangene Meldungen zu verarbeiten.ANMERKUNG

In Ausnahmefällen, in denen der Verkehrsfluss zwischen den beiden Stellen unidirektional abläuft, braucht der obligatorische Charakter für die Meldungen in nur einer Richtung zu gelten.

5.3.1.4. (NE) Wird eine Meldung als komplementär (complementary, C) für die Übermittlung beschrieben, muss der Verarbeitungsprozess unter anderem in der Lage sein, derartige Meldungen zu versenden, sofern dies durch die versendende Stelle gefordert und mit der übernehmenden Stelle bilateral vereinbart wurde.ANMERKUNG

Je nach den operationellen Anforderungen brauchen komplementäre Meldungen nur in einer Richtung anwendbar zu sein.

5.3.1.5. (NE) Wird eine Meldung als komplementär für den Empfang beschrieben, muss der Verarbeitungsprozess unter anderem in der Lage sein, in den Fällen, wo dies zwischen beiden Stellen vereinbart wurde, auch empfangene Meldungen zu verarbeiten.

5.3.1.6. Die in den Tabellen 5-3 und 5-4 beschriebenen Anforderungen gelten nur dort, wo der Einsatz des Dialogverfahrens für Koordination und/oder Kommunikationsübergabe bilateral zwischen Flugverkehrskontrollstellen vereinbart wurde.

5.3.2. Kategorisierung von Meldungen

5.3.2.1. Die Kategorisierung von Meldungen für das Grundverfahren ist in Tabelle 5-2 spezifiziert.

5.3.2.2. Die Kategorisierung der zusätzlichen Koordinationsmeldungen für das Dialogverfahren ist in Tabelle 5-3 spezifiziert.

5.3.2.3. Die Kategorisierung von Kommunikationsübergabemeldungen für das Dialogverfahren ist in Tabelle 5-4 spezifiziert.

Tabelle 5-2

Meldungen für das Grundverfahren

>PLATZ FÜR EINE TABELLE>

Tabelle 5-3

Dialogverfahren - Meldungen während der Koordinationsphase

(Zusätzlich zu Tabelle 5-2)

>PLATZ FÜR EINE TABELLE>

Tabelle 5-4

Dialogverfahren - Meldungen während der Übergabephase

>PLATZ FÜR EINE TABELLE>

6. GRUNDVERFAHREN - OBLIGATORISCHE MELDUNGEN

6.1. Allgemein

6.1.1. Anforderungsbeschreibung

In diesem Abschnitt werden die auf der Anwendungsebene vorhandenen Mindestanforderungen an die Implementierung von OLDI-Leistungsmerkmale beschrieben.

6.1.2. Implementierung

Stellen, die zur Koordination von Flügen OLDI nutzen, müssen die Meldungen ABI, ACT und LAM wie in diesem Abschnitt beschrieben implementieren, es sei denn, es liegt eine bilaterale Vereinbarung darüber vor, zur Koordination das Dialogverfahren einzusetzen wie in Abschnitt 8 dieses Dokuments beschrieben, in welchem Falle die Bedingungen für die Verwendung von ACT- und LAM-Meldungen der Festlegung in jenem Abschnitt 8 entsprechen.

6.2. Vorabinformationen über die Grenzpassage (ABI)

6.2.1. Zweck der ABI-Meldung

Die ABI erfuellt folgende operationelle Anforderungen:

- sorgt für die Erfassung fehlender Flugplandaten;

- stellt der nächsten Flugverkehrskontrollstelle Vorabinformationen über die Grenzpassage und entsprechende Revisionen zur Verfügung;

- aktualisiert die grundlegende Flugplandatenbank;

- erleichtert die frühzeitige Korrelierung von Radarkursen;

- erleichtert die exakte Beurteilung des kurzfristigen Verkehrsaufkommens für den Abschnitt.

Die ABI ist eine Hinweismeldung.

6.2.2. Bestandteile der Meldung

(NE) Die ABI-Meldung muss folgende Dateneinheiten enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- SSR-Modus und -Code (sofern vorhanden);

- Startflugplatz;

- Schätzdaten;

- Zielflugplatz;

- Luftfahrzeugmuster und -zahl;

- Flugstrecke (optional);

- sonstige Flugplandaten (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

6.2.3. Anwendungsregeln

6.2.3.1. Allgemein

6.2.3.1.1. (NE) Mit Ausnahme der nachstehend unter 6.2.3.1.3 und 6.2.3.1.4 genannten Fälle sind für jeden beabsichtigten Überflug der Grenzen von Zuständigkeitsgebieten nach OLDI-Verfahren eine oder mehrere ABI-Meldungen zu senden.

6.2.3.1.2. (NE) Im Falle des Versendens muss die ABI-Meldung der ACT-Meldung (Aktivierung) bzw. RAP-Meldung (verwiesener Aktivierungsvorschlag) vorausgehen.

6.2.3.1.3. (NE) Eine ABI-Meldung darf nicht generiert werden, wenn eine PAC-Meldung (vorläufige Aktivierung) zu senden ist.

6.2.3.1.4. Empfehlung

Die ABI-Übermittlung sollte unterdrückt werden, falls die ACT- bzw. RAP-Meldung sofort oder innerhalb eines bilateral vereinbarten Zeitintervalls zur Übermittlung ansteht.

ANMERKUNG

Zweck dieser Empfehlung ist es zu verhindern, dass an verschiedenen Positionen der übernehmenden Stelle gleichzeitig der Versuch erfolgt, Anomalien bezüglich ABI- und ACT-Meldungen für ein und denselben Flug aufzulösen.

6.2.3.1.5. (NE) Eine revidierte ABI-Meldung muss gesendet werden, falls die nachfolgende ACT-Meldung nicht generiert wurde und

- die Flugstrecke so modifiziert wurde, dass der in der vorhergehenden ABI-Meldung enthaltene COP nicht mehr stimmt;

- sich der Zielflugplatz geändert hat;

oder

- sich das Luftfahrzeugmuster geändert hat.

6.2.3.1.6. Empfehlung

Eine revidierte ABI-Meldung sollte gesendet werden, falls die darauffolgende ACT-Meldung noch nicht generiert wurde und eines der folgenden Elemente eine Änderung erfährt:

- die voraussichtliche Grenzüberflugshöhe;

- der voraussichtliche SSR-Code am Kontrollübergabepunkt;

- wenn die voraussichtliche Überflugzeit (ETO) am COP stärker als die im Letter of Agreement (LoA) festgelegte Zeitspanne von der vorausgehenden ABI-Meldung abweicht;

- sonstige bilateral vereinbarte Daten.

6.2.3.2. Verarbeitung bei der übernehmenden Stelle

6.2.3.2.1. (NE) Das eine ABI-Meldung empfangende Flugverkehrskontrollsystem muss die Assoziierung mit den entsprechenden Flugplandaten versuchen.

6.2.3.2.2. Hat die Assoziierung mit dem Flugplan keinen Erfolg, muss im empfangenden System ein Flugplan automatisch oder manuell erstellt werden.

6.2.3.2.3. (NE) Ist die Assoziierung mit dem Flugplan zwar erfolgreich, wird jedoch zwischen den in der Meldung enthaltenen Daten und den entsprechenden Daten im empfangenden System eine Diskrepanz erkannt, die bei Eingang der folgenden ACT-Meldung eine Korrekturhandlung erforderlich machen würde, ist diese Diskrepanz zur Auflösung an eine geeignete Position zu verweisen.

6.2.3.3. Zeitparameter für die Übermittlung

6.2.3.3.1. (NE) Die Meldung ist eine durch Parameter bestimmte Zahl von Minuten vor der voraussichtlichen Überflugzeit am COP zu übermitteln.

6.2.3.3.2. (NE) Der/die ABI-Generierungsparameter müssen im zwischen den betreffenden Flugverkehrskontrollstellen abgesprochenen LoA enthalten sein.

6.2.3.3.3. Empfehlung

Der/die ABI-Generierungsparameter sollten:

- variabel sein und auf den Festlegungen des LoA basieren;

- für jeden COP gesondert definiert werden.

6.2.4. Bestätigung von ABI

6.2.4.1. Bestätigung

(NE) Die ABI-Meldung muss durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

ANMERKUNG

Eine LAM-Meldung wird unabhängig vom Ergebnis des Versuchs der Assoziierung mit dem Flugplan generiert.

6.2.4.2. Nichtbestätigung

Empfehlung

Wird keine LAM-Meldung als Bestätigung für eine ABI-Meldung empfangen, sollte an einer Überwachungsposition eine Warnung angezeigt werden.

6.2.5. Beispiele

"Air 2000" 253, eine Boeing 757 von Malta nach Birmingham mit geschätztem BNE VOR um 1221 UTC, fliegt auf FL350 mit einer wahren Eigengeschwindigkeit von 480 Knoten; die Streckenführung ist über UB4 BNE UB4 BPK UB3 HON beabsichtigt, als Transponder wird A7012 genutzt, und Freigabe für FL390 wird erbeten. Es folgen äquivalente Beispiele für die von Reims zum ACC London gesendete ABI-Meldung.

6.2.5.1. ICAO

(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.2.5.2. ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.3. Aktivierungsmeldung (ACT)

6.3.1. Zweck der ACT-Meldung

Die ACT-Meldung erfuellt folgende operationelle Anforderungen:

- Sie ersetzt die verbale Grenzüberflugvoraussage durch automatisches Übertragen der Einzelheiten zu einem Flug von einer Flugverkehrskontrollstelle zur nächsten noch vor Übergabe der Kontrolle;

- sie aktualisiert die grundlegenden Flugplandaten bei der übernehmenden Flugverkehrskontrollstelle mit den neuesten Informationen;

- sie erleichtert die Verteilung von Flugplandaten an die einbezogenen Lotsenplätze bei der übernehmenden Flugverkehrskontrollstelle sowie der Anzeige dieser Daten;

- sie beschleunigt die Anzeige der Rufzeichen-/Code-Korrelierung bei der übernehmenden Flugverkehrskontrollstelle;

- sie schafft die Bedingungen zur Übergabe an die übernehmende Flugverkehrskontrollstelle.

6.3.2. Bestandteile der Meldung

(NE) Die ACT-Meldung muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- SSR-Modus und -Code

- Startflugplatz;

- Schätzdaten;

- Zielflugplatz;

- Luftfahrzeugmuster und -zahl;

- Flugstrecke (optional);

- sonstige Flugplandaten (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

6.3.3. Anwendungsregeln

6.3.3.1. Allgemein

6.3.3.1.1. (NE) Für die in Frage kommenden, die Grenze passierenden Flüge muss mit Ausnahme der Festlegungen in Absatz 6.3.3.1.10 eine ACT-Meldung übermittelt werden.

6.3.3.1.2. (NE) Die ACT-Meldung muss zur errechneten Zeit entsprechend der LoA-Festlegung automatisch generiert und übermittelt werden, es sei denn, die Einleitung erfolgte bereits zu einem früheren Zeitpunkt manuell.

6.3.3.1.3. Empfehlung

Dem ATC-Personal sollte ein Hilfsmittel zur Verfügung stehen, um die Übermittlung von ACT Meldungen bereits vor der errechneten Übermittlungszeit auslösen zu können.

6.3.3.1.4. (NE) Der operationelle Inhalt der zu übermittelnden ACT-Meldung muss vor der eigentlichen Übermittlung an dem für die Koordination des Flugs verantwortlichen Lotsenplatz angezeigt werden.

6.3.3.1.5. Empfehlung

Bezüglich 6.3.3.1.4 sollte gemeinsam mit dem Inhalt der ACT-Meldung auch der Zeitpunkt, zu dem die automatische Übermittlung der Meldung gemäß der Berechnung erfolgen soll, angezeigt werden.

6.3.3.1.6. (NE) Die ACT-Meldung muss die aktuellsten Informationen zum Flug, welche die erwarteten Ausflugbedingungen widerspiegeln, enthalten.

6.3.3.1.7. (NE) Der betreffende Lotsenplatz muss eine Mitteilung über die Übermittlung der ACT-Meldung erhalten.

6.3.3.1.8. (NE) Sobald eine LAM eingegangen ist, werden die Daten in der ACT-Meldung für beide Flugverkehrskontrollstellen operationell verbindlich. Die koordinierten Übergabebedingungen sowie die Tatsache, dass die LAM empfangen wurde, sind dem ATC-Personal bei der übergebenden Stelle vorzulegen.

6.3.3.1.9. (NE) Die Akzeptierung der in der ACT-Meldung enthaltenen Übergabebedingungen wird vorausgesetzt, sofern die übernehmende Stelle keine Koordination zu deren Änderung einleitet.

6.3.3.1.10. (NE) Eine weitere ACT-Meldung darf an denselben Koordinationspartner nur gesendet werden, falls die vorausgegangene Meldung durch ein MAC abgebrochen wurde.

6.3.3.1.11. (NE) Flugstrecke und sonstige Flugplandaten sind einzubeziehen, falls dies bilateral vereinbart wurde.

6.3.3.2. Verarbeitung bei der übernehmenden Stelle

6.3.3.2.1. (NE) Das eine ACT-Meldung empfangende ATC-System muss deren Assoziierung mit dem entsprechenden Flugplan versuchen.

6.3.3.2.2. (NE) Wird ein entsprechender Flugplan gefunden und ergibt sich zur Meldung keine Diskrepanz, die eine korrekte Verarbeitung verhindern würde,

- ist der operationelle Inhalt in den Flugplan einzubeziehen;

- sind die erforderlichen Daten an operationelle ATC- sowie andere zuständige Positionen auszugeben;

- ist eine LAM rückzumelden.

6.3.3.2.3. (NE) Lässt sich ein entsprechender Flugplan nicht finden oder wird eine Diskrepanz entdeckt, welche die korrekte Verarbeitung der Meldung verhindert,

- so muss, falls der für die Übernahme der Flugkontrolle verantwortliche Abschnitt ermittelt werden kann,

- der operationelle Inhalt der Meldung an diesem Abschnitt angezeigt werden;

- eine LAM-Rückmeldung erfolgen;

- ein Flugplan angelegt werden;

- darf in allen sonstigen Fällen keine LAM rückgemeldet werden.

6.3.3.3. Übermittlungsparameter

6.3.3.3.1. (NE) Die Meldung muss zu bzw. so bald wie möglich nach dem frühesten der nach folgenden Kriterien bestimmten Zeitpunkte übermittelt werden:

- einer parametrierten Zahl von Minuten vor der voraussichtlichen Zeit am COP;

- dem Zeitpunkt, zu dem sich der Flug in einer bilateral vereinbarten Entfernung vom COP befindet.

6.3.3.3.2. (NE) Der/die ACT-Generierungsparameter müssen in den von den betreffenden Flugverkehrskontrollstellen vereinbarten LoA aufgenommen werden.

6.3.3.3.3. (NE) Basierend auf den Festlegungen im LoA muss/müssen der/die ACT-Generierungsparameter variabel sein.

6.3.3.3.4. Empfehlung

ACT-Generierungsparameter sollten für jeden COP gesondert definiert werden.

6.3.3.3.5. (NE) Die festgelegten Parameter müssen ausreichend Zeit lassen, damit

- die übermittelnde Stelle die Übergabeflugfläche so aktualisieren kann, dass sie die voraussichtlichen Bedingungen am COP widerspiegelt;

und

- die übernehmende Stelle die ACT verarbeiten sowie eine LAM generieren und übermitteln, die übermittelnde Stelle jedoch noch eine mündliche Koordination durchführen und die übernehmende FS-Stelle dementsprechende Handlungen einleiten kann, falls der Datenaustausch fehlschlägt.

6.3.4. Bestätigung von ACT

6.3.4.1. Bestätigung

(NE) Die ACT-Meldung muss durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

6.3.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine ACT-Meldung empfangen, muss an der für die Koordination des Fluges verantwortlichen Position der Flugsicherung eine Warnung angezeigt werden.

6.3.5. Beispiele

Die folgenden Beispiele sind eine Erweiterung der für die ABI-Meldung in Absatz 6.2 dargelegten Beispiele; sämtliche Einzelheiten sind identisch, mit Ausnahme der ETO am COP, die in der aufgezeigten ACT-Meldung 1226 beträgt.

6.3.5.1. ICAO

(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)

6.3.5.2. ADEXP

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

6.4. Logische Bestätigung (LAM)

6.4.1. Zweck der LAM

Die LAM ist das Mittel, mit dem die übernehmende Stelle der versendenden Stelle den Eingang und die Sicherung der übermittelten Meldung anzeigt.

Die Verarbeitung der LAM stellt dem ATC-Personal der übergebenden Stelle folgendes bereit:

- eine Warnung, wenn keine Bestätigung empfangen wurde;

- einen Hinweis, dass die gerade bestätigte Meldung empfangen, erfolgreich verarbeitet, als fehlerfrei erkannt und gespeichert wurde sowie (so weit zutreffend) zur Weiterleitung an die entsprechenden Lotsenplätze vorliegt.

6.4.2. Bestandteile der Meldung

(NE) Die LAM muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung.

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

6.4.3. Anwendungsregeln

6.4.3.1. Allgemein

6.4.3.1.1. Die Regeln für die Rücksendung einer LAM sind in den die Verarbeitung der jeweiligen Meldung bestimmenden Abschnitten dieses Dokuments ausgeführt.

6.4.3.1.2. (NE) Die LAM muss ohne menschlichen Eingriff generiert und übermittelt werden.

6.4.3.1.3. (NE) Die LAM darf nicht dazu dienen, die Notwendigkeit technischer Meldungen zur Gewährleistung der Integrität von Datenübermittlungen aufzuheben.

6.4.3.1.4. (NE) Die LAM muss unverzüglich generiert und übermittelt werden, damit die geforderte Transaktionszeit der durch sie bestätigten Meldung eingehalten werden kann.

6.4.3.1.5. (NE) Mit der Ausnahme von ABI-Meldungen muss das übermittelnde Flugverkehrskontrollsystem den für die Koordination verantwortlichen Fluglotsen informieren, falls die LAM-Meldung nicht innerhalb des für eine derartige Warnung gesetzten Zeitparameters eingegangen ist.

6.4.4. Bestätigung von LAM

(NE) Die LAM-Meldung bedarf keiner Bestätigung.

6.4.5. Beispiele

6.4.5.1. ICAO

(LAML/E012E/L001)

6.4.5.2. ADEXP

-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -SEQNUM 001

7. GRUNDVERFAHREN - KOMPLEMENTÄRE MELDUNGEN

7.1. Allgemein

7.1.1. Anforderungsbeschreibung

Dieser Abschnitt beschreibt auf das Grundverfahren anwendbare Leistungsmerkmale, die zusätzlich zu den in Abschnitt 6 "Grundverfahren - Obligatorische Meldungen" beschriebenen gelten.

7.1.2. Implementierung

7.1.2.1. Die Verwendung jeglicher in diesem Abschnitt beschriebener Leistungsmerkmale muss vor deren Einführung bilateral vereinbart werden.

7.1.2.2. In allen Fällen, wo eine derartige Verwendung vereinbart ist, gelten die in diesem Abschnitt beschriebenen Regeln.

7.2. Vorläufige Aktivierung (PAC)

7.2.1. Zweck der PAC-Meldung

Die PAC-Meldung erfuellt folgende operationelle Anforderungen:

- Benachrichtigung und dem Abflug vorausgehende Koordination eines Fluges in Fällen, in denen die Zeit vom Abflug bis zum COP kürzer als die Zeitspanne ist, die zur Einhaltung der verabredeten Zeitparameter für die Übermittlung der ACT-Meldung benötigt wird;

- Benachrichtigung und dem Abflug vorausgehende Koordination eines Fluges durch eine örtliche Stelle (Flughafen- und Anflugkontrolle) für die nächste Stelle, welche die Kontrolle des Fluges übernehmen wird;

- Vorbereitung der Erfassung fehlender Flugplandaten im Falle von Diskrepanzen bei der anfänglichen Verteilung der Flugplandaten;

- Anforderung der Zuweisung eines SSR-Codes seitens der Stelle, an welche die obige Benachrichtigung/Koordination gesendet wird, falls erforderlich.

7.2.2. Bestandteile der Meldung

(NE) Die PAC-Meldung muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung (optional);

- Luftfahrzeugkennung;

- SSR-Modus und -Code;

- Startflugplatz;

- voraussichtliche Startzeit bzw. Schätzdaten;

- Zielflugplatz;

- Luftfahrzeugmuster;

- Flugstrecke (optional);

- sonstige Flugplandaten (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

7.2.3. Anwendungsregeln

7.2.3.1. Allgemein

7.2.3.1.1. (NE) Für jeden Flug, der das Passieren der Grenze zwischen Zuständigkeitsgebieten beabsichtigt, ist mindestens eine PAC-Meldung immer dann zu senden, wenn die Zeitspanne vom Abflug bis zum COP das Versenden der ACT-Meldung zum geforderten Zeitpunkt nicht erlauben würde.

7.2.3.1.2. (NE) Für jeden abgehenden Flug, der Benachrichtigung oder Koordination erfordert, ist mindestens eine PAC-Meldung von der Flughafen- und Anflugkontrollstelle zur nächsten Stelle zu senden.

7.2.3.1.3. Empfehlung

Für die Implementierung von PAC/LAM zwischen den Stellen sollte den maßgeblichen TWR/APP-Systemen ein Mittel zur Eingabe und Weiterleitung von "start-up", "push-back", "taxi" oder ähnlichen Informationen zur Verfügung stehen, aus denen sich die ETOT ableiten lässt, um daraus die ETO am COP zu berechnen und die Übermittlung der PAC-Meldung einzuleiten.

7.2.3.1.4. (NE) Je nach bilateraler Vereinbarung muss die Meldung entweder

- die voraussichtliche Startzeit;

oder

- Schätzdaten enthalten.

7.2.3.1.5. (NE) Ist gemäß bilateraler Vereinbarung der Bezug der Meldung enthalten, muss dieser

- die Meldungsnummer der ersten für den Flug gesendeten PAC-Meldung einschließen;

- in der zweiten und den nachfolgenden PAC-Meldungen eingetragen werden.

7.2.3.1.6. (NE) Die Verwendung der Code-Anforderungsfunktion, sofern diese erforderlich ist, muss bilateral verabredet werden.

7.2.3.1.7. (NE) Eine revidierte PAC-Meldung muss gesendet werden, falls vor Abflug eine von folgenden Bedingungen zutrifft:

- Die Flugstrecke wurde derart modifiziert, dass der in der vorangegangenen Meldung genannte COP nicht mehr zutrifft;

- das Luftfahrzeugmuster wurde gewechselt;

- der in der vorangegangenen PAC-Meldung angegebene Zielflugplatz hat sich als falsch erwiesen.

7.2.3.1.8. Empfehlung

Eine revidierte PAC-Meldung sollte gesendet werden, falls vor Abflug folgende Daten von den in der vorangegangenen PAC-Meldung genannten abweichen

- die Flugfläche (in den Schätzdaten, falls solche vorliegen);

- der voraussichtliche SSR-Code am Kontrollübergabepunkt;

- die voraussichtliche Startzeit bzw. die ETO am COP um eine Zeitspanne, die den bilateral vereinbarten Wert überschreitet;

- sonstige Daten, die bilateralen Vereinbarungen unterliegen, haben sich geändert.

7.2.3.2. Verarbeitung bei der übernehmenden Stelle

7.2.3.2.1. (NE) Das eine PAC-Meldung empfangende ATC-System muss deren Assoziierung mit dem entsprechenden Flugplan versuchen.

7.2.3.2.2. (NE) Wird ein entsprechender Flugplan gefunden und ergibt sich zur Meldung keine Diskrepanz, die eine korrekte Verarbeitung verhindern würde,

- ist der operationelle Inhalt in den Flugplan einzubeziehen;

- sind die erforderlichen Daten an operationelle ATC- sowie andere zuständige Positionen auszugeben;

- ist eine LAM rückzumelden.

7.2.3.2.3. (NE) Lässt sich ein entsprechender Flugplan nicht finden oder wird eine Diskrepanz entdeckt, welche die korrekte Verarbeitung der Meldung verhindert,

- so muss, falls sich der für die Übernahme der Flugkontrolle verantwortliche Abschnitt ermitteln lässt,

- der operationelle Inhalt der Meldung an diesem Abschnitt angezeigt werden;

- eine LAM-Rückmeldung erfolgen;

- ein Flugplan angelegt werden;

- darf in allen sonstigen Fällen keine LAM rückgemeldet werden.

7.2.3.2.4. (NE) Die in einer zweiten bzw. darauffolgenden PAC-Meldung enthaltenen Daten gelten vorrangig vor den Daten der vorausgegangenen Meldung.

7.2.3.2.5. (NE) Beinhaltet eine PAC-Meldung einen Antrag auf Zuweisung eines SSR-Codes und lässt sie sich korrekt verarbeiten wie im oben stehenden Absatz 7.2.3.2.2 beschrieben, muss zusätzlich zur LAM eine COD-Meldung rückgesendet werden.ANMERKUNG

Der Code-Zuweisungsprozess erfordert detaillierte Flugplanstreckeninformationen, weshalb dieses Dokument keine Forderung hinsichtlich der Rücksendung einer COD-Meldung durch die übernehmende Stelle erhebt, da derartige Daten für den Flug nicht in jedem Fall verfügbar sind. Dies schließt eine Rückmeldung unter den gegebenen Umständen nicht aus, falls ein spezielles Leistungsmerkmal vor Ort vorhanden ist und das Verfahren bilateral vereinbart wurde.

7.2.3.3. Zeitparameter für die Übermittlung

Ein Übermittlungszeitparameter kommt nicht zur Anwendung, da die Meldung als Ergebnis einer manuell eingegebenen Meldung, welche den unmittelbar bevorstehenden Abflug identifiziert, gesendet wird.

7.2.4. Bestätigung von PAC

7.2.4.1. Bestätigung

Die als Reaktion auf eine PAC-Meldung zu sendenden Meldungen sind im oben stehenden Absatz 7.2.3.2 beschrieben.

7.2.4.2. Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine PAC-Meldung empfangen, muss an der für die Koordination des Fluges mit der nächsten Stelle verantwortlichen Position in der Flugverkehrskontrollstelle eine Warnung angezeigt werden.

7.2.4.3. Fälle fehlender LAM

(NE) Bei Nichtvorliegen einer LAM ist die Koordination mündlich einzuleiten

7.2.4.4. Fehlende COD-Meldung

7.2.4.4.1. (NE) Wird keine COD-Meldung als Reaktion auf eine in der PAC-Meldung enthaltene Code-Anforderung empfangen, muss an einer geeigneten Position eine Warnung angezeigt werden.

7.2.4.4.2. (NE) In Fällen, in denen die Code-Anforderungsfunktion genutzt werden soll, muss der Time-Out-Wert bilateral vereinbart werden.

7.2.5. Beispiele

7.2.5.1. Voraussichtliche Startzeit und Code-Anforderung

7.2.5.1.1. ICAO

(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)

7.2.5.1.2. ADEXP

-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA

7.2.5.2. Zeit am COP

7.2.5.2.1. ICAO

(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-EBBR-9/B737/M)

7.2.5.2.2. ADEXP

-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL F110A -ARCTYP B737 -ADES EBBR

7.3. Revisionsmeldung (REV)

7.3.1. Zweck der REV-Meldung

Die REV-Meldung dient dazu, Revisionen von bereits zuvor in einer ACT-Meldung gesendeten Koordinationsdaten zu übermitteln, sofern sich im Ergebnis der Modifizierung nicht die übernehmende FS-Stelle ändert.

7.3.2. Bestandteile der Meldung

Die REV-Meldung muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung (optional);

- Luftfahrzeugkennung;

- SSR-Modus und -Code (optional);

- Startflugplatz;

- Schätzdaten;

- Koordinationspunkt (optional);

- Zielflugplatz;

- Flugstrecke (optional);

- sonstige Flugplandaten (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

7.3.3. Anwendungsregeln

7.3.3.1. Allgemein

7.3.3.1.1. Der Stelle, an die ein Flug durch eine Aktivierungsmeldung aktuell koordiniert wurde, kann eine oder mehrere REV Meldungen zugesendet werden.

7.3.3.1.2. Der Revision unterliegen folgende Elemente:

- ETO am COP;

- Übergabe-Flugfläche(n);

- SSR-Code.

7.3.3.1.3. (NE) Eine REV-Meldung ist zu senden, wenn

- die ETO am COP von der in der vorangegangenen Meldung genannten Zeit um mehr als den bilateral vereinbarten, auf den nächsten ganzzahligen Ausdruck gerundeten Wert abweicht;

- sich Übergabe-Flugfläche(n) oder SSR-Code in irgendeiner Weise geändert haben.

7.3.3.1.4. (NE) Sofern bilateral vereinbart, ist eine REV-Meldung zu senden, wenn Änderungen erfolgten an:

- COP;

- Flugstrecke;

- sonstigen Flugplandaten (ICAO-Daten in den Feldern 8, 10 und 18).

ANMERKUNG

Operationelle Vorschriften verlangen möglicherweise, dass nach der ACT-Meldung vorgenommene Änderungen zunächst der Koordination zwischen den betreffenden Stellen bedürfen.

7.3.3.1.5. (NE) Erfolgte diesbezüglich eine bilaterale Vereinbarung, muss der Meldungsbezug in der REV Meldung aufgenommen werden.

7.3.3.1.6. (NE) Wird der Meldungsbezug aufgenommen, muss er die Meldungsnummer der vorausgegangenen ACT-Meldung enthalten.

7.3.3.1.7. (NE) Die Annahme der in der REV-Meldung enthaltenen Übergabebedingungen durch die übernehmende Flugverkehrskontrollstelle wird vorausgesetzt, sofern die übernehmende Flugverkehrskontrollstelle keine Koordination zur Modifizierung dieser Bedingungen einleitet.

7.3.3.2. Formatierung von Revisionsmeldungen

7.3.3.2.1. ICAO-Format

(NE) Alle Revisionsmeldungen enthalten die Feldtypen 3, 7, 13, 14 und 16. Folgende Arten von Revision werden in diesen Feldern vorgenommen:

- eine Änderung der ETO am COP oder der Übergabe-Flugfläche(n) muss durch Einfügen der revidierten Daten in Feld 14 erfolgen;

- eine Änderung des SSR-Codes ist in Feld 7 einzutragen;

- Änderungen der Flugstrecke, die Änderungen des COP beinhalten, sind in die Daten von Feld 14 und 15 einzutragen, die im Feld-22-Format nach den ersten fünf Feldern stehen. Meldungen dieser Art müssen zwei Felder 14 enthalten, deren erstes nur Element a), also den COP, durch den der Flug zuvor koordiniert wurde, enthält. Die Vorschriften betreffs der Koordination solcher Änderungen, einschließlich direkter Streckenführungen, sind in Anhang B, Besondere Anforderungen an die Verarbeitung von Streckendaten, festgelegt;

- Modifizierungen der Felder 8, 10 und 18 sind im Datenformat von Feld 22 nach den ersten fünf Feldern einzutragen.

7.3.3.2.2. ADEXP-Format

(NE) Alle Revisionsmeldungen im ADEXP-Format müssen folgende Primärfelder enthalten: TITLE REFDATA ARCID ADEP ADES. Dabei gelten folgende Regeln:

- eine Änderung der ETO am COP oder der Übergabeflugfläche(n) ist durch Einfügen der revidierten Daten in Primärfeld COORDATA zu integrieren;

- Streckenänderungen, einschließlich Änderungen des COP, sind in den Primärfeldern COORDATA und ROUTE einzutragen. Derartige Meldungen müssen das Primärfeld COP enthalten, das den Koordinationspunkt beschreibt, durch den der Flug ursprünglich koordiniert wurde. Die Regeln für die Koordination solcher Änderungen, einschließlich direkter Streckenführungen, sind in Anhang B verzeichnet;

- eine Änderung des SSR-Codes ist durch Einfügen des Primärfelds SSRCODE anzuzeigen;

- Änderungen sonstiger Flugplandaten sind durch Einfügen des erforderlichen Primärfelds bzw. der erforderlichen Primärfelder zu integrieren, wie für sonstige Flugplandaten in Anhang A festgelegt.

(NE) Wird eine Revisionsmeldung allein dazu gesendet, den SSR-Code und/oder sonstige Flugplandaten zu koordinieren, ist anstelle von COORDATA das Primärfeld COP einzutragen.

7.3.3.2.3. SSR-Code

(NE) SSR-Modus und -Code sind nur dann in eine REV-Meldung einzubeziehen, wenn sich eine Koordination des SSR-Code erforderlich macht.

7.3.3.3. Verarbeitung bei der übernehmenden Stelle

7.3.3.3.1. (NE) Wurde für einen bestimmten Flug eine ACT-Meldung von derselben Flugverkehrskontrollstelle empfangen, muss das eine REV-Meldung erhaltende ATC-System die Assoziierung mit dem entsprechenden Flugplan versuchen.

7.3.3.3.2. (NE) Wird ein entsprechender Flugplan gefunden und ergibt sich zur Meldung keine Diskrepanz, die eine korrekte Verarbeitung verhindern würde,

- ist der operationelle Inhalt in den Flugplan einzubeziehen;

- sind die erforderlichen Daten an operationelle ATC- sowie andere zuständige Positionen auszugeben.

7.3.3.4. Einleitung der Übermittlung

7.3.3.4.1. (NE) Die REV-Meldung ist ereignisabhängig und unmittelbar auf die jeweilige Eingabe bzw. Aktualisierung folgend zu übermitteln.

7.3.3.4.2. (NE) Mittels REV-Meldung dürfen Änderungen nur solange vorgenommen werden, bis der Flug einen bestimmten zeitlichen bzw. räumlichen Abstand vom Übergabepunkt erreicht hat. Die entsprechenden Zeit- und Entfernungsparameter sind bilateral zu vereinbaren.

7.3.3.4.3. Empfehlung

Die REV-Parameter sollten für jeden COP gesondert definiert werden.

7.3.3.5. Wechsel der übernehmenden Flugverkehrskontrollstelle

(NE) Die REV-Meldung darf nicht verwendet werden, falls eine Revision der Flugplandaten zu einem Wechsel der übernehmenden Flugverkehrskontrollstelle führt (siehe Koordinationsabbruchmeldung).

7.3.4. Bestätigung von REV

7.3.4.1. Bestätigung

(NE) Falls die REV-Meldung

- mit einem Flugplan im empfangenden System assoziiert werden kann, ist eine LAM-Meldung als Bestätigung zu übermitteln;

- nicht mit einem Flugplan im empfangenden System assoziiert werden kann, ist keine LAM-Meldung zu übermitteln.

7.3.4.2. Nichtbestätigung

7.3.4.2.1. (NE) Wird keine LAM-Meldung als Bestätigung für eine REV-Meldung empfangen, muss an der für die Koordination der Flüge verantwortlichen Position der Flugverkehrskontrolle eine Warnung angezeigt werden.

7.3.4.2.2. (NE) Bei Nichtvorliegen einer LAM ist die Revision durch die übergebende Flugverkehrskontrollstelle mündlich einzuleiten.

7.3.5. Beispiele

7.3.5.1. ICAO

a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)

b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)

7.3.5.2. ADEXP

a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317

7.4. Koordinationsabbruch (MAC)

7.4.1. Zweck der MAC-Meldung

Eine MAC-Meldung wird verwendet, um der übernehmenden Stelle anzuzeigen, dass die zuvor für einen Flug durchgeführte Koordination oder Benachrichtigung abgebrochen wird.

(NE) Die MAC ist kein Ersatz für die Aufhebungsmeldung (CNL) wie durch die ICAO definiert und darf daher nicht zum Löschen der grundlegenden Flugplandaten verwendet werden.

7.4.2. Bestandteile der Meldung

Die MAC-Meldung muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung (optional);

- Luftfahrzeugkennung;

- Startflugplatz;

- Koordinationspunkt;

- Zielflugplatz;

- Koordinationsstatus und -grund (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

7.4.3. Anwendungsregeln

7.4.3.1. Allgemein

7.4.3.1.1. (NE) Einer Stelle, mit der ein Flug zuvor mittels einer ACT- oder RAP-Meldung koordiniert wurde, ist eine MAC-Meldung zu senden, wenn eines von folgenden Ereignissen eintritt:

- Die voraussichtliche Flugfläche am Übergabepunkt unterscheidet sich von der in der vorangegangenen Meldung enthaltenen Fläche, was zu einer Änderung der nächsten Stelle in der Koordinationsfolge führt;

- die Flugstrecke wurde geändert, was zu einer Änderung der nächsten Stelle in der Koordinationsfolge führt;

- der Systemflugplan wird in der versendenden Stelle aufgehoben, und die Koordination ist nicht mehr von Relevanz;

- zum betreffenden Flug geht eine MAC von der vorherigen Stelle ein.

7.4.3.1.2. (NE) Wird die MAC-Meldung aufgrund einer Änderung der Flugfläche bzw. -strecke gesendet, muss je nach Gegebenheit die Benachrichtigung und/oder Koordination mit der nächsten Stelle in der Koordinationsfolge durchgeführt werden.

7.4.3.1.3. (NE) Eine MAC-Meldung muss gesendet werden, wenn die mittels einer PAC-Meldung erfolgte Koordination für einen abgehenden Flug abgebrochen wird.

7.4.3.1.4. Empfehlung

Eine MAC-Meldung sollte gesendet werden, wenn die zuvor für einen Flug erfolgte Benachrichtigung (ABI-Meldung) aus einem der in Absatz 7.4.3.1.1 genannten Gründe aufgehoben wird oder wenn der Flug unterwegs verspätet ist und revidierte Schätzdaten nicht automatisch bestimmt werden können.

7.4.3.1.5. (NE) Sofern bilateral vereinbart, muss die Meldung einen Bezug beinhalten.

7.4.3.1.6. (NE) Ist der Bezug in die Meldung aufgenommen, muss er die Meldungsnummer der letzten für den Flug übermittelten und bestätigten ABI-, PAC- bzw. ACT-Meldung enthalten.

7.4.3.1.7. (NE) Koordinationspunkt muss derjenige COP sein, durch den der Flug zuvor angekündigt bzw. koordiniert wurde.

7.4.3.1.8. Empfehlung

Die MAC-Meldung sollte den Status ausweisen, auf den die Koordination bzw. Benachrichtigung zurückgesetzt werden soll, sowie den Grund für den Abbruch.

7.4.3.1.9. (NE) Sofern enthalten, müssen Status und Grund eine von folgenden Kombinationen bilden:

- Ist die übernehmende Stelle nicht mehr der nächste Koordinationspartner, so steht

- als Status INI (Ausgangsstatus);

- als Grund einer von folgenden:

- TFL, falls der Grund eine Änderung der Übergabefläche ist;

- RTE, falls der Grund eine Änderung der Flugstrecke ist;

- CSN, falls der Grund eine Änderung im Rufzeichen ist;

- CAN, falls der Grund eine Aufhebung ist;

- OTH bei jeglichen sonstigen Gründen bzw. falls der Grund nicht bekannt ist;

- Trifft eine von folgenden Bedingungen zu:

- Die mittels der vorangegangenen PAC- bzw. ACT-Meldung (gegebenenfalls in der durch eine darauf folgende REV-Meldung modifizierten Form) erfolgte Koordination wird abgebrochen, doch ist zu erwarten, dass der Flug Gegenstand einer neuen Koordinationsfolge mit derselben Stelle ist;

oder

- der Flug wird im Anschluss an eine ABI-Meldung auf unbestimmte Zeit in Warteposition gehalten, und es ist zu erwarten, dass er je nach Gegebenheit Gegenstand einer revidierten ABI bzw. ACT wird, so steht

- als Status NTF (Benachrichtigung);

- als Grund einer von folgenden:

- DLY, falls der Grund eine Verspätung ist;

- HLD, falls der Grund Warten ist;

- OTH bei jeglichen sonstigen Gründen bzw. falls der Grund nicht bekannt ist.

7.4.3.1.10. (NE) Soll für den Flug erneut eine Benachrichtigung oder Koordination erfolgen,

- muss je nach Gegebenheit eine neue Benachrichtigungs- und/oder Koordinationsmeldung gesendet werden;

- dürfen die grundlegenden Flugplandaten, die bei der übernehmenden Flugverkehrskontrollstelle gespeichert sind, nicht durch eine MAC-Meldung berührt werden;

- muss das System weiterhin in der Lage sein, eine neue Benachrichtigungs- und/oder Koordinationsmeldung von entweder der vorherigen übergebenden Stelle oder einer anderen Stelle in einer neuen Koordinationsfolge korrekt zu verarbeiten.

7.4.3.2. Verarbeitung bei der übernehmenden Stelle

(NE) Die mit Einzelheiten zum Flug versorgten Lotsenplätze in der übernehmenden Flugverkehrskontrollstelle müssen über den Abbruch in Kenntnis gesetzt erhalten.

7.4.4. Bestätigung von MAC

7.4.4.1. Bestätigung

7.4.4.1.1. (NE) Lässt sich die MAC-Meldung mit einem Flugplan im empfangenden System assoziieren und ist ihre Verarbeitung möglich, muss zur Bestätigung eine LAM-Meldung übermittelt werden.

7.4.4.1.2. (NE) Lässt sich die MAC-Meldung nicht mit einem Flugplan im empfangenden System assoziieren oder nicht verarbeiten, darf keine LAM-Meldung übermittelt werden.

7.4.4.2. Nichtbestätigung

7.4.4.2.1. (NE) Wird die ATC-Koordination abgebrochen und keine LAM-Meldung empfangen, muss an der für die Koordination verantwortlichen ATC-Position eine Warnung angezeigt werden.

7.4.4.2.2. (NE) In derartigen Fällen ist der Abbruch der Koordination durch die übergebende Flugverkehrskontrollstelle mündlich durchzuführen.

7.4.5. Beispiele

Für den Flug HOZ3188, voraussichtliche FL190, wurde eine ABI-Meldung vom ACC Amsterdam an das ACC Brüssel gesendet; der Flug beantragt im Nachhinein den Anstieg auf FL270, der entsprechend freigegeben wird, weshalb der Einflug in den Luftraum Maastricht anstelle von Brüssel erfolgt. Die Beispiele 7.4.5.1 a und 7.4.5.2 a zeigen, wie die von Amsterdam an Brüssel gesendete MAC im ICAO- sowie im ADEXP-Format aussehen würde.

Eine ABI-Meldung sowie zu einem späteren Zeitpunkt eine ACT-Meldung werden an Maastricht gesendet, doch kehrt das Luftfahrzeug wenige Minuten vor Erreichen des COP zum Flugplatz Amsterdam zurück, und der Flugplan wird im System der absendenden Stelle aufgehoben; eine MAC wird an Maastricht gesendet wie in den Beispielen (7.4.5.1 b und 7.4.5.2 b) dargestellt.

7.4.5.1. ICAO

a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL)

b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN)

7.4.5.2. ADEXP

a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL

b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN

7.5. SSR-Code-Zuweisung (COD)

7.5.1. Zweck der COD-Meldung

7.5.1.1. Die Methode der Code-Zuweisung bezüglich der Ursprungsregion (ORCAM) soll es einem Flug ermöglichen, mit aufeinanderfolgenden Stellen innerhalb eines teilnehmenden Gebietes über ein und denselben Code zu kommunizieren. Sofern keine zentrale Code-Zuweisung beispielsweise durch ein ACC erfolgt, muss den Flugplätzen unter Umständen eine bestimmte Menge diskreter SSR-Codes zugewiesen werden. Derartige Zuweisungen bedeuten allerdings einen verschwenderischen Umgang mit Codes.

7.5.1.2. Die COD-Meldung erfuellt die operationelle Anforderung, dass auf Anfrage für einen bestimmten Flug eine Flugverkehrsdienststelle einer anderen einen SSR-Code Modus A ausstellt. Ein optionales Leistungsmerkmal ermöglicht es der ausgebenden Stelle, falls bilateral vereinbart, die Flugstrecke einzubeziehen.

7.5.2. Bestandteile der Meldung

Die COD-Meldung muss folgende Datenelemente enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung (optional);

- Luftfahrzeugkennung;

- SSR-Modus und -Code;

- Startflugplatz;

- Zielflugplatz;

- Flugstrecke (optional).

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

7.5.3. Anwendungsregeln

7.5.3.1. Allgemein

7.5.3.1.1. (NE) Eine COD-Meldung muss als Antwort auf eine in einer eingegangenen Meldung enthaltenen Code-Zuweisungsanforderung automatisch generiert und übermittelt werden.

7.5.3.1.2. (NE) Der SSR-Code ist somit der dem Flug zugewiesene Code.

7.5.3.1.3. (NE) Falls kein diskreter Code verfügbar ist, muss der bestätigte Sättigungs-Code gemäß Festlegung im Air Navigation Plan für die Europäische Region eingetragen werden.

7.5.3.1.4. (NE) Falls bilateral vereinbart, muss der Meldungsbezug, der die Meldungsnummer derjenigen Meldung enthält, auf welche die COD-Meldung antwortet, einbezogen werden.

7.5.3.1.5. (NE) Falls bilateral vereinbart, ist die Flugstrecke einzubeziehen.

7.5.3.1.6. (NE) Die Annahme des SSR-Codes durch die eine COD-Meldung erhaltende Stelle wird vorausgesetzt.

7.5.3.2. Verarbeitung bei der übernehmenden Stelle

7.5.3.2.1. (NE) Unter der Voraussetzung, dass die Meldung keine Diskrepanz enthält, welche die korrekte Verarbeitung verhindern würde, ist eine LAM rückzumelden.

7.5.3.2.2. (NE) Lässt sich die Meldung nicht mit einem Flugplan assoziieren oder findet sich eine Diskrepanz, welche die korrekte Verarbeitung verhindert, ist keine LAM rückzumelden.

7.5.3.2.3. (NE) Flugstreckendaten, sofern enthalten, dürfen kein Hinderungsgrund für die Rücksendung einer LAM sein, es sei denn, sie entsprechen nicht den in Anhang A verzeichneten Anforderungen an das Format.

7.5.3.3. Zeitparameter für die Übermittlung

(NE) Für die Übermittlung gilt kein Zeitparameter, da der Versand der COD-Meldung im Ergebnis des Empfangs einer Anforderungsmeldung für die SSR-Code-Zuweisung ist.

7.5.4. Bestätigung von COD

7.5.4.1. Bestätigung

(NE) Die COD-Meldung muss durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

7.5.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung einer COD-Meldung empfangen, muss an einer geeigneten Position eine Warnung angezeigt werden.

7.5.5. Beispiele

7.5.5.1. ICAO

(CODP/PO011-AAL905/A0767-LFPO-KEWR)

7.5.5.2. ADEXP

-TITLE COD -REFDATA -SENDER -FAC P -RECVR -FAC PO -SEQNUM 011 -ADEP LFPO -ADES KEWR -ARCID AAL905 -SSRCODE A0767

7.6. Informationsmeldung (INF)

7.6.1. Zweck der INF-Meldung

7.6.1.1. Die INF-Meldung dient dazu, nicht unmittelbar in den Koordinationsprozess zwischen zwei aufeinanderfolgenden Flugverkehrskontrollstellen auf der Flugstrecke einbezogenen Instanzen Informationen zu bestimmten Flügen bereitzustellen.

7.6.1.2. Die INF-Meldung darf dazu verwendet werden, solchen Instanzen im Anschluss an einen Dialog zwischen Lotsen Kopien von Meldungen zu liefern und vereinbarte Koordinationsbedingungen zu übermitteln. Zu diesem Zweck dürfen INF-Meldungen durch die Systeme bei der übergebenden bzw. der übernehmenden Stelle generiert werden.

7.6.1.3. Die Meldung darf des weiteren verwendet werden, um einer Instanz Angaben zu einem jeglichen Punkt auf der Flugstrecke zu liefern.

7.6.1.4. Das Format gestattet die Kommunikation von Ausgangsdaten, Revisionen und Aufhebungen.

7.6.2. Bestandteile der Meldung

(NE) Die INF-Meldung muss folgende Datenelemente im Format einer in diesem Dokument beschriebenen Meldung enthalten:

- Art der Meldung;

- Nummer der Meldung;

- sämtliche kopierten Elemente der ursprünglichen Meldung bzw. aus dieser resultierenden Koordination;

- Art der Bezugsmeldung.

ANMERKUNG

Die Dateneinsetzregeln, Datenformate und Feldinhalte sind in Anhang A ausgeführt.

7.6.3. Anwendungsregeln

7.6.3.1. Arten von Meldungen

Die Art(en) der durch eine INF-Meldung duplizierbaren Meldung(en) ist/sind von den Anforderungen der Nutzer und den Kapazitäten der absendenden Stellen abhängig. Die Art(en) von Meldung(en) und Anwendungsregeln werden im allgemeinen bilateral vereinbart.

7.6.3.2. Adressaten

Für ein und denselben Flug dürfen an einen oder mehrere Adressaten eine oder mehrere INF-Meldungen übermittelt werden.

7.6.3.3. Operationeller Inhalt

(NE) Der operationelle Inhalt der INF-Meldung muss dem Format einer der bereits vorliegenden Meldungen entsprechen.

7.6.3.4. Empfehlungen

1. In einer einleitenden Dialogmeldung (z. B. ACT-, RAP-, REV-, RRV-Meldung) übermittelte Bedingungen dürfen vor Abschluss des Dialogs geändert oder abgelehnt werden. Die absendenden Stellen sollten in der Lage sein, die endgültig vereinbarten Koordinationsbedingungen weiterzugeben.

2. Die INF-Meldung sollte unmittelbar oder aber zu einem auf die Zeit am COP bezogenen, mit der übernehmenden Instanz bilateral vereinbarten Zeitpunkt gesendet werden.

7.6.4. Bestätigung von INF

Empfehlungen

1. In Abhängigkeit vom jeweiligen Koordinationspartner könnte die Bestätigung der INF-Meldung durch Generieren und Übertragen einer LAM-Meldung erfolgen.

2. Vorbehaltlich einer bilateralen Vereinbarung zwischen den betreffenden Stellen sollte für den Fall, dass keine LAM-Meldung als Bestätigung einer INF-Meldung eingeht, an einer geeigneten Position eine Warnung angezeigt werden.

7.6.5. Beispiele

Ein Flug mit Rufzeichen BAW011, B747 von EGLL nach OMDB auf FL290, erbetene FL410, voraussichtlich Koksy (KOK) VOR um 1905, verwendeter Transponder A5437, Weiterflug über UG1 und UB6.

London sendet an Maastricht eine ACT-Meldung für den Flug. Eine Kopie geht von London an eine als IT bezeichnete Stelle.

Nachfolgend werden Beispiele für die INF-Meldung gegeben.

7.6.5.1. ICAO

(INFL/IT112-BAW011/A5437-EGLL-KOK/1905F290-OMDB-9/B747H-15/N0490F410 DVR KOK UG1 NTM UB6 KRH-18/MSG/ACT)

7.6.5.2. ADEXP

-TITLE INF -REFDATA -SENDER -FAC L -RECVR -FAC IT -SEQNUM 112 -ARCID BAW011 -SSRCODE A5437 -ADEP EGLL -COORDATA -PTID KOK -TO 1905 -TFL F290 -ADES OMDB -ARCTYP B747 -ROUTE N0490F410 DVR UG1 KOK NTM UB6 KRH -MSGTYP ACT

8. DIALOGVERFAHREN - KOORDINATION

8.1. Allgemein

8.1.1. Einführung

8.1.1.1. Das Dialogverfahren stellt Leistungsmerkmale für die Kommunikation und Verhandlung zwischen Lotsen in der Koordinationsphase sowie für die Kommunikation in der Übergabephase bereit.

8.1.1.2. Dieser Abschnitt beschreibt Meldungen, die beim Dialogverfahren in der Koordinationsphase immer dann verwendet werden, wenn Übergabebedingungen vorgesehen sind. Entsprechende Meldungen für die Übergabephase, während der die eigentliche Überstellung (Hand-Over) des Fluges erfolgt, werden in Abschnitt 9 "Dialogverfahren - Kommunikationsübergabe" beschrieben.

8.1.1.3. Die Verfahren für die beiden Phasen sind voneinander unabhängig; sie können einzeln oder gemeinsam implementiert werden.

8.1.1.4. Eine Reihe zusätzlicher Meldungen wird eingeführt, und die Fähigkeit jedes der beiden Partner, einen Dialog einzuleiten, wird unterstützt.

8.1.1.5. Das Koordinations-Dialogverfahren gestattet die Erkennung von

- Übergaben, die mit den LoAs in Übereinstimmung stehen und automatisch angenommen werden können; und

- solchen, die bezüglich einer Entscheidung über die Annahme an den Lotsen der übernehmenden Stelle zu verweisen sind.

8.1.1.6. Dieses Verfahren gestattet zudem die Interpretation der zwischen den beiden zu überwachenden Systemen vereinbarten LoA und die Erkennung jeglicher diesbezüglichen Diskrepanz.

8.1.2. Das Filter

8.1.2.1. Allgemein

8.1.2.1.1. Das Koordinations-Dialogverfahren erfordert, dass das System erkennen kann, ob eine Übergabe mit dem LoA in Übereinstimmung steht oder nicht.

8.1.2.1.2. Der Prozess, der diese Übereinstimmung prüft, wird im vorliegenden Dokument als "das Filter" bezeichnet. Die für das Filter genutzte Datenbank muss erforderlichenfalls folgende Elemente enthalten:

- vereinbarte Koordinationspunkte;

- zulässige (bzw. nicht zulässige) Flugflächen, die zugleich mit den Koordinationspunkten assoziiert sein können;

- Startflugplätze;

- Zielorte;

- vereinbarte Direktstrecken;

- Zeit- und/oder Entfernungslimits vor dem COP, nach deren Überschreiten jegliche Koordinationsmeldung als nicht mehr normgerecht gilt;

- sonstige Bedingungen gemäß bilateraler Vereinbarung.

8.1.2.1.3. Sämtliche Elemente dieser Auflistung können kombiniert werden, um noch komplexere Bedingungen festzulegen.

8.1.2.1.4. Im Sinne von Abschnitt 8 dieses Dokuments ist der Begriff "Normbedingungen" als "in Übereinstimmung mit dem LoA" und der Begriff "nicht normgerechte Bedingungen" als "nicht in Übereinstimmung mit dem LoA" auszulegen. Sofern bilateral nicht anders vereinbart, müssen durch übergebende Stellen gesendete Koordinationsmeldungen, die als normgerecht bekannt sind, eine von den Meldungen, deren Bedingungen nicht normgerecht sind, abweichende Art der Meldung nutzen.

8.1.2.2. Handlung in der übergebenden Stelle

8.1.2.2.1. (NE) Das Filter in der übergebenden Stelle muss die zum bevorstehenden Versand an die übernehmende FS-Stelle vorgesehenen Übergabebedingungen prüfen.

8.1.2.2.2. Empfehlung

Erweisen sich die Übergabebedingungen als nicht normgerecht, sollte dieser Umstand dem übergebenden Lotsen zwecks Bestätigung oder Modifizierung zur Kenntnis gebracht werden.

8.1.2.3. Handlung in der übernehmenden Stelle

8.1.2.3.1. (NE) Alle ACT- und REV-Meldungen sind durch das Filter gegenzuprüfen.

8.1.2.3.2. Ergibt die Prüfung, dass die erhaltenen Übergabebedingungen nicht normgerecht sind, sind diese zur Entscheidung an den Lotsen zu verweisen; andernfalls werden sie automatisch angenommen.

8.1.2.4. Synchronisation der Filter

8.1.2.4.1. Die Verwendung unterschiedlicher Meldungen für normgerechte und nicht normgerechte Übergabebedingungen gestattet es, Diskrepanzen zu den Normbedingungen, wie sie in den Systemen der übergebenden und der übernehmenden Stelle vorgehalten sind, zu erkennen.

8.1.2.4.2. Werden von der übernehmenden Stelle in einer Meldung, die nur zur Koordination normgerechter Übergaben dient, nicht normgerechte Übergabebedingungen erkannt, führt dies zu einer Diskrepanz zwischen den beiden Filtern. Derartige Diskrepanzen sollten im Sinne einer effizienten Abwicklung des Dialogverfahrens ausgeräumt werden.

8.1.3. Abfolge der Meldungen

8.1.3.1. Allgemein

8.1.3.1.1. Es sind bestimmte Regeln zu befolgen, um zu gewährleisten, dass die Koordination abgeschlossen ist, bevor etwaige Revisionen oder ein Austausch von Kommunikationsübergabemeldungen stattfindet, wie auch um sicherzustellen, dass die Lotsen beider Stellen nicht gleichzeitig Vorschläge zum selben Flug einbringen.

8.1.3.1.2. (NE) Eine Flugverkehrskontrollstelle darf eine Revisionsmeldung (REV bzw. RRV) erst dann übermitteln bzw. deren Empfang bestätigen, wenn sich der betreffende Flug im koordinierten Status befindet, d. h. ein ACT- bzw. RAP-Dialog durch eine LAM- bzw. ACP-Meldung abgeschlossen wurde.

8.1.3.1.3. (NE) Die Übermittlung von CDN-Meldungen ist nur der übernehmenden Stelle gestattet.

8.1.3.1.4. (NE) CDN-Meldungen dürfen nur übermittelt und bestätigt werden

- als Teil eines Dialogs, der durch den Empfang einer Aktivierungsmeldung (ACT, RAP) oder einer Revisionsmeldung (REV bzw. RRV) eingeleitet wurde; oder

- wenn sich der Flugplan für den Flug im koordinierten Status befindet.

8.1.4. Behandlung von gleichzeitigen Meldungen

8.1.4.1. Allgemein

8.1.4.1.1. (NE) Eine mit dem Austausch von Koordinations- oder Übergabemeldungen für einen Flug befasste Stelle darf für diesen Flug solange keinen weiteren Austausch von Koordinations- oder Übergabemeldungen mit derselben Stelle einleiten, bis entweder eine LAM-, ACP- bzw. RJC-Meldung eingegangen ist oder ein Time-Out erreicht wurde.

8.1.4.1.2. Eine CDN-Meldung kann sich mit einer von der übergebenden Stelle gesendeten REV-, RRV- oder MAC-Meldung für denselben Flug kreuzen. Diese Situation könnte bei der übergebenden Stelle dadurch erkannt werden, dass die CDN vor der Bestätigung für die übermittelte Koordinationsmeldung eintrifft, sowie in der übernehmenden FS-Stelle dadurch, dass die Meldung von der übergebenden Stelle vor der Bestätigung der CDN ankommt. (NE) In diesem Fall ist die CDN nicht zu bestätigen und die REV, RRV bzw. MAC zu verarbeiten.

8.1.5. Behandlung einer Ablehnung

Die RJC-Meldung beendet einen Systemdialog. Es muss eine neue System-Koordination eingeleitet werden, welche gegebenenfalls die telefonische Koordination wiedergibt.

8.1.6. Time-Out für operationelle Antworten

8.1.6.1. Allgemein

8.1.6.1.1. (NE) Für die Antwort auf Meldungen, die an den Lotsen verwiesen werden, muss bei den sendenden wie den übernehmenden Stellen ein Time-Out-Mechanismus greifen.

8.1.6.1.2. (NE) Die Dauer solcher Time-Outs muss bilateral vereinbart werden.

8.1.6.1.3. (NE) Der Ablauf eines Time-Out bei der übergebende Stelle muss die Ausgabe einer Warnung an den übergebenden Lotsen veranlassen, um auf die Notwendigkeit der Einleitung einer telefonischen Koordination hinzuweisen.

8.1.6.1.4. Empfehlungen

1. An die für den Flug verantwortliche ATC-Position bei der übernehmenden Stelle sollte eine Warnung ausgegeben werden, wenn das Ende des Time-Out in der übergebenden Stelle unmittelbar bevorsteht.

2. Die Warnung sollte den Zeitbedarf für die Übermittlung der Antwort berücksichtigen.

8.1.6.1.5. (NE) Die Systeme müssen in der Lage sein, nach Ablauf des Time-Out empfangene Antworten zu verarbeiten.

8.1.7. Implementierung

8.1.7.1. Die Dialogverfahren richten sich auf zwei Phasen, nämlich die Koordinationsphase und die Übergabephase. In den beiden Phasen werden im Dialog jeweils unterschiedliche Meldungen verwendet, wobei auch die erforderlichen Transaktionszeiten verschieden sind. Die Koordinationsmeldungen sind im ICAO- und ADEXP-Format spezifiziert, die Kommunikationsübergabemeldungen lediglich im ADEXP-Format.

8.1.7.2. Die HMI-Mindestanforderungen an den Koordinationsdialog unterscheiden sich von den Anforderungen an den Übergabedialog dahingehend, dass

- der Übergabedialog in erster Linie auf die Führungskontrollfunktion gerichtet ist und eine schnelle und benutzerfreundliche HMI erfordert;

- der Koordinationsdialog nicht gleichermaßen zeitkritisch ist, so dass an die HMI geringere Anforderungen gestellt werden.

8.1.7.3. (NE) Das Dialogverfahren ist basierend auf einem von folgenden alternativen Szenarien zu implementieren:

- Dialogverfahren der Koordinationsphase und dazu alle komplementären Meldungen gemäß bilateraler Vereinbarung (Abschnitte 7 und 8);

- grundlegendes Koordinationsverfahren und Dialogverfahren der Übergabephase (Abschnitte 6, 7 und 9);

- Dialogverfahren der Koordinations- und Übergabephase und dazu alle komplementären Koordinationsmeldungen gemäß bilateraler Vereinbarung (Abschnitte 7, 8 und 9).

(NE) Die Meldung mit den Vorabinformationen über die Grenzpassage muss bei allen drei Szenarien gesendet werden.

8.1.7.4. (NE) Das der Implementierung zugrunde gelegte Szenarium muss bilateral vereinbart werden.

8.2. Aktivierungsmeldung (ACT)

8.2.1. Zweck der ACT-Meldung

Der Zweck der ACT-Meldung ist im Absatz 6.3.1 beschrieben. In einem Dialogverfahren dient die ACT-Meldung dazu, die genannten Anforderungen unter der Voraussetzung zu erfuellen, dass die Übergabebedingungen für den Flug normgerecht sind und der übergebende Lotse den Flug nicht zur Annahme an den übernehmenden Lotsen verweisen muss.

8.2.2. Bestandteile der Meldung

(NE) Der Inhalt der beim Dialogverfahren genutzten ACT-Meldung muss der diesbezüglichen Beschreibung im Absatz 6.3.2 entsprechen.

8.2.3. Anwendungsregeln

8.2.3.1. Allgemein

8.2.3.1.1. Mit Ausnahme der in diesem Absatz beschriebenen Sonderregeln entsprechen die Anwendungsregeln der Beschreibung für die ACT-Meldung im Absatz 6.3.

8.2.3.1.2. (NE) Eine ACT-Meldung ist für einen Flug mit normgerechten Übergabebedingungen zu senden, den der übergebende Lotse nicht an den übernehmenden Lotsen verweisen muss.ANMERKUNG

Treffen diese Voraussetzungen nicht zu, wird eine RAP gesendet (siehe Absatz 8.3 "Verwiesener Aktivierungsvorschlag").

8.2.3.1.3. Empfehlung

Wird als Antwort auf eine ACT-Meldung eine RJC-Meldung (Koordinationsablehnung) empfangen, sollte ein neues Koordinationsverfahren eingeleitet werden.

8.2.3.2. Verarbeitung bei der übernehmenden Stelle

8.2.3.2.1. Die Meldung wird durch das Filter geprüft, um zu bestätigen, dass die vorgeschlagenen Bedingungen normgerecht sind.

8.2.3.2.2. (NE) Die Meldung ist als eine RAP-Meldung zu verarbeiten, falls

- sich die Übergabebedingungen als nicht normgerecht erweisen;

- sich kein entsprechender Systemflugplan finden lässt und die vorliegenden Informationen nicht erkennen lassen, ob die Übergabebedingungen normgerecht sind oder nicht.

8.2.3.2.3. (NE) Als normgerecht erkannte ACT-Meldungen sind in Übereinstimmung mit Absatz 6.3.3.2 zu verarbeiten.

8.2.3.2.4. Empfehlung

Erweisen sich die Übergabebedingungen in einer ACT-Meldung als nicht normgerecht, liegt eine Diskrepanz zwischen den Filtern beider Systeme vor. Der Umstand, dass die ACT nicht normgerecht ist, sollte dem Aufsichtspersonal zur Kenntnis gebracht werden, damit die Diskrepanz ausgeräumt werden kann.

8.2.4. Bestätigung von ACT

8.2.4.1. Bestätigung

8.2.4.1.1. (NE) Beim Dialogverfahren muss die Bestätigung einer ACT-Meldung

- durch eine LAM erfolgen, falls sich die Übergabebedingungen als normgerecht erweisen;

- in allen sonstigen Fällen durch eine SBY-Meldung erfolgen.

8.2.4.1.2. (NE) Nach Eingang einer LAM ist der operationelle Inhalt der ACT-Meldung als für beide Flugverkehrskontrollstellen operationell verbindlich anzusehen.

8.2.4.1.3. Sofern dies bilateral vereinbart wurde, darf, um die Annahme einer normgerechte Übergabebedingungen enthaltenden ACT durch die übernehmende FS-Stelle anzuzeigen, anstelle einer LAM eine ACP verwendet werden.

8.2.4.2. Fälle von Nichtbestätigung

(NE) Geht für eine ACT-Meldung keine Bestätigung ein, muss an dem für die Koordination des Fluges verantwortlichen ATC-Platz eine Warnung angezeigt werden.

8.3. Verwiesener Aktivierungsvorschlag (RAP)

8.3.1. Zweck der RAP-Meldung

Zusätzlich zu den für die ACT-Meldung im Absatz 6.3 festgelegten Anforderungen erfuellt die RAP-Meldungen folgende operationelle Anforderungen:

- den Vorschlag des übergebenden Lotsen zur Aktivierung von Flügen mit nicht normgerechten Übergabebedingungen und deren Verweisung an den übernehmenden Lotsen;

- die Möglichkeit für den übergebenden Lotse, sofern als notwendig erachtet, das Verweisen von normgerechten Übergabebedingungen für einen speziellen Flug an den übernehmenden Lotsen zu erzwingen.

8.3.2. Bestandteile der Meldung

(NE) Die RAP-Meldung muss die gleichen Daten enthalten, wie bereits für die ACT-Meldung (Absatz 6.3) beschrieben, und kann optional noch folgendes Datenelement einbeziehen:

- den Grund, unter Hinweis auf manuelle Verweisung (nur im ADEXP-Format möglich).

8.3.3. Anwendungsregeln

8.3.3.1. Allgemein

8.3.3.1.1. (NE) Anstelle der ACT-Meldung ist eine RAP-Meldung zu senden, wenn ein die Grenze passierender Flug eine von folgenden Bedingungen erfuellt:

- Das übergebende System hat festgestellt, dass die Übergabebedingungen nicht normgerecht sind;

- der übergebende Lotse hat angezeigt, dass die vorgeschlagenen Übergabebedingungen an den übernehmenden Lotsen zu verweisen sind.

8.3.3.1.2. (NE) Der operationelle Inhalt der zur Übermittlung anstehenden RAP-Meldung muss an der für die Koordination des Fluges verantwortlichen Position vor der eigentlichen Übermittlung angezeigt werden.

8.3.3.1.3. Empfehlung

Gemeinsam mit dem Inhalt der RAP-Meldung sollte der Zeitpunkt angezeigt werden, zu dem diese automatisch übermittelt wird.

8.3.3.1.4. (NE) Dem zuständigen Lotsenplatz ist die Übermittlung der RAP-Meldung mitzuteilen.

8.3.3.2. Verarbeitung bei der übernehmenden Stelle

8.3.3.2.1. (NE) Das eine RAP-Meldung empfangende ATC-System muss deren Assoziierung mit dem entsprechenden Flugplan versuchen.

8.3.3.2.2. (NE) Wird ein entsprechender Flugplan gefunden und weist die Meldung keine Diskrepanz auf, die eine korrekte Verarbeitung verhindern würde,

- ist der operationelle Inhalt an den übernehmenden Lotsen zu verweisen;

- eine SBY-Meldung rückzusenden.

8.3.3.2.3. Empfehlung

Es sollte ein Hinweis auf die Ursache der Verweisung (nicht normgerechte Bedingungen oder manuelle Verweisung) eingefügt werden.

8.3.3.2.4. Lässt sich die Meldung nicht mit einem Flugplan assoziieren oder findet sich eine Diskrepanz, welche die korrekte Verarbeitung der Meldung verhindert, so ist

- der operationelle Inhalt der Meldung beim Sektor anzuzeigen;

und

- eine SBY-Meldung rückzusenden;

und

- ein Flugplan zu erstellen.

8.3.3.2.5. In allen sonstigen Fällen darf die Meldung nicht bestätigt werden.

8.3.3.3. Manuelle Auslösung

8.3.3.3.1. Dient die RAP dazu, die Verweisung einer vorgeschlagenen Koordination mit normgerechten Übergabebedingungen an den übernehmenden Lotsen zu erzwingen, wird sie durch den übergebenden Lotsen manuell eingeleitet und unmittelbar übermittelt.

8.3.3.3.2. Empfehlung

An dem für die Koordination des Fluges verantwortlichen Lotsenplatz sollte das manuelle Auslösen einer RAP-Meldung vor der errechneten Übermittlungszeit gestattet sein.

8.3.3.4. Zeitparameter für automatische Übermittlung

(NE) Der zeitliche/räumliche Abstand vor Erreichen der Grenze, zu dem RAP-Meldungen automatisch übermittelt werden, muss den diesbezüglichen Festlegungen für ACT-Meldungen entsprechen.

8.3.4. Bestätigung von RAP

8.3.4.1. Bestätigung

(NE) Die Meldung muss durch Generierung und Übermittlung einer SBY-Meldung bestätigt werden.

8.3.4.2. Fall von Nichtbestätigung

(NE) Wird keine SBY-Meldung als Bestätigung für eine RAP-Meldung empfangen, muss an dem für die Koordination des Fluges verantwortlichen ATC-Platz eine Warnung angezeigt werden.

8.3.5. Operationelle Antwort auf RAP

Der übernehmende Lotse darf die Übergabebedingungen entweder annehmen, einen Gegenvorschlag machen oder sie ablehnen.

8.3.5.1. Annahme

8.3.5.1.1. (NE) Entscheidet sich der übernehmende Lotse für die Annahme der vorgeschlagenen Übergabebedingungen, ist eine ACP-Meldung rückzusenden.

8.3.5.1.2. (NE) Mit dem Eingang der ACP-Meldung werden die Daten der RAP-Meldung für beide Flugverkehrskontrollstellen operationell verbindlich. Die koordinierten Übergabebedingungen und die Information, dass die ACP empfangen wurde, sind dem übergebenden Lotsen vorzulegen.

8.3.5.2. Gegenvorschlag

(NE) Entscheidet sich der übernehmende Lotse für einen Gegenvorschlag betreffs der Übergabebedingungen, muss eine CDN-Meldung rückgesendet werden.

8.3.5.3. Empfehlung

Entscheidet sich der übernehmende Lotse dafür, die vorgeschlagenen Übergabebedingungen abzulehnen, sollte eine RJC-Meldung rückgesendet werden. Daraufhin sollte ein neuer Koordinationsprozess eingeleitet werden.

ANMERKUNG

Bezüglich der Empfehlung 8.3.5.3 wird die neue Koordination in der Mehrzahl der Fälle mit einer anderen Stelle erfolgen.

8.3.6. Beispiele

8.3.6.1. ICAO

(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M)

8.3.6.2. ADEXP

-TITLE RAP -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 022 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757

8.4. Revisionsmeldung (REV)

8.4.1. Zweck der REV-Meldung

Der Zweck der REV-Meldung ist im Absatz 7.3.1 beschrieben. Beim Dialogverfahren dient die REV-Meldung dazu, die genannten Anforderungen unter der Voraussetzung zu erfuellen, dass die Übergabebedingungen für den Flug normgerecht sind und der übergebende Lotse den Flug nicht zur Annahme an den übernehmenden Lotsen verweisen muss.

8.4.2. Bestandteile der Meldung

(NE) Der Inhalt der beim Dialogverfahren genutzten REV-Meldung muss der diesbezüglichen Beschreibung im Absatz 7.3.2 entsprechen.

8.4.3. Anwendungsregeln

8.4.3.1. Allgemein

8.4.3.1.1. An die Stelle, an die ein Flug mittels einer Aktivierungs- bzw. RAP-Meldung aktuell koordiniert wurde, darf eine oder mehrere REV-Meldungen gesendet werden.

8.4.3.1.2. (NE) REV-Meldungen sind unter den im Absatz 7.3.3.1 spezifizierten Bedingungen für Flüge mit normgerechten Übergabebedingungen zu senden, die der übergebende Lotse nicht zur Annahme an den übernehmenden Lotsen verweisen muss.

8.4.3.2. Einleitung der Übermittlung

(NE) Die Übermittlung der REV-Meldung muss unmittelbar nach Erkennen einer Änderung der Koordinationsdaten erfolgen, deren Koordination wie im Absatz 7.3.3 beschrieben erforderlich ist.

8.4.3.3. Verarbeitung bei der übernehmenden Stelle

8.4.3.3.1. (NE) Wird ein entsprechender Flugplan im koordinierten Status gefunden und ergeben sich keine Diskrepanzen, die eine korrekte Verarbeitung der Meldung verhindern würden, so

- ist die REV-Meldung zu bestätigen;

- in allen sonstigen Fällen darf die Meldung nicht bestätigt werden.

8.4.3.3.2. (NE) Die Übergabebedingungen sind auf Normgerechtheit zu prüfen.

8.4.3.3.3. (NE) Sin