32000R2082

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) Sind die Übergabebedingungen nicht normgerecht, müssen sie dem übernehmenden Lotsen vorgelegt werden.

8.4.3.3.4. (NE) Erweisen sich die Übergabebedingungen als normgerecht, sind sie in den Flugplan einzubeziehen und die erforderlichen Daten an operationelle ATC-Positionen bzw. sonstige geeignete Positionen auszugeben.

8.4.3.3.5. Empfehlung

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

8.4.4. Bestätigung von REV

8.4.4.1. Bestätigung

8.4.4.1.1. (NE) Soll die REV-Meldung bestätigt werden, muss diese Bestätigung erfolgen durch

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

- eine SBY-Meldung, falls sich die Übergabebedingungen als nicht normgerecht erweisen.

8.4.4.1.2. Nach Eingang einer LAM ist der operationelle Inhalt der REV-Meldung als für beide Flugverkehrskontrollstellen operationell verbindlich anzusehen.

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

8.4.4.2. Fälle von Nichtbestätigung

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

8.4.5. Operationelle Antwort auf REV

(NE) Da die REV-Meldung dem Versenden von normgerechten Übergabebedingungen dient, wird sie vom System in der übernehmenden Stelle üblicherweise angenommen. Erkennt das Filter in der übernehmenden FS-Stelle die Übergabebedingungen als nicht normgerecht, muss die Meldung als RRV-Meldung verarbeitet werden.

8.5. Verwiesener Revisionsvorschlag (RRV)

8.5.1. Zweck der RRV-Meldung

(NE) Die RRV-Meldung muss in den folgenden Fällen zur Revision von zuvor versendeten und vereinbarten Übergabebedingungen führen:

- wenn die in der Revisionsmeldung vorgeschlagenen Übergabebedingungen nicht normgerecht sind;

- wenn die vorgeschlagene Revision zwar normgerecht ist, der übergebende Lotse diese Revision jedoch an den übernehmenden Lotsen verweisen möchte.

8.5.2. Bestandteile der Meldung

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

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

8.5.3. Anwendungsregeln

8.5.3.1. Allgemein

(NE) Für jeden Revisionsfall muss anstelle von REV-Meldungen mindestens eine RRV-Meldung gesendet werden, wenn entweder

- das übergebende System die Übergabebedingungen als nicht normgerecht eingestuft hat;

oder

- der übergebende Lotse angezeigt hat, dass die vorgeschlagenen Übergabebedingungen an den übernehmenden Lotsen verwiesen werden sollen. Die Verwendung der RRV ist hier optional.

8.5.3.2. Einleitung der Übermittlung

(NE) Die RRV-Meldung ist unmittelbar nach Erkennen einer Änderung der Koordinationsdaten oder durch manuelle Einleitung zu versenden.

8.5.3.3. Verarbeitung bei der übernehmenden Stelle

8.5.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,

- ist die RRV-Meldung zu bestätigen;

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

8.5.3.3.2. (NE) Die vorgeschlagenen Übergabebedingungen müssen an dem für die Koordination des Fluges verantwortlichen ATC-Platz angezeigt werden.

8.5.3.3.3. Empfehlung

Es sollte ein Hinweis auf den Grund für die Verweisung (nicht normgerechte Bedingungen oder manuelle Verweisung) eingefügt werden.

8.5.4. Bestätigung von RRV

8.5.4.1. Bestätigung

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

8.5.4.2. Fall von Nichtbestätigung

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

8.5.5. Operationelle Antwort auf RRV

Der übernehmende Lotse darf eine RRV-Meldung entweder annehmen, einen Gegenvorschlag machen oder sie ablehnen.

8.5.5.1. Annahme

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

8.5.5.2. Gegenvorschlag

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

8.5.5.3. Ablehnung

(NE) Entscheidet sich der übernehmende Lotse dafür, die vorgeschlagene Abänderung der vereinbarten Übergabebedingungen abzulehnen,

- muss eine RJC-Meldung rückgesendet werden;

und

- muss ein neuer Koordinationsprozess eingeleitet werden.

Von einer Ablehnung wird ausgegangen, wenn als Antwort auf eine RRV-Meldung weder eine ACP- noch eine CDN-Meldung eintrifft.

8.5.6. Beispiele

8.5.6.1. ICAO

(RRVE/L059-AMM253-LMML-BNE/1226F310-EGBB)

8.5.6.2. ADEXP

-TITLE RRV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 059 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB

8.6. Stand-By-Meldung (SBY)

8.6.1. Zweck der SBY-Meldung

(NE) Mit der SBY-Meldung wird der Eingang einer Übergabebedingungen vorschlagenden Meldung bestätigt und zugleich angezeigt, dass der Vorschlag zur Entscheidung an den Lotsen verwiesen wurde.

8.6.2. Bestandteile der Meldung

(NE) Die SBY-Meldung 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.

8.6.3. Anwendungsregeln

8.6.3.1. Allgemein

(NE) Die SBY-Meldung muss automatisch generiert und übermittelt werden als Antwort auf

- eine RAP-, RRV- oder CDN-Meldung;

- eine ACT- oder REV-Meldung, die vom Filter ausgesondert wird.

8.6.4. Bestätigung von SBY

(NE) Die SBY-Meldung ist nicht zu bestätigen.

8.6.5. Beispiele

8.6.5.1. ICAO

(SBYL/E027E/L002)

8.6.5.2. ADEXP

-TITLE SBY -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002

8.7. Annahmemeldung (ACP)

8.7.1. Zweck der ACP-Meldung

Während der ATC-Koordinations- und Übergabephase erfuellt die ACP-Meldung folgende operationellen Anforderungen:

- Bei Vorliegen einer der folgenden Meldungen zeigt sie an, dass ein Lotse der einen Stelle die vom Lotsen der anderen Stelle vorgeschlagenen Übergabebedingungen manuell angenommen hat:

- RAP;

- RRV;

- CDN;

- ACT bzw. REV, falls als nicht normgerecht erkannt;

- sofern bilateral vereinbart, sorgt sie für die automatische Annahme einer ACT- bzw. REV-Meldung, die das Filter in der übernehmenden Stelle passiert hat (anstelle der LAM);

- sofern bilateral vereinbart, zeigt sie die manuelle Annahme einer HOP-Meldung an (anstelle der ROF-Meldung).

8.7.2. Bestandteile der Meldung

Die ACP-Meldung beinhaltet folgende Datenelemente:

- Obligatorische Daten - Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung;

- Optionale Daten - Die Meldung kann außerdem enthalten:

- Frequenz;

- Optionale Daten bei Meldungen im ICAO-Format - Die Meldung kann zudem alle der folgenden Elemente enthalten:

- Luftfahrzeugkennung;

- Startflugplatz;

- Zielflugplatz.

ANMERKUNG

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

8.7.3. Anwendungsregeln

8.7.3.1. Allgemein

8.7.3.1.1. (NE) Der Bezug der ACP-Meldung muss die Nummer der Meldung, auf die sie antwortet, enthalten.

8.7.3.1.2. (NE) Sofern eingeschlossen, muss das Frequenzfeld die Frequenz, auf welcher der Flug beim Hand-Over die übernehmende FS-Stelle rufen soll, enthalten.

8.7.3.1.3. (NE) Das Versenden der ACP-Meldung erfolgt im Anschluss an die manuelle Annahme der vorgeschlagenen und per ACT, RAP, REV, RRV oder CDN übermittelten Übergabebedingungen durch den Lotsen.

8.7.3.1.4. Die ACP-Meldung kann anstelle einer ROF-Meldung als Antwort auf eine HOP-Meldung gesendet werden.

8.7.3.1.5. (NE) Sofern bilateral vereinbart, muss die ACP-Meldung vom System automatisch als Antwort auf eine ACT/REV, die das Filter passiert hat, generiert und übermittelt werden.

8.7.3.1.6. (NE) Nach dem Empfang einer ACP sind die vereinbarten Übergabebedingungen für beide Stellen verbindlich.

8.7.3.2. Verarbeitung bei der übernehmenden Stelle

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

8.7.3.2.2. (NE) Kann die ACP mit einem Flugplan assoziiert werden, muss dem Lotsen die Annahme angezeigt werden.

8.7.3.2.3. (NE) Kann die ACP nicht mit einem Flugplan assoziiert werden,

- ist an der geeigneten Position eine Warnung auszugeben; und

- darf keine LAM gesendet werden.

8.7.4. Bestätigung von ACP

8.7.4.1. Bestätigung

8.7.4.1.1. (NE) In Fällen, in denen die ACP als automatische Antwort auf eine ACT- oder REV-Meldung dient, die das Filter passiert hat, darf keine LAM rückgemeldet werden.

8.7.4.1.2. (NE) Eine ACP-Meldung, die infolge einer manuellen Annahme gesendet wurde, muss durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

8.7.4.2. Fälle von Nichtbestätigung

(NE) Geht für eine ACP-Meldung, die infolge einer manuellen Annahme gesendet wurde, keine LAM-Meldung als Bestätigung ein, muss an dem für die Koordination des Fluges verantwortlichen ATC-Platz eine Warnung angezeigt werden.

8.7.5. Beispiele

8.7.5.1. ICAO

(ACPL/E027E/L002-18/FRQ/242150)

8.7.5.2. ADEXP

-TITLE ACP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 027 -MSGREF-SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -FREQ 242150

8.8. Koordinationsmeldung (CDN)

8.8.1. Zweck der CDN-Meldung

Die CDN-Meldung erfuellt folgende operationelle Anforderungen:

- Sie leitet einen vom übernehmenden Lotsen stammenden Gegenvorschlag, der als Antwort auf eine ACT-, RAP-, REV- oder RRV-Meldung erfolgt, an den übergebenden Lotsen weiter;

- sie leitet eine dem übergebenden Lotsen durch den übernehmenden Lotsen vorgeschlagene Modifizierung vereinbarter Übergabebedingungen ein.

8.8.2. Bestandteile der Meldung

Die CDN-Meldung umfasst folgende Datenelemente:

- Obligatorische Daten - (NE) Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Bezug der Meldung (nur wenn als Antwort auf eine andere Meldung gesendet);

- Luftfahrzeugkennung;

- Startflugplatz;

- Zielflugplatz;

ANMERKUNG

Die Meldung muss außerdem mindestens eines der folgenden Elemente enthalten:

- Schätzdaten (im Fall einer ICAO-Meldung) oder Übergabe-Flugfläche (im Fall einer ADEXP-Meldung);

- Antrag auf direkte Streckenführung.

- Bilateral vereinbarte Daten - Folgende Daten können außerdem einbezogen werden, sofern bilateral vereinbart:

- Frequenz.

ANMERKUNG

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

8.8.3. Anwendungsregeln

8.8.3.1. Allgemein

8.8.3.1.1. (NE) Eine CDN-Meldung darf nur vom übernehmenden Lotsen eingeleitet werden.

8.8.3.1.2. Sie ist zu verwenden, um einen Gegenvorschlag des übernehmenden Lotsen an den übergebenden Lotsen zu übermitteln.ANMERKUNG

Dies kann beim Dialog der Fall sein, und zwar als Antwort auf einen mittels ACT, RAP, REV bzw. RRV eingebrachten Vorschlag oder als Beginn eines Dialogs zur Änderung zuvor vereinbarter Übergabebedingungen.

8.8.3.1.3. (NE) Der Meldungsbezug ist nur dann einzufügen, wenn die CDN-Meldung als Antwort auf eine andere Meldung erfolgt.

8.8.3.1.4. (NE) Wird der Meldungsbezug eingefügt, muss er die Nummer der Meldung, auf die mit der CDN geantwortet wird, enthalten.

8.8.3.1.5. (NE) Das Leistungsmerkmal "Direct Routing Request - direkte Streckenführung" (in Anhang A näher beschrieben)

- darf nur genutzt werden, wenn bilateral vereinbart; und

- muss in diesem Fall etwaige operationelle Limite, die ihrer Nutzung gesetzt sind, definieren.

8.8.3.1.6. (NE) Die CDN darf nicht gesendet werden, nachdem ein im LoA der betreffenden Stellen festgelegter zeitlicher/räumlicher Abstand zur Grenze erreicht wurde.

8.8.3.1.7. (NE) Sollte der Fall eintreten, dass eine CDN praktisch gleichzeitig mit einer Meldung für denselben Flug von der übergebenden Stelle, d. h. einer Revisions- oder Koordinationsabbruchmeldung, übermittelt wird, ist weder eine Bestätigung noch eine operationelle Antwort rückzumelden.ANMERKUNG

Wenn sich zwei Meldungen kreuzen, führt das dazu, dass die Meldung von der übergebenden Stelle Vorrang erhält, so dass in diesem Fall die CDN von beiden Stellen ignoriert werden würde. Jede Stelle kann diese Situation daraus erahnen, dass die Meldung der anderen Stelle noch vor der Bestätigung eingeht.

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

8.8.3.2. Verarbeitung bei der übernehmenden Stelle

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

- muss der operationelle Inhalt dem für die Koordination des Fluges verantwortlichen ATC-Platz vorgelegt werden;

und

- muss eine SBY-Meldung rückgesendet werden.

8.8.3.2.2. (NE) Kann die CDN nicht assoziiert werden oder wird eine Diskrepanz entdeckt, die die korrekte Verarbeitung der Meldung verhindert, darf keine SBY-Meldung rückgesendet werden.

8.8.4. Bestätigung von CDN

8.8.4.1. Bestätigung

(NE) Unter den genannten Voraussetzungen muss die CDN-Meldung durch Generierung und Übermittlung einer SBY-Meldung bestätigt werden.

8.8.4.2. Fälle von Nichtbestätigung

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

8.8.5. Operationelle Antwort auf CDN

Der Lotse kann die in einer CDN-Meldung vorgeschlagenen Übergabebedingungen entweder annehmen oder ablehnen.

8.8.5.1. Annahme

(NE) Entscheidet sich der übergebende Lotse, die vorgeschlagenen Übergabebedingungen anzunehmen, muss eine ACP-Meldung rückgesendet werden.

8.8.5.2. Empfehlung

Entscheidet sich der übergebende Lotse für die Ablehnung der vorgeschlagenen Übergabebedingungen, sollte eine RJC-Meldung gesendet werden (ausdrückliche Ablehnung).

ANMERKUNG

Die vorgeschlagene Koordination ist praktisch als abgelehnt anzusehen, wenn bis zum Time-Out der CDN-Meldung keine Bestätigung eingegangen ist.

8.8.6. Beispiele

8.8.6.1. ICAO

(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -EBBR)

8.8.6.2. ADEXP

-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -PROPFL -TFL F270 -SFL F110A

8.9. Koordinationsablehnung (RJC)

8.9.1. Zweck der RJC-Meldung

Die RJC-Meldung zeigt an, dass ein Lotse der einen Stelle die vom Lotsen der anderen Stelle in einer der folgenden Meldungen vorgeschlagenen Übergabebedingungen ablehnt:

- RAP;

- RRV;

- CDN;

- ACT bzw. REV, falls als nicht normgerecht erkannt.

Die RJC-Meldung kann nur als direkte Antwort auf eine der obigen Meldungen verwendet werden.

8.9.2. Bestandteile der Meldung

(NE) Die RJC-Meldung 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.

8.9.3. Anwendungsregeln

8.9.3.1. Allgemein

8.9.3.1.1. (NE) Die RJC ist nach obiger Massgabe als Antwort auf eine RAP-, RRV- oder CDN-Meldung bzw. auf eine von der übernehmenden Stelle als nicht normgerecht erkannte ACT- oder REV-Meldung zu senden.

8.9.3.1.2. (NE) Die RJC-Meldung beendet den Systemdialog, und jegliche zuvor vereinbarte Koordination behält ihre Gültigkeit.

8.9.3.1.3. Empfehlung

Im Anschluss an den Empfang einer RJC-Meldung sollte eine neue Koordinationssequenz eingeleitet werden, die gegebenenfalls die telefonische Koordination widerspiegelt.

8.9.3.2. Verarbeitung bei der übernehmenden Stelle

8.9.3.2.1. (NE) Wird eine entsprechende Meldung gefunden, auf welche die RJC-Meldung Bezug nimmt, so

- muss die Ablehnung am für die Koordination des betreffenden Flugs verantwortlichen ATC-Platz angezeigt werden; und

- muss als Bestätigung eine LAM rückgemeldet werden.

8.9.3.2.2. (NE) Wird keine derartige Meldung, auf die eine Antwort aussteht, gefunden oder liegt in der Meldung eine Diskrepanz vor, welche die Verarbeitung verhindert, darf keine Bestätigung rückgemeldet werden.

8.9.4. Bestätigung von RJC

8.9.4.1. Bestätigung

Die RJC-Meldung ist durch Generierung und Übermittlung einer LAM-Meldung zu bestätigen.

8.9.4.2. Fälle von Nichtbestätigung

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

8.9.5. Beispiele

8.9.5.1. ICAO

(RJCMC/E746E/MC324)

8.9.5.2. ADEXP

-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E -SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC MC -SEQNUM 324

9. DIALOGVERFAHREN - KOMMUNIKATIONSÜBERGABE

9.1. Allgemein

9.1.1. Einführung

9.1.1.1. Dieser Abschnitt der Norm beschreibt die Leistungsmerkmale und Meldungen zur Unterstützung des Gesichtspunkts der Radarübergabe beim Kontrollübergabeverfahren. Sie sind zu implementieren, sofern dies bilateral vereinbart wurde.

9.1.1.2. Leistungsmerkmale zur Kommunikationsübergabe dürfen nur unter der Voraussetzung implementiert werden, dass die betreffende Stelle entweder die in Abschnitt 6 (Grundverfahren - Obligatorische Meldungen) oder die in Abschnitt 8 (Dialogverfahren - Koordination) beschriebenen Leistungsmerkmale zur Koordination nutzt.

9.1.1.3. Die in diesem Abschnitt des Dokuments beschriebenen Meldungen sind nur im ADEXP-Format verfügbar; eine Bereitstellung im ICAO-Format ist nicht vorgesehen.

9.1.2. Meldungssequenz

9.1.2.1. (NE) Ein Austausch von Meldungen zur Kommunikationsübergabe darf mit Ausnahme der Zusatzdatenmeldung (SDM) erst dann stattfinden, wenn die Koordination vollständig ist, d. h. ein ACT- oder RAP-Dialog durch eine LAM- oder ACP-Meldung abgeschlossen wurde.

9.1.2.2. (NE) Solange die Koordination noch unvollständig ist, darf keine Bestätigung rückgemeldet werden.

9.1.3. Kommunikationsübergabe

9.1.3.1. (NE) Die Methode der Darstellung einer tatsächlichen Übergabe der Kommunikation für einen Flug muss zwischen den betreffenden Stellen bilateral vereinbart werden.

9.1.3.2. (NE) Mindestens eine der folgenden Bedingungen muss gegeben sein:

- die übergebende Stelle sendet eine Frequenzwechselmeldung (COF);

- die übernehmende FS-Stelle meldet eine Manuelle Kommunikationsübernahme (MAS);

9.1.3.3. Die jeweilige Methode ist zwischen den beiden Stellen für jeden Verkehrsfluss zu vereinbaren.ANMERKUNG

Für unterschiedliche Verkehrsfluesse können alternative Methoden verwendet werden. So kann z. B. die eine Stelle für Flüge, die ihren Luftraum verlassen, COF-Meldungen, und für Flüge, die in ihren Luftraum eintreten, MAS-Meldungen generieren. In diesem Fall bestuende für die andere Stelle keinerlei Notwendigkeit zur Eingabe von Meldungen, welche die Kommunikationsübergabe ausdrücken.

9.2. Übergabeeinleitungsmeldung (TIM)

9.2.1. Zweck der TIM-Meldung

Zweck der TIM ist es,

- das Ereignis der Übergabeeinleitung (TI), (nämlich das Ende der Koordinationsphase und den Beginn der Übergabephase) auszudrücken;

- zur gleichen Zeit Führungskontrolldaten von der übergebenden an die übernehmende FS-Stelle weiterzuleiten.

9.2.2. Bestandteile der Meldung

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

- Obligatorische Daten - die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Verfügbare Daten - die Meldung muss außerdem jegliche der folgenden Daten, sofern diese vorliegen, enthalten:

- Freigabe-Flugfläche;

- zugewiesener Kurs bzw. Direktflug-Freigabe;

- zugewiesene Geschwindigkeit;

- zugewiesene Steig-/Sinkgeschwindigkeit;

- Optionale Daten - die Meldung kann außerdem enthalten:

- Position.

ANMERKUNG

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

9.2.3. Anwendungsregeln

9.2.3.1. Allgemein

9.2.3.1.1. (NE) Zu einem bilateral vereinbarten zeitlichen/räumlichen Abstand des Fluges von der Grenze muss die TIM-Meldung ohne menschlichen Eingriff generiert und von der übergebenden Stelle an die übernehmende FS-Stelle übermittelt werden.

9.2.3.1.2. (NE) Ebenso muss eine TIM-Meldung automatisch gesendet werden, wenn die übergebende Stelle eine Frequenzanforderung (ROF-Meldung) erhält.

9.2.3.1.3. (NE) Eine TIM darf erst gesendet werden, nachdem der Flug koordiniert wurde.

9.2.3.1.4. (NE) Die TIM-Meldung muss die aktuellsten im System verfügbaren Daten enthalten.

9.2.3.2. Zeitparameter für die Übermittlung

9.2.3.2.1. (NE) Der TIM-Generierungsparameter muss ein Variabler Systemparameter sein, der je nach Festlegung im LoA geändert werden kann.

9.2.3.2.2. Empfehlung

Systemparameter für die TIM-Generierung sollten für jeden COP gesondert definiert werden.

9.2.3.2.3. (NE) Die Koordinationspartner müssen die TIM-Generierungsparameter in ihren jeweiligen LoA aufnehmen.

9.2.3.2.4. Die eine TIM-Meldung auslösenden Systemparameter können mit der errechneten Geschwindigkeit des Luftfahrzeugs über Grund in Bezug stehen. (NE) Die Einleitung einer TIM-Meldung muss jedoch stets erfolgen, bevor die aktuelle Flugplanposition einen bilateral festgelegten Mindestabstand zum COP unterschreitet.

9.2.3.2.5. Die zur Übermittlung der TIM festgelegten Systemparameter müssen ausreichend Zeit für eine mündliche Koordination vor der Übergabe lassen.

9.2.3.3. Verarbeitung bei der übernehmenden Stelle

9.2.3.3.1. (NE) Die mit einer TIM erhaltenen Daten müssen dem übernehmenden Lotsen zur Verfügung gestellt werden.

9.2.4. Bestätigung von TIM

9.2.4.1. Bestätigung

(NE) Lässt sich die TIM-Meldung

- eindeutig mit einem Flugplan assoziieren, muss sie durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden;

- nicht eindeutig mit einem Flugplan assoziieren, darf keine Bestätigung gesendet werden.

9.2.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine TIM-Meldung empfangen, muss an geeigneter Position eine Warnung angezeigt werden.

9.2.5. Beispiel

-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253

9.3. Zusatzdatenmeldung (SDM)

9.3.1. Zweck der SDM-Meldung

9.3.1.1. Allgemein

9.3.1.1.1. Vorrangig dient die SDM dazu, Kontrolldaten und daran vorgenommene Änderungen von der übergebenden Stelle an die übernehmende FS-Stelle zu übermitteln, vorausgesetzt, es wurde bilateral vereinbart, dass der übernehmende Lotse solche Änderungen nicht bestätigen muss.

9.3.1.1.2. Die SDM-Meldung kann außerdem von der übernehmenden Stelle verwendet werden, um der übergebenden Stelle die Sprechfunkfrequenz, auf die der Flug zu übergeben ist, mitzuteilen.

9.3.2. Bestandteile der Meldung

9.3.2.1. Meldungen von der übergebenden Stelle

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

- Obligatorische Daten - Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Zusätzliche Daten - Die Meldung kann außerdem eines oder mehrere von folgenden Elementen enthalten:

- zugewiesener Kurs bzw. Direktflug-Freigabe;

- zugewiesene Geschwindigkeit;

- zugewiesene Steig-/Sinkgeschwindigkeit;

- Freigabe-Flugfläche.

9.3.2.2. Meldungen von der übernehmenden Stelle

(NE) Die SDM muss folgende Daten enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Frequenz.

ANMERKUNG

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

9.3.3. Anwendungsregeln

9.3.3.1. Meldungen von der übergebenden Stelle

9.3.3.1.1. (NE) SDM-Meldungen müssen nach Einleitung der Übergabephase (siehe TIM, Absatz 9.2) gesendet werden, wenn an folgenden Elementen Änderungen vorgenommen wurden:

- Freigabe-Flugfläche;

- zugewiesene Geschwindigkeit;

- zugewiesene Steig-/Sinkgeschwindigkeit;

- zugewiesener Kurs; oder

- Ausgabe bzw. Änderung einer Freigabe für den direkten Weiterflug zu einem festgelegten Punkt.

ANMERKUNG

Ist vor einer Kommunikationsübergabe die Zustimmung durch den übernehmenden Lotsen gefordert, muss die HOP-Meldung verwendet werden.

9.3.3.1.2. (NE) Die Meldung darf nur die geänderten Felder enthalten.

9.3.3.1.3. (NE) SDM-Meldungen, welche die im Absatz 9.3.3.1.1 beschriebenen Daten enthalten, müssen vor Einleitung der Übergabe (TI) gesendet werden, falls dies bilateral vereinbart ist.

9.3.3.1.4. (NE) Derartige Meldungen müssen zu einem bilateral vereinbarten Zeitpunkt in bezug auf die TI beginnen, sofern es sich um Daten handelt, für die das System einen Wert vorrätig hat.

9.3.3.2. Meldungen von der übernehmenden Stelle

9.3.3.2.1. SDM-Meldungen können übermittelt werden, um die Frequenz anzugeben, auf welcher der Flug die übernehmende FS-Stelle rufen soll.ANMERKUNG

Die Stellen dürfen bilateral vereinbaren, andere Informationen zu senden. Übergaben solcher Art sind jedoch in dieser Norm nicht definiert und deshalb nicht Bestandteil derselben.

9.3.3.2.2. (NE) SDM-Meldungen von der übernehmenden Stelle müssen, falls bilateral vereinbart, während der Koordinationsphase übermittelt werden.

9.3.3.3. Verarbeitung bei der übernehmenden Stelle

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

