2000R2082 — DE — 15.06.2002 — 001.001 — 1
Dieses Dokument ist lediglich eine Dokumentationsquelle, für deren Richtigkeit die Organe der Gemeinschaften keine
Gewähr übernehmen
►B 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
(ABl. L 254 vom 9.10.2000, S. 1)
Geändert durch:
Amtsblatt
Nr. Seite Datum
►M1Verordnung (EG) Nr. 980/2002 der Kommission vom 4. Juni 2002 L 150 38 8.6.2002
▼B
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ürdie Beschaffung von Ausrüstungen und Systemen für das Flugverkehrs-management(
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 derRichtlinie 93/65/EWG des Rates über die Aufstellung und Anwendungkompatibler 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 Euro-control-Norm für die Darstellung des Datenaustauschs in derFlugsicherung (ADEXP), Ausgabe 1.0, übernommen.
(2)Eurocontrol hat eine neuere Fassung der beiden genanntenNormen verabschiedet, nämlich OLDI Ausgabe 2.2 und ADEXPAusgabe 2.0, sowie eine neue Eurocontrol-Norm mit der
Bezeichnung Flugdatenaustausch-Schnittstellensteuerungsdoku-
ment (FDE-ICD).
(3)Diese Eurocontrol-Normen fallen in den Geltungsbereich derRichtlinie 93/65/EWG und tragen zur Harmonisierung der Flug-verkehrsmanagementsysteme der Mitgliedstaaten bei,insbesondere was die Übergabe von Flügen von einer Flugsiche-rungszentrale 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 dieStelle der früheren Ausgaben, die nach Artikel 1 der Richtlinie
97/15/EG zur Zeit gültig sind; daher muss dieser Artikel aufge-hoben werden.
(5)Die Bestimmungen dieser Verordnung stimmen mit der Stellung-nahme des gemäß der Richtlinie 93/65/EWG eingesetztenAusschusses ü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 obligatori-schen Teile von Eurocontrol-Spezifikationen übernommen, soweit siefür die Einrichtung eines integrierten, europäischen Flugverkehrsmana-
gementsystems 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-Fundstelle2000R2082 — DE — 15.06.2002 — 001.001 — 2
(1) ABl. L 187 vom 29.7.1993, S. 52.
(2) ABl. L 95 vom 10.4.1997, S. 16.
▼B
DPS.ET1.ST09-STD), die im Anhang II dieser Verordnung wieder-
gegeben ist,
— Eurocontrol-Norm für das Flugdatenaustausch-Schnittstellensteu-
erungsdokument (FDE-ICD), Ausgabe 1.0 (Eurocontrol-FundstelleCOM.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 unmit-
telbar in jedem Mitgliedstaat.2000R2082 — DE — 15.06.2002 — 001.001 — 3
▼B
ANHANG I
ONLINE-DATENAUSTAUSCH (OLDI), AUSGABE 2.2
(Eurocontrol-Fundstelle DPS.ET1.ST06-STD)2000R2082 — DE — 15.06.2002 — 001.001 — 4
▼B
INHALTSVERZEICHNIS
URHEBERRECHTLICHER HINWEIS
VORWORT1. EINLEITUNG
1.1. Zweck1.2. Geltungsbereich
2. VERWEISE3. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN
3.1. Definitionen3.2. Symbole und Abkürzungen
4. ALLGEMEINE ANFORDERUNGEN
4.1. Einführung4.2. Anforderungen an das Flugdatenverarbeitungssystem (FDPS)4.2.1. Flugdatenbank4.2.2. Echtzeit-Operation4.2.3. Datenkommunikationsfähigkeit4.2.4. Anwendungsfunktionen4.2.5. Mensch-Maschine-Schnittstelle (HMI)4.2.6. Einleitung von Meldungen4.2.7. Empfang von Meldungen4.3. Aktualisierung anhand Überwachungsdaten4.4. Aufzeichnen von OLDI-Daten4.4.1. Inhalt4.4.2. Leistungsmerkmale4.5. Verfügbarkeit, Verlässlichkeit, Datensicherheit und Datenintegrität4.5.1. Verfügbarkeit4.5.2. Verlässlichkeit4.5.3. Datensicherheit4.5.4. Datenintegrität4.6. Operationelle Bewertung4.6.1. Bewertungszeitraum4.6.2. Datum der Betriebseinführung
5. KATEGORIEN VON MELDUNGEN
5.1. Allgemein5.1.1. Zweck5.1.2. Kategorien von Meldungen5.2. Transaktionszeiten5.2.1. Bedingungen für Transaktionszeiten5.3. Klassifizierung und Kategorisierung von Meldungen2000R2082 — DE — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Klassifizierung von Meldungen — obligatorisch und komplementär
5.3.2. Kategorisierung von Meldungen
6. GRUNDVERFAHREN — OBLIGATORISCHE MELDUNGEN
6.1. Allgemein6.1.1. Anforderungsbeschreibung6.1.2. Implementierung6.2. Vorabinformationen über die Grenzpassage (ABI)
6.2.1. Zweck der ABI-Meldung
6.2.2. Bestandteile der Meldung6.2.3. Anwendungsregeln6.2.4. Bestätigung von ABI6.2.5. Beispiele6.3. Aktivierungsmeldung (ACT)
6.3.1. Zweck der ACT-Meldung
6.3.2. Bestandteile der Meldung6.3.3. Anwendungsregeln6.3.4. Bestätigung von ACT6.3.5. Beispiele
6.4. Logische Bestätigung (LAM)
6.4.1. Zweck der LAM6.4.2. Bestandteile der Meldung6.4.3. Anwendungsregeln6.4.4. Bestätigung von LAM6.4.5. Beispiele
7. GRUNDVERFAHREN — KOMPLEMENTÄRE MELDUNGEN
7.1. Allgemein
7.1.1. Anforderungsbeschreibung7.1.2. Implementierung7.2. Vorläufige Aktivierung (PAC)7.2.1. Zweck der PAC-Meldung7.2.2. Bestandteile der Meldung
7.2.3. Anwendungsregeln
7.2.4. Bestätigung von PAC7.2.5. Beispiele7.3. Revisionsmeldung (REV)7.3.1. Zweck der REV-Meldung
7.3.2. Bestandteile der Meldung
7.3.3. Anwendungsregeln7.3.4. Bestätigung von REV7.3.5. Beispiele2000R2082 — DE — 15.06.2002 — 001.001 — 6
▼B
7.4. Koordinationsabbruch (MAC)
7.4.1. Zweck der MAC-Meldung7.4.2. Bestandteile der Meldung
7.4.3. Anwendungsregeln
7.4.4. Bestätigung von MAC7.4.5. Beispiele7.5. SSR-Code-Zuweisung (COD)
7.5.1. Zweck der COD-Meldung
7.5.2. Bestandteile der Meldung7.5.3. Anwendungsregeln
7.5.4. Bestätigung von COD
7.5.5. Beispiele7.6. Informationsmeldung (INF)7.6.1. Zweck der INF-Meldung
7.6.2. Bestandteile der Meldung
7.6.3. Anwendungsregeln7.6.4. Bestätigung von INF
7.6.5. Beispiele
8. DIALOGVERFAHREN — KOORDINATION
8.1. Allgemein8.1.1. Einführung
8.1.2. Das Filter
8.1.3. Abfolge der Meldungen8.1.4. Behandlung von gleichzeitigen Meldungen8.1.5. Behandlung einer Ablehnung
8.1.6. Time-Out für operationelle Antworten
8.1.7. Implementierung8.2. Aktivierungsmeldung (ACT)
8.2.1. Zweck der ACT-Meldung
8.2.2. Bestandteile der Meldung8.2.3. Anwendungsregeln
8.2.4. Bestätigung von ACT
8.3. Verwiesener Aktivierungsvorschlag(RAP)8.3.1. Zweck der RAP-Meldung8.3.2. Bestandteile der Meldung
8.3.3. Anwendungsregeln
8.3.4. Bestätigung von RAP8.3.5. Operationelle Antwort auf RAP
8.3.6. Beispiele
8.4. Revisionsmeldung (REV)2000R2082 — DE — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Zweck der REV-Meldung
8.4.2. Bestandteile der Meldung8.4.3. Anwendungsregeln
8.4.4. Bestätigung von REV
8.4.5. Operationelle Antwort auf REV8.5. Verwiesener Revisionsvorschlag (RRV)8.5.1. Zweck der RRV-Meldung
8.5.2. Bestandteile der Meldung
8.5.3. Anwendungsregeln8.5.4. Bestätigung von RRV
8.5.5. Operationelle Antwort auf RRV
8.5.6. Beispiele8.6. Stand-By-Meldung (SBY)8.6.1. Zweck der SBY-Meldung
8.6.2. Bestandteile der Meldung
8.6.3. Anwendungsregeln8.6.4. Bestätigung von SBY
8.6.5. Beispiele
8.7. Annahmemeldung (ACP)8.7.1. Zweck der ACP-Meldung
8.7.2. Bestandteile der Meldung
8.7.3. Anwendungsregeln8.7.4. Bestätigung von ACP8.7.5. Beispiele
8.8. Koordinationsmeldung (CDN)
8.8.1. Zweck der CDN-Meldung8.8.2. Bestandteile der Meldung
8.8.3. Anwendungsregeln
8.8.4. Bestätigung von CDN8.8.5. Operationelle Antwort auf CDN8.8.6. Beispiele
8.9. Koordinationsablehnung (RJC)
8.9.1. Zweck der RJC-Meldung8.9.2. Bestandteile der Meldung
8.9.3. Anwendungsregeln
8.9.4. Bestätigung von RJC8.9.5. Beispiele
9. DIALOGVERFAHREN — KOMMUNIKATIONSÜBERGABE
9.1. Allgemein
9.1.1. Einführung2000R2082 — DE — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Meldungssequenz
9.1.3. Kommunikationsübergabe9.2. Übergabeeinleitungsmeldung (TIM)
9.2.1. Zweck der TIM-Meldung
9.2.2. Bestandteile der Meldung9.2.3. Anwendungsregeln9.2.4. Bestätigung von TIM9.2.5. Beispiel9.3. Zusatzdatenmeldung (SDM)9.3.1. Zweck der SDM-Meldung9.3.2. Bestandteile der Meldung9.3.3. Anwendungsregeln9.3.4. Bestätigung von SDM9.3.5. Beispiel9.4. Hand-Over-Vorschlag (HOP)9.4.1. Zweck der HOP-Meldung9.4.2. Bestandteile der Meldung9.4.3. Anwendungsregeln9.4.4. Bestätigung von HOP9.4.5. Beispiel9.5. Frequenzanforderungsmeldung (ROF)
9.5.1. Zweck der ROF-Meldung
9.5.2. Bestandteile der Meldung9.5.3. Anwendungsregeln9.5.4. Bestätigung von ROF9.5.5. Beispiel9.6. Frequenzwechselmeldung (COF)9.6.1. Zweck der COF-Meldung9.6.2. Bestandteile der Meldung9.6.3. Anwendungsregeln9.6.4. Bestätigung von COF9.6.5. Beispiele9.7. Manuelle Kommunikationsübernahme (MAS)9.7.1. Zweck der MAS-Meldung9.7.2. Bestandteile der Meldung9.7.3. Anwendungsregeln9.7.4. Bestätigung von MAS9.7.5. Beispiel
ANHANG A (NORMATIV) DATENEINSETZREGELN
ANHANG B (NORMATIV) BESONDERE ANFORDERUNGEN AN DIE VERARBEITUNG VON
STRECKENDATEN2000R2082 — DE — 15.06.2002 — 001.001 — 9
▼B
ANHANG C (INFORMATIV) PHASEN DES DIALOGVERFAHRENS (SYSCO-LEVEL 1) —
MELDUNGSABFOLGE2000R2082 — DE — 15.06.2002 — 001.001 — 10
▼B
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 Mitglied-
staaten somit frei zur Verfügung; jede Abschrift oder Offenlegung an
andere bedarf jedoch der vorherigen schriftlichen Einwilligung der Agentur
Eurocontrol.2000R2082 — DE — 15.06.2002 — 001.001 — 11
▼B
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), Euro-
control, 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-Datenverarbei-
tungssysteme (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 Korrespondenzver-
fahren;
— 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 even-
tuellen 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 Empfehlung-
scharakter 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) vorange-
stellt. Elemente mit Empfehlungscharakter enthalten das Verb
„sollte“. Sie sind kursivgedruckt.
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.2000R2082 — DE — 15.06.2002 — 001.001 — 12
▼B
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üt-
zung der Überquerung 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 Übergab-
ebedingungen 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 Kommunikati-
onsü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 einge-
führt. Sämtliche für das Grundverfahren festgelegten sowie
während der Koordinationsphase des Dialogverfahrens
verwendeten Meldungen werden sowohl im Format der Inter-
nationalen 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 Doku-
ment 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.2000R2082 — DE — 15.06.2002 — 001.001 — 13
▼B
8. Sprache
Die Originalversion dieses Dokuments wurde in englischer
Sprache verfasst.2000R2082 — DE — 15.06.2002 — 001.001 — 14
▼B
1. EINLEITUNG
1.1. Zweck
1.1.1. Flüge, die dem Flugverkehrskontrolldienst (ATC-Dienst) unter-
liegen, 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 Flug-
kontrolle 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, insbe-
sondere der Bezirkskontrollstellen (ACC). Mit der operationellen
Nutzung von Verbindungen zwischen den Flugdatenverarbei-
tungssystemen (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üh-
renden 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 Flugver-
kehrskontrollstellen 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 Leistungsmerk-
male, 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 Zivilluftfahrtkonfe-
renz (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 Eurocon-
trol-Normendokuments darstellen.
Zum Zeitpunkt der Veröffentlichung dieses Eurocontrol-Normen-
dokuments waren die für die Verweisdokumente angegebenen
Ausgaben gültig.
Jede Überarbeitung der Verweisdokumente der Internationalen
Zivilluftfahrt-Organisation (ICAO) gilt unmittelbar als Überarbei-
tung dieses Eurocontrol-Normendokuments.2000R2082 — DE — 15.06.2002 — 001.001 — 15
▼B
Überarbeitungen der anderen Verweisdokumente werden erst zum
Bestandteil der Bestimmungen dieses Eurocontrol-Normendoku-
ments, wenn sie formal überprüft und in dieses Eurocontrol-
Normendokument eingearbeitet worden sind.
Bei Widersprüchen zwischen den Anforderungen dieses Eurocon-
trol-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 Flugverkehrskon-
trollstelle, 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 Abmes-
sungen, 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 Flugverkehrskontroll-
dienst 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ändigkeits-
gebiet 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.2000R2082 — DE — 15.06.2002 — 001.001 — 16
▼B
3.1.14. Koordinationsphase : In bezug auf einen gegeben Flug die Phase,
während der die übergebende und die übernehmende Flugver-
kehrskontrollstelle 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 Eigen-
schaften, Konfiguration, Werkstoffe, Leistung, Personal oder
Verfahren, deren einheitliche Anwendung für die Implementie-
rung 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 beabsich-
tigten 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 beschrie-
benen 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 angefor-
derte 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überga-
bepunkt 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 im2000R2082 — DE — 15.06.2002 — 001.001 — 17
▼B
empfangenden System, Generierung und Übermittlung einer
Bestätigungsmeldung sowie deren Identifizierung im überge-
benden 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 Luftfahr-
zeug 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 Flug-
phase, während der die Kommunikationsübergabe erfolgt.
3.1.34. Übergebende Stelle : Flugverkehrskontrollstelle, die in einer Koor-
dinationssequenz 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 Nicht-
gelingen 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 — Vorab-
informationen über die Grenzpassage
ACC Area Control Centre — Bezirkskontrollstelle
ACP Accept Message — AnnahmemeldungACT Activate Message — Aktivierungsmeldung
ADEXP ATS Data Exchange Presentation — Darstellung des
ATS-Datenaustauschs
ATC Air Traffic Control — Flugverkehrskontrolle, Flug-
sicherung
ATM Air Traffic Management — Flugverkehrsmanage-
ment
ATS Air Traffic Service — FlugverkehrsdienstCDN Co-ordination Message — Koordinationsmeldung
CNL Flight Plan Cancellation — Flugplanaufhebung
COD SSR Code Assignment Message — SSR-Code-
Zuweisung
COF Change of Frequency Message — FrequenzwechselCOP Co-ordination Point — Koordinationspunkt
DED Directorate of EATCHIP Development, Eurocontrol
— Direktorat für die EATCHIP-Entwicklung, Euro-
control
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 — Doku-
ment des EATCHIP-Arbeitsprogramms
FDPS Flight Data Processing System — Flugdatenverar-
beitungssystem
FRF Further Route of Flight — Weitere Flugstrecke
HMI Human-Machine Interface — Mensch-Maschine-
Schnittstelle2000R2082 — DE — 15.06.2002 — 001.001 — 18
▼B
HOP Handover Proposal Message — Hand-Over-
Vorschlag
ICAO International Civil Aviation Organisation — Interna-
tionale Zivilluftfahrtorganisation
INF Information Message — Informationsmeldung
LAM Logical Acknowledgement Message — Logische
Bestätigungsmeldung
LoA Letter of AgreementMAC Message for the Abrogation of Co-ordination —
Koordinationsabbruchmeldung
MAS Manual Assumption of Communications — Manu-
elle Kommunikationsübernahme
NM Nautical Mile — SeemeileOLDI On-Line Data Exchange — Online-Datenaustausch
ORCAM Originating Region Code Assignment Method —
Methode der Code-Zuweisung zur Ursprungsregion
PAC Preliminary Activate Message — Vorläufige Akti-
vierung
RAP Referred Activate Proposal Message — Verwiesener
Aktivierungsvorschlag
REV Revision Message — RevisionsmeldungRJC Reject Co-ordination Message — Koordinationsab-
lehnung
ROF Request on Frequency Message — Frequenzanforde-
rungsmeldung
RRV Referred Revision Message — Verwiesene Revision
SBY Stand-by Message — Stand-By-Meldung
SDM Supplementary Data Message — Zusatzdatenmel-
dung
SSR Secondary Surveillance Radar — Rundsicht-
Sekundärradar
SYSCO System Supported Co-ordination — Systemgestützte
Koordination
TI Transfer Initiation — ÜbergabeeinleitungTIM Transfer Initiation Message — Übergabeeinleitungs-
meldung
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-Leistungs-
merkmals 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 Informa-
tionen enthalten. Die vorrangige Datenquelle für jeden Flug istder 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 Umge-
bung 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 über-2000R2082 — DE — 15.06.2002 — 001.001 — 19
▼B
gebenden 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 Zeitpara-
meter 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 Erweiter-
ungspotential 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 Anwen-
dung 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-Kommunika-
tionssystem 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 Iden-
tifizierung 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 rele-
vante Warnungen in Bezug auf empfangene Meldungen zur
unmittelbaren Beachtung anzuzeigen;
— Koordinations- und Übergabemeldungen an die für die Koor-
dination 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 abge-
schlossen wurde.2000R2082 — DE — 15.06.2002 — 001.001 — 20
▼B
4.2.5.4. (NE) Wird innerhalb der Parameterzeit nach Übermittlung einer
Koordinations- bzw. Übergabemeldung keine Bestätigung
empfangen, muss automatisch eine Warnung oder Benachrichti-
gung 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 HMIan ATC-Positionen, die OLDIeinsetzen,
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 Übermitt-
lung 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 Zeit-
punkt vorliegt.
Beispiel: Ein Flug beginnt an einem Punkt nahe der zu durchflie-
genden 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 Zeitpara-
meter(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 anzu-
zeigen;
— Bestätigungsmeldungen automatisch auf der Anwendungs-
ebene 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 entspre-
chende 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 Infor-2000R2082 — DE — 15.06.2002 — 001.001 — 21
▼B
mationen 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 Datenin-
tegritä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 Ausfall-
zeit 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 2 000 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 Bewer-
tungszeitraum unterzogen werden.
ANMERKUNG Ein Verfahren zur Unterstützung bei der Bewer-
tung 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;2000R2082 — DE — 15.06.2002 — 001.001 — 22
▼B
— legt Anforderungen an die Transaktionszeiten für die Katego-
rien dar;
— legt dar, welche Meldungen obligatorisch und welche komple-
mentä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, Erst-
verarbeitung bei der übernehmenden Stelle, Erstellung einer
Bestätigungsmeldung, deren Übermittlung sowie deren Empfang
bei der übergebenden Stelle ein. Die automatischen Bestätigungs-
meldungen 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
Kategorien von Meldungen 90 % 99,8 %
1 4 Sek. 10 Sek.
2 15 Sek. 10 Sek.
3 25 Sek. 45 Sek.
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 erfolg-
reich ü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 komple-
mentä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 Verarbei-
tungsprozess 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.2000R2082 — DE — 15.06.2002 — 001.001 — 23
▼B
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 brau-
chen 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 Koordi-
nation 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
Art der Meldung Abkürzung Kategorie Übermittlung Empfang
Vorabinformationen über
die GrenzpassageABI 3 M M
Aktivierung ACT 2 M M
Revision REV 2 C (1)C (1)
Vorläufige Aktivierung PAC 2 C C
Koordinationsabbruch MAC 2 C C
SSR-Code-Zuweisung COD 2 C C
Information INF 3 C C
Logische Bestätigung LAM M M
ANMERKUNG
(1) Obligatorisch für TX und REC bei Verwendung in Dialogverfahren.
Tabelle 5-3
Dialogverfahren — Meldungen während der Koordinationsphase
(Zusätzlich zu Tabelle 5-2)
Art der Meldung Abkürzung Kategorie Übermittlung Empfang
Verwiesener Aktivierungs-
vorschlagRAP 2 C M
Verwiesene Revision RRV 2 C M
Koordination CDN 2 M M
Stand-By (1) SBY M M
Annahme ACP 2 M M
Koordination ablehnen (2) RJC 2 C C
ANMERKUNGEN
(1) Siehe Absatz 5.2.1.1 Bedingungen für Transaktionszeiten.
(2) Nicht in allen Luftraumkonfigurationen verwendet.2000R2082 — DE — 15.06.2002 — 001.001 — 24
▼B
Tabelle 5-4
Dialogverfahren — Meldungen während der Übergabephase
Art der Meldung Abkürzung Kategorie Übermittlung Empfang
Übergabeeinleitung TIM 1 M M
Zusatzdaten SDM 1 (1)(1)
Übergabevorschlag HOP 1 M M
Frequenzwechsel (2) COF 1 C M
Frequenzanforderung ROF 1 C MManuelle Kommunikati-
onsübernahme (
2)MAS 1 C M
ANMERKUNGEN
(1) M, wenn von der übergebenden Stelle gesendet C, wenn von der übernehmenden Stelle
gesendet.
(2) Bilateral vereinbarte Verfahren müssen die Festlegung enthalten, dass bei der Übergabe in
Bezug auf eine gegebene Richtung des Verkehrsflusses zumindest entweder die übergebende
Stelle eine COF-Meldung oder die übernehmende Stelle eine MAS-Meldung senden muss.
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 erfüllt folgende operationelle Anforderungen:
— sorgt für die Erfassung fehlender Flugplandaten;
— stellt der nächsten Flugverkehrskontrollstelle Vorabinforma-
tionen ü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 Verkehrs-
aufkommens für den Abschnitt.
Die ABI ist eine Hinweismeldung.
6.2.2. Bestandteile der Meldung
Die ABI-Meldung muss folgende Dateneinheiten enthalten:
— Art der Meldung,
— Nummer der Meldung,
— Luftfahrzeugkennung,— SSR-Modus und -Code (sofern vorhanden),— Startflugplatz,— Schätzdaten,— Zielflugplatz,2000R2082 — DE — 15.06.2002 — 001.001 — 25
▼M1
▼M1
— Luftfahrzeugmuster und -zahl,
— Art des Fluges,— Bordausrüstung und Status,
— Flugstrecke (optional),
— sonstige Flugplandaten (optional).
ANMERKUNG: Die Dateneinsatzregeln, Datenformate und
Feldinhalte sind in Anhang A aufgeführt.
6.2.3. Anwendungsregeln
6.2.3.1. Allgemein6.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 Aktivi-
erungsvorschlag) 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 überneh-
menden 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 vorher-
gehenden 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 gene-
riert 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 Zeit-
spanne von der vorausgehenden ABI-Meldung abweicht;
—sonstige bilateral vereinbarte Daten .
6.2.3.2. Verarbeitung bei der übernehmenden Stelle6.2.3.2.1. (NE) Das eine ABI-Meldung empfangende Flugverkehrskontroll-
system 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 über-
mitteln.2000R2082 — DE — 15.06.2002 — 001.001 — 26
▼B
▼B
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 Übermitt-
lung 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 Strek-
kenfü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. I C A O
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.2.5.2. A D E X P
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 -FLTTYP N -BEGIN EQCST -EQPT W/
EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON)
6.3. Aktivierungsmeldung (ACT)
6.3.1. Zweck der ACT-Meldung
Die ACT-Meldung erfüllt folgende operationelle Anforderungen:
— Sie ersetzt die verbale Grenzüberflugvoraussage durch auto-
matisches Übertragen der Einzelheiten zu einem Flug von
einer Flugverkehrskontrollstelle zur nächsten noch vor
Übergabe der Kontrolle;
— sie aktualisiert die grundlegenden Flugplandaten bei der über-
nehmenden Flugverkehrskontrollstelle mit den neuesten
Informationen;
— sie erleichtert die Verteilung von Flugplandaten an die einbe-
zogenen Lotsenplätze bei der übernehmenden
Flugverkehrskontrollstelle sowie der Anzeige dieser Daten;
— sie beschleunigt die Anzeige der Rufzeichen-/Code-Korrelie-
rung bei der übernehmenden Flugverkehrskontrollstelle;
— sie schafft die Bedingungen zur Übergabe an die überneh-
mende Flugverkehrskontrollstelle.
6.3.2. Bestandteile der Meldung
Die ACT-Meldung muss folgende Datenelemente enthalten:
— Art der Meldung,
— Nummer der Meldung,
— Luftfahrzeugkennung,2000R2082 — DE — 15.06.2002 — 001.001 — 27
▼M1
▼B
▼M1
▼M1
— SSR-Modus und -Code,
— Startflugplatz,— Schätzdaten,— Zielflugplatz,
— Luftfahrzeugmuster und -zahl,
— Art des Fluges,— Bordausrüstung und Status,
— Flugstrecke (optional),
— sonstige Flugplandaten (optional).
ANMERKUNG: Die Dateneinsatzregeln, Datenformate und
Feldinhalte sind in Anhang A aufgeführt.
6.3.3. Anwendungsregeln
6.3.3.1. Allgemein6.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 überneh-
mende Stelle keine Koordination zu deren Änderung einleitet.
6.3.3.1.10. (NE) Eine weitere ACT-Meldung darf an denselben Koordinati-
onspartner 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 Stelle6.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.2000R2082 — DE — 15.06.2002 — 001.001 — 28
▼B
▼B
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. Übermittl ungsparameter
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 voraussichtli-
chen Zeit am COP;
— dem Zeitpunkt, zu dem sich der Flug in einer bilateral verein-
barten 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 aktuali-
sieren 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 Übermitt-
lung 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 Einzel-
heiten sind identisch, mit Ausnahme der ETO am COP, die in
der aufgezeigten ACT-Meldung 1226 beträgt.
6.3.5.1. I C A O
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
81/W/EQ Y/NO)
6.3.5.2. A D E X P
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 -FLTTYP N-BEGIN EQCST-
EQPT W/EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390
UB4 BNE UB4 BPK UB3 HON2000R2082 — DE — 15.06.2002 — 001.001 — 29
▼M1
▼B
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 übermit-
telten Meldung anzeigt.
Die Verarbeitung der LAM stellt dem ATC-Personal der überge-
benden 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 Weiterlei-
tung 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 Feld-
inhalte sind in Anhang A ausgeführt.
6.4.3. Anwendungsregeln
6.4.3.1. Allgemein6.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 techni-
scher 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 übermit-
telnde Flugverkehrskontrollsystem den für die Koordination
verantwortlichen Fluglotsen informieren, falls die LAM-Meldung
nicht innerhalb des für eine derartige Warnung gesetzten Zeitpa-
rameters 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 „Grund-
verfahren — Obligatorische Meldungen“ beschriebenen gelten.2000R2082 — DE — 15.06.2002 — 001.001 — 30
▼B
7.1.2. Implementierung
7.1.2.1. Die Verwendung jeglicher in diesem Abschnitt beschriebener
Leistungsmerkmale muss vor deren Einführung bilateral verein-
bart 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 erfüllt folgende operationelle Anforderungen:
— Benachrichtigung und dem Abflug vorausgehende Koordina-
tion 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 Koordina-
tion 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 Flug-
plandaten;
— 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 Feld-
inhalte sind in Anhang A ausgeführt.
7.2.3. Anwendungsregeln
7.2.3.1. Allgemein7.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.2000R2082 — DE — 15.06.2002 — 001.001 — 31
▼B
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 einge-
tragen 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 Ziel-
flugplatz 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 vorange-
gangenen 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 Stelle7.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 vorausge-
gangenen 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 detail-
lierte 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.2000R2082 — DE — 15.06.2002 — 001.001 — 32
▼B
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ünd-
lich einzuleiten
7.2.4.4. Fehlende COD-Meldung7.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-Anforderung7.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 COP7.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 übermit-
teln, 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,
— Luftfahrzeugkennung,
— Startflugplatz,— Schätzdaten und/oder Koordinationspunkt,— Zielflugplatz,
— Bezug der Meldung (optional),2000R2082 — DE — 15.06.2002 — 001.001 — 33
▼M1
▼M1
— SSR-Modus und -Code (optional),
— Flugstrecke (optional),— Bordausrüstung und Status (optional).
ANMERKUNG: Die Dateneinsatzregeln, Datenformate und
Feldinhalte sind in Anhang A aufgefü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,
— Übergabeflugfläche(n),— SSR-Code,— Bordausrüstung und Status.
7.3.3.1.3. 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;
— Übergabeflugfläche(n), SSR-Code oder Bordausrüstung und
Status sich in irgendeiner Weise geändert haben.
7.3.3.1.4. Sofern bilateral vereinbart, ist eine REV-Meldung zu senden,
wenn Änderungen erfolgten an:
— COP,
— Flugstrecke.
ANMERKUNG Operationelle Vorschriften verlangen möglicher-
weise, dass nach der ACT-Meldung
vorgenommene Änderungen zunächst der Koor-
dination 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 Überg-
abebedingungen durch die übernehmende
Flugverkehrskontrollstelle wird vorausgesetzt, sofern die überneh-
mende Flugverkehrskontrollstelle keine Koordination zur
Modifizierung dieser Bedingungen einleitet.
7.3.3.2. Formatierung von Revisionsmel dungen
7.3.3.2.1. I C A O-Format
Alle Revisionsmeldungen enthalten die Feldarten 3, 7, 13, 14 und
16. Dabei gelten folgende Regeln:
— Eine Änderung der ETO am COP oder der Übergabeflugflä-
che(n) muss durch Einfügen der revidierten Daten in Feld 14
erfolgen;
— eine Änderung des SSR-Codes ist in den Elementen b) und c)
in Feld 7 einzutragen.
Alle weiteren Änderungen sind im Datenformat von Feld 22 nach
den ersten fünf Feldern einzutragen. Dabei gelten folgende
Regeln:
— Im Datenformat von Feld 22 eingefügte Felder können in
beliebiger Reihenfolge zueinander stehen;
— Änderungen des COP sind in Feld 14 im Datenformat von
Feld 22 einzutragen (siehe Anhang B Besondere Anforde-
rungen an die Verarbeitung von Streckendaten);2000R2082 — DE — 15.06.2002 — 001.001 — 34
▼B
▼M1
▼B
▼M1
▼M1
— Streckenänderungen sind in Feld 15 im Datenformat von Feld
22 einzutragen. Die Vorschriften betreffs Koordination
solcher Änderungen einschließlich direkter Streckenführungen
sind in Anhang B Besondere Anforderungen an die Verarbei-
tung von Streckendaten festgelegt;
— Bordausrüstung und Status: Hier ist/sind nur die Ausrüs-
tung(en) anzugeben, für die sich eine Änderung ergeben hat.
Eine Meldung, die die Änderung einer Ausrüstung beinhaltet
und Daten über eine zusätzliche Ausrüstung gemäß Anhang A
Absatz A.30 erfordert, muss Angaben zu der zusätzlichen
Ausrüstung enthalten.
7.3.3.2.2. A D E X P-Format
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;
— das Primärfeld COP muss enthalten sein, es sei denn, eine
Änderung der ETO oder der Übergabeflugfläche(n) erfordert
die Verwendung des Primärfeldes COORDATA. Darin muss
der Koordinationspunkt beschrieben werden, durch den der
Flug gegenwärtig koordiniert wird, oder, im Fall einer
Änderung des COP, durch den er ursprünglich koordiniert
wurde;
— Änderungen des COP sind im Primärfeld COORDATA einzu-
tragen (siehe Anhang B Besondere Anforderungen an die
Verarbeitung von Streckendaten). Derartige Meldungen
müssen auch das Primärfeld COP enthalten (siehe oben);
— Streckenänderungen sind im Primärfeld ROUTE einzutragen.
Die Vorschriften betreffs Koordination solcher Änderungen
einschließlich direkter Streckenführungen sind in Anhang B
Besondere Anforderungen an die Verarbeitung von Strecken-
daten festgelegt;
— eine Änderung des SSR-Codes ist durch Einfügen des Primär-
felds SSRCODE anzuzeigen;
— eine Änderung bei Bordausrüstung und Status ist im Primär-
feld EQCST einzutragen, wobei nur die geänderte(n)
Ausrüstung(en) anzugeben ist/sind. Eine Meldung, die die
Änderung einer Ausrüstung beinhaltet und Daten über eine
zusätzliche Ausrüstung gemäß Anhang A Absatz A.30 erfor-
dert, muss Angaben zu der zusätzlichen Ausrüstung enthalten.
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 erfor-
derlich macht.
7.3.3.3. Verarbeitung bei der übernehmenden Stelle7.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 Übermittlung7.3.3.4.1. (NE) Die REV-Meldung ist ereignisabhängig und unmittelbar auf
die jeweilige Eingabe bzw. Aktualisierung folgend zu übermit-
teln.
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.2000R2082 — DE — 15.06.2002 — 001.001 — 35
▼B
▼B
7.3.3.4.3. Empfehlung Die REV-Parameter sollten für jeden COP geson-
dert definiert werden.
7.3.3.5. Wechsel der übernehmenden Fl ugverkehrskontroll-
stelle
(NE) Die REV-Meldung darf nicht verwendet werden, falls eine
Revision der Flugplandaten zu einem Wechsel der überneh-
menden 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 über-
mitteln;
— nicht mit einem Flugplan im empfangenden System assoziiert
werden kann, ist keine LAM-Meldung zu übermitteln.
7.3.4.2. Nichtbestätigung7.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. I C A O
a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
EGBB)
c) (REVE/L019-AMM253-LMML-BNE/1237F350-EGBB-81/W/
NO)
d) (REVBC/P873-BAF4486-EBMB-NEBUL/2201F250-LERT-
81/W/NO U/EQ)
7.3.5.2. A D E X P
a) TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COOR-
DATA -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
c) TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 019 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -BEGIN EQCST -EQPT W/NO -END
EQCST
d) TITLE REV -REFDATA -SENDER -FAC BC -RECVR -FAC
P -SEQNUM 873 -ARCID BAF4486 -ADEP EBMB -COP
NEBUL -ADES LERT -BEGIN EQCST -EQPT Y/NO -
EQPT U/EQ -END EQCST
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;2000R2082 — DE — 15.06.2002 — 001.001 — 36
▼M1
▼B
▼B
— Nummer der Meldung;
— Bezug der Meldung (optional);
— Luftfahrzeugkennung;— Startflugplatz;— Koordinationspunkt;
— Zielflugplatz;
— Koordinationsstatus und -grund (optional).
ANMERKUNG Die Dateneinsetzregeln, Datenformate und Feld-
inhalte 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 unter-
scheidet 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 aufge-
hoben, 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 abge-
henden 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 Koordina-
tionspartner, so steht
— als Status INI (Ausgangsstatus);
— als Grund einer von folgenden:
— TFL, falls der Grund eine Änderung der Übergab-
eflä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;2000R2082 — DE — 15.06.2002 — 001.001 — 37
▼B
— 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 Koor-
dination erfolgen,
— muss je nach Gegebenheit eine neue Benachrichtigungs- und/
oder Koordinationsmeldung gesendet werden;
— dürfen die grundlegenden Flugplandaten, die bei der überneh-
menden 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ätigung7.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ätigung7.4.4.2.1. (NE) Wird die ATC-Koordination abgebrochen und keine LAM-
Meldung empfangen, muss an der für die Koordination verant-
wortlichen 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 durchzu-
fü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 Luftfahr-
zeug wenige Minuten vor Erreichen des COP zum Flugplatz
Amsterdam zurück, und der Flugplan wird im System der absen-
denden Stelle aufgehoben; eine MAC wird an Maastricht2000R2082 — DE — 15.06.2002 — 001.001 — 38
▼B
gesendet wie in den Beispielen (7.4.5.1 b und 7.4.5.2 b) darge-
stellt.
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 aufeinanderfol-
genden 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 disk-
reter SSR-Codes zugewiesen werden. Derartige Zuweisungen
bedeuten allerdings einen verschwenderischen Umgang mit
Codes.
7.5.1.2. Die COD-Meldung erfüllt 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 Feld-
inhalte 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-Zuweisungsanforde-
rung 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.2000R2082 — DE — 15.06.2002 — 001.001 — 39
▼B
7.5.3.2. Verarbeitung bei der übernehmenden Stelle
7.5.3.2.1. (NE) Unter der Voraussetzung, dass die Meldung keine Diskre-
panz 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 asso-
ziieren 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 Hinde-
rungsgrund für die Rücksendung einer LAM sein, es sei denn,
sie entsprechen nicht den in Anhang A verzeichneten Anforde-
rungen 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 Übermitt-
lung 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 Koordina-
tionsprozess 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 Feld-
inhalte sind in Anhang A ausgeführt.2000R2082 — DE — 15.06.2002 — 001.001 — 40
▼B
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 Adres-
saten 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 absen-
denden 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, Weiter-
flug ü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 Kommuni-
kation und Verhandlung zwischen Lotsen in der
Koordinationsphase sowie für die Kommunikation in der Überg-
abephase bereit.
8.1.1.2. Dieser Abschnitt beschreibt Meldungen, die beim Dialogver-
fahren in der Koordinationsphase immer dann verwendet
werden, wenn Übergabebedingungen vorgesehen sind. Entspre-2000R2082 — DE — 15.06.2002 — 001.001 — 41
▼B
chende 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 Übereinstim-
mung steht oder nicht.
8.1.2.1.2. Der Prozess, der diese Übereinstimmung prüft, wird im vorlie-
genden 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 gesen-
dete 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 Stelle8.1.2.2.1. (NE) Das Filter in der übergebenden Stelle muss die zum bevor-
stehenden 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 Stelle8.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 ange-
nommen.2000R2082 — DE — 15.06.2002 — 001.001 — 42
▼B
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, Disk-
repanzen 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 normge-
rechte Übergabebedingungen erkannt, führt dies zu einer
Diskrepanz zwischen den beiden Filtern. Derartige Diskrepanzen
sollten im Sinne einer effizienten Abwicklung des Dialogverfah-
rens 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 überneh-
menden 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 Aktivi-
erungsmeldung (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. Allgemein8.1.4.1.1. (NE) Eine mit dem Austausch von Koordinations- oder Übergab-
emeldungen 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 gegebenen-
falls die telefonische Koordination wiedergibt.
8.1.6. Time-Out für operationelle Antworten
8.1.6.1. Allgemein8.1.6.1.1. (NE) Für die Antwort auf Meldungen, die an den Lotsen
verwiesen werden, muss bei den sendenden wie den überneh-
menden 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 veran-2000R2082 — DE — 15.06.2002 — 001.001 — 43
▼B
lassen, um auf die Notwendigkeit der Einleitung einer telefoni-
schen 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übergabe-
meldungen lediglich im ADEXP-Format.
8.1.7.2. Die HMI-Mindestanforderungen an den Koordinationsdialog
unterscheiden sich von den Anforderungen an den Übergab-
edialog dahingehend, dass
— der Übergabedialog in erster Linie auf die Führungskontroll-
funktion 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 Grenz-
passage 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 erfüllen,
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. Allgemein8.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.2000R2082 — DE — 15.06.2002 — 001.001 — 44
▼B
ANMERKUNG Treffen diese Voraussetzungen nicht zu, wird
eine RAP gesendet (siehe Absatz 8.3 „Verwie-
sener 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 Überein-
stimmung 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 Übergabebedin-
gungen 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 operatio-
nell 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 festge-
legten Anforderungen erfüllt 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 Überg-
abebedingungen 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).2000R2082 — DE — 15.06.2002 — 001.001 — 45
▼B
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 erfüllt:
— Das übergebende System hat festgestellt, dass die Übergab-
ebedingungen nicht normgerecht sind;
— der übergebende Lotse hat angezeigt, dass die vorgeschla-
genen Ü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 über-
mittelt 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 Verwei-
sung (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 überge-
benden Lotsen manuell eingeleitet und unmittelbar übermittelt.
8.3.3.3.2. Empfehlung An dem für die Koordination des Fluges verant-
wortlichen 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 entspre-
chen.
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 des2000R2082 — DE — 15.06.2002 — 001.001 — 46
▼B
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 überge-
benden Lotsen vorzulegen.
8.3.5.2. Gegenvorschlag
(NE) Entscheidet sich der übernehmende Lotse für einen Gegen-
vorschlag 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 erfüllen,
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 spezifi-
zierten Bedingungen für Flüge mit normgerechten
Übergabebedingungen zu senden, die der übergebende Lotse
nicht zur Annahme an den übernehmenden Lotsen verweisen
muss.2000R2082 — DE — 15.06.2002 — 001.001 — 47
▼B
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 Stelle8.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 normge-
rechte Ü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 über-
nehmenden Stelle üblicherweise angenommen. Erkennt das Filter
in der übernehmenden FS-Stelle die Übergabebedingungen als
nicht normgerecht, muss die Meldung als RRV-Meldung verar-
beitet werden.
8.5. Verwiesener Revisionsvorschlag (RRV)
8.5.1. Zweck der RRV-Meldung
(NE) Die RRV-Meldung muss in den folgenden Fällen zur Revi-
sion von zuvor versendeten und vereinbarten
Übergabebedingungen führen:
— wenn die in der Revisionsmeldung vorgeschlagenen Übergab-
ebedingungen nicht normgerecht sind;
— wenn die vorgeschlagene Revision zwar normgerecht ist, der
übergebende Lotse diese Revision jedoch an den überneh-
menden Lotsen verweisen möchte.2000R2082 — DE — 15.06.2002 — 001.001 — 48
▼B
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 vorgeschla-
genen Ü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 Verwei-
sung (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 Übergabebe-
dingungen, ist eine ACP-Meldung rückzusenden.
8.5.5.2. Gegenvorschlag
(NE) Entscheidet sich der übernehmende Lotse für einen Gegen-
vorschlag betreffs der Übergabebedingungen, muss eine CDN-
Meldung rückgesendet werden.
8.5.5.3. Ablehnung
(NE) Entscheidet sich der übernehmende Lotse dafür, die vorge-
schlagene Abänderung der vereinbarten Übergabebedingungen
abzulehnen,
— muss eine RJC-Meldung rückgesendet werden;2000R2082 — DE — 15.06.2002 — 001.001 — 49
▼B
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 Übergabebe-
dingungen 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 Feld-
inhalte sind in Anhang A ausgeführt.
8.6.3. Anwendungsregeln
8.6.3.1. Allgemein
(NE) Die SBY-Meldung muss automatisch generiert und übermit-
telt 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 erfüllt 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 ange-
nommen 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);2000R2082 — DE — 15.06.2002 — 001.001 — 50
▼B
— 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 Feld-
inhalte sind in Anhang A ausgeführt.
8.7.3. Anwendungsregeln
8.7.3.1. Allgemein8.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 Überg-
abebedingungen für beide Stellen verbindlich.
8.7.3.2. Verarbeitung bei der übernehmenden Stelle8.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ätigung8.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 verantwortli-
chen ATC-Platz eine Warnung angezeigt werden.2000R2082 — DE — 15.06.2002 — 001.001 — 51
▼B
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 erfüllt 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 überneh-
menden 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 Feld-
inhalte 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 überneh-
menden 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.2000R2082 — DE — 15.06.2002 — 001.001 — 52
▼B
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 gleich-
zeitig mit einer Meldung für denselben Flug von der
übergebenden Stelle, d. h. einer Revisions- oder Koordinationsab-
bruchmeldung, ü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 Stelle8.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 Disk-
repanz 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 vorgeschla-
genen Ü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 einge-
gangen 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 -2000R2082 — DE — 15.06.2002 — 001.001 — 53
▼B
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 Feld-
inhalte 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 überneh-
menden 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 Stelle8.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 3242000R2082 — DE — 15.06.2002 — 001.001 — 54
▼B
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über-
gabe 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 betref-
fende Stelle entweder die in Abschnitt 6 (Grundverfahren —
Obligatorische Meldungen) oder die in Abschnitt 8 (Dialogver-
fahren — 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 Bereit-
stellung im ICAO-Format ist nicht vorgesehen.
9.1.2. Meldungssequenz
9.1.2.1. (NE) Ein Austausch von Meldungen zur Kommunikationsüber-
gabe 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 betref-fenden 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 Kommuni-
kationsübernahme (MAS);
9.1.3.3. Die jeweilige Methode ist zwischen den beiden Stellen für jeden
Verkehrsfluss zu vereinbaren.
ANMERKUNG Für unterschiedliche Verkehrsflüsse 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 bestünde
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 überge-
benden 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;2000R2082 — DE — 15.06.2002 — 001.001 — 55
▼B
— 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 Feld-
inhalte 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üg-
baren Daten enthalten.
9.2.3.2. Zeitparameter für die Übermittlung9.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-Generierungspa-
rameter 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 überneh-
menden 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 Warnungangezeigt werden.
9.2.5. Beispiel
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM2532000R2082 — DE — 15.06.2002 — 001.001 — 56
▼B
9.3. Zusatzdatenmeldung (SDM)
9.3.1. Zweck der SDM-Meldung
9.3.1.1. Allgemein9.3.1.1.1. Vorrangig dient die SDM dazu, Kontrolldaten und daran vorgen-
ommene Ä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 Sprech-
funkfrequenz, 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 Feld-
inhalte sind in Anhang A ausgeführt.
9.3.3. Anwendungsregeln
9.3.3.1. Meldungen von der übergebenden Stelle9.3.3.1.1. (NE) SDM-Meldungen müssen nach Einleitung der Übergab-
ephase (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 beschrie-
benen 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 verein-
barten 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.2000R2082 — DE — 15.06.2002 — 001.001 — 57
▼B
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 über-
mittelt werden.
9.3.3.3. Verarbeitung bei der übernehmenden Stelle9.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 erforder-
lich 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 Verwen-
dung liegt im Ermessen des übergebenden Lotsen.
ANMERKUNG Mit Bezug auf vorstehenden Absatz c) wird zur
Weitergabe von Änderungen an die Führungs-
kontrolldaten, 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;2000R2082 — DE — 15.06.2002 — 001.001 — 58
▼B
— Zugewiesener Kurs bzw. Direktflug-Freigabe;
— Zugewiesene Geschwindigkeit;— Zugewiesene Steig-/Sinkgeschwindigkeit;
— Optionale Daten — Die Meldung kann außerdem enthalten:
— Position.
ANMERKUNG Die Dateneinsetzregeln, Datenformate und Feld-
inhalte sind in Anhang A ausgeführt.
9.4.3. Anwendungsregeln
9.4.3.1. Allgemein9.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 Übergabeeinlei-
tungsmeldung (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 Stelle9.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 Systemun-
terstützung zur Überwachung der Rückmeldung
der ROF (bzw. ACP); es wird davon ausge-
gangen, dass sich der übergebende Lotse des
Nichtvorliegens einer Antwort vom überneh-
menden Lotsen durchaus bewusst ist und die
erforderlichen Handlungen unternimmt. Diese
Norm schließt jedoch nicht aus, dass der über-
gebende 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 asso-
ziieren, 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 STJ2000R2082 — DE — 15.06.2002 — 001.001 — 59
▼B
9.5. Frequenzanforderungsmeldung (ROF)
9.5.1. Zweck der ROF-Meldung
Die ROF-Meldung wird erforderlichenfalls durch die überneh-
mende FS-Stelle an die übergebende Stelle gesendet, um den
übergebenden Lotse dazu aufzufordern, das Luftfahrzeug zum
Wechsel auf die Frequenz des übernehmenden Lotsen anzu-
weisen. 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 Feld-
inhalte 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 Flug2000R2082 — DE — 15.06.2002 — 001.001 — 60
▼B
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 verein-
barten Ü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 Feld-
inhalte sind in Anhang A ausgeführt.
9.6.3. Anwendungsregeln
9.6.3.1. Allgemein9.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 AMM2532000R2082 — DE — 15.06.2002 — 001.001 — 61
▼B
9.7. Manuelle Kommunikationsübernahme (MAS)
9.7.1. Zweck der MAS-Meldung
Die MAS wird durch die übernehmende FS-Stelle an die überge-
bende 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 Feld-
inhalte sind in Anhang A ausgeführt.
9.7.3. Anwendungsregeln
9.7.3.1. Allgemein9.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 Stelle9.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 erfor-
derlichenfalls eine Warnung angezeigt werden.
9.7.5. Beispiel
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — DE — 15.06.2002 — 001.001 — 62
▼B
ANHANG A (Normativ)
DATENEINSETZREGELN
INHALT
A.1. Zweck
A.2. Generische MeldungsformateA.3. Art der Meldung
A.4. Nummer der Meldung
A.5. Bezug der MeldungA.6. Luftfahrzeugkennung
A.7. SSR-Modus und -Code
A.8. StartflugplatzA.9. Schätzdaten
A.10. Koordinationspunkt
A.11. ZielflugplatzA.12. Luftfahrzeugmuster und -zahl
A.13. Flugstrecke
A.14. Sonstige FlugplandatenA.15. Koordinationsstatus und -grund
A.16. Zugewiesener Kurs (nur ADEXP)
A.17. Zugewiesene Geschwindigkeit (nur ADEXP)A.18. Zugewiesene Steig-/Sinkgeschwindigkeit (nur ADEXP)
A.19. Direktkurs-Freigabe (nur ADEXP)
A.20. Direktkurs-AnforderungA.21. Position (nur ADEXP)
A.22. Freigabeanzeige (nur ADEXP)
A.23. FrequenzA.24. Grund (nur ADEXP)
A.25. Freigabe-Flugfläche (nur ADEXP)
A.26. Übergabe-Flugfläche (nur ADEXP)A.27. Voraussichtliche Startzeit
A.28. Art der Bezugsmeldung
A.29. Art des Fluges
A.30. Bordausrüstung und Status
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.2000R2082 — DE — 15.06.2002 — 001.001 — 63
▼M1
▼B
▼B
A.2.2. Die Feldformate für ICAO-Meldungen sind in den Verfahren für
Flugnavigationsdienste — Luftverkehrsregeln und Flugverkehrs-
dienste (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.2.a Ist kein geeignetes ICAO-Feld vorhanden, so wird in manchen
Fällen eine ICAO-Feldart-Ersatznummer verwendet. Derartige
Ersatznummern sind zweistellig und größer oder gleich 80.
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.
ANMERKUNGEN1.In diesem Anhang sind nur die ADEXP-Primärdatenfelder aufge-
listet, 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über-
gabe“ 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 die2000R2082 — DE — 15.06.2002 — 001.001 — 64
▼M1
▼B
▼B
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 überneh-
mende Stelle die Antwort des Luftfahrzeugs am
Kontrollübergabepunkt erwarten kann;
oder
2. ein Indikator, der aussagt, dass der SSR-Code von der überneh-
menden 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.2000R2082 — DE — 15.06.2002 — 001.001 — 65
▼B
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 vorge-
schlagenen Übergabebedingungen übereinstimmen.
A.9.1.4. Empfehlung Im Falle von Steig- oder Sinkflug sollten die
Schätzdaten noch ergänzende Überflugdaten und Überflugbedin-
gungen 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 über-
nehmende Flugverkehrskontrollstelle zum Zwecke der
beabsichtigten Übergabe beziehen.
A.10.1.2. Der Koordinationspunkt muss entweder als ein bekannter Bezugs-
punkt, 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.2000R2082 — DE — 15.06.2002 — 001.001 — 66
▼B
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 Formationsflügen ist die Zahl der Luftfahr-
zeuge einzubeziehen.
A.12.1. ICAO
(NE) Feldart 9 im Format der Feldart 22. Element c) der Feldart 9
muss entweder die dem Luftfahrzeugmuster entsprechende Wirbe-
lschleppenkategorie 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 defi-
nierte Streckenbeschreibung, die als erstes Element die
Geschwindigkeit und die beantragte Flugfläche bzw. Informationen
zur Höhe über Grund erfordert. Die nach der Gruppe Geschwindig-
keit/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 signifi-
kanter 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. Dieses Feld ermöglicht es, in besonderen Meldungen Flugplandaten
anzuzeigen, die im Koordinationsverfahren normalerweise nicht
angegeben und an keiner anderen Stelle dieses Anhangs beschrieben
werden. Folgende Angaben (siehe Verweisdokument 1 Anhang 2
Feldarten 8 und 18) sind zulässig:
— Flugregeln,2000R2082 — DE — 15.06.2002 — 001.001 — 67
▼M1
▼M1
— Eintragsmarkierungen,
— Name des Halters,— Grund für Sonderbehandlung durch den ATS,
— Art,
— Leistung,— Name des Start-, Ziel- und Ausweichflugplatzes,— Anmerkungen in Klartext.
A.14.1. ICAO
Feldart 8, Element a) „Flugregeln“ im Format der Feldart 22.Eines oder mehrere der folgenden Elemente der Feldart 18 im
Datenformat von Feld 22:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Primärfelder: „fltrul“, „depz“, „destz“, „opr“, „per“, „reg“, „rmk“,
„altrnt1“, „altrnt2“, „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/Koor-
dination 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 festge-
legt enthalten.2000R2082 — DE — 15.06.2002 — 001.001 — 68
▼B
▼B
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, Mach-
zahl 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“ fest-
gelegt,
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“ fest-
gelegt.
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 verein-
bart, 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.2000R2082 — DE — 15.06.2002 — 001.001 — 69
▼B
(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 angesie-
delten 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, defi-
niert 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.2000R2082 — DE — 15.06.2002 — 001.001 — 70
▼B
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 Dezi-
malstelle 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“.
A.29. Art des Fluges
Dieses Element ist so wie im Flugplan anzugeben oder durch eine
gleichwertige Information aus anderer Quelle zu spezifizieren. Ist
die Art des Fluges im Flugplan nicht aufgeführt oder aus sonstigen
Gründen unbekannt, so ist der Buchstabe X einzufügen.
A.29.1. ICAO
Die Art des Fluges ist unter Verwendung der Feldart-Ersatznummer
80 als einzelner Buchstabe im Datenformat von Feld 22 anzugeben.
A.29.2. ADEXP
Primärfeld „flttyp“.
A.30. Bordausrüstung und Status
Dieses Element beschreibt Präsenz und Status von Bordausrüstung,
die entweder für den Verkehr in bestimmten Lufträumen oder auf
bestimmten Strecken unbedingt erforderlich ist oder die Durchfüh-
rung des Flugverkehrskontrolldienstes wesentlich beeinflusst. Eine
vorhandene Ausrüstung wird im Flugplan angezeigt, doch können
diese Angaben sich als unzutreffend erweisen oder sich während2000R2082 — DE — 15.06.2002 — 001.001 — 71
▼M1
▼M1
des Flugs Änderungen hierzu ergeben. Das Element „Bordausrü-
stung und Status“ zeigt den aktuellen Status an.
Der Status folgender Elemente ist anzugeben:
— RVSM,
— 8,33 kHz RTF.
Für Staatsflüge (gemäß der Angabe „Art des Fluges“ im Flugplan),
für die den Kenntnissen nach 8,33 kHz RTF nicht zur Verfügung
steht, ist der Status folgender Ausrüstung anzugeben:
— UHF.
A.30.1. ICAO
Die Daten sind unter Verwendung der Feldart-Ersatznummer 81 im
Datenformat von Feld 22 anzugeben.
Für jede Ausrüstung sind zwei Elemente einzufügen:
— die Ausrüstung als einzelner Buchstabe gemäß der Beschreibung
in Feldart 10 „Ausrüstung“ des ICAO-Flugplans (siehe Anhang
3 des Verweisdokuments 1), unmittelbar gefolgt von
— Trennzeichen-Schrägstrich (/), unmittelbar gefolgt von— Statusangabe durch zwei Buchstaben.
Die Statusangabe erfolgt je nach Flug unter Verwendung eines der
folgenden Indikatoren:
a) EQ Ausrüstung ist vorhanden und kann für den Flug genutzt
werden;
b) NO Ausrüstung ist nicht vorhanden oder kann für den Flug aus
irgendeinem Grund nicht genutzt werden;
c) UN keine Angabe zu dieser Ausrüstung.
Die erste Gruppe von Ausrüstungen ist unmittelbar nach dem auf
die Feldnummer folgenden Schrägstrich einzufügen. Die folgenden
Gruppen sind durch Leerzeichen voneinander zu trennen. Die
Reihenfolge der Ausrüstungen spielt keine Rolle.
A.30.2. ADEXP
Primärfeld „EQCST“.2000R2082 — DE — 15.06.2002 — 001.001 — 72
▼B
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 Strecken-
abschnitts 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 Modifizie-
rung 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 Koordi-
nation 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 Koordinati-
onspunkt (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 beschrie-
bene Format erhalten.
B.2.3. Flugumleitungen nach ABI- und vor ACT-Übermittlung
(NE) Es muss eine neue ABI-Meldung mit den neuen Strecken-
daten 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 bila-
teral 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 überneh-
mende 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.2000R2082 — DE — 15.06.2002 — 001.001 — 73
▼B
B.2.4.3. (NE) Meldungen im ICAO-Format müssen folgende Felder
enthalten:
3 Art und Nummer der Meldung; Bezug der Meldung, falls bila-
teral vereinbart;
7 Luftfahrzeugkennung. Die Elemente b und c dürfen nicht
einbezogen werden, es sei denn, dass gleichzeitig eine Revi-
sion 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überflugbe-
dingungen 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 umge-
leitet 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 weiter-
fliegt;
— 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-Meld ungen
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 B2000R2082 — DE — 15.06.2002 — 001.001 — 74
▼B
(PTB).
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-Mel dung
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
2000R2082 — DE — 15.06.2002 — 001.001 — 75
▼B
Anschließend wird der Flug von 40 NM westlich des Punktes RQA
direkt zu MYY geleitet. Der dem Grenzüberflug am nächsten gele-
gene 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)
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-Übermittlung2000R2082 — DE — 15.06.2002 — 001.001 — 76
▼B
B.4.2.1. ACT-Mel dung
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)
Im nachhinein wird der Flug über die ATS-Strecke UM247 inner-halb 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)
2000R2082 — DE — 15.06.2002 — 001.001 — 77
▼B
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)
B.4.2.2. Äquivalente Meld ungen 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 DTTA2000R2082 — DE — 15.06.2002 — 001.001 — 78
▼B
ANHANG C (Informativ)
PHASEN DES DIALOGVERFAHRENS (SYSCO-LEVEL 1) — MELDUNGSABFOLGE
Meldungsabfolge
2000R2082 — DE — 15.06.2002 — 001.001 — 79
▼B
ANHANG II
DARSTELLUNG DES DATENAUSTAUSCHS IN DER FLUGSICHE-
RUNG (ADEXP), AUSGABE 2.0
(Eurocontrol-Fundstelle DPS.ET1.ST09-STD)2000R2082 — DE — 15.06.2002 — 001.001 — 80
▼B
INHALTSVERZEICHNIS
URHEBERRECHTLICHER HINWEIS
VORWORT1. GELTUNGSBEREICH2. VERWEISE3. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN
3.1. Notation3.2. Definitionen3.3. Aufbau3.4. Konventionen3.5. Operatoren3.6. Abkürzungen
4. ADEXP-GRUNDSÄTZE
4.1. Vom Menschen lesbares Textformat4.2. Identifizierte und abrufbare Felder4.3. Nichterkannte Felder
5. ADEXP-SYNTAXREGELN
5.1. Lexikalische Elemente5.2. Felder
6. NORMIERTE BESCHREIBUNG VON ADEXP-NACHRICHTEN
6.1. Einleitung6.2. Hilfsterme6.3. Definition von Primärfeldern6.4. Definition von Teilfeldern6.5. Nachrichtengruppe
ANHANG A (NORMATIV) FELDDEFINITIONEN
ANHANG B (NORMATIV) ZENTRALES REGISTER DER ADEXP-NACHRICHTENTITELANHANG C (NORMATIV) ZENTRALES REGISTER DER RESERVIERTEN NACHRICHTEN-
TITEL
ANHANG D (NORMATIV) ZENTRALES REGISTER DER RESERVIERTEN FELDERANHANG E (INFORMATIV) VORSTELLUNG DER NACHRICHTENGRUPPENANHANG F (INFORMATIV) BEISPIELE FÜR DAS ADEXP-NACHRICHTENFORMATANHANG G (INFORMATIV) KÜNFTIGE ENTWICKLUNGEN2000R2082 — DE — 15.06.2002 — 001.001 — 81
▼B
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 Mitglied-
staaten somit frei zur Verfügung; jede Abschrift oder Offenlegung an
andere bedarf jedoch der vorherigen schriftlichen Einwilligung der Agentur
Eurocontrol.2000R2082 — DE — 15.06.2002 — 001.001 — 82
▼B
VORWORT
1. Verantwortliches Gremium
Für die Erarbeitung der vorliegenden Norm war die User Requi-
rements Section der Zentralen Verkehrsflussregelungsstelle
(CFMU) der Europäischen Organisation zur Sicherung der Luft-
fahrt (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-Datenverarbei-tungssysteme (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 Überar-
beitung. Das Verfahren für die Pflege dieser Norm ist in
Anhang H der Richtlinien für die einheitliche Erarbeitung undVorlage der Eurocontrol-Normungsdokumente festgelegt.
Änderungen oder Ergänzungen mit Auswirkung auf die Grund-
prinzipien oder die Grammatik des ADEXP-Formats dürfen nur
im Rahmen des formellen Überarbeitungsverfahrens vorgen-
ommen 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-Normungs-
dokumente, wobei es jedoch einige Abweichungen gibt. Mit den
geringen Abweichungen von den Richtlinien soll eine Verwechs-
lung 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 “ gekenn-
zeichnet ist.
6. Beziehung zu anderen Normendokumenten
Diese Norm ist verbunden mit:
Eurocontrol-Normendokument für den Online-Datenaustausch
(OLDI)2000R2082 — DE — 15.06.2002 — 001.001 — 83
▼B
7. Status der Anhänge zu dieser Norm
Diese Norm hat sechs Anhänge, deren Status folgendermaßen
festgelegt ist:
Anhang A Normativ
Anhang B NormativAnhang C NormativAnhang D NormativAnhang E InformativAnhang F InformativAnhang G Informativ.
8. Sprache
Der Originaltext dieser Norm ist in englischer Sprache verfasst.2000R2082 — DE — 15.06.2002 — 001.001 — 84
▼B
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 Syntaxre-
geln 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 Berei-
chen des Nachrichtenaustauschs spezifiziert (Informationen zu
Dokumentverweisen siehe Abschnitt 0, Seite 3):
— Flugplanung: Austausch von Flugplandaten und damit verbun-
denen Nachrichten zwischen dem Integrated Initial Flight
Plan Processing System (IFPS), Verkehrsdiensten der Flugsi-
cherung (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 Flugverkehrs-
kontrollstellen (ATCU). (Dokumentverweis 6)
— Luftraummanagement: Austausch von Daten über die Verfüg-
barkeit 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-Normen-
dokuments waren die für die Verweisdokumente und -normen
angegebenen Ausgaben gültig.
Jede Überarbeitung der Verweisdokumente der Internationalen
Zivilluftfahrt-Organisation (ICAO) gilt unmittelbar als Überarbei-
tung dieses Eurocontrol-Normendokuments.
Überarbeitungen der anderen Verweisdokumente werden erst zum
Bestandteil der Bestimmungen dieses Eurocontrol-Normendoku-
ments, wenn sie formal überprüft und in dieses Eurocontrol-
Normendokument eingearbeitet worden sind.
Bei Widersprüchen zwischen den Anforderungen dieses Eurocon-
trol-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);2000R2082 — DE — 15.06.2002 — 001.001 — 85
▼B
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 Nachrichten-
menge, 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
ANMERKUNGEN1)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 gefolgtvon c) oder nur durch b ersetzt werden kann.
—Nichtterminale Symbole (z. B. die linke Seite einer grammati-
schen Produktionsregel) werden in Kleinbuchstaben
geschrieben.2000R2082 — DE — 15.06.2002 — 001.001 — 86
▼B
— In den Regeln erscheinende Zeichen und Kettenliterale
werden zwischen einfache (') bzw. doppelte Anführungszei-
chen (") 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
z. B. ”-DCT NTM RMS”.
ANMERKUNGEN
1)(NE) Eine Verkettung hat stets Vorrang vor der Auswahlmög-
lichkeit. Zur Änderung der Auswertungsreihenfolge des
Ausdrucks werden runde Klammern „(“ und „)“ verwendet.
Beispiel a::= B C | D entspricht: a::= (B C) | D
entspricht
NICHT:a::= B (C | D)2000R2082 — DE — 15.06.2002 — 001.001 — 87
▼B
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 obenge-
nannten Operatoren unklar, sollten zur Klarstellung der
gewünschten Auswertungsreihenfolge runde Klammern gesetzt
werden.
3.6. Abkürzungen
(NE) Im Sinne dieses Eurocontrol-Normdokuments gelten
folgende Abkürzungen:
ACH ATC Flight Plan Amendment Message
ADEG ATS Data Exchange Group
ADEXP ATS Data Exchange PresentationAFIL Air-Filed Flight PlanAFP ATC Flight Plan ProposalAFTN Aeronautical Fixed Telecommunication NetworkANM ATFM Notification MessageAO Aircraft Operator(s)APL ATC Flight PlanATC Air Traffic ControlATCU Air Traffic Control Unit(s)
ATFM Air Traffic Flow Management
ATS Air Traffic Services
BNF Backus Naur FormCASA Computer Assisted Slot Allocation
CIDIN Common ICAO Data Interchange Network
CFL Cleared Flight Level
CFMU Central Flow Management UnitCMTP Common Medium-Term PlanCNL Cancellation MessageCTOT Calculated Take-Off Time
DPS Data Processing Systems Domain
ECAC European Civil Aviation Conference
EFL Estimated Flight LevelEOBT Estimated Off-Block TimeETO Estimated Time OverEurocontrol European Organisation for the Safety of Air Navi-
gation
EWPD EATCHIP Work Programme Document
FIR Flight Information Region
FIW Flight Plan Input WorkstationFMP Flow Management PositionFNM Flight Notification MessageFPL Flight Plan Message (ICAO format)
GAT General Air Traffic
IA International Alphabet
IAFP Individual ATC Flight Plan ProposalICAO International Civil Aviation OrganisationIFPD Individual Flight Plan DataIFPS Integrated Initial Flight Plan Processing System
IFPU IFPS Unit
IFR Instrument Flight RulesISO International Standards OrganisationITA International Telegraph Alphabet
LAM Logical Acknowledgement Message
LRM Logical Rejection Message
MAC Co-ordination Abrogation Message
MFS Message from Shanwick
OAT Operational Air Traffic2000R2082 — DE — 15.06.2002 — 001.001 — 88
▼B
OLDI On-Line Data Interchange
RFL Requested Flight Level
RFP Replacement Flight PlanRFPD Repetitive Flight Plan DataRPL Repetitive Flight Plan
RVR Runway Visual Range
SFL Supplementary Flight Level
SRD Software Requirements DocumentSSR Secondary Surveillance Radar
TACT Tactical System of the CFMU
TOS Traffic Orientation Scheme
UIR Upper Information RegionVFR Visual Flight Rules
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 lexi-
kalische 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 Bestim-
mung 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.2000R2082 — DE — 15.06.2002 — 001.001 — 89
▼B
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 Teil-
feldern wiederholt auftreten. Die Reihenfolge, in der dies
innerhalb eines Listenfeldes geschieht, ist semantisch von Bedeu-
tung.
4.2.13. Im folgenden wird der Begriff „Feld“ in übergreifender Bedeu-
tung 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üs-
selwort 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 Schnittstellenan-
forderungen 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 fest-
gelegt 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 Mehrdeu-
tigkeit 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 RTEPTSwobei „-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).2000R2082 — DE — 15.06.2002 — 001.001 — 90
▼B
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 Interna-
tional 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 Rechner-
netzen 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 Telegraphenal-
phabet 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 | FEF2000R2082 — DE — 15.06.2002 — 001.001 — 91
▼B
— 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 Formatsteuerzei-
chen sein.
5.1.3.3. (NE) Felder werden nur durch das Vorhandensein eines Feldan-
fangszeichens, 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 gekenn-
zeichnet 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. Einnicht 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 Vorzei-
chen“ 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 entspre-
chenden Teilfeld(ern) oder dem enthaltenen Wert (contained
value).
ANMERKUNG Es sei darauf hingewiesen, dass ein Schlüssel-
wort 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 IFPL2000R2082 — DE — 15.06.2002 — 001.001 — 92
▼B
3) - TITLE IFPL
4) -
TITLE IFPL
5.1.5.3. Empfehlung Es empfiehlt sich, Trennzeichen zwischen dem Feld-
anfangszeichen „-“ und dem darauffolgenden Schlüsselwort zu
vermeiden.
ANMERKUNG1) Von den obigen Beispielen wird die erste Verwendungsart
empfohlen.
2) Zu beachten ist ferner, dass unmittelbar nach einem Schlüssel-
wort 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. (NE) Die nachfolgend aufgeführten vorgegebenen Schlüs-
selwörter des ADEXP-Formats dürfen nicht neudefiniert oder
bei spezifischer Nutzung des Formats mit einer anderen Aufgabe
verwendet werden:
TITLE: kennzeichnet eine Nachrichtenkategorie und
definiert die dazugehörige Menge zulässiger
Primärfelder;
BEGIN: kennzeichnet den Anfang eines Listenfelds;END: kennzeichnet das Ende eines Listenfelds;
COMMENT: kennzeichnet ein Anmerkungsfeld.
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 Bedeu-
tung) 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 Teil-
felder (d. h. Teilschlüsselwörter) geführt.
5.2. Felder
5.2.1. Feldsyntax
field::= basic_field | structured_field | list_fieldbasic_field::= '-' keyword contained_valuescontained_values::= {CHARACTER}
list_field::= '-' ”BEGIN” keyword {subfields} '-' ”END” keyword
structured_field::= '-' keyword field_1 field_2 ….field_nANMERKUNG 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 einge-
leitet 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;2000R2082 — DE — 15.06.2002 — 001.001 — 93
▼B
— 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 inner-
halb 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 einzu-
schließ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 Teilfel-
dern 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”
ANMERKUNG1) 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 Teil-
feldern:
xxx::= '-' ”BEGIN” ”XXX” { yyy | zzz } '-' ”END” ”XXX”.
5.2.5. Strukturierte Felder
5.2.5.1. (NE) Die Syntax von strukturierten Feldern lautet folgender-
maß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]
ANMERKUNGEN1) 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).2000R2082 — DE — 15.06.2002 — 001.001 — 94
▼B
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 Erwei-
terungsmö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-NACH-
RICHTEN
6.1. Einleitung
6.1.1. In den folgenden Absätzen ist festgelegt, wie das ADEXP-Format
unterschiedlicher Nachrichtenkategorien im Rahmen der vorlie-
genden Norm normiert beschrieben werden muss.
6.1.2. Zur normierten Beschreibung gehören:
— Definition von Hilfstermen;
— Definition von Syntax und Semantik der einzelnen Primär-
felder;
— 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 Daten-
einsetzungsregeln für die einzelnen Nachrichtentitel.
6.1.4. Es sollte auf die Definitionsdokumente (Schnittstellenspezifika-
tion) 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 Feststel-
lung eines nichterkannten Feldes.
6.1.6. Die für alle Eurocontrol-Mitgliedstaaten derzeit festgelegten und
abgestimmten Felder zur Verwendung innerhalb der verschie-
denen 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 semanti-
schen Beschreibung angegebenen Zweck verwendet werden.
6.1.8. Ein zentrales Register der reservierten Felder findet sich in
Anhang D. „Reservierte Felder“ sind zur Verwendung innerhalb2000R2082 — DE — 15.06.2002 — 001.001 — 95
▼B
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 Einheit-
lichkeit 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. Die Beschreibung lässt sich alphabetisch geordnet in einer Tabelle wie folgt darstellen:
Hilfsterm Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
TeilfeldVerw-
endung
in
Hilfs-
term
adexpmsg { CHARACTER } Frei wählbarer
Text entspre-
chend der für
eine ADEXP-
Nachricht fest-
gelegten
Syntax.ifpdlong
rfpdlong
preproctxtpostproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeFunk-, Naviga-
tions- und
Anflughilfeaus-
rüstung.ceqpt
aircraftid 1{ ALPHANUM
}7Luftfahrzeug-
kennung.arcid
arcidkarcidold
prevarcid
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 einfa-
chen 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. Die Beschreibung lässt sich alphabetisch geordnet in einer Tabelle wie folgt darstellen,
wobei
— die erste Spalte den linken Teil einer BNF-Regel (d. h. den Teil der Regel links des
Symbols „::=“) und die dritte Spalte den rechten Teil darstellt,
— die zweite Spalte (Art) angibt, ob es sich um ein Basisfeld („b“) oder ein Verbund-
feld („c“) handelt.
Primärfeld Art Syntax Semantik
eobt b '-' ”EOBT” timehhmm Voraussichtliche Off-Block-
Zeit2000R2082 — DE — 15.06.2002 — 001.001 — 96
▼B
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. Die Beschreibung lässt sich alphabetisch geordnet in einer Tabelle wie folgt darstellen:
Teilfeld Art Syntax SemantikVerwendung
in PrimärfeldVerwe-
ndung
in Teil-
feld
brng b '-' ”BRNG”
refbearingPeilung eines
Punktes aus einer
Navigationshilfe
(in Magnetgrad)ref
6.5. Nachrichtengruppe
6.5.1. Die Nutzungskategorien (Gruppen) von Nachrichten, die zur
Verwendung mit dem ADEXP-Format festgelegt wurden, werdenin 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 Titel-
wert 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 Nachrichten-
gruppe.
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-Nachrich-
tengruppen 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.2000R2082 — DE — 15.06.2002 — 001.001 — 97
▼B
ANHANG A (Normativ)
ADEXP-FELDDEFINITIONEN
A.1.Einleitung
In diesem Anhang sind alle Felder — Hilfsterme, Primärfelder und Teil-
felder — aufgeführt, die zur Verwendung in ADEXP definiert worden
sind.
A.2.ADEXP-Hilfsterme
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
adexpmsg { CHARACTER } Frei wählbarer Text
entsprechend der für
eine ADEXP-Nach-
richt festgelegten
Syntax.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeFunk-, Navigations-
und Anflughilfeaus-
rüstung.ceqpt
aircraftid 1{ ALPHANUM }7 Luftfahrzeugken-
nung.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Platzhalterform von
aircraftid zur
Verwendung in
Anfragemeldungen:
„?“ ersetzt 1
Zeichen
„+“ ersetzt eine
beliebige Anzahl
von Zeichen.arcidk
atsroute 2 {ALPHANUM} 7 Kennung einer
ATS-Strecke.atsrt refatsrte
century 2{DIGIT}2 Die ersten beiden
Ziffern einer Jahres-
angabe.fulldate
coorstatusident 3 {ALPHA} 3 Indikator für den
Koordinationsstatus
eines Fluges.statid
coorstatus-
reason3 {ALPHA} 7 Grund für die
Meldung einer
Veränderung des
Koordinationsstatus.statreas-
on
country 2{ALPHA}2 Die aus zwei Buch-
staben bestehende
ICAO-Länderken-
nung.refatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4ICAO-Kennung für
die Datalink-Fähig-
keit.
Kann folgende
Werte enthalten: S,
H, V oder M in
jeder beliebigen
Reihenfolge, aber
ohne Wiederholung.dat2000R2082 — DE — 15.06.2002 — 001.001 — 98
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
date year ! month ! day Datumsangabe im
Format JJMMTT.
z. B. 930424 = 24.
April 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm „date“-Term wie
oben beschrieben
und unmittelbar
gefolgt von der
Uhrzeit im Format
HHMM.
z. B.
9304240930 = 09.30
Uhr am 24. April
1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6„date“-Term, dem
ein Platzhalter
zugewiesen werdenkann.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITZweistellige Zahl,
die die Ziffern von
00 bis 31 enthalten
kann.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indikator für den
Typ der an Bord
des Luftfahrzeugs
befindlichen
Notfunkausrüstung,
bestehend aus
einem oder
mehreren der defi-
nierten Zeichen in
jeder beliebigen
Reihenfolge, aber
ohne Wiederholung.splr
equipmentcode 1 {(‘A' | 'B' | 'C' | 'D'
| 'E' | 'F' | 'G' | 'H' |
'I' | 'J' | 'K' | 'L' | 'M'
| 'O' | 'P' | 'Q' | 'R' |
'T' | 'U' | 'V' | 'W' |
'X' | 'Y' | 'Z' )} 24Gültiger ICAO-
Codebuchstabe zur
Angabe der an Bord
befindlichen Ausrü-
stung, bestehend aus
einem oder
mehreren der defi-
nierten Zeichen in
jeder beliebigen
Reihenfolge, aber
ohne Wiederholung.aidequip-
ment2000R2082 — DE — 15.06.2002 — 001.001 — 99
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
eqptcode 1 {ALPHANUM} 2 Angabe der an Bord
befindlichen Ausrü-
stung; ggf. identisch
mit „equipment-
code“eqpt
eqptstatus 2 {ALPHA} 2 Zwei Buchstaben
zur Angabe des
Status der Bordau-
srüstungeqpt
errorcode 1{DIGIT}4 Fehlermeldungs-
code-Nummer.error
fieldid 1{ ALPHANUM } Gültiger ADEXP-
Feldname (d. h.
Schlüsselwort).errfield
ifpsmod
firindicator 4{ ALPHA }4 ICAO-Kennung für
ein FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT }4Flugfläche, ausge-
drückt als:
„F“ oder „A“,
gefolgt von drei
Ziffern oder
„S“ oder „M“,
gefolgt von vier
Ziffern.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'Grund für Sonder-
behandlung nach
Angabe in Feld 18
„STS/“.
EMER = Notfall
HUM = Huma-
nitärer Flug
HOSP = Sanitäts-
flug
SAR = Such- und
Rettungsdienst
HEAD = Staats-
oberhaupt
STATE = Staatsflugsts
flightrule 'I' | 'V' | 'Y' | 'Z' Flugregelangabe
eines Fluges.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Art des Fluges nach
Angabe der verwen-
deten ICAO-
Kennung.flttyp
flighttypechg 'OAT' | 'GAT' Angabe einer
Änderung der Art
des Fluges in der
Flugstrecke auf
„OAT“ oder
„GAT“.chgrul ptrulchg
fulldate century ! year !
month ! dayDatumsangabe im
Format JJJJMMTT
z. B. 19970801 = 1.
Aug. 1997fulldate-
time
fulldatetime fulldate ! timehhmm Datum wie in „full-
date“ beschrieben
und direkt gefolgt
von der Uhrzeit im
Format HHMM.
z. B.
199708010930=09.-
30 Uhr am 1. Aug.
1997mesval-
period2000R2082 — DE — 15.06.2002 — 001.001 — 100
▼M1
▼B
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
geoname "GEO" !
2{DIGIT}2Kennung für eine
geographischen
Position in geogra-
phischer Breite und
Länge.geoid
heading 3{DIGIT}3 Kurs als dreistellige
Zahl im Bereich
001 bis 360.ahead
icaoaerodrome 4{ ALPHA }4 ICAO-Flugplatzken-
nung mit vier Buch-
staben.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Platzhalterform von
icaoaerodrome zur
Verwendung in
Anfragenachrichten:
„?“ ersetzt 1
Zeichen
„+“ ersetzt eine
beliebige Anzahl
von Zeichen.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3ICAO-Kennung für
ein Luftfahrzeug-
muster.arctyp
icaomsg { CHARACTER } ICAO-Nachricht.
(entspricht der in
Verweisdokument
{4} beschriebenen
Syntax)msgtxt
ifpuid 1{ ALPHANUM } Kennung für eine
IFPS-Stelle.ifpuresp
latitudelong 6{ DIGIT }6 Geographische
Breite, sechsstellig.lattd
latitudeside 'N' | 'S' Indikator für
„nördliche“ und
„südliche“ Breite.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4ICAO-Indikator für
den an Bord befind-
lichen Schwimm-
westentyp,
bestehend aus
einem oder
mehreren der defi-
nierten Zeichen in
jeder beliebigen
Reihenfolge, aber
ohne Wiederholung.splj
longitudelong 7{ DIGIT }7 Geographische
Länge, siebenstellig.longtd
longitudeside 'E' | 'W' Indikator für
„östliche“ oder
„westliche“ Länge.longtd
machnumber 'M' ! 3{ DIGIT }3 Mach-Zahl. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Angabe der Art der
an einem Feld
vorgenommenen
Änderung.ifpsmod2000R2082 — DE — 15.06.2002 — 001.001 — 101
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
month ('0' | '1' ) ! DIGIT Monat als zweistel-
lige Zahl.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Angabe der
Wochentage, an
denen ein RPL aktiv
ist.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Angabe der
Wochentage, an
denen ein RPL aktiv
ist. Auch Platzhal-
terzeichen können
verwendet werden.daysk
originatorid 1{ ALPHANUM
}10Kennung des
Abfassers einer
Nachricht.orgnid
qrorgn
point 2{ ALPHANUM }5 Kennung eines
signifikanten
Punktes. Kann ein
veröffentlichter
Punkt, ein geogra-
phischer Ort, ein
Bezugspunkt oder
ein künstlich ange-
gebener Punkt, z. B.
ein „umbenannter“
Punkt (RENxx)
sein.atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Peilrichtungsbezugs-
wert.brng
refname "REF" ! 2{DIGIT}2 Kennung eines
Punktes als Peilung
und Entfernung von
einem verö-
ffentlichten Punkt.refid
regulid 1{ ALPHANUM
}20Kennung einer
ATFM-Regelungs-
maßnahme für einen
Flug.regul regid
renameid "REN" !
2{DIGIT}2Kennung eines
umbenannten
Punktes.renid
rrteid 1{ ALPHANUM}
20Kennung einer
Umleitung.rrteref
rtf 6{DIGIT}6 Funkfrequenz in
MHz mit drei Dezi-
malstellen.freq
rulechg ‘VFR' | 'IFR' Auf einer Flug-
strecke verwendete
Indikatoren zurAngabe eines Flug-
regelwechsels.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSekunden.
Zweistellig von
„00“ bis „59“.eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Geschwindigkeit.
Ausgedrückt als
„K“ oder „N“,
gefolgt von vier
Ziffern.aspeed
speedcrspeed
ptspeed2000R2082 — DE — 15.06.2002 — 001.001 — 102
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
ssrequipment 1 {ALPHA} 2 ICAO-Kennung der
an Bord befindli-
chen SSR-Ausrü-
stung und optional
Angabe einer Data-
link-Fähigkeit.seqpt
stayidentifier ‘STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Kennung einer
„Verweildauer“,
eines Zeitraums mit
„besonderer Akti-
vität“ innerhalb der
Strecke eines
Fluges.ptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4ICAO-Kennung der
an Bord befindli-
chen Rettungsausrü-
stung,
bestehend aus
einem oder
mehreren der defi-
nierten Zeichen in
jeder beliebigen
Reihenfolge, aber
ohne Wiederholung.spls
text20 1{ LIM_CHAR }20 Text aus 1 bis 20
Zeichen mit
Ausnahme des
Bindestrichs.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITZeit in Stunden (2
Ziffern 00-23) und
Minuten (2 Ziffern
00-59). Kann eine
Uhrzeit oder Zeit-
dauer sein.aobt
ata
atd
atot
cobt
ctot
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitimecto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_el-
apsedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITUnbegrenzte Anzahl
von Stunden und
Minuten bei Zeit-
dauerangaben.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Platzhalterform von
timehhmm.eobtk
titleid 1{ ALPHA }10 Gültiger ADEXP
Nachrichtentitel.
(siehe Anhang B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' ICAO-Kennung für
eine Wirbelschlep-
penkategorie.wktrc2000R2082 — DE — 15.06.2002 — 001.001 — 103
▼B
Hilfsterm Syntax SemantikVerwen-
dung in
Primär-
feldVerwen-
dung in
TeilfeldVerwen-
dung in
Hilfsterm
year 2{ DIGIT }2 Die beiden letzten
Ziffern einer Jahres-
angabe.date
fulldate
A.3.ADEXP-Primärfelder
ADEXP-
PrimärfeldArt Syntax Semantik
ad c '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Flugplatzkennung. Ist der Flugplatz
Bestandteil der Streckenbeschrei-
bung, können zusätzliche Strecken-
informationen angegeben werden.
ada b '-' "ADA" date Tatsächliches Ankunftsdatum.
adarr b -' “ADARR” (icaoaerodrome |
'ZZZZ')Tatsächlicher Landeflugplatz.
adarrz b '-' "ADARRZ" text20 Name des tatsächlichen Landeflug-
platzes, sofern keine ICAO-Orts-
kennung existiert.
add b '-' "ADD" date Tatsächliches Abflugdatum.
addr c '- "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Adressatenliste.
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')ICAO-Ortskennung des Startflug-
platzes oder die Angabe „AFIL“
(während des Fluges aufgegebener
Flugplan) bzw. „ZZZZ“, wenn dem
Startflugplatz keine ICAO-Ortsken-
nung zugewiesen ist.
adepk b '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Startflugplatz als Datenbank-
schlüssel in einer Anfrage; Platz-
halter möglich.
Kann eine ICAO-Ortskennung oder
die Angabe „AFIL“ (während des
Fluges aufgegebener Flugplan)
bzw. „ZZZZ“, wenn dem Startflug-
platz keine ICAO-Ortskennung
zugewiesen ist, oder eine Kombi-
nation aus Buchstaben und Platz-
halterzeichen enthalten.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ'),,Vorheriger,, Startflugplatz. Kann
die ICAO-Ortskennung des Start-
flugplatzes oder die Angabe
„AFIL“ (während des Fluges
aufgegebener Flugplan) bzw.
„ZZZZ“ enthalten, wenn dem
Startflugplatz keine ICAO-Ortsken-
nung zugewiesen ist.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')ICAO-Ortskennung des Zielflug-
platzes oder „ZZZZ“, wenn dem
Zielflugplatz keine ICAO-Ortsken-
nung zugewiesen ist.
adesk b '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Zielflugplatz als Datenbank-
schlüssel in einer Anfrage; Platz-
halter möglich.
Kann eine ICAO-Ortskennung oder
die Angabe „ZZZZ“, wenn dem
Zielflugplatz keine ICAO-Ortsken-
nung zugewiesen ist, oder eine
Kombination aus Buchstaben und
Platzhalterzeichen enthalten.2000R2082 — DE — 15.06.2002 — 001.001 — 104
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
adesold b '-' "ADESOLD" (icaoaerodrome |
‘ZZZZ')„Vorheriger“ Zielflugplatz. Kann
die ICAO-Ortskennung oder die
Angabe „ZZZZ“ enthalten, wenn
dem Zielflugplatz keine ICAO-
Ortskennung zugewiesen ist.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Enthält eine ADEXP-Nachricht.
afildata c '-' "AFILDATA" ptid fl eto Schätzdaten für einen während des
Fluges aufgegebenen Flugplan.
Eine Punktkennung, die Eintritts-
flugfläche und voraussichtliche(s)
Datum-Zeit am Punkt.
ANMERKUNG: Bei der angege-
benen Flugfläche handelt es sich
um die Fläche, auf der der Einflug
eines Fluges in den kontrollierten
Luftraum über dem angegebenen
Punkt freigegeben worden ist. Sie
muss nicht mit der RFL überein-
stimmen.
ahead b '-' "AHEAD" (heading | "ZZZ") Der einem Flug zugewiesene Kurs
in Grad.
Muss eine dreistellige Zahl oder
der Wert „ZZZ“ sein, der angibt,
dass kein Kurs zugewiesen ist.
altnz b '-' "ALTNZ" text20 Name des Ausweichflugplatzes,
sofern keine ICAO-Ortskennung
existiert.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
‘ZZZZ')ICAO-Ortskennung des ersten
Ausweichzielflugplatzes oder die
Angabe „ZZZZ“, wenn dem Flug-
platz keine ICAO-Ortskennung
zugewiesen worden ist.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
‘ZZZZ')ICAO-Ortskennung des zweiten
Ausweichzielflugplatzes oder die
Angabe „ZZZZ“, wenn dem Flug-
platz keine ICAO-Ortskennung
zugewiesen worden ist.
aobd b '-' "AOBD" date Tatsächliches Off-Block-Datum.
aobt b '-' "AOBT" timehhmm Tatsächliche Off-Block-Zeit.
arcid b '-' "ARCID" aircraftid Luftfahrzeugkennung.
Eintragungszeichen des Luftfahr-
zeugs, oder die ICAO-Kennung des
Luftfahrzeughalters, gefolgt von
der Flugkennung.
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Luftfahrzeugkennung als Daten-
bankschlüssel in einer Anfrage;
Platzhalter möglich.
Muss eine Kombination aus alpha-
numerischen und Platzhalterzeichen
mit maximal insgesamt 7 Zeichen
sein.
arcidold b '-' ARCIDOLD aircraftid „Vorherige“ Luftfahrzeugkennung.
Soll die Luftfahrzeugkennung
geändert werden, wird der neue
Wert in "ARCID" angegeben.
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Luftfahrzeugmuster (ICAO-
Typkennung) oder ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")Derzeit zugewiesene Flugge-
schwindigkeit in Kilometer pro
Stunde, Knoten oder Mach-Zahl in
folgender Form:
„M“ gefolgt von drei Ziffern, „K“
oder „N“ gefolgt von vier Ziffern
oder „ZZZ“ als Hinweis darauf,
dass keine Geschwindigkeitsbe-
schränkung zugewiesen ist.2000R2082 — DE — 15.06.2002 — 001.001 — 105
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
ata b '-' "ATA" timehhmm Tatsächliche Ankunftszeit.
atd b '-' "ATD" timehhmm Tatsächliche Abflugzeit.
atot b '-' "ATOT" timehhmm Tatsächliche Startzeit.
atsrt b '-' "ATSRT" atsroute point point ATS-Streckenkennung und
Kennung des ersten und letzten
Punktes.
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Adressen, an die ATFM-Nach-
richten gerichtet werden sollten.
ceqpt b '-' "CEQPT" aidequipment Funk-, Navigations- und Anflughil-
feausrüstung (wie ICAO-Feld 10).
cfl c '-' "CFL" fl [ptid] Freigegebene Flugfläche. Die dem
Piloten von der Flugverkehrskon-
trolle derzeit zugewiesene
Flugfläche (Flugflächennummer).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointAngabe eines Wechsels der „Flug-
regeln“ (VFR/IFR) oder der „Art
des Fluges“ (OAT/GAT) oder
beides sowie des Punktes, an dem
der Wechsel eintritt.
cobd b '-' "COBD" date Errechnetes Off-Block-Datum.
cobt b '-' "COBT" timehhmm Errechnete Off-Block-Zeit.
com b '-' "COM" text20 Kommunikationsausrüstung (wie
ICAO-Feld 18 COM/).
comment b '-' "COMMENT" 1 { LIM_CHAR
}Allgemeiner Kommentar in frei
wählbarem Text ohne Bindestrich.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Kennung einer ‘außergewöhnlichen
Bedingung' im Zusammenhang mit
ATFM.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]Die Übergabebedingungen eines
Fluges. Eine Punktkennung, die
Flugfläche und voraussichtliche
Zeit an diesem Punkt sowie optio-
nale Angabe der ergänzenden
Flugfläche.
cop b '-' "COP" point Koordinationspunktkennung.
Entweder eine codierte Punktken-
nung oder ein künstlich vergebener
Name (GEOxx, RENxx oder
REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Reiseflugsteigen. Punkt, an dem
der Steigflug beginnen wird,
Geschwindigkeit oder Mach-Zahl
sowie die beiden Flächen mit
Angabe des während des Steig-
fluges belegten Höhenbandes. Ist
die obere Fläche unbekannt, kann
die zweite Fläche „PLUS“ sein.
cstat c '-' "CSTAT" statid [statreason] Angabe zur Bestätigung des neuen
Koordinationsstatus eines Fluges
sowie optional Angabe des
Änderungsgrundes.
ctod b '-' "CTOD" date Errechnetes Startdatum.
ctot b '-' "CTOT" timehhmm Errechnete Startzeit (CTOT):
Bezugszeit für einen ATFM-Slot.
dat b '-' "DAT" datalink Angabe der an Bord befindlichen
Datalink-Fähigkeit.
days b '-' "DAYS" numdays Betriebstage eines Dauerflugplans
(1234567, und zwar 1 für Montag,
2 für Dienstag, …, und 0 in
verkehrslosen Spalten).2000R2082 — DE — 15.06.2002 — 001.001 — 106
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Betriebstage eines Dauerflugplans
zur Verwendung als Datenbank-
schlüssel in einer Anfragenachricht;
Platzhalter möglich.
daysold b '-' "DAYSOLD" numdays „Vorherige“ Betriebstage zur
Verwendung als Datenbank-
schlüssel. Sollen die Betriebstage
eines RPL geändert werden, erfolgt
die Angabe der neuen Werte in
„DAYS“.
dct b '-' "DCT" point point Gibt eine direkte Strecke zwischen
zwei Punkten an.
Die Punkte können entweder eine
gültige ICAO-Punktkennung oder
ein Punkt sein, der in einem GEO-,
REN- oder REF-Feld der Form
GEOxx, RENxx oder REFxx
erscheint.
delay b '-' "DELAY" timehhmm Zeitraum, der eine Verzögerung
bzw. Verspätung darstellt. Die Art
der Verzögerung, d. h. Flugverspä-
tung, Bearbeitungsverzögerung
usw., hängt vom Kontext ab.
depz b '-' "DEPZ" text20 Name des Startflugplatzes, wenn
keine ICAO-Standortkennung
existiert.
desc b '-' "DESC" 1 {LIM_CHAR} Beschreibung einer Bedingung oder
Stelle, die für den Inhalt der Nach-
richt relevant ist.
destz b '-' "DESTZ" text20 Name des Zielflugplatzes, wenn
keine ICAO-Standortkennung
existiert.
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedFIR-Kennung sowie Flugdauer (in
Stunden und Minuten) bis zur FIR-
Grenze.
eetlat c '-' "EETLAT" lattd time Angabe der Flugdauer bis zu einer
nur durch die Breite angegebene
Position.
eetlong c '-' "EETLONG" longtd time Angabe der Flugdauer bis zu einer
nur durch die Länge angegebenen
Position.
eetpt b '-' "EETPT" point timehhmm_el-
apsedPunktkennung und aufgelaufene
Flugdauer bis zum Punkt.
endtime b '-' "ENDTIME" day ! timehhmm Endzeit eines Zeitraums.
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]Flugplandaten, die für einen Flug
am angegebenen Punkt oder bei
Einflug in den betreffenden Luft-
raum gelten. Eines der Felder
„ptid“, „airspdes“ oder beide
müssen vorhanden sein.
eobd b '-' "EOBD" date Voraussichtliches Off-Block-
Datum.
eobdk b '-' "EOBDK" date Voraussichtliches Off-Block-Datum
als Datenbankschlüssel in einer
Anfrage; Platzhalter möglich.
Muss eine Kombination aus alpha-
numerischen und Platzhalterzeichen
mit maximal insgesamt 6 Zeichen
sein.2000R2082 — DE — 15.06.2002 — 001.001 — 107
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
eobdold b '-' "EOBDOLD" date „Vorheriges“ voraussichtliches Off-
Block-Datum zur Verwendung als
Datenbankschlüssel. Soll das
voraussichtliche Off-Block-Datum
geändert werden, erfolgt die
Angabe des neuen Werts in
„EOBD“.
eobt b '-' "EOBT" timehhmm Voraussichtliche Off-Block-Zeit
(EOBT)
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Voraussichtliche Off-Block-Zeit als
Datenbankschlüssel in einer
Anfrage; Platzhalter möglich.
eobtold b '-' "EOBTOLD" timehhmm „Vorheriges“ voraussichtliche Off-
Block-Zeit zur Verwendung als
Datenbankschlüssel. Soll die
voraussichtliche Off-Block-Zeit
geändert werden, erfolgt die
Angabe des neuen Werts in
„EOBT“.
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Liste der Codes für die Bordausrü-
stung, jeweils gefolgt von der
Angabe des aktuellen Status
errfield b '-' "ERRFIELD" fieldid ADEXP-Name eines fehlerhaften
Felds bzw. fehlerhafter Felder.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Fehlermeldungstext. Kann optional
einen Fehlerkenncode enthalten.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Schätzdaten. Eine Punktkennung,
die voraussichtliche Flugfläche
(Flugflächennummer) sowie
voraussichtliche(s) Überflugdatum/-
zeit, optional gefolgt von der
ergänzenden Flugfläche (Flug-
flächennummer, gefolgt vom Indi-
kator A oder B).
etod b '-' "ETOD" date Voraussichtliches Startdatum.etot b '-' "ETOT timehhmm Voraussichtliche Startzeit.extaddr c '-'"EXTADDR" num | { fac } |
(num {fac})Zusätzlich zu den automatisch
bestimmten Adressen bereitge-
stellte „Extra-Adressen“. Kann die
Anzahl der Adressen oder die
eigentlichen Adressen oder beides
enthalten.
filrte b '-' "FILRTE" {LIM_CHAR} Strecke genau wie aufgegeben, d. h.
ohne jede Verarbeitung.
filtim b '-' "FILTIM" day ! timehhmm Tag-Uhrzeit-Gruppe, die angibt,
wann die Nachricht zur Übermitt-
lung aufgegeben wurde.
flband c '-' "FLBAND" fl fl Höhenband zur vertikalen Luft-
raumdefinition, einschließlich der
angegebenen Flugflächen.
fltrul b '-' "FLTRUL" flightrule Flugregel, wie ICAO-Feld 8.
flttyp b '-' "FLTTYP" flighttype Art des Fluges, wie ICAO-Feld 8.
fmp b '-' "FMP" 4{ ALPHA }4 Kennung einer „Verkehrsflusssteu-
erungsposition“.
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Liste der FMP und der dazuge-
hörigen ATFM-Regelungsmaß-
nahmen.
freq b '-' "FREQ" rtf Funkfrequenz.2000R2082 — DE — 15.06.2002 — 001.001 — 108
▼M1
▼B
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
fstday b '-' "FSTDAY" date Erster Betriebstag eines Dauerflug-
plans. Dient zur Angabe des ersten
tatsächlichen Tages, an dem
Flugpläne aus einem RPL generiert
werden (siehe Feld valfrom) oder
des ersten Tages, an dem ein
Nachtrag zu einem RPL gültig ist.
furthrte b '-' "FURTHRTE" {LIM_CHAR} Die weitere Streckenführung eines
Fluges. Zur Verwendung in Nach-
richten mit Schätzdaten zur Angabe
der weiteren Streckenführung eines
Fluges nach dem voraussichtlichen
Punkt. Darf entweder nur den
nächsten Punkt oder die voll-
ständige weitere Streckenführung
bis zum Zielort enthalten.
geo c '-' "GEO" geoid lattd longtd Punkt entlang einer Strecke, defi-
niert durch Breite und Länge und
im Flugplan als GEOxx angegeben
(xx ist eine Sequenznummer).
ifp b '-' "IFP" 1{ALPHA} Angabe bekannter Fehler in einer
FPL.
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Liste vollständiger IFPD, die dem
in einer Anfragenachricht angege-
benen Datenbankschlüssel entspre-
chen.Enthält eine Liste vollständiger
Informationen für jeden Einzelflug,
der vorhandenen Anfrageschlüsseln
entspricht.
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Liste von ifpdsum, die dem in einer
Anfragenachricht angegebenen
Datenbankschlüssel entsprechen.
Enthält eine Liste vollständiger
Informationen für jeden Einzelflug,
der vorhandenen Anfrageschlüsseln
entspricht.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8Vom IFPS zugewiesene eindeutige
Flugplankennung.
ifpsmod b '-' "IFPSMOD" fieldid modifind Vom IFPS zugewiesene Kennung
für veränderte Felder mit Angabe
der Art der Veränderung.
ifpuresp b '-' "IFPURESP" ifpuid Kennung der für eine Anfrage
zuständigen IFPU. Sie muss die
Anfrage bearbeiten und beant-
worten.
ignore c '-' “BEGIN” "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
“END” “IGNORE”Angabe von Bedingungen, die bei
der Verarbeitung der betreffenden
Nachricht „ignoriert“ oder
umgangen wurden. Eine „igno-
rierte“ Bedingung kann auf einen
bestimmten, durch die angegebenen
Streckenpunkte eingegrenzten Teil
der Strecke beschränkt sein. Bei
einer Bedingung kann es sich z. B.
um eine zeitliche Einschränkung
(Streckenzugangsbedingung), eine
Flugflächenbeschränkung oder eine
TOS-Verletzung handeln.2000R2082 — DE — 15.06.2002 — 001.001 — 109
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
iobd b '-' "IOBD" date Das „erste“ Off-Block-Datum, d. h.
das „Off-Block-Datum“ laut FPL
und aktualisiert durch flugplanbe-
zogene Nachrichten (DLA, CHG
usw.). Es handelt sich um das
Bezugsdatum für den Zugriff auf
den Flugplan in der Datenbank und
das einzige „Off-Block-Datum“,
das den betreffenden ATS-Stellen
bekannt ist.
Anmerkung: Das IOBD wird durch
Veränderungen, die durch
Austausch von ATFM-Nachrichten
angefordert oder gemeldet werden,
nicht berührt.
iobt b '-' "IOBT" timehhmm Die „erste“ Off-Block-Zeit, d. h.
die „Off-Block-Zeit“ laut FPL und
aktualisiert durch flugplanbezogene
Nachrichten (DLA, CHG usw.). Es
handelt sich um die Bezugszeit für
den Zugriff auf den Flugplan in der
Datenbank und die einzige „Off-
Block-Zeit“, die den betreffenden
ATS-Stellen bekannt ist.
Anmerkung: Die IOBT wird durch
Veränderungen, die durch
Austausch von ATFM-Nachrichten
angefordert oder gemeldet werden,
nicht berührt.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Liste der aktiven bedingt verfüg-
baren Strecken.
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Liste der aktiven zeitweilig
getrennten Gebiete (Temporary
Segregated Areas).
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Liste der gesperrten ATS-Strecken.
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Liste der FIR, und zwar Name der
Region, gefolgt entweder von der
Liste bedingt verfügbarer Strecken
oder der Listen bedingt verfügbarer
Strecken, gesperrter ATS-Strecken,
aktiver zeitweilig getrennter
Gebiete, verminderte Luftraumbe-
schränkungen und Lufträume mit
eingeschränkter Koordinierung.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Liste der verminderten Luftraum-
beschränkungen.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Liste der Gebiete mit
eingeschränkter Koordinierung.
lstday b '-' "LSTDAY" date Letzter Betriebstag eines Dauer-
flugplans. Dient der Angabe des
tatsächlichen letzten Tages, für den
Flugpläne aus einem RPL generiert
werden (siehe Feld valuntil) oder
des letzten Tages, an dem ein
Nachtrag zu einem RPL gilt.
=> Muss Datum zwischen
VALFROM und VALUNTIL sein.
mach b '-' "MACH" machnumber [ point ] Mach-Zahl in Hundertsteln einer
Einheit und optional der Punkt, an
dem die Änderung beantragt wird.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimeGültigkeitszeitraum einer Nachricht
einschließlich der angegebenen
Zeiten.2000R2082 — DE — 15.06.2002 — 001.001 — 110
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
minlineup b '-' "MINLINEUP" timehhmm Mindestzeit, die ein abflugbereit
erklärter Flug von seinem
derzeitigen Haltepunkt bis zum
Abheben benötigt.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Anzahl der zur Korrektur einer
ursprünglichen Nachricht
benötigten Änderungen.
msgref c '-' "MSGREF" sender recvr
seqnumBezugsdaten für zugeordnete,
früher übermittelte Nachrichten.
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Enthält die Zusammenfassung einer
Nachricht.
Anmerkung: Muss ein oder
mehrere* der Felder arcid, adep,
ades, eobt und orgn enthalten, aber
ohne Wiederholung.
* ein oder mehrere Felder können
bei der eingegangenen Nachricht
fehlen oder entstellt worden sein
msgtxt b '-' "MSGTXT" icaomsg Enthält eine vollständige ICAO-
Nachricht.
msgtyp b '-' "MSGTYP" titleid Enthält den Titel der referenzierten
oder kopierten Nachricht.
Kann jeder beliebige gültige
ADEXP-Nachrichtentitel sein
(siehe Anhang B).
nav b '-' "NAV" text20 Wesentliche Navigationsausrü-
stung, wie ICAO-Feld 18 NAV/.
nbarc b '-' "NBARC" 1{ DIGIT }2 Anzahl der Luftfahrzeuge, wenn
mehr als 1.
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Anzahl der einer Anfrage entspre-
chenden Flugplandaten.
Muss zwischen 0 und 999 liegen.
newctot b '-' "NEWCTOT" timehhmm Neue Errechnete Startzeit, aktuali-
siert vom TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmNeue Endzeit eines Zeitraums.
neweobd b '-' "NEWEOBD" date Neues voraussichtliches Off-Block-
Datum.
neweobt b '-' "NEWEOBT" timehhmm Neue voraussichtliche Off-Block-
Zeit.
newptot b '-' "NEWPTOT" timehhmm Neue vorläufige Startzeit.newrte b '-' "NEWRTE" { LIM_CHAR } Neue Strecke zwischen denselben
Start- und Zielflugplätzen wie in
der ursprünglichen Nachricht.
newstart-
timeb ‘-' “NEWSTARTTIME” day !
timehhmmNeue Anfangszeit eines Zeitraums.
oldmsg b '-' "OLDMSG" { CHARACTER } Eine vollständige ursprüngliche
Nachricht, genau in der Form, in
der sie empfangen wurde (und im
gleichen Format).
opr b '-' "OPR" 1 { LIM_CHAR } Name des Unternehmens oder der
Agentur, die den Flug betreibt, wie
ICAO-Feld 18 Element OPR/.
orgmsg b '-' "ORGMSG" titleid ADEXP-Titel einer fehlerhaften
Nachricht, wie vom TACT
empfangen.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Adresse des Abfassers einer Nach-
richt.
orgnid b '-' "ORGNID" originatorid Kennung des Abfassers einer
Nachricht.
orgrte b '-' "ORGRTE" { LIM_CHAR } Originalstrecke zwischen Start- und
Zielflugplatz.2000R2082 — DE — 15.06.2002 — 001.001 — 111
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Informationen zum Abfasser einer
Nachricht. Kann den verwendeten
Netzwerktyp oder die betreffende
Adresse oder beides enthalten.
origindt b '-' "ORIGINDT" datetime Datum und Uhrzeit des Empfangs
der ursprünglichen Nachricht durch
das IFPS.
Anmerkung: Es handelt sich nicht
um die Aufgabezeit der Nachricht.
Das Format ist JJMMTTHHMM.
part c '-' "PART" num lastnum Kennung des durch Titel, Aufgabe-
zeit und Gültigkeitszeitraum
gekennzeichneten Nachrichtenteils.
per b '-' "PER" text20 Flugleistungsdaten, wie ICAO-Feld
18 PER/.
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Position eines Luftfahrzeugs, ange-
geben entweder als Punkt oder als
Flugplatz mit optionalen Zeit- und
Flugflächeninformationen.
prevarcid b '-' "PREVARCID" aircraftid Das zuvor verwendete Rufzeichen.prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4Der vom Flug unmittelbar vor dem
im Feld „-SSRCODE“ angege-
benen SSR-Modus und -Code
verwendete SSR-Modus und -Code.
propfl c '-' "PROPFL" tfl [sfl] Von einer übernehmenden FS-
Stelle für die Übernahme eines
Flugs vorgeschlagene Flugfläche.
ptot b '-' "PTOT" timehhmm Vorläufige Startzeit. Vorläufige
Bezugszeit für einen ATFM-Slot.
qrorgn b '-' "QRORGN" originatorid Kennung des Abfassers der
Anfrage.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Name des Ausweichflugplatzes/der
Ausweichflugplätze auf der
Strecke.
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Änderungsgeschwindigkeit: die
einem Luftfahrzeug zugewiesene
Steig- oder Sinkgeschwindigkeit in
Hunderter-Fuß pro Minute.
=> Vorgeschriebene Form: „C“ für
eine Steiggeschwindigkeit bzw.
„D“ für eine Sinkgeschwindigkeit,
gefolgt von einer zweistelligen
Zahl zur Angabe der zugewiesenen
Geschwindigkeit in Hunderter-Fuß
pro Minute. Als Alternative kann
mit der Kennung „ZZZ“ angegeben
werden, dass keine zugewiesene
Steig- oder Sinkgeschwindigkeit
vorliegt.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Liste der Zeiträume und ihrer
jeweiligen Durchsätze für eine
ATFM-Bedingung.
reason b '-' "REASON" 4{ALPHA}12 Grund für die Zurückweisung einer
Nachricht oder die Streichung eines
Slots durch TACT.
Begleitinformation zur Nachricht in
Abhängigkeit vom Inhalt.
ref c '-' "REF" refid ptid brng distnc Punkt entlang einer Strecke, der
durch den Magnetkurs und die
Entfernung von einem anderen
Punkt definiert ist und die Kennung
REFxx erhält.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumBezugsdaten für die Nachricht, die
gerade übermittelt wird.2000R2082 — DE — 15.06.2002 — 001.001 — 112
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
reg b '-' "REG" 1{ LIM_CHAR }7 Eintragungsmarkierungen, wie
ICAO-Feld 18 REG/.
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Bezugsort für eine ATFM-Regel-
ungsmaßnahme.
regul b '-' "REGUL" regulid Kennung einer einen Flug betref-
fenden Verkehrsflussregelungsmaß-
nahme.
rejctot b '-' "REJCTOT" timehhmm Abgelehnte Errechnete Startzeit:
negative Antwort auf einen
Vorschlag für eine bessere Start-
zeit.
release b '-' "RELEASE" 1{ALPHA}1 Angabe, dass der Flug vom über-
gebenden Lotsen an den überneh-
menden Lotsen freigegeben ist.
C = freigegeben für Steigflug
D = freigegeben für Sinkflug
T = freigegeben für Kurvenflug
F = freigegeben für alle Manöver
rename c '-' "RENAME" renid ptid Angabe eines zeitweiligen neuen
Namens für einen „signifikanten
Punkt“, der mehr als einmal in der
Streckenbeschreibung erscheint,
dient der Vermeidung von
Verwechslungen. Dieser zeitweilige
Name wird nur zur Klarstellung der
Streckendarstellung angewendet
und bedeutet keine Änderung der
wirklichen Kennung des Punktes.
respby b '-' "RESPBY" timehhmm Antwort bis: Uhrzeit, bis zu der
eine Antwort auf einen Vorschlag
für eine bessere Startzeit abzugeben
ist.
rfl b '-' "RFL" flightlevel [point] Angeforderte Flugfläche (in Flug-
flächennummer, zehn Metern bzw.
Hunderter-Fuß) und optional der
Punkt, an dem ein Wechsel der
RFL erforderlich ist.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Kennung für Ersatzflugplan (RFP).
Vorgeschriebene Form: „Q“ gefolgt
von einer Ziffer (1 - 9).
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Liste vollständiger RFPD, die den
in einer Anfrage angegebenen
Datenbankschlüsseln entsprechen.
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Liste der rfpdsum (RFPD-Kurzin-
formationen), die den in einer
Anfrage angegebenen Datenbank-
schlüsseln entsprechen.
rif b '-' "RIF 4{LIM_CHAR} Berichtigte Strecke vorbehaltlich
Freigabe während des Fluges und
endend mit der ICAO-Kennung des
berichtigten Zielflugplatzes.
rmk b '-' "RMK" 1{ LIM_CHAR } Klartextanmerkungen, wie ICAO-
Feld 18 RMK/.
route b '-' "ROUTE" {LIM_CHAR} Vollständige ICAO-Feld-15-Infor-
mationen mit Geschwindigkeit,
RFL und Strecke (entsprechend der
Syntax in Verweisdokument 4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockBeschreibung eines umzuleitenden
Verkehrsflusses.
rrteref b '-' "RRTEREF" rrteid Umleitungsbezugsnummer.
rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockBeschreibung eines Verkehrs-
flusses, zu dem der Verkehr umzu-
leiten ist.2000R2082 — DE — 15.06.2002 — 001.001 — 113
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Liste von Streckenpunkten. Kann
auch eine Flugplatzkennung
enthalten.
rvr b '-' "RVR" 1{ DIGIT }3 Pistensichtbereich (RVR).
Betriebsminima bei besonderenmeteorologischen Bedingungen.
Ausgedrückt in Metern.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Liste von Zeiträumen und deren
geltende RVR-Limits.
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitZeitraum, innerhalb dessen das
angegebene RVR-Limit gilt.
sector b '-' "SECTOR" 1{ ALPHANUM }8 Kennung eines ATC-Sektors.sel b '-' "SEL" 4{ ALPHA }5 SELCAL-Code wie ICAO-Feld 18,
Element „SEL/“.
sendto c '-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"Liste der Luftfahrtstellen, an die
eine Nachricht gesendet werden
soll.
seqpt b '-' "SEQPT" ssrequipment Luftraumüberwachungsausrüstung,
wie ICAO-Feld 10.
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Kennung eines Standardinstrumen-
tenabflugverfahrens.
speed b '-' "SPEED" spd [ point ] Eigengeschwindigkeit (in Kilo-
meter pro Stunde oder Knoten)
sowie optional der Punkt, an dem
eine Änderung der Eigengeschwin-
digkeit beantragt wird.
spla b '-' "SPLA" 1{ LIM_CHAR }50 Farbe der am Luftfahrzeug befind-
lichen Markierungen, wie ICAO-
Feld 19 Element „A/“.
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Angabe der Kontaktadresse, bei der
ergänzende Flugplaninformationen
eingeholt werden können.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Name des verantwortlichen Luft-
fahrzeugführers, wie ICAO-Feld 19
Element „C/“.
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Gesamtkapazität Schlauchboote,
wie ICAO-Feld 19 Element 'D/'.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Farbe Schlauchboote, wie ICAO-
Feld 19 Element „D/“.
spldcov b '-' "SPLDCOV" ('T' | 'F') Schlauchboote: Angabe, ob über-
dacht, wie ICAO-Feld 19 Element
„D/“.T = True (=> „C“ in ICAO)
F = False, nicht überdacht.
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Anzahl Schlauchboote, wie ICAO-
Feld 19 Element „D/“.
sple b '-' "SPLE" timehhmm_elapsed Auf Treibstoffvorrat bezogene
Flugdauer, wie ICAO-Feld 19
Element „E/“.
splj b '-' "SPLJ" lifejackets Schwimmwesten, wie ICAO-Feld
19 Element „J/“.
spln b '-' "SPLN" 1{ LIM_CHAR } Sonstige Rettungsausrüstung und
nützliche Bemerkungen, wie
ICAO-Feld 19 Element „N/“.
splp b '-' "SPLP" 1{DIGIT}3 Personen an Bord, wie ICAO-Feld
19 Element „P/“.
splr b '-' "SPLR" emergradio Notfunkausrüstung, wie ICAO-Feld
19 Element „R/“.
spls b '-' "SPLS" survivaleqpt Rettungsausrüstung, wie ICAO-
Feld 19 Element „S/“.2000R2082 — DE — 15.06.2002 — 001.001 — 114
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Angabe der Datenquelle. Inhalt
abhängig vom TITLE-Feld.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Entweder
- SSR-Modus und -Code, wie
ICAO-Feld 7 Elemente b und c.
oder
- die Buchstaben „REQ“, d. h Code
wird angefordert.
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Kennung eines Standardanflugver-
fahrens.
starttime b '-' "STARTTIME" day !
timehhmmAnfangszeit eines Zeitraums.
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Angabe eines Zeitraums in der
Flugstrecke mit „besonderer Akti-
vität“, wenn das Luftfahrzeug in
dem durch die Punkte und/oder
Flugplätze definierten Gebiet für
die angegebene Zeit verweilt, d. h.
Übung, Luftbetankung, Bildflug
usw.
ANMERKUNG: Die Reihenfolge,
in der die Punkte und/oder
Flugplätze angegeben werden, ist
von Bedeutung.
stayinfo c '-' "STAYINFO" stayident remark Informationen zur Art der Aktivität
(Übung, Bildflug usw.), die
während einer „Verweildauer“ auf
der Strecke eines Fluges ausgeführt
werden soll.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Grund für Sonderbehandlung, wie
ICAO-Feld 18 STS/. Entweder
„PROTECTED“ zur Angabe einer
sensiblen Behandlung oder eines
der anerkannten Kennzeichen,
EMER, HOSP usw. oder frei
wählbarer Text.
taxitime b '-' "TAXITIME" timehhmm Differenz zwischen dem Verlassen
der Parkposition und der „Start-
zeit“. Bei den beiden Zeiten kann
es sich je nach Kontext um
tatsächliche oder voraussichtliche
Zeiten handeln.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Kennung eines „Verkehrsaufkom-
mens“.
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockBeschreibung eines Verkehrsauf-
kommens.
title b '-' "TITLE" titleid Nachrichtentitel.ttleet b '-' "TTLEET" timehhmm_elapsed Voraussichtliche Gesamtflugdauer
in Stunden und Minuten.
typz b '-' "TYPZ" text20 Luftfahrzeugmuster, wenn kein
ICAO-Code existiert.
unit c '-' "UNIT" unitid [addrinfo] Informationen zu einer Luftfahrt-
stelle, d. h. zu einer ATC-Stelle,
einem Luftfahrzeughalter oder
einem Flugplanaufgeber. Enthält
die Kennung der Stelle sowie
optional Angaben zur Adresse.
valfrom b '-' "VALFROM" date Erster Betriebstag des Fluges (Jahr,
Monat, Tag).2000R2082 — DE — 15.06.2002 — 001.001 — 115
▼B
ADEXP-
PrimärfeldArt Syntax Semantik
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Erster Betriebstag des Fluges zur
Verwendung als Datenbank-
schlüssel in einer Anfrage; Platz-
halter möglich.
Muss ein gültiges Datum oder eine
Kombination aus gültigem Datum
und Platzhalterzeichen sein.
valfromold b '-' "VALFROMOLD" date „Vorheriges“„valfrom“-Datum.
Verwendung als Datenbank-
schlüssel. Soll das Gültig-ab-Datum
verändert werden, erscheint der
neue Wert in „VALFROM“.
validitydate b '-' "VALIDITYDATE" date Gültigkeitsdatum.
valuntil b '-' "VALUNTIL" date Letzter Betriebstag des Fluges
(Jahr, Monat, Tag).
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Letzter Betriebstag des Fluges zur
Verwendung als Datenbank-
schlüssel in einer Anfrage; Platz-
halter möglich.
Muss ein gültiges Datum oder eine
Kombination aus gültigem Datum
und Platzhalterzeichen sein.
valuntilold b '-' "VALUNTILOLD" date „Vorheriges“„valuntil“-Datum.
Verwendung als Datenbank-
schlüssel. Soll das Gültig-bis-
Datum verändert werden, erscheint
der neue Wert in „VALUNTIL“.
wktrc b '-' "WKTRC" waketurbcat Wirbelschleppenkategorie.
A.4.ADEXP-Teilfelder
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
addrinfo c '-' "ADDRINFO"
networktype facAdresseninformation. unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'Flugplatzkennung.
Kann eine ICAO-
Ortskennung oder die
Angabe „ZZZZ“
enthalten, wenn keine
Ortskennung zuge-
wiesen ist.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Beschreibung einer
gesamten ATS-
Strecke oder eines
Teils davon während
eines spezifizierten
Zeitraums.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Beschreibung eines
gesamten Luftraums
oder eines Teils
davon während eines
spezifizierten Zeit-
raums.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Bezeichnet einen
Luftraum, der keine
ATS-Strecke ist.entrydata airspace
brng b '-' "BRNG" refbe-
aringPeilung eines Punktes
aus einer Navigati-
onshilfe (in Magnet-
grad).ref2000R2082 — DE — 15.06.2002 — 001.001 — 116
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
condition b '-' "CONDITION" 2
{ALPHA} 20Art der Bedingung
oder Beschränkung,
z. B. TOS, FL-
Bedingung.ignore
crfl1 b '-' "CRFL1" flight-
levelUntere Begrenzung
des Höhenbandes,
innerhalb dessen ein
Reisesteigflug bean-
tragt wird.crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")Obere Begrenzung
des Höhenbandes,
innerhalb dessen ein
Reisesteigflug bean-
tragt wird. „PLUS“,
wenn die obere
Begrenzung unbe-
kannt ist.crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberDie während eines
Reisesteigfluges
gehaltene Mach-Zahl.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd Die während eines
Reisesteigfluges zu
haltende Geschwin-
digkeit.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Errechnete Überflug-
zeit.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Entfernung eines
Punkts von einer
Navigationshilfe in
nautischen Meilen.
Vorgeschrieben sind
1 bis 3 Ziffern,
möglichst mit vorge-
setzten Nullen.ref
efl b '-' "EFL" flightlevel Voraussichtliche
Flugfläche.Reserved
for future
use.
endreg b '-' "ENDREG" day!ti-
mehhmmEndzeit einer ATFM-
Regelungsmaßnahme.exccond
regulation
eqpt B '-' "EQPT" eqptcode !
/! eqptstatusAngabe der Bordau-
srüstung und ihres
aktuellen Statuseqcst
eto b '-' "ETO" date !
timehhmm ! secondsVoraussichtliche
Überflugzeit in Jahr,
Monat, Tag, Stunden,
Minuten und
Sekunden.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]Eine „außergewöhn-
liche Bedingung“ im
Zusammenhang mit
ATFM, z. B. Nebel
auf einem Flugplatz.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Adressendaten. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Bezeichnet ein FIR
oder UIR.lfir2000R2082 — DE — 15.06.2002 — 001.001 — 117
▼M1
▼B
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
fl b '-' " FL" flightlevel Generisches Flug-
flächenfeld.
Je nach Kontext eine
„SFL“, „EFL“,
„CFL“, „RFL“ usw.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt
flblock c '-' "FLBLOCK" fl fl Flugflächenblock zur
vertikalen Definition
eines Luftraums,
einschließlich der
angegebenen Flugflä-
chen. Ein als unter
oder über einer
Flugfläche definierter
Block ist auszu-
drücken als von
Flugfläche 000 bis
zur spezifizierten
Fläche bzw. als von
der spezifizierten
Fläche bis Flugfläche
999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleBeschreibung eines
Verkehrsflusses mit
Herkunftsgebiet,
optional die vom
Herkunftsgebiet aus
zu überfliegenden
Strecken oder Punkte,
Zielgebiet und
optional die zum
Zielgebiet hin zu
überfliegenden
Strecken oder Punkte.flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Liste der Verkehrs-
flüsse.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7Der von einer
ATFM-Regelungs-
maßnahme auferlegte
Durchsatz.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Angabe der „Rolle“
eines Verkehrs-
flusses:
EX = excluded
IE = included
exempted
EM = exempted
IN = includedflow
from b '-' "FROM" day!ti-
mehhmmAnfangszeit eines
Zeitraums.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15Position, an der eine
Strecke, ein Strek-
kenteil, ein Flugweg
oder ein Verkehrs-
fluss beginnt.
Kann eine Region,
ein Flugplatz oder ein
signifikanter Punkt
sein.flow
geoid b '-' "GEOID" geoname Kennung eines
geographischen
Punkts, bestehend aus
„GEO“, gefolgt von
einer Sequenz-
nummer
(Beispiel: "GEO12").geo2000R2082 — DE — 15.06.2002 — 001.001 — 118
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Vollständige Infor-
mation zu einem
Einzelflugplan.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnZusammenfassende
Information zu einem
Einzelflugplan.
Enthält die Felder
arcid, adep, ades,
eobt und orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Dreistellige Zahl, die
das Ende einer
Sequenz anzeigt.
lattd b '-' "LATTD" latitu-
delong ! latitudesideGeographische Breite
in Grad, Minuten,
Sekunden und Rich-
tung (Nord oder
Süd).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitu-
desideGeographische Länge
in Grad, Minuten,
Sekunden und Rich-
tung (Ost oder West)eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Angabe des für einen
Nachrichtenaustausch
verwendeten Netz-
werktyps.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Dreistellige Zahl. extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7„pending rate“, zur
Verwendung für
ATFM-Zwecke.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgEnthält eine voll-
ständige ADEXP-
Nachricht nach deren
Verarbeitung.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgEnthält eine voll-
ständige ADEXP-
Nachricht vor deren
Verarbeitung, d. h. so
wie empfangen.adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Punkt auf einer
Strecke.
=> Enthält eine
Punktkennung sowie
optional:
— Flugfläche oder
Flugflächenblock,
— Ergänzungs-
flugfläche,
— Zeitbezug.
— Reisesteigflug
— Streckenführungs-
angabe
— Angabe eines
Zeitraums mit
„besonderer Akti-
vität“, d. h. dass der
Flug für einen
bestimmten Zeitraum
im Gebiet 'verweilt'
Änderung von:
— RFL, Flugregeln,
Geschwindigkeit/
Mach-Zahlrtepts2000R2082 — DE — 15.06.2002 — 001.001 — 119
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Angabe eines Reise-
steigfluges auf einer
Flugstrecke.
Geschwindigkeit oder
Mach-Zahl, gefolgt
von den beiden
Flächen mit Angabe
des während des
Steigflugs belegten
Höhenbandes. Ist die
obere Fläche unbe-
kannt, kann die
zweite Fläche
„PLUS“ sein.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Angabe der am
betreffenden Punkt
geltenden Flugregeln.entrydata
ptid b '-' "PTID" point Punktkennung,
entweder codiert oder
künstlich vergebener
Name (GEOxx,
REFxx oder RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberMach-Zahl in
Hundertsteln einer
Einheit an einem
Punkt auf der
Strecke.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Angabe der am
betreffenden Punkt
geltenden „militäri-
schen“ Flugregeln.entrydata
ptrfl b '-' "PTRFL" flight-
levelAngeforderte
Flugfläche an einem
Punkt auf der
Strecke.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}Flugstrecke nach dem
angegebenen Punkt.
Entweder die voll-
ständige Strecke bis
zum Zielflugplatz
oder lediglich das
Streckenelement bis
zum nächsten Punkt.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgAngabe eines Wech-
sels der „Flugregeln“
(VFR/IFR) oder der
„Art des Fluges“
(OAT/GAT) oder
beides an einem
Punkt auf der
Strecke.ad pt
ptspeed b '-' "PTSPEED" spd Eigengeschwindigkeit
(in Kilometer pro
Stunde oder Knoten)
an einem Punkt auf
der Strecke.ad
entrydatapt2000R2082 — DE — 15.06.2002 — 001.001 — 120
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmAngabe eines Zeit-
raums in der aufge-
gebenen Flugstrecke
mit „besonderer
Aktivität“, wenn das
Luftfahrzeug in dem
durch die Punkte
und/oder Flugplätze
definierten Gebiet für
die angegebene Zeit
verweilt, d. h. Übung,
Luftbetankung, usw.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penrateZeitraum, in dem die
angegebenen Durch-
satzraten für eine
ATFM-Regelungs-
maßnahme gelten.ratepdlst regcond
recvr b '-' "RECVR" fac Empfänger der mit
Bezugsdaten verse-
henen Nachricht.msgref
refdata
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]ATS-Streckenken-
nung und Kennung
des ersten und letzten
Punkts. Die aufge-
führten Punkte
können ICAO-Kenn-
ungen oder künstlich
vergebene Punkte
GEOxx, RENxx bzw.
REFxx sein. Die
Kennung des Landes,
in dem sich der Punkt
befindet, kann
optional angegeben
werden. Die
Endpunkte müssen
der Streckeninforma-
tion entsprechen.airroute
refid b '-' "REFID" refname Kennung eines
Bezugspunkts, aus
„REF“, gefolgt von
einer Sequenz-
nummer (Beispiel:
„REF02“).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Bezugsstandort einer
ATFM-Regelungs-
maßnahme.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Liste von Zeiträumen
und ihrer jeweiligen
Durchsatzraten für
eine bestimmte
ATFM-Regelungs-
maßnahme.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Beschreibung einer
ATFM-Regelungs-
maßnahme.regulation
regid b '-' "REGID" regulid Kennung einer
„Maßnahme“ zur
Verkehrsflussrege-
lung.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Liste von
„Maßnahmen“ zur
Verkehrsflussrege-
lung.fmplist2000R2082 — DE — 15.06.2002 — 001.001 — 121
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Bezugszahl für eine
ATFM-„Regelungs-
maßnahme“ mit
einem eindeutigen
Bezug, gefolgt von
einer Gültigkeitsan-
gabe.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12Grund für eine
ATFM-Regelungs-
maßnahme.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]Eine zwecks
Verkehrsflussrege-
lung festgelegte
„Maßnahme“.reglist
remark b '-' "REMARK"
1{LIM_CHAR}Bemerkung zu dem
Posten, zu dessen
Beschreibung dieses
Feld gehört.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Kennung für einen
Punkt, der in der
Streckenbeschreibung
wiederholt wird.rename
respunit b '-' "RESPUNIT"
12{ALPHA}12Zuständige ATC-
Stelle.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Vollständige Infor-
mation zu einem
Dauerflugplan.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilZusammenfassung
der Information zu
einem Dauerflugplan.
Enthält die Felder
arcid, adep, ades,
eobt, orgn, days,
valfrom und valuntil.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Pistensichtbereich:
Betriebsminima bei
besonderen meteoro-
logischen Bedin-
gungen. Ausgedrückt
in Metern.rvrperiod exccond
sender b '-' "SENDER" fac Absender der mit
Bezugsdaten verse-
henen Nachricht.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Laufende Nummer
der übersandten
Nachricht (eindeutige
dreistellige Zahl für
die Kombination
Absender/
Empfänger).msgref
refdata2000R2082 — DE — 15.06.2002 — 001.001 — 122
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
sfl b '-' SFL flightlevel !
('A'|'B')Ergänzungs-
flugfläche.
Flugfläche, auf oder
oberhalb bzw. auf
oder unterhalb
welcher ein Flug zur
Querung eines
Punktes koordiniert
worden ist oder wird.
Besteht aus einer
Flugflächennummer
und einer Querungs-
bedingung (entweder
„A“, wenn das Luft-
fahrzeug den Punkt
auf oder oberhalb der
Fläche kreuzt, oder
„B“, wenn die Kreu-
zung auf oder unter-
halb der Fläche
erfolgt.coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmZeit, zu der eine
ATFM-Regelungs-
maßnahme wirksam
wird.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentIndikator des Koordi-
nationsstatus eines
Fluges.cstat
statreason b '-' "STATREASON"
coorstatusreasonGrund für eine
Änderung des Koor-
dinationsstatus eines
Fluges.cstat
stayident b '-' "STAYIDENT"
stayidentifierKennung eines Zeit-
raums mit 'beson-
derer Aktivität' oder
einer 'Verweildauer'
innerhalb der Strecke
eines Fluges.stay
stayinfo
sto b '-' "STO" timehhmm
! secondsGenerisches Zeitfeld
mit der Zeit für einen
Punkt oder für einen
Flugplatz. Bei der
Zeit kann es sich je
nach Kontext um
eine voraussichtliche,
errechnete oder
tatsächliche Zeit
handeln.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Übergabeflugfläche.
Flugfläche, auf der
ein Flug bei Horizon-
talflug zur Querung
eines Punktes koordi-
niert worden ist oder
wird (Flugflächen-
nummer), oder bei
Steig- oder Sinkflug
am Grenzpunkt die
freigegebene Fläche,
auf die sich der Flug
zubewegt.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Kennung eines
„Verkehrsflusses“.rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Zeitangabe. Kann je
nach Nachrichtenkon-
text eine Uhrzeit oder
ein Zeitraum sein.stay2000R2082 — DE — 15.06.2002 — 001.001 — 123
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
to b '-' "TO" timehhmm „Time Over/Off“.
Generisches Zeitfeld,
das die Zeit für einen
Punkt oder für einen
Flugplatz enthalten
kann. Bei der Zeit
kann es sich je nach
Kontext um eine
voraussichtliche,
errechnete oder
tatsächliche Zeit
handeln.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15Position, zu der eine
Strecke, ein Strek-
kenteil, ein Flugweg
oder ein Verkehrs-
fluss führt.
Kann eine Region,
ein Flugplatz oder ein
signifikanter Punktsein.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Kennung einer Luft-
fahrtstelle, d. h. einer
ATC-Stelle, eines
Luftfahrzeughalters
oder eines Flugpla-
naufgebers.unit
until b '-' "UNTIL" day!ti-
mehhmmEndzeit eines Zeit-
raums.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeGültigkeitszeitraum
einschließlich der
angegebenen Zeiten.airroute
airspace
via1 b '-' "VIA1" 1
{ALPHANUM} 15Ein Punkt, eine ATS-
Strecke oder ein
Luftraum, die sich
auf der Strecke des
Fluges befinden oder
befinden müssen.
Wenn mehr als ein
Punkt anzugeben ist,
enthält dieses Feld
den ersten in der
Folge.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Ein Punkt, eine ATS-
Strecke oder ein
Luftraum, die sich
auf der Strecke des
Fluges befinden oder
befinden müssen.
Wenn mehr als ein
Punkt anzugeben ist,
enthält dieses Feld
den zweiten in der
Folge.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Ein Punkt, eine ATS-
Strecke oder ein
Luftraum, die sich
auf der Strecke des
Fluges befinden oder
befinden müssen.
Wenn mehr als ein
Punkt anzugeben ist,
enthält dieses Feld
den dritten in der
Folge.flow2000R2082 — DE — 15.06.2002 — 001.001 — 124
▼B
Teilfeld Art Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
via4 b '-' "VIA4" 1
{ALPHANUM} 15Ein Punkt, eine ATS-
Strecke oder ein
Luftraum, die sich
auf der Strecke des
Fluges befinden oder
befinden müssen.
Wenn mehr als ein
Punkt anzugeben ist,
enthält dieses Feld
den vierten in der
Folge.flow2000R2082 — DE — 15.06.2002 — 001.001 — 125
▼B
ANHANG B (Normativ)
ZENTRALES REGISTER DER ADEXP-NACHRICHTENTITEL
Titel DefinitionVorgestellt in
Abschnitt
ABI Advance Boundary Information Message E.3
ACK Acknowledge Message E.1
ACP Acceptance Message E.5
ACT Activation Message E.3
AUP Airspace Use Plan Message E.4
BFD Basic Flight Data Message E.5
CDN Co-ordination Message E.3
CFD Change to Flight Data Message E.5
CNLCOND ATFM Exceptional Condition Cancellation Message E.2.3
CNLREG ATFM Regulation Cancellation Message E.2.3
COD SSR Code Assignment Message E.3
COF Change of Frequency Message E.3
CRAM Conditional Route Availability Message E.4
DES De-Suspension Message E.2.2
ERR Error Message E.2.2
EXCOND ATFM Exceptional Condition Notification Message E.2.3
FCM Flight Confirmation Message E.2.2
FLS Flight Suspension Message E.2.2
FSA First System Activation Message E.2.3HOP Hand-Over Proposal Message E.3
IACH Individual ATC Modification Message E.1
IAFP Individual ATC Flight Plan Proposal Message E.1
IAPL Individual ATC Flight Plan Message E.1
IARR Individual Arrival Message E.1
ICHG Individual Modification Message E.1
ICNL Individual Cancellation Message E.1
IDEP Individual Departure Message E.1
IDLA Individual Delay Message E.1
IFPL Individual Flight Plan Message E.1
INF Information Message E.3
IRPL Individual Repetitive Flight Plan E.1
IRQS Individual Request Supplementary Flight Plan E.1
ISPL Individual Supplementary Flight Plan E.1
LAM Logical Acknowledgement Message E.3, E.5
LRM Logical Rejection Message E.3
MAC Message for Abrogation of Co-ordination E.3
MAN Manual Processing Pending Message E.1
MAS Manual Assumption of Communications Message E.3
MODCOND ATFM Exceptional Condition Modification Message E.2.3
MODREG ATFM Regulation Modification Message E.2.3MRA Mandatory Route Activation Message E.2.3
MRCNL Mandatory Route Cancellation Message E.2.3
MRMOD Mandatory Route Modification Message E.2.3
NEWREG New ATFM Regulation Notification Message E.2.32000R2082 — DE — 15.06.2002 — 001.001 — 126
▼B
Titel DefinitionVorgestellt in
Abschnitt
NTA No Traffic Accepted Message E.2.3
NTACNL No Traffic Accepted Cancellation Message E.2.3
NTAMOD No Traffic Accepted Modification Message E.2.3
OLRA Off-Load Route Activation Message E.2.3
OLRCNL Off-Load Route Cancellation Message E.2.3OLRMOD Off-Load Route Modification Message E.2.3
PAC Preliminary Activation Message E.3
RAP Referred Activate Proposal Message E.3
RCHG Repetitive Flight Plan Data Modification Message E.1
RCNL Repetitive Flight Plan Data Cancellation Message E.1
RDY Ready Message E.2.2
REJ Rejection Message E.1
REV Revision Message E.3
RJC Reject Co-ordination Message E.5
RJT Re-Routing Rejection Message E.2.2
ROF Request On Frequency Message E.3
RRP Re-Routing Proposal Message E.2.2
RRV Referred Revision Proposal Message E.3
SAM Slot Allocation Message E.2.2
SBY Stand-by Message E.3
SDM Supplementary Data Message E.3
SIP Slot Improvement Proposal Message E.2.2
SLC Slot Requirement Cancellation Message E.2.2
SMM Slot Missed Message E.2.2
SPA Slot Proposal Acceptance Message E.2.2
SRJ Slot Proposal Rejection Message E.2.2SRM Slot Revision Message E.2.2
SRR Slot Revision Request Message E.2.2
TIM Transfer Initiation Message E.3
UUP Updated Airspace Use Plan Message E.4
XAP Crossing Alternate Proposal Message E.5
XCM Crossing Cancellation Message E.5
XIN Crossing Intention Notification Message E.5
XRQ Crossing Request Message E.52000R2082 — DE — 15.06.2002 — 001.001 — 127
▼B
ANHANG C (Normativ)
ZENTRALES REGISTER DER RESERVIERTENNACHRICHTENTITELC.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
Reservierter Titel Art der Nachricht Reserviert von
ACTARR Activation Message for an Arrival Frankreich
ACTDEP Activation Message for a Departure Frankreich
ADMFPL ADMAR2000 Flight Plan Message Deutschland
ADMFPT ADMAR2000 Flight Plan Termination Message Deutschland
ADMFPU ADMAR2000 Flight Plan Update Message Deutschland
ANM ATFM Notification Message CFMU
ANSWERCT Response Message (Terminal Control System) Frankreich
ANSWM Response Message (ODS) Frankreich
ANSXFPLCT Response Message Frankreich
ATT Landing Message Frankreich
BEGINPROC Begin Processing Message Frankreich
BEGPROC Controller Working Position Initialisation Procedure
Message (ODS)Frankreich
BEGPROCCT Controller Working Position Initialisation Message
(Terminal Control System)Frankreich
CDA Departure Cleanance Message (ARINC 623) Frankreich
CDAFTX Departure Clearance (ARINC 620) Frankreich
CHGDEP Modification message for a Departure flight Frankreich
CLD Departure Clearance (ARINC 623) Frankreich
CLDFTX Departure Clearance (ARINC620) Frankreich
CNLARR Cancellation of an Arrival Frankreich
CNLCOND Cancellation of Exceptional Condition CFMUCNLDEP Cancellation of a Departure Frankreich
CNLREG Cancellation of an ATFM Regulation CFMU
CONFEND End Message to a change of Operational Configuration Frankreich
CONFIDM Operational Configuration Message (ODS) Frankreich
CONFIDMCT Operational Configuration Message (Terminal Control
System)Frankreich
DEC Take-Off Message Frankreich
DOUBM Duplication Flight Plan Message Frankreich
DRT Modification of Destination Message Frankreich
EATARR Update of Estimated Arrival Time Message Frankreich
ENDPROC Controller Working Position Initialisation Procedure
Last Message (ODS)Frankreich2000R2082 — DE — 15.06.2002 — 001.001 — 128
▼B
Reservierter Titel Art der Nachricht Reserviert von
ENDPROCCT Controller Working Position Initialisation Procedure
Last Message (Terminal Control System)Frankreich
EVLARR Pre-Activation Message for Arrival Frankreich
EVLDEP Pre-Activation Message for Departure Frankreich
EXCOND Activation of an Exceptional Condition CFMUFICM Flight Data Creation Message FrankreichFLXVIVO „Flexible Track“ Description Display Message Frankreich
FPCLOSE Flight Plan Data Close Message (ODS) Frankreich
FPCLOSECT Flight Plan Data Close Message (Terminal Control
System)Frankreich
FPCLOSED Duplication of Flight Plan Data Close Message (ODS) Frankreich
FPCRD Activation of Flight Plan Message (ODS) FrankreichFPCRDCT Activation of Flight Plan Message (Terminal Control
System)Frankreich
FPCRDD Duplication of Flight Plan Data Activation Message
(ODS)Frankreich
FPCRE Creation of Flight Plan Message (ODS) Frankreich
FPCRECT Creation of Flight Plan Message (Terminal Control
System)Frankreich
FPINI Pre-Activation of Flight Plan Message (ODS) Frankreich
FPINICT Pre-Activation of Flight Plan Message (Terminal
Control System)Frankreich
FPINID Duplication of Pre-Activation of Flight Plan Message Frankreich
FPNTF Pre-Activation of Flight Plan Message (ODS) Frankreich
FPNTFD Duplication of Pre-Activation of Flight Plan Message
(ODS)Frankreich
FPRDU Flight Data Information Message for a Non-Concerned
Sector (ODS)Frankreich
FPRDUCT Flight Data Information Message for a non-concerned
Sector (Terminal Control System)Frankreich
FSM Departure Clearance System Message (ARINC 623) Frankreich
FSMFTX Departure Clearance System Message (ARINC 620) FrankreichFSR Flight Suspension Request Message CFMU
IACHD Individual ATC Modification Message Deutschland
ICHGD Individual Modification Message DeutschlandIDEPD Individual Departure Message DeutschlandIDLAD Individual Delay Message DeutschlandIFPDQ Individual Flight Plan Data Query Message CFMU
IFPDQR Individual Flight Plan Data Query Reply Message CFMU
IFPDSQ Individual Flight Plan Data Summary Query Message CFMUIFPDSQR Individual Flight Plan Data Summary Query Reply
MessageCFMU
IFPLD Individual Flight Plan Deutschland
INFOM Information Message FrankreichIRQS Individual Request for Supplementary Information
MessageCFMU
ISPL Individual Supplementary Flight Plan Message CFMU
LGR Flight Plan Message List FrankreichLISTFP Flight Plan Message List (ODS) Frankreich
LISTFPCT Flight Plan Message List (Terminal Control System) Frankreich
LOGON Identification of Flight Plan Message FrankreichMAJVIVO Daily Movements Message Frankreich2000R2082 — DE — 15.06.2002 — 001.001 — 129
▼B
Reservierter Titel Art der Nachricht Reserviert von
MCOM Co-ordination Message Frankreich
MODCOND Modification of an Exceptional Condition CFMU
MODREG Modification of an ATFM Regulation CFMU
MRA Activation of a Mandatory Route CFMU
MRCNL Cancellation of a Mandatory Route CFMU
MRMOD Modification of a Mandatory Route CFMUMRR Mandatory Re-Routing Message CFMU
MVTVIVO Movements Information Message Frankreich
NEWREG Activation of an ATFM Regulation CFMU
NTA Activation of a „Not Allowed“ Traffic Flow CFMU
NTACNL Cancellation of a „Not Allowed“ Traffic Flow CFMU
NTAMOD Modification of a „Not Allowed“ Traffic Flow CFMU
OCLM Oceanic Clearance Message Frankreich
OCLMD Duplication of Oceanic Clearance Message Frankreich
OLRA Activation of an Off-Load Route CFMUOLRCNL Cancellation of an Off-Load Route CFMU
OLRMOD Modification of an Off-Load Route CFMU
PAMAER Runway Application Message Frankreich
PAMARB „On-Stand“ Confirmation Message Frankreich
PAMARRANN Cancellation of Parking Allocation for an Arrival Frankreich
PAMARRCRE Allocation of Parking Position for an Arrival Frankreich
PAMARRPST Modification of Parking Allocation for an Arrival FrankreichPAMDAPARB Parking Message for Arrival Aircraft Frankreich
PAMDAPCRE Allocation of a Parking Position Frankreich
PAMDEPANN Cancellation of Parking Allocation for a Departure Frankreich
PAMDEPCRE Parking Allocation for a Departure Frankreich
PAMDEPPST Modification of Parking Allocation for a Departure Frankreich
PAMDRB „Off-Stand“ Confirmation Message Frankreich
QTAARR Return to Original „Created“ Status for an Arrival Frankreich
QTADEP Return to Original „Created“ Status for a Departure Frankreich
RCD Request Departure Clearance Message (AIRINC 623) FrankreichRCDFTX Request Departure Clearance Message (AIRINC 620) Frankreich
REVARR Revision Message for an Arrival Frankreich
RFPDQ Repetitive Flight Plan Data Query Message CFMU
RFPDQR Repetitive Flight Plan Data Query Reply Message CFMU
RFPDSQ Repetitive Flight Plan Data Summary Query Message CFMU
RFPDSQR Repetitive Flight Plan Data Summary Query Reply
MessageCFMU
RIEM Flight Data Information Message Frankreich
RMG Missed Approach Message Frankreich
RRA Re-Routing Acceptance Message CFMU
RREC Repetitive Flight Plan Recovery Message CFMU
RRN Re-Routing Notification Message CFMU
RSUS Repetitive Flight Plan Suspension Message CFMU
RWYCHGCT Runway Configuration Message Frankreich
TRACT Request for Flight Plan Activation (ODS) Frankreich
TRACTCT Request for Flight Plan Activation (Terminal Control
System)Frankreich
TRCNL Request for Flight Plan Cancellation (ODS) Frankreich2000R2082 — DE — 15.06.2002 — 001.001 — 130
▼B
Reservierter Titel Art der Nachricht Reserviert von
TRCNLCT Request for Flight Plan Cancellation (Terminal Control
System)Frankreich
TRCOR Request for Manual Correlation Frankreich
TRDECOR Request for Manual De-Correlation Frankreich
TRFIC Request for Creation of Flight Plan Data (ODS) Frankreich
TRFICCT Request for Creation of Flight Plan Data (Terminal
Control System)Frankreich
TRFLRQT Request Flight Level Message Frankreich
TRMOD Request for Flight Plan Modification (ODS) Frankreich
TRMODCT Request for Flight Plan Modification (Terminal Control
System)Frankreich
TRMODH Request for Time Modification Frankreich
TRMODHD Request for Time Modification for Delayed Flight Frankreich
TRMVT Co-ordination Request for Exiting Flight (ODS) Frankreich
TRMVTCT Co-ordination Request for Exiting Flight (Terminal
Control System)Frankreich
TRPOINT Specific Flight Data Request Message Frankreich
TRRET Request for Revision of Flight Plan to „Created“ Status
(ODS)Frankreich
TRRETCT Request for Revision of Flight Plan to „Created“ Status
(Terminal Control System)Frankreich
TRRIP Request for Display of Flight Data Information (ODS) Frankreich
TRRIPCT Request for Display of Flight Data Information
(Terminal Control System)Frankreich
TRRQT Flight Plan Request (ODS) Frankreich
TRRQTCT Flight Plan Request (Terminal Control System) FrankreichTRSHRQT Request for SHOOT Action Frankreich
TRSTAR Controller Working Position Initialisation Request
(ODS)Frankreich
TRSTARCT Controller Working Position Initialisation Request
(Terminal Control System)Frankreich
TRTRP Transfer Position Message Frankreich
UNKFP Suppression of Flight Plan Message (ODS) Frankreich
UNKFPCT Suppression of Flight Plan Message (Terminal Control
System)Frankreich2000R2082 — DE — 15.06.2002 — 001.001 — 131
▼B
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
Reservierter
HilfstermSyntax SemantikVerwendung
in PrimärfeldVerwendung
in TeilfeldVerwen-
dung in
Hilfs-
term
centreidentifi-
cation1{ALPHA}4 FS-Stellenken-
nung.ctsrc
ripsrcctripectdest
contextfdpsid 'opepal' | 'opesos' |
'evalpal' | 'tsto-
pepal' |'tstopesos'Betriebsart einer
FDPS-Anwen-
dung.
(in Betrieb, Test
usw.)ctxtfdps
contextphi-
diasid'ope'|'eva-
l1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Besonderheit des
französischen
Systems.ctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Einflugpunkt für
die Kontrollposi-
tion („E“).
Ausflugpunkt für
die Kontrollposi-
tion („S“),
XFL-Punkt (X),
OCL-Punkt (O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Kennung einer
„operationellen
Stelle“.eosrc eoid
fl3 'F' ! 3{DIGIT}3 Flughöhe in
Hundert Fuß.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Vorausberechnete
Tendenz des
Flugprofils
U — AufwärtsD — AbwärtsS — Stabiletrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Flugplanstatus
innerhalb eines
ACC.fpctst2000R2082 — DE — 15.06.2002 — 001.001 — 132
▼B
Reservierter
HilfstermSyntax SemantikVerwendung
in PrimärfeldVerwendung
in TeilfeldVerwen-
dung in
Hilfs-
term
latitude 4{ DIGIT }4 Geographische
Breite, vierstellig.Reserviert
für künftige
Verwendung
latitudeshort 2{ DIGIT }2 Geographische
Breite, zwei-
stellig.Reserviert
für künftige
Verwendung
longitude 5{ DIGIT }5 Geographische
Länge, fünf-
stellig.Reserviert
für künftige
Verwendung
longitu-
deshort3{ DIGIT }3 Geographische
Länge, dreistellig.Reserviert
für künftige
Verwendung
pointcautra 1{ALPHANU-
M}5Besonderheit des
französischen
Systemsfirstpid pointid
ptcid
ptid
positionident-
ification1{ALPHANU-
M}6Tatsächliche oder
logische Arbeits-
position.posid
qfuid (‘0'|'1'|'2'|'3')!1{
DIGIT }1!(‘L'|'C'
|'R'|NIL)QFU für eine
Piste.
L = LinksC= MitteR = Rechtsqfu qful
secidentifica-
tion1{ALPHANU-
M}2Sektorkennung. secdest
secsrcsecid
sendin-
greason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|
'MVTSEC'|'COO-
RAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'-
INIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|'PKG'Grund für die
Sendung von
Flugplandaten.event
starreason 'TOTAL' Art der Initiali-
sierung einer
Position mit
Flugplandaten.streason
temperature ("N" | "P") !
2{DIGIT}2Temperatur in
Grad Celsius (00-
99) mit Vorzei-
chen-angabe
(negativ oder
positiv)temp2000R2082 — DE — 15.06.2002 — 001.001 — 133
▼B
Reservierter
HilfstermSyntax SemantikVerwendung
in PrimärfeldVerwendung
in TeilfeldVerwen-
dung in
Hilfs-
term
updatereason ('T'!('R'|NIL)|'R') Art der zuletzt
vorgenommenen
Flugdatenaktuali-
sierung.
Transaktion des
Flugbetriebsunter-
nehmens („T“).
Radar („R“).udpt
D.4.Reservierte Primärfelder
Reser-
viertes
PrimärfeldArt Syntax Semantik
aabd b '-' "AABD" date Tatsächliches On-Block-Datum.
aabt b '-' "AABT" timehhmm Tatsächliche On-Block-Zeit.
acnf c '-' "ACNF" ad rcnf [qfulist] Pistenkonfiguration.
aobd b '-' "AOBD" date Tatsächliches Off-Block-Datum.
aobt b '-' "AOBT" timehhmm Tatsächliche Off-Block-Zeit.
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Anflugart des Fluges (einstellig,
Werte: 1, 2, 3).
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Von Luftfahrzeughaltern verwen-
dete Luftfahrzeugkennung.
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Von ATC verwendete lokal
eindeutige Luftfahrzeugkennung.
atis b '-' "ATIS" 1{ALPHA}1 Indikator Automatischer Nahbe-
reichsinformationsdienst.
autfl1 b '-' "AUTFL1" fl3 Genehmigte Flugfläche 1.
autfl2 b '-' "AUTFL2" fl3 Genehmigte Flugfläche 2.
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Bereitstellung der Daten, die in
einer Koordinierungsmeldung über-
mittelt werden sollen:
Sendezeit, Ausflugpunkt, Flughöhe
über Ausflugpunkt, geplante
Flugfläche und Information, ob
Flugfläche den Vereinbarungen
entspricht.
avail b '-' "AVAIL" 'YES'|'NO' Angabe, ob einem Sektor die
Änderung von Flugplandaten
gestattet ist oder nicht.
bkrow b '-' "BKROW" 1{DIGIT}2 Position eines Bezugspunktes in
einer Liste von Streckenpunkten.
bkt b '-' "BKT" datetime Überflugzeit des Bezugspunktes für
eine Transaktion.
codetr b '-' "CODETR" 'YES'|'NO' Angabe, ob dem Piloten von der
Kontrollstelle der ssrcode übermit-
telt werden sollte (oder nicht).
confid b '-' "CONFID" 1{DIGIT}5 Kennung operationelle Konfigura-
tion (sectors|positions).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-'"END" "CONFL"Liste der Sektoren-Positionszuord-
nungen für eine FS-Stelle auf der
Strecke.
crspd b '-' "CRSPD" 1{DIGIT}4 Reisegeschwindigkeit in Knoten.
ctripe b '-' "CTRIPE" centreidentification Name der empfangenden FS-Stelle
für eine Transaktion.
ctrow b '-' "CTROW" 1{DIGIT}1 Position einer FS-Stelle in einer
Liste der FS-Stellen.2000R2082 — DE — 15.06.2002 — 001.001 — 134
▼B
Reser-
viertes
PrimärfeldArt Syntax Semantik
ctsrc b '-' "CTSRC" centreidentification Kennung der sendenden FS-Stelle.
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Betriebsart des Bereichskontrollsy-
stems.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Betriebsart eines FPDS.
ctxtpos b '-' "CTXTPOS" contextphidiasid Betriebsart für ODS.curfl b '-' "CURFL" fl3 Derzeitige Flugfläche.
curpos c '-' "CURPOS" ptid | (lattd longtd) Derzeitige Position.
curpost b '-' "CURPOST" datetime Datum und Uhrzeit an der
derzeitigen Position.
curptt b '-' "CURPTT" datetime Überflugdatum und -zeit am
derzeitigen Punkt.
curptx b '-' "CURPTX" 1{DIGIT}2 Positionsnummer des derzeitigen
Punktes in einer Liste der Strek-
kenpunkte.
dcatcid b '-' "DCATCID" icaoaerodrome Für die Abflugfreigabe zuständiger
Flugplatz bei Übermittlung vom
FDPS zum Luftfahrzeug über
Datenverbindung.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Basistext für Abflugfreigabemel-
dungen ARINC 623. „ACK“ -
Bestätigungsmeldung.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Basistext für Abflugfreigabemel-
dungen ARINC 620. „ACK“ -
Bestätigungsmeldung.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Abflugfreigabestatus für einen
Flug.
dcid b '-' "DCID" 1{DIGIT}3 Systemnummer für Abflugfreigabe.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Art der Abflugfreigabemeldung.
dcref b '-' "DCREF" 1{ALPHANUM}5 Kontextbezug für eine Abflugfrei-
gabe.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Bemerkung für eine Abflugfrei-
gabe.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Ergänzungstext für die Abflugfrei-
gabe-Systemmeldung (ARINC
623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Zweiter Ergänzungstext für die
Abflugfreigabemeldung (ARINC
623).
dcdt b '-' "DCDT" datetime ! seconds Tag, Stunde, Minuten, Sekunden
für Abflugfreigabe.
delcode b -' “DELCODE”
1{ALPHANUM}20Grund für eine Verspätung.
dfdpsid b '-' "DFDPSID datetime ! seconds Kennung Daten Flugdatenverarbei-
tungssystem.
doubid b '-' "DOUBID" 1{ALPHANUM}2 Kennung einer „Duplikat“-Stelle.
ecurptt b '-' "ECURPTT" datetime Voraussichtliche Überflugzeit des
derzeitigen Punktes.
eda b '-' "EDA" date Voraussichtliche Ankunftszeit.
elastptt b '-' "ELASTPTT" datetime Voraussichtliche Überflugzeit des
letzten Streckenpunktes.
endhldt b '-' "ENDHLDT" datetime Endzeit Warteschleife.2000R2082 — DE — 15.06.2002 — 001.001 — 135
▼B
Reser-
viertes
PrimärfeldArt Syntax Semantik
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Häufigkeit des Auftretens eines
Flugplans innerhalb einer FS-Stelle.
entryt b '-' "ENTRYT" datetime Einflugzeit für die Position.
enxtptt b '-' "ENXTPTT" datetime Voraussichtliche Überflugzeit des
nächsten Punktes (keine Angabe,
wenn derzeitiger Punkt der letzte
Punkt ist).
eobdt b '-' "EOBDT" datetime Datum und voraussichtliche Off-
Block-Zeit.
eosrc b '-' "EOSRC" eoidentification Kennung operationelle Stelle.espfl b '-' "ESPFL" flightlevel Ergänzende Übergabeflugfläche für
die vorherige Kontrollposition.
eta b '-' "ETA" timehhmm Voraussichtliche Ankunftszeit.etrfl b '-' "ETRFL" flightlevel|flightten-
dancyEinflugfläche oder Flugprofilten-
denz.
event b '-' "EVENT" sendingreason Auslösendes Ereignis für FDPS.firstpid b '-' "FIRSTPID" pointcautra Besonderheit des französischen
Systems
flbk b '-' "FLBK" flightlevel Flugfläche des letzten Transakti-
onsbezugspunkts für einen aktivi-
erten Flug oder geänderte Höhe für
den Bezugspunkt einer Transaktion.
fpbaseid b '-'FPBASEID" datetime!seconds Kennung Flugplandatenbank.fpctst b '-' "FPCTST" fpcentrestate Flugplanstatus innerhalb einer FS-
Stelle.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Liste der bekannten, aber noch
nicht übergebenen Flugpläne für
eine Position.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Flugkategorie:
T = Überflug
E = Anflug
S = Abflug
I = intern.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Liste der Flugplaninformationen für
ein Rufzeichen.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Liste der Flugplanfelder.
fplnb b '-' "FPLNB" 1{DIGIT}1 Nummer der Flugpläne
von 0 bis 5
fplstat b '-' "FPLSTAT" "T" | "C" Flugstatus:
T = abgeschlossen
C = aktiv.
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Erste Flugplanbemerkungen.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"“|FIC-
PAC"|'FPL"|"RPL"|"NKW")Flugplanquelle.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Liste „unbekannter“ Flugpläne.
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Freitextnachricht.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Kennung des flexiblen Kurses.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Name des flexiblen Kurses.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Erzeugungsnummer des flexiblen
Kurses.2000R2082 — DE — 15.06.2002 — 001.001 — 136
▼B
Reser-
viertes
PrimärfeldArt Syntax Semantik
grspd b '-' "GRSPD" 1{DIGIT}4 Geschwindigkeit über Grund in
Knoten.
hldbkrw b '-' "HLDBKRW" 1{DIGIT}2 Positionsnummer eines Bezugs-
punktes für eine Warteschleife in
einer Liste von Streckenpunkten.
icing b '-' "ICING" 1{ALPHA}8 Vereisung.
„TRACE“ oder „LIGHT“ oder
„MODERATE“ oder „SEVERE“.
indstip b '-' "INDSTIP" 'STIP' Besonderheit des französischen
Systems
initid b '-' "INITID" 1{DIGIT}1 Initialisierungsnummer.interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Schnittstellenkennung FDPS/ODS
oder FDPS/Bereichssystem.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Liste der geographischen Breite
und Länge von Punkten auf der
Strecke.
lang b '-' "LANG" '?' Indikator Konversationssprache.
„?“ = Sprache im Unternehmen
nicht gebräuchlich
lastradt b '-' "LASTRADT" datetime Letzte Aktualisierungszeit durch
Radarinformation.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Befeuerungscode.maint b '-' "MAINT" 'YES'|'NO' Angabe, ob die Dateninformation
für eine Kontrollposition konti-
nuierlich gehalten wird oder nicht.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Information SSR Mode A.
modec b '-' "MODEC" flightlevel Information SSR Mode C.
msgbody b '-' "MSGBODY"
1{CHARACTER}Enthält eine Zeichenfolge, die mit
dem Textkörper der äquivalenten
und vorhandenen Nicht-ADEXP-
Nachricht identisch ist.
msgct b '-' "MSGCT" datetime ! seconds Zeitstempel der Nachricht im
Format: Tag, Stunden, Minuten,
Sekunden.
nat b '-' "NAT" 1{ALPHA}1 Kennung eines Nordatlantik-Flug-
wegs.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Nächster Frequenzkontakt.
nxtfir b '-' "NXTFIR" icaoaerodrome Nächstes zu kontaktierendes FIR.
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Nächste Position.
nxtpost b '-' "NXTPOST" datetime Überflugzeit der nächsten Position.
oclfl b '-' "OCLFL" flightlevel OCL-Flugfläche (Freigabegrenze
für ozeanisches Gebiet).
oprfl b '-' "OPRFL" flightlevel Von einem Flugbetriebsunter-
nehmen vorgenommene Änderung
der angeforderten Flugfläche.
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Liste von Bemerkungen des Flug-
betriebsunternehmens.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Bemerkungen des Flugbetriebsun-
ternehmens.
oriented b '-' "ORIENTED" 'YES'|'NO' Orientierter Flug oder nicht.pfl b '-' "PFL" flightlevel Geplante Flugfläche (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistRadarflugwegkoordinaten und
Geschwindigkeitsvektorkoordi-
naten.
pistid b '-' "PISTID" 1{DIGIT}4 Radarflugwegkennung.2000R2082 — DE — 15.06.2002 — 001.001 — 137
▼B
Reser-
viertes
PrimärfeldArt Syntax Semantik
pkarr c '-' "PKARR" [pka] [pkc] pkatt Parkposition für einen ankom-
menden Flug.
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Parkposition für einen abgehenden
Flug.
plnid b '-' "PLNID" 4{DIGIT}4 Flugplankennung.plnold b '-' "PLNOLD" 4{DIGIT}4 Alte Flugplankennung.
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Bewegungskoordinationsstatus für
die Position:
Akzeptierte Bewegung für Einflug
(MAE) oder Ausflug (MAS) oder
Vorgeschlagene Bewegung für
Ausflug (MPS) oder Vorgeschla-
gene Bewegung Ausflug Alarm
(MPSA) oder Position noch nicht
bewegungskoordiniert (NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Anzahl der Punkte in der Strecke.qfu b '-' "QFU" qfuid Kennung der zu benutzenden
Landebahn (QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Quebec-Flug oder nicht.
radioid b '-' "RADIOID"
1{ALPHANUM}20Funkkennung.
reqid b '-' "REQID" 1{DIGIT}5 Nummer einer Anfrage.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Art der Flugplananfrage.
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Liste der Stellen, die Flugplandaten
erhalten sollen.
ripsrc b '-' "RIPSRC" centreidentification Kennung der für die Einleitung der
Übermittlung von Flugplandaten
zuständigen FS-Stelle.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' IFPS-Transaktionsnummer in einer
Flugplananfrage.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Liste der CAUTRA-Punkte einer
nichtgelenkten Strecke.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Liste von Streckenpunkten für
bestimmte Transaktionen.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Liste von Flugplatzkonfigurationen.
secdest b '-' "SECDEST" secidentification Kennung empfangender Sektor.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Globale Liste von Sektoren.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Globale Liste der Sektoren.
secsrc b '-' "SECSRC" secidentification Kennung aufgebender Sektor.
spfl b '-' "SPFL" flightlevel Ergänzungsflugfläche.
ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Übermittelter SSR-Code.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmStempelkennung.
streason b '-' "STREASON" starreason Grund für die von einem Lotsen-
platz ausgegebene Initialisierungs-
anfrage.
strid b '-' "STRID" 1{DIGIT} RDPS-Kennung.temp b '-' "TEMP" temperature Temperatur.terminal b '-' "TERMINAL"
1{ALPHANUM}2Name des Zielflugplatzes.2000R2082 — DE — 15.06.2002 — 001.001 — 138
▼B
Reser-
viertes
PrimärfeldArt Syntax Semantik
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Liste möglicher Transaktionen für
die Kontrollposition und für den
angegebenen Flugplan.
trfl b '-' "TRFL" flightlevel | flightten-
dancyÜbergabeflugfläche oder Tendenz-
informationen über ein Flugprofil.
turb b '-' "TURB" 1{ALPHA}8 Turbulenz = LIGHT oder MODE-
RATE oder SEVERE
validend b '-' "VALIDEND" datetime Endzeit der Anzeige.
validst b '-' "VALIDST" datetime Startzeit der Anzeige.
visi b '-' "VISI" 1{ALPHANUM}20 Sicht.
wddir b '-' "WDDIR" 1{DIGIT}3 Windrichtung in Grad von 0 bis
359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Windgeschwindigkeit in Knoten.
xfl b '-' "XFL" flightlevel Ausflugfläche (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Antwortmeldung auf eine Flugpla-
nanfrage.
D.5.Reservierte Teilfelder
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Flugplanfelder, die
zum Zeitpunkt der
Aktivierung eines
Flugs veränderbar
sind.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxImplizite FL,
Mindest-FL und
maximale FL für den
Bezugspunkt einer
Transaktion. Die FL
ist generisch und
kann RFL, PFL usw.
lauten.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Wert (+/-), um den
eine zeitliche
Änderung an einem
Punkt zulässig ist.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxImplizite freigege-
bene Flugfläche
(CFL), Mindest-CFL
und maximale CFL
für den Bezugspunkt
einer Transaktion.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-Modus und
zugewiesener Code.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-Modus und
verfügbarer Code.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-Modus und
zuvor zugewiesener
Code.ssrcodes2000R2082 — DE — 15.06.2002 — 001.001 — 139
▼B
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-Modus und
Code, der zur
Verwendung reser-
viert wurde und
daher nicht verfügbar
ist.ssrcodes
coorpt b '-' "COORPT" coord-
pointsEigenschaft des
Koordinierungs-
punkts: Initial, Exit,
OCL, XFL.ptc
ctdest b '-' "CTDEST"
centreidentificationEmpfangende FS-
Stelle (ACC).destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITZeitintervall für die
Berechnung einer
Mindestzeit.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITZeitintervall für die
Berechnung einer
Maximalzeit.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Geschwindigkeitsin-
tervall für die
Berechnung einer
Mindestgeschwindig-keit.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Geschwindigkeitsin-
tervall für die
Berechnung einer
Höchstgeschwindig-
keit.spdchg
destid c '-' "DESTID" ctdest
secripATC-Stelle und Liste
der Sektoren, an die
Flugplandaten zu
senden sind.ripel
edto b '-' "EDTO" dateti-
me|"WT"Voraussichtliche
Überflugzeit eines
Punktes in Jahr,
Monat, Tag, Stunden,
Minuten oder Indi-
kator „Punkt ohne
Zeit“„WT“.ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationName der operatio-
nellen Stellen.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Liste der mit einer
Kontrollposition
zusammenhängenden
operationellen
Stellen.eopos
eopos c '-' "EOPOS" posid
[eolist]Name der Kontroll-
position und Liste der
mit ihr zusammen-
hängenden operatio-
nellen Stellen.confl
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'-
RTE'|'ADEP'|'CO-
DE'|'LAN-
G'|'BK'|spdchg|rflch-
g|cflchg|pflchg|tflch-
g|sflchg|xflchg|bkch-
g|bktchg|'QFU'|'PK-
DEP'|'SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Kennung veränder-
barer Felder für eine
Transaktion.act
mod
mvt
ret
modh2000R2082 — DE — 15.06.2002 — 001.001 — 140
▼B
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
flb b '-' "FLB" flightlevel Errechnete Flugfläche
am Ausflugkoordinie-
rungspunkt, die in der
automatischen Koor-
dinierungsmeldung
an die nächste FS-
Stelle übermittelt
werden kann.automsg
flimp b '-' "FLIMP" flight-
levelImplizite Flugfläche. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" flight-
levelMaximale Flugfläche. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" flight-
levelMindestflugfläche. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbFlugplankennung in
einer Nachricht.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobt„Zusammenfassung“
der Flugplandaten.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidFlugplankennung. fplist
lalg c '-' "LALG" lattd
longtdGeographische Breite
und Länge der
einzelnen Punkte auf
der Strecke.laglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Liste der nach Akti-
vierung veränder-
baren Felder.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Liste der Felder, die
nach Aktivierung in
einer zeitlichen
Aktualisierungstrans-
aktion veränderbar
sind.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Liste der Felder, die
in einer manuell
ausgelösten Koordi-
nierung zwischen den
Sektoren veränderbar
sind.transid
pflchg c '-' "PFLCHG" flimp
flmin flmaxImplizite, Mindest-
und maximale
Flugfläche für
Änderung der PFL.fieldid2000R2082 — DE — 15.06.2002 — 001.001 — 141
▼B
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Geplante Flugfläche,
die in der automati-
schen Koordinie-
rungsmeldung an die
nächste FS-Stelle
übermittelt wird.
Dazu eine Angabe,
ob die Flugfläche den
geltenden operatio-
nellen Vereinba-
rungen entspricht.
NA = nicht gemäß
Vereinbarungautomsg
pka b '-' "PKA"
1{ALPHANUM}3Reservierte Parkposi-
tion, noch nicht
zugewiesen.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indikator, dass das
Luftfahrzeug auf
Parkposition wartet.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Zugewiesene Parkpo-
sition.pkarr
pointid b '-' "POINTID" point-
cautraBesonderheit des
französischen
Systems.ptpro
posid b '-' "POSID" positioni-
dentificationName der Kontroll-
position.eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Merkmale eines
Streckenpunktes.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameBesonderheit des
französischen
Systems.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Beschreibung der
vorgeschlagenen
Streckenpunkte.rtetr
qful c '-' "QFUL" qfuid Gültige QFU für eine
bestimmte Landebahn
auf einem Flugplatz.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Liste gültiger QFU
für einen Flugplatz.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Allgemeine Start-
und Landerichtung
für einen Flugplatz
(Ost, West usw.)acnf
ref c '-' "REF" (refi-
d|ref1id)Merkmale eines
Bezugspunktes für
eine Transaktion.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Kennung eines
möglichen Bezugs-
punktes für eine
Transaktion.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Kennung des wahr-
scheinlichsten
Bezugspunktes für
eine Transaktion.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Maßnahmeinforma-
tion, französisches
System.regul
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Maßnahmeinforma-
tion, französisches
System.regul2000R2082 — DE — 15.06.2002 — 001.001 — 142
▼B
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
regult b '-' "REGULT" date-
timeMaßnahmeinforma-
tion, französisches
System.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Liste der Felder, die
in einer Transaktion
zur Rückführung der
Flugplandaten auf
ihren vorherigen
Status veränderbar
sind.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxImplizite, Mindest-
und maximale
Flugfläche für
Änderung der RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Text einer Lotsenbe-
merkung.oprmk
sec c '-' "SEC" secid
[seccar]Kennung und Merk-
male der ACC-
Sektoren, an die
Flugplandaten zu
senden sind.seclist secrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Charakteristik eines
ACC-Sektors:
— Erster Sektor
(„F“)
— Letzter Sektor
(„L“)
— Für Einflug
akzeptiert („M“)
— Quellensektor für
„Duplizierung“ („D“)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Charakteristik eines
Nahbereichssektors:
Erster Sektor („F“)
— Letzter Sektor
(„L“)
— Für Einflug
akzeptiert („M“)secct
secct c '-' "SECCT" secid
[seccarct]Kennung und Merk-
male von Nahbe-
reichssektoren.seclistct
secid b '-' "SECID" secident-
ificationSektorkennung. secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Liste empfangender
Stellen (Sektoren
oder Abflug-/
Anflugkontroll-
stellen), an die Flug-
plandaten zu senden
sind.destid
sendt b '-' "SENDT" datetime Zeit für die Sendung
der Koordinierungs-
meldung.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxImplizite, Mindest-
und maximale
Flugfläche für
Änderung der ergän-
zenden Flugfläche
(SFL)fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Obere und untere
Geschwindigkeitsin-
tervalle für die
Änderung der Flug-
plangeschwindigkeit
während einer Trans-
aktion.fieldid2000R2082 — DE — 15.06.2002 — 001.001 — 143
▼B
Reservierte
TeilfelderArt Syntax SemantikVerwen-
dung in
PrimärfeldVerwen-
dung in
Teilfeld
tflchg c '-' "TFLCHG" flimp
flmin flmaxImplizite, Mindest-
und maximale
Flugfläche für
Änderung der Überg-
abeflugfläche (TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Merkmale eines
Punktes in bezug auf
die Flugbahn:
S = Splitpoint
M = Mergepoint
T = Abeam point
A = STAR pointptc
ptpro
transid b '-' "TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Kennung einer
möglichen Transak-
tion der Kontrollposi-
tion für diesen
Flugplan oder Indi-
kator „NO“ für
„Transaktion nicht
möglich“.translist
txt b '-' "TXT"
1{LIM_CHAR}80Frei wählbarer Text. freetxt
udpt b '-' "UDPT" update-
reasonLetzte Aktualisierung
durch Flugbetriebsun-
ternehmen und/oder
Radarinformation.ptc
view b '-' "VIEW"
('V'|'VNX')Angabe der Sichtbar-
keit eines Punktes.
V = sichtbar
VNX = nicht sichtbar
(künstlicher Punkt)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeX-Koordinate des
Geschwindigkeitsvek-
tors einer Radarposi-
tion.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeY-Koordinate des
Geschwindigkeitsvek-
tors einer Radarposi-
tion.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxMindest- und maxi-
male Flugfläche für
Änderung der
Ausflugfläche (XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positif
N:= NegativeX-Koordinate einer
Radarposition.pistcoord
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= NegativeY-Koordinate einer
Radarposition.pistcoord2000R2082 — DE — 15.06.2002 — 001.001 — 144
▼B
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 voll-
stä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 Schnittstel-
lenspezifikation) 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 Dateneinset-
zungsregeln 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 9803051231522000R2082 — DE — 15.06.2002 — 001.001 — 145
▼B
-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 Dateneinset-
zungsregeln 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 -POSI-
TION -PTID LIFFY -TO 16462000R2082 — DE — 15.06.2002 — 001.001 — 146
▼B
E.3. ATC-Koordinierungsmeldungen
E.3.1. Einleitung
Koordinierungsmeldungen dienen der Automatisierung der operatio-
nellen Koordinierung und des Informationsaustauschs zwischen
ATC-Stellen. Die Meldungen sorgen für eine rechtzeitige Zustellung
operationeller Koordinierungsinformationen durch genormte Datenex-
traktion 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 Luftraumma-
nagements. 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
1998033006002000R2082 — DE — 15.06.2002 — 001.001 — 147
▼B
-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 mili-
tä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 0122000R2082 — DE — 15.06.2002 — 001.001 — 148
▼B
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 Verwen-
dung 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 über-
lassen. 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 LBSF2000R2082 — DE — 15.06.2002 — 001.001 — 149
▼B
-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 -ETO980317074449 -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 -PTID2000R2082 — DE — 15.06.2002 — 001.001 — 150
▼B
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 TALAS2000R2082 — DE — 15.06.2002 — 001.001 — 151
▼B
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 „über-
springen“ 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 Flexibi-
lität ist einer der Vorzüge des ADEXP-Formats.
Dieses Ziel wird in der derzeitigen Norm durch die Verwendung vorge-
gebener, durch eindeutige Schlüsselwörter eingeleitete Primär- und
Teilfelder erreicht. Ein lexikalischer Analysator (Parser), der ein Schlüs-
selwort nicht „erkennt“, muss den gesamten Text bis zum nächsten
bekannten Primärfeld ignorieren, das sich nicht innerhalb eines Listen-
felds 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 vorgeschla-
genen Ä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 belie-
bigen 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 Fest-
stellung 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
Derzeitiges Format Vorgeschlagenes Format
Beispiel für Basisfeld: -RFL F330 (RFL F330)Beispiel für Verbundfeld: -CRSCLIMB
-PTID DUB-CRSPEED M084
-CRFL1 F370
-CRFL2 F430(CRSCLIMB
(PTID DUB)(CRSPEED M084)
(CRFL1 F370)
(CRFL2 F430))2000R2082 — DE — 15.06.2002 — 001.001 — 152
▼B
ANHANG III
FLUGDATENAUSTAUSCH-SCHNITTSTELLENSTEUERUNGSDOKU-
MENT (FDE-ICD), AUSGABE 1.0
(Eurocontrol-Fundstelle COM.ET1.ST12-STD)2000R2082 — DE — 15.06.2002 — 001.001 — 153
▼B
INHALTSVERZEICHNIS
URHEBERRECHTLICHER HINWEIS
VORWORT1. EINLEITUNG2. GELTUNGSBEREICH3. VERWEISE
3.1. Einleitung3.2. Verweise
4. DEFINITIONEN, SYMBOLE UND ABKÜRZUNGEN
4.1. Definitionen4.2. Symbole und Abkürzungen4.3. Notation
5. TECHNISCHER ÜBERBLICK
5.1. Protokoll-Stack5.2. Struktur des Profils5.3. Beziehung zu früheren Versionen der Spezifikation
6. PROFILANFORDERUNGEN
6.1. Konformitätsanforderungen6.2. Anforderungen bezüglich der oberen Schichten6.3. Anforderungen bezüglich der unteren Schichten6.3.1. Transportschichtanforderungen6.3.2. Vermittlungsschichtanforderungen6.3.3. Sicherungsschichtanforderungen6.3.4. Bitübertragungsschichtanforderungen
7. PRÜFMETHODENANHANG A (NORMATIV) NACHRICHTENÜBERTRAGUNGSPROTOKOLL
A.1. EinleitungA.2. Implementierter DienstA.3. Übernommener DienstA.4. Protokoll-SpezifikationA.4.1. EinleitungA.4.2. DatenartenA.4.3. AssoziationsaufbauA.4.4. DatenübertragungA.4.5. Regulärer AssoziationsabbauA.4.6. Wiederaufbau der AssoziationA.4.7. Integrität der AssoziationA.4.8. Irregulärer AssoziationsabbauA.4.9. Wiederherstellung nach Ausfall2000R2082 — DE — 15.06.2002 — 001.001 — 154
▼B
A.4.10. Nachrichtenformate
A.5. ProtokollzustandstabellenA.5.1. Einleitung
A.5.2. Zustandsdefinitionen
A.5.3. Mögliche EreignisseA.5.4. ZeitgeberA.5.5. ZustandsübergangstabelleA.5.6. Zustandsdiagramm
ANHANG B (NORMATIV) NACHRICHTENKOPFPROTOKOLL
B.1. EinleitungB.2. Implementierter DienstB.3. Übernommener DienstB.4. ProtokollspezifikationB.4.1. VerbindungsaufbauB.4.2. Vermeidung redundanter NetzverbindungenB.4.3. VerbindungsabbauB.4.4. Datenübertragung
ANHANG C (NORMATIV) VERMITTLUNGSPROTOKOLL
C.1. EinleitungC.2. Bereitgestellter DienstC.3. Übernommener DienstC.4. NSAP-AdressierungC.4.1. EinleitungC.4.2. NSAP-AdressenstrukturC.4.3. Zuweisung von ATC-Stellenkennungen und -wählernC.5. ProtokollspezifikationC.5.1. ÜberblickC.5.2. AdresscodierungC.5.3. Codierung des Nutzdatenfeldes
C.5.4. Behandlung von Adressen in INCOMING CALL-Paketen
C.5.5. Datenübertragung
ANHANG D (NORMATIV) PROFILSPEZIFISCHE PICS-FORMULARE
D.1. Einleitung
D.2. Anweisungen zum Ausfüllen der PICS-Formulare
D.2.1. Allgemeiner Aufbau der PICS-FormulareD.2.2. ZusatzinformationenD.2.3. EinwandinformationenD.2.4. Bedingte PositionenD.3. PICS-Formular für das NachrichtenübertragungsprotokollD.3.1. Abkürzungen und Sonderzeichen2000R2082 — DE — 15.06.2002 — 001.001 — 155
▼B
D.3.2. Kennblatt
D.3.3. Protokollimplementierung
D.4. PICS-Formular für das NachrichtenkopfprotokollD.4.1. Abkürzungen und SonderzeichenD.4.2. StatuszeichenD.4.3. ProtokollimplementierungD.5. PICS-Formular für das VermittlungsprotokollD.5.1. Abkürzungen und SonderzeichenD.5.2. Statuszeichen
D.5.3. Protokollimplementierung
ANHANG E (NORMATIV) LISTE DER PROFILANFORDERUNGEN
E.1. EinleitungE.2. Die Rolle der PRL und PICS-FormulareE.3. NotationE.4. Anweisungen für das Ausfüllen der PICS-FormulareE.5. VerweiseE.6. KonformitätserklärungE.6.1. Konformitätsüberblick
E.6.2. Dynamische Konformitätsanforderungen
E.7. Anforderungen bezüglich der oberen SchichtenE.8. Anforderungen bezüglich der unteren SchichtenE.8.1. TransportschichtanforderungenE.8.2. Allgemeine DEE-KenndatenE.8.3. SicherungsschichtanforderungenE.8.4. Bitübertragungsschichtanforderungen
ANHANG F (INFORMATIV) METHODIK DER KONFORMITÄTSRPÜFUNG
F.1. Einleitung
F.2. Zweck und Anwendungsbereich
F.3. BibliographieF.4. Entwicklungsmethoden und -praktikenF.5. PrüfungenF.5.1. EinleitungF.5.2. Prüfung der unteren Schichten (Schicht 1–3)F.5.3. Prüfung der AnwendungsschichtF.5.4. Zertifizierung
F.5.5. Meldung
ANHANG G (INFORMATIV) ZUWEISUNG VON ATC-STELLENKENNUNGEN
ANHANG H (INFORMATIV) HINWEISE ZU VERLÄSSLICHKEIT, VERFÜGBARKEIT UND
SICHERHEIT
H.1. Einleitung2000R2082 — DE — 15.06.2002 — 001.001 — 156
▼B
H.2. Zweck und Anwendungsbereich
H.3. BibliographieH.4. Standleitungsimplementierungen
H.4.1. Verlässlichkeit
H.4.2. VerfügbarkeitH.4.3. SicherheitH.4.4. KonfigurationsbeispielH.5. NetzimplementierungH.5.1. VerlässlichkeitH.5.2. VerfügbarkeitH.5.3. SicherheitH.6. Allgemeine Hinweise für Standleitungs- und NetzimplementierungenH.6.1. VerlässlichkeitH.6.2. VerfügbarkeitH.6.3. SystemmanagementH.6.4. Konfigurationsbeispiel2000R2082 — DE — 15.06.2002 — 001.001 — 157
▼B
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 Mitglied-
staaten somit frei zur Verfügung; jede Abschrift oder Offenlegung an
andere bedarf jedoch der vorherigen schriftlichen Einwilligung der Agentur
Eurocontrol.2000R2082 — DE — 15.06.2002 — 001.001 — 158
▼B
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 Fernmeldeverbin-
dungen, 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 Rich-
tlinien 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-Normungs-
dokumente.
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 ANMER-
KUNG 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-Schnittstellensteu-
erungsdokumenten (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 — Normativ2000R2082 — DE — 15.06.2002 — 001.001 — 159
▼B
— 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.2000R2082 — DE — 15.06.2002 — 001.001 — 160
▼B
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 Proto-
kollen 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 überzu-
gehen. 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 forma-
lisiert und erweitert. Bei der Neuabfassung wurde Wert auf eine
strengere Spezifikation gelegt, die eine Verbesserung der Inter-
operabilitä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 gemein-
samer Netze und der Einführung neuer Normen für die unteren
Schichten, eignet. Diese Eurocontrol-Norm enthält ein Mindest-
paket 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 weitereMö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 Anwen-
dungsprotokolle einsetzen möchten, können entweder eine
Ergänzung des vorliegenden Protokolls beantragen oder ihr Proto-
koll unter Verwendung unterschiedlicher virtueller Leitungen
abtrennen.
2. GELTUNGSBEREICH
2.1. Im vorliegenden Eurocontrol-Normendokument ist eine Daten-
übertragungsschnittstelle für den Austausch vonFlugdatennachrichten 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 Elek-
trotechnischen 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-Anwendungsnach-
richten 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.2000R2082 — DE — 15.06.2002 — 001.001 — 161
▼B
2. Nicht in Figure 1 dargestellt sind potentielle Ersatzverbin-
dungen, wie z. B. PSTN; Hinweise dazu enthält Anhang H.
Figure 1
Schnittstellenanordnung
2.4. Die einzelnen Sicherheitsaspekte der spezifizierten Datenübertra-
gungsschnittstelle 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-Normen-
dokuments waren die für die Verweisdokumente und -normen
angegebenen Ausgaben gültig.
Jede Überarbeitung der Verweisdokumente der Internationalen
Zivilluftfahrt-Organisation (ICAO) gilt unmittelbar als Überarbei-
tung dieses Eurocontrol-Normendokuments.
Überarbeitungen der anderen Verweisdokumente werden erst zum
Bestandteil der Bestimmungen dieses Eurocontrol-Normendoku-
ments, wenn sie formal überprüft und in dieses Eurocontrol-
Normendokument eingearbeitet worden sind.
Bei Widersprüchen zwischen den Anforderungen dieses Eurocon-
trol-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 dedi-
cated 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).2000R2082 — DE — 15.06.2002 — 001.001 — 162
▼B
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 — Telecommu-
nications 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 — Inter-
national 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 — Telecommu-
nications 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),
No001-92, Edition 1, 1992.
14. ISO/IEC 9646-1:1994, Information technology — Open
Systems Interconnection — Conformance testing methodo-
logy 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-swit-
ched signalling system between public network providing
data transmission service.
20. ITU-T Recommendation X.121 (1993), International numbe-
ring 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 gege-
benenfalls die Angabe der gewählten Klassen, Teilmengen,2000R2082 — DE — 15.06.2002 — 001.001 — 163
▼B
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
Im Sinne dieses Eurocontrol-Normendokuments werden die
folgenden Symbole und Abkürzungen verwendet:
ACC Area Control Centre — Bezirkskontrollstelle
AFI Authority and Format Identifier — Zutei-
lungsstellen- und Formatkennung
ASCII American Standard Code for Information
Interchange
ATC Air Traffic Control — FlugverkehrskontrolleATCC Air Traffic Control Centre — Flugverkehrs-
kontrollstelle
CAUTRA Coordinateur Automatique du Trafic Aérien
CCITT Comité consultatif international télégra-
phique et téléphonique (jetzt ITU-T)
CFMU Central Flow Management Unit — Zentrale
Verkehrsflussregelungsstelle
CUG Closed User Group — Geschlossene Benut-
zergruppe
DCTS Digital Communications Terminal System
DEE DatenendeinrichtungDSP Domain Specific Part — Bereichsspezifi-
scher Adressteil
DÜE DatenübertragungseinrichtungDÜV Datenübertragungs- und -verteilungssystem
FDE Flight Data Exchange — Flugdatenaus-
tausch
FEP Front-End-ProzessorFPDE Flight Plan related Data Exchange — Flug-
planbezogener Datenaustausch
FPPS Flight Plan Processing System — Flugplan-
verarbeitungssystem
ICAO International Civil Aviation Organisation —
Internationale Zivilluftfahrt-Organisation
ICD Interface Control Document — Schnittstel-
lensteuerungsdokument
IDI Initial Domain Identifier — Kennung des
Adressierungsbereichs
IDP Initial Domain Part — Zuteilungsstellen-
und Bereichskennung
IEC International Electrotechnical Commission
— Internationale Elektrotechnische
Kommission
INTERCAUTRA Inter-CAUTRA-ProtokollISDN Integrated Services Digital Network —
Diensteintegrierendes Digitalnetz
ISO International Organization for Standardiza-
tion — Internationale Organisation für
Normung
ITU-T International Telecommunication Union —
Telecommunication Standardization Sector2000R2082 — DE — 15.06.2002 — 001.001 — 164
▼B
LAPB Link Access Procedure Balanced — Gleich-
berechtigtes Übermittlungsverfahren
LSB Least Significant Bit — Niedrigstwertiges
Bit
M, m Mandatory — Vorgeschrieben
MSB Most Significant Bit — Höchstwertiges Bit
MT Message Transfer — Nachrichtenübertra-
gung
NA Not Applicable — keine Angabe, nichtzu-
treffend
NS Network Service — VermittlungsdienstNSAP Network Service Access Point — Vermitt-
lungsdienstzugangspunkt
NSDU Network Service Data Unit — Vermitt-
lungsdienstdateneinheit
O, O.<n> Optional, wobei <n> ein Referenziernume-
rales ist
o, o.<n> Optional, wobei <n> ein Referenziernume-
rales ist
OLDI On-Line Data Interchange — Online-Daten-
austausch
OSI Open Systems Interconnection — Kommu-
nikation offener Systeme
PICS Protocol Implementation Conformance
Statement — Erklärung zur Konformität
der Protokollimplementierung
PLP Packet Layer Protocol — Paketschichtproto-
koll
PRL Profile Requirements List — Liste der Profi-
lanforderungen
PSTN Public Switched Telephone Network —
Öffentliches Telefonwählnetz
ST-ICD Short Term Interface Control Document —
Kurzfristiges Schnittstellensteuerungsdoku-
ment
SUT System Under Test — System in Prüfung
T<x> Timer (wobei <x> ein einfacher oder
doppelter Referenzierbuchstabe ist)
TA Terminal Adaptor — EndgeräteanpassungTSDU Transport Service Data Unit — Transport-
dienstdateneinheit
TPDU Transport Protocol Data Unit — Protokol-
ldateneinheit der Transportschicht
TR ISO Technical Report — Technischer
Bericht der ISO
X Prohibited — Verboten
x Excluded — Ausgeschlossen
<Position> Bedingte Position (in Abhängigkeit des
Positionswertes)
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.2000R2082 — DE — 15.06.2002 — 001.001 — 165
▼B
M, O, O.<n>, X). Die genaue Bedeutung des jeweiligen Status-
zeichens 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 Unter-
stü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 Euro-
control-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-Basisre-
ferenzmodells [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
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.2000R2082 — DE — 15.06.2002 — 001.001 — 166
▼B
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
ANMERKUNGEN1. Dieses Profil basiert auf dem von der ehemaligen Technischen
Untergruppe OLDIentwickelten ST-I CD. Die in diesem Euro-
control-Normendokument definierten Protokolle und
Paketformate sind eine kompatible Teilmenge der in ST-ICD
enthaltenen. Der Unterschied besteht darin, dass diese Euro-
control-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 Nach-
richtenkopfprotokoll (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 erfüllen.
6.1.2. (NE) Ein Konformitätsanspruch muss durch eine in Anhang D
und Anhang E beschriebene Erklärung zur Konformität der Proto-
kollimplementierung 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 erfüllen.
6.2.2. (NE) Eine konforme Implementierung muss die in der Liste der
Profilanforderungen in Anhang E.7 aufgeführten Vorgaben
erfüllen.
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 erfüllen.
6.3.1.2. (NE) Eine konforme Implementierung muss die in der Liste der
Profilanforderungen in Anhang E.8.1 aufgeführten Vorgaben
erfüllen.
6.3.1.3. (NE) Eine konforme Implementierung muss die Anforderung der
Unterstützung von TSDU-Größen bis einschließlich 4 097 Oktette
erfüllen.
ANMERKUNG Das erste Oktett der TSDU entspricht einem
Feld des Nachrichtenkopfes (siehe A.4.10 und
B.4.4), so dass maximal 4 096 Oktette für Benut-
zerdaten verbleiben.2000R2082 — DE — 15.06.2002 — 001.001 — 167
▼B
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 erfüllen.
6.3.2.2. (NE) Eine konforme Implementierung muss die in der Liste der
Profilanforderungen in Anhang E.8.2 aufgeführten Vorgaben
erfüllen.
6.3.2.3. (NE) Wird ein DEE-DEE-Betrieb unterstützt, muss eine
konforme Implementierung in der Lage sein, durch Systemmana-
gementmechanismen 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 erfüllen.
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-Markie-
rung 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ätsan-
forderungen von ISO/IEC 7776 [Verweisdokument 6] für das
LAPB-Einzelstreckenprotokoll (Gleichberechtigtes Übermitt-
lungsverfahren) erfüllen.
6.3.3.2. (NE) Eine konforme Implementierung muss zudem die in der
Liste der Profilanforderungen in Anhang E.8.3 aufgeführten
Vorgaben erfüllen.
6.3.4. Bitübertragungsschichtanforderungen
(NE) Eine konforme Implementierung muss die Konformitätsan-
forderungen von ISO/IEC ISP 10609-9 clause 7
[Verweisdokument 8] erfüllen.
7. PRÜFMETHODEN
ANMERKUNGEN1. Ein Ansatz für die Konformitätsprüfung von Implementie-
rungen dieser Spezifikation ist in Anhang F kurz dargestellt.
2. Eine Kurzdarstellung zur Verwendung der mit dieser Spezifi-
kation bereitgestellten PRL und PICS-Formulare zur
Dokumentierung der Konformität findet sich in Anhang E.2000R2082 — DE — 15.06.2002 — 001.001 — 168
▼B
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 Nach-
richt;
MT-Abort : Abbruch einer Übertragungszuordnung für eine Anwen-
dungsnachricht.
A.3. Übernommener Dienst
Dieses Nachrichtenübertragungsprotokoll übernimmt eine Teil-
menge des verbindungsorientierten Transportdienstes nach ISO/IEC
8072 [Verweisdokument 11], wie sie z. B vom in dieser Eurocon-
trol-Norm definierten Protokoll angeboten wird.
A.4. Protokoll-Spezifikation
A.4.1. Einleitung
Im nachfolgenden Text wird nur der Betrieb von einer anwendungs-
initiierten 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 Übermitt-
lungsü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-Normendoku-
ment für den Online-Datenaustausch definiert operationelle
Nachrichten wie die Aktivierungsmeldung (ACT), die Vorabinfor-
mationen ü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
ANMERKUNGEN1. 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 bila-
teralen Vereinbarungen und werden in dieser Eurocontrol-Norm
nicht weiter spezifiziert.2000R2082 — DE — 15.06.2002 — 001.001 — 169
▼B
3. Vom Zustand des Protokolls hängt es ab, welche Nachrichten-
typen ü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 beschrie-
benen 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 Übertra-
gung 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-Nach-
richt) 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 ASSO-
CIATION_PENDING, bis eine STARTUP-
Nachricht empfangen wird. Ständige Zeitüber-
schreitungen 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-Asso-
ciate-Indication wird signalisiert;
— in jedem anderen Zustand wird die Nachricht ignoriert.
A.4.3.6. Der Empfang der STARTUP-Nachricht im Zustand ASSOCIA-
TION_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 igno-
riert.
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 Dienstele-
menten 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.2000R2082 — DE — 15.06.2002 — 001.001 — 170
▼B
A.4.5. Regulärer Assoziationsabbau
A.4.5.1. Die Nachrichtenübertragungsassoziation zwischen zwei Anwen-
dungen 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 SHUT-
DOWN-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 Schnitt-
stelle 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 Transportverbin-
dung 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 Zeit-
geber 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 Transportproto-
kolls in Anhang B gibt es keine durchgehende
Transportverbindung. Daher ist der Ausfall der2000R2082 — DE — 15.06.2002 — 001.001 — 171
▼B
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-Nach-
richt (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 Wiederherstel-
lung der Strecke unternommen wird. Damit wird
der Zeitsperrprozess (Time-Out) des Tr der
entfernten Anwendung abgekürzt und unter
Umständen eine schnellere Wiederherstellung erre-
icht, ohne dass zu viele Daten verlorengehen.
A.4.10. Nachrichtenformate
A.4.10.1. Allgemeine Struktur von Nachrichten
Alle Nachrichten bestehen aus einem ganzzahligen Typfeld („TYP“)
mit dem Bereich 1…63, gefolgt vom Hauptteil der Nachricht. Das
„TYP“-Feld ist durch Hinzufügen von '40'H zur binären Darstellung
des Felds in einem Oktett als ASCII-Zeichen codiert (z. B. ist der
Wert 3 als '43'H, Zeichen 'C' codiert). Der Hauptteil besteht aus
einem je Oktett codierten ASCII-Zeichen. Somit entsteht folgendes
Format:
TYP Hauptteil der Nachricht
Oktett 1 Oktett 2 …Oktett n
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
Systemnachrichten haben den Code TYP = 4, codiert als '44'H. Der
Hauptteil besteht aus zwei wie folgt codierten Oktetten:
— STARTUP-Nachricht: '3031'H (ASCII digits "01");
— SHUTDOWN-Nachricht: '3030'H (ASCII digits "00");
— HEARTBEAT-Nachricht: '3033'H (ASCII digits "03").
A.4.10.4. Andere Nachrichtenformate
Das Feld TYP definiert den Nachrichtentyp mit wie oben beschrie-
bener Codierung:
— Wert 1 (codiert als '41'H) operationelle Nachrichten;
— Wert 2 (codiert als '42'H) Betreibernachrichten;— Wert 5 (codiert als '45'H) Statusnachrichten.
ANMERKUNGEN
1. Das Format des Hauptteils von Statusnachrichten liegt außer-
halb des Geltungsbereichs dieses Eurocontrol-Normendokuments.2000R2082 — DE — 15.06.2002 — 001.001 — 172
▼B
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 Benutzer-
oberfläche bereitgestellt werden, um empfangene Nachrichten
anzuzeigen und um die Erstellung von Nachrichten zur Übertra-
gung 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 Defini-
tionen und daraus resultierenden Aktionen sindjedoch überarbeitet worden und können daher
vom ST-ICD abweichen.
A.5.2. Zustandsdefinitionen
Tabelle 1
Zustandsdefinitionen
Zustand Zustandsbeschreibung Zusätzliche Zustandsinformationen
Zustand 0 IDLE Keine Transportverbindung
Zustand 1 READY Transportverbindung aufgebaut,
lokaler Benutzer ab, entfernter
Benutzer ab
Zustand 2 ASSOCIATION_PEN-
DINGTransportverbindung aufgebaut,
lokaler Benutzer an, entfernter
Benutzer ab
Zustand 3 DATA_READY Lokaler Benutzer an, entfernter
Benutzer an
A.5.3. Mögliche Ereignisse
Tabelle 2
Mögliche Ereignisse
Ereignisbeschreibung Zusätzliche Zustandsinformationen
L_data Anzeige, dass Daten (operationelle, Betreiber- oder Statusnach-
richt) vom lokalen zum entfernten Benutzer gesendet werden
sollen (Dienstelement MT-Data Request)
L_shutdown Befehlserteilung zum Stoppen des lokalen Benutzers (MT-Abort
Request)
L_startup Befehlserteilung zum Starten des lokalen Benutzers (MT-Asso-
ciate Request)
R_data Zeigt an, dass Daten vom entfernten Benutzer empfangen worden
sind (T-Daten-Anzeige, TYP ≠„System“)
R_heartbeat Eine HEARTBEAT-Nachricht vom entfernten Benutzer wird
empfangen (T-Daten-Anzeige, TYP = „System“, Nachrichtencode
= HEARTBEAT)
R_shutdown Eine SHUTDOWN-Nachricht vom entfernten Benutzer wird
empfangen (T-Daten-Anzeige, TYP = „System“, Nachrichtencode
= SHUTDOWN)
R_startup Eine STARTUP-Nachricht vom entfernten Benutzer wird
empfangen (T-Data Indication, TYP = „System“, Message code =
STARTUP)2000R2082 — DE — 15.06.2002 — 001.001 — 173
▼B
Ereignisbeschreibung Zusätzliche Zustandsinformationen
Ts_timeout Ablauf des Zeitgebers Ts
Tr_timeout Ablauf des Zeitgebers Tr
TC_disconnect Eine Transportverbindungsabbau-Anzeige ist empfangen worden
(T-Verbindungsabbau-Anzeige)
TC_setup Ereignis (z. B. expliziter Befehl, Anwendungsanfrage), das ein
Dienstelement T-Verbindungsaufbau-Anforderung bewirkt.
A.5.4. Zeitgeber
Tabelle 3
Zeitgeber
Zeitgeber Zeitgeberinformationen
Tr Zeitüberwachung bei Erwartung einer HEARTBEAT- oder Daten-
nachricht
Ts Zeitüberwachung für die Sendung eines HEARTBEAT zum
entfernten Benutzer
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
Zustand Ereignis AktionenNeuer
Zustand
Zustand 0 TC_setup Die Transportschicht versucht, die
Verbindung(en) der unteren
Schichten zwischen lokalem und
entferntem Benutzer aufzubauen;
nach erfolgreichem Aufbau wird
der Benutzer benachrichtigt (1)Zustand 1
TC_disconnect Das System ergreift die geeigneten
Maßnahmen, verbleibt aber in
Zustand 0Zustand 0
L_data Ignoriert Zustand 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignorieren (Ereignis sollte nicht
eintreten)Zustand 0
R_heartbeat
R_shutdown
R_startup2000R2082 — DE — 15.06.2002 — 001.001 — 174
▼B
Zustand Ereignis AktionenNeuer
Zustand
Zustand 1 L_startup Der lokale Benutzer sendet eine
STARTUP-Nachricht an den
entfernten Benutzer, Zeitgeber Tr
wird gestartet (2)Zustand 2
R_startup Der lokale Benutzer empfängt eine
STARTUP-Nachricht vom
entfernten Benutzer, diese
STARTUP-Nachricht wird igno-
riert, da ein L_startup-Ereignis
nicht eingetreten istZustand 1
L_data Ignoriert Zustand 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignoriert Zustand 1
Ts_timeout
L_shutdown Die Transportverbindung wird
ausgelöst.Zustand 0
TC_disconnect Der lokale Benutzer wird benach-
richtigt, dass die Transportverbin-
dung abgebaut wird (z. B.
aufgrund eines Fehlers oder einer
entfernten Abschaltung)Zustand 0
Zustand 2 R_startup Der lokale Benutzer empfängt eine
STARTUP-Nachricht vom
entfernten Benutzer; die Zeitgeber
Tr und Ts werden gestartet; der
lokale Benutzer wird benachrich-
tigt, dass Daten über die Assozia-
tion gesendet werden können, und
der Empfang der STARTUP-
Nachricht wird durch Antwort mit
einer weiteren STARTUP-Nach-
richt ausdrücklich bestätigt (3)Zustand 3
Tr_timeout Der lokale Benutzer sendet erneut
eine STARTUP-Nachricht, wenn
er innerhalb eines bestimmten
Zeitraums Tr keine STARTUP-
Nachricht vom entfernten Benutzer
erhalten hat; Zeitgeber Tr wird
neugestartetZustand 2
L_startup Ignoriert Zustand 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown Der lokale Benutzer wird ange-
wiesen, die Assoziation herunter-
zufahren: es wird eine
SHUTDOWN-Nachricht gesendet,
der Zeitgeber Tr wird gestoppt und
die Transportverbindung abgebautZustand 0
TC_disconnect Der lokale Benutzer wird benach-
richtigt, dass die Transportverbin-
dung abgebaut wird (z. B.
aufgrund eines Fehlers), der Zeit-
geber Tr wird gestoppt und die
Assoziation wird abgebrochenZustand 02000R2082 — DE — 15.06.2002 — 001.001 — 175
▼B
Zustand Ereignis AktionenNeuer
Zustand
Zustand 3 L_data Zeitgeber Ts wird neugestartet Zustand 3
R_data Zeitgeber Tr wird neugestartet Zustand 3
R_heartbeat
R_startup Bei Empfang einer STARTUP-
Nachricht vom entfernten Benutzer
wird sie als Bestätigung einer
zuvor gesendeten STARTUP-
Nachricht betrachtet; der Zeitgeber
Tr wird nicht neugestartetZustand 3
Ts_timeout Eine HEARTBEAT-Nachricht
wird gesendet, und der Zeitgeber
Ts wird neugestartetZustand 3
L_startup Ignoriert Zustand 3(4)
TC_setup
R_shutdown Zeitgeber Ts wird gestoppt; dem
lokalen Benutzer wird MT-Abort-
Indication gemeldetZustand 2
Tr_timeout Zeitgeber Ts wird gestoppt. dem
lokalen Benutzer wird MT-Abort-
Indication gemeldet; Zeitgeber Tr
wird neugestartetZustand 2
L_shutdown Eine SHUTDOWN-Nachricht wird
gesendet; die Zeitgeber Tr und Ts
werden gestoppt, und die Trans-
portverbindung wird abgebautZustand 0
TC_disconnect Der lokale Benutzer wird benach-
richtigt, dass die Transportverbin-
dung abgebaut wird (z. B.
aufgrund eines Fehlers); die Zeit-
geber Tr und Ts werden gestoppt
und die Assoziation wird abgebro-
chenZustand 0
ANMERKUNGEN
(1) Bei Eintritt in Zustand 0 kann die automatische Generierung des Ereignisses TC_setup erwogen
werden.
(2) Nur bei Eintritt in Zustand 1 über ein automatisch generiertes TC_setup-Ereignis, wie in Zustand 0
beschrieben, kann das Ereignis L_startup automatisch generiert werden.
(3) Diese Methode gewährleistet, dass eine empfangene STARTUP-Nachricht von einem entfernten
Benutzer immer durch eine STARTUP-Nachricht bestätigt wird.
(4) Einige Implementierungen, die bereits vor diesem Eurocontrol-Normendokument vorhanden
waren, können dieses Ereignis als TC_disconnect, d. h. als Rückkehr zum Zustand 0 behandeln.2000R2082 — DE — 15.06.2002 — 001.001 — 176
▼B
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 aufge-
führten Zustandstabellen sind letztere maßgeblich.
Abbildung A.1
Nachrichtenübertragungsprotokoll: Zustandsdiagramm2000R2082 — DE — 15.06.2002 — 001.001 — 177
▼B
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 verbin-
dungsorientierten 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 Wieder-
vereinigung 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 Dienstele-
menten (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 Verwen-
dung 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-Verbin-
dungsaufbau-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 abzu-
bauen, 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-Verbindungs-
aufbau-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).2000R2082 — DE — 15.06.2002 — 001.001 — 178
▼B
B.4.3. Verbindungsabbau
B.4.3.1. (NE) Für den Verbindungsabbau werden die Dienstelemente N-
Verbindungsabbau und N-Rücksetz des zugrundeliegenden Vermitt-
lungsdienstes verwendet.
B.4.3.2. (NE) Zur Implementierung einer T-Verbindungsabbau-Anforderung
wird eine N-Verbindungsabbau-Anforderung signalisiert. Sollte ande-
rerseits 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ück-
gesetzt werden.
B.4.3.3. (NE) Bei Empfang einer der beiden folgenden Vermittlungsdienstele-
mente über eine Netzverbindung, die einer ganz oder teilweise
aufgebauten Transportverbindung entspricht, muss eine T-Verbin-
dungsabbau-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 Zuord-
nung verwendet eine Transportprotokolldateneinheit (TPDU), die
durch den Vermittlungsdienst übertragen wird.
B.4.4.2. (NE) Die TPDU hat folgendes von links nach rechts übertragenes
Format, womit die in A.4.10.1 definierte Nachrichtenstruktur in die
Felder Daten(1), Daten(2)…Daten(n) einzufügen ist.
STX LENG ADEST DEST AEMM EMM Daten(1) ADRDaten(2) …
Daten(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
ANMERKUNGEN
1. Dieser Kopf ist bei der Ausführung von in definierten Nachrich-
tenformaten 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 Geltungs-
bereiches 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 4 105 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.2000R2082 — DE — 15.06.2002 — 001.001 — 179
▼B
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üt-
zung der Übertragung von Flugdaten. Die Protokollteilmenge ist
kompatibel mit der in den Versionen von [Verweisdokument 1] abAusgabe 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-Sicherungs-
dienstes, 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 veranschau-
licht wird.
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;2000R2082 — DE — 15.06.2002 — 001.001 — 180
▼B
— das zweite Paar ist ein ATC-Stellen-Wähler, der zur Identifizie-
rung eines bestimmten Endpunktes innerhalb einer ATC-Stelle
verwendet werden kann.
C.4.2.5. Die sich daraus ergebende NSAP-Adresse wird nachfolgend veran-
schaulicht.
AFI DSP
48 ATC-Stellenkennung ATC-Stellen-Wähler
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 Erar-
beitung dieser Norm ist in Anhang G aufgeführt.
C.5. Protokollspezifikation
C.5.1. Überblick
Dieses Protokoll basiert auf dem teilnetzspezifischen Anpassungspro-
tokoll 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 Nutzdaten-
feld verfügbar ist, mit dem Nutzdatenfeld im Basisformat in
CALL REQUEST- und INCOMING CALL-Paketen verwendet,
da die Einschränkungen bei den zulässigen Verbindungsdienstpa-
rametern 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 INDI-
CATION nicht verwendet;
— die Alternativverfahren für den Netzverbindungsaufbau und -
abbau werden nicht verwendet;
— Empfangsbestätigung mit D-Bit-Markierung wird nicht unter-
stü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är-
codierung 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.2000R2082 — DE — 15.06.2002 — 001.001 — 181
▼B
Tabelle 1
Nutzdatenfeldcodierung
FeldbeschreibungHalboktett höherer
OrdnungHalboktett niederer
Ordnung
Oktett 0: Protokollidentität bin(1000) bin(0100)
Oktett 1: Nachrichtencodetyp bin(0010) bin(0000)
Oktett 2: Nachrichtencodewert (N CR) bin(0000) bin(0001)
Oktett 3: Parametertyp = Gerufene NSAP bin(1100) bin(1001)
Oktett 4: Parameterlänge bin(0000) bin(0110)
Oktett 5: Parameterwert (1. Oktett) = AFI-
Wertbin(0100) bin(1000)
Oktett 6: Parameterwert (2. Oktett) = ATC-
StellenkennungZiffer höherer
OrdnungZiffer niederer
Ordnung
Oktett 7: Parameterwert (3. Oktett) = ATC-
Stellen-WählerZiffer höherer
OrdnungZiffer niederer
Ordnung
Oktett 8: Parameter type = Rufende NSAP bin(1100) bin(1011)
Oktett 9: Parameterlänge bin(0000) bin(0110)
Oktett 10: Parameterwert (1. Oktett) = AFI-
Wertbin(0100) bin(1000)
Oktett 11: Parameterwert (2. Oktett) =
ATC-StellenkennungZiffer höherer
OrdnungZiffer niederer
Ordnung
Oktett 12: Parameterwert (3. Oktett) =
ATC-Stellen-WählerZiffer höherer
OrdnungZiffer niederer
Ordnung
Oktett 13: Für künftige Verwendung reser-
viertbin(0000) bin(0000)
Oktett 14: Für künftige Verwendung reser-
viertbin(0000) bin(0000)
Oktett 15: Für künftige Verwendung reser-
viertbin(0000) bin(0000)
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 aufzu-
heben.
ANMERKUNG Die NSAP-Adresse kann optional auch anhand einer
(typischerweise aus einem Element bestehenden)2000R2082 — DE — 15.06.2002 — 001.001 — 182
▼B
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-Nach-
richt, 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 Höchstnutzdaten sind zu segmentieren und in den Nutzda-
tenfeldern 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.2000R2082 — DE — 15.06.2002 — 001.001 — 183
▼B
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 auszufüllen.
ANMERKUNG Nachdruck von PICS-Formularen: Benutzer dieses
Eurostat-Normendokuments dürfen die in diesem
Anhang enthaltenen PICS-Formulare zur zweckent-
sprechenden Verwendung kostenlos nachdrucken
und die ausgefüllten PICS veröffentlichen.
D.1.2. Ein ausgefülltes 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 Verringe-
rung 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ändi-
gungsbasis, wie sie das Standard-PICS-Formular darstellt;
— durch den Benutzer bzw. potentiellen Benutzer der Implementie-
rung 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 geeig-
neter Prüfungen zur Bewertung des Konformitätsanspruchs der
Implementierung.
D.2. Anweisungen zum Ausfüllen 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 Identifizie-
rung des Lieferanten und der Implementierung auszufüllen.
D.2.1.2. (NE) Der Hauptteil des PICS-Formulars ist ein Fragebogen mit fest-
stehendem 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 Zusatzinforma-
tionen oder Einwandinformationen angeben bzw. dazu
aufgefordert werden. Derartige Informationen sind zu Querver-
weiszwecken als Unterpositionen A<i> bzw. X<i> zu
kennzeichnen, wobei <i> eine beliebige eindeutige Positionsken-
nung (z. B. einfach eine Zahl) darstellt. Für Format und
Darstellung bestehen keine weiteren Einschränkungen.
D.2.1.3. (NE) Ein ausgefülltes PICS-Formular einschließlich eventueller
Zusatzinformationen und Einwandinformationen wird als Erklärung
zur Konformität der Protokollimplementierung für die betreffende
Implementierung (PICS) bezeichnet.2000R2082 — DE — 15.06.2002 — 001.001 — 184
▼B
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.
ANMERKUNGEN1. 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 Einrich-
tungsmö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 aufgen-
ommen 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 Anwen-
dung 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 „Unter-
stü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 erfor-
derlich 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 Implemen-
tierung nicht erfüllten Anforderung kommen kann.
D.2.4. Bedingte Positionen
D.2.4.1. Einzelne bedingte Positionen werden durch ein Bedingungssymbol
der Form „<Position>:
“ in der Status-Spalte angegeben, wobei
„<Position>“ eine Positionskennung, die in der ersten Tabellenspalte
für eine andere Position erscheint, und „
“ 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 „
“ angegeben. Die Spalte „Unterstützung“ ist
auf die übliche Weise auszufüllen. Anderenfalls ist die bedingte Posi-
tion 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.2000R2082 — DE — 15.06.2002 — 001.001 — 185
▼B
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. Positionsken nungen
Positionen im PICS-Formular werden durch mnemonische Positions-
kennungen 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.
— MTsy, MTop, MTst, Mtor Nachrichtentypen
— MAE, MAR, MCI, MDT,
MAVProzeduren
— MEsu, MEsd, MEhb, Mety Codierungen
— MNmsg Nachrichtengröße— Ts, Tr Zeitgeber
D.3.2. Kennblatt
2000R2082 — DE — 15.06.2002 — 001.001 — 186
▼B
D.3.3. Protokollimplementierung
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 optionalO.<n> optional, aber Unterstützung mindestens einer der mit
der gleichen Zahl <n> gekennzeichneten Options-
gruppen 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)2000R2082 — DE — 15.06.2002 — 001.001 — 187
▼B
D.4.1.3. Positionsken nungen
Positionen im PICS-Formular werden durch mnemonische Positions-
kennungen 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.
— IHC1, IHC2, IHC3, IHC4,
IHCCVerbindungsaufbau
— IHR1, IHR2 Verbindungsabbau
— IHT1, IHTx Datenübertragung
— Tcr Zeitgeber
D.4.2. Kennblatt
2000R2082 — DE — 15.06.2002 — 001.001 — 188
▼B
D.4.3. Protokollimplementierung
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. Positionsken nungen
Positionen im PICS-Formular werden durch mnemonische Positions-
kennungen angegeben. PICS-Positionen, die sich auf verwandte
Funktionen beziehen, werden mit dem gleichen Anfangsbuchstaben
oder -buchstabenpaar (Großbuchstaben) gekennzeichnet. Nachfolgend2000R2082 — DE — 15.06.2002 — 001.001 — 189
▼B
eine Liste dieser Anfangsbuchstaben in der Reihenfolge, in der die
Positionsgruppen im PICS-Formular erscheinen.
— SNDCP1 Protokollkennungsfeld
— NCRdae, NCRgae, NCCx,
NDRxParameter in Protokollnach-
richten
— NCD1, NCD2, NCN1, NCN2 Adressenvalidierung— NDT Datenübertragung
D.5.2. Kennblatt
2000R2082 — DE — 15.06.2002 — 001.001 — 190
▼B
D.5.3. Protokollimplementierung
2000R2082 — DE — 15.06.2002 — 001.001 — 191
▼B
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 Anwei-
sungen zu erstellen.
ANMERKUNG Die in diesem Anhang enthaltenen Formulare
basieren auf den Formularen, die den als Verweis-
dokumente zitierten Grundnormen beiliegen.
E.1.2. (NE) Eine konforme Implementierung muss die vorgeschriebenen
Konformitätsanforderungen der in diesem Profil als Verweisdoku-
mente zitierten Grundnormen erfüllen.
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 tabellari-
schen 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 Informations-
verarbeitungsfunktion erfüllt 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-Formularposi-
tionen 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 ausgefüllt wurden). Diese Positionen sind
zusammen mit den PICS-Formularen der Grundnorm auszufüllen.
Alle ausgefüllten 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 entspre-
chend der PRL ausgefüllt 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 ausgefüllte
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 Lieferungbzw. 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 ausgefüllte ICS vorzulegen. Durch Konfor-
mität mit dem Profil wird beispielsweise sichergestellt, dass
ein für zwei Verwaltungen tätiger Lieferant nicht eigene,
proprietäre Protokolle zur Erfüllung der FDE-Anforderungen
einführen kann und die für die Auftragsvergabe zuständige
Verwaltungen die Kontrolle behalten.2000R2082 — DE — 15.06.2002 — 001.001 — 192
▼B
— Einbindung von Standardprodukten in eine Profilimplementie-
rung in einem der genannten Fälle: Der Lieferant eines
Produkts sollte verpflichtet werden, die für das Produkt rele-
vanten PICS-Formulare entsprechend der hier angegebenen
PRL auszufüllen 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 Bestand-
teil 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, Verwen-
dung 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 Leistungsmerk-
malen 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 Kombina-
tion von Prädikaten sein („ ¬“ ist das Zeichen für
die logische Negation).
E.3.3. Bei der Angabe von Grundnormenanforderungen erfolgt die entspre-
chende Notation in Großbuchstaben (d. h. M, O, O.<n> X).
E.4. Anweisungen für das Ausfüllen 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 auszufüllen.
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 aufge-
fü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 auszufüllen. In dieser Spalte
ist die entsprechende Antwort entweder aus den Vorgaben2000R2082 — DE — 15.06.2002 — 001.001 — 193
▼B
auszuwählen oder gegebenenfalls als Parameterwert(e) bzw. -wertbe-
reich einzutragen.
E.4.4. Wird eine zwingend vorgeschriebene Anforderung nicht erfüllt, so
sind Einwandinformationen zu liefern, indem einer Begründung für
die Nichterfüllung 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 Fehlermel-
dung 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-Normendoku-
ment);
— 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.2000R2082 — DE — 15.06.2002 — 001.001 — 194
▼B
E.6. Konformitätserklärung
E.6.1. Konformitätsüberblick
2000R2082 — DE — 15.06.2002 — 001.001 — 195
▼B
E.6.2. Dynamische Konformitätsanforderungen
E.7. Anforderungen bezüglich der oberen Schichten
Tabelle 3
Nachrichtenübertragungsprotokoll
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionNachrichtenübertragungs-
protokollVerweise Status Verweise Status
MTst — Statusnachrichten A.4.2 O ox
MTor — Betreibernach-
richtenA.4.2 O ox
E.8. Anforderungen bezüglich der unteren Schichten
E.8.1. Transportschichtanforderungen
Tabelle 4
Nachrichtenkopfprotokoll
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Nachrichtenkopfprotokoll Verweise Status Verweise Status
IHTx Verwendung der
Felder ADEST, DEST,
AEMM, EMM und
ADR mit anderen
Werten als '40'HB.4.4 O ox
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“ der2000R2082 — DE — 15.06.2002 — 001.001 — 196
▼B
nachfolgenden Tabellen sind Verweise auf Klauseln dieser Grund-
norm.
E.8.2.1. Allgemeine DEE-Kenndaten
Tabelle 5
Allgemeine DEE-Kenndaten
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionAllgemeine DEE-Kenn-
datenVerweise Status Verweise Status
Unterstützter Dienst:
Vs — virtuelle Wählver-
bindungO.1 m
Vp — virtuelle Standver-
bindungO.1 x
Unterstützte Umge-
bungen:3, 3.2
Ec/3 — DEE/DÜE(1993) O.2 6.3.2 o.2
Ec/8 — DEE/DÜE(1988) O.2 6.3.2 o.2
Ec/4 — DEE/DÜE(1984) O.2 6.3.2 o.2
Ec/0 — DEE/DÜE(1980) O.2 6.3.2 o.2
Et/t — DEE/DEE in fester
Rolle als DEEO.2 6.3.2 o.2
Et/c — DEE/DEE in fester
Rolle als DÜEVs: O.2 6.3.2 o.2
Et/d — DEE/DEE mit
dynamischer Rollen-
wahl4.5 Vs: O.2 x
Unterstützte Paketlauf-
numerierung:
M8 — Modulo 8 13.2, 12.1.1,
Tabelle 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Tabelle 3O.3 x
Unterstütztes wahl-
freies Leistungs-
merkmal Bezugs-
nummer, für
alternative Zuweisung
der Kennung der Netz-
zugangsverbindung:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Tabelle
31
RNa — ohne Rückgriff auf
Verwendung von
Bereichen der
Netzzugangsverbin-
dung13.29.2.1 Et:O
¬Et:Xx
RNb — mit möglichem
Rückgriff auf
Verwendung von
Bereichen der
Netzzugangsverbin-
dung13.29.2.1 Et:O
¬Et:Xx2000R2082 — DE — 15.06.2002 — 001.001 — 197
▼B
E.8.2.2. Prozeduren, Pakettypen und Paketformate
Tabelle 6
Paketschichtfunktionen unabhängig von Netzzugangsverbindungen
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionPaketschichtfunktionen
unabhängig von Netzzu-
gangsverbindungenVerweise Status Verweise Status
Werden die folgenden
Paketschichtfunktionen
unterstützt:
Z2s Senden Diagnosean-
zeige12.7, Tabelle 24 Et:O
¬Et:Xx
Z4i Auslösen der
Leistungsmerkmalregi-
strierung während des
Betriebes:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— Senden REGI-
STRATION
REQUEST12.9.1
— Empfangen REGI-
STRATION CONFIR-
MATION12.9.2, Tabelle
10
Z4r Antwort auf Leistungs-
merkmalregistrierung
während des Betriebes:13.1, 13.1.1.1,
13.1.1.4Et:O –
— Empfangen REGI-
STRATION
REQUEST12.9.1
— Senden REGI-
STRATION CONFIR-
MATION12.9.2, Tabelle
10
Tabelle 7
Verbindungsaufbau
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Verbindungsaufbau Verweise Status Verweise Status
Werden abgehende
virtuelle Wählverbin-
dungen unterstützt:5.2.1, 5.2.5,
Tabelle 33
S1a — Ruf mit erweitertem
Nutzdatenfeld, keine
Antwortbeschränkung5.2.4, 13.16 O x
S1b — Ruf mit erweitertem
Nutzdatenfeld mit
Antwortbeschränkung?13.16 O x
S1c — kein Ruf mit erwei-
tertem Nutzdatenfeld?5.2.4 O m
SP1b CALL REQUEST,
Basisformat12.2.3.1 S1c:M
S1ab: O.4m
SP1e Senden CALL
REQUEST, erweitertes
Format12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b Empfangen CALL
CONNECTED, Basis-
format12.2.4.1 S1ac:M m
SP2e Empfangen CALL
CONNECTED, erwei-
tertes Format12.2.4.1,
12.2.4.2S1a:M –2000R2082 — DE — 15.06.2002 — 001.001 — 198
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Verbindungsaufbau Verweise Status Verweise Status
Wird alternative
Adressierung für abge-
hende virtuelle
Wählverbindungen
unterstützt:13.28
— Verwendung von A
= 1 und erweitertes
Adressblockformat?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— Verwendung des
Leistungsmerkmals
Erweiterung der Ziel-
adresse?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Werden ankommende
virtuelle Wählverbin-
dungen unterstützt:5.2.2, 5.2.5,
Tabelle 33
S2a — Ruf mit erweitertem
Nutzdatenfeld,
Annahme möglich?5.2.3, 13.17 O –
S2b — Ruf mit erweitertem
Nutzdatenfeld, immer
ausgelöst?13.17 O m
S2c — kein Ruf mit erwei-
tertem Nutzdatenfeld,
Annahme möglich?5.2.3 O m
S2d — Kein Ruf mit
erweitertem Nutzdaten-
feld, immer ausgelöst?5.2.3 O x
SP3b Empfangen INCO-
MING CALL, Basis-
format12.2.3.1 S2:M m
SP3e Empfangen INCO-
MING CALL, erwei-
tertes Format12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b Senden CALL
ACCEPTED, Basis-
format12.2.4.1 S2c:M
S2axc:
O.5m
SP4e Senden CALL
ACCEPTED, erwei-
tertes Format12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
Wird D-Bit-Aushand-
lung unterstützt:
DN1 — für abgehende
virtuelle Wählverbin-
dungen6.3 S1ac:O m
DN2 — für ankommende
virtuelle Wählverbin-
dungen6.3 S1ac:O m
ANMERKUNG (NE) Die D-Bit-Markierung ist stets auf 0 zu verhandeln.
Tabelle 8
Verbindungsauslösung
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Verbindungsauslösung Verweise Status Verweise Status
Wird Verbindungs-
abbau unterstützt für:5.5.4, Tabelle 33
C1 — Antwort auf
Auslösemeldung?5.5.2 O m2000R2082 — DE — 15.06.2002 — 001.001 — 199
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Verbindungsauslösung Verweise Status Verweise Status
C2a — Abbruch eines
abgehenden virtuellen
Wählverbindungsver-
suchs?5.4, 5.5.1, 5.5.3 S1:O o
C2b — Rückweisung einer
ankommenden
virtuellen Wählverbin-
dung?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd:
Om
C2c — Einleitung der
Auslösung einer aufge-
bauten virtuellen
Wählverbindung?5.5.1, 5.5.3 O o
CP1b Empfang CLEAR
INDICATION, Basis-
format12.2.5.1 Cany:M m
CP1e Empfang CLEAR
INDICATION, erwei-
tertes Format12.2.5.1,
12.2.5.2Cany:M –
CP2b Senden CLEAR
CONFIRMATION,
Basisformat12.2.6.1 C1:M m
CP2e Senden CLEAR
CONFIRMATION,
erweitertes Format12.2.6.1,
12.2.6.2C1rn:M x
CP3b Senden CLEAR
REQUEST, Basis-
format12.2.5.1 C2a:M
C2bcxa:
O.6m
CP3e Senden CLEAR
REQUEST, erweitertes
Format12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b Empfang CLEAR
CONFIRMATION,
Basisformat12.2.6.1 C2:M m
CP4e Empfang CLEAR
CONFIRMATION,
erweitertes Format12.2.6.1,
12.2.6.2C2rnci:M –
Tabelle 9
Rücksetzen von Netzzugangsverbindungen
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionRücksetzen von Netzzu-
gangsverbindungenVerweise Status Verweise Status
Wird Rücksetzen
unterstützt:8, 8.4, Tabelle
34
RSi — als einleitende
Instanz?8.1, 8.3 O mm
Senden RESET
REQUEST12.5.1
Empfang RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.12000R2082 — DE — 15.06.2002 — 001.001 — 200
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionRücksetzen von Netzzu-
gangsverbindungenVerweise Status Verweise Status
RSr — als antwortende
Instanz?8.2 O mm
Empfang RESET
INDICATION12.5.1
Senden RESET
CONFIRMATION12.5.2
Tabelle 10
Fehlerverfahren
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionFehlerverfahren (Virtueller
Wählverbindungsdienst)Verweise Status Verweise Status
Ist das ERROR-C-
Verfahren:5.2.1, 5.4, 8.1,
Tabelle 33
W1a — Abbau der
virtuellen Wählverbin-
dung?O.7 m
W1b — Neustart der Paket-
schicht?O.7 x
Ist das ERROR-R-
Verfahren für virtuelleWählverbindungen:6.3, 6.4, 6.6,
6.8.1, 6.8.2,7.1.3, 7.1.4, 8.2,
11.2.1, 13.4.1,
Tabelle 34-36
W2sc — Neustart der Paket-
schicht?O.8 x
Tabelle 11
Interrupt-Transfer
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Interrupt-Transfer Verweise Status Verweise Status
Is Wird Senden von
Interrupts unterstützt?6.8, 6.8.1, 6.8.3,
Tabelle 35Oo x
— Senden INTER-
RUPT REQUEST12.3.2
Empfang INTERRUPT
CONFIRMATION12.3.3
Ir Wird Empfang von
Interrupts unterstützt?6.8, 6.8.2, 6.8.3
Tabelle 35O–
— Empfang INTER-
RUPT INDICATION12.3.2
— Senden INTER-
RUPT CONFIRMA-
TION12.3.32000R2082 — DE — 15.06.2002 — 001.001 — 201
▼B
Tabelle 12
Senden von Daten
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Senden von Daten Verweise Status Verweise Status
DS1 Wird das Senden von
Normaldatenpaketen
unterstützt?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Wird folgendes unter-
stützt:
DS2 — Sendefenster-Rota-
tion bei Empfang von
aktualisierten P(R)-
Werten?7.1, 7.1.2, 7.1.3 O mm
DS4a — Senden M = 0 in
Normaldatenpaketen?6.4, 6.5, 6.7 M mo.9
DS4b — Senden M = 1 in
Normaldatenpaketen?6.4, 6.5, 6.7 O mo.9
DS5a — Senden Q = 0 in
Normaldatenpaketen?6.6 O.10 mm
DS5b — Senden Q = 1 in
Normaldatenpaketen?6.6 O.10 ox
DS6 — Antwort auf Anfor-
derungen zur Wieder-
holung von
Datenpaketen
(empfangene Rückwei-
sungspakete)?13.4.2 12.8 Et:O –
— Fensterrotationszeit-
geber-Verfahren:
DS7a — ERROR-R bei
Ablauf11.2.1(a) O ox
DS7b — Datenpaketwieder-
holung bei Ablauf11.2.1(b) Et:O
¬Et:Xox
DS8 — Verwerfen von
Flussregelungspaketen
mit Überlänge (statt
ERROR-R)?Tabelle 36
Anmerkung 2Oo x
Tabelle 13
Empfang von Daten
Grundnorm-Leistungsmerkmale Profilmerkamele
Position Empfang von Daten Verweise Status Verweise Status
DR1 Wird Empfang von
Normaldatenpaketen
unterstützt?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Wird folgendes unter-
stützt:
DR2 — Empfangsfenster-
Rotation durch Senden
von aktualisierten
P(R)-Werten?7.1.2, 7.1.3 O mm
DR3 — Flussregelung durch
Senden von RECEIVE
NOT READY und
RECEIVE READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — Empfang M = 1 in
Normaldatenpaketen?6.4, 6.5, 6.7 O mm
DR5a — Empfang Q = 0 in
Normaldatenpaketen?6.6 O.11 mm2000R2082 — DE — 15.06.2002 — 001.001 — 202
▼B
Grundnorm-Leistungsmerkmale Profilmerkamele
Position Empfang von Daten Verweise Status Verweise Status
DR5b — Empfang Q = 1 in
Normaldatenpaketen?6.6 O.11 –
DR6 — Anforderung von
Datenpaket-Wiederho-
lung durch Senden von
Rückweisungspaketen?13.4.1, 12.8 O ox
— Wiederherstellung
nach Empfang von
Normaldatenpaketen
mit ungültigem P(S)
durch:
DR7a — ERROR-R-Aktion? 11.3(a) O.12 mm
DR7b — Anforderung von
Datenpaket-Wiederho-
lung?11.3(b) O.12 ox
DR7c — Ignorieren des
Pakets und Waren auf
ein korrektes wieder-
holtes Datenpaket?11.3(c) O.12 ox
— Wiederherstellung
nach Emfpfang von
Normaldatenpaketen
mir ungültigem Nutz-
datenfeld durch:
DR8a — ERROR-R-Aktion? 11.3(a) O.13 mm
DR8b — Anforderung von
Datenpaket-Wiederho-
lung?11.3(b) O.13 ox
DR8c — Ignorieren des
Pakets und Waren auf
ein korrektes wieder-
holtes Datenpaket?11.3(c) O.13 ox
DR9 — Fensterstatusübe-
rtragungs-Zeitgeber-
Verfahren?11.2.2 O ox
Tabelle 14
Übergabebestätigung
Grundnorm-Leistungsmerkmale Profilmerkmale
Position Übergabebestätigung Verweise Status Verweise Status
DC Wird Übergabebestäti-
gung unterstützt?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Verschiedene Leist ungsmerkmale und Optionen
Tabelle 15
Werte für Grund- und Diagnosekodierung
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionWerte für Grund- und
DiagnosekodierungVerweise Status Verweise Status
In gesendeten
RESTART REQUEST-
Paketen:12.6.1.1,
12.6.1.2, Tabelle
24-25
Y1d — Grund = 128,
private Diagnosekodie-
rungO.14 ox2000R2082 — DE — 15.06.2002 — 001.001 — 203
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionWerte für Grund- und
DiagnosekodierungVerweise Status Verweise Status
In empfangenen
RESTART INDICA-
TION-Paketen:12.6.1.1, Tabelle
9, 12.6.1.2
Y2b — Grund nicht 0 oder
128, beliebiger
Diagnosekodierungs-
wertEC:M
¬EC:Om
In gesendeten CLEAR
REQUEST-Paketen:12.2.3.1.1,
12.2.3.1.2,
Tabelle 24-25
Y3d — Grund = 128,
private Diagnosekodie-
rungenO.15 ox
In empfangenen
CLEAR INDICA-
TION-Paketen:12.2.3.1.1,
Tabelle 7
12.2.3.1.2,
Y4b — Grund nicht 0 oder
128, beliebiger
Diagnosekodierungs-
wertEC:M
¬EC:Om
In gesendeten RESET
REQUEST-Paketen:12.5.1.1,
12.5.1.2, Tabelle
24-25
Y5d — Grund = 128,
private Diagnosekodie-
rungenO.16 ox
In empfangenen
RESET INDICATION-
Paketen:12.5.1.1, Tabelle
8, 12.5.1.2
Y6b — Grund nicht 0 oder
128, beliebiger
Diagnosekodierungs-
wertEC:M
¬EC:Om
E.8.2.4. Leistungsmerkmale
Tabelle 16
In CALL REQUEST-Paketen gesendete Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL REQUEST-
Paketen gesendete
LeistungsmerkmaleVerweise Status Verweise Status
FS1pi Verhandlung über
Parameter zur Flussre-
gelung, Paketgröße13.12, 15.2.2.1.1 O x
FS1wi Verhandlung über
Parameter zur Flussre-
gelung, Fenstergröße13.12, 15.2.2.1.2 O x
FS2ib Basisverhandlung der
Durchsatzklasse13.13,
15.2.2.2.1,
Tabelle 20aOx
FS2ie Erweiterte Verhand-
lung der Durchsatz-
klasse13.13,
15.2.2.2.2,
Tabelle 20bOx
FS3b Auswahl einer
geschlossenen Benut-
zergruppe, Basisformat13.14.6,
15.2.2.3.1Oo2000R2082 — DE — 15.06.2002 — 001.001 — 204
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL REQUEST-
Paketen gesendete
LeistungsmerkmaleVerweise Status Verweise Status
FS3e Auswahl einer
geschlossenen Benut-
zergruppe, erweitertes
Format13.14.6,
15.2.2.3.2Ox
FS4b Auswahl einer
geschlossenen Benut-
zergruppe ohne
Beschränkung für
abgehenden Ruf,
Basisformat13.14.7,
15.2.2.4.1Ox
FS4e Auswahl einer
geschlossenen Benut-
zergruppe ohne
Beschränkung für
abgehenden Ruf,
erweitertes Format13.14.7,
15.2.2.4.2Ox
FS5 Bilaterale Auswahl
einer geschlossenen
Benutzergruppe13.15, 15.2.2.5 O x
FS6a Ruf mit erweitertem
Nutzdatenfeld13.16, 15.2.2.6 O x
FS6b Aufforderung zur
Gebührenübernahme13.18, 15.2.2.6 O x
FS6c ICRD-Zustandswahl 13.25.4.2,
15.2.2.6Ox
FS7i Netzteilnehmer-
Kennung13.21, 13.21.3,
15.2.2.7Ox
FS8i Gebührendaten, Anfor-
derungsdienst13.22, 15.2.2.8.1 O x
FS9b RPOA-Auswahl,
Basisformat13.23, 13.23.2,
15.2.2.9.1Ox
FS9e RPOA-Auswahl,
erweitertes Format13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Übertragungszeitaus-
wahl und -anzeige13.27, 15.2.2.13 O x
FS99i Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS98i Entfernte X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS20i Leistungsmerkmal-
Markierung, CCITT-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FS21i Erweiterung der
Herkunftsadresse14.1, 15.3.2.1 x
FS22i Erweiterung der Ziel-
adresse14.2, 15.3.2.2 x
FS23ib Verhandlung der
Mindestdurchsatz-
klasse, Basisformat14.3, 15.3.2.3.1,
Tabelle 20aOx
FS23ie Verhandlung der
Mindestdurchsatz-
klasse, erweitertes
Format14.3, 15.3.2.3.2,
Tabelle 20bO2000R2082 — DE — 15.06.2002 — 001.001 — 205
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL REQUEST-
Paketen gesendete
LeistungsmerkmaleVerweise Status Verweise Status
FS24i Verhandlung der Ende-
zu-Ende-Übertragungs-
zeit14.4, 15.3.2.4 O x
FS25i Verhandlung der
Vorrangdaten14.7, 15.3.2.7 O x
FS26i Priorität 14.5, 15.3.2.5 O x
FS27i Schutz 14.6, 15.3.2.6 O x
Tabelle 17
In CALL ACCEPT-Paketen gesendete Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL ACCEPT-Paketen
gesendete Leistungsmerk-
maleVerweise Status Verweise Status
FS1pr Verhandlung über
Parameter zur Flussre-
gelung, Paketgröße13.12,
15.2.2.1.1,
Tabelle 13Ox
FS1wr Verhandlung über
Parameter zur Flussre-
gelung, Fenstergröße13.12,
15.2.2.1.2,
Tabelle 13Ox
FS2rb Basisverhandlung der
Durchsatzklasse13.13,
15.2.2.2.1,
Tabelle 20aOx
FS2re Erweiterte Verhand-
lung der Durchsatz-
klasse13.13,
15.2.2.2.2,
Tabelle 20bOx
FS7r Netzteilnehmerken-
nung13.21, 13.21.3
15.2.2.7Ox
FS8r Gebührendaten, Anfor-
derungsdienst13.22, 15.2.2.8.1 O x
FS10r Mitteilung über die
Änderung der Ziel-
adresse13.26, 15.2.2.12 O x
FS99r Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS98r Entfernte X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS20r Leistungsmerkmal-
Markierung, CCITT-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FS22r Erweiterung der Ziel-
adresse14.2, 15.3.2.2 O x
FS24r Verhandlung der Ende-
zu-Ende-Übertragungs-
zeit14.4, 15.3.2.4 O x
FS25r Verhandlung der
Vorrangdaten14.7, 15.3.2.7 O x
FS26r Priorität 14.5, 15.3.2.5 O x
FS27r Schutz 14.6, 15.3.2.6 O x2000R2082 — DE — 15.06.2002 — 001.001 — 206
▼B
Tabelle 18
In CLEAR REQUEST-Paketen gesendete Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CLEAR REQUEST-
Paketen gesendete
LeistungsmerkmaleVerweise Status Verweise Status
FS10d Mitteilung über die
Änderung der Ziel-
adresse13.26, 15.2.2.12 O x
FS13 Auswahl Rufweiterlei-
tung13.25.2.2,
15.2.2.10Ox
FS99d Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS98d Entfernte X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FS20d Leistungsmerkmal-
Markierung, CCITT-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FS22d Erweiterung der Ziel-
adresse14.2, 15.3.2.2 O x
Tabelle 19
In INCOMING CALL-Paketen empfangene Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn INCOMING CALL-
Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR1pi Verhandlung über
Parameter zur Flussre-
gelung, Paketgröße13.12, 15.2.2.1.1 O x
FR1wi Verhandlung über
Parameter zur Flussre-
gelung, Fenstergröße13.12, 15.2.2.1.2 O x
FR2ib Basisverhandlung der
Durchsatzklasse13.13, 15.2.2.2.1
Tabelle 20aOx
FR2ie Erweiterte Verhand-
lung der Durchsatz-
klasse13.13, 15.2.2.2.2
Tabelle 20bOx
FR3b Auswahl einer
geschlossenen Benut-
zergruppe, Basisformat13.14.6,
15.2.2.3.1Oo
FR3e Auswahl einer
geschlossenen Benut-
zergruppe, erweitertes
Format13.14.6,
15.2.2.3.2Ox
FR4b Auswahl einer
geschlossenen Benut-
zergruppe ohne
Beschränkung für
abgehenden Ruf,
Basisformat13.4.7,
15.2.2.4.1Ox
FR4e Auswahl einer
geschlossenen Benut-
zergruppe ohne
Beschränkung für
abgehenden Ruf,
erweitertes Format13.4.7,
15.2.2.4.2Ox2000R2082 — DE — 15.06.2002 — 001.001 — 207
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn INCOMING CALL-
Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR5 Bilaterale Auswahl
einer geschlossenen
Benutzergruppe13.15, 15.2.2.5 O x
FR6a Ruf mit erweitertem
Nutzdatenfeld13.16, 13.17,
15.2.2.6Ox
FR6b Aufforderung zur
Gebührenübernahme13.18, 13.19,
15.2.2.6Ox
FR11 Mitteilung über
erfolgte Rufumleitung
oder Rufweiterleitung13.25.3,
15.2.2.11Ox
FR12i Übertragungszeitaus-
wahl und -anzeige13.27, 15.2.2.13 O x
FR99i Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FR20i Leistungsmerkmal-
Markierung, CCITT-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FR21 Erweiterung der
Herkunftsadresse14.1, 15.3.2.1 x
FR22i Erweiterung der Ziel-
adresse14.2, 15.3.2.2 x
FR23b Verhandlung der
Mindestdurchsatz-
klasse, Basisformat14.3, 15.3.2.3.1,
Tabelle 20aOx
FR23e Verhandlung der
Mindestdurchsatz-
klasse, erweitertes
Format14.3, 15.3.2.3.2,
Tabelle 20bOx
FR24i Verhandlung der Ende-
zu-Ende-Übertragungs-
zeit14.4, 15.3.2.4 O x
FR25i Verhandlung der
Vorrangdaten14.7, 15.3.2.7 O x
FR26i Priorität 14.5, 15.3.2.5 O x
FR27i Schutz 14.6, 15.3.2.6 O x
Tabelle 20
In CALL CONNECTED-Paketen empfangene Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL CONNECTED-
Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR1pr Verhandlung über
Parameter zur Flussre-
gelung, Paketgröße13.12,
15.2.2.1.1,
Tabelle 14Ox
FR1wr Verhandlung über
Parameter zur Flussre-
gelung, Fenstergröße13.12,
15.2.2.1.2,
Tabelle 14Ox
FR2rb Basisverhandlung der
Durchsatzklasse13.13,
15.2.2.2.1,
Tabelle 20aOx
FR2re Erweiterte Verhand-
lung der Durchsatz-
klasse13.13,
15.2.2.2.2,
Tabelle 20bOx2000R2082 — DE — 15.06.2002 — 001.001 — 208
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CALL CONNECTED-
Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR10r Mitteilung über die
Änderung der Ziel-
adresse13.26, 15.2.2.12 O x
FR12r Übertragungszeitaus-
wahl und -anzeige13.27, 15.2.2.13 O x
FR99r Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FR20r Leistungsmerkmal-
Markierung, CCITT-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FR22r Erweiterung der Ziel-
adresse14.2, 15.3.2.2 O x
FR24r Verhandlung der Ende-
zu-Ende-Übertragungs-
zeit14.4, 15.3.2.4 O x
FR25r Verhandlung der
Vorrangdaten14.7, 15.3.2.7 O x
FR26r Priorität 14.5, 15.3.2.5 O x
FR27r Schutz 14.6, 15.3.2.6 O x
Tabelle 21
In CLEAR INDICATION-Paketen empfangene Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CLEAR INDICATION-
Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR8ad Gebührendaten,
Währungseinheit13.22, 15.2.2.8.2 O x
FR8bd Gebührendaten,
Segmentzählung13.22, 15.2.2.8.3 O x
FR8cd Gebührendaten,
Verbindungsdauer13.22, 15.2.2.8.4 O x
FR10d Mitteilung über die
Änderung der Ziel-
adresse13.26, 15.2.2.12 O x
FR99d Lokale X.25-fremde
Merkmale, nach
Leistungsmerkmal-
Markierung15.1, Tabelle 18 O x
FR20d Leistungsmerkmal-
Markierung, ITU-T-
spezifizierte DEE-
Leistungsmerkmale15.1 O x
FR22d Erweiterung der Ziel-
adresse14.2, 15.3.2.2 O x2000R2082 — DE — 15.06.2002 — 001.001 — 209
▼B
Tabelle 22
In CLEAR CONFIRMATION-Paketen empfangene Leistungsmerkmale
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionIn CLEAR CONFIRMA-
TION-Paketen empfangene
LeistungsmerkmaleVerweise Status Verweise Status
FR8af Gebührendaten,
Währungseinheit13.22, 15.2.2.8.2 O x
FR8bf Gebührendaten,
Segmentzählung13.22, 15.2.2.8.3 O x
FR8cf Gebührendaten,
Verbindungsdauer13.22, 15.2.2.8.4 O x
E.8.2.5. Parameterwerte und -Bereiche
Tabelle 23
Parameterwerte und -Bereiche
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionParameterwerte und -
BereicheVerweise Status Verweise Status
Welche Werte werden
unterstützt:
V1s — Ersatzpaketgrößen
(Senden)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
Oktette6.3.2 Minde-
stens
128
und
256
V1r — Ersatzpaketgrößen
(Empfang)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
Oktette6.3.2 Minde-
stens
128
und
256
V2s — Ersatzfenstergrößen,
Senden?16.2.2.6 (M8: im
Bereich 1-
7)2
V2r — Ersatzfenstergrößen,
Empfang?16.2.2.6 (M8: im
Bereich 1-
7)2
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
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionÜbermittlungsabschnittspro-
tokollVerweise Status Verweise Status
Lm Steuerungsverfahren
für Übermittlungsab-
schnittsbündel6O o x2000R2082 — DE — 15.06.2002 — 001.001 — 210
▼B
Grundnorm-Leistungsmerkmale Profilmerkmale
PositionÜbermittlungsabschnittspro-
tokollVerweise Status Verweise Status
Lc DEE/DÜE-Betrieb 1, 5.1 M mo.1
Lt DEE/DEE-Betrieb 1, 5.1 O mo.1
M8 Basisbetrieb (Modulo
8)1, 3, 4.1.1 O.1 mm
M128 Erweiterter Betrieb
(Modulo 128)1, 3, 4.1.1 O.1 ox
T4 Zeitgeber-T4-
Verfahren5.3.2, 5.6.1 O mm
SPN1 Höchstzahl (N1) von
Bits in einem I-Block5.7.3 N1 ≥
1 080N1≥
2 104
SPk Höchstzahl ausste-
hender Blöcke (k)5.7.4 1 ≤k≤
7k=7
E.8.4. Bitübertragungsschichtanforderungen
Siehe ISO/IEC TR 10609-9 clause A.4 [Verweisdokument 8].2000R2082 — DE — 15.06.2002 — 001.001 — 211
▼B
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äsenta-
tion 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 Interoperabi-
litä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 Divi-
sion) 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 vorgege-
benen Eigenschaftserklärung angeben, welche Teile des ICD und
welche Beschränkungen für variable Parameter gegebenenfalls unter-
stü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 Endsy-
stems.
F.5.1.2. Die Ergebnisse einer derartigen Prüfung können als Beleg zur Stüt-
zung 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ä-2000R2082 — DE — 15.06.2002 — 001.001 — 212
▼B
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 Eurocon-
trol(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.2000R2082 — DE — 15.06.2002 — 001.001 — 213
▼B
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 Kennung-
szuweisung erteilt Eurocontrol. Darüber hinaus zeigt die Tabelle die
hexadezimale Binärcodierung der Kennung im Rahmen der in Anhang C defi-
nierten Adresscodierung.
Tabelle 1
ATC-Stellenkennungen
ATC-Stellenkennung Codierung Beschreibung
00 Reserviert
01 '01'H CATCAS, Kopenhagen
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Brüssel
05 '05'H Generic CAUTRA, Frankreich
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, London
09 '09'H Oslo ATCC
10 '10'H Karlsruhe ATCC
11 '11'H Langen (künftiges deutsches System)
12 '12'H FATMI-system, Tampere
13 '13'H ROVA-system, Rovaniemi14 '14'H VAS, Wien
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H Genf ACC/FMP
18 '18'H Zürich ACC/FMP
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Mailand
23 '23'H Rom
24 '24'H Jersey
25 '25'H Shanwick
26 '26'H Athis-Mons
27 '27'H Reims
28 '28'H Brest
29 '29'H Bordeaux
30 '30'H Aix-en-Provence
31 '31'H Bratislava
32 '32'H Stockholm-Arlanda
33 '33'H Malmö-Sturup
34 '34'H Sundsvall35 '35'H Lissabon
36 '36'H Sevilla
37 '37'H Gran Canaria
38 '38'H Prag2000R2082 — DE — 15.06.2002 — 001.001 — 214
▼B
ATC-Stellenkennung Codierung Beschreibung
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Deutsches Militärsystem
42 '42'H Deutsches Militärsystem
43 '43'H Deutsches Militärsystem
44 '44'H Deutsches Militärsystem
45 '45'H Deutsches Militärsystem
46 '46'H Deutsches Militärsystem
47 '47'H Deutsches Militärsystem
48 '48'H Deutsches Militärsystem
49 '49'H Deutsches Militärsystem
50 '50'H München (künftiges deutsches System)
51 '51'H Zagreb
52 '52'H Flughafen Hahn, Deutschland
53 '53'H Santa Maria FIR
54 '54'H Ljubljana
55 '55'H Belgisches Militärsystem
56 '56'H Budapest57 '57'H Warschau2000R2082 — DE — 15.06.2002 — 001.001 — 215
▼B
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 Tele-
kommunikationsdienste 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-Netzverbundum-
gebung 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 unter-
schiedlichen 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 Beschleuni-
gung des Verbindungswiederaufbaus einen DISC-Block generieren.
H.4.3. Sicherheit
H.4.3.1. Wird ISDN als Träger genutzt, sollte die gerufene ISDN-Endge-
rä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 Berech-
tigungsinformationen erfüllen.2000R2082 — DE — 15.06.2002 — 001.001 — 216
▼B
H.4.4. Konfigurationsbeispiel
Abbildung H.1.
Konfigurationsbeispiel Standleitung
H.5. Netzimplementierung
H.5.1. Verlässlichkeit
Zur Erhöhung der Verlässlichkeit des Dienstes sollten die Zentral-
rechner 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 Verbindungswie-
deraufbau über diesen zweiten Zugang erfolgen.
H.5.3. Sicherheit
Innerhalb des Anwendungsbereichs dieses Anhangs sollte die
geschlossene Benutzergruppe (CUG) als einzige gültige Netzeinrich-
tung verwendet werden.
H.6. Allgemeine Hinweise für Standleitungs- und Netzimplementie-
rungen
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ük-
kung 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 Trans-
port-Stacks in die Profilspezifikation entwickelt.2000R2082 — DE — 15.06.2002 — 001.001 — 217
▼B
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über-
tragung 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 Sicherungs-
schichten 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übertragungsproto-
kollausfall 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 Netz2000R2082 — DE — 15.06.2002 — 001.001 — 218