9.3.3.3.2. Wird ein entsprechender Flugplan im koordinierten Status gefunden,

- ist eine LAM rückzumelden und

- ist der operationelle Inhalt der SDM-Meldung dem zuständigen Lotsen zur Verfügung zu stellen.

9.3.3.3.3. Lässt sich ein entsprechender Flugplan nicht finden oder ergibt sich eine Diskrepanz, welche die korrekte Verarbeitung der Meldung verhindert,

- darf keine LAM rückgemeldet werden; und

- muss an einer geeigneten Position eine Warnung ausgegeben werden.

9.3.4. Bestätigung von SDM

9.3.4.1. Bestätigung

(NE) Die SDM-Meldung ist durch Generierung und Übermittlung einer LAM-Meldung zu bestätigen.

9.3.4.2. Fälle von Nichtbestätigung

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

9.3.5. Beispiel

-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290

9.4. Hand-Over-Vorschlag (HOP)

9.4.1. Zweck der HOP-Meldung

Die HOP-Meldung dient

- dem übergebenden Lotsen dazu, die Aufmerksamkeit des übernehmenden Lotsen zu Zwecken des Hand-Over auf einen speziellen Flug zu lenken;

- dem übergebenden Lotsen dazu, dem übernehmenden Lotsen den Flug zum Hand-Over vorzuschlagen, wenn dies erforderlich wird;

- zur Weitergabe von Änderungen, die gemäß bilateraler Vereinbarung der Bestätigung durch den übernehmenden Lotsen bedürfen, an die Führungskontrolldaten.

Die HOP ist nicht für sämtliche Flüge erforderlich; ihre Verwendung liegt im Ermessen des übergebenden Lotsen.ANMERKUNG

Mit Bezug auf vorstehenden Absatz c) wird zur Weitergabe von Änderungen an die Führungskontrolldaten, die keiner Bestätigung durch den übernehmenden Lotsen bedürfen, die SDM-Meldung verwendet.

9.4.2. Bestandteile der Meldung

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

- Obligatorische Daten - Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Verfügbare Daten - Die Meldung muss außerdem folgende Daten enthalten, sofern diese vorliegen:

- Freigabe-Flugfläche;

- Zugewiesener Kurs bzw. Direktflug-Freigabe;

- Zugewiesene Geschwindigkeit;

- Zugewiesene Steig-/Sinkgeschwindigkeit;

- Optionale Daten - Die Meldung kann außerdem enthalten:

- Position.

ANMERKUNG

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

9.4.3. Anwendungsregeln

9.4.3.1. Allgemein

9.4.3.1.1. (NE) Wird eine HOP-Meldung verwendet, muss sie durch den übergebenden Lotsen manuell eingeleitet werden.

9.4.3.1.2. (NE) Die Meldung muss alle der in Absatz 9.4.2 genannten Daten, die sich seit der vorhergehenden Übermittlung geändert haben, enthalten.

9.4.3.1.3. (NE) Wird eine HOP-Meldung vor der TI gesendet, muss die Übergabephase eingeleitet werden.ANMERKUNG

Zusätzlich zur HOP ist eine Übergabeeinleitungsmeldung (TIM) nicht erforderlich.

9.4.3.1.4. (NE) Der früheste zeitliche oder räumliche Abstand vom COP bzw. von der Grenze, zu dem eine HOP gesendet werden darf, muss bilateral vereinbart werden.

9.4.3.1.5. Empfehlung

Die entsprechende Zeit/Entfernung sollte für jeden COP gesondert festgelegt werden.

9.4.3.2. Verarbeitung bei der übernehmenden Stelle

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

9.4.3.2.2. (NE) Die mit der Meldung empfangenen Flugdaten müssen unverzüglich dem übernehmenden Lotsen angezeigt werden.

9.4.3.2.3. Falls der übernehmende Lotse den Flug unter den in der HOP vorgeschlagenen Bedingungen annimmt, kann an die übergebende Stelle als Antwort eine ROF gemeldet werden. Sofern bilateral vereinbart, kann als Antwort auf eine HOP eine ACP-Meldung gesendet werden.

9.4.3.2.4. (NE) Ist der übernehmende Lotse nicht in der Lage, den Flug anzunehmen, muss die Übergabe mündlich vereinbart werden.ANMERKUNG

Angesichts der Dringlichkeit des Hand-Over-Verfahrens verlangt diese Norm keine Systemunterstützung zur Überwachung der Rückmeldung der ROF (bzw. ACP); es wird davon ausgegangen, dass sich der übergebende Lotse des Nichtvorliegens einer Antwort vom übernehmenden Lotsen durchaus bewusst ist und die erforderlichen Handlungen unternimmt. Diese Norm schließt jedoch nicht aus, dass der übergebende Lotse eine Warnmeldung erhält, falls dies als operationell notwendig erachtet wird.

9.4.3.2.5. (NE) Sobald eine ROF (bzw. ACP) eingegangen ist, werden die Daten der HOP-Meldung für beide Flugverkehrskontrollstellen operationell verbindlich.

9.4.4. Bestätigung von HOP

9.4.4.1. Bestätigung

(NE) Lässt sich die HOP-Meldung mit einem Flugplan assoziieren, muss sie automatisch durch eine LAM bestätigt werden.

9.4.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine HOP-Meldung empfangen, muss an geeigneter Position eine Warnung angezeigt werden.

9.4.5. Beispiel

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ

9.5. Frequenzanforderungsmeldung (ROF)

9.5.1. Zweck der ROF-Meldung

Die ROF-Meldung wird erforderlichenfalls durch die übernehmende FS-Stelle an die übergebende Stelle gesendet, um den übergebenden Lotse dazu aufzufordern, das Luftfahrzeug zum Wechsel auf die Frequenz des übernehmenden Lotsen anzuweisen. Die Meldung darf verwendet werden, um

- als Antwort auf eine HOP die Annahme des Fluges unter den vorgeschlagenen Bedingungen auszudrücken;

- die vorzeitige Übergabe des Fluges zu erbitten.

9.5.2. Bestandteile der Meldung

Die ROF-Meldung muss folgende Datenelemente umfassen:

- Obligatorische Daten - Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Optionale Daten - Die Meldung kann außerdem enthalten:

- Frequenz.

ANMERKUNG

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

9.5.3. Anwendungsregeln

9.5.3.1. Allgemein

9.5.3.1.1. (NE) Die ROF-Meldung muss vom übernehmenden Lotsen manuell eingeleitet werden.

9.5.3.1.2. Vom übernehmenden Lotsen kann die ROF ausgelöst werden,

- wenn der übernehmende Lotse das Luftfahrzeug schon früher auf seiner Frequenz haben möchte; oder

- als Antwort auf eine HOP-Meldung.

9.5.3.2. Verarbeitung bei der übernehmenden Stelle

9.5.3.2.1. (NE) Das eine ROF-Meldung erhaltende ATC-System muss deren Assoziierung mit dem entsprechenden Flugplan versuchen.

9.5.3.2.2. (NE) Der Empfang der ROF muss dem übergebenden Lotsen unverzüglich angezeigt werden.

9.5.3.2.3. (NE) Falls sich der Flug noch nicht in der Übergabephase befindet, muss die Übergabephase eingeleitet und eine TIM-Meldung übermittelt werden.

9.5.4. Bestätigung von ROF

9.5.4.1. Bestätigung

9.5.4.1.1. (NE) Lässt sich die ROF-Meldung eindeutig mit einem Flugplan assoziieren, muss sie durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

9.5.4.1.2. (NE) Lässt sich die ROF-Meldung nicht eindeutig mit einem Flugplan assoziieren, darf keine Bestätigung gesendet werden.

9.5.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine ROF-Meldung empfangen, muss an geeignetem ATC-Platz eine Warnung angezeigt werden.

9.5.5. Beispiel

-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.6. Frequenzwechselmeldung (COF)

9.6.1. Zweck der COF-Meldung

9.6.1.1. Allgemein

9.6.1.1.1. Die COF-Meldung wird durch die übergebende Stelle an die übernehmende FS-Stelle gesendet, um mitzuteilen, dass der Flug angewiesen wurde, mit dem übernehmenden Lotsen in Kontakt zu treten.

9.6.1.1.2. Die Meldung kann für den übergebenden Lotsen die Möglichkeit enthalten, den Flug, sobald dieser mit dem übernehmenden Lotsen den Sprechfunkverkehr aufgenommen hat, von den vereinbarten Übergabebedingungen zu entbinden.

9.6.2. Bestandteile der Meldung

(NE) Die COF-Meldung muss folgende Datenelemente umfassen:

- Obligatorische Daten - Die Meldung muss enthalten:

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung;

- Verfügbare Daten - Die Meldung muss außerdem folgende Daten enthalten, sofern diese vorliegen:

- Freigabehinweis;

- Frequenz;

- Freigabe-Flugfläche;

- Zugewiesener Kurs bzw. Direktflugfreigabe;

- Zugewiesene Geschwindigkeit;

- Zugewiesene Steig-/Sinkgeschwindigkeit;

- Optionale Daten - Die Meldung kann außerdem enthalten:

- Position.

ANMERKUNG

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

9.6.3. Anwendungsregeln

9.6.3.1. Allgemein

9.6.3.1.1. (NE) Die COF-Meldung muss durch den übergebenden Lotsen manuell eingeleitet werden.

9.6.3.1.2. (NE) Die Verwendung der COF-Meldung ist obligatorisch, wenn gemäß bilateraler Vereinbarung keine MAS-Meldung genutzt wird.

9.6.3.1.3. (NE) Wird eine COF-Meldung vor der TI gesendet, muss die Übergabephase eingeleitet werden.ANMERKUNG

Eine Übergabeeinleitungsmeldung (TIM) ist zusätzlich zur COF nicht erforderlich.

9.6.3.2. Verarbeitung bei der übernehmenden Stelle

9.6.3.2.1. (NE) Das eine COF-Meldung empfangende ATC-System muss die Assoziierung mit dem entsprechenden Flugplan versuchen.

9.6.3.2.2. (NE) Der Empfang der COF muss dem übernehmenden Lotsen unverzüglich angezeigt werden.

9.6.4. Bestätigung von COF

9.6.4.1. Bestätigung

9.6.4.1.1. (NE) Lässt sich die COF-Meldung eindeutig mit einem Flugplan assoziieren, muss sie durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

9.6.4.1.2. (NE) Lässt sich die COF-Meldung nicht eindeutig mit einem Flugplan assoziieren, darf keine Bestätigung gesendet werden.

9.6.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine COF-Meldung empfangen, muss an der geeigneten ATC-Position eine Warnung angezeigt werden.

9.6.5. Beispiele

-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

9.7. Manuelle Kommunikationsübernahme (MAS)

9.7.1. Zweck der MAS-Meldung

Die MAS wird durch die übernehmende FS-Stelle an die übergebende Stelle gesendet, um anzuzeigen, dass Wechselsprechfunkverkehr mit dem Flug aufgenommen wurde.

9.7.2. Bestandteile der Meldung

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

- Art der Meldung;

- Nummer der Meldung;

- Luftfahrzeugkennung.

ANMERKUNG

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

9.7.3. Anwendungsregeln

9.7.3.1. Allgemein

9.7.3.1.1. (NE) Die MAS-Meldung muss durch den übernehmenden Lotsen manuell eingeleitet werden.

9.7.3.1.2. Die Verwendung der MAS-Meldung ist obligatorisch, falls gemäß bilateraler Vereinbarung keine COF-Meldung genutzt wird.

9.7.3.2. Verarbeitung bei der übernehmenden Stelle

9.7.3.2.1. (NE) Das eine MAS-Meldung empfangende ATC-System muss die Assoziierung mit dem entsprechenden Flugplan versuchen.

9.7.3.2.2. (NE) Der Empfang der MAS-Meldung muss dem übernehmenden Lotsen unverzüglich angezeigt werden.

9.7.4. Bestätigung von MAS

9.7.4.1. Bestätigung

9.7.4.1.1. (NE) Lässt sich die MAS-Meldung eindeutig mit einem Flugplan assoziieren, muss sie durch Generierung und Übermittlung einer LAM-Meldung bestätigt werden.

9.7.4.1.2. (NE) Lässt sich die MAS-Meldung nicht eindeutig mit einem Flugplan assoziieren, darf keine Bestätigung gesendet werden.

9.7.4.2. Fälle von Nichtbestätigung

(NE) Wird keine LAM-Meldung als Bestätigung für eine COF-Meldung empfangen, muss an der geeigneten ATC-Position erforderlichenfalls eine Warnung angezeigt werden.

9.7.5. Beispiel

-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

ANHANG A (Normativ)

DATENEINSETZREGELN

INHALT

>PLATZ FÜR EINE TABELLE>

A.1. Zweck

In diesem Anhang werden die allgemeinen Regeln für das Einsetzen der Daten in die Meldung entsprechend dieser Norm beschrieben. Diese Regeln gelten für sämtliche Meldungen, sofern in den Anwendungsregeln für eine spezielle Meldung nicht ausdrücklich Alternativen oder Ausnahmen angeführt sind.

A.2. Generische Meldungsformate

A.2.1. Alle in den folgenden Abschnitten beschriebenen Meldungen können im ICAO-Format übermittelt werden:

6 Grundverfahren - Obligatorische Meldungen;

7 Grundverfahren - Komplementäre Meldungen;

8 Dialogverfahren - Koordination.

A.2.2. Die Feldformate für ICAO-Meldungen sind in den Verfahren für Flugnavigationsdienste - Luftverkehrsregeln und Flugverkehrsdienste (Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control) (Dokument 4444) festgelegt. In Meldungen, welche diese Formate enthalten, sind folgende ICAO-Feldarten vor allen sonstigen Feldarten in folgender Reihenfolge zu übermitteln: 3, 7, 13, 14 und 16. Da die übrigen ICAO-Feldarten dem Format der Feldart 22 entsprechen, ist ihre Reihenfolge nicht von Bedeutung; sie dürfen lediglich nicht den oben aufgelisteten Feldarten vorangestellt sein.

A.2.3. Alle in diesem Dokument beschriebenen Meldungen können im ADEXP-Format von Eurocontrol übermittelt werden. Inhalt, Struktur und Verwendung der ADEXP-Datenfelder müssen Verweisdokument 2 entsprechen.ANMERKUNGEN

1. In diesem Anhang sind nur die ADEXP-Primärdatenfelder aufgelistet, es sei denn, zu den zugehörigen Teilfeldern sind spezielle Anmerkungen erforderlich. Die ADEXP-Norm führt sämtliche optionalen und obligatorischen Teilfelder auf, die im jeweiligen Primärfeld benötigt werden.

2. Die in Abschnitt 9 "Dialogverfahren - Kommunikationsübergabe" beschriebenen Meldungen stehen nur im ADEXP-Format.

A.3. Art der Meldung

Die Meldungsart ist durch die in nachstehender Liste definierten Abkürzungen beschrieben:

ABI: Vorabinformationen über die Grenzpassage.

ACP: Annahmemeldung.

ACT: Aktivierungsmeldung.

CDN: Koordinationsmeldung.

COD: SSR-Code-Zuweisung.

COF: Frequenzwechselmeldung.

HOP: Hand-Over-Vorschlag.

INF: Informationsmeldung.

LAM: Logische Bestätigungsmeldung.

MAC: Koordinationsabbruchmeldung.

MAS: Manuelle Kommunikationsübernahme.

PAC: Vorläufige Aktivierung.

RAP: Verwiesener Aktivierungsvorschlag.

REV: Revisionsmeldung.

RJC: Koordinationsablehnung.

ROF: Frequenzanforderung.

RRV: Verwiesener Revisionsvorschlag.

SBY: Stand-By-Meldung.

SDM: Zusatzdatenmeldung.

TIM: Übergabeeinleitungsmeldung.

A.3.1. ICAO

Feldart 3, Element (a).

A.3.2. ADEXP

Primärfeld "title".

A.4. Meldungsnummer

Die Meldungsnummerdaten beinhalten die der übermittelnden und der übernehmenden Stelle zugeordneten Kennungen sowie die laufende Nummer der Meldung. Unabhängig von der Art der Meldung erhöht sich die laufende Nummer der Meldung für alle an denselben Adressaten gerichteten Meldungen fortlaufend von 001 bis 000 (steht für 1000), um dann wieder bei 001 zu beginnen.

A.4.1. ICAO

Feldart 3, Element (b).

A.4.2. ADEXP

Primärfeld "refdata".

(NE) Das Teilfeld "fac" innerhalb der Teilfelder "sender" und "recvr" muss die den Flugverkehrskontrollstellen zugeordneten Kenndaten enthalten. Diese Kenndaten dürfen höchstens acht Zeichen umfassen.

(NE) Das Teilfeld "seqnum" muss die laufende Nummer enthalten.

A.5. Bezug der Meldung

A.5.1. ICAO

Feldart 3, Element (c) (im ICAO-Dokument 4444 als "reference data" bezeichnet).

(NE) Der Inhalt von Element (c) muss dem Inhalt von Element (b), Feldart 3, der bezogenen OLDI-Meldung entsprechen.

A.5.2. ADEXP

Primärfeld "msgref".

(NE) Die Werte der Teilfelder "sender", "recvr" und "seqnum" im Primärfeld "msgref" müssen denen der Teilfelder im Primärfeld "refdata" der OLDI-Meldung, auf die verwiesen wird, gleich sein.

A.6. Luftfahrzeugkennung

A.6.1. ICAO

Feldart 7, Element (a).

A.6.2. ADEXP

Primärfeld "arcid".

A.7. SSR-Modus und -Code

Entweder

1. der SSR-Modus/-Code, sofern bekannt, in dem die übernehmende Stelle die Antwort des Luftfahrzeugs am Kontrollübergabepunkt erwarten kann;

oder

2. ein Indikator, der aussagt, dass der SSR-Code von der übernehmenden Stelle angefordert wird.

A.7.1. ICAO

Feldart 7, Elemente (b) und (c).

(NE) Ist kein SSR-Code zugewiesen oder ist der Modus/Code nicht bekannt, sind die Elemente (b) und (c) auszulassen.

Bei Anforderung eines SSR-Code/-Modus müssen die Elemente b) und c) den Wert "A9999" enthalten.

A.7.2. ADEXP

Primärfeld "ssrcode".

Ist kein gültiger SSR-Code zugewiesen oder ist der Modus/Code nicht bekannt, muss das Feld frei gelassen werden.

Bei Anforderung eines SSR-Code/-Modus mittels PAC-Meldung muss im Primärfeld "ssrcode" der Indikator "REQ" stehen.

A.8. Startflugplatz

A.8.1. ICAO

Feldart 13, Element (a).

A.8.2. ADEXP

Primärfeld "adep".

A.9. Schätzdaten

A.9.1. Allgemein

A.9.1.1. (NE) Schätzdaten müssen den COP, die Zeit am COP und die Übergabefläche enthalten.

A.9.1.2. (NE) Der Koordinationspunkt muss entweder als ein bekannter Bezugspunkt, als Entfernung und Peilung von einem bekannten Bezugspunkt oder als Breiten- und Längengrad definiert sein.

A.9.1.3. (NE) Die freigegebene (Übergabe-) Flugfläche muss mit den vorgeschlagenen Übergabebedingungen übereinstimmen.

A.9.1.4. Empfehlung

Im Falle von Steig- oder Sinkflug sollten die Schätzdaten noch ergänzende Überflugdaten und Überflugbedingungen enthalten.

A.9.1.5. (NE) Werden ergänzende Überflugdaten verwendet, müssen diese die zusätzliche Überflugfläche am Kontrollübergabepunkt enthalten. Die Überflugbedingungen sind wie folgt zu definieren:

- Buchstabe "A", falls sich der Flug auf oder über der in den ergänzenden Überflugdaten genannten Fläche befinden wird; oder

- Buchstabe "B", falls sich der Flug auf oder unter der in den ergänzenden Überflugdaten genannten Fläche befinden wird.

A.9.2. ICAO

Feldart 14.

A.9.3. ADEXP

Primärfeld "coordata".

Das Teilfeld "ptid" im Primärfeld "coordata" muss entweder

- einen bekannten Bezugspunkt oder

- Peilung und Entfernung von einem bekannten Bezugspunkt, wie in derselben Meldung durch das Primärfeld "REF" bzw. "GEO" definiert, enthalten.

A.10. Koordinationspunkt

A.10.1. Allgemein

A.10.1.1. Der Koordinationspunkt, auf den sich die übergebende und die übernehmende Flugverkehrskontrollstelle zum Zwecke der beabsichtigten Übergabe beziehen.

A.10.1.2. Der Koordinationspunkt muss entweder als ein bekannter Bezugspunkt, als Entfernung und Peilung von einem bekannten Bezugspunkt oder als Breiten- und Längengrad definiert sein.

A.10.2. ICAO

Feld 14, Element (a).

A.10.3. ADEXP

Das Primärfeld "cop" enthält

- einen bekannten Bezugspunkt oder

- Peilung und Entfernung von einem bekannten Bezugspunkt, wie in derselben Meldung durch das Primärfeld "REF" bzw. "GEO" definiert.

A.11. Zielflugplatz

A.11.1. ICAO

Feld 16, Element (a).

A.11.2. ADEXP

Primärfeld "ades".

A.12. Luftfahrzeugmuster und -zahl

(NE) Luftfahrzeugmuster und -zahl muss das Luftfahrzeugmuster ausweisen. Im Falle von Formationsfluegen ist die Zahl der Luftfahrzeuge einzubeziehen.

A.12.1. ICAO

(NE) Feldart 9 im Format der Feldart 22. Element c) der Feldart 9 muss entweder die dem Luftfahrzeugmuster entsprechende Wirbelschleppenkategorie oder den Buchstaben "Z" enthalten.

A.12.2. ADEXP

Primärfeld "arctyp". Falls der Flug mehr als ein Luftfahrzeug umfasst, zusätzlich das Primärfeld "nbarc".

A.13. Flugstrecke

(NE) Beide Formate unterstützen die für ICAO-Meldungen definierte Streckenbeschreibung, die als erstes Element die Geschwindigkeit und die beantragte Flugfläche bzw. Informationen zur Höhe über Grund erfordert. Die nach der Gruppe Geschwindigkeit/Flugfläche folgenden Streckendaten müssen als Mindestanforderung die im nachstehenden Absatz genannten Daten enthalten. Sind weitere Streckendaten verfügbar, können diese nach Datenelement c) eingefügt werden. Bezüglich der Regeln für das Einsetzen von Streckendaten siehe außerdem Anhang B "Besondere Anforderungen an die Verarbeitung von Streckendaten".

A.13.1. Inhalt

A.13.1.1. Über einen definierten COP geleitete Flüge

- das Streckenelement vor dem COP (ATS-Strecke, SID-Kennung, DCT bzw. signifikanter Punkt);

- der COP;

- das Streckenelement nach dem COP (ATS-Strecke oder signifikanter Punkt).

A.13.1.2. Von der ATS-Flugstrecke abweichende Flüge

- der Punkt, von dem der Flug auf dem direkten Streckenabschnitt fortgesetzt wird;

- das Element "DCT";

- der Punkt, zu dem der Flug auf dem direkten Streckenabschnitt fortgesetzt wird.

A.13.2. Format

A.13.2.1. ICAO

Feldart 15, im Format der Feldart 22.

A.13.2.2. ADEXP

Primärfeld "route".

A.14. Sonstige Flugplandaten

A.14.1. ICAO

Feldarten 8, 10 und 18 im Format der Feldart 22.

A.14.2. ADEXP

Primärfelder: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts" und "typz".

A.15. Koordinationsstatus und -grund

(NE) Der Koordinationsstatus und -grund muss folgende Elemente enthalten:

- einen drei Buchstaben umfassenden Indikator, der den neuen Status des Systemflugplans bestätigt und wie folgt aussehen kann:

- INI, wenn sich der Systemflugplan im Einleitungsstatus befinden soll, d. h. ohne Erhalt einer Hinweismeldung;

- NTF, wenn sich der Systemflugplan im benachrichtigten Status befinden soll;

- CRD, wenn sich der Systemflugplan im koordinierten Status befinden soll, d. h. eine ACT-Meldung wurde erhalten bzw. der einleitende Koordinationsdialog wurde mit vereinbarten Bedingungen abgeschlossen.

- einen drei Buchstaben umfassenden Indikator, der den Grund für den Status nennt und wie folgt aussehen kann:

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

- RTE, falls der Grund eine Streckenänderung ist;

- HLD um auszudrücken, dass der Flug auf unbestimmte Zeit im Wartezustand gehalten und Gegenstand einer weiteren Meldung sein wird;

- DLY um auszudrücken, dass sich der Abflug verzögert;

- CAN, falls der Grund eine Streichung ist;

- CSN bei Änderung des Rufzeichens;

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

A.15.1. ICAO

A.15.1.1. Koordinationsstatus und -grund müssen im Format der Feldart 18 stehen.

A.15.1.2. Folgende Elemente müssen als zehn Zeichen umfassende Gruppe im Koordinationsstatus und -grund enthalten sein:

- STA, gefolgt von einem Schrägstrich;

- der Indikator, der den neuen Status der Benachrichtigung/Koordination bestätigt;

- der Indikator, der den Grund beschreibt.

A.15.2. ADEXP

Primärfeld "cstat".

(NE) Die Hilfselemente "coordstatusident" und "coordstatusreason" müssen jeweils den neuen Status bzw. den Grund wie oben festgelegt enthalten.

A.16. Zugewiesener Kurs (nur ADEXP)

(NE) Das Primärfeld "ahead" muss entweder

- den dem Flug zugewiesenen Kurs in Grad enthalten

oder,

- sofern kein Kurs zugewiesen ist, den Indikator "ZZZ", d. h. wenn eine SDM-Meldung zu der Anzeige verwendet wird, dass ein zuvor zugewiesener Kurs keine Gültigkeit mehr hat.

A.17. Zugewiesene Geschwindigkeit (nur ADEXP)

(NE) Das Primärfeld "aspeed" muss entweder

- die dem Flug zugewiesene Geschwindigkeit in Knoten, Machzahl oder Kilometer/Stunde enthalten

oder,

- sofern keine Geschwindigkeit zugewiesen ist, den Indikator "ZZZ", d. h. wenn eine SDM-Meldung zu der Anzeige verwendet wird, dass eine zuvor zugewiesene Geschwindigkeit keine Gültigkeit mehr hat.

A.18. Zugewiesene Steig-/Sinkgeschwindigkeit (nur ADEXP)

(NE) Das Primärfeld "rate" muss entweder

- die dem Flug zugewiesene Steig- bzw. Sinkgeschwindigkeit in Fuß pro Minute enthalten

oder,

- sofern keine Steig- bzw. Sinkgeschwindigkeit zugewiesen ist, den Indikator "ZZZ", d. h. wenn eine SDM-Meldung zu der Anzeige verwendet wird, dass eine zuvor zugewiesene Steig- bzw. Sinkgeschwindigkeit keine Gültigkeit mehr hat.

A.19. Direktkurs-Freigabe (nur ADEXP)

Die direkte, nicht als ATS-Strecke definierte Strecke zwischen zwei Punkten. Diese Punkte können entweder als bekannter Bezugspunkt oder als Abstand und Peilung von einem bekannten Bezugspunkt definiert sein. Alle verwendeten Endpunkt-Designatoren müssen bilateral vereinbart, d. h. beiden Systemen bekannt sein.

(NE) Das Primärfeld "DCT" muss enthalten:

- den Punkt, an dem die Abweichung begann bzw. beginnen wird, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt, wie in derselben Meldung durch das Primärfeld "REF" festgelegt,

oder

- als Wert "ZZZ", falls die übermittelnde Stelle nicht verlangt, dass der Punkt der Abweichung bezeichnet wird;

- den auf der ursprünglichen Flugplanstrecke angesiedelten Punkt, zu dem das Luftfahrzeug geleitet wurde bzw. wird, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt wie in derselben Meldung durch das Primärfeld "REF" festgelegt.

A.20. Direktkurs-Anforderung

Anforderung einer direkten, nicht als ATS-Strecke definierten, Strecke zwischen zwei Punkten. Diese Punkte können entweder als bekannter Bezugspunkt oder als Abstand und Peilung von einem bekannten Bezugspunkt definiert sein.

Alle verwendeten Endpunkt-Designatoren müssen bilateral vereinbart, d. h. beiden Systemen bekannt sein.

A.20.1. ICAO

Feldart 15, ohne die Gruppe "anfängliche Geschwindigkeit/Flugfläche", im Format von Feld 22.

(NE) Das Feld muss enthalten:

- den Punkt, an dem die Abweichung der Anforderung zufolge beginnen soll, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt

oder

- als Wert "ZZZ", falls die direkte Streckenführung durch die übernehmende Flugverkehrskontrollstelle beantragt wird.

- das Kürzel "DCT",

- gefolgt von dem auf der ursprünglichen Flugplanstrecke angesiedelten Punkt, zu dem für das Luftfahrzeug die Freigabe beantragt wird, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt.

A.20.2. ADEXP

(NE) Das Primärfeld "DCT" muss enthalten:

- den Punkt, an dem die Abweichung der Anforderung zufolge beginnen soll, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt, wie in derselben Meldung im Primärfeld "REF" definiert,

oder

- als Wert "ZZZ", falls die direkte Streckenführung durch die übernehmende Flugverkehrskontrollstelle beantragt wird, jedoch der genaue Punkt, an dem diese beginnen würde, nicht bekannt ist;

- den auf der ursprünglichen Flugplanstrecke angesiedelten Punkt, zu dem für das Luftfahrzeug die Freigabe beantragt wird, definiert entweder

- als ein bekannter Bezugspunkt

oder

- als Abstand und Peilung von einem bekannten Bezugspunkt, wie in derselben Meldung im Primärfeld "REF" definiert.

A.21. Position (nur ADEXP)

A.21.1. Allgemein

A.21.1.1. Die gegenwärtige Position des Fluges, entweder als geographische Koordinaten oder als Peilung und Abstand von einem designierten Punkt.

A.21.1.2. Das Primärfeld "ref" bzw. "geo" muss die gegenwärtige horizontale Position des Luftfahrzeugs enthalten. Für Abstand und Peilung im Primärfeld "ref" stehende Punkte müssen bilateral vereinbart, d. h. beiden Systemen bekannt sein. Das Primärfeld "position" muss das Teilfeld "ptid" beinhalten, das auf den definierten geographischen bzw. Bezugspunkt verweist. Soll eine Zeitinformation einbezogen werden, ist je nach bilateraler Vereinbarung entweder das Teilfeld "to" (hhmm) oder "sto" (hhmmss) zu verwenden.

A.22. Freigabeanzeige (nur ADEXP)

(NE) Das Primärfeld "release" muss eines der folgenden Elemente enthalten:

- C, falls der Flug für Steigflug freigegeben ist;

- D, falls der Flug für Sinkflug freigegeben ist;

- T, falls der Flug für Wenden freigegeben ist;

- F, falls der Flug für jegliche Handlungen freigegeben ist.

A.23. Frequenz

A.23.1. ICAO

(NE) Die Feldart 18 muss folgende Elemente im Format von Feld 22 enthalten:

- FRQ, gefolgt von einem Schrägstrich;

- 6 Stellen, mit denen die Frequenz in MHz bis zur dritten Dezimalstelle angezeigt wird.

A.23.2. ADEXP

Primärfeld "freq".

A.24. Grund (nur ADEXP)

Primärfeld "reason", unter Einbeziehung des Wertes "MANUAL" für manuell verwiesene Meldungen.

A.25. Freigabe-Flugfläche (nur ADEXP)

Primärfeld "cfl".

A.26. Vorgeschlagene Übergabe-Flugfläche (nur ADEXP)

Primärfeld "propfl".

A.27. Voraussichtliche Startzeit

A.27.1. ICAO

Feldart 13 Element (b).

A.27.2. ADEXP

Primärfeld "etot".

A.28. Art der Bezugsmeldung

Das Feld enthält die Art der Meldung wie im Absatz A.1 dieses Anhangs festgelegt.

A.28.1. ICAO

Feldart 18 im Format der Feldart 22. Der Indikator für das Element muss "MSG" sein.

A.28.2. ADEXP

Primärfeld "msgtyp".

ANHANG B (Normativ)

BESONDERE ANFORDERUNGEN AN DIE VERARBEITUNG VON STRECKENDATEN

B.1. Einführung

B.1.1. Allgemein

B.1.1.1. Dieser Anhang beschreibt die Regeln für das Einfügen von Daten, sofern dies zulässig ist, in folgenden Fällen:

- als Ergebnis eines im Flugplan hinterlegten direkten Streckenabschnitts passiert ein Flug die Grenze auf einem direkten, von der ATS-Strecke abweichenden Kurs;

- ein Flug wird nach Übermittlung einer ABI- oder ACT-Meldung umgeleitet, und zwar entweder über

- eine andere ATS-Strecke; oder

- einen direkten Kurs, um an einem späteren Punkt wieder auf die ursprüngliche Strecke zu gelangen.

B.1.1.2. In Bezug auf die Umleitung von Flügen (Absatz B.1.1.1) unterstützt der in diesem Anhang beschriebene Datenaustausch die Modifizierung der in beiden Systemen vorgehaltenen Flugstrecke durch Benachrichtigungs- und Koordinationsmeldungen.

B.2. Anwendungsregeln für die Meldungen

B.2.1. Grundregeln für direkte Streckenführung

B.2.1.1. (NE) Die Bedingungen für die Verwendung von OLDI zur Koordination von Flügen auf direkten Streckenführungen müssen bilateral vereinbart werden.

B.2.1.2. Die für die Benachrichtigung und Koordination von Flügen auf Direktstrecken benötigten Daten sind in den Daten zu Koordinationspunkt (Schätzdaten (ICAO-Format) und Koordinationsdaten (ADEXP-Format)) und Strecke in den anwendbaren Meldungen enthalten.

B.2.2. Hinterlegte Direktflugstrecke

Geht aus der Strecke hervor, dass der Flug die Grenze auf einem direkten Kurs passiert, werden der direkte Streckenabschnitt und der daraus resultierende COP in die ABI-Meldung(en) einbezogen. Dieser COP steht auch in der darauffolgenden ACT- bzw. RAP-Meldung.

Die COP- und Streckendaten müssen das im Absatz B.3.2 beschriebene Format erhalten.

B.2.3. Flugumleitungen nach ABI- und vor ACT-Übermittlung

(NE) Es muss eine neue ABI-Meldung mit den neuen Streckendaten gesendet werden.

B.2.4. Flugumleitung nach ACT-Übermittlung

B.2.4.1. (NE) Um Flugumleitungen nach Versenden der ACT-Meldung anzuzeigen, ist die REV-Meldung zu verwenden, sofern eine bilateral vereinbarte Zeit vor der ETO am zuvor koordinierten COP noch nicht überschritten wurde. ANMERKUNG

Eine REV-Meldung wird nur verwendet, wenn im Ergebnis der Streckenmodifizierung die übernehmende FS-Stelle unverändert bleibt. Ändert sich diese, muss der ursprünglichen übernehmenden Stelle eine MAC-Meldung übermittelt oder die Koordination mündlich aufgehoben werden.

B.2.4.2. (NE) Die Meldung muss folgende Datenelemente enthalten:

- Koordinationspunkt (der vorherige COP als Bezugsgröße);

- Schätzdaten;

- Flugstrecke.

B.2.4.3. (NE) Meldungen im ICAO-Format müssen folgende Felder enthalten:

3 Art und Nummer der Meldung; Bezug der Meldung, falls bilateral vereinbart;

7 Luftfahrzeugkennung. Die Elemente b und c dürfen nicht einbezogen werden, es sei denn, dass gleichzeitig eine Revision des SSR-Codes koordiniert wird;

13 Startflugplatz;

14 Nur Element a, das als Bezugsgröße den vorherigen COP enthält;

16 Flugziel;

22 Feld 14 mit den Schätzdaten für die neuen Grenzüberflugbedingungen im Format von Feld 22;

22 Feld 15 mit der neuen Strecke im Format von Feld 22.

B.2.4.4. (NE) Meldungen im ADEXP-Format müssen zusätzlich zu Art und Nummer der Meldung, Luftfahrzeugkennung, Startflugplatz, Ziel sowie, falls bilateral vereinbart, Nummer der Bezugsmeldung folgendes enthalten:

- den vorherigen Koordinationspunkt im Feld COP;

- die neuen Koordinationsbedingungen im Feld COORDATA;

- die neue Strecke im Feld ROUTE.

B.2.4.5. (NE) Revisionen der Flugstrecke, die als Teil des Dialogverfahrens übermittelt werden, sind als RRV-Meldungen zu senden, es sei denn, sie gelten laut bilateraler Vereinbarung als "normgerecht".

B.3. Feldinhalte

B.3.1. ATS-Strecken

In bezug auf Flüge, die über eine alternative ATS-Strecke umgeleitet werden, weisen die Felder für Schätzdaten und Strecke dasselbe Format auf wie bei ABI- und ACT-Meldungen.

B.3.2. Direkte Strecken

B.3.2.1. (NE) Der in den Schätzdaten genannte Koordinationspunkt muss der Punkt des Grenzüberflugs sein, ausgedrückt als Peilung und Entfernung von einem Meldepunkt. Diese Punkte sind bilateral zu vereinbaren. Ist der Abstand von einem solchen Punkt gleich Null oder passiert ihn der Flug innerhalb einer bilateral vereinbarten Entfernung, muss lediglich die Kennung für diesen Punkt genannt werden.

B.3.2.2. Falls bilateral vereinbart, kann der Koordinationspunkt für einen Flug auf direkter Strecke durch Breitengrad/Längengrad definiert werden.

B.3.2.3. (NE) In den Streckendaten muss enthalten sein:

- der auf der ursprünglichen Strecke angesiedelte Punkt, von dem aus das Luftfahrzeug auf direkter Strecke weiterfliegt; wird ein Flug von der "gegenwärtigen Position" aus direkt weitergeleitet, so kann dieser Punkt als Peilung und Entfernung von einem Meldepunkt ausgedrückt werden. Falls bilateral vereinbart, kann der Punkt durch Breitengrad/Längengrad definiert werden;

- das Kürzel "DCT";

- der Punkt, zu dem das Luftfahrzeug auf direkter Strecke weiterfliegt;

- der übrige Teil der weiteren Flugstrecke (FRF), falls dem sendenden System bekannt.

B.4. Beispiele

B.4.1. Direkte Strecken

B.4.1.1. ABI- und ACT-Meldungen

B.4.1.1.1. Der Flug (Kennung Jetset 253) soll die Grenze auf einem direkten Kurs vom Punkt A (PTA) zum Punkt C (PTC) passieren und anschließend der ATS-Strecke UA134 folgen. Das System bestimmt einen COP mit Peilung 350, Entfernung 22 NM vom Punkt B (PTB).

>PIC FILE= "L_2000254DE.008401.EPS">

Folgende ABI-Meldung wird gesendet:

- ICAO

(ABIE/L003-AMM253/A0701-LMML-PTB350022/1440F350-EGBB-9/B757/M-15/N0490F390 PTA DCT PTC UA134)

- ADEXP

-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 003 -ARCID AMM253 -SSRCODE A0701 -ADEP LMML-COORDATA -PTID REF01 -TO 1440 -TFL F350 -ADES EGBB-ARCTYP B757-REF-REFID REF01 -PTID PTB -BRNG 350 -DSTNC 022 -ROUTE N0490F390 PTA DCT PTC UA134

B.4.1.1.2. Die ACT-Meldung hat dasselbe Format wie die ABI-Meldung mit der Ausnahme, dass die Flugstrecke optional ist.

B.4.1.2. REV-Meldung

Flug HZT2051 war zuvor Gegenstand folgender ACT-Meldung (bzw. deren Äquivalent im ADEXP-Format):

(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M

>PIC FILE= "L_2000254DE.008501.EPS">

Anschließend wird der Flug von 40 NM westlich des Punktes RQA direkt zu MYY geleitet. Der dem Grenzüberflug am nächsten gelegene Punkt ist TDS, dessen Entfernung zum tatsächlichen Überflugpunkt 26 NM ist, bei einer Peilung von 240 Grad. Es wird folgende Revisionsmeldung gesendet:

(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY)

>PIC FILE= "L_2000254DE.008502.EPS">

Die äquivalente Meldung im ADEXP-Format lautet:

-TITLE REV -REFDATA -SENDER -FAC QW -RECVR -FAC FG -SEQNUM 464 -ARCID HZT2051 -ADEP HECA -COP WSS -ADES EHBK -COORDATA -PTID REF01 -TO 1842 -TFL F310 -REF -REFID REF01 -PTID TDS -BRNG 240 -DSTNC 026 -ROUTE N0458F310 RQA270040 DCT MYY

Eine nachfolgende Revisionsmeldung würde TDS240026 als den COP ausweisen.

B.4.2. Flugumleitung über ATS-Strecken nach ACT-Übermittlung

B.4.2.1. ACT-Meldung

Es ist beabsichtigt, Flug GKP217 über den Koordinationspunkt EMT zu leiten. Die folgende ACT-Meldung wird übermittelt:

(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)

>PIC FILE= "L_2000254DE.008601.EPS">

Im nachhinein wird der Flug über die ATS-Strecke UM247 innerhalb des Luftraums der sendenden Luftverkehrszentrale zum neuen Koordinationspunkt XAT umgeleitet; im weiteren soll er der ATS-Strecke UJ124 folgen. Die übernehmende FS-Stelle bleibt unverändert. Es wird folgende Revisionsmeldung gesendet:

(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)

>PIC FILE= "L_2000254DE.008602.EPS">

Der Flug wird daraufhin auf FL290 freigegeben, was folgende Meldung (unter Einbeziehung des neuen COP) nach sich zieht:

(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)

>PIC FILE= "L_2000254DE.008701.EPS">

B.4.2.2. Äquivalente Meldungen im ADEXP-Format

Die Äquivalente der beiden Revisionsmeldungen im ADEXP-Format sehen folgendermaßen aus:

a. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 214 -ARCID GKP217 -ADEP EGNX -COP EMT -ADES DTTA -COORDATA -PTID AT -TO 1225 -TFL F270 -ROUTE N0430F290 UM247 XAT UJ124

b. -TITLE REV -REFDATA -SENDER -FAC K -RECVR -FAC G -SEQNUM 233 -ARCID GKP217 -ADEP EGNX -COORDATA -PTID XAT -TO 1225 -TFL F290 -ADES DTTA

ANHANG C (Informativ)

PHASEN DES DIALOGVERFAHRENS (SYSCO-LEVEL 1) - MELDUNGSABFOLGE

Meldungsabfolge

>PIC FILE= "L_2000254DE.008802.EPS">

ANHANG II

DARSTELLUNG DES DATENAUSTAUSCHS IN DER FLUGSICHERUNG (ADEXP), AUSGABE 2.0

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

INHALTSVERZEICHNIS

>PLATZ FÜR EINE TABELLE>

URHEBERRECHTLICHER HINWEIS

Dieses Dokument ist von der Agentur Eurocontrol erstellt worden.

Das Urheberrecht liegt 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

Für die Erarbeitung der vorliegenden Norm war die User Requirements Section der Zentralen Verkehrsflussregelungsstelle (CFMU) der Europäischen Organisation zur Sicherung der Luftfahrt (Eurocontrol) zuständig, in deren Verantwortungsbereich auch die Pflege des Dokuments fällt.

2. Dokument des EATCHIP-Arbeitsprogramms

Diese Norm wurde aufgrund der Vorgaben im Dokument des EATCHIP-Arbeitsprogramms (EWPD), ATM-Datenverarbeitungssysteme (DPS), Führungsaufgabe 09, erstellt.

3. Genehmigung der Norm

3.1. Die Annahme dieser Norm erfolgt gemäß den Verfahren, die in den Richtlinien für Eurocontrol-Normungsverfahren, Ref. 000-2-93, Ausgabe 1.0, aufgeführt sind.

3.2. Die Bestimmungen dieser Norm traten nach Annahme der Ausgabe 1.0 durch die Ständige Kommission von Eurocontrol im Jahre 1995 in Kraft und waren mit Wirkung vom 1. Dezember 1997 anzuwenden.

4. Technische Korrigenda und Änderungen

Diese Norm unterliegt zur Durchführung erforderlicher Änderungen oder technischer Korrigenda der ständigen Überarbeitung. Das Verfahren für die Pflege dieser Norm ist in Anhang H der Richtlinien für die einheitliche Erarbeitung und Vorlage der Eurocontrol-Normungsdokumente festgelegt.

Änderungen oder Ergänzungen mit Auswirkung auf die Grundprinzipien oder die Grammatik des ADEXP-Formats dürfen nur im Rahmen des formellen Überarbeitungsverfahrens vorgenommen werden, das in den Richtlinien für die einheitliche Erarbeitung und Vorlage der Eurocontrol-Normungsdokumente vorgeschrieben ist.

Vorschläge für Änderungen oder Ergänzungen dieser Norm sind schriftlich einzureichen an: CFMU Users Requirements Section (ADEXP), Eurocontrol Agency.

5. Redaktionelle Regeln

5.1. Das Format dieser Norm entspricht den Richtlinien für die einheitliche Erarbeitung und Vorlage der Eurocontrol-Normungsdokumente, wobei es jedoch einige Abweichungen gibt. Mit den geringen Abweichungen von den Richtlinien soll eine Verwechslung mit der Notation der Darstellung des Datenaustausches in der Flugsicherung (ADEXP) vermieden werden.

5.2. Zur Kennzeichnung des Status der einzelnen Aussagen wurde folgende Notation verwendet:

- Im Zusammenhang mit den normativen Elementen wird im Deutschen das Verb im Präsenz verwendet (im Englischen steht an dieser Stelle "shall"). Zur deutlicheren Hervorhebung steht im Deutschen vor diesen Sätzen die Abkürzung "(NE)" (für normatives Element).

- Elemente mit Empfehlungscharakter enthalten das Verb "sollte" und erscheinen ohne Hervorhebung in Kursivschrift, wobei der Status durch die Angabe "Empfehlung" gekennzeichnet ist.

6. Beziehung zu anderen Normendokumenten

Diese Norm ist verbunden mit:

Eurocontrol-Normendokument für den Online-Datenaustausch (OLDI)

7. Status der Anhänge zu dieser Norm

>PLATZ FÜR EINE TABELLE>

8. Sprache

Der Originaltext dieser Norm ist in englischer Sprache verfasst.

1. GELTUNGSBEREICH

1.1. ADEXP ist ein Format, kein Protokoll. Bis auf den Zeichensatz bestehen keine Beschränkungen hinsichtlich der zu verwendenden Übertragungsmedien oder Protokolle.

1.2. ADEXP bietet ein Format zur vorrangigen Verwendung beim Online-Nachrichtenaustausch von Rechner zu Rechner.

1.3. Im vorliegenden Dokument werden die Grundsätze und Syntaxregeln des ADEXP-Formats festgelegt. Diese Festlegung erfolgt in Form einer umfassenden Definition der ADEXP-Felder.

1.4. Das ADEXP-Format wurde zur Verwendung in folgenden Bereichen des Nachrichtenaustauschs spezifiziert (Informationen zu Dokumentverweisen siehe Abschnitt 0, Seite 3):

- Flugplanung: Austausch von Flugplandaten und damit verbundenen Nachrichten zwischen dem Integrated Initial Flight Plan Processing System (IFPS), Verkehrsdiensten der Flugsicherung (ATS) und Luftfahrzeughaltern (AO). (Dokumentverweis 3)

- Verkehrsflussregelung (ATFM): Austausch von Nachrichten zwischen dem Tactical System (TACT) der CFMU, den AO und den ATS. (Dokumentverweis 5)

- Koordinierung der Flugverkehrskontrolle: Austausch von taktischen Koordinierungsmeldungen zwischen Flugverkehrskontrollstellen (ATCU). (Dokumentverweis 6)

- Luftraummanagement: Austausch von Daten über die Verfügbarkeit von Luftraum zwischen nationalen ATS-Stellen, der CFMU und den AO. (Dokumentverweis 7)

- Koordinierung ziviler/militärischer Flugverkehr: Nachrichten zu zivilen/militärischen Flugdaten sowie Meldungen über Luftraumdurchquerungen. (Dokumentverweis 7).

1.5. Ausführliche Spezifikationen zum Gebrauch und zum Inhalt der Nachrichten innerhalb der einzelnen Gruppen finden sich in den Verweisdokumenten.

2. VERWEISE

2.1. Die folgenden Dokumente und Normen 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 und -normen 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. Zum Zeitpunkt der Veröffentlichung wird auf die nachfolgend aufgeführten Dokumente verwiesen; die Benutzer werden jedoch aufgefordert, wegen des neuesten Standes in den jeweiligen Ausgaben dieser Dokumente die Tabellen zum Gebrauch und zum Nachrichtenfeldaufbau nachzulesen.

1. ICAO Chicago Convention Annex 10 Volume I, Ausgabe vom November 1985;

2. ICAO Chicago Convention Annex 10 Volume II, Ausgabe vom Juli 1995;

3. IFPS and RPL Dictionary of Messages, Ausgabe 1.0, März 1998;

4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, Ausgabe vom November 1985 (einschließlich Amendment No 6 vom November 1995);

5. Guide To ATFM Message Exchange Eurocontrol Document Ref. TACT/USD/MSGGUID, Ausgabe 6.0, gültig ab März 1998,

6. Eurocontrol Standard for On-Line Data Interchange, Ausgabe 2.0, Oktober 1996.

7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, Ausgabe 1.0, Mai 1996.

3. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN

3.1. Notation

Die zur Beschreibung der Syntax verwendete Notation ist die Backus-Naur-Form (BNF). Die BNF definiert eine Regelmenge, die eine Klasse von Zeichenketten bestimmt. Bei der Klasse von Zeichenketten handelt es sich in diesem Fall um die Nachrichtenmenge, die sich als syntaktisch gültige ADEXP-Nachricht bezeichnen lässt.

3.2. Definitionen

(NE) Im Sinne dieses Eurocontrol-Normendokuments gelten die folgenden Definitionen:

Token: Zeichen oder Zeichensatz, das bzw. der sich aufgrund Vorhandenseins von Trennzeichen durch einen lexikalischen Analysator "extrahieren" lässt.

Symbol: Jeder "Term", der in einer BNF-Regel erscheint, aber kein Zeichen ist.

Terminales Symbol: Symbol, das als Zeichenfolge dargestellt wird.

Nichtterminales Symbol: Symbol, das durch ein oder mehrere terminale Symbole dargestellt wird.

ANMERKUNG

Ein nichtterminales Symbol lässt sich auch als Mischung von terminalen und nichtterminalen Symbolen darstellen.

3.3. Aufbau

3.3.1. Die BNF besteht aus einer Menge von Regeln bzw. Konstrukten der Form:

Symbol::= Ausdruck

ANMERKUNGEN

1) Das Zuweisungszeichen "::=" ist als "kann ersetzt werden durch" zu lesen.

2) Das "Symbol" ist als nichtterminal eingestuft.

3) Der "Ausdruck"-Teil enthält terminale und nichtterminale Symbole.

3.3.2. Terminale Symbole lassen sich direkt als Folge von Zeichen darstellen, die bei Vorhandensein von Trennzeichen von einem lexikalischen Analysator als Token erkannt werden können.

3.4. Konventionen

(NE) Im Sinne dieses Eurocontrol-Normendokuments gelten die folgenden Konventionen:

- Terminale Symbole werden in Großbuchstaben geschrieben.ANMERKUNG

Konventionsgemäß steht das terminale Symbol NIL für "kein terminales Symbol".

Es kommt bei Alternativmöglichkeiten wie im folgenden Beispiel zur Anwendung:

a::= b ( c | NIL ) wobei a durch (b gefolgt von c) oder nur durch b ersetzt werden kann.

- Nichtterminale Symbole (z. B. die linke Seite einer grammatischen Produktionsregel) werden in Kleinbuchstaben geschrieben.

- In den Regeln erscheinende Zeichen und Kettenliterale werden zwischen einfache (') bzw. doppelte Anführungszeichen (") gesetzt.

Beispiele

1) HYPHEN::= '-'

2) title::= '-' "TITLE" titleid

Bei einigen Datenmodellierungen kann es erforderlich sein, auf andere Weise als durch Groß- und Kleinschreibung zwischen terminalen und nichtterminalen Symbolen zu unterscheiden.

Wenn auf andere Weise als durch Groß- und Kleinschreibung zwischen terminalen und nichtterminalen Symbolen unterschieden werden muss, empfiehlt es sich, Suffixe wie folgt anzuhängen: "_at" für einen Hilfsterm, "_pf" für ein Primärfeld und "_sf" für ein Teilfeld.

3.5. Operatoren

(NE) Im Sinne dieses Eurocontrol-Normendokuments gelten folgende Operatoren:

Optional: Wenn es zulässig ist, dass Symbole an einer Stelle in der Grammatik erscheinen oder nicht erscheinen. Die optionalen Symbole stehen in eckigen Klammern "[" und "]".

Closure: Wenn eine Gruppe von Symbolen null mal oder öfter erscheinen darf. Die Symbole sind von geschweiften Klammern "{" und "}" eingeschlossen. Ein Symbol vor der "{" gibt an, wie oft die Symbolgruppe mindestens erscheinen darf. Ein Symbol nach der "}" gibt an, wie oft die Symbolgruppe höchstens erscheinen darf.

Auswahlmöglichkeit: Wenn eine Anzahl von alternativen Symbolen an einer Stelle der Grammatik erscheinen kann. Die Auswahlmöglichkeit wird durch "|" dargestellt.

Verkettung: Darstellung von sequentiell aufeinander folgenden Symbolen, wobei ein oder mehrere Trennzeichen dazwischen stehen können. Eine explizite Darstellung dafür gibt es nicht. Es lassen sich zwei Typen unterscheiden:

- Strenge Verkettung: (NE) Auf lexikalischer Ebene können die Regeln eine Verkettung von Terminalen beinhalten, die streng aufeinander folgen (ohne Trennzeichen); in diesem Falle ist das Symbol "!" zu verwenden.Beispiel

datetime:: = date ! timehhmm

So bedeutet beispielsweise "9912251200" 25. Dezember 1999, 12.00 Uhr.

- Lockere Verkettung: Trennzeichen zwischen Terminalen sind erlaubt. Die Darstellung einer lockeren Verkettung innerhalb einer Regel kann entweder implizit oder explizit erfolgen.Beispiele

1) Implizit:

dct::= '-' "DCT" point point

2) Explizit

dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

>PLATZ FÜR EINE TABELLE>

ANMERKUNGEN

1) (NE) Eine Verkettung hat stets Vorrang vor der Auswahlmöglichkeit. Zur Änderung der Auswertungsreihenfolge des Ausdrucks werden runde Klammern "(" und ")" verwendet.Beispiel

>PLATZ FÜR EINE TABELLE>

2) Bei allen Regeln bleibt zur Erhaltung der Lesbarkeit die zulässige Präsenz von Trennzeichen zwischen den Symbolen implizit.

Empfehlung

Ist die Vorrangsituation zwischen den obengenannten Operatoren unklar, sollten zur Klarstellung der gewünschten Auswertungsreihenfolge runde Klammern gesetzt werden.

3.6. Abkürzungen

>PLATZ FÜR EINE TABELLE>

4. ADEXP-GRUNDSÄTZE

4.1. Vom Menschen lesbares Textformat

4.1.1. Das ADEXP-Format ist ein auf Zeichen basierendes Textformat.

4.1.2. Die ADEXP-Nachrichten bleiben für einen Humanoperator lesbar, so dass operationelle oder Abstimmungsfragen besser bewältigt werden können.

4.1.3. Ein Textformat ist zudem offener und verständlicher.

4.2. Identifizierte und abrufbare Felder

4.2.1. (NE) Eine Nachricht in ADEXP-Format setzt sich aus Feldern zusammen.

4.2.2. (NE) Felder sind durch ein spezielles Feldanfangszeichen, den Bindestrich ("-"), abgegrenzt und werden durch spezifische Schlüsselwörter identifiziert.ANMERKUNG

Es sei darauf hingewiesen, dass bestimmte Felder (die laut syntaktischer Definition die lexikalische Einheit "CHARACTER" enthalten) als Bestandteil des Feldinhalts das Zeichen "-" enthalten dürfen.

4.2.3. Durch diesen Ansatz verbessern sich die Erweiterbarkeit und Robustheit des Formats. (Fehlt ein Feld oder ist es inkorrekt, kann es übersprungen werden, und der übrige Teil der Nachricht lässt sich dennoch interpretieren. (Siehe Abschnitt 4.3).

4.2.4. (NE) Eine weitere Konsequenz besteht darin, dass sich die Reihenfolge der Felder in einer Nachricht nicht auf die Bestimmung ihrer Zulässigkeit auswirkt. Eine Ausnahme bildet das erste Feld (das obligatorische Titelfeld), welches die zulässigen Felder bestimmt.

4.2.5. Bei Feldern kann es sich um Basisfelder oder Verbundfelder handeln.

4.2.6. Die Bestandteile von Verbundfeldern heißen Teilfelder und sind durch das Vorhandensein von Schlüsselwörtern, abgegrenzt durch ein Feldanfangszeichen, definiert.

4.2.7. Basisfelder sind Felder, die keine Teilfelder enthalten.

4.2.8. Die Basis- oder Verbundfelder, die die erste Definitionsebene einer Nachricht bilden, heißen Primärfelder.

4.2.9. Alle Bestandteile einer niedrigeren Ebene sind definitionsgemäß Teilfelder, die wiederum Basis- oder Verbundfelder sein können.

4.2.10. Es gibt zwei Arten von Verbundfeldern - strukturierte Felder und Listenfelder.

4.2.11. Strukturierte Felder haben einen vorgegebenen, ausschließlich aus Teilfeldern bestehenden Inhalt. Die Reihenfolge der Teilfelder in einem strukturierten Feld ist OHNE Bedeutung.

4.2.12. Listenfelder werden mit dem Schlüsselwort BEGIN eingeleitet und mit dem Schlüsselwort END abgeschlossen. Dazwischen kann ein und dasselbe Teilfeld oder eine Kombination von Teilfeldern wiederholt auftreten. Die Reihenfolge, in der dies innerhalb eines Listenfeldes geschieht, ist semantisch von Bedeutung.

4.2.13. Im folgenden wird der Begriff "Feld" in übergreifender Bedeutung für Primär- und/oder Teilfelder gebraucht, sofern nicht eine anderweitige Bestimmung angegeben ist.

4.2.14. Felder in einer Nachricht können je nach Syntaxdefinition optional oder obligatorisch sein.

4.3. Nichterkannte Felder

4.3.1. (NE) Erscheint in einer Nachricht ein unbekanntes Feld, so wird es ignoriert.

4.3.2. Wenn also das System, das die Nachricht analysiert, ein Schlüsselwort nicht erkennt, wird der gesamte Text bis zum nächsten bekannten Primärfeld, das sich nicht innerhalb eines Listenfeldes befindet, ignoriert.

4.3.3. In Abhängigkeit vom Nachrichtentitel kann das ignorierte Feld eine Rückweisung der geparsten Nachricht bewirken oder nicht.ANMERKUNG

Es sei darauf hingewiesen, dass ADEXP zwar für diese Art von Flexibilität ausgelegt ist, es aber den für die Festlegung der Schnittstellenanforderungen Verantwortlichen überlassen bleibt, für die einzelnen Nachrichten anzugeben, wie das System auf ein nichterkanntes Feld reagieren soll.

4.3.4. Handelt es sich bei dem unbekannten Feld um ein Listenfeld (festgestellt aufgrund des Schlüsselworts -BEGIN), wird sein gesamter Inhalt (bis zum entsprechenden Schlüsselwort -END) ignoriert.

4.3.5. Um bei der Wiederherstellung im Anschluss an das Überspringen eines unerkannten Feldes jede Mehrdeutigkeit zu vermeiden, muss ein Schlüsselwort entweder ein Primärfeld oder ein Teilfeld einleiten.

4.3.6. Somit lassen sich zwei Arten von Schlüsselwörtern festlegen:

- Primärschlüsselwörter

- Teilschlüsselwörter.

4.3.7. (NE) Nachdem ein Schlüsselwort für eine der beiden Arten festgelegt ist, darf es in einer anderen Nachrichtengruppe nicht für die andere Art verwendet werden, es sei denn, es befindet sich innerhalb eines Listenfeldes. Ein Primärschlüsselwort kann überall in einem Listenfeld auftreten, ohne dass dies zu Mehrdeutigkeit führt, da das Vorhandensein des Schlüsselwortes BEGIN anzeigt, dass das innere Auftreten als Teilfeld zu betrachten ist.Beispiele (für die Verwendung der Schlüsselwortarten)

1) Primärfeld

-RFL F330

2) Teilfeld: stets innerhalb eines "Verbundfeldes"

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

wobei -GEO ein primäres Verbundfeld ist und -GEOID, -LATTD sowie LONGTD Teilfelder sind.

3) Listenfeld

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

...

-END RTEPTS

wobei "-BEGIN" das Listenfeld anzeigt und "RTEPTS" ein Primärfeld ist.

ANMERKUNG

"RFL" ist als Primärfeld definiert. Nur bei Einschließung in einem Listenfeld kann ein Primärfeld als Teilfeld verwendet werden. (Siehe Beispiel 3).

5. ADEXP-SYNTAXREGELN

5.1. Lexikalische Elemente

5.1.1. Zeichensatz

5.1.1.1. (NE) Als Zeichensatz für das ADEXP-Format wird das International Alphabet Number 5 (IA-5) entsprechend der Festlegung in Verweis 1 verwendet.

5.1.1.2. Das ADEXP-Format ist als Format für den Datenaustausch von Rechner zu Rechner konzipiert, das auf verschiedenen Rechnernetzen oder auf speziellen Rechner-Rechner-Verbindungen übertragen werden kann. Darüber hinaus besteht die Anforderung, einige ADEXP-Nachrichten - speziell bei Flugplanung und ATFM - über das Feste Flugfernmeldenetz (AFTN) austauschen zu können.

5.1.1.3. (NE) Bei Nachrichten, die über das AFTN übermittelt werden sollen, wird der Zeichensatz auf die Zeichen beschränkt, die eine direkte Korrelation zwischen dem Internationalen Telegraphenalphabet 2 (ITA-2) und IA-5 laut Definition in Verweis 1 besitzen.ANMERKUNG

Neben den nachfolgend definierten Druckzeichen und Formatsteuerzeichen sind im Zeichensatz ITA-2 auch "Signale" (wie z. B. Lochstreifen) festgelegt. Sie gehören nicht zum zulässigen Zeichensatz für ADEXP-Nachrichten.

5.1.1.4. Für die Verwendung in ADEXP-Nachrichten, die über das AFTN übertragen werden können, sind folgende Druckzeichen und Formatsteuerzeichen gestattet:

Druckzeichen

a) Großbuchstaben (A bis Z)

b) Ziffern (0 bis 9)

c) Folgende Sonderdruckzeichen:

1) Leerzeichen " "

2) Klammer auf "("

3) Klammer zu ")"

4) Bindestrich "-"

5) Fragezeichen " "

6) Doppelpunkt ":"

7) Punkt "."

8) Komma ","

9) Apostroph "'"

10) Gleichheitszeichen "="

11) Pluszeichen "+"

12) Schrägstrich "/"

Formatsteuerzeichen

a) Carriage-Return (Wagenrücklauf)

b) Line-Feed (Zeilenvorschub)

5.1.2. Lexikalische Grundeinheiten

Die folgenden lexikalischen Grundeinheiten sind zur Verwendung in dieser Spezifikation festgelegt:

- ALPHA ::= 'A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'

- DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'

- ALPHANUM ::= ALPHA | DIGIT

- SPACE ::= ' '

- HYPHEN ::= '-'

- FEF ::= Carriage_return | Line_Feed

- SEP ::= 1{ SPACE | FEF }

- SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'

- CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF | HYPHEN

- LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF

- START-OF-FIELD ::= HYPHEN

ANMERKUNG

LIM_CHAR steht für jedes zulässige Zeichen außer HYPHEN; letzteres ist für die Anzeige des Feldanfangs reserviert. CHARACTER dagegen steht für jedes zulässige Element des Zeichensatzes.

5.1.3. Zeilen, Trennzeichen und Begrenzungszeichen

5.1.3.1. (NE) Die Aufteilung des Textes in Zeilen hat keine syntaktischen Auswirkungen.

5.1.3.2. Ein Trennzeichen kann ein Leerzeichen oder ein Formatsteuerzeichen sein.

5.1.3.3. (NE) Felder werden nur durch das Vorhandensein eines Feldanfangszeichens, gefolgt von einem Schlüsselwort, abgegrenzt.

5.1.3.4. Die gesamte Nachricht könnte daher zulässigerweise auf einer Zeile stehen.

5.1.4. Werte mit Vorzeichen

5.1.4.1. Unter Umständen muss ein numerischer Wert als negativ gekennzeichnet werden.

5.1.4.2. (NE) Felder, die einen negativen Wert anzeigen sollen, müssen innerhalb ihrer Syntaxdefinition den Wert ausdrücklich als "Wert mit Vorzeichen", d. h. als positiv oder negativ kennzeichnen. Ein nicht derart definiertes Feld darf keinen negativen Wert darstellen.

5.1.4.3. (NE) Einem "Wert mit Vorzeichen" muss stets der Buchstabe "N" mit der Bedeutung "negativ" oder der Buchstabe "P" mit der Bedeutung "positiv" vorangestellt sein. Vor einem Nullwert kann entweder ein "N" oder ein "P" stehen.

5.1.4.4. (NE) Die Syntax eines Feldes mit zulässigem "Wert mit Vorzeichen" lautet folgendermaßen:

'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}

Beispiel

Ein Feld mit der Bezeichnung "NUMBER", das einen negativen Wert von einer bis acht Ziffern enthalten darf, würde definiert als:

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

Daher:

-NUMBER P5 Wert von "number" ist +5

-NUMBER N5 Wert von "number" ist -5

-NUMBER 5 ungültige Syntax, da entweder ein "P" oder ein "N" muss vorhanden sein

5.1.5. Schlüsselwörter

5.1.5.1. Ein Schlüsselwort (keyword) ist jede beliebige Folge von Großbuchstaben oder Ziffern. Es dient nur dann zur Einführung eines Feldes, wenn ihm ein Feldanfangszeichen ("-") vorangestellt ist.

keyword::= 1{ ALPHANUM }

5.1.5.2. (NE) Schlüsselwörter müssen folgender Syntax genügen:

'-'!{SEP}!"KEYWORD"!1{SEP}! < subfield/s or contained value >

d. h. ein Schlüsselwort wird durch null oder mehr Trennzeichen von seinem "Feldanfangszeichen" getrennt. Unmittelbar dahinter steht ein oder mehr Trennzeichen, gefolgt von dem/den entsprechenden Teilfeld(ern) oder dem enthaltenen Wert (contained value).

ANMERKUNG

Es sei darauf hingewiesen, dass ein Schlüsselwort und sein vorangestelltes Feldanfangszeichen durch jede beliebige Anzahl von Trennzeichen getrennt sein kann. Es ist auch möglich, dass kein Trennzeichen vorhanden ist.

BeispieleAls Feldeinführung ist folgendes zulässig:)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Empfehlung

Es empfiehlt sich, Trennzeichen zwischen dem Feldanfangszeichen "-" und dem darauffolgenden Schlüsselwort zu vermeiden.

ANMERKUNG

1) Von den obigen Beispielen wird die erste Verwendungsart empfohlen.

2) Zu beachten ist ferner, dass unmittelbar nach einem Schlüsselwort mindestens 1 Trennzeichen stehen muss.

5.1.5.4. Im gesamten Dokument wird die Verkettung von Elementen, die durch mindestens 1 Trennzeichen getrennt sind, implizit durch die Notation der "lockeren Verkettung" (siehe 3.5) dargestellt.ANMERKUNG

Wie an anderer Stelle noch erläutert wird, können Schlüsselwörter auch Listenfelder einführen, wenn ihnen das Schlüsselwort BEGIN vorangestellt ist.

5.1.5.5. (NE) Schlüsselwörter müssen unter Wahrung der semantischen Bedeutung so kurz wie möglich sein.

5.1.5.6.

>PLATZ FÜR EINE TABELLE>

5.1.5.7. Zur Vermeidung von Mehrdeutigkeit (doppelte Verwendung des gleichen Schlüsselwortes mit unterschiedlicher Bedeutung) oder Redundanz (unterschiedliche Schlüsselwörter mit gleicher Bedeutung) werden in dieser Norm in Anhang A (A3) eine Zentrale Definitionstabelle der Primärfelder (d. h. Primärschlüsselwörter) und in Anhang (A4) eine Zentrale Definitionstabelle der Teilfelder (d. h. Teilschlüsselwörter) geführt.

5.2. Felder

5.2.1. Feldsyntax

field::= basic_field | structured_field | list_field

basic_field::= '-' keyword contained_values

contained_values::= {CHARACTER}

list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keyword

structured_field::= '-' keyword field_1 field_2 ...field_n

ANMERKUNG

Wie im Falle der Listenfelder zu sehen sein wird, ist dem Schlüsselwort nicht unmittelbar das Zeichen "-", sondern das Konstrukt "-""BEGIN" vorangestellt.

5.2.2. Nachrichtenaufbau unter dem Gesichtspunkt der Felder

5.2.2.1. (NE) Das erste Feld einer ADEXP-Nachricht ist stets ein TITLE-Feld (d. h. ein Feld, das von einem TITLE-Schlüsselwort eingeleitet wird).

5.2.2.2. (NE) Im Hinblick auf die zugehörigen Primärfelder ist der übrige Inhalt einer Nachricht durch den TITLE festgelegt.

5.2.2.3. (NE) Die Syntax von Nachrichten, die einem bestimmten TITLE entsprechen, ist durch die darin enthaltenen Felder (definiert durch ihre Schlüsselwörter) festgelegt:

- Name und zulässiger Inhalt seiner Primärfelder;

- Name und zulässiger Inhalt seiner Teilfelder.

5.2.3. Basisfelder

5.2.3.1. (NE) Die Syntax von Basisfeldern lautet folgendermaßen:

basic_field::= '-' keyword contained_values

5.2.3.2. "Contained_values" (enthaltene Werte) legt den Text fest, der den Wert des Feldes ausmacht, und darf kein Teilfeld einleiten.Beispielregel

arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")

ANMERKUNG:

1) Eine explizite Äquivalentregel davon lautet:

arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) Ein Beispielteil einer Nachricht ist:: "-ARCTYP ZZZZ".

5.2.3.3. Empfehlung

Befinden sich mehr als zwei enthaltene Werte innerhalb eines Basisfelds und soll darüber hinaus "Auswahlmöglichkeit" oder "Option" zwischen den Werten ausgedrückt werden, empfiehlt es sich, das Feld als strukturiertes Feld zu gestalten und die enthaltenen Werte in Teilfelder einzuschließen.

5.2.4. Listenfelder

5.2.4.1. (NE) Die Syntax von Listenfeldern lautet folgendermaßen:

list_field::='-' "BEGIN" keyword { subfields } '-' "END" keyword

5.2.4.2. Die "subfields" können jede beliebige Kombination von Teilfeldern sein, die null mal oder öfter innerhalb des Listenfelds auftreten können.

5.2.4.3. (NE) Die in einem Listenfeld enthaltene Teilfelderliste bildet eine geordnete Menge (die Ordnung der Teilfelder ist signifikant).Beispielregel

addr::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"

ANMERKUNG

1) Dieses Beispiel zeigt, dass es sich bei einem "addr"-Feld um ein Listenfeld handelt, in dem ein "fac"-Teilfeld (eine ATS-Einrichtung) null Mal oder öfter auftritt.

2) Beispielteil einer Nachricht mit ADDR als Listenfeld mit FAC-Teilfeldern:-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) Beispielteil einer Nachricht mit einer Kombination von Teilfeldern:

xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5. Strukturierte Felder

5.2.5.1. (NE) Die Syntax von strukturierten Feldern lautet folgendermaßen:

structured_field::= '-' keyword field_1 field_2...field_n

5.2.5.2. (NE) Die zulässigen enthaltenen Teilfelder in einem strukturierten Feld hängen nur vom strukturierten Feld selbst ab.

5.2.5.3. (NE) Die Reihenfolge, in der Teilfelder in einem strukturierten Feld auftreten, ist unwichtig, so dass künftige Erweiterungen (durch Hinzufügen neuer enthaltener Teilfelder) problemlos möglich sind.Beispielregel

pt::= '-' "PT" ptid [fl] [eto]

ANMERKUNGEN

1) Hiermit wird as "pt"-Feld als strukturiertes Feld mit einem Punkt ("ptid"-Teilfeld) festgelegt, optional gefolgt von einer errechneten Flugfläche ("fl"-Teilfeld), optional gefolgt von einer voraussichtlichen Überflugzeit ("eto"-Teilfeld).

2) Ein Beispiel für das Auftreten dieses Feld wäre:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

5.2.5.4. Empfehlung

Zeichnet sich ab, dass es in einem Feld häufiger zu Änderungen kommt, sollte es als strukturiertes Feld angelegt werden. Auf diese Weise ist eine schrittweise Erweiterung seiner Teilfelder möglich. Ein Basisfeld mag einfacher zu verwenden oder der Umgang damit vertrauter sein, doch ist es auf eine feste Folge von Elementen (Werten) mit stark eingeschränkten Erweiterungsmöglichkeiten begrenzt.

5.2.6. Das COMMENT-Feld

5.2.6.1. Das Anmerkungsfeld führt einen Bereich mit frei wählbarem Text ein, in dem sämtliche verfügbaren Zeichen mit Ausnahme des Feldanfangszeichens ("-") verwendet werden können und das sich bis zum nächsten Feld erstreckt.

comment::= '-' "COMMENT" { LIM_CHAR }

Beispiel

COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA

5.2.7. Das TITLE-Feld

5.2.7.1. (NE) Das erste Feld einer ADEXP-Nachricht ist stets ein TITLE-Feld, dessen Syntax folgendermaßen lautet:

title::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2. Die möglichen Werte des TITLE-Feldes bestehen aus der Menge von ADEXP-Nachrichtentiteln, wie sie in Anhang B dieser Norm aufgeführt sind.Beispiel

-TITLE IFPL

6. NORMIERTE BESCHREIBUNG VON ADEXP-NACHRICHTEN

6.1. Einleitung

6.1.1. In den folgenden Absätzen ist festgelegt, wie das ADEXP-Format unterschiedlicher Nachrichtenkategorien im Rahmen der vorliegenden Norm normiert beschrieben werden muss.

6.1.2. Zur normierten Beschreibung gehören:

- Definition von Hilfstermen;

- Definition von Syntax und Semantik der einzelnen Primärfelder;

- Definition von Syntax und Semantik der einzelnen Teilfelder;

- Definition der einzelnen Nachrichtengruppen mit Verweis auf ihre Definitionsdokumente.

6.1.3. Diese Norm enthält keine Einzelheiten zu Feldaufbau und Dateneinsetzungsregeln für die einzelnen Nachrichtentitel.

6.1.4. Es sollte auf die Definitionsdokumente (Schnittstellenspezifikation) Bezug genommen werden, die für die jeweilige Nachrichtengruppe anwendbar sind (siehe Abschnitt 6.5.7).

6.1.5. In den Definitionsdokumenten sollten die folgenden normierten Informationen für die einzelnen Nachrichtentitel enthalten sein:

- eine Liste obligatorischer Primärfelder;

- eine Liste optionaler Primärfelder;

- die Dateneinsetzungsregeln für die einzelnen Felder und insbesondere die Regeln für die Verwendung von in der vorliegenden Norm als optional definierten Teilfelder;

- die Wiederherstellungsregeln im Anschluss an die Feststellung eines nichterkannten Feldes.

6.1.6. Die für alle Eurocontrol-Mitgliedstaaten derzeit festgelegten und abgestimmten Felder zur Verwendung innerhalb der verschiedenen Nachrichtenkategorien, die für den Einsatz mit ADEXP definiert wurden, sind in Anhang A dieses Dokuments aufgeführt.

6.1.7. (NE) Ein Feld darf nicht für einen anderen als in seiner semantischen Beschreibung angegebenen Zweck verwendet werden.

6.1.8. Ein zentrales Register der reservierten Felder findet sich in Anhang D. "Reservierte Felder" sind zur Verwendung innerhalb der derzeit festgelegten ADEXP-Nachrichten nicht vereinbart worden. Normalerweise handelt es sich dabei um Felder, die für eine mögliche künftige Verwendung vorgesehen sind oder die lokal innerhalb nationaler Systeme verwendet werden. Mit der Aufnahme in diese Norm wird der Zweck verfolgt, die Einheitlichkeit von Feldtiteln sichern zu helfen und unnötige Redundanz zu vermeiden.

6.2. Hilfsterme

6.2.1. Für eine lesbare Definition von Feldern ist es oft angebracht, Hilfsterme in der Grammatikbeschreibung einzuführen.

6.2.2. Hilfsterme leiten kein Feld oder Teilfeld ein und stehen daher nicht im Zusammenhang mit einem bestimmten Schlüsselwort. Sie können jedoch in der Definition von mehr als einem Feld, Teilfeld oder Hilfsterm auftreten. Beispielsweise lässt sich ein Hilfsterm wie "date" in der Definition vieler Felder verwenden.

6.2.3. (NE) Alle erforderlichen Hilfsterme sind alphabetisch einzuführen und werden in Anhang A (A2) dieser Norm definiert.

6.2.4.

>PLATZ FÜR EINE TABELLE>

6.3. Definition von Primärfeldern

6.3.1. (NE) Alle in ADEXP-Nachrichten verwendeten Primärfelder müssen der Syntax und der Semantik nach Anhang A (A3) dieser Norm entsprechen.

6.3.2. Zunächst wird die Syntax jedes einzelnen Feldes, danach in einfachen klaren und eindeutigen Worten dessen Semantik angegeben.

6.3.3. Die Feldsyntax wird mit Hilfe der in Abschnitt 3 dieser Norm vorgestellten BNF-Notation ausgedrückt.

6.3.4.

>PLATZ FÜR EINE TABELLE>

6.4. Definition von Teilfeldern

6.4.1. (NE) Alle in ADEXP-Nachrichten verwendeten Teilfelder müssen der Syntax und der Semantik nach Anhang A (A3) dieser Norm entsprechen.

6.4.2. Darüber hinaus werden zum Zwecke des Querverweises die Primärfelder ausgewiesen, in denen ein bestimmtes Teilfeld erscheint.

6.4.3. Da ein Teilfeld auch ein Teilfeld anderer Teilfelder sein kann, wird zudem ein Querverweis auf diese Teilfelder angegeben.

6.4.4.

>PLATZ FÜR EINE TABELLE>

6.5. Nachrichtengruppe

6.5.1. Die Nutzungskategorien (Gruppen) von Nachrichten, die zur Verwendung mit dem ADEXP-Format festgelegt wurden, werden in Anhang E dieser Norm vorgestellt.

6.5.2. Die Gruppen werden anhand der Nutzungsart der ausgetauschten Nachrichten definiert und sind oft durch die betreffenden Systeme charakterisiert.

6.5.3. (NE) Bei den einzelnen Nachrichtengruppen ist auf die jeweiligen Definitionsdokumente Bezug zu nehmen.

6.5.4. (NE) Ein bereits für eine Nachrichtengruppe verwendeter Titelwert darf nicht mit anderer Bedeutung für eine andere Gruppe wiederverwendet werden.

6.5.5. (NE) In Anhang B dieser Norm wird ein zentrales Register der Nachrichtentitel geführt.

6.5.6. Für die jeden der im zentralen Register der Nachrichtentitel aufgeführten Titel wird ein Verweis auf die dazugehörige Gruppe angegeben. Die Bezugnahme auf die Definitionsdokumente der einzelnen Nachrichtentitel erfolgt somit über die Nachrichtengruppe.

6.5.7. Ein zentrales Register der reservierten Nachrichtentitel befindet sich zudem in Anhang C. "Reservierte" Nachrichtentitel sind zur Verwendung innerhalb der derzeit festgelegten ADEXP-Nachrichtengruppen nicht vereinbart worden. Normalerweise handelt es sich um Nachrichten, die für eine mögliche künftige Verwendung vorgesehen sind oder die lokal innerhalb nationaler Systeme verwendet werden. Mit der Aufnahme in diese Norm wird der Zweck verfolgt, die Einheitlichkeit von Nachrichtentiteln sichern zu helfen und unnötige Redundanz zu vermeiden.

ANHANG A (Normativ)

ADEXP-FELDDEFINITIONEN

A.1. Einleitung

In diesem Anhang sind alle Felder - Hilfsterme, Primärfelder und Teilfelder - aufgeführt, die zur Verwendung in ADEXP definiert worden sind.

A.2. ADEXP-Hilfsterme

>PLATZ FÜR EINE TABELLE>

A.3. ADEXP-Primärfelder

>PLATZ FÜR EINE TABELLE>

A.4. ADEXP-Teilfelder

>PLATZ FÜR EINE TABELLE>

ANHANG B (Normativ)

ZENTRALES REGISTER DER ADEXP-NACHRICHTENTITEL

>PLATZ FÜR EINE TABELLE>

ANHANG C (Normativ)

ZENTRALES REGISTER DER RESERVIERTEN NACHRICHTENTITEL

C.1. Einleitung

Dieser Anhang enthält ein zentrales Register reservierter Nachrichtentitel, die noch nicht zur Verwendung in ADEXP definiert worden sind. Die Aufnahme der Titel in dieses Register zeigt an, dass sie entweder zur künftigen Verwendung vorgesehen sind oder bereits verwendet werden, allerdings auf lokale Systeme beschränkt.

C.2. Zweck

Mit der Auflistung von Titeln, die noch nicht formell zur Verwendung im Rahmen dieser ADEXP-Norm angenommen worden sind, soll soweit wie möglich verhindert werden, dass bei Notwendigkeit eines neuen Titels für einen bestimmten Zweck Redundanz entsteht bzw. dass ein Titel erstellt wird, der sich bereits in einem lokalen System in Gebrauch befindet.

C.3. Reservierte Nachrichtentitel

>PLATZ FÜR EINE TABELLE>

ANHANG D (Normativ)

ZENTRALES REGISTER DER RESERVIERTEN FELDER

D.1. Einleitung

Dieser Anhang enthält ein zentrales Register reservierter Felder, Primär-, Teilfeld- und Hilfsterme, die noch nicht zur Verwendung in ADEXP definiert worden sind. Die Aufnahme in dieses Register zeigt an, dass sie entweder zur künftigen Verwendung vorgesehen sind oder bereits verwendet werden, allerdings auf lokale Systeme beschränkt.

D.2. Zweck

Mit der Auflistung von Feldern, die noch nicht formell zur Verwendung im Rahmen dieser ADEXP-Norm angenommen worden sind, soll soweit wie möglich verhindert werden, dass bei Notwendigkeit eines neuen Felds für einen bestimmten Zweck Redundanz entsteht bzw. dass ein Schlüsselwort erstellt wird, das sich bereits in einem lokalen System in Gebrauch befindet.

D.3. Reservierte Hilfsterme

>PLATZ FÜR EINE TABELLE>

D.4. Reservierte Primärfelder

>PLATZ FÜR EINE TABELLE>

D.5. Reservierte Teilfelder

>PLATZ FÜR EINE TABELLE>

ANHANG E (Informativ)

VORSTELLUNG DER NACHRICHTENGRUPPEN

EINLEITUNG

In diesem Anhang werden die verschiedenen Gruppen bzw. Kategorien von Nachrichten vorgestellt, die in ADEXP ausgetauscht werden können. Eine vollständige Auflistung aller ADEXP-Nachrichtentitel findet sich in Anhang B.

ANMERKUNG

Die genauen Bedingungen, Anwendungsregeln und der Gebrauch der Felder, insbesondere optionaler Felder, sind der einschlägigen Dokumentation (z. B. Dokument zur Schnittstellenspezifikation) der betreffenden Systeme zu entnehmen.

E.1. Flugplanmeldungen

E.1.1. Einleitung

Nachrichten dieser Kategorie werden vorrangig zwischen AO, IFPS und den entsprechenden ATS-Stellen ausgetauscht.

E.1.2. Definition der Nachrichtentitel

Nachrichtentitel innerhalb dieser Kategorie:

ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.

Alle Definitionen für diese Nachrichten sind im Verweisdokument 3 enthalten.

E.1.3. Aufbau der Primärfelder

Eine ausführliche Definition des Nachrichteninhalts, der Dateneinsetzungsregeln und des Gebrauchs von obligatorischen und optionalen Feldern findet sich im Verweisdokument 3.

Beispiel:

Flugplanmeldung

-TITLE IFPL

-BEGIN ADDR -FAC CFMUTACT -FAC EGZYTTFO -FAC EGZYTTTE -FAC EGTTZGZP

-FAC EGKKZPZI -FAC LFFBTEST -FAC LESCYFPX -FAC LPPCIFPS -FAC LPPTYWYA

-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS

-END ADDR

-ADEP EGKK -ADES LPPT -ARCID AZX752 -ARCTYP BA11 -CEQPT S

-EOBD 980305 -EOBT 1130 -FILTIM 041530 -IFPLID AA00463686 -ORGNID AZXRPLO

-SEQPT C -SRC RPL -WKTRC M -TTLEET 0230 -RFL F330 -SPEED N0400 -FLTRUL I

-FLTTYP S

-ROUTE N0400F330 SAM UR41 ORTAC UR1 QPR UR107 AVS UG41 FTM

-BEGIN RTEPTS

-PT -PTID EGKK -FL F000 -ETO 980305113000

-PT -PTID SAM -FL F196 -ETO 980305114012

-PT -PTID ASPEN -FL F288 -ETO 980305114658

-PT -PTID ORTAC -FL F311 -ETO 980305114959

-PT -PTID GUR -FL F330 -ETO 980305115617

-PT -PTID AKEMI -FL F330 -ETO 980305120118

-PT -PTID LARSI -FL F330 -ETO 980305120626

-PT -PTID QPR -FL F330 -ETO 980305121236

-PT -PTID ERWAN -FL F330 -ETO 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS

-ATSRT UG41 AVS FTM

E.2. Nachrichten der Verkehrsflusslenkung

E.2.1. Einleitung

Nachrichten dieser Kategorie werden vorrangig zwischen dem TACT-System der EUROCONTROL-CFMU, Luftfahrzeugbetreibern und ATS-Stellen ausgetauscht.

E.2.2. Rechnergestützte Slotzuteilung (CASA)

Nachrichtentitel innerhalb dieser Kategorie:

DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.

E.2.2.1. Definition der Nachrichtentitel

Alle Definitionen für diese Nachrichten sind im Verweisdokument 5 enthalten.

E.2.2.2. Aufbau der Primärfelder

Eine ausführliche Definition des Nachrichteninhalts, der Dateneinsetzungsregeln und des Gebrauchs von obligatorischen und optionalen Feldern findet sich im Verweisdokument 5.

Beispiel:

-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945

-CTOT 010 -REGUL UZZU11 -TAXITIME 0020

E.2.3. Informationsmeldungen

Nachrichtentitel innerhalb dieser Kategorie:

FSA

E.2.3.1. Definition der Nachrichtentitel

Definitionen für diese Nachrichten sind im Verweisdokument 5 enthalten.

E.2.3.2. Aufbau der Primärfelder

Eine Definition des Nachrichteninhalts, der Dateneinsetzungsregeln und des Gebrauchs von obligatorischen und optionalen Feldern findet sich im Verweisdokument 5.

Beispiel:

First System Activation Message

-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646

E.3. ATC-Koordinierungsmeldungen

E.3.1. Einleitung

Koordinierungsmeldungen dienen der Automatisierung der operationellen Koordinierung und des Informationsaustauschs zwischen ATC-Stellen. Die Meldungen sorgen für eine rechtzeitige Zustellung operationeller Koordinierungsinformationen durch genormte Datenextraktion und -übertragung.

E.3.2. Definition der Nachrichtentitel

Nachrichtentitel innerhalb dieser Kategorie:

ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.

Alle Definitionen für diese Nachrichten sind im Verweisdokument 6 enthalten.

E.3.3. Aufbau der Primärfelder

Alle Definitionen für diese Nachrichten sind im Verweisdokument 6 enthalten.

Beispiele:

Hand-Over Proposal Message

-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253

-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN

Activate Message

-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253

-SSRCODE A7041 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350

-ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON

E.4. Luftraummanagementmeldungen

E.4.1. Einleitung

Nachrichten zur Verwendung in der Koordinierung des Luftraummanagements. Diese Meldungen betreffen das Management des Umfelds, in dem sich der Verkehr bewegt: ständig und bedingt verfügbare Strecken, zeitweilig getrennte Gebiete, Gefahren- und Sperrgebiete usw.

E.4.2. Definition der Nachrichtentitel

Nachrichtentitel innerhalb dieser Kategorie:

AUP, CRAM, UUP.

Alle Definitionen für diese Nachrichten sind im Verweisdokument 7 enthalten.

E.4.3. Aufbau der Primärfelder

Alle Definitionen für diese Nachrichten sind im Verweisdokument 7 enthalten.

Beispiel:

Conditional Route Availability Message

-TITLE CRAM -PART -NUM 001 -LASTNUM 010

-FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600

-BEGIN LACDR

-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600

-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP

-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730

-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600

-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP

-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530

-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL

-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330

-END LACDR

E.5. Koordinierungsmeldungen ziviler/militärischer Flugverkehr

E.5.1. Einleitung

Meldungen zur Verwendung bei der Koordinierung von Flugdaten und Anfragen zur Luftraumdurchquerung zwischen zivilen und militärischen ATS-Stellen.

E.5.2. Definition der Nachrichtentitel

Nachrichtentitel innerhalb dieser Kategorie:

ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.

Alle Definitionen für diese Nachrichten sind im Verweisdokument 7 enthalten.

E.5.3. Aufbau der Primärfelder

Alle Definitionen für diese Nachrichten sind im Verweisdokument 7 enthalten.

Beispiel:

Crossing Clearance Request Message

-TITLE XRQ -REFDATA -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012 -ARCID DEUCE22 -SSRCODE A1240 -ARCTYP F111 -SECTOR SOUTH

-BEGIN RTEPTS

-PT -PTID GEO01 -TO 1630 -FL F250

-PT -PTID GEO02 -TO 1631 -FL250

-END RTEPTS

-GEO -GEOID GEO01 -LATTD 500000N -LONGTD 0051000E

-GEO -GEOID GEO02 -LATTD 500000N -LONGTD 0051500E

Acceptance Message

-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ

-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012

ANHANG F (Informativ)

BEISPIELE FÜR DAS ADEXP-NACHRICHTENFORMAT

Die folgenden Beispiele dienen als Demonstration des ADEXP-Formats, nicht als Beispiele für den Nachrichteninhalt. Es handelt sich um eine IFPL-Meldung, und obgleich die Meldung zum Zeitpunkt der Veröffentlichung korrekt war, wird für die Genauigkeit des Feldaufbaus usw. keine Garantie übernommen.

BEISPIEL 1 ist in einer gut lesbaren Form dargestellt, was durch die Verwendung von Wagenrücklauf, Zeilenvorschub, Einrückungen usw. erreicht wurde. Ein derartiges Layout ist jedoch nicht Bestandteil der ADEXP-Formatregeln.

Die Darstellung einer Nachricht bleibt daher dem empfangenden System überlassen. BEISPIEL 2 und BEISPIEL 3 sind beides gültige Darstellungen der gleichen Meldung wie in BEISPIEL 1.

BEISPIEL 1

-TITLE IFPL

-BEGIN ADDR

-FAC CFMUTACT

-FAC LFFFSTIP

-FAC EDFFZRZL

-FAC EDZZZQZA

-FAC EDUUZQZA

-FAC LOVVZQZX

-FAC LHBPZEZX

-FAC LYBAZQZX

-FAC LWSSZQZX

-FAC LGTSZAZX

-END ADDR

-ADEP EDDF

-ADES LGTS

-ARCID DLH3728

-ARCTYP B73A

-CEQPT SDMRY

-EOBD 980517

-EOBT 0715

-FILTIM 170421

-IFPLID AA05966101

-ORGNID DLHAOCC

-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH

-REG DABHM

-SEL KMGJ

-SRC FPL

-FLTTYP S

-WKTRC M

-TTLEET 0210

-RFL F330

-SPEED N0417

-FLTRUL I

-SEQPT C

-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26

SAVIN UG18 BUI UB1 TALAS

-ALTRNT1 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

BEISPIEL 2

-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M -TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO 9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS

BEISPIEL 3

-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS

ANHANG G (Informativ)

KÜNFTIGE ENTWICKLUNGEN

G.1. Einleitung

Dieser Anhang soll eine Vorstellung von der geplanten künftigen Entwicklung von ADEXP und den entsprechenden Gründen vermitteln.

G.2. Ziele

Eines der wichtigsten Ziele bei der Entwicklung von ADEXP war das Erfordernis, ein Format zu erstellen, mit dem ein empfangendes System ein unbekanntes oder nichterkanntes Feld "ignorieren" oder "überspringen" kann, ohne die zu verarbeitende Nachricht unbedingt für ungültig zu erklären. Auf diese Weise lässt sich innerhalb einer Meldung ein neues Feld hinzufügen, ohne dass sämtliche empfangenden Systeme vorher geändert werden müssen und ein sehr sorgfältig koordiniertes "Umsteigen" erfolgt. Die daraus resultierende außerordentliche Flexibilität ist einer der Vorzüge des ADEXP-Formats.

Dieses Ziel wird in der derzeitigen Norm durch die Verwendung vorgegebener, durch eindeutige Schlüsselwörter eingeleitete Primär- und Teilfelder erreicht. Ein lexikalischer Analysator (Parser), der ein Schlüsselwort nicht "erkennt", muss den gesamten Text bis zum nächsten bekannten Primärfeld ignorieren, das sich nicht innerhalb eines Listenfelds befindet. Die Wiederherstellung erfolgt somit auf Ebene der Primärfelder.

Wie die derzeitigen und künftigen Entwicklungen bei der Definition neuer Nachrichten zeigen, bedarf es in bestimmten Bereichen einer höheren Komplexität, so dass eine Verschachtelung von Feldern auf dritter und sogar vierter Ebene erforderlich wird. (Ein aktuelles Beispiel dafür ist die Conditional Route Allocation Message (CRAM)). ADEXP bietet heute die Möglichkeit, eine Nachricht mit jeder beliebigen Verschachtelungsebene zu erstellen. Allerdings besteht keine Möglichkeit einer Wiederherstellung bei einem nichterkannten Teilfeld, das vielleicht auf der dritten oder vierten Verschachtelungsebene auftritt, ohne dass es unter Umständen zu einer Fehlinterpretation von Daten oder einer erzwungenen Ungültigmachung der Nachricht kommt. Die vorgeschlagenen Änderungen am ADEXP-Format sollen dafür sorgen, dass ein lexikalischer Analysator (Parser) jederzeit in der Lage ist festzustellen, wo innerhalb der Struktur einer Nachricht oder eines Feldes er sich befindet, und somit eine Wiederherstellung auf jeder beliebigen Verschachtelungsebene ohne die Gefahr einer Fehlinterpretation der Daten ermöglichen.

G.3. Vorschlag

Zur Erreichung der Zielsetzung, eine Wiederherstellung auf jeder beliebigen Ebene innerhalb einer Nachricht zu ermöglichen, muss der lexikalische Analysator in der Lage sein, neben dem Anfang auch das Ende eines Feldes zu erkennen. Das derzeitige Format lässt nur die Feststellung des Feldanfangs anhand des Zeichens "-" zu.

Für eine künftige Version von ADEXP wird die Einführung runder Klammern vorgeschlagen, die jeweils den Beginn und das Ende eines Feldes anzeigen. Die derzeitige Verwendung des Zeichens "-" zur Einführung des Feldanfangs würde dabei durch das Zeichen "(" ersetzt. Das Feldende, das bisher nicht explizit angezeigt wird, würde künftig durch das Zeichen ")" gekennzeichnet. Anhand der folgenden Beispielen soll das Prinzip erläutert werden.

BEISPIELE

>PLATZ FÜR EINE TABELLE>

ANHANG III

FLUGDATENAUSTAUSCH-SCHNITTSTELLENSTEUERUNGSDOKUMENT (FDE-ICD), AUSGABE 1.0

(Eurocontrol-Fundstelle COM.ET1.ST12-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

Diese Norm wurde von der Flight Plan-Related Data Exchange (FPDE) Task Force der Europäischen Organisation zur Sicherung der Luftfahrt (Eurocontrol) erarbeitet und wird von ihr gepflegt.

2. Dokument des EATCHIP-Arbeitsprogramms

Diese Norm bezieht sich auf das Dokument des EATCHIP-Arbeitsprogramms (EWPD), Fachbereich Fernmeldeverbindungen, Führungsaufgabe 01, Specialist Task 12.

3. Genehmigung der Norm

3.1. Die Annahme dieser Norm erfolgt gemäß den Verfahren, die in den Richtlinien für Eurocontrol-Normungsverfahren, Ref. 000-2-93, aufgeführt sind.

3.2. Diese Norm tritt nach Annahme durch die Ständige Kommission von Eurocontrol in Kraft und löst die Eurocontrol-Norm für den Online-Datenaustausch (OLDI), Ausgabe 1, Teil 3: TECHNICAL REQUIREMENTS (Short Term Interface Control Document) Ref. 001-3-92, ab.

4. Technische Korrigenda und Änderungen

Diese Norm unterliegt der Überarbeitung zwecks Ermittlung erforderlicher Änderungen oder technischer Korrigenda. Das Verfahren für die Pflege dieser Norm ist in Anhang H der Richtlinien für die einheitliche Erarbeitung und Vorlage der Eurocontrol-Normungsdokumente Ref. 000-1-92 festgelegt.

5. Redaktionelle Regeln

5.1. Das Format dieser Norm entspricht den Richtlinien für die einheitliche Erarbeitung und Vorlage der Eurocontrol-Normungsdokumente.

5.2. Zur Kennzeichnung des Status der einzelnen Aussagen wurde folgende Notation verwendet:

- 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". Elemente mit Empfehlungscharakter enthalten das Verb "sollte" und sind kursiv gedruckt, wobei der Status durch die Angabe Empfehlung gekennzeichnet ist.

5.3. Sonstige Informationen, die als wesentlich für das Verständnis eines bestimmten Absatzes betrachtet werden, sind als ANMERKUNG in den Text eingefügt. Eine Anmerkung gilt als informativ, enthält daher keine Spezifikationen und erscheint unmittelbar nach dem Absatz, auf den sie sich bezieht.

5.4. Zur Darstellung der Listen der Profilanforderungen (PRL) in Anhang E sind einige Tabellen ausnahmsweise nicht eingerückt und werden nicht über mehrere Seiten fortgesetzt.

6. Beziehung zu anderen Normendokumenten

6.1. Dieses Eurocontrol-Normendokument tritt an die Stelle des OLDI Short Term Interface Control Document (ST-ICD), Part 3, Edition 1 der Eurocontrol-Norm OLDI [Verweisdokument 13].

6.2. Dieses Eurocontrol-Normendokument ist der erste Teil einer beabsichtigten Reihe von Eurocontrol-Norm-Schnittstellensteuerungsdokumenten (ICD) für den Flugdatenaustausch.

7. Status der Anhänge zu dieser Norm

Die Anhänge zu dieser Norm haben folgenden Status:

- Anhang A - Normativ

- Anhang B - Normativ

- Anhang C - Normativ

- Anhang D - Normativ

- Anhang E - Normativ

- Anhang F - Informativ

- Anhang G - Informativ

- Anhang H - Informativ

8. Sprache

Der Originaltext dieser Norm ist in englischer Sprache verfasst.

1. EINLEITUNG

Diese Eurocontrol-Norm basiert auf dem von der ehemaligen Technischen Untergruppe OLDI entwickelten Kurzfristigen Schnittstellensteuerungsdokument (ST-ICD). Aufgabe der Gruppe war es, neue Schnittstellennormen für den künftigen OLDI-Betrieb zwischen Bezirkskontrollstellen festzulegen.

Frühere OLDI-Verbindungen beruhten auf proprietären Protokollen wie INTERCAUTRA oder dem Datenübertragungs- und -verteilungssystem (DÜV), die über Standleitungen oder begrenzte Netze laufen und den Einsatz spezieller Hardware und Software erforderlich machen.

Für die meisten der geplanten neuen Verbindungen wurde es als angebracht erachtet, zu einer netzbasierten Architektur unter Einhaltung internationaler Telekommunikationsnormen überzugehen. Die Verbindungen lassen sich so kostengünstiger aufbauen, indem die Zahl der Anschlüsse in den einzelnen Zentralen reduziert und die Nutzung von Hard- und Software "von der Stange" ermöglicht wird.

Mit der vorliegenden Eurocontrol-Norm wird das ST-ICD formalisiert und erweitert. Bei der Neuabfassung wurde Wert auf eine strengere Spezifikation gelegt, die eine Verbesserung der Interoperabilität bewirkt und sich zudem als Grundlage für künftige ICD in Anpassung an die sich wandelnden Anforderungen des Flugdatenaustauschs (FDE), einschließlich der Nutzung gemeinsamer Netze und der Einführung neuer Normen für die unteren Schichten, eignet. Diese Eurocontrol-Norm enthält ein Mindestpaket von Funktionalitäten, die von vorhandenen OLDI-Implementierungen mit minimalen Änderungen unterstützt werden können, und zwar unter Verwendung von Standleitungen oder von paketvermittelten Netzen entsprechend der Empfehlung X.25 (1980 oder später) des Comité Consultatif des Téléphones et Télégraphes (CCITT). Für die Beschaffung lassen sich weitere Möglichkeiten spezifizieren. Weiterführende Vereinbarungen auf bilateraler Basis werden durch dieses ICD nicht ausgeschlossen.

Einrichtungen, die zusätzlich zu dem in diesem Dokument beschriebenen Protokoll oder an seiner Stelle andere Anwendungsprotokolle einsetzen möchten, können entweder eine Ergänzung des vorliegenden Protokolls beantragen oder ihr Protokoll unter Verwendung unterschiedlicher virtueller Leitungen abtrennen.

2. GELTUNGSBEREICH

2.1. Im vorliegenden Eurocontrol-Normendokument ist eine Datenübertragungsschnittstelle für den Austausch von Flugdatennachrichten zwischen Bezirkskontrollstellen (ACC) spezifiziert. Sie wird in Form eines OSI-Profils (Kommunikation offener Systeme) des Technischen Berichts (TR) 10000-2 der Internationalen Organisation für Normung/Internationalen Elektrotechnischen Kommission (ISO/IEC) [Verweisdokument 3] dargestellt. Das Profil umfaßt sowohl die unteren Schichten (T-Profil) als auch die oberen Schichten (A-Profil).

2.2. Dieses Eurocontrol-Normendokument gilt für die folgenden Szenarien:

- Unterstützung von OLDI laut Eurocontrol-Norm Nr. 001-92 Ausgabe 1;

- Unterstützung der Übertragung von OLDI-Anwendungsnachrichten von ACC zu den Systemen der Zentralen Verkehrsflussregelungsstelle (CFMU).

2.3. Die Norm gilt für Verbindungen unter Nutzung:

- von gemieteten Standleitungen oder

- von Standleitungen des öffentlichen Telefonwählnetzes (PSTN) oder

- von paketvermittelten Datennetzen oder paketvermittelten Datennetzverbünden, die eine Schnittstelle gemäß CCITT-Empfehlung X.25 (1980 oder später) aufweisen.

ANMERKUNGEN

1. Die Anordnung der Flugplanverarbeitungssysteme (FPPS) ist in Figure 1 dargestellt.

2. Nicht in Figure 1 dargestellt sind potentielle Ersatzverbindungen, wie z. B. PSTN; Hinweise dazu enthält Anhang H.

Figure 1

Schnittstellenanordnung

>PIC FILE= "L_2000254DE.017801.EPS">

2.4. Die einzelnen Sicherheitsaspekte der spezifizierten Datenübertragungsschnittstelle sind nicht Bestandteil des Normungsauftrags für diese Norm. Eine grundlegende Bestimmung ist jedoch in Anhang aufgeführt, und weitere Hinweise finden sich in Anhang H dieser Eurocontrol-Norm.

3. VERWEISE

3.1. Einleitung

Die folgenden Dokumente und Normen 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 und -normen 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.

3.2. Verweise

1. ITU-T Recommendation X.25 (1993) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for terminals operating in the packet mode and connected to public data networks by dedicated circuit.

2. ISO/IEC TR 10000-1:1992, Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework (2nd edition).

3. ISO/IEC TR 10000-2:1994, Information technology - Framework and taxonomy of International Standardized Profiles - Part 2: Principles and Taxonomy for OSI Profiles (3rd edition).

4. ITU-T Recommendation X.21 (1992) (Rev. 1), Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks.

5. CCITT Recommendation X.21bis (1988), Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems.

6. ISO/IEC 7776:1994, Information technology - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2nd edition).

7. ISO/IEC 8208:1993, Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment (3rd edition).

8. ISO/IEC ISP 10609-9:1992, Information technology - International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service - Part 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a packet-switched data network using virtual calls.

9. ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model (2nd edition).

10. ISO/IEC 8348:1993, Information technology - Open Systems Interconnection - Network Service Definition (1st edition).

11. ISO/IEC 8072:1994, Information technology - Open Systems Interconnection - Transport service definition (2nd edition).

12. ISO/IEC 8878:1992, Information Technology - Telecommunications and information exchange between systems - Use of X.25 to provide the OSI connection-mode Network Service (2nd edition).

13. Eurocontrol Standard for On-Line Data Interchange (OLDI), No 001-92, Edition 1, 1992.

14. ISO/IEC 9646-1:1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (2nd edition).

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, dated 10 May 1996.

16. Eurocontrol FDE ICD Part 1 - Reliability, Availability and Security - Technical Report version 1.0, dated 20 April 1997.

17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface between DTE and DCE for terminals operating in the packet mode and accessing a packet switched public data through a public switched telephone network or an integrated services digital network or a circuit switched public data network.

18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering plan for the ISDN era.

19. ITU-T Recommendation X.75 (1993) (Rev. 1), Packet-switched signalling system between public network providing data transmission service.

20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks.

4. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN

4.1. Definitionen

4.1.1. Im Sinne dieses Eurocontrol-Normendokuments gelten die folgenden Definitionen:

4.1.2. Profil: Menge einer oder mehrerer für die Erzielung einer bestimmten Funktion erforderlichen Grundnormen sowie gegebenenfalls die Angabe der gewählten Klassen, Teilmengen, Optionen und Parameter dieser Grundnormen [Verweisdokument 2].

4.1.3. Liste der Profilanforderungen (PRL): Die Profilanforderungen werden in Form von Konformitätsanforderungen ausgedrückt und sind in Form einer tabellarischen Liste angeordnet [Verweisdokument 2].

4.1.4. T-Profil: Transportprofil, das einen verbindungsorientierten Transportdienst bietet [Verweisdokument 3].

4.1.5. A-Profil: Anwendungsprofil, das einen verbindungsorientierten Transportdienst verlangt [Verweisdokument 3].

4.1.6. Erklärung zur Konformität der Protokollimplementierung (PICS): Vom Lieferanten eines OSI-Systems gemachte Aussage, welche Fähigkeiten für ein bestimmtes OSI-Protokoll implementiert wurden [Verweisdokument 14].

4.2. Symbole und Abkürzungen

>PLATZ FÜR EINE TABELLE>

4.3. Notation

4.3.1. Für die Zwecke dieses Eurocontrol-Normendokuments werden binäre Werte oder eine Bitfolge im Hexadezimalsystem mit der Notation 'd'H wiedergegeben, wobei der Buchstabe d für eine Ziffer oder eine Folge von Hexadezimalziffern steht.

4.3.2. Für die Zwecke dieses Eurocontrol-Normendokuments erfolgt die hexadezimale Darstellung einer Bitfolge durch jeweils 4 Bits vom höchstwertigen Bit (MSB) bis zum niedrigstwertigen Bit (LSB).ANMERKUNG

Sofern in den verwiesenen internationalen Normen nicht anderweitig spezifiziert, wird eine Bitfolge vom MSB zum LSB übertragen.

4.3.3. Für die Zwecke dieses Eurocontrol-Normendokuments wird der Status der Unterstützung von Merkmalen einer Grundnorm oder dieser Eurocontrol-Norm in Großbuchstaben angegeben (z. B. M, O, O.< n >, X). Die genaue Bedeutung des jeweiligen Statuszeichens wird in den Anhängen dieser Eurocontrol-Norm vor der entsprechenden Verwendung beschrieben.

4.3.4. Für die Zwecke der Festlegung des Profils FDE ICD Teil 1 in diesem Eurocontrol-Normendokument wird der Status der Unterstützung von Merkmalen einer Grundnorm oder dieser Eurocontrol-Norm in Kleinbuchstaben angegeben (z. B. m, o, o.< n >, x).ANMERKUNG

Ergebnis ist eine weitere Präzisierung der bedingten, optionalen oder wertabhängigen Merkmale der Grundnormen (siehe E.3.1).

5. TECHNISCHER ÜBERBLICK

5.1. Protokoll-Stack

ANMERKUNG

Der Protokoll-Stack für das Profil dieser Eurocontrol-Norm ist in Figure 2 veranschaulicht. Die Abbildung stellt die Protokolle durch Ausrichtung des Stacks mit den entsprechenden OSI-Schichten in den Rahmen des OSI-Basisreferenzmodells [Verweisdokument 9]. Allerdings ist der Protokoll-Stack eine Spezifikation für Systeme, die vor der Einführung des OSI-Modells vorhanden waren, und unterstützt daher nicht die vielen Funktionen, die in den OSI-Protokollen der entsprechenden OSI-Schichten zulässig sind.

Figure 2

Profil-Protokoll-Stack

>PIC FILE= "L_2000254DE.018201.EPS">

5.2. Struktur des Profils

ANMERKUNGEN

1. Wie in Figure 2 dargestellt, kombiniert der Profil-Stack mehrere Protokolle der unteren Schichten, von denen nur das X.25-Paketschichtprotokoll (PLP) [Verweisdokument 1] und seine Begleitprotokolle X.21 [Verweisdokument 4] und X.21bis [Verweisdokument 5] in vorhandenen ISO/IEC- und ITU-T-Normen definiert sind. Die anderen Protokolle der oberen Schichten sind in Anhängen (Anhang A, B und C) dieses Eurocontrol-Normendokuments definiert.

2. Die Konformitätsanforderungen an das Profil können sich gleichermaßen auf diese Spezifikationen ebenso wie auf externe Normen beziehen. Sie sind in Abschnitt 6 aufgeführt. Eine detaillierte Darstellung der Anforderungen erfolgt unter Verwendung des Tabellenformats von PRL (Anhang E) und PICS-Formularen (Formulare für in den Anhängen definierte Protokolle sind in Anhang D aufgeführt). Die Verwendung dieser PRL und PICS-Formulare bei der Entwicklung und/oder Beschaffung wird in Anhang E erläutert.

5.3. Beziehung zu früheren Versionen der Spezifikation

ANMERKUNGEN

1. Dieses Profil basiert auf dem von der ehemaligen Technischen Untergruppe OLDI entwickelten ST-ICD. Die in diesem Eurocontrol-Normendokument definierten Protokolle und Paketformate sind eine kompatible Teilmenge der in ST-ICD enthaltenen. Der Unterschied besteht darin, dass diese Eurocontrol-Norm detailliertere Anforderungen an die Nutzung des X.25-PLP stellt, eine obligatorische Unterstützung der M-Bit-Markierung enthält und die widersprüchliche Spezifikation des AFI-Wertes (Zuteilungsstellen- und Formatkennung) in der NSAP-Adresse (Vermittlungsdienstzugangspunkt) korrigiert.

2. Die wichtigste stilistische Änderung dieses Eurocontrol-Normendokuments betrifft die Struktur der ICD-Spezifikation. Das Nachrichtenübertragungsprotokoll (Anhang A) ist vom begleitenden T-Profil getrennt. Dadurch erleichtert sich die Verwendung anderer T-Profile im Zuge der sich entwickelnden FDE-Anforderungen.

3. Die Teile der ST-ICD-Spezifikation, die sich mit der Steuerung von virtuellen X.25-Verbindungen und der Abgrenzung der Anwendungsnachrichten befassen, befinden sich jetzt im Nachrichtenkopfprotokoll (Anhang B), das eine minimale Transportschicht für FDE darstellt.

6. PROFILANFORDERUNGEN

6.1. Konformitätsanforderungen

6.1.1. (NE) Eine Implementierung, für die Konformität mit dieser Spezifikation beansprucht wird, muss die in den Abschnitten 6.2 und 6.3 aufgeführten Anforderungen erfuellen.

6.1.2. (NE) Ein Konformitätsanspruch muss durch eine in Anhang D und Anhang E beschriebene Erklärung zur Konformität der Protokollimplementierung untermauert werden.

6.2. Anforderungen bezüglich der oberen Schichten

6.2.1. (NE) Eine konforme Implementierung muss die in Anhang A aufgeführten Anforderungen der Grundnorm erfuellen.

6.2.2. (NE) Eine konforme Implementierung muss die in der Liste der Profilanforderungen in Anhang E.7 aufgeführten Vorgaben erfuellen.

6.3. Anforderungen bezüglich der unteren Schichten

6.3.1. Transportschichtanforderungen

6.3.1.1. (NE) Eine konforme Implementierung muss die in aufgeführten Anforderungen der Grundnorm erfuellen.

6.3.1.2. (NE) Eine konforme Implementierung muss die in der Liste der Profilanforderungen in Anhang E.8.1 aufgeführten Vorgaben erfuellen.

6.3.1.3. (NE) Eine konforme Implementierung muss die Anforderung der Unterstützung von TSDU-Größen bis einschließlich 4097 Oktette erfuellen.ANMERKUNG

Das erste Oktett der TSDU entspricht einem Feld des Nachrichtenkopfes (siehe A.4.10 und B.4.4), so dass maximal 4096 Oktette für Benutzerdaten verbleiben.

6.3.2. Vermittlungsschichtanforderungen

6.3.2.1. (NE) Eine konforme Implementierung muss die Anforderungen von ISO/IEC 8208 [Verweisdokument 7] entsprechend der in Anhang C aufgeführten Protokollzuordnung erfuellen.

6.3.2.2. (NE) Eine konforme Implementierung muss die in der Liste der Profilanforderungen in Anhang E.8.2 aufgeführten Vorgaben erfuellen.

6.3.2.3. (NE) Wird ein DEE-DEE-Betrieb unterstützt, muss eine konforme Implementierung in der Lage sein, durch Systemmanagementmechanismen die Wahl der DEE- oder DÜE- Rolle für den DEE-DEE-Betrieb zu konfigurieren.

6.3.2.4. (NE) Eine konforme Implementierung muss in beiden der in 6.3.2.3 definierten Rollen in der Lage sein, eine Verbindung entsprechend der Spezifikation in Anhang C auszulösen, d. h. das Protokoll ist vollkommen symmetrisch.ANMERKUNG

Einige vorhandene Implementierungen auf der Basis des ST-ICD sind unter Umständen nicht in der Lage, Netzverbindungen entsprechend dem Protokoll von Anhang C auszulösen.

6.3.2.5. (NE) Eine konforme Implementierung muss eine Zeitlang das Leistungsmerkmal vereinbarte Ersatzpaketgrößen mit dem Wert 256 für beide Übertragungsrichtungen erfuellen.

6.3.2.6. (NE) Eine konforme Implementierung muss NSAP-Adressen entsprechend der Definition in Anhang C verwenden.

6.3.2.7. (NE) Eine konforme Implementierung muss die D-Bit-Markierung in den Paketen CALL REQUEST, CALL ACCEPTED und DATA auf 0 setzen.ANMERKUNG

Die Einstellung D=0 in den Paketen CALL REQUEST und CALL ACCEPTED bewirkt, dass keine Übergabebestätigung verwendet wird.

6.3.3. Sicherungsschichtanforderungen

6.3.3.1. (NE) Eine konforme Implementierung muss die Konformitätsanforderungen von ISO/IEC 7776 [Verweisdokument 6] für das LAPB-Einzelstreckenprotokoll (Gleichberechtigtes Übermittlungsverfahren) erfuellen.

6.3.3.2. (NE) Eine konforme Implementierung muss zudem die in der Liste der Profilanforderungen in Anhang E.8.3 aufgeführten Vorgaben erfuellen.

6.3.4. Bitübertragungsschichtanforderungen

(NE) Eine konforme Implementierung muss die Konformitätsanforderungen von ISO/IEC ISP 10609-9 clause 7 [Verweisdokument 8] erfuellen.

7. PRÜFMETHODEN

ANMERKUNGEN

1. Ein Ansatz für die Konformitätsprüfung von Implementierungen dieser Spezifikation ist in Anhang F kurz dargestellt.

2. Eine Kurzdarstellung zur Verwendung der mit dieser Spezifikation bereitgestellten PRL und PICS-Formulare zur Dokumentierung der Konformität findet sich in Anhang E.

ANHANG A (Normativ)

NACHRICHTENÜBERTRAGUNGSPROTOKOLL

A.1. Einleitung

Diese Spezifikation definiert ein Protokoll für die Implementierung eines einfachen Nachrichtenübertragungsdienstes für Anwendungen, die einen Flugdatenaustausch erfordern.

A.2. Implementierter Dienst

Das Nachrichtenübertragungsprotokoll (MT) implementiert die folgenden unbestätigten Dienste:

MT-Associate: Aufbau einer Übertragungsassoziation für eine Anwendungsnachricht;

MT-Data: Übertragung einer aus ASCII-Zeichen bestehenden Nachricht;

MT-Abort: Abbruch einer Übertragungszuordnung für eine Anwendungsnachricht.

A.3. Übernommener Dienst

Dieses Nachrichtenübertragungsprotokoll übernimmt eine Teilmenge des verbindungsorientierten Transportdienstes nach ISO/IEC 8072 [Verweisdokument 11], wie sie z. B vom in dieser Eurocontrol-Norm definierten Protokoll angeboten wird.

A.4. Protokoll-Spezifikation

A.4.1. Einleitung

Im nachfolgenden Text wird nur der Betrieb von einer anwendungsinitiierten Nachrichtenübertragungsassoziation beschrieben. Durch Wiederholung dieser Prozeduren für jede einzelne zugrundeliegende Transportverbindung können weitere Assoziationen auf derselben Netzschnittstelle unterstützt werden.

A.4.2. Datenarten

In diesem Anhang werden vier Typen von Anwendungsnachrichten herausgestellt, die den in der Eurocontrol-Norm Nr. 001-3-92 Ausgabe 1 definierten Arten äquivalent sind:

Systemnachrichten: (NE) Diese Nachrichten werden zur Übermittlungsüberwachung (HEARTBEAT-Nachricht) und Anwendungssteuerung (STARTUP- und SHUTDOWN-Nachricht) verwendet.

Operationelle Nachrichten: (NE) Diese Nachrichten sind an einen spezifischen operationellen Kontext gebunden und werden in den Eurocontrol-Normen und -Dokumenten definiert, die diese Norm für den Datenaustausch verwenden. Das Eurocontrol-Normendokument für den Online-Datenaustausch definiert operationelle Nachrichten wie die Aktivierungsmeldung (ACT), die Vorabinformationen über die Grenzpassage (ABI) und die Logische Bestätigung (LAM).

Betreibernachrichten: (NE) Diese Nachrichten enthalten frei wählbaren Text. Ihre Verwendung ist bilateral zu vereinbaren. Sie können beispielsweise zum Austausch von Prüfungsinformationen oder zur Inkenntnissetzung der anderen Seite über Maßnahmen des Betreibers genutzt werden.

Statusnachrichten: (NE) Verwendung und Inhalt dieser Nachrichten sind bilateral zu vereinbaren. Sie können beispielsweise zum Austausch von Systemverwaltungsinformationen genutzt werden

ANMERKUNGEN

1. Die Verwendung von Systemnachrichten ist Bestandteil des Betriebs dieses Protokolls, und ihr Format ist im Abschnitt A.4.10.3 dieses Anhangs definiert.

2. Verwendung und Format von Statusnachrichten unterliegen bilateralen Vereinbarungen und werden in dieser Eurocontrol-Norm nicht weiter spezifiziert.

3. Vom Zustand des Protokolls hängt es ab, welche Nachrichtentypen übertragen werden können, wie in den nachfolgenden Absätzen beschrieben.

A.4.3. Assoziationsaufbau

A.4.3.1. Das Protokoll befindet sich zu Beginn im Ruhezustand (IDLE).

A.4.3.2. Das Dienstelement MT-Associate-Request wird ausgeführt, um eine Anwendungsassoziation aufzubauen und das Protokoll in den Zustand DATA_READY zu versetzen. Das Dienstelement muss sowohl von der lokalen als auch von der entfernten Anwendung aufgerufen werden.

A.4.3.3. Zunächst muss entsprechend der in Annex B Absatz B.4.1 beschriebenen T-Verbindungs-Dienstelemente eine zugrundeliegende Transportverbindung aufgebaut werden, woraufhin das Protokoll in den Bereitschaftszustand (READY) eintritt. Auf dieser Stufe lassen sich nur Systemnachrichten (und nach bilateraler Vereinbarung möglicherweise auch Betreibernachrichten) übertragen. Zur Übertragung einer System- oder Betreibernachricht verwendet der Absender das T-Daten-Dienstelement (siehe ) mit der Nachricht als Parameter.

A.4.3.4. (NE) Anschließend wird eine STARTUP-Nachricht (System-Nachricht) gesendet, der Zeitgeber Tr (siehe A.4.7) wird gestartet, und das Protokoll tritt in den Zustand ASSOCIATION_PENDING. Läuft der Zeitgeber Tr ab, während sich das Protokoll in diesem Zustand befindet, wird die STARTUP-Nachricht erneut gesendet und der Zeitgeber erneut gestartet.ANMERKUNG

Das Protokoll bleibt so lange im Zustand ASSOCIATION_PENDING, bis eine STARTUP-Nachricht empfangen wird. Ständige Zeitüberschreitungen des Zeitgebers Tr könnten lokal gemeldet werden.

A.4.3.5. (NE) Bei Empfang der STARTUP-Nachricht werden folgende Aktionen ausgelöst:

- im Zustand ASSOCIATION_PENDING wird eine weitere STARTUP-Nachricht gesendet, das Protokoll tritt in den Zustand DATA_READY, und das Dienstelement MT-Associate-Indication wird signalisiert;

- in jedem anderen Zustand wird die Nachricht ignoriert.

A.4.3.6. Der Empfang der STARTUP-Nachricht im Zustand ASSOCIATION_PENDING bedeutet entweder,

- die entfernte Anwendung hat ein Dienstelement MT-Associate-Request ausgegeben und ihr Nachrichtenübermittlungsprotokoll ist in den Zustand ASSOCIATION_PENDING getreten oder

- das entfernte Nachrichtenübermittlungsprotokoll antwortet auf eine zuvor erhaltene STARTUP-Nachricht und ist in den Zustand DATA_READY getreten.

ANMERKUNG

Diese Ungewissheit rührt daher, dass für STARTUP und für die Antwort auf STARTUP die gleiche Nachricht verwendet wird. Infolgedessen empfängt das Nachrichtenübermittlungsprotokoll, das zuerst in den Zustand DATA_READY eintritt, eine weitere STARTUP-Nachricht. Wie in A.4.3.5 ausgeführt, wird diese STARTUP-Nachricht ignoriert.

A.4.3.7. Nach dem Austausch von STARTUP-Nachrichten erfolgt der Aufbau der Assoziation, und alle angegebenen Nachrichtentypen können übertragen werden (Zustand DATA_READY).

A.4.4. Datenübertragung

Andere Nachrichtentypen werden unter Verwendung des T-Daten-Dienstes mit der Nachricht als Parameter auf die gleiche Weise übertragen wie Systemnachrichten. Dies entspricht den Dienstelementen MT-Data-Request und MT-Data-Indication. ANMERKUNG

Jede Nachricht wird als einzelne TSDU gesendet. Auf dieser Ebene erfolgt keine Verkettung oder Segmentierung der Nachrichten.

A.4.5. Regulärer Assoziationsabbau

A.4.5.1. Die Nachrichtenübertragungsassoziation zwischen zwei Anwendungen kann durch beide Seiten ausgelöst werden. Dies entspricht dem Dienstelement MT-Abort-Request.

A.4.5.2. (NE) Folgende Aktionen sind durchzuführen:

- im Zustand DATA_READY wird eine SHUTDOWN-Nachricht (Systemnachricht) gesendet, die Zeitgeber Tr und Ts werden gestoppt, und die Transportverbindung wird abgebaut;

- im Zustand ASSOCIATION_PENDING wird eine SHUTDOWN-Nachricht (Systemnachricht) gesendet, der Zeitgeber Tr wird gestoppt, und die Transportverbindung wird abgebaut;

- im Zustand READY wird die Transportverbindung abgebaut;

- ansonsten erfolgt keine Aktion.

ANMERKUNG

Die SHUTDOWN-Nachricht ist keine Vorwarnung - die Assoziation wird sofort abgebrochen. Für diese Nachricht gibt es keine Bestätigung von der Gegenstelle.

A.4.5.3. (NE) Bei Empfang einer SHUTDOWN-Nachricht müssen folgende Aktionen ausgelöst werden:

- im Zustand DATA_READY wird der Zeitgeber Ts (siehe A.4.7) gestoppt, MT-Abort-Indication wird gemeldet, und die Schnittstelle tritt ohne Senden einer STARTUP-Nachricht in den Zustand ASSOCIATION_PENDING;

- in jedem anderen Zustand erfolgt keine Aktion.

A.4.6. Wiederaufbau der Assoziation

Die Anwendung, die den Abbau der Assoziation ausgelöst hat, ist dafür verantwortlich, bei Bereitschaft die Anwendungsassoziation wiederaufzubauen, (gegebenenfalls) auf einer niedrigeren Ebene.ANMERKUNG

Hat die Aufhebung der Assoziation zum Abbau der zugrundeliegenden Netzverbindung geführt, ist die in Absatz A.4.3 spezifizierte Prozedur zu befolgen.

A.4.7. Integrität der Assoziation

A.4.7.1. Die Integrität der Assoziation zwischen zwei Anwendungen wird durch das Leistungsmerkmal Idle Heartbeat gewährleistet.

A.4.7.2. (NE) Beim Eintritt in den Zustand DATA_READY und beim Senden eines beliebigen Nachrichtentyps über die Transportverbindung wird ein konfigurierbarer Zeitgeber Ts (neu)gestartet. Läuft der Zeitgeber Ts im Zustand DATA_READY ab, wird eine HEARTBEAT-Nachricht (Systemnachricht) gesendet (und der Zeitgeber wird neugestartet).

A.4.7.3. (NE) Ebenso wird beim Eintritt in den Zustand DATA_READY und beim Empfang einer beliebigen Nachricht mit Ausnahme einer STARTUP-Nachricht über die Verbindung ein konfigurierbarer Zeitgeber Tr (neu)gestartet. Läuft der Zeitgeber Tr im Zustand DATA_READY ab, wird MT-Abort-Indication signalisiert, die Übertragung sämtlicher Nachrichten wird gestoppt, der Zeitgeber Ts wird angehalten und der Zeitgeber Tr wird neugestartet. Die Schnittstelle befindet sich im Zustand ASSOCIATION_PENDING.ANMERKUNG

Die Wiederherstellung und Resynchronisierung der Anwendungen erfolgt durch den Austausch von STARTUP-Nachrichten (siehe A.4.3).

A.4.8. Irregulärer Assoziationsabbau

A.4.8.1. Ein fehlerbedingter Abbau der Assoziation kann erfolgen

- bei Ausfall der Transportverbindung (z. B. Leitungsausfall, Protokollfehler),

- bei Ausfall einer der beiden Anwendungen oder Systeme (möglicherweise aufgrund einer Hardware- oder Softwarestörung; in einigen Fällen kann die zugrundeliegende Netzverbindung weiterhin bestehen).

ANMERKUNG

Entsprechend der Definition des Transportprotokolls in Anhang B gibt es keine durchgehende Transportverbindung. Daher ist der Ausfall der Transportverbindung eine unmittelbare Folge des Netzverbindungsausfalls.

A.4.8.2. Ein Anwendungs- oder Systemausfall kann durch Zeitüberschreitung (Time-Out) beim Empfang einer erwarteten HEARTBEAT-Nachricht (siehe A.4.7) von dieser Anwendung festgestellt werden.

A.4.9. Wiederherstellung nach Ausfall

A.4.9.1. Es sind zwei Fälle zu betrachten:

- nach Ausfall der Transportverbindung;

- nach Ausfall einer Anwendung.

A.4.9.2. In beiden Fällen umfaßt die Wiederherstellung die normale Prozedur für den Assoziationsaufbau (siehe A.4.3), einschließlich des Austauschs von STARTUP-Nachrichten.ANMERKUNG

Bei einer Störung auf Anwendungsebene, die nicht zum Abbau der zugrundeliegenden Netzverbindung führt, kann das gestörte System eine SHUTDOWN-Nachricht senden (d. h. L_shutdown entweder manuell oder als Teil der Anwendungslogik ausgelöst), bevor ein Versuch zur Wiederherstellung der Strecke unternommen wird. Damit wird der Zeitsperrprozess (Time-Out) des Tr der entfernten Anwendung abgekürzt und unter Umständen eine schnellere Wiederherstellung erreicht, ohne dass zu viele Daten verlorengehen.

A.4.10. Nachrichtenformate

A.4.10.1. Allgemeine Struktur von Nachrichten

>PLATZ FÜR EINE TABELLE>

A.4.10.2. Länge des Hauptteils

(NE) Es müssen Hauptteile mit einer Länge bis einschließlich 4096 Oktetten unterstützt werden.

A.4.10.3. Systemnachrichtenformate

>PLATZ FÜR EINE TABELLE>

A.4.10.4. Andere Nachrichtenformate

>PLATZ FÜR EINE TABELLE>

ANMERKUNGEN

1. Das Format des Hauptteils von Statusnachrichten liegt außerhalb des Geltungsbereichs dieses Eurocontrol-Normendokuments.

2. Das Format von operationellen Nachrichten ist in Eurocontrol-Normen und -Dokumenten spezifiziert, in denen Nachrichtenübermittlungsanwendungen definiert sind, z. B. Online-Datenaustausch [Verweisdokument 13].

3. Betreibernachrichten bestehen aus druckbarem ASCII-Text. Werden diese Nachrichten unterstützt, muss eine Benutzeroberfläche bereitgestellt werden, um empfangene Nachrichten anzuzeigen und um die Erstellung von Nachrichten zur Übertragung zu ermöglichen.

A.5. Protokollzustandstabellen

A.5.1. Einleitung

(NE) Die nachfolgend aufgeführten Zustandstabellen stellen die endgültige Spezifikation des Protokolls dar. Bei eventuellen Abweichungen zum vorstehenden Haupttext ist die nachfolgende Spezifikation maßgebend.ANMERKUNG

Die zur Beschreibung der Zustände, Ereignisse, Zeitgeber und Aktionen verwendete Notation basiert auf dem ST-ICD. Die folgenden Definitionen und daraus resultierenden Aktionen sind jedoch überarbeitet worden und können daher vom ST-ICD abweichen.

A.5.2. Zustandsdefinitionen

Tabelle 1

Zustandsdefinitionen

>PLATZ FÜR EINE TABELLE>

A.5.3. Mögliche Ereignisse

Tabelle 2

Mögliche Ereignisse

>PLATZ FÜR EINE TABELLE>

A.5.4. Zeitgeber

Tabelle 3

Zeitgeber

>PLATZ FÜR EINE TABELLE>

Die Werte dieser Zeitgeber sollen so ausgelegt sein, dass sich Tr = 2Ts + Laufzeit ergibt.ANMERKUNG

Typische Werte dieser Zeitgeber sind: Ts = 30s, Tr = 70s.

A.5.5. Zustandsübergangstabelle

Tabelle 4

Zustandsübergänge

>PLATZ FÜR EINE TABELLE>

A.5.6. Zustandsdiagramm

ANMERKUNG

In Abbildung A.1 wird das Protokoll in Form eines Zustandsdiagramms beschrieben. Das Diagramm dient lediglich der Information. Bei Widersprüchen zwischen dem Diagramm und den oben aufgeführten Zustandstabellen sind letztere maßgeblich.

Abbildung A.1

Nachrichtenübertragungsprotokoll: Zustandsdiagramm

>PIC FILE= "L_2000254DE.019301.EPS">

ANHANG B (Normativ)

NACHRICHTENKOPFPROTOKOLL

B.1. Einleitung

Dieser Anhang definiert das Nachrichtenkopfprotokoll, bei dem es sich um ein Mindesttransportprotokoll für Anwendungen, wie z. B. OLDI, handelt.

B.2. Implementierter Dienst

B.2.1. Das Nachrichtenkopfprotokoll entspricht einer Teilmenge des verbindungsorientierten Transportdienstes nach ISO/IEC 8072 [Verweisdokument 11] und umfasst die folgenden Dienstelemente.

T-Verbindungsaufbau: Herstellung einer Transportverbindung für eine Anwendung

T-Daten: Übertragung von ASCII-Daten

T-Verbindungsabbau: Beendigung der Transportverbindung einer Anwendung

B.2.2. Multiplexbetrieb, Fehlerbehebung sowie Segmentierung und Wiedervereinigung werden von diesem Dienst nicht unterstützt.

B.3. Übernommener Dienst

Das Protokoll übernimmt einen verlässlichen Basisvermittlungsdienst, wie er vom X.25-Paketschichtprotokoll bereitgestellt wird.ANMERKUNG

Auf jeder Netzverbindung wird nur eine einzige Transportverbindung unterstützt.

B.4. Protokollspezifikation

B.4.1. Verbindungsaufbau

(NE) Die Implementierung des Dienstelements T-Verbindungsaufbau muss unter Verwendung des N-Verbindungsaufbau-Dienstes des zugrundeliegenden Vermittlungsdienstes erfolgen. Es besteht eine direkte Zuordnung zwischen den beiden Mengen von Dienstelementen (Anforderung, Anzeige). Alternativ dazu kann eine bestehende Netzverbindung verwendet werden (die z. B. durch Systemmanagementmechanismen aufgebaut wurde).Empfehlungen

1. Im letztgenannten Fall sollte die Netzverbindung vor der Verwendung rückgesetzt werden. Das Dienstmerkmal N-Verbindungsaufbau kann automatisch wiederholt werden, wenn innerhalb einer bestimmten Zeit keine Antwort eingegangen ist.

2. Ist diese automatische Wiederholung implementiert, sollte sie ca. alle 15 s erfolgen.

B.4.2. Vermeidung redundanter Netzverbindungen

(NE) Bleibt das Dienstmerkmal N-Verbindungsaufbau-Anforderung aus (d. h. es wurde kein entsprechendes Dienstmerkmal N-Verbindungsaufbau-Bestätigung oder N-Verbindungsabbau signalisiert) und es wird eine N-Verbindungsaufbau-Anzeige gemeldet, so ist der ankommende Netzaufbauversuch durch das Dienstmerkmal N-Verbindungsabbau-Anforderung nur dann zurückzuweisen oder abzubauen, wenn die beiden folgenden Bedingungen vorliegen:

- die rufende NSAP-Adresse der N-Verbindungsaufbau-Anzeige ist die gleiche wie die gerufene NSAP-Adresse der ausstehenden N-Verbindungsaufbau-Anforderung;

- die rufende NSAP-Adresse der ausstehenden N-Verbindungsaufbau-Anforderung ist größer als die gerufene NSAP-Adresse der ausstehenden N-Verbindungsaufbau-Anforderung, wobei der Vergleich anhand der durch die bevorzugte Bitcodierung der einzelnen NSAP-Adressen nach ISO/IEC 8348 Anhang A [Verweisdokument 10] vorgenommen wird (eine Folge gilt als größer als jeder ihrer eigenen Ausgangsteilstrings, z. B. '8800'H > '88'H).

B.4.3. Verbindungsabbau

B.4.3.1. (NE) Für den Verbindungsabbau werden die Dienstelemente N-Verbindungsabbau und N-Rücksetz des zugrundeliegenden Vermittlungsdienstes verwendet.

B.4.3.2. (NE) Zur Implementierung einer T-Verbindungsabbau-Anforderung wird eine N-Verbindungsabbau-Anforderung signalisiert. Sollte andererseits der Aufbau von Netzverbindungen mit Hilfe von N-Verbindungsaufbau-Dienstelementen nicht unterstützt werden, so darf die Netzverbindung nicht explizit abgebaut werden.Empfehlung

Im letztgenannten Fall sollte die Netzverbindung rückgesetzt werden.

B.4.3.3. (NE) Bei Empfang einer der beiden folgenden Vermittlungsdienstelemente über eine Netzverbindung, die einer ganz oder teilweise aufgebauten Transportverbindung entspricht, muss eine T-Verbindungsabbau-Anzeige signalisiert werden:

- N-Verbindungsabbau-Anzeige;

- N-Rücksetz-Anzeige.

B.4.4. Datenübertragung

B.4.4.1. (NE) Das Dienstelement T-Daten wird durch Verwendung des Dienstelements N-Daten des zugrundeliegenden Vermittlungsdienstes implementiert. Zwischen den beiden Mengen von Dienstelementen (Anforderung, Anzeige) besteht eine direkte Zuordnung. Die Zuordnung verwendet eine Transportprotokolldateneinheit (TPDU), die durch den Vermittlungsdienst übertragen wird.

B.4.4.2.

>PLATZ FÜR EINE TABELLE>

ANMERKUNGEN

1. Dieser Kopf ist bei der Ausführung von in definierten Nachrichtenformaten als identisch mit dem im INTERCAUTRA-Verfahren verwendeten Nachrichtenkopf definiert - dem Verfahren für den ACT-Nachrichtenaustausch zwischen CAUTRA Paris, dem 9020D-System des London Air Traffic Control Centre und dem Digital Communications Terminal System (DCTS) Maastricht/Karlsruhe; in diesem Fall entspricht das Feld "Daten(1)" dem TYP-Feld.

2. Die Verwendung der Felder ADEST, DEST, AEMM, EMM, und ADR mit anderen Werten als '40'H liegt außerhalb des Geltungsbereiches dieses Eurocontrol-Normendokuments, kann jedoch bilateral vereinbart werden.

B.4.4.3. (NE) Der T-Daten-Dienst muss auf die Übertragung von druckbaren ASCII-Zeichendaten beschränkt sein. Insbesondere darf keines der Datenoktette den Wert '03'H (das Zeichen ETX) aufweisen.

B.4.4.4. (NE) Eine konforme Implementierung muss NSDU-Größen bis einschließlich 4105 Oktette unterstützen.

B.4.4.5. (NE) Eine konforme Implementierung darf keine Verkettung mehrerer TSDU zu einer NSDU zulassen.

B.4.4.6. (NE) Eine konforme Implementierung darf keine Segmentierung einer TSDU in mehrere NSDU zulassen.

ANHANG C (Normativ)

VERMITTLUNGSPROTOKOLL

C.1. Einleitung

Dieser Anhang spezifiziert ein grundlegendes Vermittlungsprotokoll unter Nutzung des X.25-Paketschichtprotokolls zur Verwendung bei Standleitungen und in paketvermittelten Netzen zwecks Unterstützung der Übertragung von Flugdaten. Die Protokollteilmenge ist kompatibel mit der in den Versionen von [Verweisdokument 1] ab Ausgabe 1980 definierten Teilmengen.

C.2. Bereitgestellter Dienst

C.2.1. Das Protokoll implementiert den verbindungsorientierten OSI-Vermittlungsdienst laut Definition in ISO/IEC 8348 [Verweisdokument 10] mit folgenden Ausnahmen.

- NSAP-Adressen sind auf die in definierte Form beschränkt;

- es gibt kein Leistungsmerkmal für die Herbeiführung einer Vereinbarung zwischen den Benutzern des Vermittlungsdienstes (NS) und dem NS-Provider über die mit einer Netzverbindung zusammenhängende Dienstqualität;

- die Übertragung von NS-Nutzdaten während des Aufbaus und des Abbaus der Netzverbindung wird mit Ausnahme der in C.5.3 beschriebenen Bestimmungen nicht unterstützt.

C.2.2. Die folgenden NS-Provider-Optionen werden nicht angeboten:

- Empfangsbestätigung;

- Vorrangdatenübertragung.

C.3. Übernommener Dienst

Das Protokoll übernimmt die Bereitstellung eines OSI-Sicherungsdienstes, wie er durch ISO/IEC 7776 (LAPB) [Verweisdokument 6] angeboten wird.

C.4. NSAP-Adressierung

C.4.1. Einleitung

C.4.1.1. Die Struktur der NSAP-Adressen folgt der Definition in ISO/IEC 8348 Anhang A [Verweisdokument 10], wie nachfolgend veranschaulicht wird.

>PIC FILE= "L_2000254DE.019702.EPS">

C.4.1.2. Die Bestandteile der NSAP-Adresse werden nachfolgend definiert:

IDP: Zuteilungsstellen- und Bereichskennung, Felder AFI und IDI

AFI: Zuteilungsstellen- und Formatkennung und

IDI: Kennung des Adressierungsbereichs

DSP: Bereichsspezifischer Adressteil

C.4.2. NSAP-Adressenstruktur

C.4.2.1. (NE) Für die Zwecke dieses Eurocontrol-Normendokuments sind die Adressbestandteile auf die folgende Form beschränkt.

C.4.2.2. (NE) Es ist der AFI-Wert 48 zu verwenden, der eine lokale Format-IDI mit dezimaler abstrakter Syntax angibt.

C.4.2.3. Die IDI ist dem lokalen Format folgend null.

C.4.2.4. (NE) Der DSP besteht aus 2 Dezimalzifferpaaren wie folgt:

- das erste Paar ist eine ATC-Stellenkennung, die ein ATC-System und damit indirekt einen Ort identifiziert;

- das zweite Paar ist ein ATC-Stellen-Wähler, der zur Identifizierung eines bestimmten Endpunktes innerhalb einer ATC-Stelle verwendet werden kann.

C.4.2.5.

>PLATZ FÜR EINE TABELLE>

C.4.3. Zuweisung von ATC-Stellenkennungen und -wählern

C.4.3.1. Die Zuweisung von eindeutigen ATC-Stellenkennungen für die einzelnen ATC-Systeme obliegt Eurocontrol, während die ATC-Stellen-Wähler von der entsprechenden Instanz innerhalb der ATC-Verwaltung oder -Organisation zugewiesen werden.

C.4.3.2. Die Zuordnung von ATC-Stellenkennungen zum Zeitpunkt der Erarbeitung dieser Norm ist in Anhang G aufgeführt.

C.5. Protokollspezifikation

C.5.1. Überblick

Dieses Protokoll basiert auf dem teilnetzspezifischen Anpassungsprotokoll für X.25(1980), definiert in Annex A von ISO/IEC 8878 [Verweisdokument 12], mit folgenden Unterschieden:

- das Leistungsmerkmal Ruf mit erweitertem Nutzdatenfeld wird nicht verwendet; jedoch wird hier die in Annex A von ISO/IEC 8878 [Verweisdokument 12] definierte Codierung, die für den Gebrauch mit dem erweiterten Nutzdatenfeld gilt, wie es im Rahmen des Leistungsmerkmals Ruf mit erweitertem Nutzdatenfeld verfügbar ist, mit dem Nutzdatenfeld im Basisformat in CALL REQUEST- und INCOMING CALL-Paketen verwendet, da die Einschränkungen bei den zulässigen Verbindungsdienstparametern dafür sorgen, dass die codierte Information in 16 Oktette passt;

- von den Verbindungsdienstparametern, für die in ISO/IEC 8878 [Verweisdokument 12] Codierungen definiert sind, werden nur die gerufene und die rufende NSAP-Adresse (und nur in der in definierten Form) im CALL REQUEST-Paket gesendet;

- das Nutzdatenfeld wird in den Paketen CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST oder CLEAR INDICATION nicht verwendet;

- die Alternativverfahren für den Netzverbindungsaufbau und -abbau werden nicht verwendet;

- Empfangsbestätigung mit D-Bit-Markierung wird nicht unterstützt.

ANMERKUNG

Mit den ersten drei dieser Einschränkungen wird sichergestellt, dass sämtliche zwischen zwei DEE übermittelte Informationen die Beschränkungen des X.25-PLP (1980) einhalten.

C.5.2. Adresscodierung

(NE) Die rufende und die gerufene Adresse wird mit der in ISO/IEC 8348 Annex A [Verweisdokument 10] definierten bevorzugten Binärcodierung codiert.

C.5.3. Codierung des Nutzdatenfeldes

C.5.3.1. (NE) Ausgehend von den obengenannten Anforderungen wird das Nutzdatenfeld in den Paketen CALL REQUEST und INCOMING CALL wie nachfolgend dargestellt codiert. Alle 16 Oktette werden übertragen.

Tabelle 1

Nutzdatenfeldcodierung

>PLATZ FÜR EINE TABELLE>

C.5.3.2. (NE) Andere in ISO/IEC 8878 [Verweisdokument 12] beschriebene Parameter sind nicht zu verwenden.

C.5.4. Behandlung von Adressen in INCOMING CALL-Paketen

C.5.4.1. DEE-Adressen

(NE) Die rufende DEE-Adresse in einem INCOMING CALL-Paket ist anhand einer lokalen Liste gültiger entfernter DEE-Adressen für das System zu validieren. Wird eine ungültige Adresse festgestellt, ist die Verbindung aufzuheben.

ANMERKUNGEN

1. Die gegebenenfalls vorhandene gerufene DEE-Adresse in einem gegebenenfalls vorhandenen INCOMING CALL-Paket kann optional auch anhand einer (typischerweise aus einem Element bestehenden) Liste gültiger lokaler DEE-Adressen für das System validiert werden.

2. In einigen Fällen kann die DEE-Adresse einer Stelle wert- und/oder längenmäßig unterschiedlich sein, wenn die Stelle als rufendes oder gerufenes System agiert. Daher ist dieser Frage bei der Spezifizierung oder Implementierung der Funktionalität DEE-Adressenvalidierung besondere Aufmerksamkeit zu schenken.

C.5.4.2. NSAP-Adressen

(NE) Die wie oben beschrieben in einem INCOMING CALL-Paket codierte rufende NSAP-Adresse ist anhand einer lokalen Liste gültiger entfernter NSAP-Adressen für das System zu validieren. Wird eine ungültige Adresse festgestellt, ist die Verbindung aufzuheben.

ANMERKUNG

Die NSAP-Adresse kann optional auch anhand einer (typischerweise aus einem Element bestehenden) Liste gültiger lokaler NSAP-Adressen für das System validiert werden.

C.5.5. Datenübertragung

C.5.5.1. Wie in ISO/IEC 8878 Annex A.5.3 [Verweisdokument 12] beschrieben, werden NSDU im Nutzdatenfeld eines Daten-Pakets übertragen.

ANMERKUNG

Infolgedessen ist die Übertragung von mehr als einer Benutzernachricht, wie z. B. einer OLDI-Nachricht, pro X.25-Paket oder M-Bitfolge unzulässig.

C.5.5.2. (NE) NSDU, die länger sind als die für die virtuelle Verbindung zulässigen Hoechstnutzdaten sind zu segmentieren und in den Nutzdatenfeldern einer Folge von DATA-Paketen zu übertragen, wobei bis auf das letzte alle sowohl die Maximallänge als auch die M-Bitmenge (d. h. eine More-Bit-Folge) aufweisen müssen.

C.5.5.3. Bei Empfang sind die Nutzdatenfelder einer More-Bit-Folge wieder zur empfangenen NSDU zusammenzusetzen.

ANHANG D (Normativ)

PROFILSPEZIFISCHE PICS-FORMULARE

D.1. Einleitung

D.1.1. (NE) Vom Lieferanten einer Protokollimplementierung, für die Konformität mit den Spezifikationen in Anhang A-C beansprucht wird, sind die folgenden PICS-Formulare auszufuellen.ANMERKUNG

Nachdruck von PICS-Formularen: Benutzer dieses Eurostat-Normendokuments dürfen die in diesem Anhang enthaltenen PICS-Formulare zur zweckentsprechenden Verwendung kostenlos nachdrucken und die ausgefuellten PICS veröffentlichen.

D.1.2. Ein ausgefuelltes PICS-Formular stellt die PICS für die betreffende Implementierung dar. Die PICS ist eine Erklärung darüber, welche Eigenschaften und Optionen des Protokolls umgesetzt worden sind.

D.1.3. Die PICS lässt sich verschiedentlich verwenden, und zwar

- durch den Protokollimplementierer als Checkliste zur Verringerung des Risikos, aufgrund übersehener Mängel eine Nichtkonformität mit der Norm zu bewirken;

- durch den Lieferanten und Erwerber bzw. potentiellen Erwerber der Implementierung als detaillierte Angabe der Eigenschaften der Implementierung in Bezug auf die gemeinsame Verständigungsbasis, wie sie das Standard-PICS-Formular darstellt;

- durch den Benutzer bzw. potentiellen Benutzer der Implementierung als Grundlage für die erste Prüfung der Möglichkeit der Kommunikationsfähigkeit mit einer anderen Implementierung (es sei darauf hingewiesen, dass sich die Kommunikationsfähigkeit zwar nie garantieren lässt, inkompatible PICSs jedoch oftmals ein Anhaltspunkt dafür sind, dass ein Zusammenwirken nicht möglich ist);

- durch einen Protokollprüfer als Grundlage für die Auswahl geeigneter Prüfungen zur Bewertung des Konformitätsanspruchs der Implementierung.

D.2. Anweisungen zum Ausfuellen der PICS-Formulare

D.2.1. Allgemeiner Aufbau der PICS-Formulare

D.2.1.1. (NE) Das Implementierungskennblatt mit Protokollzusammenfassung bildet den ersten Teil jedes PICS-Formulars und ist wie angegeben mit den erforderlichen Informationen zur vollständigen Identifizierung des Lieferanten und der Implementierung auszufuellen.

D.2.1.2. (NE) Der Hauptteil des PICS-Formulars ist ein Fragebogen mit feststehendem Format. Die Antworten auf die einzelnen Positionen sind in die äußerste rechte Spalte einzutragen, und zwar entweder durch Ankreuzen einer Antwort (meist Ja oder Nein) oder durch Angabe eines Wertes bzw. einer Menge von Werten oder eines Wertbereichs.ANMERKUNGEN

1. Jede Position verfügt über eine eindeutige Kennung in der ersten Spalte; die zweite Spalte enthält die zu beantwortende Frage; die dritte Spalte enthält den Verweis bzw. die Verweise auf die entsprechende Spezifikation in dieser Eurocontrol-Norm. Die übrigen Spalten geben den Status der Position an (Unterstützung zwingend vorgeschrieben, optional, unzulässig oder bedingt) und bieten Raum für die Antworten: siehe auch D.2.4.

2. Ein Lieferant kann auch weitere Informationen als Zusatzinformationen oder Einwandinformationen angeben bzw. dazu aufgefordert werden. Derartige Informationen sind zu Querverweiszwecken als Unterpositionen A< i > bzw. X< i > zu kennzeichnen, wobei < i > eine beliebige eindeutige Positionskennung (z. B. einfach eine Zahl) darstellt. Für Format und Darstellung bestehen keine weiteren Einschränkungen.

D.2.1.3. (NE) Ein ausgefuelltes PICS-Formular einschließlich eventueller Zusatzinformationen und Einwandinformationen wird als Erklärung zur Konformität der Protokollimplementierung für die betreffende Implementierung (PICS) bezeichnet. ANMERKUNG

Kann eine Implementierung auf mehr als eine Weise konfiguriert werden, ist die Beschreibung sämtlicher Konfigurationen unter Umständen in einer einzigen PICS möglich. Wenn sich die Angaben jedoch anders einfacher und klarer darstellen lassen, steht es dem Lieferanten frei, mehrere PICS abzugeben, die sich jeweils auf eine Teilmenge der Konfigurationsmöglichkeiten beziehen.

D.2.2. Zusatzinformationen

Mit Zusatzinformationen kann ein Lieferant weitere Angaben für eine bessere Auslegung der PICS bereitstellen.ANMERKUNGEN

1. Es ist weder beabsichtigt noch wird erwartet, dass große Mengen derartiger Angaben bereitgestellt werden, und eine PICS kann auch ohne derartige Informationen als vollständig gelten. Beispiele wären etwa eine kurze Beschreibung der Einrichtungsmöglichkeiten einer (bestimmten) Implementierung für den Betrieb in den verschiedensten Umgebungen und Konfigurationen oder eine kurze Begründung (vielleicht auf der Grundlage spezieller Anwendungserfordernisse) für den Ausschluss von Leistungsmerkmalen, die, obgleich optional, in Implementierungen dieses Protokolls allgemeinhin vorhanden sind.

2. Verweise auf Zusatzinformationen können neben einer Antwort im Fragebogen eingetragen und in Einwandinformationen aufgenommen werden.

D.2.3. Einwandinformationen

D.2.3.1. Mitunter möchte ein Lieferant möglicherweise eine Position mit dem Status "zwingend vorgeschrieben" oder "unzulässig" (nach Anwendung von Bedingungen) in einer Weise beantworten, die im Widerspruch zur angegebenen Anforderung steht. Da in der Spalte "Unterstützung" dafür keine vorgedruckten Antworten vorhanden sind, muss der Lieferant die fehlende Antwort in die Spalte "Unterstützung" mit dem Verweis X< i > auf eine Einwandinformation eintragen.

D.2.3.2. (NE) Die entsprechende Begründung ist vom Lieferanten in der eigentlichen Einwandposition abzugeben.

D.2.3.3. Eine Implementierung, für die eine derartige Einwandposition erforderlich ist, ist nicht mit dieser Spezifikation konform.ANMERKUNG

Ein möglicher Grund für die beschriebene Situation besteht darin, dass ein Fehler in der Norm gemeldet worden ist und es im Zusammenhang mit dessen Korrektur zu einer Änderung der von der Implementierung nicht erfuellten Anforderung kommen kann.

D.2.4. Bedingte Positionen

D.2.4.1. Einzelne bedingte Positionen werden durch ein Bedingungssymbol der Form "< Position >:< s >" in der Status-Spalte angegeben, wobei "< Position >" eine Positionskennung, die in der ersten Tabellenspalte für eine andere Position erscheint, und "< s >" ein Statuszeichen M, O, O.< n > oder X ist.ANMERKUNG

Ein PICS-Formular kann eine Reihe von bedingten Positionen enthalten. Dabei handelt es sich um Positionen, bei denen sowohl ihre Anwendbarkeit als auch ihr Status im Falle der Anwendbarkeit (zwingend vorgeschrieben, optional oder unzulässig) davon abhängen, ob bestimmte andere Positionen unterstützt werden oder nicht.

D.2.4.2. (NE) Wenn die mit dem Bedingungssymbol angegebene Position als unterstützt angekreuzt ist, so ist die bedingte Position anwendbar, und ihr Status wird mit "< s >" angegeben. Die Spalte "Unterstützung" ist auf die übliche Weise auszufuellen. Anderenfalls ist die bedingte Position nicht relevant, und es ist die Antwort Nichtzutreffend (NA) anzukreuzen.

D.2.4.3. Jede Position, deren Kennung in einem Bedingungssymbol verwendet wird, ist in der Positionsspalte mit einem Sternchen versehen.

D.3. PICS-Formular für das Nachrichtenübertragungsprotokoll

D.3.1. Abkürzungen und Sonderzeichen

D.3.1.1. Statuszeichen

M: Mandatory (zwingend vorgeschrieben)

O: Optional

D.3.1.2. Positionskennungen

Positionen im PICS-Formular werden durch mnemonische Positionskennungen angegeben. PICS-Positionen, die sich auf verwandte Funktionen beziehen, werden mit dem gleichen Anfangsbuchstaben oder -buchstabenpaar (Großbuchstaben) gekennzeichnet. Nachfolgend eine Liste dieser Anfangsbuchstaben in der Reihenfolge, in der die Positionsgruppen im PICS-Formular erscheinen.

>PLATZ FÜR EINE TABELLE>

D.3.2. Kennblatt

>PIC FILE= "L_2000254DE.020301.EPS">

D.3.3. Protokollimplementierung

>PIC FILE= "L_2000254DE.020401.EPS">

D.4. PICS-Formular für das Nachrichtenkopfprotokoll

D.4.1. Abkürzungen und Sonderzeichen

D.4.1.1. Statuszeichen

M mandatory (zwingend vorgeschrieben)

O optional

O.< n > optional, aber Unterstützung mindestens einer der mit der gleichen Zahl < n > gekennzeichneten Optionsgruppen ist erforderlich

X unzulässig

< Position >: Zeichen für bedingte Position, abhängig von der für die < Position > angekreuzten Unterstützung (siehe D.2.4)

D.4.1.2. Abkürzungen

NA not applicable (nicht zutreffend)

D.4.1.3. Positionskennungen

>PLATZ FÜR EINE TABELLE>

D.4.2. Kennblatt

>PIC FILE= "L_2000254DE.020501.EPS">

D.4.3. Protokollimplementierung

>PIC FILE= "L_2000254DE.020601.EPS">

D.5. PICS-Formular für das Vermittlungsprotokoll

D.5.1. Abkürzungen und Sonderzeichen

D.5.1.1. Statuszeichen

M mandatory (zwingend erforderlich)

O optional

D.5.1.2. Positionskennungen

>PLATZ FÜR EINE TABELLE>

D.5.2. Kennblatt

>PIC FILE= "L_2000254DE.020701.EPS">

D.5.3. Protokollimplementierung

>PIC FILE= "L_2000254DE.020702.EPS">

ANHANG E (Normativ)

LISTE DER PROFILANFORDERUNGEN

E.1. Einleitung

E.1.1. (NE) Dieser Anhang enthält die PRL für das in diesem Eurocontrol-Normendokument definierte FDE-ICD-Profil. Die Erklärung zur Konformität einer Implementierung, für die Konformität mit diesem Protokoll beansprucht wird, ist anhand der nachfolgenden Anweisungen zu erstellen.ANMERKUNG

Die in diesem Anhang enthaltenen Formulare basieren auf den Formularen, die den als Verweisdokumente zitierten Grundnormen beiliegen.

E.1.2. (NE) Eine konforme Implementierung muss die vorgeschriebenen Konformitätsanforderungen der in diesem Profil als Verweisdokumente zitierten Grundnormen erfuellen.

E.2. Die Rolle der PRL und PICS-Formulare

Der Status dieses Abschnitts (E.2) ist informativ. Er stellt keine Bestimmung dieses Teils der Eurocontrol-Norm dar.

- Die Darstellung der Konformitätsanforderungen in der tabellarischen Form der PRL und PICS-Formulare soll als Checkliste der Merkmale dienen, die implementiert werden müssen oder können. Die zugrundeliegenden Begriffe werden in ISO/IEC 9646-1 [Verweisdokument 14] (ITU-T-Empfehlung X.290 ist äquivalent) und ISO/IEC TR 10000-1 [Verweisdokument 2] definiert.

- Bei einem Profil werden die Optionen mehrerer Grundnormen kombiniert und ausgewählt, so dass eine bestimmte Informationsverarbeitungsfunktion erfuellt wird. Für jede Grundnorm gibt es ein PICS-Formular, in dem die Anforderungen der Norm aufgelistet sind. Die PRL umfasst die Teilmenge der PICS-Formularpositionen der Grundnorm, die vom Profil erzwungen werden, sowie die spezifischen Profilanforderungen. Sie definiert die Antworten, die auf den Grundnorm-PICS-Formularen für die Konformität mit dem Profil notwendig sind. Darüber hinaus enthält die PRL PICS-Positionen, die für das Profil spezifisch sind (so gibt es mindestens eine Position, die prüft, ob alle erforderlichen PICS-Formulare korrekt ausgefuellt wurden). Diese Positionen sind zusammen mit den PICS-Formularen der Grundnorm auszufuellen. Alle ausgefuellten Formulare zusammen bilden die Profil-Erklärung zur Konformität der Implementierung (ICS).

- Nach der Methodik von ISO/IEC TR 10000-1 [Verweisdokument 2] muss der Anspruch auf Konformität mit einem Profil durch PICS-Formulare belegt werden, die entsprechend der PRL ausgefuellt sind. Die Verwendung dieses Materials richtet sich nach dem Beschaffungsansatz für eine FDE-ICD-Implementierung.

- Es sind mehrere mögliche Ansätze für eine FDE-Implementierung denkbar:

- Interne Implementierung durch eine nationale Verwaltung oder Organisation: Die PRL sollte als Grundlage für die Spezifikation der Anforderungen und der Abnahmeprüfung für die Implementierung verwendet werden; die ausgefuellte ICS sollte im Rahmen des Abnahmeverfahrens erstellt werden.

- Implementierung des Profils durch einen Auftragnehmer: Verwendung und Erstellung des Materials wie bei einer internen Implementierung, doch sollte hier der Auftragnehmer die ICS abgeben, was vertraglich festzulegen ist.

- Implementierung des Profils durch einen Auftragnehmer im Rahmen eines Auftrags über die schlüsselfertige Lieferung bzw. Gesamtsystemherstellung: Das Material wird wie bei einer internen Implementierung verwendet, doch muss der Auftragnehmer verpflichtet werden, dies intern zu tun und darüber hinaus die ausgefuellte ICS vorzulegen. Durch Konformität mit dem Profil wird beispielsweise sichergestellt, dass ein für zwei Verwaltungen tätiger Lieferant nicht eigene, proprietäre Protokolle zur Erfuellung der FDE-Anforderungen einführen kann und die für die Auftragsvergabe zuständige Verwaltungen die Kontrolle behalten.

- Einbindung von Standardprodukten in eine Profilimplementierung in einem der genannten Fälle: Der Lieferant eines Produkts sollte verpflichtet werden, die für das Produkt relevanten PICS-Formulare entsprechend der hier angegebenen PRL auszufuellen und die Konformität des Produkts mit den geltenden Profilanforderungen zu garantieren; diese PICS kann dann als Teil der Profil-ICS weitergeleitet werden.

- Im Anschluss an die Implementierung sollte die ICS als Bestandteil der Dokumentation der Implementierung aufbewahrt werden; sie lässt sich zur Vorhersage der Interoperabilität mit anderen Verwaltungen sowie zur Feststellung eventuell erforderlicher Veränderungen beim Übergang zu anderen Protokollen verwenden.

E.3. Notation

E.3.1. Zur Angabe des Status von Leistungsmerkmalen wird in der PRL die folgende Notation aus ISO/IEC TR 10000-1 [Verweisdokument 2] verwendet:

m: mandatory (zwingend vorgeschrieben)

o: optional

-: nicht zutreffend (d. h. logisch unmöglich im Anwendungsbereich des Profils)

x: ausgeschlossen

ANMERKUNG

1. Es können Kombinationen aus zwei Zeichen verwendet werden, wobei das erste Zeichen den statischen (Implementierungs-) Status und das zweite den dynamischen (Verwendungs-) Status angibt; somit bedeutet "mo""Implementierung vorgeschrieben, Verwendung optional".

2. Mit der Notation "o.< n >" soll eine Menge wählbarer Optionen (d. h. mindestens eine Option muss implementiert werden) mit der gleichen Kennung n dargestellt werden.

3. Ein mit "x" gekennzeichnetes Leistungsmerkmal kann dennoch Bestandteil einer Implementierung sein, solange es nicht beim profilkonformen Betrieb der Implementierung genutzt wird.

4. Die Verwendung von mit "x" gekennzeichneten Leistungsmerkmalen bedarf einer bilateralen Vereinbarung. In diesem Falle sollte der Status der Leistungsmerkmale abgeändert werden, da sie unter Umständen von Interesse für andere Implementierungen sind.

E.3.2. Es wird die folgende Prädikatnotation verwendet:

< Prädikat > führt eine Gruppe von Positionen ein, die von < Prädikat > abhängen (der Umfang der Gruppe wird durch das Layout angezeigt).

< Prädikat > führt eine einzelne von < Prädikat > abhängige Position ein.

ANMERKUNG

In beiden Fällen kann das Prädikat die Kennung eines Profilmerkmals oder eine Boolsche Kombination von Prädikaten sein ("¬" ist das Zeichen für die logische Negation).

E.3.3. Bei der Angabe von Grundnormenanforderungen erfolgt die entsprechende Notation in Großbuchstaben (d. h. M, O, O.< n > X).

E.4. Anweisungen für das Ausfuellen der PICS-Formulare

E.4.1. (NE) Zur Bereitstellung der Profil-ICS sind die PICS-Formulare für die als Verweisdokumente zitierten Grundnormen zusammen mit den zusätzlichen in diesem Anhang enthaltenen profilbezogenen PICS-Positionen auszufuellen.

E.4.2. (NE) Werden die Leistungsmerkmale der Grundnormen durch dieses Profil präzisiert, so sind zur Einschränkung der zulässigen Antworten in den PICS-Formularen der Grundnormen die in dieser PRL aufgeführten Anforderungen (in den PRL-Positionen mit der Spalte "Profilmerkmale" angegeben) anzuwenden.

E.4.3. (NE) Werden in diesem Profil zusätzliche Anforderungen gestellt, so ist die Antwortspalte für diese Positionen auszufuellen. In dieser Spalte ist die entsprechende Antwort entweder aus den Vorgaben auszuwählen oder gegebenenfalls als Parameterwert(e) bzw. -wertbereich einzutragen.

E.4.4. Wird eine zwingend vorgeschriebene Anforderung nicht erfuellt, so sind Einwandinformationen zu liefern, indem einer Begründung für die Nichterfuellung der Verweis X< i > mit < i > als eindeutiger Kennung zur Seite gestellt wird.ANMERKUNG

Ein möglicher Grund für einen derartigen Einwand ist eine abgegebene Fehlermeldung im Hinblick auf eine Bestimmung des Profils; wird der Fehlermeldung stattgegeben, gilt die Implementierung als konform.

E.5. Verweise

E.5.1. Dieses Profil nimmt auf die folgenden Protokollspezifikationen Bezug:

- Nachrichtenübertragungsprotokoll ( zu diesem Eurocontrol-Normendokument);

- Nachrichtenkopfprotokoll ( zu diesem Eurocontrol-Normendokument);

- Verbindungsorientiertes Vermittlungsprotokoll unter Verwendung von ISO/IEC 8208 ( zu diesem Eurocontrol-Normendokument);

- ISO/IEC 7776 [Verweisdokument 6];

- Bitübertragungsschichtnormen, aufgerufen in ITU-T-Empfehlung X.25 (1993) clause 1 [Verweisdokument 1].

E.5.2. Da es keine expliziten PICS-Formulare für die entsprechenden Bitübertragungsschichtnormen gibt, sind die vorläufigen PICS-Formulare für die Bitübertragungsschicht in ISO/IEC ISP 10609-9 clause A.4 [Verweisdokument 8] zu verwenden.

E.6. Konformitätserklärung

E.6.1. Konformitätsüberblick

>PIC FILE= "L_2000254DE.021101.EPS">

E.6.2. Dynamische Konformitätsanforderungen

>PIC FILE= "L_2000254DE.021201.EPS">

E.7. Anforderungen bezüglich der oberen Schichten

Tabelle 3

Nachrichtenübertragungsprotokoll

>PLATZ FÜR EINE TABELLE>

E.8. Anforderungen bezüglich der unteren Schichten

E.8.1. Transportschichtanforderungen

Tabelle 4

Nachrichtenkopfprotokoll

>PLATZ FÜR EINE TABELLE>

E.8.2. Vermittlungsschichtanforderungen

Die in diesem Abschnitt aufgeführten PRL basieren auf dem PICS-Formular für ISO/IEC 8208:1993 [Verweisdokument 7]. Die Einträge in der Spalte "Verweise" unter "Grundnorm-Leistungsmerkmale" der nachfolgenden Tabellen sind Verweise auf Klauseln dieser Grundnorm.

E.8.2.1. Allgemeine DEE-Kenndaten

Tabelle 5

Allgemeine DEE-Kenndaten

>PLATZ FÜR EINE TABELLE>

E.8.2.2. Prozeduren, Pakettypen und Paketformate

Tabelle 6

Paketschichtfunktionen unabhängig von Netzzugangsverbindungen

>PLATZ FÜR EINE TABELLE>

Tabelle 7

Verbindungsaufbau

>PLATZ FÜR EINE TABELLE>

Tabelle 8

Verbindungsauslösung

>PLATZ FÜR EINE TABELLE>

Tabelle 9

Rücksetzen von Netzzugangsverbindungen

>PLATZ FÜR EINE TABELLE>

Tabelle 10

Fehlerverfahren

>PLATZ FÜR EINE TABELLE>

Tabelle 11

Interrupt-Transfer

>PLATZ FÜR EINE TABELLE>

Tabelle 12

Senden von Daten

>PLATZ FÜR EINE TABELLE>

Tabelle 13

Empfang von Daten

>PLATZ FÜR EINE TABELLE>

Tabelle 14

Übergabebestätigung

>PLATZ FÜR EINE TABELLE>

E.8.2.3. Verschiedene Leistungsmerkmale und Optionen

Tabelle 15

Werte für Grund- und Diagnosekodierung

>PLATZ FÜR EINE TABELLE>

E.8.2.4. Leistungsmerkmale

Tabelle 16

In CALL REQUEST-Paketen gesendete Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 17

In CALL ACCEPT-Paketen gesendete Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 18

In CLEAR REQUEST-Paketen gesendete Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 19

In INCOMING CALL-Paketen empfangene Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 20

In CALL CONNECTED-Paketen empfangene Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 21

In CLEAR INDICATION-Paketen empfangene Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

Tabelle 22

In CLEAR CONFIRMATION-Paketen empfangene Leistungsmerkmale

>PLATZ FÜR EINE TABELLE>

E.8.2.5. Parameterwerte und -Bereiche

Tabelle 23

Parameterwerte und -Bereiche

>PLATZ FÜR EINE TABELLE>

E.8.3. Sicherungsschichtanforderungen

Die in diesem Abschnitt angegebenen PRL basieren auf dem PICS-Formular für ISO/IEC 7776:1994 [Verweisdokument 6]. Die Einträge in der Spalte "Verweise" unter "Grundnorm-Leistungsmerkmale" der nachfolgenden Tabellen sind Verweise auf Klauseln dieser Norm.

Tabelle 24

Übermittlungsabschnittsprotokoll

>PLATZ FÜR EINE TABELLE>

E.8.4. Bitübertragungsschichtanforderungen

Siehe ISO/IEC TR 10609-9 clause A.4 [Verweisdokument 8].

ANHANG F (Informativ)

METHODIK DER KONFORMITÄTSRPÜFUNG

F.1. Einleitung

F.1.1. Implementierungen dieses ICD müssen unbedingt so ausgelegt sein, dass für die Zusammenarbeit zwischen den über die Schnittstelle verbundenen Flugverkehrskontrollstellen (ATCC) ein hohes Maß an Interoperabilitätssicherheit besteht.

F.1.2. Bei den Implementierungen der Schnittstelle dürfte die Beschaffung in den Mitgliedstaaten wahrscheinlich aus mehreren Quellen erfolgen. Um eine hohe Interoperabilitätssicherheit zu gewährleisten, bedarf es gemeinsamer Konformitätsprüfungsanforderungen, damit für die Vorbereitung und Durchführung der Prüfung sowie für die Präsentation der Ergebnisse eine einheitliche Grundlage vorhanden ist.

F.2. Zweck und Anwendungsbereich

F.2.1. In diesem Anhang werden die Anforderungen an die Prüfung der Konformität von Implementierungen der vorliegenden Eurocontrol-Norm, deren Bestandteil dieser Anhang ist, definiert.

F.2.2. Es werden Mechanismen aufgeführt, anhand derer die Interoperabilitätssicherheit der beanspruchten Schnittstelle mit Hilfe eines entsprechenden Prüfverfahrens ermittelt wird.

F.3. Bibliographie

Das folgende Dokument ist für die Prüfung von Implementierungen dieses Eurocontrol-Normendokuments relevant:

Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, vom 10. Mai 1996 [Verweisdokument 5].

F.4. Entwicklungsmethoden und -praktiken

F.4.1. Implementierungen des ICD lassen sich unter Heranziehung bestimmter Optionen und Versionen des ICD selbst umsetzen. Damit das Interoperabilitätspotential festgestellt werden kann, muss ein Mitgliedstaat, der die Schnittstelle implementiert, mit einer vorgegebenen Eigenschaftserklärung angeben, welche Teile des ICD und welche Beschränkungen für variable Parameter gegebenenfalls unterstützt werden.

F.4.2. Jede Implementierung sollte einer im folgenden beschriebenen Konformitätsprüfung unterzogen werden.

F.5. Prüfungen

F.5.1. Einleitung

F.5.1.1. Zur Feststellung der Interoperabilität und Unterstützung der FDE-Schnittstelle einer ATCC im Rahmen der Zusammenarbeit zwischen FDE-Anwendungen ist es wünschenswert, dass eine Prüfung der Konformität mit den Normen durchgeführt wird, deren Bestandteil dieser Anhang ist. Diese Prüfung erfolgt gegenüber dem äußeren Verhalten des Systems in Prüfung (SUT) und dient als Prüfung des Zusammenwirkens und nicht der Funktionstüchtigkeit des Endsystems.

F.5.1.2. Die Ergebnisse einer derartigen Prüfung können als Beleg zur Stützung gemäß Abschnitt 5.1 dieses Teils des vorliegenden Eurocontrol-Normendokuments erhobener Konformitätsansprüche dienen. Die durch diese Profilspezifikation aufgerufenen PICS-Formulare und PRL können als Grundlage für Konformitätsprüfungen herangezogen werden; darüber hinaus sind in internationalen Normen (z. B. ISO/IEC 8208 [Verweisdokument 7])möglicherweise bereits abstrakte Prüfreihen definiert, die sich bei der Konformitätsprüfung verwenden lassen.

F.5.1.3. Mit diesem Dokument soll ein einheitliches Prüfprogramm auf der Grundlage einer einheitlichen Prüfreihe bereitgestellt werden, mit dessen Anwendung eine Vergleichbarkeit der Prüfergebnisse, deren breite Akzeptanz sowie eine Minimierung erforderlicher Konformitätsprüfungen zu erwarten ist. Die einheitliche Prüfreihe wurde zum Teil von Eurocontrol entwickelt.

F.5.1.4. Auf der Basis von Abbildung 2 erfolgt die Prüfung des kompletten Endsystems in Form von Tests in den drei unteren Schichten. Es empfiehlt sich, Prüfungen der FDE-Anwendung, sowie der Status-, System- und Betreibernachrichten mit aufzunehmen.

F.5.1.5. Die einzelnen nachfolgend beschriebenen Prüfungen sollten in der angegebenen Reihenfolge durchgeführt werden. So ist die letzte Prüfung nur dann erfolgreich, wenn die unteren Schichten korrekt funktionieren, was wahrscheinlich mit den ersten Prüfungen ermittelt werden kann.

F.5.1.6. Ungeachtet der vorstehenden Ausführungen sind die in diesem Abschnitt beschriebenen Prüfungen freiwillig.

F.5.2. Prüfung der unteren Schichten (Schicht 1 - 3)

Angesichts des erforderlichen Zusammenwirkens zwischen den einzelnen ATCC wird empfohlen, den Prüfungen den im Eurocontrol(Maastricht UAC Systems Division) FDE ICD Integration Test Plan dargelegten Prüfungsplan zugrundezulegen. Prüfverfahren sind zwischen kooperierenden ATCC bilateral zu vereinbaren.

F.5.3. Prüfung der Anwendungsschicht

Von kooperierenden ATCC sollte eine Reihe von Prüfungen bilateral vereinbart und durchgeführt werden.

F.5.4. Zertifizierung

Die Prüfungsergebnisse sollten aufgezeichnet und zwischen den kooperierenden Stellen abgestimmt werden.

F.5.5. Meldung

Angaben zur den Ergebnissen durchgeführter Prüfungen sollten von den Mitgliedstaaten an Eurocontrol weitergeleitet werden.

ANHANG G (Informativ)

ZUWEISUNG VON ATC-STELLENKENNUNGEN

In der folgenden Tabelle sind die mit Stand vom 22. April 1997 zugewiesenen ATC-Stellenkennungen aufgeführt. Auskunft zum aktuellen Stand der Kennungszuweisung erteilt Eurocontrol. Darüber hinaus zeigt die Tabelle die hexadezimale Binärcodierung der Kennung im Rahmen der in Anhang C definierten Adresscodierung.

Tabelle 1

ATC-Stellenkennungen

>PLATZ FÜR EINE TABELLE>

ANHANG H (Informativ)

HINWEISE ZU VERLÄSSLICHKEIT, VERFÜGBARKEIT und sicherheit

H.1. Einleitung

Es wird davon ausgegangen, dass ATC-Anwendungen wie z. B. OLDI X.25-Verbundnetze und/oder öffentliche bzw. private Telekommunikationsdienste verwendet werden. Daher wird es als notwendig erachtet, Hinweise für Implementierungen des FDE ICD Teil 1 zu geben.

H.2. Zweck und Anwendungsbereich

H.2.1. In diesem Anhang sollen Hinweise zu Fragen der Verlässlichkeit, Verfügbarkeit und Sicherheit gegeben werden.

H.2.2. Der Anwendungsbereich dieses Anhangs basiert auf zwei Szenarien. Beim ersten Szenario handelt es sich um eine Festverbindung über Standleitung. Das zweite Szenario ist in einer X.25-Netzverbundumgebung angesiedelt.ANMERKUNG

Fragen des Verbunds von X.25-Netzen bleiben beim zweiten Szenario unberücksichtigt.

H.2.3. Es wird zugesichert, dass Implementierungen vor Aufschalten, Stromausfall und anderen äußeren Gefahren, die einen normalen Betrieb beeinträchtigen können, geschützt sind.

H.3. Bibliographie

Das folgende Dokument ist eine ausführliche technische Analyse, zu der dieser Anhang einen Überblick gibt:

Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [Verweisdokument 16].

H.4. Standleitungsimplementierungen

H.4.1. Verlässlichkeit

Zur Erhöhung der Zuverlässigkeit müssen Standleitungs-, PSTN-, ISDN-Kabel physisch unterschiedlichen Wegen folgen und mit unterschiedlichen Switches des Telekommunikationsbetreibers verbunden sein (dem Telekommunikationsbetreiber sind entsprechende Angaben zu machen).

H.4.2. Verfügbarkeit

H.4.2.1. Wegen der langen Aufbauzeiten in PSTN, die mit zeitkritischen Anwendungen unvereinbar sind, sollte ISDN als Träger genutzt werden.

H.4.2.2. Im Falle einer Ersatzschaltung sollte die Ersatz-DEE zur Beschleunigung des Verbindungswiederaufbaus einen DISC-Block generieren.

H.4.3. Sicherheit

H.4.3.1. Wird ISDN als Träger genutzt, sollte die gerufene ISDN-Endgeräteanpassung (TA) die E.164-Adresse des Anrufers auf Gültigkeit prüfen [Verweisdokument 18].

H.4.3.2. Die rufende DEE sollte die ITU-T-Empfehlung X.32 [Verweisdokument 17] durch Anruferidentifizierung und für Berechtigungsinformationen erfuellen.

H.4.4. Konfigurationsbeispiel

Abbildung H.1.

Konfigurationsbeispiel Standleitung

>PIC FILE= "L_2000254DE.023301.EPS">

H.5. Netzimplementierung

H.5.1. Verlässlichkeit

Zur Erhöhung der Verlässlichkeit des Dienstes sollten die Zentralrechner eines Standorts mit zwei zu unterschiedlichen Netz-Switches gehörenden DÜE verbunden sein (diese Anforderung sollte dem Netzbetreiber angegeben werden).

H.5.2. Verfügbarkeit

H.5.2.1. Um den an einem Standort befindlichen DÜE eine einheitliche X.121-Adresse [Verweisdokument 20] zuweisen zu können und so die Netzverkehrslenkung zu optimieren und erfolglose Verbindungen zu begrenzen, sollte das Leistungsmerkmal Teilnehmergruppe mit gemeinsamer Adresse verwendet werden.

H.5.2.2. Falls andere Verbindungsmechanismen implementiert werden, die zu einem anderen Wert der gerufenen DEE-Adresse in den Paketen CALL REQUEST und CALL ACCEPT führen, sollte die rufende DEE so konfiguriert sein, dass sich keine Auswirkungen auf den Verbindungsaufbau ergeben.

H.5.2.3. Bei DTE-Verbindungsabbau aufgrund eines Netzausfalls und bei Verfügbarkeit eines zweiten Netzzugangs sollte der Verbindungswiederaufbau über diesen zweiten Zugang erfolgen.

H.5.3. Sicherheit

Innerhalb des Anwendungsbereichs dieses Anhangs sollte die geschlossene Benutzergruppe (CUG) als einzige gültige Netzeinrichtung verwendet werden.

H.6. Allgemeine Hinweise für Standleitungs- und Netzimplementierungen

H.6.1. Verlässlichkeit

H.6.1.1. Da ein vollständiger Host-Switchover lange dauern kann, ist die Verwendung eines Front-End-Prozessors (FEP) zwecks Überbrückung von Zentralrechnerausfällen überlegenswert.

H.6.1.2. Mit einer auf einem FEP basierenden Architektur kann sich die Dienstverlässlichkeit erhöhen.ANMERKUNG

Im Rahmen einer künftigen Norm FDE ICD Teil 2 wird möglicherweise die Einbindung eines Transport-Stacks in die Profilspezifikation entwickelt.

H.6.2. Verfügbarkeit

Ist eine Verbindung erfolglos, sollte die rufende Stelle eine zweite Verbindung unter Verwendung der (gegebenenfalls vorhandenen) zweiten X.121-Adresse aufbauen.

H.6.3. Systemmanagement

H.6.3.1. Wenn möglich, sollten Switches verwendet werden, die durch Scannen der Schnittstellensignale automatisch umschalten.

H.6.3.2. Zur Auslösung eines Host-Switchover kann während der Datenübertragung eine lokale Fehleranzeige verwendet werden.

H.6.3.3. Der Switchover eines FEP sollte ein TC-Disconnect erzeugen, um sicherzustellen, dass sich der lokale Host im Ruhezustand befindet.

H.6.3.4. Bei Überschreiten der Zeit im X.25-Netz oder in den Sicherungsschichten sollten die höheren Schichten freigegeben werden.

H.6.3.5. Ein FEP-Totalausfall sollte ein TC-Disconnect erzeugen.

H.6.3.6. Zur Unterscheidung zwischen einem Nachrichtenübertragungsprotokollausfall und einem Anwendungsausfall sollte das Managementsystem die Nachrichtenübertragungsprotokollschicht (Anhang A) abfragen und den Zustandsautomaten überprüfen.

H.6.4. Konfigurationsbeispiel

Abbildung H.2

Konfigurationsbeispiel Netz

>PIC FILE= "L_2000254DE.023401.EPS">