2000R2082 — NL — 15.06.2002 — 001.001 — 1
Dit document vormt slechts een documentatiehulpmiddel en verschijnt buiten de verantwoordelijkheid van de instellingen
►B VERORDENING (EG) Nr. 2082/2000 VAN DE COMMISSIE
van 6 september 2000
tot bekrachtiging van Eurocontrol-normen en tot wijziging van Richtlijn 97/15/EG tot bekrachti-
ging van Eurocontrol-normen en tot wijziging van Richtlijn 93/65/EEG van de Raad
(PB L 254 van 9.10.2000, blz. 1)
Gewijzigd bij:
Publicatieblad
nr. blz. datum
►M1 Verordening (EG) nr. 980/2002 van de Commissie van 4 juni 2002 L 150 38 8.6.2002
▼B
VERORDENING (EG) Nr. 2082/2000 VAN DE COMMISSIE
van 6 september 2000
tot bekrachtiging van Eurocontrol-normen en tot wijziging van
Richtlijn 97/15/EG tot bekrachtiging van Eurocontrol-normen en
tot wijziging van Richtlijn 93/65/EEG van de Raad
DE COMMISSIE VAN DE EUROPESE GEMEENSCHAPPEN,
Gelet op het Verdrag tot oprichting van de Europese Gemeenschap,
Gelet op Richtlijn 93/65/EEG van de Raad van 19 juli 1993 betref-
fende de vaststelling en het gebruik van compatibele technische
normen en specificaties voor de aanschaf van apparatuur en vansystemen voor luchtverkeersafhandeling (
1), inzonderheid op artikel 3,
Gelet op Richtlijn 97/15/EG van de Commissie van 25 maart 1997 tot
bekrachtiging van Eurocontrol-normen en tot wijziging van Richtlijn93/65/EEG van de Raad betreffende de vaststelling en het gebruik vancompatibele technische normen en specificaties voor de aanschaf van
apparatuur en van systemen voor luchtverkeersafhandeling (
2),
Overwegende hetgeen volgt:
(1) Bij Richtlijn 97/15/EG zijn de Eurocontrol-norm voor On-Line
Data Interchange (OLDI), editie 1.0, en de Eurocontrol-normvoor Air Traffic Services Data Exchange Presentation (presen-
tatie van ATS-gegevensuitwisseling) (ADEXP), editie 1.0,
bekrachtigd.
(2) Eurocontrol heeft nieuwe versies van de bovenvermelde twee
normen aangenomen, namelijk OLDI, editie 2.2, en ADEXP,
editie 2.0, alsook een nieuwe Eurocontrol — norm, Flight DataExchange — Interface Control Document (FDE-ICD) genaamd.
(3) Deze Eurocontrol-normen vallen onder het toepassingsgebied
van Richtlijn 93/65/EEG en dragen bij tot de harmonisatie van
de nationale luchtverkeersafhandelingssystemen van de lidstaten,met name wat betreft de overdracht van vluchten tussenverkeersleidingscentra (OLDI), de afhandeling van luchtverkeer-sstromen (ADEXP) en de communicatie tussen nationalesystemen (FDE-ICD).
(4) De edities 2.2 van OLDI en 2.0 van ADEXP treden in de plaatsvan de voorgaande uitgaven, die momenteel van kracht zijn opgrond van het bepaalde in artikel 1 van Richtlijn 97/15/EG, en
dit artikel dient derhalve te worden ingetrokken.
(5) De in deze verordening vervatte maatregelen zijn in overeen-
stemming met het advies van het comité dat conform Richtlijn93/65/EEG is ingesteld,
HEEFT DE VOLGENDE VERORDENING VASTGESTELD:
Artikel 1
De bindende elementen van de Eurocontrol-specificaties die opge-
nomen zijn in de volgende normatieve Eurocontrol-documenten
worden bekrachtigd in het kader van Richtlijn 93/65/EEG, voorzover
zij nodig zijn voor de tenuitvoerlegging van een geïntegreerd Europeessysteem voor luchtverkeersafhandeling:
— de Eurocontrol-norm voor On-Line Data Interchange (OLDI), editie
2.2 (Eurocontrol-referentiedocument DPS. ET1.ST06-STD),
waarvan de tekst in bijlage I bij deze verordening is opgenomen,
— de Eurocontrol-norm voor de presentatie van gegevensuitwisseling
tussen verkeersleidingsdiensten (Air Traffic Services DataExchange Presentation) (ADEXP), editie 2.0 (Eurocontrol-referen-2000R2082 — NL — 15.06.2002 — 001.001 — 2
(1) PB L 187 van 29.7.1993, blz. 52.
(2) PB L 95 van 10.4.1997, blz. 16.
▼B
tiedocument DPS.ET1.ST09-STD), waarvan de tekst in bijlage II bij
deze verordening is opgenomen,
— de Eurocontrol-norm voor uitwisseling van vluchtgegevens — inter-
facebesturingsdocument (Flight Data Exchange — Interface ControlDocument) (FDE-ICD), editie 1.0 (Eurocontrol-referentiedocument
COM.ET1.ST12-STD), waarvan de tekst in bijlage III bij deze
verordening is opgenomen.
Artikel 2
Artikel 1 van Richtlijn 97/15/EG wordt ingetrokken.
Artikel 3
Deze verordening treedt in werking op de derde dag volgende op die
van haar bekendmaking in het Publicatieblad van de Europese
Gemeenschappen .
Deze verordening in verbindend in al haar onderdelen en is rechtstreeks
toepasselijk in elke lidstaat.2000R2082 — NL — 15.06.2002 — 001.001 — 3
▼B
BIJLAGE I
ON-LINE DATA INTERCHANGE (OLDI), EDITIE 2.2
(Eurocontrol-referentiedocument DPS.ET1.ST06-STD)2000R2082 — NL — 15.06.2002 — 001.001 — 4
▼B
INHOUDSOPGAVE
AUTEURSRECHT
VOORWOORD1. INLEIDING
1.1. Doelstelling1.2. Reikwijdte
2. REFERENTIES3. DEFINITIES, SYMBOLEN EN AFKORTINGEN
3.1. Definities3.2. Symbolen en afkortingen
4. ALGEMENE VEREISTEN
4.1. Inleiding4.2. Vereisten voor het Flight Data Processing System4.2.1. Vluchtdatabase4.2.2. Real time-verwerking4.2.3. Datacommunicatie4.2.4. Applicatiefuncties4.2.5. Human-Machine Interface (HMI)4.2.6. Starten van berichten4.2.7. Ontvangst van berichten4.3. Bijwerken aan de hand van bewakingsgegevens4.4. Registratie van OLDI-gegevens4.4.1. Inhoud4.4.2. Faciliteiten4.5. Beschikbaarheid, betrouwbaarheid, gegevensbeveiliging en gegevensintegriteit4.5.1. Beschikbaarheid4.5.2. Betrouwbaarheid4.5.3. Gegevensbeveiliging4.5.4. Gegevensintegriteit4.6. Operationele evaluatie4.6.1. Evaluatieperiode4.6.2. Operationele introductiedatum
5. BERICHTENCATEGORIEËN
5.1. Algemeen5.1.1. Doelstelling5.1.2. Berichtencategorieën5.2. Transactietijden5.2.1. Voorwaarden voor transactietijden5.3. Berichtenclassificatie en -categorisatie2000R2082 — NL — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Berichtenclassificatie — verplicht en complementair
5.3.2. Categorisatie van berichten
6. BASISPROCEDURE — VERPLICHTE BERICHTEN
6.1. Algemeen6.1.1. Beschrijving van de vereisten6.1.2. Implementatie6.2. ABI-bericht(Advance Boundary Informat ion)
6.2.1. Doel van hetABI-bericht
6.2.2. Inhoud van bericht6.2.3. Regels voor toepassing6.2.4. Bevestiging van ABI-bericht6.2.5. Voorbeelden6.3. ACT-bericht (Activate)
6.3.1. Doel van hetACT-bericht
6.3.2. Inhoud van bericht6.3.3. Regels voor toepassing6.3.4. Bevestiging van ACT-bericht6.3.5. Voorbeelden
6.4. LAM-bericht(Logical AcknowledgementMessage)
6.4.1. Doel van hetLAM-bericht6.4.2. Inhoud van bericht6.4.3. Regels voor toepassing6.4.4. Bevestiging van LAM-bericht6.4.5. Voorbeelden
7. BASISPROCEDURE — COMPLEMENTAIRE BERICHTEN
7.1. Algemeen
7.1.1. Beschrijving van vereiste7.1.2. Implementatie7.2. PAC-bericht (Preliminary Activate Message)7.2.1. Doel van hetPAC-bericht7.2.2. Inhoud van bericht
7.2.3. Regels voor toepassing
7.2.4. Bevestiging van PAC-bericht7.2.5. Voorbeelden7.3. REV-bericht(Revision)7.3.1. Doel van hetREV-bericht
7.3.2. Inhoud van bericht
7.3.3. Regels voor toepassing7.3.4. Bevestiging van REV-bericht7.3.5. Voorbeelden2000R2082 — NL — 15.06.2002 — 001.001 — 6
▼B
7.4. MAC-bericht (Message for the Abrogation of Co-ordination)
7.4.1. Doel van hetMAC-bericht7.4.2. Inhoud van bericht
7.4.3. Regels voor toepassing
7.4.4. Bevestiging van MAC-bericht7.4.5. Voorbeelden7.5. COD-bericht(SSR Code Assignment )
7.5.1. Doel van hetCOD-bericht
7.5.2. Inhoud van bericht7.5.3. Regels voor toepassing
7.5.4. Bevestiging van COD-bericht
7.5.5. Voorbeelden7.6. INF-bericht(Informat ion)7.6.1. Doel van hetINF-bericht
7.6.2. Inhoud van bericht
7.6.3. Regels voor toepassing7.6.4. Bevestiging van INF-bericht
7.6.5. Voorbeelden
8. DIALOOGPROCEDURE — COÖRDINATIE
8.1. Algemeen8.1.1. Inleiding
8.1.2. Hetfilt er
8.1.3. Berichtenvolgorde8.1.4. Gelijktijdige afhandeling van berichten8.1.5. Behandeling van afwijzing
8.1.6. Operationele time-out voor antwoord
8.1.7. Implementatie8.2. ACT-bericht (Activate)
8.2.1. Doel van hetACT-bericht
8.2.2. Inhoud van bericht8.2.3. Regels voor toepassing
8.2.4. Bevestiging van ACT-bericht
8.3. RAP-bericht (Referred Activate Proposal)8.3.1. Doel van hetRAP-bericht8.3.2. Inhoud van bericht
8.3.3. Regels voor toepassing
8.3.4. Bevestiging van RAP-bericht8.3.5. Operationeel antwoord op RAP
8.3.6. Voorbeelden
8.4. REV-bericht(Revision)2000R2082 — NL — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Doel van hetREV-bericht
8.4.2. Inhoud van bericht8.4.3. Regels voor toepassing
8.4.4. Bevestiging van REV-bericht
8.4.5. Operationeel antwoord op REV8.5. RRV-bericht(Referred Revision Proposal)8.5.1. Doel van hetRRV-bericht
8.5.2. Inhoud van bericht
8.5.3. Regels voor toepassing8.5.4. Bevestiging van RRV-bericht
8.5.5. Operationeel antwoord op RRV
8.5.6. Voorbeelden8.6. SBY-bericht(St and-by)8.6.1. Doel van hetSBY-bericht
8.6.2. Inhoud van bericht
8.6.3. Regels voor toepassing8.6.4. Bevestiging van SBY-bericht
8.6.5. Voorbeelden
8.7. ACP-bericht(Accept ance)8.7.1. Doel van hetACP-bericht
8.7.2. Inhoud van bericht
8.7.3. Regels voor toepassing8.7.4. Bevestiging van ACP-bericht8.7.5. Voorbeelden
8.8. CDN-bericht(Co-ordinat ion)
8.8.1. Doel van hetCDN-bericht8.8.2. Inhoud van bericht
8.8.3. Regels voor toepassing
8.8.4. Bevestiging van CDN-bericht8.8.5. Operationeel antwoord op CDN8.8.6. Voorbeelden
8.9. RJC-bericht(RejectCo-ordinat ion)
8.9.1. Doel van hetRJC-bericht8.9.2. Inhoud van bericht
8.9.3. Regels voor toepassing
8.9.4. Bevestiging van RJC-bericht8.9.5. Voorbeelden
9. DIALOOGPROCEDURE — OVERDRACHT VAN COMMUNICATIE
9.1. Algemeen
9.1.1. Inleiding2000R2082 — NL — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Berichtenvolgorde
9.1.3. Overdrachtvan communicat ie9.2. TIM-bericht (Transfer Initiation Message)
9.2.1. Doel van hetTIM-bericht
9.2.2. Inhoud van bericht9.2.3. Regels voor toepassing9.2.4. Bevestiging van TIM-bericht
9.2.5. Voorbeeld
9.3. SDM-bericht (Supplementary Data Message)9.3.1. Doel van hetSDM-bericht
9.3.2. Inhoud van bericht
9.3.3. Regels voor toepassing9.3.4. Bevestiging van SDM-bericht9.3.5. Voorbeeld
9.4. Hand-Over Proposal (HOP)
9.4.1. Doel van hetHOP-bericht9.4.2. Inhoud van bericht
9.4.3. Regels voor toepassing
9.4.4. Bevestiging van HOP-bericht9.4.5. Voorbeeld
9.5. ROF-bericht(Requeston Frequency)
9.5.1. Doel van hetROF-bericht9.5.2. Inhoud van bericht9.5.3. Regels voor toepassing
9.5.4. Bevestiging van ROF-bericht
9.5.5. Voorbeeld9.6. COF-bericht(Change of Frequency)
9.6.1. Doel van hetCOF-bericht
9.6.2. Inhoud van bericht9.6.3. Regels voor toepassing9.6.4. Bevestiging van COF-bericht
9.6.5. Voorbeelden
9.7. MAS-bericht (Manual Assumption of Communications)9.7.1. Doel van hetMAS-bericht
9.7.2. Inhoud van bericht
9.7.3. Regels voor toepassing9.7.4. Bevestiging van MAS-bericht
9.7.5. Voorbeeld
BIJLAGE A (NORMATIEF) REGELS VOOR HET INVOEGEN VAN GEGEVENS
BIJLAGE B (NORMATIEF) SPECIALE VEREISTEN VOOR ROUTEVERWERKING2000R2082 — NL — 15.06.2002 — 001.001 — 9
▼B
BIJLAGE C (TER INFORMATIE) DIALOOGPROCEDURE (SYSCO-NIVEAU 1) FASEN —
BERICHTENVOLGORDE2000R2082 — NL — 15.06.2002 — 001.001 — 10
▼B
AUTEURSRECHT
Ditdocumentis geproduceerd door Eurocont rol Agency.
Het auteursrecht berust bij Eurocontrol Agency.De inhoud of enig deel daarvan is derhalve vrijelijk beschikbaar voor verte-
genwoordigers van de lidstaten, maar kopiëren of openbaar maken aan
derden vereist voorafgaande schriftelijke toestemming van Eurocontrol
Agency.2000R2082 — NL — 15.06.2002 — 001.001 — 11
▼B
VOORWOORD
1. Verantwoordelijke instantie
De Eurocontrol-norm voor On-Line Data Interchange (OLDI),
Uitgave 2.2 is opgesteld door het Directorate of European ATCHarmonisation and Integration Programme (EATCHIP) Develop-
ment (DED), Eurocontrol, dat ook verantwoordelijk is voor het
actualiseren van het document. Alle eventuele opmerkingen of
vragen dienen te worden gericht aan de Director General, Euro-
control, Rue de la Fusée, 96, B-1130 Brussel, ter attentie van de
Divisie DED-2.
2. Relatie met het EATCHIP Work Programme Document
Deze norm vormteen t e realiseren onderdeel op grond van de
SpecialistTask DPS.ET1.ST06 van hetATM Dat a Processing
Systems (DPS) domein van EATCHIP zoals gespecificeerd in
hetEATCHIP Work Programme Document(EWPD) Edit ion 2.0,
gedateerd 30/09/94.
3. Goedkeuring en amendementen
Deze norm is onderworpen aan de volgende goedkeuringsproce-
dure zoals beschreven in de richtlijnen voor normalisatie van
Eurocontrol:
— goedkeuring door hetEATCHIP Operat ional Requirementand
ATM Data Processing Team (ODT) volgens schriftelijke
procedure;
— raadpleging van alle ECAC-staten via hun vertegenwoordigers
in het Committee of Management of in de EATCHIP Project
Board;
— goedkeuring door de EATCHIP ProjectBoard en de
Committee of Management;
— aanvaarding door de Permanente Commissie.
De bepalingen van deze norm worden van krachtna aanvaarding
door de Permanente Commissie.
Teneinde te voldoen aan de vereisten van de evolutie van de
procedures van Air Traffic Control (ATC), kunnen via de ODT
amendementen en aanvullingen worden voorgesteld ter bespre-
king en mogelijke goedkeuring. De vereisten worden ofwel
opgenomen als een amendementof als een volgende uit gave van
het document ter bekrachtiging en goedkeuring conform gespeci-
ficeerde procedures.
4. Redactionele conventies
De volgende gebruiken zijn gehanteerd om de status van elke
formulering aan te geven: Normatieve elementen staan afgedrukt
in tekst met een licht lettertype; Aanbevolen elementen staan
afgedrukt in een cursief licht lettertype, de status wordt aangeven
door hetprefix Aanbeveling .
Het volgende redactionele gebruik is gehanteerd bij het opstellen
van de specificaties: voor normatieve elementen zijn de (hulp)-
werkwoorden „zullen” of „dienen” gebruikten voor Aanbevolen
elementen zijn de (hulp)werkwoorden „zouden” of „dienen”
gebruikt.
Opmerkingen staan afgedrukt in een cursief licht lettertype, voor-
afgegaan door hetprefix „Opmerking”.
5. Relatie met Uitgave 1 van de Eurocontrol Standard for On
Line Data Interchange
Ditdocumentvervangtde delen 1 en 2 van Uit gave 1 van de
Eurocontrol Standard for On Line Data Interchange. Deel 3,
waarin de technische protocollen staan beschreven die dienen te
worden gebruikt, wordt vervangen door de Eurocontrol Standard
for Flight Data Exchange — Interface Control Document Part 1.2000R2082 — NL — 15.06.2002 — 001.001 — 12
▼B
6. Belangrijke wijzigingen ten opzichte van Uitgave 1
Hier volgteen overzichtvan de belangrijkst e wijzigingen en
aanvullingen ten opzichte van Uitgave 1:
1. Opname van de volgende complementaire (niet-verplichte)
berichten met betrekking tot de basisprocedure:
— Message for the Abrogation of Co-ordination (MAC)
[berichtvoor de opheffing van coördinat ie];
— Secondary Surveillance Radar (SSR) Code Assignment
(COD) Message [secundaire bewakingsradar codetoewij-
zingsbericht];
— Information (INF) Message [informatiebericht].
2. Definitie van inhoud en structuur van berichten ter ondersteu-
ning van hetoverschrijden van een grens door een vluchtop
een route die geen gedefinieerde Air Traffic Services (ATS)-
route is, maar die wordt gedefinieerd door de begin- en eind-
punten van het routesegment.
3. Integratie van een dialoogprocedure die het volgende mogelijk
maakt:
— de aanwijzing en totstandkoming van niet-standaard trans-
fervoorwaarden door vluchtleiders die de planningfunctie
uitvoeren;
— de mogelijkheid voor de accepterende eenheid om op zijn
beurt overdrachtsvoorwaarden voor te stellen;
— de overdracht van communicatiefaciliteiten als onderdeel
van de procedure voor overdrachtvan de cont role.
4. Het gebruik van de structuur beschreven in Uitgave 2 van het
Eurocontrol Standard Document for ATS Data Exchange
Presentation (ADEXP) wordt ingevoerd. Alle berichten die op
grond van de basisprocedure zijn gespecificeerd en berichten
die welke worden gebruikt tijdens de coördinatiefase van de
dialoogprocedure worden beschreven metgebruik van de
structuren van zowel de International Civil Aviation Organisa-tion (ICAO) als de ADEXP. Transfer of Communication-
berichten die zijn beschreven op grond van de dialoogproce-
dure worden alleen beschreven metgebruik van de ADEXP-
structuur.
5. Verwijderen van de volgende bijlagen bij Uitgave 1:
A ATC Unit Identification.
B OLDI Message Structure
(alle berichten in Uitgave 3 gaan vergezeld van voor-
beelden).
D Historical Overview.
E Implementation Plan.F Compliance by States.
G Guidelines for Implementation.
H Guidelines for Evaluation of OLDI.
6. Scheiding van Deel 3 — Tecnical Requirements — van de
specificatie van de applicaties.
7. Relatie tot andere documenten
In ditdocumentwordtgerefereerd aan hetgebruik van t wee
typen veldstructuren bij de samenstelling van berichten; namelijk
ICAO en ADEXP.
ICAO-veldstructuren worden beschreven in Referentie 1. In het
geval datReferent ie 1 wordtvervangen door een ander document
zal de definitie van ICAO-veldtypen zijn zoals beschreven in dat
document.
Structuren voor ADEXP-velden worden beschreven in Referentie
2.
OPMERKING Documenten waaraan gerefereerd wordt staan
vermeld in Sectie 2.2000R2082 — NL — 15.06.2002 — 001.001 — 13
▼B
8. Taal
Het origineel van dit document is gesteld in de Engelse taal.2000R2082 — NL — 15.06.2002 — 001.001 — 14
▼B
1. INLEIDING
1.1. Doelstelling
1.1.1. Vluchten die worden voorzien van een ATC-dienst worden door
de ene ATC-eenheid aan de andere overgedragen op een wijze
die is bedoeld om volledige veiligheid te garanderen. Om deze
doelstelling te verwezenlijken is het een standaardprocedure dat
het passeren door elke vlucht van de grens tussen de verantwoor-
delijkheidsgebieden van de twee eenheden door hen tevoren
wordtgecoördineerd en datde cont role over de vluchtwordt
overgedragen als deze zich op, of vlakbij, de genoemde grens
bevindt.
1.1.2. Waar dit plaatsvindt per telefoon, is de overdracht van gegevens
van individuele vluchten als onderdeel van het coördinatieproces
een belangrijke ondersteunende taak van ATC-eenheden, in het
bijzonder bij Area Control Centres (ACC)'s. Het operationele
gebruik van verbindingen tussen Flight Data Processing Systems
(FDPS)'s bij ACC's metals doel om dergelijke verbale „schat -
tingen” te vervangen, hetgeen On-Line Data Interchange (OLDI)
wordt genoemd, begon in Europa in de vroege jaren tachtig.
1.1.3. Om de implementatie te vergemakkelijken zijn algemene regels
en berichtenstructuren uitgewerkt en overeengekomen door de
betrokken instanties en opgenomen in Uitgave 1 van de Eurocon-
trol Standard for On-Line Data Interchange; het voorliggende
document, Uitgave 2.2, is geproduceerd ter ondersteuning van de
voortdurende ontwikkeling van zulke faciliteiten conform de
vereisten van EATCHIP.
1.2. Reikwijdte
1.2.1. Dit document bevat een specificatie van de faciliteiten en
berichten die dienen te worden geleverd door FDPS-en die voorATC-eenheden werken metals doel hetvolgende t e realiseren:
— de vereiste coördinatie voorafgaand aan de overdracht van
vluchten van de ene eenheid aan de volgende;
— de overdracht van de communicatie van dergelijke vluchten.
1.2.2. Ditdocumentbevat :
— definities van de berichtenstructuren en de regels voor de
inhoud daarvan;
— een beschrijving van de bij zulke eenheden vereiste facili-
teiten die een voorwaarde zijn voor het gebruik van
gegevensuitwisseling voor dit doeleinde.
1.2.3. Deze norm is binnen de lidstaten Eurocontrol van toepassing op
internationale OLDI-faciliteiten tussen eenheden die een ATC-
dienstvoor een gebied leveren.
1.2.4. Aanbeveling: Aanbevolen wordt dat de staten van de European
Civil Aviation Conference (ECAC) deze norm toepassen op:
—internationale OLDI-faciliteiten tussen eenheden die een
ATC-dienst voor een gebied leveren binnen het ECAC-gebied;
—OLDI-faciliteiten tussen eenheden die ATC-diensten voor een
gebied leveren die een intern onderdeel vormen van de
betrokken staat .
2. REFERENTIES
2.1. De volgende documenten bevatten bepalingen die, doordat er in
deze tekst naar wordt verwezen, bepalingen vormen van dit Euro-
control-normdocument.
Ten tijde van publicatie van dit Eurocontrol-normdocument
waren de genoemde uitgaven van de documenten waarnaar wordt
verwezen correct.
Metelke herziening van de ICAO-document en waarnaar wordt
verwezen wordtonmiddellijk rekening gehouden door ditEuro-
control-normdocument te herzien.
Herzieningen van de andere documenten waarnaar wordt
verwezen zullen geen deel uitmaken van de bepalingen van dit
Eurocontrol-normdocument totdat ze formeel zijn beoordeeld en
in ditEurocont rol-normdocumentzijn opgenomen.2000R2082 — NL — 15.06.2002 — 001.001 — 15
▼B
In het geval van conflicten tussen de vereisten van dit Eurocon-
trol-normdocument en de inhoud van deze andere documenten
waarnaar wordtverwezen, prevaleertditEurocont rol-normdocu-
ment.
2.2. In ditnormdocumentwordtverwezen naar de volgende docu-
menten:
1. Procedures for Air Navigation Services — Rules of the Air &
Air Traffic Services [procedures voor luchtvaartnavigatiedien-
sten — regels van de lucht- & luchtverkeersdiensten], ICAO
Document 4444, dertiende uitgave gedateerd 7 nov. 1996,
zoals geamendeerd.
2. Uitgave 2.0 van het Eurocontrol Standard Document for ATS
Data Exchange Presentation (ADEXP) [normdocument voor
de presentatie van ATS-gegevensuitwisseling], referentie
DPS-ET1-ST09-STD-01-00, gedateerd juni 1998.
3. DEFINITIES, SYMBOLEN EN AFKORTINGEN
3.1. Definities
Ten behoeve van deze Eurocontrol-norm gelden de volgende
definities.
3.1.1. Accepterende eenheid : de eenheid die een ATC-dienstleverten
de controle dient over te nemen of heeft overgenomen van een
vluchtals de overdrachtvan de ene eenheid naar de andere dient
plaats te vinden of heeft plaatsgevonden.
3.1.2. Bevestiging : mededeling dateen berichtis ont vangen en datis
gebleken dathetop de juist e manier kan worden verwerkt
3.1.3. Activering : hetproces in een ont vangende ATC-eenheid waarbij
het vluchtplan voor de betreffende vlucht wordt bijgewerkt met
de gegevens die worden aangeleverd door de overdragende
eenheid als onderdeel van het coördinatieproces tussen de twee
eenheden en die resulteert in het beschikbaar stellen van de gege-
vens aan vluchtleiders.
3.1.4. Hoogte : de verticale afstand van een niveau, een punt of een
object dat wordt beschouwd als een punt, gemeten vanaf het
gemiddelde zeeniveau.
3.1.5. Applicatie : datonderdeel van een ATS-subsyst eem datzich
conformeertaan deze norm en samenwerktmetzulke eenheden
in andere ATS-systemen.
3.1.6. Verantwoordelijkheidsgebied : een luchtruim met gedefinieerde
afmetingen waarbinnen een ATC-eenheid luchtverkeersleiding-
diensten levert.
3.1.7. Associatie : een procedure waarbij een systeem een ontvangen
OLDI-bericht associeert met een in de database ingevoerd vlucht-
plan.
3.1.8. ATC-eenheid : een eenheid die een luchtverkeersleidingdienst
levert.
3.1.9. Beschikbaarheid : de kans dat een faciliteit op een tijdstip voor
een gebruiker toegankelijk is.
3.1.10. Grens : de vlakken (lateraal en verticaal) die het verantwoordelijk-
heidsgebied van een ATC-eenheid afbakenen.
3.1.11. Vrijgegeven vluchtniveau : hetvlucht niveau waarnaar of waarop
een vluchtop ditmomentdoor ATC is vrijgegeven.
3.1.12. Coördinatie, ATC : het proces, uitgevoerd tussen ATC-eenheden
metaangrenzende verant woordelijkheidsgebieden, waarbij deze
elkaar formeel op de hoogte brengen van de geplande passage
van vluchten over de grens, teneinde de vluchtveiligheid te garan-
deren door middel van consistentie van voorgenomen acties.
3.1.13. Coördinatiebericht : een algemene term die verwijst naar een
berichtdatwordtgebruiktvoor hett otst and brengen van ATC-
coördinatie. Daartoe behoort de CDN, wat een specifiek bericht
is datwordtbesproken in paragaaf 8.8.
3.1.14. Coördinatiefase : met betrekking tot een bepaalde vlucht, de fase
gedurende welke de overdragende en ontvangende ATC-eenheden
de voorwaarden overeenkomen (bijv. vluchtniveau, grenspunt)2000R2082 — NL — 15.06.2002 — 001.001 — 16
▼B
waaronder een vluchtvan de leiding van de ene eenheid overgaat
naar die van de andere.
3.1.15. Coördinatiepunt : een puntop of naastde grens bekend bij de
ATC-eenheden in een coördinatiereeks en waarnaar wordt
verwezen in coördinatieberichten.
3.1.16. Correlatie : hetproces gebaseerd op gedefinieerde crit eria voor de
associatie van vluchtplangegevens en de radarbaan van dezelfde
vlucht, normaal gesproken voor presentatie op het display van
een vluchtleider.
3.1.17. Eurocontrol-norm : alle specificaties voor fysieke kenmerken,
configuratie, materiaal, prestaties, personeel of procedure,
waarvan de uniforme toepassing is goedgekeurd als zijnde essen-
tieel voor implementatie in ATS-systemen binnen lidstaten van
Eurocontrol. Een Eurocontrol-norm mag niet strijdig zijn met
ICAO-norms maar dient, waar van toepassing, een aanvulling op
laatstgenoemde te vormen.
3.1.18. Executive Controller : een vluchtleider die rechtstreeks instructies
geeft aan de vluchten onder zijn/haar controle. Tot dergelijke
vluchtleiders behoren die welke radarcontrolediensten voor het
gebied leveren.
3.1.19. Exit-niveau : hetniveau waarop een vluchtis gecoördineerd om
een controleoverdrachtspunt te passeren. Tot een exit-niveau
kunnen aanvullende passeervoorwaarden behoren die de niveau-
band definiëren waarbinnen een klimmende/dalende vluchtzich
zal bevinden.
3.1.20. Vluchtplan : gespecificeerde informatie geleverd aan luchtverkeer-
sdiensteenheden, met betrekking tot een voorgenomen vlucht of
deel van een vlucht van een vliegtuig. Daarnaast, informatie
afkomstig uit het vluchtplan van een specifieke vlucht die binnen
een FDPS plaatsvindt.
3.1.21. Genereren : een proces in een ATC-systeem waarbij relevante
gegevens uitde dat abase(s) worden opgehaald en een bericht
wordt samengesteld voor verzending aan een ontvangende ATC-
eenheid.
3.1.22. ICAO-structuur : de structuur die wordt gebruikt voor de grond-
grond-verzending van ATS-berichten en waarbij de veldtypen en
scheidingstekens zoals beschreven in Referentie 1 worden
gebruikt.
3.1.23. Niveau : een algemene term die betrekking heeft op de verticale
positie van een vliegtuig in de lucht; binnen deze norm omvat
de term niveau of vluchtniveau in de gevallen waarin het wordt
gebruiktook de hoogt e.
3.1.24. Mededeling : hetproces waarbij de overdragende eenheid gege-
vens verzendt om het systeem van de ontvangende eenheid bij te
werken ter voorbereiding van de coördinatiefase.
3.1.25. Ontvangende eenheid : de ATC-eenheid waarnaar een bericht
wordtverzonden.
3.1.26. Betrouwbaarheid : hetpercent age van de geplande beschikbaar-
heid gedurende welke de dienstbeschikbaar dientt e zijn.
3.1.27. Aangevraagd vluchtniveau : een vluchtniveau dat voor de vlucht
in hetvlucht plan wordtaangevraagd.
3.1.28. Herziening : een amendementop eerder door de overdragende
ATC-eenheid aan de ontvangende ATC-eenheid verzonden gege-
vens.
3.1.29. Supplementair passeerniveau : een niveau, waarop of waarboven,
of waarop of waaronder een vluchtgecoördineerd is om het
controleoverdrachtspunt te passeren. Het supplementaire niveau,
indien aanwezig, is een onderdeel van hetexit -niveau.
3.1.30. Systeemvluchtplan : informatie afkomstig uit het vluchtplan van
een specifieke vluchtdie plaat svindtbinnen een FDPS.
3.1.31. Transactietijd : een tijdsinterval volgend op de start van een
berichtgedurende welke de verzending, de eerst e verwerking in
het ontvangende systeem, het genereren en het verzenden van
een bevestigingsbericht en de identificatie daarvan in het overdra-
gende systeem plaatsvinden.2000R2082 — NL — 15.06.2002 — 001.001 — 17
▼B
3.1.32. Controleoverdrachtspunt : een gedefinieerd puntdatzich bevindt
op een vliegroute van een vliegtuig, waarop de verantwoordelijk-
heid voor de levering van ATS aan hetvliegt uig wordt
overgedragen van de ene ATC-eenheid of controlepost aan de
volgende. Valtnietnoodzakelijkerwijze samen methetcoördina-
tiepunt.
3.1.33. Overdrachtsfase : een vluchtfase die volgt op de coördinatiefase
en gedurende welke overdracht van de communicatie plaatsvindt.
3.1.34. Overdragende eenheid : in een coördinatiereeks, de ATC-eenheid
die verantwoordelijk is voor de levering van een dienst aan een
vluchtvoor de grens en die de coördinat iefase metde volgende
eenheid start.
3.1.35. Verzenden : een berichtvan hetene syst eem naar hetandere over-
brengen.
3.1.36. Eenheid : diensteenheid voor luchtverkeer.
3.1.37. Waarschuwing : een berichtdatop een werkplek wordtafgebeeld
als het automatische coördinatieproces is mislukt.
3.2. Symbolen en afkortingen
Ten behoeve van deze Eurocontrol-norm gelden de volgende
symbolen en afkortingen.
ABI Advance Boundary Information Message [vooraf-
gaand berichtmetgrensinformat ie]
ACC Area Control Centre [gebiedscontrolecentrum]
ACP AcceptMessage [berichtaccept eren]ACT Activate Message [bericht activeren]ADEXP ATS Data Exchange Presentation [presentatie uitwis-
seling ATS-gegevens]
ATC Air Traffic Control [luchtverkeersleiding]ATM Air Traffic Management[lucht verkeersbeheer]ATS Air Traffic Service [luchtverkeersdienst]
CDN Co-ordination Message [coördinatiebericht]
CNL Flight Plan Cancellation [annulering vluchtplan]COD SSR Code AssignmentMessage [t oewijzingsbericht
SSR-code]
COF Change of Frequency Message [frequentiewijzi-
gingsbericht]
COP Co-ordination Point [coördinatiepunt]
DED Directorate of EATCHIP Development, Eurocontrol
[directoraat van EATCHIP-ontwikkeling, Eurocon-
trol]
EATCHIP European ATC Harmonisation and Integration
Programme [Europees programma voor harmonisatie
en integratie van ATC]
ECAC European Civil Aviation Conference [Europese
burgerluchtvaartconferentie]
ETO Estimated Time Over [geschatte tijd boven]ETOT Estimated Take-Off Time [geschatte vertrektijd]
EWPD EATCHIP Work Programme Document[EATCHIP-
werkprogrammadocument]
FDPS Flight Data Processing System [systeem voor
verwerking van vluchtgegevens]
FRF Further Route of Flight [verdere vliegroute]HMI Human-Machine Interface [mens-machine-interface]HOP Handover Proposal Message [bericht met voorstel tot
overdracht]
ICAO International Civil Aviation Organisation [internatio-
nale organisatie voor de burgerluchtvaart]
INF Information Message [informatiebericht]LAM Logical AcknowledgementMessage [logisch beves-
tigingsbericht]2000R2082 — NL — 15.06.2002 — 001.001 — 18
▼B
LoA Letter of Agreement [overeenkomstbrief]
MAC Message for the Abrogation of Co-ordination
[berichtvoor de opheffing van coördinat ie]
MAS Manual Assumption of Communications [handma-
tige overname van communicatie]
NM Nautical Mile [zeemijl]OLDI On-Line Data Interchange [on-line gegevensuitwis-
seling]
ORCAM Originating Region Code Assignment Method [code-
toewijzingsmethode voor herkomstregio]
PAC Preliminary Activate Message [bericht van voorlo-
pige activering]
RAP Referred Activate Proposal Message [bericht met
voorstel tot activering waarnaar wordt verwezen]
REV Revision Message [herzien bericht]RJC RejectCo-ordinat ion Message [berichtmetafwijzing
van coördinatie]
ROF Requeston Frequency Message [berichtmetvraag
over frequentie]
RRV Referred Revision Message [herzien berichtwaar-
naar wordtverwezen]
SBY Stand-by Message [stand-by-bericht]
SDM Supplementary Data Message [supplementair gege-
vensbericht]
SSR Secondary Surveillance Radar [secundaire bewa-
kingsradar]
SYSCO System Supported Co-ordination [systeemonder-
steunde coördinatie]
TI Transfer Initiation [start van overdracht]TIM Transfer Initiation Message [bericht van start van
overdracht]
TWR/APP Tower (aerodrome control) and Approach Control
[toren- (vliegveldcontrole) en naderingscontrole]
4. ALGEMENE VEREISTEN
4.1. Inleiding
Dit gedeelte bevat een beschrijving van de algemene operationele
vereisten die noodzakelijk zijn voor de implementatie van een
OLDI-faciliteit tussen ATC-eenheden en de classificatie- en pres-
tatievereisten van de verschillende typen berichten die worden
gebruikt.
4.2. Vereisten voor het Flight Data Processing System
4.2.1. Vluchtdatabase
Eenheden die gebruik maken van een in ditdocumentbeschreven
faciliteit zullen worden voorzien van gegevens afkomstig van een
FDPS die alle benodigde informatie bevat voor de gespecifi-
ceerde afbeelding, verwerking en samenstelling van de berichten.
De primaire gegevensbron voor elke vluchtis hetvlucht plan
zoals ingediend door, of namens, de bevelvoerende piloot.
Verdere gegevens worden verzameld door de verwerking van
vluchtplannen met betrekking tot de omgeving van de betreffende
eenheid.
4.2.2. Real time-verwerking
De OLDI-procedure omvatgebeurt enissen in de overdragende
ATC-eenheid voor het starten van functies die noodzakelijk zijn
voor de tijdige presentatie van gegevens aan de overdragende
vluchtleider en de verzending van coördinatiegegevens aan de
accept erende eenheid. Voor datdoel zal hetFDPS in st aatzijn
om functies te starten door de vergelijking van Co-ordinated
Universal Time en toepasselijke tijdparameters met de tijden op
gespecificeerde posities op de vliegroute zoals bepaald aan de
hand van de vluchtdatabase.2000R2082 — NL — 15.06.2002 — 001.001 — 19
▼B
4.2.3. Datacommunicatie
4.2.3.1. Het FDPS zal in staat zijn om vluchtgegevens te ontvangen en te
verzenden in de toepasselijke structuur voor het bericht zoals
gespecificeerd in dit document via een datacommunicatiemedium
dat de OLDI-functie ondersteunt.
4.2.3.2. Aanbeveling: Het FDPS dient over het ontwikkelingspotentieel te
beschikken om de toevoeging van nieuwe berichten mogelijk te
maken die in toekomstige uitgaven van deze norm kunnen worden
opgenomen.
4.2.3.3. Binnen de in dit document gespecificeerde prestatievereisten zal
het medium voor datacommunicatie een snelle en betrouwbare
gegevensuitwisseling tussen applicaties mogelijk maken door:
— de integriteit van de verzending van OLDI-berichten te garan-
deren;
en
— waar van toepassing, de point-to-point-verbindingen of de
status van het communicatienetwerk te bewaken.
4.2.3.4. Het FDPS waarschuwt de werkplekken als het systeem voor data-
communicatie abnormaliteiten constateert.
4.2.4. Applicatiefuncties
4.2.4.1. De systemen die worden gebruikt voor de levering van OLDI-
faciliteiten zullen in staat zijn tot het automatisch en in real-time
ontvangen, opslaan, verwerken, onttrekken en afleveren van op
OLDI betrekking hebbende gegevens ten behoeve van afbeelding
en verzending.
4.2.4.2. HetFDPS zal:
— huidige operationele gegevens bevatten met betrekking tot de
OLDI-functie zoals vereist door deze norm, welke gegevens
automatisch of handmatig of door een combinatie daarvan
worden bijgewerkt;
— in staat zijn om dergelijke elementen te onttrekken aan de
vluchtplandatabase;
— de volgende ATC-eenheid op de vliegroute kunnen aangeven.
4.2.4.3. Hetvolgende wordtbilat eraal overeengekomen:
— Coördinatiepunten (COP's);
— Referentiepunten gebruikt voor koers- en afstandnotaties voor
het identificeren van het COP op directe, niet-ATS-routeseg-
menten, waar gebruikt.
OPMERKING de COP's hoeven niet altijd identiek te zijn aan de
controleoverdrachtspunten.
4.2.5. Human-Machine Interface (HMI)
4.2.5.1. De HMI zal in staat zijn om:
— de operationele inhoud van OLDI-berichten en relevante
waarschuwingen met betrekking tot ontvangen berichten die
onmiddellijke aandachtbehoeven af t e beelden;
— waarschuwingen met betrekking tot routecoördinatie- en over-
drachtsberichten door te geven aan de operationele posities
die verantwoordelijk zijn voor de coördinatie van de betref-
fende vluchten.
4.2.5.2. ATC-medewerkers zullen worden voorzien van middelen om de
gegevens waaruit de operationele inhoud van de berichten wordt
afgeleid aan te passen volgens de vereisten in dit document.
4.2.5.3. De HMI zal naar gelang de situatie aangeven of de verzending
van hetberichtplaat svindtof dathetmetsucces is verzonden.
4.2.5.4. Een waarschuwing of mededeling aan de betreffende ATC of
technische positie(s) wordt automatisch gegenereerd als geen
bevestiging wordt ontvangen binnen de parametertijd volgend op
een verzending van een coördinatie- of overdrachtsbericht.
4.2.5.5. Een dergelijke waarschuwing of mededeling zal plaatsvinden in
een vorm die onmiddellijk de aandacht trekt op de betreffende
werkplek.
4.2.5.6. Aanbeveling: De HMI op ATC-posities waar gebruik wordt
gemaakt van OLDI dient een waarschuwing af te geven als de
OLDI-faciliteit niet beschikbaar is.2000R2082 — NL — 15.06.2002 — 001.001 — 20
▼B
4.2.6. Starten van berichten
4.2.6.1. Elk systeem zal een reeks systeemparameters bevatten om een
tijdig, automatisch begin van OLDI-berichten mogelijk te maken.
4.2.6.2. Aanbeveling: Er dient een mogelijkheid aanwezig te zijn om
voorafgaand aan de berekende verzendtijd handmatig de verzen-
ding van een coördinatiebericht te starten.
4.2.6.3. De automatisch uitvoering dient altijd te zijn gewaarborgd als
geen handmatige uitvoering plaatsvindt.
4.2.6.4. Het systeem zal tijdparameters gebruiken om het volgende te
definiëren:
— aanlooptijd, voorafgaand aan verzending, als de operationele
inhoud van de berichten binnen de overdragende eenheid
wordtafgebeeld;
— aanlooptijd, globaal of per COP, om het bericht te verzenden,
waar van toepassing;
— tijd na verzending van een bericht waarbinnen een applica-
tieniveaubevestiging dient te worden ontvangen (time-out).
4.2.6.5. Een bericht dient onverwijld te worden verzonden als de vereiste
informatie beschikbaar komt op een tijdstip later dan dat waarop
hetanders zou zijn verzonden.
Voorbeeld: een vluchtbeginteen GAT IFR-segmentop een punt
dichtbij de grens die de vlucht dan zal passeren; de ETO op dat
puntwordtachtminut en voor hetCOP doorgegeven, op welk
tijdstip de verzending van het ACT-bericht reeds laat is op basis
van de betreffende tijdparameter(s); het bericht wordt onverwijld
verzonden.
4.2.7. Ontvangst van berichten
4.2.7.1. Het ATC-systeem dient in staat te zijn om:
— OLDI-berichten te ontvangen;
— deze automatisch te verwerken overeenkomstig deze norm;— vluchtgegevens te produceren overeenkomstig het ontvangen
bericht en vereiste waarschuwingen af te beelden in het geval
dat de ontvangen gegevens inconsistent zijn;
— op het applicatieniveau automatisch bevestigingsberichten te
genereren en te verzenden.
4.2.7.2. Een bevestigingsbericht (Logical Acknowledgement (LAM),
Accept (ACP) of Stand-by (SBY) bericht) zal worden gegene-
reerd en verzonden als hetbijbehorende berichtis verwerkten
de presentatie van de resultaten van de verwerking aan de betref-
fende positie(s), waar nodig, is verzekerd.
OPMERKING de gedetailleerde voorwaarden voor het gene-
reren van een bevestiging worden voor elk
bericht individueel gespecificeerd.
4.3. Bijwerken aan de hand van bewakingsgegevens
Aanbeveling: Om de nauwkeurigheid van geschatte tijdsgegevens
te garanderen dient informatie afkomstig van de registratie van
vluchten door radar of andere bewakingsmiddelen te worden
gebruikt om de vluchtplandatabase bij te werken.
4.4. Registratie van OLDI-gegevens
4.4.1. Inhoud
De inhoud van alle OLDI-berichten en het tijdstip van ontvangst
zullen worden geregistreerd.
4.4.2. Faciliteiten
Er zullen faciliteiten beschikbaar zijn voor het ophalen en
afbeelden van de geregistreerde gegevens.2000R2082 — NL — 15.06.2002 — 001.001 — 21
▼B
4.5. Beschikbaarheid, betrouwbaarheid, gegevensbeveiliging en
gegevensintegriteit
4.5.1. Beschikbaarheid
4.5.1.1. De OLDI-faciliteit zal beschikbaar zijn tijdens de normale uren
en piekuren van de verkeersstroom tussen de twee betreffende
eenheden.
4.5.1.2. Aanbeveling: De OLDI-faciliteit dient elke dag 24 uur beschik-
baar te zijn.
4.5.1.3. Alle geplande uitvalperioden (en dus de geplande beschikbaar-
heidtijd) zullen bilateraal worden overeengekomen tussen de
twee betreffende eenheden.
4.5.2. Betrouwbaarheid
4.5.2.1. De betrouwbaarheid van elke OLDI-verbinding zal ten minste
99,86 % bedragen (gelijk aan een uitvaltijd van niet meer dan
12 uur per jaar op basis van 24-uurs beschikbaarheid).
4.5.2.2. Aanbeveling: Waar operationeel gerechtvaardigd dient te
worden voorzien in een betrouwbaarheid van ten minste 99,99 %
(gelijk aan een uitvaltijd van niet meer dan 52 minuten per jaar,
op basis van een 24-uurs beschikbaarheid).
4.5.3. Gegevensbeveiliging
Aanbeveling: Methoden voor gegevensbeveiliging (bijv.
toegangsrechten, bronverificatie) en, indien van
toepassing, netwerkbeheer dienen op OLDI-facili-
teiten te worden toegepast.
4.5.4. Gegevensintegriteit
Het aantal fouten op applicatieniveau zal niet meer bedragen dan
een (1) verzendfoutper 2 000 bericht en.
4.6. Operationele evaluatie
4.6.1. Evaluatieperiode
Elke nieuwe OLDI-faciliteit, met inbegrip van een nieuwe facili-
teit op een bestaande verbinding, zal voorafgaand aan de
operationele implementatie worden onderworpen aan een evalua-
tieperiode om de gegevensintegriteit, nauwkeurigheid, prestaties
en compatibiliteit met ATC-procedures en de algehele veiligheid
te verifiëren.
OPMERKING een procedure die behulpzaam kan zijn bij de
evaluatie van een nieuwe OLDI-faciliteit is
verkrijgbaar bij het OLDI-secretariaat van Euro-
control.
4.6.2. Operationele introductiedatum
De datum van de operationele introductie, met andere woorden
het einde van de evaluatieperiode, zal door de twee eenheden
formeel worden overeengekomen.
5. BERICHTENCATEGORIEËN
5.1. Algemeen
5.1.1. Doelstelling
In dit gedeelte van het document:
— worden de berichtencategorieën gedefinieerd;
— worden de vereisten voor transactietijden voor de categorieën
vermeld;
— wordtvermeld welke bericht en verplichten welke comple-
mentair zijn;
— worden berichtentypen aan categorieën toegewezen.
5.1.2. Berichtencategorieën
OLDI-berichten zijn toegewezen aan de volgende categorieën:
— Categorie 1: Overdracht van communicatie;
— Categorie 2: Coördinatie;
— Categorie 3: Mededeling.2000R2082 — NL — 15.06.2002 — 001.001 — 22
▼B
5.2. Transactietijden
5.2.1. Voorwaarden voor transactietijden
5.2.1.1. De gespecificeerde transactietijden omvatten verzending, eerste
verwerking bij de ontvangende eenheid, aanmaak van het bevesti-
gingsbericht, de verzending daarvan en de ontvangst bij de
overdragende eenheid. De automatische bevestigingsberichten
LAM en SBY zijn daarom niet aan een berichtencategorie toege-
wezen.
5.2.1.2. De maximale transactietijden voor de verschillende categorieën
berichten zullen zijn zoals gespecificeerd in Tabel 5-1.
Tabel 5-1
Maximale transactietijden
Berichtencategorie 90 % 99,8 %
1 4 sec 10 sec
2 15 sec 10 sec
3 25 sec 45 sec
5.2.1.3. Per berichtencategorie of -type zal een time-out-waarde worden
gedefinieerd.
5.2.1.4. Als na verzending binnen de gespecificeerde tijd geen bevestiging
is ont vangen zal een berichtals nietmetsucces verzonden of
verwerktworden beschouwd en zal een waarschuwing worden
afgegeven zoals gespecificeerd in het betreffende gedeelte van
ditdocument .
5.2.1.5. Aanbeveling: De time-out-waarden voor de drie categorieën
mogen niet meer bedragen dan respectievelijk 12 seconden, 30
seconden en 60 seconden .
5.3. Berichtenclassificatie en -categorisatie
5.3.1. Berichtenclassificatie — verplicht en complementair
5.3.1.1. De in ditdocumentbeschreven bericht en worden geclassificeerd
als verplichtof complement air.
5.3.1.2. Als een berichtwordtomschreven als verplicht(V) voor verzen-
ding (TX), omvatditook de verwerking om dergelijke bericht en
te kunnen verzenden.
5.3.1.3. Als een berichtwordtomschreven als verplichtvoor ont vangst
(REC), omvat dit ook de verwerking om ontvangen berichten te
kunnen verwerken.
OPMERKING In uitzonderlijke gevallen, als de verkeersstroom
tussen twee eenheden zich in één richting
beweegt, kunnen de verplichte berichten alleen
op één richting betrekking hebben.
5.3.1.4. Als een berichtwordtomschreven als complement air (C) voor
verzending, omvatditook de verwerking om dergelijke bericht en
te verzenden indien vereist door de verzendende eenheid en bila-
teraal overeengekomen met de ontvangende eenheid.
OPMERKING Complementaire berichten mogen slechts in één
richting worden gebruikt, zoals bepaald door
operationele vereisten.
5.3.1.5. Als een berichtwordtomschreven als complement air voor
ontvangst, omvat dit ook de verwerking om ontvangen berichten
te kunnen verwerken als dergelijk gebruik bilateraal is overeenge-
komen.
5.3.1.6. De vereisten zoals beschreven in de Tabellen 5-3 en 5-4 zijn
alleen van toepassing als het gebruik van respectievelijk de
Dialoogprocedure voor coördinatie en/of Overdracht van commu-
nicatie bilateraal tussen ATC-eenheden is overeengekomen.
5.3.2. Categorisatie van berichten
5.3.2.1. De categorisatie van berichten voor de basisprocedure wordt
gespecificeerd inTabel 5-2.2000R2082 — NL — 15.06.2002 — 001.001 — 23
▼B
5.3.2.2. De categorisatie van de aanvullende coördinatieberichten voor de
dialoogprocedure wordtgespecificeerd in Tabel 5-3.
5.3.2.3. De categorisatie van berichten voor overdracht van communicatie
voor de dialoogprocedure wordtgespecificeerd in Tabel 5-4.
Tabel 5-2
Basisprocedureberichten
Berichttype Afkorting Categorie Verzending Ontvangst
Advance Boundary Infor-
mation (voorafgaande
grensinformatie)ABI 3 V V
Activate (activeren) ACT 2 V V
Revision (herziening) REV 2 C (1)C (1)
Preliminary Activate
(begin activering)PAC 2 C C
Abrogation of Co-ordina-
tion (opheffing van
coördinatie)MAC 2 C C
SSR Code Assignment
(SSR-codetoewijzing)COD 2 C C
Information (informatie) INF 3 C C
Logical Acknowledgement
Message (logisch bevesti-
gingsbericht)LAM V V
Opmerkingen
(1) Verplichtvoor TX en REC bij gebruik in een dialoogprocedure.
Tabel 5-3
Dialoogprocedure — Coördinatiefaseberichten
(aanvulling op Tabel 5-2)
Berichttype Afkorting Categorie Verzending Ontvangst
Referred Activate Proposal
(voorstel tot activering
waarnaar wordtverwezen)RAP 2 C V
Referred Revision (herzie-
ning waarnaar wordt
verwezen)RRV 2 C V
Co-ordination (coördinatie) CDN 2 V V
Stand-by (1) SBY V V
Accept (acceptatie) ACP 2 V V
RejectCo-ordinat ion
(afwijzing van coördi-
natie) (2)RJC 2 C C
Opmerkingen
(1) Zie paragraaf 5.2.1.1 Voorwaarden voor transactietijden.
(2) Niet in gebruik bij alle luchtruimconfiguraties.
Tabel 5-4
Dialoogprocedure — Overdrachtsfaseberichten
Berichttype Afkorting Categorie Verzending Ontvangst
Transfer Initiation (begin
overdracht)TIM 1 V V
Supplementary Data
(supplementaire gegevens)SDM 1 (1)(1)
Handover Proposal (voor-
stel tot overdracht)HOP 1 V V2000R2082 — NL — 15.06.2002 — 001.001 — 24
▼B
Berichttype Afkorting Categorie Verzending Ontvangst
Change of Frequency
(wijziging van
frequentie (2)COF 1 C V
Requeston Frequency
(vraag over frequentie)ROF 1 C V
Manual Assumption
(handmatige overname) (2)MAS 1 C V
Opmerkingen
(1) V bij verzending door de overdragende eenheid; C bij verzending door de accepterende
eenheid.
(2) In bilateraal overeengekomen procedures zal worden gespecificeerd dat als de overdracht
plaatsvindt met betrekking tot een bepaalde richting van de verkeersstroom, als minimum de
overdragende eenheid een COF-berichtzal zenden of de accept erende eenheid een MAS-berichtzal zenden.
6. BASISPROCEDURE — VERPLICHTE BERICHTEN
6.1. Algemeen
6.1.1. Beschrijving van de vereisten
Dit gedeelte bevat een beschrijving van de minimum vereisten op
het applicatieniveau voor de implementatie van OLDI-faciliteiten.
6.1.2. Implementatie
Eenheden die gebruik maken van OLDI voor de coördinatie van
vluchten zullen de ABI-, ACT- en LAM-berichten zoals in dit
gedeelte beschreven implementeren, behalve als bilateraal het
gebruik van de coördinatiedialoogprocedure is overeengekomen
zoals beschreven in Sectie 8 van dit document, in welk geval de
voorwaarden voor hetgebruik van ACT- en LAM-bericht en
zullen gelden zoals in datgedeelt e gedefinieerd.
6.2. ABI-bericht (Advance Boundary Information)
6.2.1. Doel van het ABI-bericht
Het ABI-bericht voldoet aan de volgende operationele vereisten:
— ontbrekende vluchtplangegevens ophalen;
— voorafgaande grensinformatie en herzieningen daarop voor de
volgende ATC-eenheid verzorgen;
— basisvluchtplangegevens bijwerken;— vroege correlatie van radarregistraties vergemakkelijken;— nauwkeurige beoordeling van sectorbelasting op korte termijn
vergemakkelijken.
HetABI-berichtis een mededelingbericht .
6.2.2. Inhoud van het bericht
Het ABI-bericht zal de volgende gegevens bevatten:
— Berichttype
— Berichtnummer
— Vliegtuigidentificatie
— SSR-modus en -code (indien beschikbaar)— Luchthaven van vertrek— Geschatte gegevens— Luchthaven van bestemming— Vliegtuignummer en -type— Vluchttype— Capaciteit en status van de apparatuur
— Route (optioneel)
— Overige vluchtplangegevens (optioneel).
OPMERKING: Regels voor invoegen van gegevens, structuren
en inhoud van velden worden gespecificeerd in
bijlage A.2000R2082 — NL — 15.06.2002 — 001.001 — 25
▼M1
▼B
6.2.3. Regels voor Toepassing
6.2.3.1. Algemeen
6.2.3.1.1. Behalve zoals bepaald in 6.2.3.1.3 en 6.2.3.1.4 hieronder zullen
een of meer ABI-berichten worden verzonden voor elke vlucht
die gepland is om de grens van verantwoordelijkheidsgebieden
te overschrijden waarvoor OLDI-procedures gelden.
6.2.3.1.2. Bij verzending zal hetABI-berichtvooraf gaan aan hetACT-
(Activate) of RAP-bericht (Referred Activate Proposal).
6.2.3.1.3. Er zal geen ABI-berichtworden gegenereerd als een PAC-bericht
(Preliminary Activate) dient te worden verzonden.
6.2.3.1.4. Aanbeveling: De verzending van ABI-berichten dient te worden
geblokkeerd als het ACT- of RAP-bericht onmiddellijk dient te
worden verzonden of binnen een bilateraal overeengekomen tijds-
interval.
OPMERKING Het doel van deze aanbeveling is om pogingen tot
gelijktijdige oplossing van onregelmatigheden op
verschillende posities van de ontvangende eenheid
met betrekking tot ABI- en ACT-berichten voor
dezelfde vlucht te voorkomen.
6.2.3.1.5. Een herzien ABI-berichtzal worden verzonden als hetdaarop
volgende ACT-berichtnietis gegenereerd en:
— de vliegrout e zodanig is gewijzigd dathetCOP in hetvorige
ABI-berichtnietlanger accuraatis;
— de luchthaven van bestemming is gewijzigd;
of
— het type vliegtuig is gewijzigd.
6.2.3.1.6. Aanbeveling: Een herzien ABI-berichtdientt e worden
verzonden als hetdaaropvolgende ACT-berichtnietis gegene-
reerd en een van de volgende onderdelen is gewijzigd:
—Het verwachte grensoverschrijdingniveau;
—De verwachte SSR-code op het controleoverdrachtspunt;
—Als de geschatte tijd boven (ETO) bij het COP meer van het
vorige ABI-bericht verschilt dan de tijd die is gespecificeerd
in de Letter of Agreement (LoA);
—Alle andere gegevens zoals bilateraal overeengekomen .
6.2.3.2. Verwerking in de ontvangende eenheid
6.2.3.2.1. Het ATC-systeem dat een ABI-bericht ontvangt zal proberen dit
te associëren met de bijbehorende vluchtplangegevens.
6.2.3.2.2. Als de associatie met het vluchtplan niet succesvol is, zal in het
ontvangende systeem automatisch of handmatig een vluchtplan
worden aangemaakt.
6.2.3.2.3. Als de associatie met het vluchtplan succesvol is maar een afwij-
king wordt geconstateerd tussen de gegevens in het bericht en
bijbehorende gegevens in het ontvangende systeem die zou resul-
teren in de noodzaak voor corrigerende actie bij ontvangst van
het volgende ACT-bericht, zal de afwijking naar een daartoe
aangewezen positie worden verwezen om te worden opgelost.
6.2.3.3. Tijdparameters voor verzending
6.2.3.3.1. Het bericht zal een parameter-aantal minuten voor de geschatte
tijd bij het COP worden verzonden.
6.2.3.3.2. De parameter(s) voor het genereren van ABI-berichten zullen
worden opgenomen in de LoA tussen de betreffende ATC-
eenheden.
6.2.3.3.3. Aanbeveling: De parameters(s) voor het genereren van ABI-
berichten dienen:
—variabel te zijn, gebaseerd op de bepalingen van de LoA;
—voor elk van de COP's afzonderlijk te worden gedefinieerd .
6.2.4. Bevestiging van ABI-bericht
6.2.4.1. Bevestiging
HetABI-berichtzal worden bevest igd door hetgenereren en
verzenden van een LAM-bericht.2000R2082 — NL — 15.06.2002 — 001.001 — 26
▼B
OPMERKING Een LAM-bericht wordt gegenereerd ongeacht het
resultaat van de poging om het vluchtplan te
associëren.
6.2.4.2. Geen bevestiging
Aanbeveling: Als geen LAM-bericht wordt ontvangen als bevesti-
ging voor een ABI-bericht, dient bij een toezichthoudende positie
een waarschuwing te worden afgebeeld.
6.2.5. Voorbeelden
„Air 2000” 253, een Boeing 757 van Malta naar Birmingham,
geschatte BNE VOR om 1221 UTC, vliegend op FL350 met een
werkelijke luchtsnelheid van 480 knopen, geplande route via UB4
BNE UB4 UB3 HON, transponder op A7012 en aanvraag voor
FL390. Hier volgen gelijkwaardige voorbeelden van hetABl-
berichtdatvan Reims naar Londen ACC wordtgezonden.
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. ACT-bericht (Activate)
6.3.1. Doel van het ACT-bericht
Het ACT-bericht voldoet aan de volgende operationele vereisten:
— De verbale grensschatting vervangen door de automatische
verzending van gegevens van een vluchtvan de ene ATC-
eenheid naar de volgende voorafgaand aan de overdrachtvan
de controle;
— Het basisvluchtplangegevens in de ontvangende ATC-eenheid
bijwerken met de meest recente informatie;
— Binnen de ontvangende ATC-eenheid de distributie en afbeel-
ding van vluchtplangegevens aan de betrokken werkplekken
vergemakkelijken;
— Afbeelden van oproepletters/code-correlatie in de ontvan-
gende ATC-eenheid bespoedigen;
— De ontvangende ATC-eenheid voorzien van overdrachtsvoor-
waarden.
6.3.2. Inhoud van het bericht
Het ACT-bericht zal de volgende gegevens bevatten:
— Berichttype
— Berichtnummer
— Vliegtuigidentificatie
— SSR-modus en -code
— Luchthaven van vertrek
— Geschatte gegevens— Luchthaven van bestemming
— Vliegtuignummer en -type
— Vluchttype
— Capaciteit en status van de apparatuur
— Route (optioneel)— Overige vluchtplangegevens (optioneel).
OPMERKING: Regels voor invoegen van gegevens, structuren
en inhoud van velden worden gespecificeerd in
bijlage A.2000R2082 — NL — 15.06.2002 — 001.001 — 27
▼M1
▼B
▼M1
▼B
6.3.3. Regels voor toepassing
6.3.3.1. Algemeen6.3.3.1.1. Voor daarvoor in aanmerking komende vluchten die de grens
overschrijden zal een ACT-berichtworden verzonden, behalve
zoals voorzien in paragraaf 6.3.3.1.10.
6.3.3.1.2. Het ACT-bericht zal automatisch op de berekende tijd worden
gegenereerd en verzonden zoals gespecificeerd in de LoA, tenzij
het handmatig op een eerder tijdstip wordt gestart.
6.3.3.1.3. Aanbeveling: ATC-medewerkers dienen te worden voorzien van
een middel om de verzending van ACT-berichten te starten voor-
afgaand aan de berekende verzendtijd.
6.3.3.1.4. De operat ionele inhoud van hetACT-berichtdatop hetpuntst aat
om te worden verzonden zal worden afgebeeld op de werkplek
die verantwoordelijk is voor de coördinatie van de vlucht vooraf-
gaand aan de feitelijke verzending.
6.3.3.1.5. Aanbeveling: Met betrekking tot 6.3.3.1.4 dient de tijd waarop is
berekend dat de ACT automatisch dient te worden verzonden
samen met de inhoud te worden afgebeeld.
6.3.3.1.6. Het ACT-bericht zal de meest recente informatie over de vlucht
bevatten, waaruit de verwachte exit-voorwaarden blijken.
6.3.3.1.7. De betreffende werkplek zal worden geïnformeerd over de
verzending van hetACT-bericht .
6.3.3.1.8. Zodra een LAM-bericht is ontvangen worden de ACT-berichtge-
gevens operationeel bindend voor beide ATC-eenheden. Degecoördineerde overdracht svoorwaarden en hetfeitdathet
LAM-berichtis ont vangen zullen aan de ATC-medewerkers van
de overdragende eenheid worden gepresenteerd.
6.3.3.1.9. Aanvaarding door de ontvangende eenheid van de in het ACT-
berichtgeïmpliceerde overdracht svoorwaarden zal worden veron-
dersteld, tenzij de ontvangende eenheid coördinatie start om deze
te amenderen.
6.3.3.1.10. Een volgend ACT-berichtmag alleen naar dezelfde coördinat ie-
partner worden verzonden als het vorige is opgeheven door het
gebruik van een MAC-bericht.
6.3.3.1.11. Indien bilateraal overeengekomen zullen de route en andere
vluchtplangegevens worden meegezonden.
6.3.3.2. Verwerking in de ontvangende eenheid6.3.3.2.1. Het ATC-systeem dat een ACT-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
6.3.3.2.2. Als een bijbehorend vluchtplan wordt gevonden en geen afwij-
king in hetberichtvoorkomtdie een correct e verwerking zou
verhinderen:
— zal de operationele inhoud worden opgenomen in het vlucht-
plan;
— zullen de vereiste gegevens beschikbaar worden gesteld op de
daarvoor in aanmerking komende operationele ATC- en
andere posities;
— zal een LAM-berichtworden t eruggezonden.
6.3.3.2.3. Als geen bijbehorend vluchtplan kan worden gevonden, of als een
afwijking wordt aangetroffen die de juiste verwerking van het
berichtverhindert :
— als de verantwoordelijke sector voor het accepteren van de
controle over de vlucht kan worden geïdentificeerd:
— zal de operationele inhoud van het bericht worden afge-
beeld bij de sector;
— zal een LAM-berichtworden t eruggezonden;
— zal een vluchtplan worden aangemaakt;
— in alle andere gevallen zal geen LAM-berichtworden t erugge-
stuurd.2000R2082 — NL — 15.06.2002 — 001.001 — 28
▼B
6.3.3.3. Parameters voor verzending
6.3.3.3.1. Hetberichtzal op of zo snel mogelijk na de eerdere van de als
volgtbepaalde t ijden worden verzonden:
— een parameter-aantal minuten voor de geschatte tijd bij het
COP;
— de tijd waarop de vlucht zich op een bilateraal overeenge-
komen afstand van het COP bevindt.
6.3.3.3.2. De parameter(s) voor het genereren van ACT-berichten zal/zullen
worden opgenomen in de LoA tussen de betreffende ATC-
eenheden.
6.3.3.3.3. De parameter(s) voor het genereren van ACT-berichten zal/zullen
variabel zijn en gebaseerd op de bepalingen van de LoA.
6.3.3.3.4. Aanbeveling: De parameter(s) voor het genereren van ACT-
berichten dient/dienen voor elk van de COP's afzonderlijk te
worden gedefinieerd.
6.3.3.3.5. De gespecificeerde parameters zullen voldoende tijd toestaan
voor:
— de verzendende eenheid om hetoverdracht sniveau van de
vlucht bij te werken met de te verwachten omstandigheden
op hetCOP;
en
— de ontvangende eenheid om het ACT-bericht te verwerken en
een LAM-bericht te genereren en te verzenden maar nog
steeds verbale coördinatie door de overdragende eenheid
mogelijk te maken, alsmede resulterende actie gestart door
de accepterende eenheid als de uitwisseling van gegevens
mislukt.
6.3.4. Bevestiging van ACT-bericht
6.3.4.1. Bevestiging
HetACT-berichtzal worden bevest igd door hetgenereren en
verzenden van een LAM-bericht.
6.3.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
ACT-berichtzal een waarschuwing worden afgebeeld op de
ATC-positie die verantwoordelijk is voor de coördinatie van de
vlucht.
6.3.5. Voorbeelden
De volgende voorbeelden vormen een uitbreiding op die welke
werden gegeven voor hetABI-berichtin paragraaf 6.2; alle
details zijn hetzelfde behalve de ETO op het COP, die in het
afgebeelde ACT-bericht1226 is.
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 HON
6.4. LAM-bericht (Logical Acknowledgement Message)
6.4.1. Doel van het LAM-bericht
HetLAM-berichtis hetmiddel waarmee door de ont vangende
eenheid aan de verzendende eenheid de ontvangst en beveiliging
van een verzonden berichtwordtaangegeven.2000R2082 — NL — 15.06.2002 — 001.001 — 29
▼M1
▼B
▼B
De verwerking van hetLAM-berichtvoorzietde ATC-medewer-
kers van de overdragende eenheid van hetvolgende:
— een waarschuwing als geen bevestiging werd ontvangen;
— een indicat ie dathetberichtdatwordtbevest igd is ont vangen,
met succes is verwerkt, foutvrij is bevonden, is opgeslagen en,
indien relevant, beschikbaar is voor presentatie aan de betref-
fende werkplek(ken).
6.4.2. Inhoud van bericht
Het LAM-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;
— berichtreferentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
6.4.3. Regels voor toepassing
6.4.3.1. Algemeen6.4.3.1.1. De regels voor hett erugzenden van een LAM-berichtzijn gespe-
cificeerd in de gedeelten van dit document waarin de verwerking
van elke berichtwordtgedefinieerd.
6.4.3.1.2. HetLAM-berichtzal worden gegenereerd en verzonden zonder
menselijke tussenkomst.
6.4.3.1.3. HetLAM-berichtzal nietworden gebruiktvoor hetvermijden
van de behoefte aan technische berichten bedoeld om de integri-
teit van gegevensoverdracht te garanderen.
6.4.3.1.4. HetLAM-berichtzal onmiddellijk worden gegenereerd en
verzonden zodat de vereiste transactietijd van het bericht dat
wordtbevest igd kan worden gerealiseerd.
6.4.3.1.5. Met uitzondering van ABI-berichten zal het verzendende ATC-
systeem de vluchtleider die verantwoordelijk is voor coördinatie
op de hoogte stellen als binnen de voor zulke waarschuwingen
gestelde tijdparameter geen LAM-bericht is ontvangen.
6.4.4. Bevestiging van LAM-bericht
HetLAM-berichtzal geen bevest iging vereisen.
6.4.5. Voorbeelden
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. BASISPROCEDURE — COMPLEMENTAIRE BERICHTEN
7.1. Algemeen
7.1.1. Beschrijving van vereiste
In dit gedeelte worden faciliteiten beschreven die van toepassing
zijn op de basisprocedure en die een aanvulling vormen op die
welke zijn beschreven in Sectie 6 Basisprocedure — Verplichte
berichten.
7.1.2. Implementatie
7.1.2.1. Het gebruik van alle in dit gedeelte beschreven faciliteiten zal
voorafgaand aan hun introductie bilateraal worden overeenge-
komen.
7.1.2.2. Als een dergelijk gebruik is overeengekomen zullen de in dit
gedeelte beschreven regels worden toegepast.2000R2082 — NL — 15.06.2002 — 001.001 — 30
▼B
7.2. PAC-bericht(PreliminaryActivateMessage)
7.2.1. DoelvanhetPAC-bericht
HetPAC-berichtvoldoetaandevolgendeoperationelevereisten:
—mededelingencoördinatievoorafgaandaanvertrekvaneen
vluchtwaarvandevluchtduurvanvertrektotaanhetCOP
minderbedraagtdandiewelkevereistzouzijnomtevoldoen
aandeovereengekomentijdparametersvoorverzendingvan
eenACT-bericht;
—mededelingencoördinatievoorafgaandaanvertrekvaneen
vluchtdooreenlokale(luchthaven/naderingscontrole)eenheid
naardevolgendeeenheiddiedecontroleoverdevluchtover-
neemt;
—zorgtvoorophalenvanontbrekendevluchtplangegevensin
hetgevalvanafwijkingenindeeersteverzendingvanvlucht-plangegevens;
—vraagt,indiennodig,detoewijzingvaneenSSR-codevande
eenheidwaaraandebovengenoemdemededeling/coördinatie
isverzonden.
7.2.2.Inhoudvanbericht
HetPAC-berichtzaldevolgendegegevensbevatten:
—berichttype;
—berichtnummer;
—berichtreferentie (optioneel);—vliegtuigidentificatie;
—SSR-modus en -code;
—luchthavenvan vertrek;
—luchthaven van bestemming;
—type vliegtuig;—route(optioneel);
—overige vluchtplangegevens (optioneel).
OPMERKING:Regelsvoorinvoegenvangegevens,structuren
eninhoudvanveldenwordengespecificeerdin
BijlageA.
7.2.3. Regels voor toepassing
7.2.3.1. Algemeen
7.2.3.1.1. Voor elke vluchtdie gepland is om de grenzen van verant woorde-
lijkheidsgebieden te passeren zullen een of meer PAC-berichten
worden verzonden als de tijd vanaf vertrek tot het COP niet toe
zou staan dat het ACT-bericht op het vereiste tijdstip wordt
verzonden.
7.2.3.1.2. Voor elke vertrekkende vlucht waarvoor mededeling of coördi-
natie is vereist zullen door de luchthaven-/naderingseenheid eenof meer PAC-berichten aan de volgende eenheid worden
verzonden.
7.2.3.1.3. Aanbeveling: Voor de implementatie van PAC/LAM tussen
eenheden dienen de betreffende TWR/APP-systemen te worden
voorzien van een middel om „start-up” ,„push-back” , „taxi” of
soortgelijke informatie waaraan de ETOT kan worden ontleendin te voeren en door te zenden teneinde de ETO bij het COP te
berekenen en de verzending van het PAC-bericht te starten.
7.2.3.1.4. Zoals bilateraal overeengekomen zal het bericht het volgende
bevatten:
— geschatte vertrektijd;
of
— geschatte gegevens.
7.2.3.1.5. Als, door bilaterale overeenkomst, de berichtreferentie wordt
meegezonden zal deze:— het berichtnummer bevatten van het eerste PAC-bericht dat
voor de vluchtwordtverzonden;
— zijn opgenomen in tweede en daarop volgende PAC-
berichten.2000R2082 — NL — 15.06.2002 — 001.001 — 31
—  geschatte vertrektijd of geschatte gegevens;
▼B
7.2.3.1.6. Indien vereist zal het gebruik van de codeaanvraagfaciliteit bilate-
raal worden overeengekomen.
7.2.3.1.7. Als, voorafgaand aan vertrek, aan een van de volgende voor-
waarden wordtvoldaan zal een herzien PAC-berichtworden
verzonden:
— de vliegrout e is zodanig gewijzigd dathetCOP in hetvorige
berichtnietlanger accuraatis;
— het type vliegtuig is gewijzigd;— de luchthaven van bestemming in het vorige PAC-bericht is
onjuistbevonden.
7.2.3.1.8. Aanbeveling: Als, voorafgaand aan vertrek, de volgende gege-
vens verschillen van die in hetvorige PAC-berichtdienteen
herzien PAC-berichtt e worden verzonden:
—het niveau (in de geschatte gegevens, indien aanwezig);
—de verwachte SSR-code op het controleoverdrachtspunt;
—de geschatte vertrektijd of de ETO bij het COP met een tijd
die een bilateraal overeengekomen waarde overschrijdt;
—er een wijziging optreedt in andere gegevens, zoals bilateraal
overeengekomen .
7.2.3.2. Verwerking in de ontvangende eenheid7.2.3.2.1. Het ATC-systeem dat een PAC-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
7.2.3.2.2. Als een bijbehorend vluchtplan wordt gevonden en geen afwij-
king in hetberichtvoorkomtdie een correct e verwerking zou
verhinderen:
— zal de operationele inhoud worden opgenomen in het vlucht-
plan;
— zullen de vereiste gegevens beschikbaar worden gesteld op de
betreffende operationele ATC- en andere posities;
— zal een LAM-berichtworden t eruggezonden.
7.2.3.2.3. Als geen bijbehorend vluchtplan kan worden gevonden of als er
een afwijking wordt geconstateerd die een juiste verwerking van
hetberichtverhinderd:
— als de verantwoordelijke sector voor het accepteren van de
controle op de vlucht kan worden geïdentificeerd:
— zal de operationele inhoud van het bericht bij de sector
worden afgebeeld;
— zal een LAM-berichtworden t eruggezonden;
— zal een vluchtplan worden aangemaakt;
— in alle andere gevallen zal geen LAM-berichtworden t erugge-
zonden.
7.2.3.2.4. De gegevens in een tweede of daarop volgend PAC-bericht zullen
de plaats innemen van de gegevens in het vorige bericht.
7.2.3.2.5. Als hetPAC-berichteen verzoek voor de t oewijzing van een
SSR-code bevaten op correct e wijze verwerkbaar is zoals
beschreven in paragraaf 7.2.3.2.2 hierboven zal naasthetLAM-
berichtook een COD-berichtworden t eruggezonden.
OPMERKING Aangezien het proces voor de toewijzing van
codes gedetailleerde route-informatie voor het
vluchtplan vereist, bevat dit document geen
vereisten voor het terugzenden van een COD-
bericht door de ontvangende eenheid waar zulke
gegevens mogelijk niet beschikbaar zijn voor de
vlucht. Dit verhindert niet dat onder zulke
omstandigheden een bericht wordt teruggezonden
als een specifieke plaatselijke faciliteit daarvoor
bestaat en de procedure bilateraal is overeenge-
komen.
7.2.3.3. Tijdparameters voor verzending
Een verzendtijdparameter is niet van toepassing aangezien het
bericht wordt verzonden als het resultaat van een handmatig inge-
voerd berichtdathetop handen zijnde vert rek van de vlucht
aangeeft.2000R2082 — NL — 15.06.2002 — 001.001 — 32
▼B
7.2.4. Bevestiging van PAC-bericht
7.2.4.1. Bevestiging
De berichten die dienen te worden verzonden als antwoord op een
PAC-berichtworden beschreven in paragraaf 7.2.3.2 hierboven.
7.2.4.2. Geen bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
PAC-bericht zal op de positie in de ATC-eenheid die verantwoor-
delijk is voor coördinatie met de volgende eenheid een
waarschuwing worden afgebeeld.
7.2.4.3. Gevallen zonder LAM-bevestiging
In gevallen zonder LAM-bevestiging zal verbale coördinatieworden gestart.
7.2.4.4. Geen COD-bericht
7.2.4.4.1. Als geen COD-bericht wordt ontvangen in antwoord op een code-
verzoek datis opgenomen in hetPAC-berichtzal op een daart oe
geschikte plaats een waarschuwing worden afgebeeld.
7.2.4.4.2. Waar de codeverzoekfunctie dient te worden gebruikt zal de
toepasselijke time-out-waarde bilateraal worden overeengekomen.
7.2.5. Voorbeelden
7.2.5.1. Geschatte vertrektijd en codeverzoek
7.2.5.1.1. ICAO
(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)
7.2.5.1.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC
SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP
LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA
7.2.5.2. Tijd bij COP
7.2.5.2.1. ICAO
(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-
EBBR-9/B737/M)
7.2.5.2.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP
EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL
F110A -ARCTYP B737 -ADES EBBR
7.3.REV-bericht(Revision)
7.3.1.DoelvanhetREV-bericht
HetREV-berichtwordtgebruiktvoorhetverzendenvanherzie-
ningenopeerderineenACT-berichtverzonden
coördinatiegegevensmitsdeaccepterendeeenheidnietverandert
alsgevolgvandeaanpassing.
7.3.2.Inhoudvanhet bericht
HetREV-berichtzaldevolgendegegevensbevatten:
—Berichttype
—Berichtnummer—Vliegtuigidentificatie—Luchthaven van vertrek—Geschatte gegevens en/of coördinatiepunt
—Luchthaven van bestemming
—Berichtreferentie (optioneel)
—SSR-modus en -code (optioneel)—Route (optioneel)—Capaciteit en status van de apparatuur (optioneel).2000R2082 — NL — 15.06.2002 — 001.001 — 33
M1▼
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
bijlageA.
7.3.3. Regels voor toepassing
7.3.3.1. Algemeen
7.3.3.1.1. Door het gebruik van een Activate-bericht kunnen een of meer
REV-berichten worden verzonden naar de eenheid waarnaar een
vluchtop ditmomentis gecoördineerd.
7.3.3.1.2. De volgende elementen zullen zijn onderworpen aan herzie-
ningen:
— ETO bij hetCOP;
— overdrachtsniveau(s);
— SSR-code;
— capaciteit en status van de apparatuur.
7.3.3.1.3. Een REV-berichtzal worden verzonden als:
— de ETO bij hetCOP meer dan een bilat eraal overeengekomen
waarde verschiltvan die in hetvorige bericht , afgerond op de
dichtst bijgelegen gehele getalswaarde;
— er sprake is van een wijziging in het(de) overdracht sni-
veau(s), de SSR-code of de capaciteit en status van deapparatuur.
7.3.3.1.4. Indien bilateraal overeengekomen zal een REV-bericht worden
verzonden als zich een verandering in een van onderstaande
onderdelen voordoet:
— COP;
— route.
OPMERKING: Operationele regels kunnen vereisen dat aanpas-
singen die na ACT plaatsvinden, zijn
onderworpen aan voorafgaande coördinatie
tussen de betrokken eenheden.
7.3.3.1.5. Indien bilateraal overeengekomen zal de berichtreferentie in het
REV-berichtworden opgenomen.
7.3.3.1.6. De berichtreferentie, indien opgenomen, zal het berichtnummer
van het voorafgaande ACT-bericht bevatten.
7.3.3.1.7. Acceptatie door de ontvangende ATC-eenheid van de over-
drachtsvoorwaarden die zijn geïmpliceerd in het REV-bericht zalworden verondersteld, tenzij de ontvangende ATC-eenheid
coördinatie start om deze te amenderen.
7.3.3.2. Structuren van herzieningsberichten
7.3.3.2.1. I C A O-structuur
Alle herzieningsberichten bevatten de veldtypen 3, 7, 13, 14 en
16. De volgende regels zijn van toepassing:
— een wijziging in de ETO bij het COP of het/de overdrachtsni-
veau(s) zal worden verwerktdoor de opname van de herziene
gegevens in veld 14;
— een wijziging in de SSR-code zal worden opgenomen als
elementen b) en c) in veld 7.
Alle overige aanpassingen zullen worden opgenomen als veld 22-gegevens na de eerste vijf velden. De volgende regels zijn van
toepassing:
— velden die worden opgenomen in de veld 22-structuur kunnen
ten opzichte van elkaar in willekeurige volgorde staan;
— een wijziging in hetCOP zal worden opgenomen als veld 14-
gegeven in veld 22-structuur (zie bijlage B „Speciale
vereisten voor routeverwerking”);
— routewijzigingen zullen worden opgenomen als veld 15-gege-
vens in de veld 22-structuur. Regels voor de coördinatie vanzulke wijzigingen, met inbegrip van directe routebepalingen,
worden gespecificeerd in bijlage B „Speciale vereisten voor
routeverwerking”;2000R2082 — NL — 15.06.2002 — 001.001 — 34
▼M1
▼B
M1▼M1▼
B▼
▼M1
— capaciteit en status van de apparatuur; alleen die capaci-
teit(en) welke wordt (worden) gewijzigd, wordt (worden)
opgenomen. In een berichtbet reffende de wijziging van een
capaciteit, dat resulteert in de noodzaak om gegevens betref-
fende de aanvullende capaciteit op te nemen als aangegeven
in bijlage A, puntA.30, wordtdie aanvullende capacit eit
opgenomen.
7.3.3.2.2. A D E X P-structuur
Alle herzieningsberichten in ADEXP-structuur zullen de volgende
primaire velden bevatten: TITLE REFDATA ARCID ADEP
ADES. De volgende regels zijn van toepassing:
— een wijziging in de ETO bij het COP of de (het) overdracht-
sniveau(s) zal worden verwerktdoor de opname van de
herziene gegevens in hetprimaire veld COORDATA;
— hetprimaire veld COP wordtopgenomen t enzij een wijziging
van de ETO of de (het) overdrachtsniveau(s) het gebruik van
hetprimaire veld COORDATA noodzakelijk maakt . Derge-lijke berichten zullen het COP omvatten waardoor de vlucht
momenteel gecoördineerd wordt, of, indien het COP gewij-
zigd is, hetCOP waardoor de vluchtvoorheen gecoördineerd
was;
— wijzigingen van hetCOP worden opgenomen in hetprimaire
veld COORDATA (zie bijlage B „Speciale vereisten voor
routeverwerking”). Dergelijke berichten zullen ook het
primaire veld COP omvatten zoals hierboven aangegeven;
— routewijzigingen worden opgenomen in het primaire veld
ROUTE. Regels voor de coördinatie van zulke wijzigingen,
met inbegrip van directe routebepalingen, worden gespecifi-
ceerd in bijlage B „Speciale vereisten voor routeverwerking”;
— een wijziging in de SSR-code wordtaangegeven door de
opname van hetprimaire veld SSRCODE;
— een wijziging van de capaciteit en status van de apparatuur
wordtaangegeven in hetprimaire veld EQCST; alleen die
capaciteit(en) welke wordt (worden) gewijzigd, wordt
(worden) opgenomen. In een berichtbet reffende de wijziging
van een capaciteit, dat resulteert in de noodzaak om gegevens
betreffende de aanvullende capaciteit op te nemen als aange-
geven in bijlage A, puntA.30, wordtdie aanvullende
capaciteit opgenomen.
7.3.3.2.3. SSR-code
SSR-modus en -code zal alleen in een REV-berichtworden opge-
nomen als hetvereistis om een wijziging in SSR-code t e
coördineren.
7.3.3.3. Verwerking in de ontvangende eenheid
7.3.3.3.1. Als voor de betreffende vlucht een ACT is ontvangen van
dezelfde ATC-eenheid zal hetATC-syst eem dateen REV-bericht
ontvangt proberen om dit te associëren met het bijbehorende
vluchtplan.
7.3.3.3.2. Als een bijbehorend vluchtplan wordt gevonden en geen afwij-
king in het bericht wordt geconstateerd die een correcte
verwerking zou verhinderen:
— zal de operationele inhoud worden opgenomen in het vlucht-
plan;
— zullen de vereiste gegevens waar van toepassing ter beschik-
king worden gesteld aan operationele ATC- en andere
posities.
7.3.3.4. Verzending starten
7.3.3.4.1. Het REV-bericht wordt aangestuurd door gebeurtenissen en zal
onmiddellijk na de betreffende invoer of wijziging worden
verstuurd.
7.3.3.4.2. Nadat de vlucht zich op een gespecificeerde tijd/afstand van het
overdracht spuntbevindtmogen door hetgebruik van hetREV-
berichtgeen wijzigingen worden doorgevoerd. De t ijd- en
afstandparameters zullen bilateraal worden overeengekomen.
7.3.3.4.3. Aanbeveling: De REV-parameters dienen voor elk van de COP's
afzonderlijk te worden gedefinieerd.2000R2082 — NL — 15.06.2002 — 001.001 — 35
▼B
▼B
7.3.3.5. Wijziging van de ontvangende ATC-eenheid
HetREV-berichtzal nietworden gebruiktals een herziening van
vluchtplangegevens leidt tot een wijziging van de ontvangende
ATC-eenheid (zie Berichtvoor de opheffing van coördinat ie).
7.3.4. Bevestiging van REV-bericht
7.3.4.1. Bevestiging
Als hetREV-bericht :
— kan worden geassocieerd meteen vlucht plan binnen het
ontvangende systeem zal ter bevestiging een LAM-bericht
worden verzonden;
— nietkan worden geassocieerd meteen vlucht plan binnen het
ontvangende systeem zal geen LAM-bericht worden
verzonden.
7.3.4.2. Geen bevestiging7.3.4.2.1. Als geen LAM-bericht ter bevestiging van een REV-bericht
wordtont vangen zal een waarschuwing worden afgebeeld op de
ATC-positie die verantwoordelijk is voor de coördinatie van de
vluchten.
7.3.4.2.2. In gevallen waarin geen LAM-berichtwordtont vangen zal door
de overdragende ATC-eenheid een verbale herziening worden
gestart.
7.3.5. Voorbeelden
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. MAC-bericht (Message for the Abrogation of Co-ordination)
7.4.1. Doel van het MAC-bericht
Een MAC-berichtwordtgebruiktom aan de ont vangende eenheid
kenbaar te maken dat de eerder voor een vlucht geleverde coördi-
natie of mededeling wordt opgeheven.
HetMAC-berichtis geen vervanging voor een annuleringsbericht
(CNL-bericht), zoals gedefinieerd door ICAO, en zal daarom niet
worden gebruikt om de basisvluchtplangegevens te wissen.
7.4.2. Inhoud van bericht
Het MAC-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;
— berichtreferentie (optioneel);2000R2082 — NL — 15.06.2002 — 001.001 — 36
▼M1
▼B
▼B
— vliegtuigidentificatie;
— luchthaven van vertrek;
— coördinatiepunt;
— luchthaven van bestemming;
— coördinatiestatus en -reden (optioneel).
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
7.4.3. Regels voor toepassing
7.4.3.1. Algemeen
7.4.3.1.1. Als een van onderstaande zaken plaatsvinden zal aan een eenheid
waaraan eerder door middel van een ACT- of RAP-bericht
coördinatie voor een vlucht is verzonden een MAC-bericht
worden verzonden:
— hetverwacht e niveau op hetoverdracht spuntverschiltvan het
niveau in het vorige bericht hetgeen resulteert in een wijzi-
ging van de volgende eenheid in de coördinatievolgorde;
— de vliegroute is gewijzigd hetgeen resulteert in een wijziging
van de volgende eenheid in de coördinatievolgorde;
— het systeemvluchtplan is geannuleerd in de verzendende
eenheid en de coördinatie niet langer relevant is;
— er met betrekking tot de vlucht een MAC-bericht is ontvangen
van de vorige eenheid.
7.4.3.1.2. Als hetMAC-berichtis verzonden als gevolg van een wijziging
in het vluchtniveau of de route, zal, waar van toepassing, mede-
deling en/of coördinatie plaatsvinden met de nieuwe eenheid in
de coördinatievolgorde.
7.4.3.1.3. Een MAC-berichtzal worden verzonden als de coördinat ie voor
een vertrekkende vlucht, die wordt bewerkstelligd door het
gebruik van een PAC-bericht, wordt opgeheven.
7.4.3.1.4. Aanbeveling: Er dient een MAC-bericht te worden verzonden als
de eerder voor een vlucht verzonden mededeling (ABI-bericht)
wordt geannuleerd als gevolg van een van de redenen gespecifi-
ceerd in paragraaf 7.4.3.1.1 hierboven of als de vlucht onderweg
wordt vertraagd en een herziene schatting niet automatisch kan
worden bepaald.
7.4.3.1.5. Indien bilateraal overeengekomen zal een berichtreferentie
worden meegezonden.
7.4.3.1.6. Indien meegezonden zal de berichtreferentie het berichtnummer
van het laatste voor de vlucht verzonden en bevestigde ABI-,
PAC- of ACT-bericht bevatten.
7.4.3.1.7. Hetcoördinat iepuntzal hetCOP zijn via welke eerder de mede-
deling of coördinatie van de vlucht hebben plaatsgevonden.
7.4.3.1.8. Aanbeveling: Het MAC-bericht dient de status aan te geven
waarnaar de coördinatie of mededeling dient terug te keren en
de reden voor de opheffing.
7.4.3.1.9. Indien meegezonden zullen de status en de reden een van de
volgende combinaties zijn:
— als de ontvangende eenheid niet langer de volgende coördina-
tiepartner is:
— de status is INI (initieel);
— de reden is een van de volgende:
— TFL als de reden een wijziging van hetoverdracht sni-
veau is;
— RTE als de reden een routewijziging is;
— CSN als de reden een wijziging in hetoproept eken is;
— CAN als de reden een annulering is;
— OTH voor alle andere redenen of als de reden onbe-
kend is;
— als een van de volgende voorwaarden van toepassing is:
— de coördinat ie door hetgebruik van hetvorige PAC- of
ACT-bericht(zoals gewijzigd door volgende REV-
berichten) wordt opgeheven maar de vlucht zal naar2000R2082 — NL — 15.06.2002 — 001.001 — 37
▼B
verwachting het onderwerp zijn van een nieuwe coördina-
tiereeks bij dezelfde eenheid;
of
— volgend op de verzending van een ABI-berichtis de
vluchtvoor een ongedefinieerde periode in de wachtgezet
en zal naar verwachting het onderwerp zijn van een
herzien ABI- of ACT-bericht, waar van toepassing:
— de status is NTF (notification = mededeling);
— de reden is een van de volgende:
— DLY als de reden een vertraging is (delay);
— HLD als de reden een wachtsituatie is (hold);— OTH voor elke andere reden (other) of als de
reden onbekend is.
7.4.3.1.10. Als een nieuwe mededeling voor de vluchtwordtafgegeven of
als deze opnieuw wordtgecoördineerd:
— zal, waar van toepassing, een nieuw mededelingsbericht en/of
coördinatiebericht worden verzonden;
— zal hetbasisvlucht plan datis opgeslagen in de ont vangende
ATC-eenheid nietworden beïnvloed door een MAC-bericht ;
— zal het systeem de mogelijkheid behouden om op correcte
wijze een nieuw mededeling- en/of coördinatiebericht te
verwerken van ofwel de vorige overdragende eenheid of een
andere eenheid in een nieuwe coördinatiereeks.
7.4.3.2. Verwerking in de ontvangende eenheid
De werkplek(ken) in de ontvangende ATC-eenheid die worden
voorzien van vluchtgegevens zullen op de hoogte worden gesteld
van de opheffing.
7.4.4. Bevestiging van MAC-bericht
7.4.4.1. Bevestiging
7.4.4.1.1. Als hetMAC-berichtkan worden geassocieerd meteen vlucht -
plan binnen het ontvangende systeem en kan worden verwerkt,
zal ter bevestiging een LAM-bericht worden verzonden.
7.4.4.1.2. Als hetMAC-berichtnietkan worden geassocieerd meteen
vluchtplan binnen het ontvangende systeem, of niet kan worden
verwerkt, zal geen LAM-bericht worden verzonden.
7.4.4.2. Geen bevestiging
7.4.4.2.1. Als ATC-coördinatie wordt opgeheven en geen LAM-bericht is
ontvangen zal een waarschuwing worden afgebeeld op de ATC-
positie die verantwoordelijk is voor de coördinatie.
7.4.4.2.2. In dergelijke gevallen zal door een overdragende ATC-eenheid
een verbale opheffing van de coördinatie worden uitgevoerd.
7.4.5. Voorbeelden
Er is een ABI-berichtverzonden door Amst erdam ACC aan
Brussel ACC voor vluchtHOZ3188, gepland voor FL190; de
vlucht verzoekt daarna om te mogen klimmen tot FL270 en
ontvangt daartoe toestemming en gaat daarmee het luchtruim
van Maastricht binnen in plaats van dat van Brussel. De voor-
beelden 7.4.5.1 a en 7.4.5.2 a tonen hoe het MAC-bericht dat
door Amsterdam naar Brussel wordt gezonden zowel in ICAO-
als in ADEXP-structuur zou verschijnen.
Er wordt een ABI- en later een ACT-bericht naar Maastricht
gezonden, maar een paar minuten voordat het COP wordt bereikt
keert het vliegtuig terug naar Amsterdam Airport en wordt het
vluchtplan geannuleerd in het systeem van de verzendende
eenheid; zoals blijktuitde voorbeelden (7.4.5.1 b en 7.4.5.2 b)
wordteen MAC-berichtnaar Maast richtgezonden.
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)2000R2082 — NL — 15.06.2002 — 001.001 — 38
▼B
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 -STATRE-
ASON TFL
b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -
FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES
LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATRE-
ASON CAN
7.5. COD-bericht (SSR Code Assignment)
7.5.1. Doel van het COD-bericht
7.5.1.1. Het doel van de Originating Region Code Allocation Method
(ORCAM) is om een vlucht in staat te stellen om met dezelfde
code te reageren op opeenvolgende eenheden binnen een deelne-
mend gebied. Tenzij de codetoewijzing centraal plaatsvindt,
bijvoorbeeld door een ACC, kan hetnodig zijn om aan vlieg-
velden individueel een reeks afzonderlijke SSR-codes toe te
wijzen. Dergelijke toewijzingen zijn een grote verspilling van
codes.
7.5.1.2. Het COD-bericht voldoet aan de operationele vereiste voor het
verstrekken van een Mode A SSR-code door de ene Air Traffic
Service-eenheid aan de andere voor een speciale vluchtindien
daarom wordt verzocht. Indien bilateraal overeengekomen maakt
een optionele faciliteit het de verstrekkende eenheid mogelijk om
de vliegroute op te nemen.
7.5.2. Inhoud van bericht
Het COD-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;
— berichtreferentie (optioneel);
— vliegtuigidentificatie;— SSR-modus en -code;— vliegveld van vertrek;
— vliegveld van bestemming;
— route (optioneel).
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
7.5.3. Regels voor toepassing
7.5.3.1. Algemeen7.5.3.1.1. Een COD-bericht zal automatisch worden gegenereerd en
verzonden als antwoord op een verzoek voor het toewijzen van
een code datbinnen een berichtwordtont vangen.
7.5.3.1.2. De SSR-code zal de code zijn die aan de vluchtwordtt oege-
wezen.
7.5.3.1.3. De goedgekeurde verzadigingscode, zoals gespecificeerd in het
Air Navigation Plan for the European Region, zal worden inge-
voegd als een afzonderlijke code nietbeschikbaar is.
7.5.3.1.4. Indien bilateraal overeengekomen zal de berichtreferentie, die het
bericht nummer bevatvan hetberichtwaarop hetCOD-berichteen
reactie is, worden opgenomen.
7.5.3.1.5. Indien bilateraal overeengekomen zal de route worden opge-
nomen.
7.5.3.1.6. Acceptatie van de SSR-code door de eenheid die het COD-bericht
ontvangt zal worden verondersteld.
7.5.3.2. Verwerking in de ontvangende eenheid7.5.3.2.1. Mits het bericht geen afwijking bevat die een correcte verwerking
zou verhinderen zal een LAM-berichtworden t eruggezonden.
7.5.3.2.2. Als hetberichtnietkan worden geassocieerd meteen vlucht plan
of als een afwijking wordt geconstateerd die een correcte verwer-2000R2082 — NL — 15.06.2002 — 001.001 — 39
▼B
king van hetberichtverhindertzal geen LAM-berichtworden
teruggezonden.
7.5.3.2.3. Routegegevens, indien opgenomen, zullen geen reden zijn om het
terugzenden van een LAM-bericht te verhinderen, tenzij het
bericht niet voldoet aan de structuurvereisten zoals vermeld in
Bijlage A.
7.5.3.3. Tijdparameters voor verzending
Een verzendtijdparameter zal niet van toepassing zijn, omdat het
COD-berichtwordtverzonden als gevolg van de ont vangstvan
een berichtwaarin om de t oewijzing van een SSR-code wordt
verzocht.
7.5.4. Bevestiging van COD-bericht
7.5.4.1. Bevestiging
HetCOD-berichtzal worden bevest igd door hetgenereren en
verzenden van een LAM-bericht.
7.5.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
COD-bericht zal op een daartoe aangewezen plaats een waarschu-
wing worden afgebeeld.
7.5.5. Voorbeelden
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. INF-bericht (Information)
7.6.1. Doel van het INF-bericht
7.6.1.1. HetINF-berichtwordtgebruiktom informat ie over specifieke
vluchten te leveren aan instanties die niet direct betrokken zijn
bij het coördinatieproces tussen twee opeenvolgende ATC-
eenheden op de vliegroute.
7.6.1.2. HetINF-berichtkan worden gebruiktom kopieën van bericht en
te leveren en om overeengekomen coördinatievoorwaarden aan
dergelijke instanties door te geven volgend op een dialoog tussen
vluchtleiders. Voor dit doel kunnen INF-berichten worden gege-
nereerd door de systemen van de overdragende of accepterendeeenheid.
7.6.1.3. Het bericht kan ook worden gebruikt om informatie te leveren
met betrekking tot enig punt op de vliegroute naar een instantie.
7.6.1.4. De structuur maakt de communicatie mogelijk van initiële gege-
vens, herzieningen en annuleringen.
7.6.2. Inhoud van bericht
Het INF-bericht zal de volgende gegevens bevatten in de struc-
tuur van een bericht zoals beschreven in dit document:
— berichttype;
— berichtnummer;
— alle onderdelen van operationele gegevens zoals die zich
bevinden in hetoorspronkelijke berichtof daaruitvolgende
coördinatie die wordt gekopieerd;
— type referentiebericht.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
7.6.3. Regels voor toepassing
7.6.3.1. Berichttypen
Het/de type(n) bericht(en) die dient/dienen te worden gedupli-
ceerd door een INF-berichtzal/zullen gebaseerd zijn op vereist en
van gebruikers en de mogelijkheden van de verzendende eenheid.2000R2082 — NL — 15.06.2002 — 001.001 — 40
▼B
Type(n) bericht(en) en toepassingsregels zullen, in het algemeen,
bilateraal worden overeengekomen.
7.6.3.2. Geadresseerden van bericht
Voor dezelfde vluchtkunnen een of meer INF-bericht en worden
verzonden naar een of meer geadresseerden.
7.6.3.3. Operationele in houd
De operationele inhoud van het INF-bericht zal de structuur
hebben van een van de bestaande berichten.
7.6.3.4. Aanbevelingen
1.Voorwaarden die worden verzonden in een eerste dialoogbe-
richt (bijv. ACT-, RAP-, REV-, RRV-bericht) kunnen worden
gewijzigd of afgewezen voordat de dialoog is voltooid. Verzen-
dende eenheden dienen in staat te zijn om de uiteindelijk
overeengekomen coördinatievoorwaarden te verzenden .
2.Het INF-bericht dient onmiddellijk te worden verzonden, of op
een tijdstip dat is gerelateerd aan het tijdstip bij het COP, dat
bilateraal wordt overeengekomen met de ontvangende instel-
ling.
7.6.4. Bevestiging van INF-bericht
Aanbevelingen1.Het INF-bericht kan afhankelijk van de coördinatiepartner
worden bevestigd door het genereren en verzenden van een
LAM-bericht .
2.Afhankelijk van bilaterale overeenkomsten tussen de betref-
fende eenheden, dient als er geen LAM-bericht als
bevestiging voor een INF-bericht wordt ontvangen, op een
daartoe geschikte plaats een waarschuwing te worden afge-
beeld .
7.6.5. Voorbeelden
Een vluchtmetoproept eken BAW011, B747 van EGLL naar
OMDB op FL290, aanvraag voor FL410, schatKoksy (KOK)
VOR om 1905, transponder op A5437, voortgang via UG1 en
UB6.
Voor de vluchtwordtdoor Londen een ACT-berichtnaar
Maastricht gezonden. Vanuit Londen wordt een kopie gezonden
naar een eenheid die wordtgeïdent ificeerd als IT.
Hier volgen enkele voorbeelden van hetINF-bericht .
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. DIALOOGPROCEDURE — COÖRDINATIE
8.1. Algemeen
8.1.1. Inleiding
8.1.1.1. De dialoogprocedure biedt faciliteiten voor communicatie en
onderhandeling tussen vluchtleiders in de coördinatiefase en
voor communicatie in de overdrachtsfase.
8.1.1.2. Dit gedeelte bevat een beschrijving van de berichten die worden
gebruiktin de dialoogprocedure in de coördinat iefase waarin de
overdrachtsvoorwaarden worden gepland. De berichten voor de
overdrachtsfase waarin de overdracht van de vlucht plaatsvindt
staan beschreven in Sectie 9 — Dialoogprocedure — Overdracht
van communicatie.2000R2082 — NL — 15.06.2002 — 001.001 — 41
▼B
8.1.1.3. Procedures voor de twee fasen zijn niet afhankelijk van elkaar, ze
kunnen zowel individueel als samen worden geïmplementeerd.
8.1.1.4. Er worden een aantal aanvullende berichten geïntroduceerd en de
mogelijkheid voor elk van de partners om een dialoog te starten
wordtonderst eund.
8.1.1.5. De coördinatiedialoogprocedure maakt de identificatie mogelijk
van:
— overdrachten die overeenkomstig LoA's zijn en automatisch
kunnen worden geaccepteerd; en
— die welke dienen te worden verwezen naar de vluchtleider van
de ontvangende eenheid voor een beslissing met betrekking
tot acceptatie.
8.1.1.6. Deze procedure maakt het ook mogelijk om de interpretatie van
de LoA's binnen de twee systemen te bewaken en eventuele
afwijkingen tussen de twee te signaleren.
8.1.2. Het filter
8.1.2.1. Algemeen
8.1.2.1.1. De coördinatiedialoogprocedure vereist dat systemen aangeven of
overdrachten al dan niet in overeenstemming zijn met LoA's.
8.1.2.1.2. Hetproces waarbij ditwordtgecont roleerd wordtin ditdocument
„het filter” genoemd. De database die voor het filter wordt
gebruikt zal, indien vereist, het volgende bevatten:
— overeengekomen coördinatiepunten;
— in aanmerking komende (of nietin aanmerking komende)
vluchtniveaus die ook kunnen worden geassocieerd met de
coördinatiepunten;
— luchthavens van vertrek;— bestemmingen;— overeengekomen directe routes;
— tijd- en/of afstandslimieten voorafgaand aan het COP, waarna
elk coördinatiebericht als niet-standaard wordt beschouwd;
— alle andere voorwaarden, zoals bilateraal overeengekomen.
8.1.2.1.3. Alle onderdelen in deze lijstkunnen worden gecombineerd om
meer complexe voorwaarden te definiëren.
8.1.2.1.4. In Sectie 8 van dit document zal de term „standaardvoorwaarden”
worden geïnterpreteerd als „in overeenstemming met de LoA” en
de term „niet-standaardvoorwaarden” als „niet in overeenstem-
ming metde LoA”. Tenzij bilat eraal overeengekomen, zullen
berichten verzonden door overdragende eenheden voor coördina-
ties die bekend zijn als standaard andere berichtentypen
gebruiken dan die waarvoor de voorwaarden niet-standaard zijn.
8.1.2.2. Actie in de overdragende eenheid
8.1.2.2.1. Het filter in de overdragende eenheid zal de overdrachtsvoor-
waarden controleren die op het punt staan om naar de
accepterende eenheid te worden verzonden.
8.1.2.2.2. Aanbeveling: Als geconstateerd wordt dat de overdrachtsvoor-
waarden niet-standaard zijn, dan dient dit feit onder de
aandacht van de overdragende vluchtleider te worden gebracht
ten behoeve van bevestiging of wijziging.
8.1.2.3. Actie in de accepterende eenheid
8.1.2.3.1. Alle ACT- en REV-berichten zullen door het filter worden gecon-
troleerd.
8.1.2.3.2. Als de controle aangeeft dat de ontvangen overdrachtsvoor-
waarden niet-standaard zijn, zullen ze worden verwezen naar de
vluchtleider voor een beslissing, in het andere geval zullen ze
automatisch worden geaccepteerd.
8.1.2.4. Synchronisatie van de filters
8.1.2.4.1. Het gebruik van verschillende berichten voor standaard en niet-
standaard overdrachtsvoorwaarden maakt het mogelijk om afwij-
kingen te constateren tussen de standaardvoorwaarden van de
systemen in de overdragende en accepterende eenheden.
8.1.2.4.2. De constatering in de accepterende eenheid van niet-standaard
overdrachtsvoorwaarden in een bericht dat wordt gebruikt om2000R2082 — NL — 15.06.2002 — 001.001 — 42
▼B
alleen standaard overdrachten te coördineren betekent dat er een
afwijking tussen de twee filters bestaat. Dergelijke afwijkingen
dienen te worden opgelost om de dialoogprocedure doelmatig te
laten verlopen.
8.1.3. Berichtenvolgorde
8.1.3.1. Algemeen
8.1.3.1.1. Bepaalde regels dienen te worden gevolgd om ervoor te zorgen
dat de coördinatie voltooid is voordat eventuele herziening of
uitwisseling van berichten voor communicatieoverdracht plaats-
vindt en ook om ervoor te zorgen dat vluchtleiders van beide
eenheden niet tegelijkertijd voorstellen doen voor dezelfde vlucht.
8.1.3.1.2. Een ATC-eenheid zal alleen ontvangst van een Revision-bericht
(REV of RRV) voor een vluchtverzenden of bevest igen als deze
zich in de gecoördineerde staat bevindt, d.w.z. dat een ACT- of
RAP-dialoog is voltooid door een LAM- of ACP-bericht.
8.1.3.1.3. CDN-berichten zullen alleen in aanmerking komen voor verzen-
ding door de accepterende eenheid.
8.1.3.1.4. CDN-berichten zullen alleen worden verzonden en bevestigd:
— als onderdeel van een dialoog die wordtgest artdoor de
ontvangst van een Activate- (ACT, RAP) of Revision-bericht
(REV of RRV); of
— als hetvlucht plan voor die vluchtzich in de gecoördineerde
staat bevindt.
8.1.4. Gelijktijdige afhandeling van berichten
8.1.4.1. Algemeen
8.1.4.1.1. Een eenheid die is betrokken bij een uitwisseling van coördinatie-
of overdrachtsberichten voor een vlucht zal geen verdere uitwis-
seling van coördinatie- of overdrachtsberichten voor dezelfde
vlucht met dezelfde eenheid starten totdat ofwel een LAM-,
ACP- of RJC-bericht is ontvangen, of een time-out is bereikt.
8.1.4.1.2. Hetis mogelijk dateen CDN-berichteen REV-, RRV- of MAC-
berichtvoor dezelfde vluchtkruistdatis verzonden door de over-
dragende eenheid. Deze situatie kan in de overdragende eenheid
worden geconstateerd door het CDN-bericht dat arriveert vooraf-
gaand aan de bevestiging voor het verzonden coördinatiebericht
en in de accepterende eenheid door het bericht van de overdra-
gende eenheid datarriveertvoorafgaand aan de bevest iging van
hetCDN-bericht . In datgeval zal hetCDN-berichtnietworden
bevestigd en zal het REV-, RRV- of MAC-bericht worden
verwerkt.
8.1.5. Behandeling van afwijzing
HetRJC-berichtbeëindigteen syst eemdialoog. Er dienteen
nieuwe systeemcoördinatie te worden gestart die waar van toepas-
sing de telefonische coördinatie aangeeft.
8.1.6. Operationele time-out voor antwoord
8.1.6.1. Algemeen
8.1.6.1.1. Er zal in de verzendende en ontvangende centra een time-out-
mechanisme worden toegepast voor het antwoord op berichten
die naar de vluchtleider worden verwezen.
8.1.6.1.2. De duur van deze time-outs zal bilateraal worden overeenge-
komen.
8.1.6.1.3. De afloop van de time-out bij de verzendende eenheid zal resul-
teren in de verzending van een waarschuwing aan de
overdragende vluchtleider, om de noodzaak aan te geven van het
starten van een telefonische coördinatie.
8.1.6.1.4. Aanbevelingen
1.Er dient een waarschuwing te worden afgebeeld op de ATC-
positie van de accepterende eenheid die verantwoordelijk is
voor de vlucht als de time-out in de overdragende eenheid op
het punt staat om plaats te vinden .
2.De waarschuwing dient rekening te houden met de verzendtijd
van het antwoord .2000R2082 — NL — 15.06.2002 — 001.001 — 43
▼B
8.1.6.1.5. Systemen zullen in staat zijn om antwoorden te verwerken die
worden ontvangen na afloop van de time-out.
8.1.7. Implementatie
8.1.7.1. De dialoogprocedures hebben betrekking op twee fasen, namelijk
de coördinatiefase en de overdrachtsfase. De dialoog in de twee
fasen maakt gebruik van verschillende berichten en de vereiste
transactietijden zijn verschillend. De coördinatieberichten worden
gespecificeerd in ICAO- en ADEXP-structuur, de berichten voor
communicatieoverdracht alleen in ADEXP.
8.1.7.2. De minimum HMI-vereisten voor de coördinatiedialoog
verschillen van die voor de overdrachtsdialoog:
— de overdrachtsdialoog heeft primair betrekking op de uitvoe-
rende controlefunctie en vereist een snelle en
gebruikersvriendelijke HMI;
— de coördinatiedialoog is niet zo tijdgevoelig en daarom zijn
de betreffende HMI-vereisten van een lagere orde.
8.1.7.3. De dialoogprocedure zal worden geïmplementeerd met gebruik
van een van de volgende alternatieve scenario's:
— coördinatiefase dialoogprocedure plus eventuele complemen-
taire berichten zoals bilateraal overeengekomen (Secties 7 en
8);
— basis coördinatieprocedure en overdrachtsfase dialoogproce-
dure (Secties 6, 7 en 9);
— coördinatie- en overdrachtsfase dialoogprocedure plus even-
tuele complementaire coördinatieberichten zoals bilateraal
overeengekomen (Secties 7, 8 en 9).
HetAdvance Boundary Informat ion-berichtzal in alle scenario's
worden verzonden.
8.1.7.4. Het voor de implementatie gebruikte scenario zal bilateraal
worden overeengekomen.
8.2. ACT-bericht (Activate)
8.2.1. Doel van het ACT-bericht
Hetdoel van hetACT-berichtst aatbeschreven in paragraaf 6.3.1.
In een dialoogprocedure wordthetACT-berichtgebruiktom aan
deze vereisten te voldoen, mits de overdrachtsvoorwaarden voor
de vlucht standaard zijn en de overdragende vluchtleider de
vlucht niet naar de accepterende vluchtleider hoeft te verwijzen
voor acceptatie.
8.2.2. Inhoud van bericht
De inhoud van hetACT-berichtdatin de dialoogprocedure wordt
gebruiktzal zijn zoals beschreven voor hetACT-berichtin para-
graaf 6.3.2.
8.2.3. Regels voor toepassing
8.2.3.1. Algemeen8.2.3.1.1. De regels voor toepassing zijn zoals beschreven voor het ACT-
berichtin paragraaf 6.3 metuit zondering van de speciale regels
die worden beschreven in deze paragraaf.
8.2.3.1.2. Er zal een ACT-berichtworden verzonden voor een vluchtmet
standaard overdrachtsvoorwaarden waarvoor de overdragende
vluchtleider niet vereist dat deze wordt verwezen naar de accep-
terende vluchtleider.
OPMERKING Als deze vereisten niet van toepassing zijn wordt
een RAP-bericht verzonden (zie paragraaf 8.3
Referred Activate Proposal-bericht).
8.2.3.1.3. Aanbeveling: Er dient een nieuwe coördinatieprocedure te
worden gestart als een RJC-bericht (Reject Co-ordination) wordt
teruggezonden als antwoord op een ACT-bericht.
8.2.3.2. Verwerking in de ontvangende eenheid8.2.3.2.1. Het bericht wordt door het filter gecontroleerd om te bevestigen
dat de voorgestelde voorwaarden standaard zijn.2000R2082 — NL — 15.06.2002 — 001.001 — 44
▼B
8.2.3.2.2. Hetberichtzal worden verwerktals een RAP-berichtals:
— blijkt dat de overdrachtsvoorwaarden niet-standaard zijn;
— geen bijbehorend vluchtplan kan worden gevonden en er
onvoldoende informatie beschikbaar is om te bepalen of de
overdrachtsvoorwaarden al dan niet standaard zijn.
8.2.3.2.3. ACT-berichten die standaard blijken te zijn zullen worden
verwerktovereenkomst ig paragraaf 6.3.3.2.
8.2.3.2.4. Aanbeveling: Als de overdrachtsvoorwaarden in een ACT-bericht
niet-standaard blijken te zijn bestaat er een afwijking tussen de
filters in de twee systemen. Het feit dat het ACT-bericht niet-stan-
daard is dient ter kennis van toezichthoudende medewerkers te
worden gebracht zodat de afwijking kan worden opgeheven.
8.2.4. Bevestiging van ACT-bericht
8.2.4.1. Bevestiging
8.2.4.1.1. In een dialoogprocedure zal een ACT-berichtworden bevest igd
door:
— een LAM-bericht als de overdrachtsvoorwaarden standaard
blijken te zijn;
— een SBY-berichtin alle andere gevallen.
8.2.4.1.2. Als een LAM-bericht is ontvangen zal de operationele inhoud van
hetACT-berichtoperat ioneel bindend worden voor beide ATC-
eenheden.
8.2.4.1.3. Indien bilateraal overeengekomen kan een ACP-bericht worden
gebruikt in plaats van een LAM-bericht om de acceptatie door
de accepterende eenheid van een ACT-bericht met standaard
overdrachtsvoorwaarden aan te geven.
8.2.4.2. Gevallen zonder bevestiging
Als geen bevestiging voor een ACT-bericht wordt ontvangen zal
een waarschuwing worden afgebeeld op de ATC-positie die
verantwoordelijk is voor de coördinatie van de vlucht.
8.3. RAP-bericht (Referred Activate Proposal)
8.3.1. Doel van het RAP-bericht
Het RAP-bericht voldoet aan de volgende operationele vereisten,
naastdie welke zijn gespecificeerd voor hetACT-berichtin para-
graaf 6.3:
— het voorstel van de overdragende vluchtleider en verwijzing
naar de accepterende vluchtleider van vluchten met niet-stan-
daard overdrachtsvoorwaarden;
— hetde overdragende vlucht leider mogelijk maken om, indien
hij/zij dit wenst, de verwijzing van standaard overdrachtsvoor-
waarden voor een specifieke vluchtnaar de accept erende
vluchtleider te forceren.
8.3.2. Inhoud van bericht
De inhoud van hetRAP-berichtzal best aan uitdezelfde gegevens
zoals beschreven voor hetACT-bericht(paragraaf 6.3) en kan
optioneel het volgende gegevenselement bevatten:
— reden, duidthandmat ige verwijzing aan (alleen beschikbaar in
ADEXP).
8.3.3. Regels voor toepassing
8.3.3.1. Algemeen
8.3.3.1.1. Voor vluchten die de grens overschrijden en aan een van de
volgende voorwaarden voldoen zal een RAP-berichtworden
verzonden in plaats van het ACT-bericht:
— het overdragende systeem heeft bepaald dat de overdrachts-
voorwaarden niet-standaard zijn;
— de overdragende vluchtleider heeft aangegeven dat de voorge-
stelde overdrachtsvoorwaarden dienen te worden verwezen
naar de accepterende vluchtleider.
8.3.3.1.2. De operat ionele inhoud van hetRAP-berichtdatop hetpuntst aat
om te worden verzonden zal worden afgebeeld op de werkplek2000R2082 — NL — 15.06.2002 — 001.001 — 45
▼B
die verantwoordelijk is voor de coördinatie van de vlucht vooraf-
gaand aan de feitelijke verzending.
8.3.3.1.3. Aanbeveling: Het tijdstip waarop het RAP-bericht automatisch
wordt verzonden dient samen met de inhoud ervan te worden
afgebeeld.
8.3.3.1.4. De betreffende werkplek zal op de hoogte worden gesteld van de
verzending van hetRAP-bericht .
8.3.3.2. Verwerking in de ontvangende eenheid
8.3.3.2.1. Het ATC-systeem dat een RAP-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
8.3.3.2.2. Als een bijbehorend vluchtplan wordt gevonden en geen afwij-
king in het bericht wordt geconstateerd die een correcte
verwerking zou verhinderen:
— zal de operationele inhoud worden verwezen naar de accepte-
rende vluchtleider;
— zal een SBY-berichtworden t eruggezonden.
8.3.3.2.3. Aanbeveling: Er dient een aanwijzing voor de reden van de
verwijzing (niet-standaard voorwaarden of handmatige verwij-
zing) te worden opgenomen.
8.3.3.2.4. Als hetberichtnietkan worden geassocieerd meteen vlucht plan
of als een afwijking wordt geconstateerd die een correcte verwer-
king van hetberichtverhindert , dan:
— zal de operationele inhoud van het bericht bij de sector
worden afgebeeld;
en
— zal een SBY-berichtworden t eruggezonden;
en
— zal een vluchtplan worden aangemaakt.
8.3.3.2.5. In alle andere gevallen zal hetberichtnietworden bevest igd.8.3.3.3. Handmatig starten
8.3.3.3.1. Als hetgebruiktwordtom de verwijzing van een voorgest elde
coördinatie met standaard overdrachtsvoorwaarden naar de accep-
terende vluchtleider te forceren, wordt het RAP-bericht
handmatig gestart door de overdragende vluchtleider en onmid-
dellijk verzonden.
8.3.3.3.2. Aanbeveling: Handmatig starten van een RAP-bericht voor het
berekende tijdstip van verzending dient te worden toegestaan op
de positie die verantwoordelijk is voor de coördinatie van de
vlucht.
8.3.3.4. Tijdparameters voor automatische verzending
De tijd/afstand voor de grens waarbij RAP-berichten automatisch
worden verzonden zal dezelfde zijn als voor de ACT-berichten.
8.3.4. Bevestiging van RAP-bericht
8.3.4.1. Bevestiging
Hetberichtzal worden bevest igd door hetgenereren en
verzenden van een SBY-bericht.
8.3.4.2. Gevallen zonder bevestiging
Als geen SBY-bericht wordt ontvangen ter bevestiging van een
RAP-berichtzal een waarschuwing worden afgebeeld op de
ATC-positie die verantwoordelijk is voor de coördinatie van de
vlucht.
8.3.5. Operationeel antwoord op RAP
De accepterende vluchtleider kan overdrachtsvoorwaarden naar
keuze accepteren, afwijzen of met een tegenvoorstel komen.
8.3.5.1. Acceptatie8.3.5.1.1. Als de accepterende vluchtleider ervoor kiest om de voorgestelde
overdrachtsvoorwaarden te accepteren zal een ACP-bericht
worden teruggezonden.
8.3.5.1.2. Zodra hetACP-berichtis ont vangen worden de gegevens van het
RAP-berichtoperat ioneel bindend voor beide ATC-eenheden. De2000R2082 — NL — 15.06.2002 — 001.001 — 46
▼B
gecoördineerde overdracht svoorwaarden en hetfeitdathetACP-
bericht is ontvangen zullen aan de overdragende vluchtleider
worden gepresenteerd.
8.3.5.2. Tegen voorstel
Als de accepterende vluchtleider ervoor kiest om een tegenvoor-
stel te doen met betrekking tot de overdrachtsvoorwaarden zal
een CDN-berichtworden t eruggezonden.
8.3.5.3. Aanbeveling: Als de accepterende vluchtleider ervoor kiest om
de voorgestelde overdrachtsvoorwaarden af te wijzen dient een
RJC-bericht te worden teruggezonden. In dat geval dient een
nieuwe coördinatieproces te worden gestart.
OPMERKING Met betrekking tot de aanbeveling in 8.3.5.3, zal
in de meeste gevallen de nieuwe coördinatie
plaatsvinden met een andere eenheid.
8.3.6. Voorbeelden
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. REV-bericht (Revision)
8.4.1. Doel van het REV-bericht
Hetdoel van hetREV-berichtst aatbeschreven in paragraaf 7.3.1.
In een dialoogprocedure wordthetREV-berichtgebruiktom aan
deze vereisten te voldoen, mits de overdrachtsvoorwaarden voor
de vlucht standaard zijn en de overdragende vluchtleider niet
vereist dat de vlucht naar de accepterende vluchtleider wordt
verwezen voor acceptatie.
8.4.2. Inhoud van bericht
De inhoud van hetREV-berichtzal zijn zoals beschreven voor
hetREV-berichtin paragraaf 7.3.2.
8.4.3. Regels voor toepassing
8.4.3.1. Algemeen
8.4.3.1.1. Door het gebruik van een Activate- of RAP-bericht kunnen een of
meer REV-berichten worden gezonden aan de eenheid waarvoor
op ditmomenteen vluchtis gecoördineerd.
8.4.3.1.2. REV-berichten zullen worden verzonden onder de voorwaarden
zoals gespecificeerd in paragraaf 7.3.3.1 voor vluchten met stan-
daard overdrachtsvoorwaarden waarvan de overdragende
vluchtleider niet vereist dat ze worden verwezen naar de accepte-
rende vluchtleider.
8.4.3.2. Verzending starten
HetREV-berichtzal onmiddellijk worden verzonden volgend op
de ontdekking van een wijziging in de coördinatiegegevens die
vereistzijn om t e worden gecoördineerd zoals beschreven in
paragraaf 7.3.3.
8.4.3.3. Verwerking in de ontvangende eenheid8.4.3.3.1. Als een bijbehorend vluchtplan is gevonden in de gecoördineerde
staat en geen afwijking is geconstateerd die een correcte verwer-
king van hetberichtzou verhinderen, dan:
— zal hetREV-berichtworden bevest igd;
— zal in alle andere gevallen hetberichtnietworden bevest igd.
8.4.3.3.2. De overdrachtsvoorwaarden zullen worden onderzocht om er
zeker van te zijn dat ze standaard zijn.
8.4.3.3.3. Als de overdrachtsvoorwaarden niet standaard zijn, zullen ze
worden gepresenteerd aan de accepterende vluchtleider.2000R2082 — NL — 15.06.2002 — 001.001 — 47
▼B
8.4.3.3.4. Als de voorgestelde overdrachtsvoorwaarden standaard blijken te
zijn, zullen ze waar van toepassing worden opgenomen in het
vluchtplan en in de vereiste gegevensuitvoer van operationele
ATC- en ander posities.
8.4.3.3.5. Aanbeveling: Als de overdrachtsvoorwaarden in een REV-bericht
niet standaard blijken te zijn, bestaat er een afwijking tussen de
filters in de twee systemen. Het feit dat het REV-bericht niet-stan-
daard is dient ter kennis van toezichthoudende medewerkers te
worden gebracht zodat de afwijking kan worden opgeheven.
8.4.4. Bevestiging van REV-bericht
8.4.4.1. Bevestiging8.4.4.1.1. Als het REV-bericht dient te worden bevestigd zal het worden
bevestigd door:
— een LAM-berichtals blijktdatde overdracht svoorwaarden
standaard zijn;
— een SBY-berichtals blijktdatde overdracht svoorwaarden
niet-standaard zijn.
8.4.4.1.2. Als een LAM-bericht is ontvangen wordt de operationele inhoud
van hetREV-berichtoperat ioneel bindend voor beide ATC-
eenheden.
8.4.4.1.3. Indien bilateraal overeengekomen kan een ACP-bericht worden
gebruikt in plaats van een LAM-bericht om de acceptatie door
de accepterende eenheid aan te geven van een REV-bericht dat
standaard overdrachtsvoorwaarden bevat.
8.4.4.2. Gevallen zonder bevestiging
Als voor een REV-bericht geen bevestiging wordt ontvangen zal
een waarschuwing worden afgebeeld op de ATC-positie die
verantwoordelijk is voor de coördinatie van de vluchten.
8.4.5. Operationeel antwoord op REV
Omdat het REV-bericht wordt gebruikt om standaard overdrachts-
voorwaarden te verzenden zal het normaal gesproken
geaccepteerd worden door het systeem in de accepterende
eenheid. Als de overdrachtsvoorwaarden door het filter in de
accepterende eenheid niet-standaard worden bevonden zal het
berichtworden verwerktals een RRV-bericht .
8.5. RRV-bericht (Referred Revision Proposal)
8.5.1. Doel van het RRV-bericht
In de volgende gevallen dienthetRRV-berichtvoor herziening
van eerder verzonden en overeengekomen overdrachtsvoor-
waarden:
— als de voorgestelde overdrachtsvoorwaarden in de herziening
niet-standaard zijn;
— als de voorgestelde herziening standaard is, maar de overdra-
gende vluchtleider de herziening naar de accepterende
vluchtleider wil verwijzen.
8.5.2. Inhoud van bericht
De inhoud van hetRRV-berichtzal zijn zoals beschreven voor
hetREV-bericht(paragraaf 7.3.2) en kan opt ioneel hetvolgende
gegevenselement bevatten:
— reden, duidthandmat ige verwijzing aan (alleen beschikbaar in
ADEXP-structuur).
8.5.3. Regels voor toepassing
8.5.3.1. Algemeen
Voor elke herziening zullen, in plaats van REV-berichten, een of
meer RRV-berichten worden verzonden, indien ofwel:
— het overdragende systeem heeft bepaald dat de overdrachts-
voorwaarden niet-standaard zijn;
of
— de overdragende vluchtleider heeft aangegeven dat de voorge-
stelde overdrachtsvoorwaarden dienen te worden verwezen
naar de accepterende vluchtleider. Dit gebruik van het RRV-
berichtis opt ioneel.2000R2082 — NL — 15.06.2002 — 001.001 — 48
▼B
8.5.3.2. Verzending starten
HetRRV-berichtzal onmiddellijk worden verzonden volgend op
de ontdekking van een wijziging in de coördinatiegegevens of bijeen handmatige start.
8.5.3.3. Verwerking in de ontvangende eenheid
8.5.3.3.1. Als een bijbehorend vluchtplan wordt gevonden in de gecoördi-
neerde staat en geen afwijking wordt geconstateerd die een
correcte verwerking van het bericht zou verhinderen, dan:
— zal hetRRV-berichtworden bevest igd;
— zal in alle andere gevallen hetberichtnietworden bevest igd.
8.5.3.3.2. De voorgestelde overdrachtsvoorwaarden zullen worden afge-
beeld op de ATC-positie die verantwoordelijk is voor de
coördinatie van de vlucht.
8.5.3.3.3. Aanbeveling: Er dient een indicatie van de reden voor de verwij-
zing (niet-standaard voorwaarden of handmatige verwijzing) te
worden meegezonden .
8.5.4. Bevestiging van RRV-bericht
8.5.4.1. Bevestiging
Hetberichtzal worden bevest igd door hetgeneren en verzenden
van een SBY-bericht.
8.5.4.2. Gevallen zonder bevestiging
Als geen SBY-bericht wordt ontvangen ter bevestiging van een
RRV-berichtzal een waarschuwing worden afgebeeld op de
ATC-positie die verantwoordelijk is voor de coördinatie van de
vlucht.
8.5.5. Operationeel antwoord op RRV
De accepterende vluchtleider kan een RRV-bericht naar keuze
accepteren, afwijzen of met een tegenvoorstel komen.
8.5.5.1. Acceptatie
Als de accepterende vluchtleider ervoor kiest om het voorgestelde
amendement op de overeengekomen overdrachtsvoorwaarden te
accepteren, zal een ACP-bericht worden teruggezonden.
8.5.5.2. Tegen voorstel
Als de accepterende vluchtleider ervoor kiest om met een tegen-
voorstel te komen voor de overdrachtsvoorwaarden, zal een
CDN-berichtworden t eruggezonden.
8.5.5.3. Afwijzing
Als de accepterende vluchtleider ervoor kiest om het voorgestelde
amendementop de overeengekomen overdracht svoorwaarden af
te wijzen:
— zal een RJC-berichtworden t eruggezonden;
en
— zal een nieuw coördinatieproces worden gestart.
Als noch een ACP-, noch een CDN-berichtwordtont vangen als
reactie op het RRV-bericht zal een afwijzing worden veronder-
steld.
8.5.6. Voorbeelden
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 EGBB2000R2082 — NL — 15.06.2002 — 001.001 — 49
▼B
8.6. SBY-bericht (Stand-by)
8.6.1. Doel van het SBY-bericht
Het SBY-bericht bevestigt de ontvangst van een bericht waarin
overdrachtsvoorwaarden worden voorgesteld en geeft aan dat het
voorstel wordt verwezen naar de vluchtleider voor een beslissing.
8.6.2. Inhoud van bericht
Het SBY-bericht zal de volgende gegevens bevatten:
— Berichttype;
— Berichtnummer;
— Berichtreferentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
8.6.3. Regels voor toepassing
8.6.3.1. Algemeen
Het SBY-bericht zal onmiddellijk automatisch worden gegene-
reerd en verzonden, in antwoord op:
— een RAP-, RRV- of CDN-bericht;
— een ACT- of REV-berichtdatnietaan hetfilt er voldoet .
8.6.4. Bevestiging van SBY-bericht
HetSBY-berichtzal nietworden bevest igd.
8.6.5. Voorbeelden
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. ACP-bericht (Acceptance)
8.7.1. Doel van het ACP-bericht
Het ACP-bericht voldoet aan de volgende operationele vereisten
tijdens de ATC coördinatie- en overdrachtsfasen:
— de handmatige acceptatie door een vluchtleider in de ene
eenheid aangeven van de overdrachtsvoorwaarden voorgesteld
door de vluchtleider in de andere eenheid in een van de
volgende berichten:
— RAP;
— RRV;
— CDN;— ACT en REV, als geconstateerd wordt dat onverschillig
welke van de twee niet-standaard is;
— indien bilateraal overeengekomen, voorzien in de automatisch
acceptatie van een ACT- of REV-bericht dat door het filter in
de accepterende eenheid is goedgekeurd (in plaats van het
LAM-bericht);
— indien bilateraal overeengekomen, de handmatige acceptatie
van een HOP-berichtaangeven (in plaat s van hetROF-
bericht).
8.7.2. Inhoud van bericht
HetACP-berichtbest aatuitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— berichtreferentie;
— Optionele gegevens — het bericht kan ook bevatten:
— frequentie;2000R2082 — NL — 15.06.2002 — 001.001 — 50
▼B
— Optionele gegevens voor berichten in ICAO-structuur — het
bericht kan tevens alle volgende onderdelen bevatten:
— vliegtuigidentificatie;
— luchthaven van vertrek;— luchthaven van bestemming.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
8.7.3. Regels voor toepassing
8.7.3.1. Algemeen
8.7.3.1.1. De berichtreferentie van het ACP-bericht zal het berichtnummer
bevatten van het bericht waarop het een antwoord is.
8.7.3.1.2. Het frequentieveld, indien aanwezig, zal de frequentie bevatten
waarop de vlucht contact dient op te nemen met de accepterende
eenheid als de overdracht plaatsvindt.
8.7.3.1.3. HetACP-berichtzal worden verzonden volgend op de handma-
tige acceptatie door de vluchtleider van voorgestelde
overdrachtsvoorwaarden, verzonden via een ACT-, RAP-, REV-,
RRV- of CDN-bericht.
8.7.3.1.4. Het ACP-bericht kan worden verzonden als een alternatief voor
een ROF-bericht in antwoord op een HOP-bericht.
8.7.3.1.5. Indien bilateraal overeengekomen zal het ACP-bericht automa-
tisch door het systeem worden gegenereerd en verzonden als
ant woord op een ACT/REV-berichtdatdoor hetfilt er is goedge-
keurd.
8.7.3.1.6. Als een ACP-berichtis ont vangen zullen de overeengekomen
overdrachtsvoorwaarden bindend zijn voor beide eenheden.
8.7.3.2. Verwerking in de ontvangende eenheid
8.7.3.2.1. Het ATC-systeem dat een ACP-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
8.7.3.2.2. Als hetACP-berichtkan worden geassocieerd meteen vlucht plan
zal de acceptatie aan de vluchtleider worden medegedeeld.
8.7.3.2.3. Als hetACP-berichtnietkan worden geassocieerd meteen
vluchtplan:
— zal een waarschuwing worden gegeven op de daartoe aange-
wezen positie; en
— zal geen LAM-berichtworden verzonden.
8.7.4. Bevestiging van ACP-bericht
8.7.4.1. Bevestiging8.7.4.1.1. Er zal geen LAM-berichtworden t eruggezonden als hetACP-
bericht is gebruikt als een automatisch antwoord op een ACT- of
REV-berichtdatdoor hetfilt er is goedgekeurd.
8.7.4.1.2. Een ACP-berichtdatis verzonden als een gevolg van een hand-
matige acceptatie zal worden bevestigd door het genereren en
verzenden van een LAM-bericht.
8.7.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht is ontvangen ter bevestiging van een ACP-
berichtdatis verzonden als gevolg van een handmat ige accep-
tatie, zal een waarschuwing worden afgebeeld op de ATC-positie
die verantwoordelijk is voor de coördinatie van de vlucht.
8.7.5. Voorbeelden
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 2421502000R2082 — NL — 15.06.2002 — 001.001 — 51
▼B
8.8. CDN-bericht (Co-ordination)
8.8.1. Doel van het CDN-bericht
Het CDN-bericht voldoet aan de volgende operationele vereisten:
— een tegenvoorstel van de accepterende vluchtleider verzenden
naar de overdragende vluchtleider als antwoord op een ACT-,
RAP-, REV- of RRV-bericht;
— een voorgestelde wijziging op overeengekomen overdrachts-
voorwaarden van de accepterende vluchtleider naar de
overdragende vluchtleider starten.
8.8.2. Inhoud van bericht
HetCDN-berichtbest aatuitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;
— berichtreferentie (alleen indien als antwoord op een ander
bericht);
— vliegtuigidentificatie;
— luchthaven van vertrek;
— luchthaven van bestemming;
OPMERKING Het bericht zal ook een van de volgende, of
beide, onderdelen bevatten:
— geschatte gegevens (bij een ICAO-bericht) of overdracht-
vluchtniveau (bij een ADEXP-bericht);
— directe routeaanvraag.
— Bilateraal overeengekomen gegevens — de volgende gege-
vens kunnen eveneens worden opgenomen, indien bilateraal
overeengekomen:
— frequentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
8.8.3. Regels voor toepassing
8.8.3.1. Algemeen8.8.3.1.1. CDN-berichten zullen alleen worden gestart door de accepterende
vluchtleider.
8.8.3.1.2. CDN-berichten zullen worden gebruikt om een tegenvoorstel te
verzenden van de accepterende vluchtleider naar de overdragende
vluchtleider.
OPMERKING Dit kan plaatsvinden in een dialoog als antwoord
op een voorstel verzonden door middel van een
ACT-, RAP-, REV- of RRV-bericht, of als de start
van een dialoog om eerder overeengekomen over-
drachtsvoorwaarden te amenderen.
8.8.3.1.3. De berichtreferentie zal alleen worden ingevoegd als het CDN-
bericht een antwoord is op een ander bericht.
8.8.3.1.4. Indien ingevoegd zal de berichtreferentie het berichtnummer
bevatten van het bericht waarop het CDN-bericht een antwoord
is.
8.8.3.1.5. De faciliteit voor Directe routeaanvraag (in detail beschreven in
Bijlage A) zal:
— alleen worden gebruiktindien bilat eraal overeengekomen; en
— indien overeengekomen, alle operationele beperkingen met
betrekking tot het gebruik ervan definiëren.
8.8.3.1.6. Het CDN-bericht zal niet worden verzonden na een tijd/afstand
voor de grens die is gespecificeerd in de LoA die tussen de
betreffende eenheden geldt.
8.8.3.1.7. In hetgeval dateen CDN-berichteffect ief gelijkt ijdig wordt
verzonden meteen berichtvoor dezelfde vluchtvan de overdra-
gende eenheid, bijvoorbeeld een herziening of een opheffing van
coördinatie, zal noch een bevestiging, noch een operationeel
antwoord worden teruggezonden.2000R2082 — NL — 15.06.2002 — 001.001 — 52
▼B
OPMERKING Het effect hiervan is dat als twee berichten elkaar
kruisen, het bericht van de overdragende eenheid
prioriteit krijgt en het CDN-bericht door beide
wordt genegeerd. Beide eenheden kunnen de situ-
atie aanvoelen door de ontvangst van het bericht
van de ander voordat de bevestiging wordt
ontvangen.
8.8.3.1.8. Zodra er een acceptatie is ontvangen worden de CDN-berichtge-
gevens operationeel bindend voor beide ATC-eenheden. De
gecoördineerde overdracht svoorwaarden en hetfeitdathetACP-
bericht is ontvangen zullen worden gepresenteerd aan de betref-
fende ATC-medewerkers.
8.8.3.2. Verwerking in de ontvangende eenheid8.8.3.2.1. Als een bijbehorend vluchtplan wordt gevonden en geen afwij-
king in het bericht wordt geconstateerd die een correcte
verwerking zou verhinderen:
— zal de operationele inhoud worden gepresenteerd op de ATC-
positie die verantwoordelijk is voor de coördinatie van de
vlucht;
en
— zal een SBY-berichtworden t eruggezonden.
8.8.3.2.2. Als hetCDN-berichtnietkan worden geassocieerd, of als een
afwijking wordt geconstateerd die een correcte verwerking van
het bericht verhindert, zal geen SBY-bericht worden terugge-
zonden.
8.8.4. Bevestiging van CDN-bericht
8.8.4.1. Bevestiging
Onder de hierboven gespecificeerde voorwaarden zal hetCDN-
berichtworden bevest igd door hetgenereren en verzenden van
een SBY-bericht.
8.8.4.2. Gevallen zonder bevestiging
Als geen SBY-bericht wordt ontvangen ter bevestiging van een
CDN-berichtzal een waarschuwing worden afgebeeld op de
ATC-positie die verantwoordelijk is voor de coördinatie van de
vlucht.
8.8.5. Operationeel antwoord op CDN
De vluchtleider kan de overdrachtsvoorwaarden die in een CDN-
bericht worden voorgesteld accepteren of afwijzen.
8.8.5.1. Acceptatie
Als de overdragende vluchtleider ervoor kiest om de voorgestelde
overdrachtsvoorwaarden te accepteren zal een ACP-bericht
worden teruggestuurd.
8.8.5.2. Aanbeveling: Als de overdragende vluchtleider ervoor kiest om
de voorgestelde overdrachtsvoorwaarden af te wijzen dient een
RJC-bericht te worden gezonden (expliciete afwijzing).
OPMERKING De voorgestelde coördinatie wordt impliciet afge-
wezen als geen acceptatie is ontvangen tegen de
tijd dat de time-out voor het CDN-bericht is
verstreken.
8.8.6. Voorbeelden
8.8.6.1. ICAO
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A2000R2082 — NL — 15.06.2002 — 001.001 — 53
▼B
8.9. RJC-bericht (Reject Co-ordination)
8.9.1. Doel van het RJC-bericht
HetRJC-berichtgeeftde afwijzing aan door een vlucht leider van
de ene eenheid van de overdrachtsvoorwaarden voorgesteld door
de vluchtleider van de andere eenheid in een van de volgende
berichten:
— RAP;
— RRV;
— CDN;— Intentionally Blank ACT en REV, als geconstateerd wordt dat
onverschillig welke van de twee niet-standaard is.
HetRJC-berichtkan alleen worden gebruiktals een direct
antwoord op een van de bovengenoemde berichten.
8.9.2. Inhoud van bericht
Het RJC-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;
— berichtreferentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
8.9.3. Regels voor toepassing
8.9.3.1. Algemeen
8.9.3.1.1. HetRJC-berichtzal waar vereistworden verzonden als ant woord
op een RAP-, RRV-, CDN-berichtof op een ACT- of REV-
bericht dat door de accepterende eenheid niet-standaard is
bevonden.
8.9.3.1.2. HetRJC-berichtbeëindigtde syst eemdialoog en alle eerder over-
eengekomen coördinatie blijft geldig.
8.9.3.1.3. Aanbeveling: Volgend op de ontvangst van een RJC-bericht
dient een nieuwe coördinatiereeks te worden gestart, die waar
van toepassing de telefonische coördinatie aangeeft.
8.9.3.2. Verwerking in de ontvangende eenheid
8.9.3.2.1. Als een bijbehorend berichtwordtaanget roffen waarnaar het
RJC-berichtverwijst ;
— zal de afwijzing worden aangegeven op de ATC-positie die
verantwoordelijk is voor de coördinatie van de betreffende
vlucht; en
— zal ter bevestiging een LAM-bericht worden teruggezonden.
8.9.3.2.2. Als er geen dergelijk bericht wordt aangetroffen dat op antwoord
wacht, of als er een afwijking bestaat in het bericht die verwer-
king verhindert, dan zal er geen bevestiging worden
teruggestuurd.
8.9.4. Bevestiging van RJC-bericht
8.9.4.1. Bevestiging
HetRJC-berichtzal worden bevest igd door hetgenereren en
verzenden van een LAM-bericht.
8.9.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht is ontvangen ter bevestiging van een RJC-
bericht, zal een waarschuwing worden afgebeeld op de ATC-
positie die verantwoordelijk is voor de coördinatie van de
vluchten.
8.9.5. Voorbeelden
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 — NL — 15.06.2002 — 001.001 — 54
▼B
9. DIALOOG PROCEDURE — OVERDRACHT VAN
COMMUNICATIE
9.1. Algemeen
9.1.1. Inleiding
9.1.1.1. In dit gedeelte van de norm worden de faciliteiten en berichten
beschreven die hetaspectvan de radaroverdrachtvan de cont ro-
leprocedureoverdracht ondersteunen. Deze zullen waar bilateraal
overeengekomen worden geïmplementeerd.
9.1.1.2. Faciliteiten voor communicatieoverdracht zullen niet worden
geïmplementeerd tenzij de eenheid gebruik maakt van ofwel de
coördinatiefaciliteiten beschreven in Sectie 6 (Basisprocedure —
Verplichte berichten) of die in Sectie 8 (Dialoogprocedure —
Coördinatie).
9.1.1.3. De in dit gedeelte van het document beschreven berichten zijn
alleen beschikbaar in ADEXP-structuur en er bestaan geen
plannen om ze in ICAO-structuur beschikbaar te stellen.
9.1.2. Berichtenvolgorde
9.1.2.1. Uitwisseling van communicatieoverdrachtsberichten, anders dan
het SDM-bericht (Supplementary Data Message), zal niet plaats-
vinden tenzij de coördinatie is voltooid, d.w.z. een ACT- of RAP-
dialoog is voltooid door een LAM- of ACP-bericht.
9.1.2.2. Er zal geen bevestiging worden teruggezonden als er nog sprake
is van openstaande coördinatie.
9.1.3. Overdracht van communicatie
9.1.3.1. De methode voor de aanduiding van de feitelijke verandering van
communicatie van vluchten zal tussen de twee betreffende
eenheden bilateraal worden overeengekomen.
9.1.3.2. De voorwaarden zullen een of beide van de volgende zijn:
— de overdragende eenheid zendteen COF-bericht(Change Of
Frequency);
— de accepterende eenheid zendt een MAS-bericht (Manual
Assumption of Communication);
9.1.3.3. De methode zal tussen de twee eenheden worden overeenge-
komen voor elke verkeersstroom.
OPMERKING Voor verschillende stromen mogen alternatieve
methoden worden gebruikt, zo kan bijvoorbeeld
een eenheid COF-berichten genereren voor
vluchten die haar luchtruim verlaten en MAS-
berichten voor vluchten die haar luchtruim
binnenkomen. In een dergelijk geval zou het voor
de andere eenheid niet nodig zijn om berichten in
te voeren ter aanduiding van overdracht van
communicatie.
9.2. TIM-bericht (Transfer Initiation Message)
9.2.1. Doel van het TIM-bericht
Hetdoel van hetTIM-berichtis om:
— het TI-event (Transfer Initiation) aan te geven (het einde van
de coördinatiefase en de start van de overdrachtsfase);
— gelijktijdig uitvoerende controlegegevens te verzenden van de
overdragende naar de accepterende eenheid.
9.2.2. Inhoud van bericht
HetTIM-berichtzal best aan uitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;
— Beschikbare gegevens — hetberichtzal ook, indien beschik-
baar, een of meer van de volgende onderdelen bevatten:
— vrijgegeven vluchtniveau;
— toegewezen koers of Directe vrijgave;2000R2082 — NL — 15.06.2002 — 001.001 — 55
▼B
— toegewezen snelheid;
— toegewezen klim-/daalsnelheid;
— Optionele gegevens — het bericht kan ook bevatten:
— positie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.2.3. Regels voor toepassing
9.2.3.1. Algemeen9.2.3.1.1. HetTIM-berichtzal worden gegenereerd en verzonden door de
overdragende eenheid aan de accepterende eenheid zonder
menselijke tussenkomst op een bilateraal overeengekomen tijd-
stip/afstand van de vlucht tot de grens.
9.2.3.1.2. Een TIM-bericht zal ook automatisch worden verzonden als het
ROF-bericht(RequestOn Frequency) door de overdragende
eenheid is ontvangen.
9.2.3.1.3. Er zal geen TIM-berichtworden verzonden voordatde vluchtis
gecoördineerd.
9.2.3.1.4. Het TIM-bericht zal de meest recente in het systeem beschikbare
gegevens bevatten.
9.2.3.2. Tijdparameters voor verzending9.2.3.2.1. De parameter voor het genereren van TIM-berichten zal een Vari-
abele systeemparameter zijn die kan worden gewijzigd op basis
van de voorwaarden van de LoA's.
9.2.3.2.2. Aanbeveling: De systeemparameter voor het genereren van TIM-
berichten dient voor elk van de COP's afzonderlijk te worden
gedefinieerd.
9.2.3.2.3. De coördinatiepartners zullen de parameters voor het genereren
van TIM-berichten opnemen in hun LoA.
9.2.3.2.4. De systeemparameter die het TIM-bericht start kan zijn gerela-
teerd aan de berekende grondsnelheid van het vliegtuig. Het
starten van een TIM-bericht zal echter altijd beginnen voordat
de huidige vluchtplanpositie zich dichter bij het COP bevindt
dan een minimum bilateraal gespecificeerde afstand.
9.2.3.2.5. De gespecificeerde systeemparameter voor het verzenden van
TIM-berichten zal voldoende tijd laten voor verbale coördinatie
voorafgaand aan de overdracht.
9.2.3.3. Verwerking in de ontvangende eenheid9.2.3.3.1. De gegevens die in een TIM-berichtworden ont vangen zullen
beschikbaar worden gesteld aan de accepterende vluchtleider.
9.2.4. Bevestiging van TIM-bericht
9.2.4.1. Bevestiging
Als hetTIM-bericht :
— ondubbelzinnig meteen vlucht plan kan worden geassocieerd
zal hetworden bevest igd door hetgenereren en verzenden
van een LAM-bericht;
— nietondubbelzinnig meteen vlucht plan kan worden geassoci-
eerd zal geen bevestiging worden verzonden.
9.2.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
TIM-bericht zal op de daartoe aangewezen positie een waarschu-
wing worden afgebeeld.
9.2.5. Voorbeeld
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM2532000R2082 — NL — 15.06.2002 — 001.001 — 56
▼B
9.3. SDM-bericht (Supplementary Data Message)
9.3.1. Doel van het SDM-bericht
9.3.1.1. Algemeen
9.3.1.1.1. Hetprimaire doel van hetSDM-berichtis om cont rolegegevens
en wijzigingen daarop te verzenden van de overdragende eenheid
naar de accepterende eenheid, mits bilateraal is overeengekomen
dat de wijzigingen niet hoeven te worden bevestigd door de
accepterende vluchtleider.
9.3.1.1.2. HetSDM-berichtkan ook worden gebruiktdoor de accept erende
eenheid om de overdragende eenheid in kennis te stellen van de
radiotelefoniefrequentie waaraan de vlucht zal worden overge-
dragen.
9.3.2. Inhoud van bericht
9.3.2.1. Berichten van de overdragende eenheid
HetSDM-berichtzal best aan uitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;
— Aanvullende gegevens — hetberichtzal ook een of meer van
de volgende onderdelen bevatten:
— toegewezen koers of Directe vrijgave;
— toegewezen snelheid;— toegewezen klim-/daalsnelheid;
— vrijgegeven vluchtniveau.
9.3.2.2. Berichten van de accepterende eenheid
Het SDM-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;— frequentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.3.3. Regels voor toepassing
9.3.3.1. Berichten van de overdragende eenheid
9.3.3.1.1. SDM-berichten zullen worden verzonden na het starten van de
overdrachtsfase (zie TIM, paragraaf 9.2) volgend op elke wijzi-
ging in de volgende onderdelen:
— vrijgegeven vluchtniveau;
— toegewezen snelheid;
— toegewezen klim-/daalsnelheid;
— toegewezen koers; of— afgifte of wijzing van een vrijgave voor de vlucht om direct
naar een gespecificeerd puntt e gaan.
OPMERKING Het HOP-bericht is vereist als goedkeuring door
de accepterende vluchtleider is vereist vooraf-
gaand aan de overdracht van de communicatie.
9.3.3.1.2. Het bericht zal alleen de velden bevatten die zijn gewijzigd.
9.3.3.1.3. SDM-berichten die de gegevens bevatten zoals beschreven in
9.3.3.1.1 zullen worden verzonden voorafgaand aan TI, indien
bilateraal overeengekomen.
9.3.3.1.4. Dergelijke berichten zullen beginnen op een bilateraal overeenge-
komen tijdstip relatief ten opzichte van TI, mits er gegevens zijn
waarvoor een waarde in hetsyst eem beschikbaar is.
9.3.3.2. Berichten van de accepterende eenheid
9.3.3.2.1. SDM-berichten kunnen worden verzonden om de frequentie aan
te geven waarop de vlucht contact dient op te nemen met de
accepterende eenheid.2000R2082 — NL — 15.06.2002 — 001.001 — 57
▼B
OPMERKING Eenheden kunnen bilateraal overeenkomen om
andere informatie te zenden. Een dergelijke over-
dracht is niet gedefinieerd in, en daarom geen
onderdeel van, deze norm.
9.3.3.2.2. Indien bilateraal overeengekomen zullen SDM-berichten van de
accepterende eenheid worden verzonden tijdens de coördinatie-
fase.
9.3.3.3. Verwerking in de ontvangende eenheid
9.3.3.3.1. Het ATC-systeem dat een SDM-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
9.3.3.3.2. Als een bijbehorend vluchtplan in de gecoördineerde fase wordt
gevonden:
— zal een LAM-berichtworden t eruggezonden; en
— zal de operationele inhoud van het SDM-bericht beschikbaar
worden gemaaktvoor de daarvoor in aanmerking komende
vluchtleider.
9.3.3.3.3. Als geen bijbehorend vluchtplan kan worden gevonden, of als een
afwijking wordt geconstateerd die een correcte verwerking van
hetberichtverhindert :
— zal geen LAM-berichtworden t eruggezonden; en
— zal een waarschuwing worden gegeven op een daartoe aange-
wezen positie.
9.3.4. Bevestiging van SDM-bericht
9.3.4.1. Bevestiging
HetSDM-berichtzal worden bevest igd door hetgenereren en
verzenden van een LAM-bericht.
9.3.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
SDM-bericht zal op een daartoe aangewezen positie een waar-
schuwing worden afgebeeld.
9.3.5. Voorbeeld
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4. Hand-Over Proposal (HOP)
9.4.1. Doel van het HOP-bericht
Hetdoel van hetHOP-berichtis:
— voor de overdragende vluchtleider om de aandacht van de
accepterende vluchtleider te richten op een specifieke vlucht
ten behoeve van een overdracht;
— voor de overdragende vluchtleider om de vlucht ter over-
dracht voor te dragen aan de accepterende vluchtleider op
hetmomentdatditnodig is;
— om wijzigingen naar de uitvoerende controlegegevens te
zenden die de goedkeuring van de accepterende vluchtleider
vereisen, zoals bilateraal overeengekomen.
Het is niet nodig om het HOP-bericht voor alle vluchten te
gebruiken; hetgebruik wordtbepaald door de overdragende
vluchtleider.
OPMERKING Met betrekking tot paragraaf c) hierboven wordt
het SDM-bericht gebruikt om wijzingen naar
uitvoerende controlegegevens te zenden die geen
goedkeuring van de accepterende vluchtleider
behoeven.
9.4.2. Inhoud van bericht
HetHOP-berichtzal best aan uitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;2000R2082 — NL — 15.06.2002 — 001.001 — 58
▼B
— Beschikbare gegevens — hetberichtzal ook een of meer van
de volgende onderdelen bevatten, indien beschikbaar:
— vrijgegeven vluchtniveau;
— toegewezen koers/Directe vrijgave;— toegewezen snelheid;— toegewezen klim-/daalsnelheid;
— Optionele gegevens — het bericht kan ook bevatten:
— positie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.4.3. Regels voor toepassing
9.4.3.1. Algemeen9.4.3.1.1. Het HOP-bericht zal, indien gebruikt, handmatig worden gestart
door de overdragende vluchtleider.
9.4.3.1.2. Hetberichtzal alle hierboven in paragraaf 9.4.2. beschreven
vluchtgegevens bevatten die sinds de eerder verzonden gegevens
zijn gewijzigd.
9.4.3.1.3. Als een HOP-berichtwordtverzonden voorafgaand aan TI zal de
overdrachtsfase worden gestart.
OPMERKING Een TIM-bericht (Transfer Initiation Message) is
niet vereist als aanvulling op het HOP-bericht.
9.4.3.1.4. Het vroegste tijdstip of de vroegste afstand voor het COP of de
grens waarbij een HOP-berichtkan worden gezonden zal bilat e-
raal worden overeengekomen.
9.4.3.1.5. Aanbeveling: Tijdstip/afstand dient voor elke COP afzonderlijk
te worden gespecificeerd.
9.4.3.2. Verwerking in de ontvangende eenheid9.4.3.2.1. Het ATC-systeem dat een HOP-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
9.4.3.2.2. De in het bericht ontvangen vluchtgegevens zullen onmiddellijk
zichtbaar worden gemaakt voor de accepterende vluchtleider.
9.4.3.2.3. Als de accepterende vluchtleider de vlucht accepteert op de voor-
waarden zoals voorgesteld in het HOP-bericht, kan als antwoord
een ROF-berichtnaar de overdragende eenheid worden
verzonden. Indien bilateraal overeengekomen kan als antwoord
op een HOP-berichteen ACP-berichtworden verzonden.
9.4.3.2.4. Als de accepterende vluchtleider niet in staat is om de vlucht te
accepteren zal de overdracht verbaal worden overeengekomen.
OPMERKING Als gevolg van de dringende aard van de over-
drachtsprocedure vereist deze norm geen
systeemondersteuning voor het bewaken van het
terugzenden van het ROF-bericht (of ACP-
bericht); aangenomen wordt dat de overdragende
vluchtleider zich goed bewust zal zijn van de
afwezigheid van een antwoord van de accepte-
rende vluchtleider en de benodigde actie zal
ondernemen. Deze norm verbiedt echter niet dat
een waarschuwing wordt verzonden naar de over-
dragende vluchtleider als dit operationeel
noodzakelijk wordt geacht.
9.4.3.2.5. Zodra een ROF-bericht (of een ACP-bericht) is ontvangen zullen
de gegevens in hetHOP-berichtoperat ioneel bindend worden
voor beide ATC-eenheden.
9.4.4. Bevestiging van HOP-bericht
9.4.4.1. Bevestiging
Als hetHOP-berichtkan worden geassocieerd meteen vlucht plan
zal het HOP-bericht automatisch worden bevestigd door een
LAM-bericht.2000R2082 — NL — 15.06.2002 — 001.001 — 59
▼B
9.4.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
HOP-bericht zal op de daartoe aangewezen positie een waarschu-
wing worden afgebeeld.
9.4.5. Voorbeeld
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ
9.5. ROF-bericht (Request on Frequency)
9.5.1. Doel van het ROF-bericht
Het ROF-bericht wordt, indien vereist, door de accepterende
eenheid naar de overdragende eenheid verzonden, waarbij de
overdragende vluchtleider wordt gevraagd om het vliegtuig te
instrueren om naar de frequentie van de accepterende vluchtleider
te schakelen. Het bericht kan worden gebruikt:
— als antwoord op een HOP-bericht om de acceptatie van de
vlucht onder de voorgestelde voorwaarden aan te geven;
— om de eerdere overdrachtvan de vluchtt e vragen.
9.5.2. Inhoud van bericht
HetROF-berichtzal best aan uitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;
— Optionele gegevens — het bericht kan ook bevatten:
— frequentie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.5.3. Regels voor toepassing
9.5.3.1. Algemeen9.5.3.1.1. Het ROF-bericht zal handmatig worden gestart door de accepte-
rende vluchtleider.
9.5.3.1.2. De accepterende vluchtleider kan een ROF-bericht starten, ofwel:
— als de accepterende vluchtleider het vliegtuig in een vroeg
stadium op zijn/haar frequentie wil hebben; of
— als een antwoord op een HOP-bericht.
9.5.3.2. Verwerking in de ontvangende eenheid
9.5.3.2.1. Het ATC-systeem dat een ROF-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
9.5.3.2.2. De ontvangst van het ROF-bericht zal onverwijld worden mede-
gedeeld aan de overdragende vluchtleider.
9.5.3.2.3. Als de vluchtzich nietin de overdracht sfase bevindtzal de over-
drachtsfase worden gestart en zal een TIM-bericht worden
verzonden.
9.5.4. Bevestiging van ROF-bericht
9.5.4.1. Bevestiging9.5.4.1.1. Als hetROF-berichtondubbelzinnig kan worden geassocieerd
met een vluchtplan zal het worden bevestigd door het genereren
en verzenden van een LAM-bericht.
9.5.4.1.2. Als hetROF-berichtnietondubbelzinnig kan worden geassoci-
eerd met een vluchtplan zal geen bevestiging worden verzonden.
9.5.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
ROF-berichtzal een waarschuwing worden afgebeeld op de
daartoe aangewezen ATC-positie.2000R2082 — NL — 15.06.2002 — 001.001 — 60
▼B
9.5.5. Voorbeeld
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6. COF-bericht (Change of Frequency)
9.6.1. Doel van het COF-bericht
9.6.1.1. Algemeen
9.6.1.1.1. HetCOF-berichtwordtdoor de overdragende eenheid aan de
accepterende eenheid gezonden om aan te geven dat de vlucht
geïnstrueerd is om contact op te nemen met de accepterende
vluchtleider.
9.6.1.1.2. Het bericht kan voor de overdragende vluchtleider de faciliteit
bevatten om de vlucht te ontheffen van de overeengekomen over-
drachtsvoorwaarden nadat de vlucht radiocontact heeft gemaakt
met de accepterende vluchtleider.
9.6.2. Inhoud van bericht
HetCOF-berichtzal best aan uitde volgende gegevens:
— Verplichte gegevens — het bericht zal bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie;
— Beschikbare gegevens — hetberichtzal ook, indien beschik-
baar, een of meer van de volgende onderdelen bevatten:
— vrijgave-indicatie;
— frequentie;— vrijgegeven vluchtniveau;— toegewezen koers of Directe vrijgave;— toegewezen snelheid;— toegewezen klim-/daalsnelheid;
— Optionele gegevens — het bericht kan ook bevatten:
— positie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.6.3. Regels voor toepassing
9.6.3.1. Algemeen9.6.3.1.1. Het COF-bericht zal handmatig worden gestart door de overdra-
gende vluchtleider.
9.6.3.1.2. Hetgebruik van hetCOF-berichtis verplichtals, volgens bilat e-
rale overeenkomst, het MAS-bericht niet wordt gebruikt.
9.6.3.1.3. Als een COF-berichtwordtverzonden voorafgaand aan TI, zal de
overdrachtsfase worden gestart.
OPMERKING Een TIM-bericht (Transfer Initiation Message) is
niet vereist als aanvulling op het COF-bericht.
9.6.3.2. Verwerking in de ontvangende eenheid9.6.3.2.1. Het ATC-systeem dat een COF-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
9.6.3.2.2. De ontvangst van het COF-bericht zal onverwijld aan de accepte-
rende vluchtleider worden medegedeeld.
9.6.4. Bevestiging van COF-bericht
9.6.4.1. Bevestiging
9.6.4.1.1. Als hetCOF-berichtondubbelzinnig kan worden geassocieerd
met een vluchtplan zal het worden bevestigd door het genereren
en verzenden van een LAM-bericht.
9.6.4.1.2. Als hetCOF-berichtnietondubbelzinnig kan worden geassoci-
eerd met een vluchtplan zal geen bevestiging worden verzonden.2000R2082 — NL — 15.06.2002 — 001.001 — 61
▼B
9.6.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
COF-berichtzal een waarschuwing worden afgebeeld op de
daartoe aangewezen ATC-positie.
9.6.5. Voorbeelden
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7. MAS-bericht (Manual Assumption of Communications)
9.7.1. Doel van het MAS-bericht
HetMAS-berichtwordtdoor de accept erende eenheid aan de
overdragende eenheid verzonden om aan te geven dat tweeweg-
radiocontact met de vlucht tot stand is gebracht.
9.7.2. Inhoud van bericht
Het MAS-bericht zal de volgende gegevens bevatten:
— berichttype;
— berichtnummer;— vliegtuigidentificatie.
OPMERKING Regels voor invoegen van gegevens, structuren en
inhoud van velden worden gespecificeerd in
Bijlage A.
9.7.3. Regels voor toepassing
9.7.3.1. Algemeen
9.7.3.1.1. Het MAS-bericht zal handmatig worden gestart door de accepte-
rende vluchtleider.
9.7.3.1.2. Hetgebruik van hetMAS-berichtis verplichtals, door bilat erale
overeenkomst, het COF-bericht niet wordt gebruikt.
9.7.3.2. Verwerking in de ontvangende eenheid
9.7.3.2.1. Het ATC-systeem dat een MAS-bericht ontvangt zal proberen dit
te associëren met het bijbehorende vluchtplan.
9.7.3.2.2. HetfeitdathetMAS-berichtis ont vangen zal onmiddellijk t er
kennis worden gebrachtvan de vlucht leider.
9.7.4. Bevestiging van MAS-bericht
9.7.4.1. Bevestiging
9.7.4.1.1. Als hetMAS-berichtondubbelzinnig kan worden geassocieerd
met een vluchtplan zal het worden bevestigd door het genereren
en verzenden van een LAM-bericht.
9.7.4.1.2. Als hetMAS-berichtnietondubbelzinnig kan worden geassoci-
eerd met een vluchtplan zal geen bevestiging worden verzonden.
9.7.4.2. Gevallen zonder bevestiging
Als geen LAM-bericht wordt ontvangen ter bevestiging van een
MAS-berichtzal, zoals vereist , een waarschuwing worden afge-
beeld op de daartoe aangewezen ATC-positie.
9.7.5. Voorbeeld
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — NL — 15.06.2002 — 001.001 — 62
▼B
BIJLAGE A (Normatief)
REGELS VOOR HET INVOEGEN VAN GEGEVENS
INHOUD
A.1. Doel
A.2. Algemene berichtenstructurenA.3. Berichttype
A.4. Berichtnummer
A.5. BerichtreferentieA.6. Vliegtuigidentificatie
A.7. SSR-modus en -code
A.8. Luchthaven van vertrekA.9. Geschatte gegevens
A.10. Coördinatiepunt
A.11. Luchthaven van bestemmingA.12. Vliegtuignummer en -type
A.13. Route
A.14. Overige vluchtplangegevensA.15. Coördinatiestatus en -reden
A.16. Toegewezen koers (alleen ADEXP)
A.17. Toegewezen snelheid (alleen ADEXP)A.18. Toegewezen klim-/daalsnelheid (alleen ADEXP)
A.19. Directe vrijgave (alleen ADEXP)
A.20. Directe routeaanvraagA.21. Positie (alleen ADEXP)
A.22. Vrijgave-indicatie (alleen ADEXP)
A.23. FrequentieA.24. Reden (alleen ADEXP)
A.25. Vrijgegeven vluchtniveau (alleen ADEXP)
A.26. Overdrachtvluchtniveau (alleen ADEXP)A.27. Geschatte vertrektijd
A.28. Type verwijzingsbericht
A.29. Vluchttype
A.30. Capaciteit en status van de apparatuur
A.1. Doel
Deze bijlage bevateen beschrijving van de algemene regels voor
hetinvoegen van gegevens in de bericht en die in deze norm worden
beschreven. Deze regels gelden voor alle berichten behalve als
andere alternatieven of uitzonderingen op deze regels specifiek
staan vermeld in de Regels voor toepassing voor een specifiek
bericht.
A.2. Algemene berichtenstructuren
A.2.1. Alle berichten die in de volgende gedeelten worden beschreven
kunnen worden verzonden met behulp van het ICAO-structuur:
6 Basisprocedure — Verplichte berichten;
7 Basisprocedure — Complementaire berichten;8 Dialoogprocedure — Coördinatie.2000R2082 — NL — 15.06.2002 — 001.001 — 63
▼M1
▼B
▼B
A.2.2. De veldstructuren voor ICAO-berichten worden gespecificeerd in
de Procedures for Air Navigation Services — Rules of the Air and
Air Traffic Control (Document 4444). In de berichten waarin deze
voorkomen zullen de volgende ICAO-veldtypen voorafgaand aan
alle andere Veldtypen worden verzonden in de volgorde: 3, 7, 13,
14 en 16. Aangezien ze in Veldtype 22-structuur zijn is de volgorde
van andere ICAO-veldtypen niet belangrijk, anders dan dat ze niet
voor de hierboven genoemde Veldtypen komen.
A.2.2 bis. In bepaalde omstandigheden, wanneer geen geschikt ICAO-veld-
type bestaat, wordt een pseudo-ICAO-veldtypenummer gebruikt.
Dergelijke nummers zijn een uit twee cijfers bestaand getal, gelijk
aan of groter dan 80.
A.2.3. Alle in ditdocumentbeschreven bericht en kunnen worden
verzonden met gebruik van het Eurocontrol ADEXP-structuur.
Inhoud, structuur en gebruik van ADEXP-gegevensvelden zal
plaatsvinden overeenkomstig Referentie 2.
OPMERKINGEN1.Alleen de primaire ADEXP-gegevensvelden staan vermeld in
deze bijlage, behalve waar geassocieerde Subvelden specifiek
commentaar vereisen. De ADEXP-norm bevat een opsomming
van alle optionele en verplichte Subvelden die vereist zijn in elk
primair veld.
2.De berichten die worden beschreven in Sectie 9, Dialoogproce-
dure — Overdracht van communicatie, zijn alleen beschreven in
ADEXP-structuur.
A.3. Berichttype
Het berichttype zal de afkorting van het bericht zijn zoals
beschreven in de volgende lijst:
ABI: Advance Boundary Information [voorafgaand bericht met
grensinformatie].
ACP: Acceptance [accepteren].
ACT : Activate [activeren].
CDN : Co-ordination [coördinatie].
COD : SSR Code Assignment[SSR-codet oewijzing].
COF : Change of Frequency [wijziging van frequentie].
HOP : Hand-Over Proposal [overdrachtsvoorstel].
INF: Information [informatie].
LAM : Logical AcknowledgementMessage [logisch bevest igings-
bericht].
MAC : Message for Abrogation of Co-ordination [bericht voor
opheffing van coördinatie].
MAS : Manual Assumption of Communications [handmatige
overname van communicatie]
PAC: Preliminary Activation [voorlopige activering].
RAP: Referred Activate Proposal [voorstel tot activering waar-
naar wordtverwezen].
REV : Revision [herziening].
RJC: Reject Co-ordination [afwijzing van coördinatie].
ROF : Requeston Frequency [vraag over frequent ie].
RRV : Referred Revision Proposal [ voorstel tot herziening waar-
naar wordtverwezen].
SBY: Stand-by.
SDM : Supplementary Data Message [aanvullend gegevensbe-
richt].
TIM: Transfer Initiation Message [bericht van start van over-
dracht].
A.3.1. ICAO
Veldtype 3, element (a).2000R2082 — NL — 15.06.2002 — 001.001 — 64
▼M1
▼B
▼B
A.3.2. ADEXP
Primair veld „title”.
A.4. Berichtnummer
Tot de berichtnummergegevens behoren de identificaties die zijn
toegewezen aan de verzendende en ontvangende eenheden en het
berichtvolgordenummer. Het berichtvolgordenummer telt op van
001 tot 000 (aanduiding voor 1000) en wordt dan herhaald vanaf
001 voor alle berichten die aan dezelfde geadresseerde worden
gezonden, ongeacht het type bericht.
A.4.1. ICAO
Veldtype 3, element (b).
A.4.2. ADEXP
Primair veld „refdata”.
Subveld „fac”, binnen de Subvelden „sender” en „recvr”, zal de
identificaties bevatten die aan de ATC-eenheden zijn toegewezen.
Deze identificaties zullen niet langer zijn dan acht tekens.
Subveld „seqnum” zal het volgordenummer bevatten.
A.5. Berichtreferentie
A.5.1. ICAO
Veldtype 3, element (c) (genaamd 'reference data' in ICAO docu-
ment4444).
De inhoud van element(c) zal zijn die van Veldt ype 3, element(b),
van hetOLDI-berichtwaarnaar wordtverwezen.
A.5.2. ADEXP
Primair field „msgref”.
De waarden van de Subvelden „sender”, „recvr”, en „seqnum”,
binnen hetPrimaire veld „msgref”, zullen zijn die van dezelfde
Subvelden binnen hetPrimaire veld „refdat a” van hetOLDI-bericht
waarnaar wordtverwezen.
A.6. Vliegtuigidentificatie
A.6.1. ICAO
Veldtype 7, element (a).
A.6.2. ADEXP
Primair veld „arcid”.
A.7. SSR-modus en -code
Ofwel:1. indien bekend, de SSR-modus/code waarop de ontvangende
eenheid kan verwachten dat het vliegtuig antwoordt op het
controleoverdrachtspunt;
of
2. een indicator dat de SSR-code wordt aangevraagd bij de ontvan-
gende eenheid.
A.7.1. ICAO
Veldtype 7, elementen (b) en (c).Als geen SSR-code is toegewezen of de modus/code niet bekend is,
zullen de elementen (b) en (c) worden weggelaten.
Bij hetaanvragen van een SSR-code/modus, zullen de element en b)
en c) de waarde „A9999” bevatten.2000R2082 — NL — 15.06.2002 — 001.001 — 65
▼B
A.7.2. ADEXP
Primair veld „ssrcode”.
Als geen geldige SSR-code is toegewezen of als de modus/code
nietbekend is, zal hetveld worden weggelat en.
Bij hetaanvragen van een SSR-code/modus via hetPAC-berichtzal
het primaire veld „ssrcode” de indicator „REQ” bevatten.
A.8. Luchthaven van vertrek
A.8.1. ICAO
Veldtype 13, element (a).
A.8.2. ADEXP
Primair veld „adep”.
A.9. Geschatte gegevens
A.9.1. Algemeen
A.9.1.1. Tot de geschatte gegevens zullen behoren het COP, het tijdstip bij
hetCOP en hetoverdracht sniveau.
A.9.1.2. Hetcoördinat iepuntzal worden gedefinieerd als ofwel een bekend
referentiepunt, een afstand en koers vanaf een bekend referentiepunt
of een breedte- en lengtegraad.
A.9.1.3. Hetvrijgegeven (overdracht )niveau zal overeenkomen metde voor-
gestelde overdrachtsvoorwaarden.
A.9.1.4. Aanbeveling: Voor klimmende of dalende vluchten dienen de
geschatte gegevens tevens supplementaire kruisingsgegevens en
kruisingsvoorwaarden te bevatten.
A.9.1.5. Indien gebruiktzullen de supplement aire kruisingsgegevens het
supplementaire kruisingsniveau op het controleoverdrachtspunt
bevatten. De kruisingsvoorwaarden zullen zijn:
— Letter 'A'; — als de vlucht zich op of boven het niveau in de
supplementaire kruisingsgegevens zal bevinden; of
— Letter 'B'; — als de vlucht zich op of onder het niveau in de
supplementaire kruisingsgegevens zal bevinden.
A.9.2. ICAO
Veldtype 14.
A.9.3. ADEXP
Primair veld „coordata”.
Subveld „ptid” binnen het Primaire veld „coordata” zal ofwel
bevatten:
— een bekend referentiepunt; of
— een koers en afstand vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht door Primair veld „REF” of
„GEO”.
A.10. Coördinatiepunt
A.10.1. Algemeen
A.10.1.1. Hetcoördinat iepuntwaarnaar wordtverwezen door de overdra-
gende en ontvangende ATC-eenheden ten behoeve van de
betreffende overdracht.
A.10.1.2. Hetcoördinat iepuntzal worden gedefinieerd als ofwel een bekend
referentiepunt, een afstand en koers vanaf een bekend referentiepunt
of een breedte- en lengtegraad.
A.10.2. ICAO
Veld 14, element(a).2000R2082 — NL — 15.06.2002 — 001.001 — 66
▼B
A.10.3. ADEXP
Primair veld „cop” datbevat :
— een bekend referentiepunt; of
— een koers en een afstand vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht door het Primaire veld „REF”
of „GEO”.
A.11. Luchthaven van bestemming
A.11.1. ICAO
Veld 16, element(a).
A.11.2. ADEXP
Primair veld „ades”.
A.12. Vliegtuignummer en -type
Vliegtuignummer en -type zal het type vliegtuig bevatten. In het
geval van formatievluchten zal het aantal vliegtuigen worden opge-
nomen.
A.12.1. ICAO
Veldtype 9 in veldtype 22-structuur. Element c van veldtype 9 zal
ofwel de volgturbulentiecategorie bevatten die bij het type vliegtuig
hoort of de letter ‘Z'.
A.12.2. ADEXP
Primair veld „arctyp”. Als aanvulling, als de vlucht meer dan een
vliegtuig omvat, het Primaire veld „nbarc”.
A.13. Route
Beide structuren ondersteunen de routebeschrijving zoals gedefini-
eerd voor ICAO-berichten die als eerste element de snelheid
vereist en het aangevraagde vluchtniveau of hoogte-informatie. Na
de snelheidsniveaugroep zullen de routegegevens als minimum
bevatten hetgeen in de volgende paragraaf wordt gespecificeerd.
Indien beschikbaar kunnen verdere routegegevens worden inge-
voegd na onderdeel c). Zie ook Bijlage B 'Speciale vereisten voor
routeverwerking' voor de regels voor het invoegen van routegege-
vens.
A.13.1. Inhoud
A.13.1.1. Vluchten die zich bewegen via een gedefinieerde COP
— het route-element voor het COP (ATS-route, SID-identificatie,
DCT of belangrijk punt);
— hetCOP;— het route-element na het COP (ATS-route of belangrijk punt).
A.13.1.2. Vluchten die zich bewegen buiten een ATS-route
— het punt van waaraf de vlucht zich beweegt op het directe route-
segment;
— hetelement‘DCT';— hetpuntwaarnaar de vluchtzich beweegtop hetdirect e rout e-
segment.
A.13.2. Structuur
A.13.2.1. ICAO
Veldtype 15, in veldtype 22-structuur.
A.13.2.2. ADEXP
Primair veld „route”.2000R2082 — NL — 15.06.2002 — 001.001 — 67
▼M1
A.14. Dit veld maakt het mogelijk om in gespecificeerde berichten vlucht-
plangegevens op te nemen die normaal niet worden opgenomen in
hetkader van de coördinat ieprocedure en nietelders in deze bijlage
worden beschreven. De opname van de volgende items zoals
beschreven in referentie 1, aanhangsel 2, veldtypen 8 en 18, is
toegestaan:
— vluchtregels;
— registratiemarkeringen;— naam van de luchtvaartmaatschappij;— reden voor speciale behandeling door ATS;
— type;
— prestaties;— naam van de luchthaven van vertrek en bestemming en van de
alternatieve luchthavens;
— opmerkingen (tekst in gewone taal).
A.14.1. ICAO
Veldtype 8, element a) „Vluchtregels” in veldtype 22-structuur.
Eén of meer van de volgende veldtype 18-elementen in veldtype
22-structuur:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Primaire velden: „fltrul”, „depz”, „destz”, „opr”, „per”, „reg”,
„rmk”, „altrnt1”, „altrnt2”, „sts” en „typz”.
A.15. Coördinatiestatus en -reden
Coördinatiestatus en -reden zal de volgende elementen bevatten:
— een van de volgende indicators van drie letters die de nieuwe
status van het systeemvluchtplan bevestigen:
— INI, als het systeemvluchtplan zich in een initiële status
dient te bevinden, d.w.z. geen mededelingbericht ontvangen;
— NTF, als het systeemvluchtplan zich in een medegedeelde
status dient te bevinden;
— CRD, als het systeemvluchtplan zich in gecoördineerde
status dient te bevinden, d.w.z. basis ACT-bericht ontvangen
of initiële coördinatiedialoog voltooid met overeengekomen
voorwaarden.
— een indicator van drie letters die de reden voor de status speci-
ficeertals een van de volgende:
— TFL, als de reden een wijziging van hetoverdracht sniveau
is;
— RTE, als de reden een routewijziging is;
— HLD, om aan te geven dat de vlucht voor een onbepaalde
tijd in de wacht is geplaatst en dat er nog een verder bericht
voor zal volgen;
— DLY, om aan te geven dat het vertrek is vertraagd;— CAN, als de reden een annulering is;
— CSN, voor een wijziging van een oproepteken;
— OTH, voor elke andere reden of als de reden onbekend is.
A.15.1. ICAO
A.15.1.1. De coördinatiestatus en -reden zullen het Veldtype 18-structuur
hebben.
A.15.1.2. De coördinatiestatus en -reden zal de volgende elementen bevatten
in de vorm van een groep van tien tekens:
— STA gevolgd door een schuine streep;
— de indicator om de nieuwe status van de mededeling/coördinatie
te bevestigen;
— de indicator die de reden specificeert.
A.15.2. ADEXP
Primair veld „cstat”.2000R2082 — NL — 15.06.2002 — 001.001 — 68
▼B
▼B
Hulp-onderdelen „coordstatusident” en „coordstatusreason” zullen
de nieuwe status en reden bevatten zoals hierboven respectievelijk
gespecificeerd.
A.16. Toegewezen koers (alleen ADEXP)
Primair veld „ahead” zal bevatten ofwel:
— de koers die aan een vlucht is toegewezen, uitgedrukt in graden;
of
— als geen koers is toegekend, de indicator „ZZZ”, bijv. als een
SDM-berichtwordtgebruiktom aan t e geven dateen eerder
toegewezen koers niet langer van toepassing is.
A.17. Toegewezen snelheid (alleen ADEXP)
Primair veld „aspeed” zal bevatten ofwel:
— de aan een vlucht toegewezen snelheid, uitgedrukt in knopen,
mach-nummer of kilometers/uur;
of
— als geen snelheid is toegewezen, de indicator „ZZZ”, bijv. als
een SDM-berichtwordtgebruiktom aan t e geven dateen eerder
toegewezen snelheid niet langer van toepassing is.
A.18. Toegewezen klim-/daalsnelheid (alleen ADEXP)
Primair veld „rate” zal bevatten:
— de aan een vlucht toegewezen klim- of daalsnelheid, uitgedrukt
in honderden voeten per minuut;
of
— als geen klim-/daalsnelheid is toegewezen, de indicator „ZZZ”
in hetcijfergedeelt e van hetveld, bijv. als een SDM-bericht
wordt gebruikt om aan te geven dat een eerder toegewezen
klim-/daalsnelheid nietlanger van t oepassing is.
A.19. Directe vrijgave (alleen ADEXP)
Een directe route, niet gedefinieerd als een ATS-route, tussen twee
punten. De punten kunnen worden gedefinieerd als ofwel een
bekend referentiepunt of een afstand en koers vanaf een referentie-
punt. Alle gebruikte eindpuntaanduidingen zullen bilateraal worden
overeengekomen, d.w.z. bekend zijn bij beide systemen.
Primair veld „DCT” zal bevatten:
— hetpuntwaarop de afwijking is begonnen of zal beginnen,
gedefinieerd als een van de volgende:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht door het Primaire veld
„REF”;
of
— de waarde „ZZZ” als de verzendende eenheid nietvereist
dathetafwijkingspuntwordtaangewezen.
— het punt op de oorspronkelijke vluchtplanroute waarvoor het
vliegtuig is of zal worden vrijgegeven, gedefinieerd als:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht als het Primaire veld
„REF”.
A.20. Directe routeaanvraag
Aanvraag voor een directe route, niet gedefinieerd als een ATS-
route, tussen twee punten. De punten kunnen worden gedefinieerd
als ofwel een bekend referentiepunt of een afstand en koers vanaf
een referentiepunt.
Alle gebruikte eindpuntaanduidingen zullen bilateraal worden over-
eengekomen, d.w.z. bekend bij beide systemen.2000R2082 — NL — 15.06.2002 — 001.001 — 69
▼B
A.20.1. ICAO
Veldtype 15, exclusief de initiële snelheids-/niveaugroep, in veld
22-structuur.
Dit type zal bevatten:
— hetpuntwaarop de afwijking aangevraagd is om t e beginnen,
gedefinieerd als een van de volgende:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt;
of
— de waarde „ZZZ” als een directe route wordt aangevraagd
door de ontvangende ATC-eenheid.
— de afkorting 'DCT',— gevolgd door het punt op de oorspronkelijke vluchtplanroute
waarvoor gevraagd wordt om het vliegtuig vrij te geven, gedefi-
nieerd als:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt.
A.20.2. ADEXP
Primair veld „DCT” datbevat :
— hetpuntwaarop de afwijking is aangevraagd om t e beginnen,
gedefinieerd als een van de volgende:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht door het Primaire veld
„REF”;
of
— de waarde „ZZZ” als een directe route wordt aangevraagd
door de ontvangende ATC-eenheid maar het precieze punt
waarop de route zou beginnen niet bekend is.
— het punt op de oorspronkelijke vluchtplanroute waarvoor
gevraagd wordt om het vliegtuig vrij te geven, gedefinieerd als:
— een bekend referentiepunt;
of
— een afstand en koers vanaf een bekend referentiepunt, zoals
gedefinieerd in hetzelfde bericht door het Primaire veld
„REF”.
A.21. Positie (alleen ADEXP)
A.21.1. Algemeen
A.21.1.1. De huidige positie van de vlucht uitgedrukt in ofwel geografische
coördinaten of door middel van koers en afstand vanaf een aange-
wezen punt.
A.21.1.2. Primair veld „ref” of „geo” zal de huidige horizontale locatie van
het vliegtuig definiëren. De punten die worden gebruikt voor
afstand- en koersdoeleinden in het Primaire veld „ref” zullen bilate-
raal worden overeengekomen, d.w.z. bekend zijn bij beide
systemen. Primair veld „position” zal het subveld „ptid” bevatten
datverwijstnaar hetgedefinieerde referent iepuntof geografische
punt. Als tijdinformatie dient te worden opgenomen dient ofwel
het subveld ‘to' (uumm) of ‘sto' (uummss) te worden gebruikt, zoals
bilateraal overeengekomen.
A.22. Vrijgave-indicatie (alleen ADEXP)
Primair veld „release” zal een van de volgende bevatten:
— C, als de vluchtwordtvrijgegeven om t e klimmen;
— D, als de vluchtwordtvrijgegeven om t e dalen;
— T, als de vluchtwordtvrijgegeven voor bocht en;— F, als de vluchtvolledig wordtvrijgegeven voor alle act ies.2000R2082 — NL — 15.06.2002 — 001.001 — 70
▼B
A.23. Frequentie
A.23.1. ICAO
Veldtype 18 zal de volgende elementen in veld 22-structuur
bevatten:
— FRQ, gevolgd door een schuine streep;
— 6 cijfers die de frequentie aangeven, uitgedrukt in MHz met drie
cijfers achter de komma.
A.23.2. ADEXP
Primair veld „freq”.
A.24. Reden (alleen ADEXP)
Primair veld „reason”, datde waarde „MANUAL” bevatvoor hand-
matig verwezen berichten.
A.25. Vrijgegeven vluchtniveau (alleen ADEXP)
Primair veld „cfl”.
A.26. Overdrachtvluchtniveau (alleen ADEXP)
Primair veld „propfl”.
A.27. Geschatte vertrektijd
A.27.1. ICAO
Veldtype 13 element (b).
A.27.2. ADEXP
Primair veld „etot”.
A.28. Type verwijzingsbericht
Het veld bevat het berichttype zoals gespecificeerd in paragraaf A.1
van deze bijlage.
A.28.1. ICAO
Veldtype 18 in veldtype 22-structuur. De elementindicator zal
'MSG' zijn.
A.28.2. ADEXP
Primair veld „msgtyp”.
A.29. Vluchttype
Dit item wordt verwerkt in het vluchtplan of in equivalente gege-
vens uit een alternatieve bron. De letter „X” wordt gebruikt
wanneer het vluchttype niet is opgenomen in het vluchtplan of om
andere redenen onbekend is.
A.29.1. ICAO
Het vluchttype wordt opgenomen als één enkele letter in de veld-
type 22-structuur met gebruikmaking van het pseudo-
veldtypenummer 80.
A.29.2. ADEXP
Primair veld „flttyp”.
A.30. Capaciteit en status van de apparatuur
In dit item worden de capaciteit en status aangegeven van de appa-
ratuur die hetzij verplicht is voor vluchten in bepaalde luchtruimen
of op gespecificeerde routes, hetzij een significant effect heeft op
de levering van ATC-diensten. De aanwezigheid van bedoelde
capaciteit wordt aangegeven in het vluchtplan, maar kan incorrect2000R2082 — NL — 15.06.2002 — 001.001 — 71
▼M1
▼M1
blijken te zijn of gewijzigd worden in de loop van de vlucht. In het
item „Capaciteit en status van de apparatuur” wordt de huidige
status gespecificeerd.
De status van de volgende apparatuur wordt vermeld:
— RVSM-capaciteit;
— 8,33 kHz RTF-apparatuur.
De status van de volgende apparatuur wordt vermeld bij staats-
vluchten zoals gespecificeerd in het „Vluchttype” in het vluchtplan
waarvoor 8,33 kHz RTF-apparatuur, voorzover bekend is, niet
beschikbaar is:
— UHF-apparatuur.
A.30.1. ICAO
De gegevens worden opgenomen in veldtype 22-structuur met
gebruikmaking van hetpseudo-veldt ypenummer 81.
Voor elke capaciteit worden twee elementen opgenomen:
— de capaciteit van de apparatuur, uitgedrukt met één enkele letter
zoals gespecificeerd in veldtype 10 „Apparatuur” in het ICAO-
vluchtplan (zie referentie 1, aanhangsel 3), onmiddellijk gevolgd
door
— een scheidingsteken — schuine streep (/), onmiddellijk gevolgd
door
— de status, uitgedrukt met twee letters.
De status wordt uitgedrukt met behulp van de volgende indicatoren
zoals van toepassing op de vlucht:
a) EQ betekent dat de vlucht over de apparatuur beschikt en dat die
klaar is voor gebruik tijdens de vlucht;
b) NO betekent dat de vlucht niet over de apparatuur beschikt of
datde apparat uur om een andere reden nietkan worden gebruikt
tijdens de vlucht;
c) UN betekent dat de capaciteit niet bekend is.
De eerste capaciteitsgroep wordt direct na de op het veldnummer
volgende schuine streep ingevoegd. De volgende groepen worden
gescheiden door een spatie. De volgorde van de groepen is wille-
keurig.
A.30.2. ADEXP
Primair veld „EQCST”.2000R2082 — NL — 15.06.2002 — 001.001 — 72
▼B
BIJLAGE B (Normatief)
SPECIALE VEREISTEN VOOR ROUTEVERWERKING
B.1. Inleiding
B.1.1. Algemeen
B.1.1.1. Deze bijlage bevateen beschrijving van de regels en vereist en voor
hetinvoegen van gegevens in de volgende gevallen, waar t oege-
staan:
— een vlucht volgt een directe koers, buiten de route, over de
grens als hetgevolg van een directrout esegmentdatis opge-
nomen in hetvlucht plan;
— na verzending van hetABI- of ACT-berichtwordteen vlucht
omgeleid via ofwel:
— een andere ATS-route;
— een directe koers om op een later punt de oorspronkelijke
route weer te gaan volgen.
B.1.1.2. Met betrekking tot het omleiden van vluchten (paragraaf B.1.1.1)
ondersteunt de gegevensuitwisseling zoals beschreven in deze
bijlage de aanpassing van de vliegroute zoals aanwezig in beide
systemen met behulp van mededelings- en coördinatieberichten.
B.2. Toepassing van berichten
B.2.1. Basisregels voor directe routes
B.2.1.1. Voorwaarden voor hetgebruik van OLDI voor de coördinat ie van
vluchten op directe routes zullen bilateraal worden overeenge-komen.
B.2.1.2. De gegevens die vereistzijn voor de mededeling en coördinat ie van
vluchten op directe routes zijn vervat in het coördinatiepunt
(geschatte gegevens (ICAO-structuur) en coördinatiegegevens
(ADEXP-structuur)) en de route in de betreffende berichten.
B.2.2. Ingediende directe route
Als de route aangeeft dat de vlucht de grens op een directe koers
zal overschrijden, worden het directe routesegment en het daaruit
voortkomende COP opgenomen in het ABI-bericht/de ABI-
berichten. Deze COP wordt opgenomen in het daarop volgende
ACT- of RAP-bericht.
De COP- en routegegevens zullen worden gestructureerd zoals
beschreven in paragraaf B.3.2.
B.2.3. Omleidingen na ABI- en voor ACT-verzending
Er zal een nieuw ABI-berichtworden verzonden metgegevens die
overeenkomen metde nieuwe rout e.
B.2.4. Omleiding na ACT-verzending
B.2.4.1. Een REV-berichtzal worden gebruiktom aan t e geven datomlei-
dingen na het ACT-bericht zijn gezonden tot een bilateraal
overeengekomen tijd voor de ETO op het eerdere gecoördineerde
COP.
OPMERKING Een REV-bericht wordt alleen gebruikt als de
accepterende eenheid niet verandert als gevolg van
de aanpassing. Als de eenheid wel verandert moet
een MAC-bericht naar de oorspronkelijke accepte-
rende eenheid worden verzonden of de coördinatie
dient verbaal te worden geannuleerd.
B.2.4.2. Het bericht zal de volgende gegevenselementen bevatten:
— Coördinatiepunt (vorig COP, voor referentiedoeleinden);
— Geschatte gegevens;
— Route.2000R2082 — NL — 15.06.2002 — 001.001 — 73
▼B
B.2.4.3. Berichten in ICAO-structuur zullen de volgende velden bevatten:
3 Berichttype en -nummer; berichtreferentie indien bilateraal
overeengekomen;
7 Vliegtuigidentificatie. Elementen b en c zullen niet worden
opgenomen tenzij gelijktijdig een herziening van de SSR-code
wordtgecoördineerd;
13 Luchthaven van vertrek;
14 Alleen elementa, dathetvorige COP bevatvoor referent ie-
doeleinden;
16 Bestemming;22 Veld 14 dat de geschatte gegevens voor de nieuwe grensover-
schrijdingvoorwaarden in veld 22-structuur bevat;
22 Veld 15 dat de nieuwe route in veld 22-structuur bevat.
B.2.4.4. Berichten in ADEXP-structuur zullen bevatten, naast het bericht-
type en -nummer, de vliegtuigidentificatie, de luchthaven van
vertrek, de bestemming en, indien bilateraal overeengekomen, het
berichtreferentienummer:
— hetvorige COP in hetCOP-veld;
— de nieuwe coördinatievoorwaarden in het COORDATA-veld;— de nieuwe route in het ROUTE-veld.
B.2.4.5. Routeherzieningen die zijn verzonden als onderdeel van de dialoog-
procedure zullen worden verzonden als RRV-berichten tenzij
bilateraal is overeengekomen om ze als „standaard” te beschouwen.
B.3. Inhoud van het veld
B.3.1. ATS-routes
Voor vluchten die worden omgeleid via een alternatieve ATS-route
worden de velden voor schatting en route gestructureerd zoals voor
ABI- en ACT-berichten.
B.3.2. Directe routes
B.3.2.1. Het coördinatiepunt in de geschatte gegevens zal het grensover-
schrijdingpunt zijn uitgedrukt als een koers en afstand vanaf een
rapportagepunt. Zulke punten zullen bilateraal worden overeenge-
komen. Als de afstand nul is of een vlucht binnen een bilateraal
overeengekomen afstand van een dergelijk punt zal passeren zal
alleen de identificatie van het punt worden opgenomen.
B.3.2.2. Indien bilateraal overeengekomen kan het coördinatiepunt voor een
vlucht op een directe route worden uitgedrukt door te verwijzen
naar de breedtegraad/lengtegraad.
B.3.2.3. De route zal bevatten:
— hetpuntop de oorspronkelijke rout e van waaraf hetvliegt uig
een directe route dient te volgen; als een vlucht direct vanaf de
„huidige positie” vliegt kan het punt worden uitgedrukt als een
koers en afstand vanaf een rapportagepunt. Indien bilateraal
overeengekomen kan het punt worden uitgedrukt door te
verwijzen naar breedtegraad/lengtegraad;
— de afkorting „DCT”;
— het punt waar het vliegtuig direct naar toe dient te gaan;— het restant van de verdere vliegroute [further route of flight]
(FRF), indien bekend bij hetverzendende syst eem.
B.4. Voorbeelden
B.4.1. Directe routes
B.4.1.1. ABI- en ACT-berichten
B.4.1.1.1. De vlucht (identificatie Jetset 253) zal de grens overschrijden op
een directe koers van Punt A (PTA) naar Punt C (PTC) waarna hij
ATS-route UA134 zal volgen. Het systeem bepaalt een COP van
koers 350, afstand 22 NM vanaf Punt B (PTB).2000R2082 — NL — 15.06.2002 — 001.001 — 74
▼B
Hetvolgende ABI-berichtwordtverzonden:
— 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. Het ACT-bericht heeft dezelfde structuur als het ABI-bericht
behalve dat de vliegroute optioneel is.
B.4.1.2. REV-bericht
VluchtHZT2051 was eerder hetonderwerp van hetvolgende ACT-
bericht(of ADEXP-equivalent ):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
2000R2082 — NL — 15.06.2002 — 001.001 — 75
▼B
De route van de vlucht loopt dan 40 NM west van punt RQA direct
naar MYY. Het dichtstbijzijnde punt tot de grensoverschrijding is
TDS van waaraf de afstand tot het feitelijke overschrijdingspunt
26 NM is bij een koers van 240 graden. Hetvolgende herzienings-
berichtwordtverzonden:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
HetADEXP-equivalentvan hetberichtis:
-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
In een daarop volgend herzieningsberichtzou TDS240026 worden
aangeduid als hetCOP.2000R2082 — NL — 15.06.2002 — 001.001 — 76
▼B
B.4.2. Omleiding via ATS-routes na verzending van ACT-bericht
B.4.2.1. ACT-bericht
De route van vlucht GKP217 is gepland via coördinatiepunt EMT.
Hetvolgende ACT-berichtwordtverzonden:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
De vluchtwordtvervolgens omgeleid via ATS rout e UM247
binnen het luchtruim van het verzendende centrum naar het nieuwe
coördinatiepunt XAT waarna hij ATS route UJ124 dient te volgen.
Het accepterende centrum blijft hetzelfde. Het volgende herzie-
ningsberichtwordtverzonden:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
2000R2082 — NL — 15.06.2002 — 001.001 — 77
▼B
De vlucht wordt dan vrijgegeven voor FL290 hetgeen resulteert in
hetvolgende bericht(dathetnieuwe COP bevat ):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. ADEXP-equivalenten
De ADEXP-equivalenten van de twee herzieningsberichten luiden
als volgt:
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 — NL — 15.06.2002 — 001.001 — 78
▼B
BIJLAGE C (Ter informatie)
DIALOOGPROCEDURE (SYSCO NIVEAU 1) FASEN — BERICHTENVOLGORDE
Berichtenvolgorde
2000R2082 — NL — 15.06.2002 — 001.001 — 79
▼B
BIJLAGE II
AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION
(ADEXP), EDITIE 2.0
(Eurocontrol-referentiedocument DPS.ET1.ST09-STD)2000R2082 — NL — 15.06.2002 — 001.001 — 80
▼B
INHOUDSOPGAVE
AUTEURSRECHT
VOORWOORD1. REIKWIJDTE2. REFERENTIES3. DEFINITIES, SYMBOLEN EN AFKORTINGEN
3.1. Notatie3.2. Definities3.3. Constructie3.4. Conventies3.5. Operators3.6. Afkortingen
4. ADEXP-PRINCIPES
4.1. Door de mens leesbare tekst4.2. Geïdentificeerde en opvraagbare velden4.3. Niet-herkende velden
5. ADEXP SYNTAXIS-REGELS
5.1. Lexicale elementen5.2. Velden
6. GENORMALISEERDE BESCHRIJVING VAN ADEXP-BERICHTEN
6.1. Inleiding6.2. Hulptermen6.3. Definitie van primaire velden6.4. Definitie van subvelden6.5. Groep van berichten
BIJLAGE A (NORMATIEF) VELDDEFINITIES
BIJLAGE B (NORMATIEF) CENTRALE INDEX VAN ADEXP-BERICHTTITELSBIJLAGE C (NORMATIEF) CENTRALE INDEX VAN GERESERVEERDE BERICHTTITELSBIJLAGE D (NORMATIEF) CENTRALE INDEX VAN GERESERVEERDE VELDENBIJLAGE E (TER INFORMATIE) INTRODUCTIE VAN BERICHTGROEPENBIJLAGE F (TER INFORMATIE) VOORBEELDEN VAN ADEXP-BERICHTSTRUCTUURBIJLAGE G (TER INFORMATIE) TOEKOMSTIGE ONTWIKKELINGEN2000R2082 — NL — 15.06.2002 — 001.001 — 81
▼B
AUTEURSRECHT
Ditdocumentis geproduceerd door Eurocont rol Agency.
Het auteursrecht berust bij Eurocontrol Agency.De inhoud, of enig deel daarvan, is dus vrijelijk beschikbaar voor vertegen-
woordigers van de lidstaten, maar voor kopiëren of openbaarmaking aan
derden is voorafgaand schriftelijke toestemming vereist van Eurocontrol
Agency.2000R2082 — NL — 15.06.2002 — 001.001 — 82
▼B
VOORWOORD
1. Verantwoordelijke instantie
Deze norm is ontwikkeld en wordt onderhouden door de User
Requirements Section van de Central Flow Management Unit
(CFMU) van de European Organisation for the Safety of Air
Navigation (Eurocontrol).
2. EATCHIP Work Programme Document
Deze norm is geproduceerd als een te realiseren onderdeel van
hetEATCHIP Work Programme Document(EWPD), Dat a
Processing Systems Domain (DPS), Executive Task 09.
3. Goedkeuring van de norm
3.1. Deze norm wordtaanvaard in overeenst emming metde proce-
dures zoals beschreven in de Directives for Eurocontrol
Standardisation, Ref. 000-2-93, Edition 1.0.
3.2. De bepalingen van deze norm werden van krachtna aanvaarding
van uitgave 1.0 door de Permanente Commissie van Eurocontrol
in 1995 en hun toepassingsdatum ging in op 1 december 1997.
4. Technische correcties en amendementen
Deze norm wordtbijgehouden om er zeker van t e zijn dat
vereiste amendementen of technische correcties worden opge-
nomen. De procedure voor hetonderhoud van deze norm st aat
vermeld in Annex H van de Directives for the Uniform Drafting
and Presentation of Eurocontrol Standard Documents.
Amendementen of toevoegingen die van invloed zijn op de basis-
principes of grammatica van de ADEXP-structuur zullen alleen
plaatsvinden na de formele beoordelingsprocedure zoals vastge-
legd in de Directives for the Uniform Drafting and Presentation
of Eurocontrol Standard Documents.
Amendementen of toevoegingen aan deze norm zullen schriftelijk
worden voorgelegd aan: CFMU Users Requirements Section
(ADEXP), Eurocontrol Agency.
5. Redactionele conventies
5.1. De stijl van deze norm voldoet aan de Directives for the Uniform
Drafting and Presentation of Eurocontrol Standard Documents,
hoewel op sommige plaatsen van de Directives wordt afgeweken.
De kleinere stijlafwijkingen van de Directives zijn bedoeld om
verwarring met de notatie ATS Data Exchange Presentation
(ADEXP) te voorkomen.
5.2. De volgende notatie wordt gebruikt om de status van elke formu-
lering aan te geven:
— Voor normatieve elementen worden de (hulp)werkwoorden
„zullen” of „dienen” gebruikt, afgedrukt in lichte Romeinse
letters;
— VoorAanbevolen elementen worden de (hulp)werkwoorden
„zouden” of „dienen” gebruikt, afgedrukt in lichte cursieve
letters, waarbij de status wordt aangegeven door het prefix
Aanbeveling .
6. Relatie met andere normdocumenten
Deze norm is gerelateerd aan:Eurocontrol-normdocument voor On-Line Data Interchange
(OLDI)
7. Status van bijlagen bij deze norm
Deze richtlijn bevat zes bijlagen, waarvan de status als volgt is
gedefinieerd:
Bijlage A normatief;
Bijlage B normatief;Bijlage C normatief;Bijlage D normatief;2000R2082 — NL — 15.06.2002 — 001.001 — 83
▼B
Bijlage E ter informatie;
Bijlage F ter informatie;Bijlage G ter informatie.
8. Taal
Het origineel van deze norm is gesteld in de Engelse taal.2000R2082 — NL — 15.06.2002 — 001.001 — 84
▼B
1. REIKWIJDTE
1.1. ADEXP is een structuur, geen protocol. Er gelden geen beper-
kingen voor de te gebruiken transmissiemedia of protocollen,
anders dan die van de tekenset.
1.2. ADEXP biedt een structuur de primair bedoeld is voor gebruik in
de on-line uitwisseling van berichten tussen computers.
1.3. Dit document bevat een definitie van de principes en syntaxisre-
gels van het ADEXP-structuur. Deze definitie wordt geleverd in
termen van een uitgebreide definitie van de ADEXP-velden.
1.4. De ADEXP-structuur is gespecificeerd voor gebruik binnen de
volgende gebieden van gegevensuitwisseling (raadpleeg voorinformatie over documentreferenties Sectie 0, pagina …):
— Vluchtplanning: uitwisseling van vluchtplangegevens en
bijbehorende berichten tussen het Integrated Initial Flight
Plan Processing System (IFPS), Air Traffic Services (ATS)
en Aircraft Operators (AO). (Documentref. 3)
— Air Traffic Flow Management[beheer van lucht verkeer-
sstromen] (ATFM): uitwisseling van berichten tussen het
Tactical System (TACT) van de CFMU, AO en ATS.
(Documentref. 5)
— Coördinatie van luchtverkeersleiding: uitwisseling van tacti-
sche coördinatieberichten tussen Air Traffic Control Units
(ATCU). (Documentref. 6)
— Luchtruimbeheer: uitwisseling van gegevens tussen nationale
ATS-eenheden, de CFMU en AO, met betrekking tot beschik-
baarheid van het luchtruim. (Documentref. 7)
— Civiele / Militaire Coördinatie: berichten met betrekking tot
civiele/militaire vluchtgegevens en berichten met betrekking
tot het doorkruisen van luchtruimen. (Documentref. 7)
1.5. Gedetailleerde specificaties met betrekking tot het gebruik en de
inhoud van de berichten binnen elk van de bovengenoemde
groepen is aanwezig in de documenten waarnaar wordt verwezen.
2. REFERENTIES
2.1. De volgende documenten en normen bevatten bepalingen die,
doordater in deze t ekstnaar wordtverwezen, bepalingen vormen
van dit Eurocontrol-normdocument.
Ten tijde van publicatie van dit Eurocontrol-normdocument
waren de genoemde uitgaven van de documenten en normen
waarnaar wordtverwezen correct .
Elke herziening van de documenten van de International Civil
Aviation Organisation (ICAO) waarnaar wordt verwezen wordt
onmiddellijk gebruikt om dit Eurocontrol-normdocument te
herzien.
Herzieningen van de andere documenten waarnaar wordt
verwezen zullen geen deel uitmaken van de bepalingen van dit
Eurocontrol-normdocument totdat ze formeel zijn beoordeeld en
in ditEurocont rol-normdocumentzijn opgenomen.
In het geval van conflicten tussen de vereisten van dit Eurocon-
trol-normdocument en de inhoud van deze andere documenten
waarnaar wordtverwezen, zal ditEurocont rol-normdocument
prevaleren.
2.2. Ten tijde van publicatie zijn de hieronder vermelde documenten
die waarnaar in deze norm wordtverwezen. Gebruikers kunnen
echter desgewenst de tabellen voor het gebruik en de samenstel-
ling van berichtenvelden controleren in de laatste nieuwe
uitgaven van deze documenten.
1. ICAO Chicago Convention Annex 10 Volume I, uitgave geda-
teerd november 1985;
2. ICAO Chicago Convention Annex 10 Volume II, uitgave
gedateerd juli 1995;
3. IFPS and RPL Dictionary of Messages, uitgave 1.0, gedateerd
maart1998;
4. „Rules of the Air and Air Traffic Services”, PANS-RAC Doc
4444, uitgave gedateerd november 1985 (inclusief Amendment
nr. 6 gedateerd november 1995);2000R2082 — NL — 15.06.2002 — 001.001 — 85
▼B
5. Guide To ATFM Message Exchange Eurocontrol
Documentref. TACT/USD/MSGGUID, uitgave 6.0, geldend
vanaf maart1998,
6. Eurocontrol Standard for On-Line Data Interchange,
uitgave 2.0, gedateerd oktober 1996.
7. Functional Specifications for System Support to Airspace Data
Distribution and Civil Military Co-ordination, uitgave 1.0,
gedateerd mei 1996.
3. DEFINITIES, SYMBOLEN EN AFKORTINGEN
3.1. Notatie
De notatie die wordt gebruikt om de syntaxis te definiëren wordt
Backus Naur Form (BNF) genoemd. BNF definieerteen reeks
regels die een klasse tekenreeksen bepaalt. In dit geval is de
klasse tekenreeksen de reeks berichten die een syntactisch geldig
ADEXP-berichtkan worden genoemd.
3.2. Definities
Ten behoeve van ditEurocont rol-normdocumentgelden de
volgende definities:
Token : Een teken of reeks tekens dat of die door een lexicale
analysator kan worden „geëxtraheerd” door de aanwezigheid van
scheidingstekens.
Symbool : Elke „term” die in een BNF-regel voorkomt maar geen
teken is.
Terminalsymbool : Een symbool datwordtweergegeven in t ermen
van een reeks tekens.
Niet-terminalsymbool : Een symbool datwordtweergegeven door
een of meer terminalsymbolen.
OPMERKING Een niet-terminalsymbool kan ook worden weer-
gegeven als een mengeling van terminal- en niet-
terminalsymbolen.
3.3. Constructie
3.3.1. BNF bestaat uit een reeks regels of constructies in de vorm:
symbool::= expressieOPMERKINGEN
1)De notatie „::=” dient te worden gelezen als „kan worden
vervangen door”.
2)Het „symbool” wordt geclassificeerd als niet-terminal.
3)Het „expressie” gedeelte bevat terminal- en niet-terminalsym-
bolen.
3.3.2. Terminalsymbolen hebben een directe weergave als een reeks
tekens die door een lexicale analysator, dankzij de aanwezigheid
van scheidingstekens, kan worden herkend als een token.
3.4. Conventies
Ten behoeve van ditEurocont rol-normdocumentgelden de
volgende conventies:
—Terminalsymbolen staan in hoofdletters.
OPMERKING Volgens conventie betekent het NIL-terminal-
symbool „geen terminalsymbool” .
Het wordt gebruikt in keuzen, zoals in onder-
staand voorbeeld:
a::= b ( c | NIL) waar a kan worden
vervangen door (b gevolgd door c) of door
alleen b.
—Niet-terminalsymbolen (bijv. de linkerkantvan een grammat i-
caproductie) staan in kleine letters.
—Tekens en letterreeksen die binnen regels voorkomen worden
respectievelijk omsloten door enkele (') of dubbele aanha-
lingstekens (").2000R2082 — NL — 15.06.2002 — 001.001 — 86
▼B
Voorbeelden
1) HYPHEN::= '-'
2) title::= '-' "TITLE" titleid
Voor sommige toepassingen voor gegevensmodellering kan het
nodig zijn om verschil te maken tussen terminal- en niet-termi-
nalsymbolen metandere middelen dan door hetgebruik van
hoofdletters en kleine letters.
Telkens als het nodig is om expliciet verschil te maken tussen
terminal- en niet-terminalsymbolen, anders dan door het gebruik
van hoofdletters en kleine letters, wordt aanbevolen om een
aanvullende suffix te gebruiken, als volgt: „_at” voor een hulp-
term, „_pf” voor een primair veld en „_sf” voor een subveld.
3.5. Operators
Ten behoeve van ditEurocont rol-normdocumentgelden de
volgende operatoren:
Facultatief: Als sommige symbolen legitiem al dan niet op een
bepaald puntbinnen de grammat ica kunnen voorkomen. De facul-
tatieve symbolen staan tussen vierkante haakjes „[” en „]”.
Sluiting: Als een groep symbolen nul of meer keren mag voor-
komen. De symbolen staan tussen accolades „{” en „}”. Als
voor de „{” een getal wordt gespecificeerd, geeft dit het
minimum aantal keren aan dat de groep symbolen mag voor-
komen. Als na de „}” een getal wordt gespecificeerd geeft dit
hetmaximum aant al keren aan datde groep symbolen mag voor-
komen.
Keuze: Als een aantal alternatieve symbolen op een bepaald punt
binnen de grammatica mag voorkomen. Keuze wordt weerge-
geven door „|”.
Aaneenschakeling: Weergave van opeenvolgende symbolen, zelfs
als er in het midden een of meer scheidingstekens staan. Hiervoor
bestaat geen expliciete weergave. Er zijn twee typen:
—Strikte aaneenschakeling: op hetlexicale niveau kunnen de
regels aaneenschakeling van terminals omvatten, waarbij
wordtaangegeven datze st riktop elkaar volgen (geen schei-
dingst eken in hetmidden), in datgeval zal hetsymbool '!'
worden gebruikt.
Voorbeeld datetime:: = date ! timehhmm
Bijv. "9912251200" hetgeen betekent 25 december 1999, om
12.00 uur.
—Losse aaneenschakeling: scheidingstekens tussen terminals
zijn toegestaan. De weergave van losse aaneenschakeling
binnen een regel kan implicietof explicietzijn.
Voorbeelden1) Impliciet:
dct::= '-' "DCT" point point
2) Expliciet
dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
Bijv. "-DCT NTM RMS".
OPMERKINGEN
1)Aaneenschakeling zal altijd prioriteit hebben boven Keuze.
Haakjes „(” en „)” worden gebruikt om de evaluatievolgorde
van de expressie te veranderen.
Voorbeeld a::= B C | D is gelijk aan: a::= (B C) | D
en NIET
aan:a::= B (C | D).
2)In alle regels zal de toegestane aanwezigheid van scheidings-
tekens tussen de symbolen impliciet worden gelaten, teneinde
de leesbaarheid te behouden .2000R2082 — NL — 15.06.2002 — 001.001 — 87
▼B
Aanbeveling: Als er kans op verwarring bestaat als gevolg van
prioriteit tussen de bovengenoemde operatoren wordt aanbevolen
om de haakjes te gebruiken teneinde de gewenste evaluatievolg-
orde te verduidelijken.
3.6. Afkortingen
Ten behoeve van ditEurocont rol-normdocumentgelden de
volgende afkortingen:
ACH ATC FlightPlan AmendmentMessage [bericht
met ATC-vluchtplanamendement]
ADEG ATS Data Exchange Group [ATS-gegevensuitwis-
selingsgroep]
ADEXP ATS Data Exchange Presentation [presentatie van
ATS-gegevensuitwisseling]
AFIL Air-Filed FlightPlan [in de luchtingediend
vluchtplan]
AFP ATC FlightPlan Proposal [voorst el voor ATC-
vluchtplan]
AFTN Aeronautical Fixed Telecommunication Network
[aëronautisch vast telecommunicatienetwerk]
ANM ATFM Notification Message [ATFM-medede-
lingsbericht]
AO Aircraft Operator(s) [luchtvaartmaatschappij(en)]APL ATC FlightPlan [ATC vlucht plan]ATC Air Traffic Control [luchtverkeersleiding]
ATCU Air Traffic Control Unit(s) [luchtverkeersleidin-
geenheid/-eenheden]
ATFM Air Traffic Flow Management[lucht verkeer-
sstroombeheer]
ATS Air Traffic Services [luchtverkeersdiensten]
BNF Backus Naur FormCASA Computer Assisted Slot Allocation [door
computer gesteunde beurttoewijzing]
CIDIN Common ICAO Data Interchange Network [alge-
meen ICAO-netwerk voor gegevensuitwisseling]
CFL Cleared FlightLevel [vrijgegeven vlucht niveau]CFMU Central Flow Management Unit [centrale
verkeersstroombeheerseenheid
CMTP Common Medium-Term Plan [algemeen middel-
langetermijnplan]
CNL Cancellation Message [annuleringsbericht]CTOT Calculated Take-Off Time [berekende opstijgtijd]
DPS Data Processing Systems Domain [domein van
gegevensverwerkingssystemen]
ECAC European Civil Aviation Conference [Europese
burgerluchtvaartconferentie]
EFL Estimated Flight Level [geschat vluchtniveau]EOBT Estimated Off-Block Time [geschatte afbloktijd]ETO Estimated Time Over [geschatte tijd boven]Eurocontrol European Organisation for the Safety of Air Navi-
gation [Europese organisatie voor de veiligheid
van de luchtvaart]
EWPD EATCHIP Work Programme Document
[EATCHIP-werkprogrammadocument]
FIR Flight Information Region [vluchtinformatieregio]
FIW Flight Plan Input Workstation [werkstation voor
vluchtplaninvoer]
FMP Flow Management Position [verkeersstroombe-
heerpositie]
FNM Flight Notification Message [vluchtmededelings-
bericht]
FPL Flight Plan Message (ICAO format) [vluchtplan-
bericht (ICAO-structuur)]
GAT General Air Traffic [algemeen luchtverkeer]
IA International Alphabet [internationaal alfabet]2000R2082 — NL — 15.06.2002 — 001.001 — 88
▼B
IAFP Individual ATC FlightPlan Proposal [individueel
ATC vluchtplanvoorstel]
ICAO International Civil Aviation Organisation [interna-
tionale organisatie voor de burgerluchtvaart]
IFPD Individual Flight Plan Data [individuele vlucht-
plangegevens]
IFPS Integrated Initial Flight Plan Processing System
[geïntegreerd systeem voor initiële vluchtplanver-
werking]
IFPU IFPS Unit[IFPS-eenheid]IFR Instrument Flight Rules [regels voor vliegen op
instrumenten]
ISO International Standards Organisation [internatio-
nale normenorganisatie]
ITA International Telegraph Alphabet [internationaal
telegrafisch alfabet]
LAM Logical AcknowledgementMessage [logisch
bevestigingsbericht]
LRM Logical Rejection Message [logisch afwijzingsbe-
richt]
MAC Co-ordination Abrogation Message [bericht voor
opheffing van coördinatie]
MFS Message from Shanwick [berichtvan Shanwick]
OAT Operational Air Traffic [operationeel luchtver-
keer]
OLDI On-Line Data Interchange [on-line gegevensuit-
wisseling]
RFL Requested Flight Level [aangevraagd vluchtni-
veau]
RFP ReplacementFlightPlan [vervangend vlucht plan]RFPD Repetitive Flight Plan Data [herhaalde vluchtplan-
gegevens]
RPL Repetitive Flight Plan [herhaald vluchtplan]RVR Runway Visual Range [zichtbaar start-/landings-
baanbereik]
SFL Supplementary Flight Level [supplementair
vluchtniveau]
SRD Software Requirements Document [document met
softwarevereisten]
SSR Secondary Surveillance Radar [secundaire bewa-
kingsradar]
TACT Tactical System of the CFMU [tactisch systeem
van de CFMU]
TOS Traffic Orientation Scheme [verkeersoriëntatie-
systeem]
UIR Upper Information Region [bovenste informatie-
regio]
VFR Visual FlightRules [regels voor vliegen met
visuele waarneming]
4. ADEXP-PRINCIPES
4.1. Door de mens leesbare tekst
4.1.1. De ADEXP-structuur is een tekststructuur die is gebaseerd op
tekens.
4.1.2. De ADEXP-berichten blijven leesbaar door een menselijke
operator, waardoor betere mogelijkheden bestaan om ze aan te
passen of operationeel in te zetten.
4.1.3. Een tekststructuur is tevens opener en begrijpelijker.
4.2. Geïdentificeerde en opvraagbare velden
4.2.1. Een bericht in ADEXP-structuur zal bestaan uit velden.2000R2082 — NL — 15.06.2002 — 001.001 — 89
▼B
4.2.2. Velden zullen worden begrensd door een speciaal begin-van-veld
teken, het koppelteken („-”) en worden aangeduid door specifieke
trefwoorden.
OPMERKING Opgemerkt dient te worden dat bepaalde velden
(die welke syntactisch zijn gedefinieerd als het
lexicale onderdeel „CHARACTER” bevattend)
legitiem een teken „-” mogen bevatten als onder-
deel van de veldinhoud.
4.2.3. Deze benadering verbetert de uitbreidbaarheid en robuustheid van
de structuur. (Als een veld afwezig of onjuist is kan het worden
overgeslagen en kan hetrest erende deel van hetberichtnog
steeds worden geïnterpreteerd (zie sectie 0).
4.2.4. Een ander gevolg is datde volgorde van velden in een bericht
niet relevant zal zijn om de legitimiteit ervan te bepalen, behalve
voor wat betreft het eerste veld (verplicht titelveld) dat de toege-
stane velden bepaalt.
4.2.5. Velden kunnen basisvelden of samengestelde velden zijn.4.2.6. De onderdelen waaruit samengestelde velden bestaan worden
subvelden genoemd, welke worden gedefinieerd door de aanwe-
zigheid van trefwoorden, begrensd door een begin-van-veld teken.
4.2.7. Basisvelden zijn velden die geen subvelden bevatten.
4.2.8. De basisvelden of samengestelde velden waaruit het eerste defini-
tieniveau van een bericht is opgebouwd worden de primaire
velden genoemd.
4.2.9. Alle onderdelen van een lager niveau zijn per definitie subvelden,
die op hun beurtbasisvelden of samengest elde velden kunnen
zijn.
4.2.10. Er zijn twee soorten samengestelde velden, namelijk gestructu-
reerde velden en lijstvelden.
4.2.11. Gestructureerde velden hebben een vooraf gedefinieerde inhoud
die exclusief bestaat uit subvelden. De volgorde van subveldenin een gestructureerd veld is NIET belangrijk.
4.2.12. Lijstvelden worden geïntroduceerd door het trefwoord BEGIN en
beëindigd door het trefwoord END. Daartussen kunnen herhaalde-
lijk dezelfde subvelden of combinaties van subvelden voorkomen.
De volgorde binnen een lijstveld is semantisch belangrijk.
4.2.13. In het volgende gedeelte zal de term „veld” algemeen worden
gebruiktom primaire en/of subvelden aan t e duiden, behalve
indien explicietanders vermeld.
4.2.14. Velden in een bericht kunnen facultatief of verplicht zijn, zoals
gedefinieerd door hun syntaxis.
4.3. Niet-herkende velden
4.3.1. Als in een berichteen onbekend berichtverschijnt , zal ditworden
genegeerd.
4.3.2. Metandere woorden, als hetsyst eem dathetberichtanalyseert
een trefwoord niet herkent, zal alle tekst tot aan het volgende
bekende primaire veld, dat zich niet binnen een lijstveld bevindt,
worden genegeerd.
4.3.3. Afhankelijk van de berichttitel kan het genegeerde veld al dan
nieteen afwijzing veroorzaken van hetberichtdatwordt
verwerkt.
OPMERKING Opgemerkt dient te worden dat hoewel ADEXP is
ontworpen om dit soort flexibiliteit te bieden, het
aan het oordeel van degenen die verantwoordelijk
zijn voor het definiëren van de interfacebehoeften
wordt overgelaten om, voor elk bericht, aan te
geven hoe het systeem dient te reageren op een
niet-herkend veld.
4.3.4. Als hetonbekende veld een lijst veld is (ditis afgeleid uithett ref-
woord -BEGIN), dan wordtde gehele inhoud (t otaan het
bijbehorende trefwoord -END) genegeerd.
4.3.5. Teneinde alle eventuele dubbelzinnigheid te vermijden tijdens het
herstel dat volgt op het overslaan van een niet-herkend veld is2000R2082 — NL — 15.06.2002 — 001.001 — 90
▼B
vereistdateen t refwoord voorafgaataan een primair veld of een
subveld.
4.3.6. Hierdoor kunnen twee soorten trefwoorden worden gedefinieerd:
— Primaire trefwoorden;
— Subtrefwoorden.
4.3.7. Nadatis gedefinieerd dateen t refwoord van de ene soortis zal
hetnietverder opnieuw worden gebruiktin een andere groep
berichten als van de andere soort, met als enige uitzondering als
het zich in een lijstveld bevindt. Een primair trefwoord kan overal
binnen een lijstveld meerdere malen voorkomen zonder dubbel-
zinnigheid te creëren, aangezien de aanwezigheid van het
trefwoord BEGIN aangeeft dat we het trefwoord in dit geval als
een subveld kunnen beschouwen.
Voorbeelden (van gebruik van typen trefwoorden)
1)Primair veld
-RFL F330
2)Subveld: altijd binnen een „Samengesteld veld”
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000Wwaarbij -GEO een primair samengesteld veld is en -GEOID, -
LATTD en LONGTD subvelden zijn.
3)Lijstveld
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTSwaarbij „-BEGIN” de indicator van het lijstveld is en
„RTEPTS” een primair veld.
OPMERKING „RFL” is gedefinieerd als een primair veld.
Opname binnen een lijstveld is de enige gelegen-
heid waarbij een primair veld kan worden
gebruikt als een subveld (zie Voorbeeld 3 hier-
boven).
5. ADEXP SYNTAXIS-REGELS
5.1. Lexicale elementen
5.1.1. Tekenverzameling
5.1.1.1. De tekenverzameling die dient te worden gebruikt voor de uitwis-
seling van berichten in ADEXP-structuur zal het International
AlphabetNumber 5 (IA-5) zijn zoals gedefinieerd in Referent ie
1.
5.1.1.2. De ADEXP-structuur is ontworpen als een uitwisselingsstructuur
tussen computers onderling die kan worden verzonden op
verschillende computernetwerken of op speciale verbindingen
tussen computers onderling. Daarnaast bestaat een vereiste om
enkele ADEXP-berichten te kunnen uitwisselen, gewoonlijk met
betrekking tot vluchtplanning en ATFM, op het Aeronautical
Fixed Telecommunication Network (AFTN).
5.1.1.3. Voor berichten die mogelijk dienen te worden verzonden via
AFTN zal de tekenverzameling worden beperkt tot die tekens
die een directe correlatie hebben tussen International Telegraph
AlphabetNumber 2 (ITA-2) en IA-5, zoals gedefinieerd in
Referentie 1.
OPMERKING Naast grafische tekens en structuureffectors zoals
hieronder gedefinieerd, definieert de tekenverza-
meling ITA-2 „signalen” (zoals geperforeerde
band). Deze maken geen deel uit van de toege-
stane tekenverzameling voor ADEXP-berichten.
5.1.1.4. De tekens die zijn toegestaan voor gebruik binnen ADEXP-
berichten die via AFTN kunnen worden verzonden zijn de grafi-2000R2082 — NL — 15.06.2002 — 001.001 — 91
▼B
sche tekens en de structuureffectors die hieronder worden gedefi-
nieerd:
Grafische tekens
a) hoofdletters (A t/m Z)
b) cijfers (0 t/m 9)
c) speciale grafische tekens, als volgt:
1) spatieteken „ ”
2) haakje openen „(”3) haakje sluiten „)”4) liggend streepje „-”5) vraagteken „?”6) dubbele punt„:”
7) punt„.”
8) komma „,”9) apostrof „'”
10) isgelijkteken „=”11) plusteken „+”12) schuine streep „/”
Structuureffectors
a) Wagenterugloop
b) Regelopschuiving
5.1.2. Lexicale basistermen
De volgende lexicale basistermen zijn gedefinieerd voor gebruik
in deze specificatie:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'
— ALPHANUM ::= ALPHA | DIGIT
— SPACE ::= ' '
— HYPHEN ::= '-'— FEF ::= Carriage_return | Line_Feed
— SEP ::= 1{ SPACE | FEF }
— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'
— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF
— START-OF-FIELD ::= HYPHEN
OPMERKING LIM_CHAR staat voor elk toegestaan teken
behalve HYPHEN, dat is gereserveerd om het
begin van een veld aan te duiden. Daarentegen
staat CHARACTER voor elk toegestaan element
van de tekenset.
5.1.3. Regels, scheidingstekens en begrenzers
5.1.3.1. De verdeling van de tekst van een bericht in regels zal geen
syntactisch effect hebben.
5.1.3.2. Een scheidingsteken kan een spatieteken zijn of een structuuref-
fector.
5.1.3.3. Velden zullen alleen worden afgebakend door de aanwezigheid
van een begin-van-veldteken gevolgd door een trefwoord.
5.1.3.4. Daardoor kan hethele berichtgeldig op één regel st aan.5.1.4. Waarden met voortekens
5.1.4.1. Hetkan nodig zijn aan t e geven dateen numerieke waarde nega-
tief is.
5.1.4.2. Velden waarvoor vereistis datze een negat ieve waarde
aanduiden zullen, binnen hun syntaxisdefinitie, de waarde expli-
cietaanduiden als een „waarde metvoort eken” d.w.z. als
positief of negatief. Een veld dat niet als zodanig is gedefinieerd
mag geen negatieve waarde weergeven.2000R2082 — NL — 15.06.2002 — 001.001 — 92
▼B
5.1.4.3. Een „waarde met voorteken” zal altijd worden voorafgegaan door
de letter „N” voor negatief of de letter „P” voor positief. Een
nulwaarde kan worden voorafgegaan door „N” of „P”.
5.1.4.4. De syntaxis van een veld dat een „waarde met voorteken”
toestaat zal als volgt zijn:
'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}Voorbeeld: Een veld genaamd „NUMBER” dateen negat ieve
waarde van een tot acht cijfers mag bevatten zou
worden gedefinieerd als:
'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8
Daarom: -NUMBER P5 — waarde van „number” is +5
-NUMBER N5 — waarde van „number” is -5
-NUMBER 5 — ongeldige syntaxis, ofwel een
„P” of een „N” dientaanwezig
te zijn
5.1.5. Trefwoorden
5.1.5.1. Een trefwoord is elke reeks van hoofdletters of cijfers. Dit vormt
alleen hetbegin van een veld indien voorafgegaan door een
begin-van-veldteken („-”).
keyword::= 1{ ALPHANUM }
5.1.5.2. Keywords [trefwoorden] zullen voldoen aan de volgende
syntaxis:
'-'!{SEP}!"KEYWORD"!1{SEP}! <subfield/s or contained value>d.w.z. dat een trefwoord van zijn „begin-van-veld teken” zal
worden gescheiden door nul of meer scheidingstekens. Het tref-
woord zal onmiddellijk worden gevolgd door een of meer
scheidingstekens, gevolgd door het/de betreffende subveld(en) of
inhoudwaarde.
OPMERKING Het is belangrijk om op te merken dat een tref-
woord en hetdaaraan voorafgaande begin-van-
veld teken door elk willekeurig aantal scheidings-
tekens kan worden gescheiden, inclusief door
geen tekens.
Voorbeelden (de volgende reeksen vormen alle op geldige wijze
hetbegin van een veld)
1) -TITLE IFPL
2) - TITLE IFPL
3) - TITLE IFPL4) -
TITLE IFPL
5.1.5.3. Aanbeveling: Het verdient aanbeveling het gebruik van een
scheidingsteken tussen het begin-van-veld teken „-” en het
daarop volgende trefwoord te vermijden.
OPMERKING
1) In bovenstaande voorbeelden is het eerste voorbeeld de aanbe-
volen keuze.
2) Het is ook belangrijk om op te merken dat een trefwoord
onmiddellijk moet worden gevolgd door ten minste één schei-
dingsteken.
5.1.5.4. Binnen hetgehele documentwordtde aaneenschakeling van
onderdelen die worden gescheiden door ten minste één schei-
dingsteken impliciet aangegeven door de notatie „Losse
aaneenschakeling” (zie 0).
OPMERKING Zoals later zal worden uitgelegd vormen tref-
woorden eveneens hetbegin van lijst velden als ze worden
voorafgegaan door hett refwoord BEGIN.
5.1.5.5. Trefwoorden zullen zo kortmogelijk zijn zonder dathun seman-
tische betekenis wordt aangetast.
5.1.5.6. De vooraf gedefinieerde trefwoorden van de ADEXP-structuur
die hieronder staan vermeld zullen bij specifiek gebruik van de2000R2082 — NL — 15.06.2002 — 001.001 — 93
▼B
structuur niet opnieuw worden gedefinieerd of in een andere rol
worden gebruikt:
TITLE: duidt een categorie berichten aan en definieert
de bijbehorende verzameling toegestane
primaire velden;
BEGIN: duidthetbegin van een lijst veld aan;
END: duidtheteinde van een lijst veld aan;
COMMENT: duidteen comment aarveld aan.
5.1.5.7. Teneinde dubbelzinnigheid (dubbel gebruik van hetzelfde tref-
woord met verschillende betekenissen) of redundantie
(verschillende trefwoorden met dezelfde betekenis) te vermijden
wordt in deze norm in Bijlage A (A3) een Centrale definitietabel
van primaire velden (d.w.z. primaire trefwoorden) bijgehouden en
wordt in Bijlage A (A4) ook een Centrale definitietabel van
subvelden (bijv. subtrefwoorden) bijgehouden.
5.2. Velden
5.2.1. Veldsyntaxis
field::= basic_field | structured_field | list_fieldbasic_field::= '-' keyword contained_valuescontained_values::= {CHARACTER}list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keywordstructured_field::= '-' keyword field_1 field_2 ….field_nOPMERKING Zoals zal blijken wordtin hetgeval van lijst -
velden hett refwoord nietonmiddellijk
voorafgegaan door „-” maar door de constructie
„-”„BEGIN”.
5.2.2. Samenstelling van berichten in termen van velden
5.2.2.1. Het eerste veld van een ADEXP-bericht zal altijd een veld TITLE
zijn (d.w.z. een veld datwordtvoorafgegaan door hett refwoord
TITLE).
5.2.2.2. De resterende inhoud van een bericht in termen van de primaire
velden ervan zal worden gedefinieerd door de TITLE.
5.2.2.3. De syntaxis van berichten die behoren bij een gegeven TITLE zal
worden gedefinieerd door de velden die hetberichtbevat(gedefi-
nieerd door hun trefwoorden):
— De naam en toegestane inhoud van de primaire velden van het
bericht;
— De naam en toegestane inhoud van de subvelden van het
bericht.
5.2.3. Basisvelden
5.2.3.1. De syntaxis van basisvelden zal als volgt zijn:
basic_field::= '-' keyword contained_values
5.2.3.2. „Contained_values” definieert de tekst die de waarde van het veld
leverten mag niethetbegin zijn van een subveld.
Voorbeeldregel arctyp::= '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")
OPMERKING:1) Een explicietequivalent e regel waarvan is:
arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype |
"ZZZZ").
2) Een voorbeeldgedeelte van een bericht is ::
"-ARCTYP ZZZZ".
5.2.3.3. Aanbeveling: Als er meer dan twee inhoudswaarden in een
basisveld staan en er, daarnaast, de noodzaak bestaat om
„keuze” of „optie” tussen de waarden tot uitdrukking te brengen,2000R2082 — NL — 15.06.2002 — 001.001 — 94
▼B
wordt aanbevolen om van het veld een gestructureerd veld te
maken en om de inhoudwaarden op te nemen in subvelden.
5.2.4. Lijstvelden
5.2.4.1. De syntaxis van de lijstvelden zal als volgt zijn:
list_field::='-' "BEGIN" keyword { subfields } '-' "END" keyword
5.2.4.2. De „subfields” kunnen elke combinatie zijn van subvelden, die
nul of meer keer binnen hetlijst veld kunnen voorkomen.
5.2.4.3. De lijstmetsubvelden die een gegeven lijst veld bevatzal een
geordende setvormen (de volgorde van de subvelden is belang-
rijk).
Voorbeeldregel addr::= '-' "BEGIN" "ADDR" { fac } '-' "END"
"ADDR"
OPMERKINGEN1) Dit voorbeeld toont dat een „addr” veld een lijstveld is dat 0
of meer malen een subveld „fac” bevat (een ATS-faciliteit).
2) Een voorbeeldgedeelte van een bericht dat ADDR toont als
een lijstveld dat FAC-subvelden bevat is:
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.
3) Een voorbeeldgedeelte van een bericht dat een combinatie van
subvelden toont is:
xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".
5.2.5. Gestructureerde velden
5.2.5.1. De syntaxis van gestructureerde velden zal als volgt zijn:
structured_field::= '-' keyword field_1 field_2…field_n
5.2.5.2. De toegestane subvelden in een gegeven gestructureerd veld
zullen alleen afhangen van het gestructureerde veld zelf.
5.2.5.3. De volgorde van subvelden in een gestructureerd veld zal niet
belangrijk zijn, watde mogelijkheid biedtvoor gemakkelijke
toekomstige uitbreidingen (door het toevoegen van nieuwe
subvelden).
Voorbeeldregel pt::= '-' "PT" ptid [fl] [eto]
OPMERKINGEN1) Dit definieert het veld „pt” als een gestructureerd veld dat een
punt (subveld „ptid”) bevat, eventueel gevolgd door een bere-
kend vluchtniveau (subveld „fl”), eventueel gevolgd door een
geschatte tijd boven het punt (subveld „eto”).
2) Een voorbeeld van datveld zou zijn:
"-PT -PTID RMS -FL F250 -ETO 921225120000".
5.2.5.4. Aanbeveling: Als men van mening is dat de inhoud van een veld
in de toekomst kan evolueren, is het gewenst om er een gestructu-
reerd veld van te maken. Dit maakt een progressieve uitbreiding
van de subvelden van het veld mogelijk. Anderzijds kan een basis-
veld eenvoudiger of meer vertrouwd zijn om te gebruiken, maar
een dergelijk veld legt een vaste reeks elementen (waarden) op
met zeer beperkte uitbreidingsmogelijkheden.
5.2.6. Het veld COMMENT
5.2.6.1. Hetcomment aarveld vormthetbegin van een gebied metvrije
tekst waarin alle beschikbare tekens behalve het begin-van-veld
teken („-”) kunnen worden gebruikt en dat zich uitstrekt tot het
volgende veld.
comment::= '-' "COMMENT" { LIM_CHAR }Voorbeeld COMMENT DIT IS HET BEGIN VAN EEN VRIJ
GEBIED VOOR ROUTETEKST
5.2.7. Het veld TITLE
5.2.7.1. Het eerste veld van een ADEXP-bericht zal altijd een titelveld
zijn. De syntaxis ervan zal als volgt zijn:
title::= '-' "TITLE" 1{ ALPHA }102000R2082 — NL — 15.06.2002 — 001.001 — 95
▼B
5.2.7.2. De mogelijke waarden van het titelveld bestaan uit de set
ADEXP-berichtentitels, zoals vermeld in Bijlage B van deze
norm.
Voorbeeld -TITLE IFPL
6. GENORMALISEERDE BESCHRIJVING VAN ADEXP-
BERICHTEN
6.1. Inleiding
6.1.1. In de volgende paragrafen wordtgedefinieerd hoe de ADEXP-
structuur van verschillende categorieën berichten zal worden
beschreven op een genormaliseerde wijze, binnen hetkader van
de huidige norm.
6.1.2. De Genormaliseerde beschrijving omvat:
— definitie van hulptermen;
— definitie van de syntaxis en semantiek van elk individueel
primair veld;
— definitie van de syntaxis en semantiek van elk individueel
subveld;
— definitie van elke groep berichten met verwijzing naar hun
definitiedocumentatie.
6.1.3. Deze norm bevat geen details met betrekking tot de veldsamen-
stelling en de regels voor het invoegen van gegevens voor elke
berichttitel.
6.1.4. Verwezen dient te worden naar de definitiedocumentatie (Interfa-
cespecificatie) die van toepassing is op de betreffende
berichtgroep (zie sectie 6.5.7).
6.1.5. Definitiedocumentatie dient, op een genormaliseerde wijze, voor
elke berichttitel de volgende informatie te leveren:
— een lijstmetverplicht e primaire velden;
— een lijst met facultatieve primaire velden;— de regels voor hetinvoegen van gegevens voor elk veld en in
het bijzonder de regels met betrekking tot het gebruik van
subvelden die binnen deze norm zijn gedefinieerd als faculta-
tief;
— de regels met betrekking tot herstel volgend op de constate-
ring van een niet-herkend veld.
6.1.6. De velden die op dit moment binnen de lidstaten van Eurocontrol
zijn gedefinieerd en overeengekomen voor gebruik binnen de
verschillende categorieën berichten die zijn gedefinieerd voor
gebruik metADEXP zijn die welke in Bijlage A van ditdocu-
mentst aan vermeld.
6.1.7. Een veld zal nietworden gebruiktvoor een ander doel dan
hetgeen is gespecificeerd in de semantische beschrijving van dat
veld.
6.1.8. Bijlage D bevateen cent rale index van gereserveerde velden.
„Gereserveerde velden” zijn nietovereengekomen voor gebruik
binnen de op ditmomentgedefinieerde ADEXP-bericht en.
Gewoonlijk betreft het velden die zijn voorzien voor mogelijk
toekomstig gebruik, of ze worden lokaal binnen nationale
systemen gebruikt. Het doel van hun opname in deze norm is
om te helpen bij het garanderen van de uniekheid van de veldti-
tels en het vermijden van onnodige redundantie.
6.2. Hulptermen
6.2.1. Om tot een leesbare definitie van velden te komen is het vaak
nuttig om hulptermen in de grammaticale beschrijving te introdu-
ceren.
6.2.2. Hulptermen vormen geen begin van een veld of subveld en zijn
daarom nietgeassocieerd meteen bepaald t refwoord. Ze kunnen
echter verschijnen in de definitie van meer dan een veld, subveld
of hulpveld. Een hulpterm zoals „date” kan worden gebruikt in de
definitie van vele velden.
6.2.3. Alle noodzakelijke hulptermen zullen worden geïntroduceerd in
alfabetische volgorde en zijn gedefinieerd in Bijlage A (A2) van
deze norm.2000R2082 — NL — 15.06.2002 — 001.001 — 96
▼B
6.2.4. De beschrijving kan worden gepresenteerd in de vorm van een tabel zoals in onder-
staand voorbeeld, gesorteerd op alfabetische volgorde:
Hulpterm Syntaxis SemantiekGebruiktin
primair
veldGebruiktin
subveldGebru-
iktin
hulp-
veld
adexpmsg { CHARACTER } Vrije tekst die
zich confor-
meertaan de
syntaxis die is
beschreven
voor een
ADEXP-
bericht.ifpdlong
rfpdlongpreproctxtpostproctxt
aidequip-
ment( ('N' | 'S') ! [ equi-
pmentcode ] ) |
equipmentcodeApparatuur
voor radiocom-
municatie,
navigatie en
hulp bij nade-
ring.ceqpt
aircraftid 1{ ALPHANUM
}7Vliegtuigiden-
tificatie.arcid
arcidkarcidoldprevarcid
6.3. Definitie van primaire velden
6.3.1. Alle primaire velden die in ADEXP-berichten worden gebruikt
zullen zich conformeren aan de syntaxis en semantiek zoals tot
uitdrukking gebracht in Bijlage A (A3) van deze norm.
6.3.2. De syntaxis van elk veld wordt als eerste gegeven, gevolgd door
de semantiek in heldere en ondubbelzinnige termen.
6.3.3. De syntaxis van velden zal tot uitdrukking worden gebracht met
behulp van de BNF-notatie zoals beschreven in sectie 3 van deze
norm.
6.3.4. De beschrijving kan worden gepresenteerd in een tabel zoals in onderstaand voorbeeld,
gesorteerd op alfabetische volgorde, waarbij:
— De eerste kolom het linker gedeelte van een BNF-regel voorstelt (d.w.z. het
gedeelte van de regel links van het symbool „::=”) en de derde kolom het rechter
gedeelte van de regel voorstelt.
— De tweede kolom (Type) geeft aan of een veld een basisveld („b”) of een samen-
gesteld („c”) veld is.
Primair veld Type Syntaxis Semantiek
eobt b '-' "EOBT" timehhmm Geschatte afbloktijd
6.4. Definitie van subvelden
6.4.1. Alle subvelden die in ADEXP-berichten worden gebruikt zullen
zich conformeren aan de syntaxis en semantiek zoals tot uitdruk-
king gebrachtin Bijlage A (A4) van deze norm.
6.4.2. Daarnaastworden, om reden van kruisverwijzing, de primaire
velden waarbinnen een gegeven subveld verschijntaangegeven.
6.4.3. Een subveld kan ook een subveld van andere subvelden zijn,
daarom wordtook een kruisverwijzing naar deze subvelden
gegeven.2000R2082 — NL — 15.06.2002 — 001.001 — 97
▼B
6.4.4. De beschrijving kan worden gepresenteerd in een tabel zoals in onderstaand voorbeeld,
gesorteerd op alfabetische volgorde:
Subveld Type Syntaxis SemantiekGebruiktin
primair veldGebrui-
ktin
subveld
brng b '-' "BRNG"
refbearingPositie van een
puntvan een
navigatiehulp-
middel (in
magnetische
graden)ref
6.5. Groep van berichten
6.5.1. De operationele categorieën (groepen) berichten die zijn gedefini-
eerd voor gebruik met behulp van de ADEXP-structuur staan
vermeld in Bijlage E van deze norm.
6.5.2. De groepen worden gedefinieerd in termen van de operationele
aard van de berichten die worden uitgewisseld en worden vaak
gekenmerkt door de betreffende systemen.
6.5.3. Voor elke groep berichten zal worden verwezen naar de definitie-
documentatie.
6.5.4. Er zal geen titelwaarde voor een groep berichten opnieuw worden
gebruiktvoor een andere groep meteen andere bet ekenis.
6.5.5. In Bijlage B van deze norm zal een centrale index van berichtti-
tels worden bijgehouden.
6.5.6. Voor elke berichttitel die staat vermeld in de centrale index van
berichttitels wordt een verwijzing naar de gerelateerde groepgegeven. Verwijzing naar de definitiedocumentatie voor elke
berichttitel wordt daarom geleverd via de berichtgroep.
6.5.7. Bijlage C bevat tevens een centrale index van gereserveerde
berichttitels. „Gereserveerde” berichttitels zijn niet overeenge-
komen voor gebruik binnen de op ditmomentgedefinieerde
groepen berichten die gebruik maken van ADEXP. Gewoonlijk
zijn het berichten waarvan het mogelijke toekomstige gebruik is
voorzien binnen een van de gedefinieerde groepen of ze worden
lokaal binnen nationale systemen gebruikt. Het doel van hun
opname in deze norm is om te helpen bij het garanderen van de
uniekheid van berichttitels en het vermijden van onnodige redun-
dantie.2000R2082 — NL — 15.06.2002 — 001.001 — 98
▼B
BIJLAGE A (Normatief)
ADEXP-VELDDEFINITIES
A.1.Inleiding
Deze bijlage bevateen overzichtvan alle velden; hulpt ermen, primaire
velden en subvelden die zijn gedefinieerd voor gebruik in ADEXP.
A.2.ADEXP-hulptermen
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
adexpmsg { CHARACTER } Vrije tekst die zich
conformeertaan de
syntaxis die is
beschreven voor een
ADEXP-bericht.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment( ('N' | 'S') ! [ equi-
pmentcode ] ) |
equipmentcodeApparatuur voor
radiocommunicatie,
navigatie en hulp
bij nadering.ceqpt
aircraftid 2{ ALPHANUM }7 Vliegtuigidentifi-
catie.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Joker-vorm van
aircraftid voor
gebruik in Query-
berichten:
„?” vervangteen
teken
„+” vervangtelk
aantal tekens.arcidk
atsroute 2 {ALPHANUM} 7 De aanduiding van
een ATS-route.atsrt refatsrte
century 2{DIGIT}2 Twee eerste cijfers
van een eeuw.fulldate
coorstatusident 3 {ALPHA} 3 Een indicator van
de coördinatiestatus
van een vlucht.statid
coorstatusre-
ason3 {ALPHA} 7 De reden voor
mededeling van een
wijziging in de
coördinatiestatus.statre-
ason
country 2{ALPHA}2 De ICAO-aandui-
ding van twee
letters voor een
land.refatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4De ICAO-aandui-
ding van de data-
link-capaciteit.
Kan elk van de
waarden: S, H, V of
M in elke volgorde
bevatten, maar
zonder herhaling.dat2000R2082 — NL — 15.06.2002 — 001.001 — 99
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
date year ! month ! day Een datumnotatie in
het structuur,
JJMMDD.
bijv. 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 Een „date” term
zoals hierboven
beschreven en
onmiddellijk
gevolgd door de tijd
in de structuur
UUMM.
bijv.
9304240930=0930Z
op 24 april 1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6Een „date” term
waarvoor jokers
mogen worden
gebruikt.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITEen tweecijferig
getal dat de cijfers
00 t/m 31 kan
bevatten.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicator van het
type noodradioappa-
ratuur aan boord
van hetvliegt uig.
Kan een of meer
van de gedefini-
eerde tekens zijn in
elke volgorde, maar
zonder herhaling.splr
eqptcode 1 {ALPHANUM} 2 Code waarmee de
capaciteit van appa-
ratuur wordt aange-
geven. Kan identiek
zijn aan de equi-
pmentcode.eqpt
eqptstatus 2 {ALPHA} 2 Een tweeletterige
code waarmee de
status van de vlieg-
tuigcapaciteit wordt
aangegeven.eqpt2000R2082 — NL — 15.06.2002 — 001.001 — 100
▼M1
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
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' )} 24Een geldige ICAO-
codeletter die de
apparatuur aan
boord aanduidt. Kan
een of meer van de
gedefinieerde tekens
zijn in elke volg-
orde, maar zonder
herhaling.aidequip-
ment
errorcode 1{DIGIT}4 Codenummer van
foutbericht.error
fieldid 1{ ALPHANUM } Geldige ADEXP-
veldnaam (d.w.z.
trefwoord).errfield
ifpsmod
firindicator 4{ ALPHA }4 Een ICAO-aandui-
ding van een FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4Een vluchtniveau
uitgedrukt als
ofwel;
„F” of „A” gevolgd
door drie cijfers of,
„S” of „M” gevolgd
door vier cijfers.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'De reden voor
speciale behande-
ling zoals aange-
geven in veld 18
element„STS/”.
EMER = Emer-
gency (noodgeval)
HUM = Humanita-
rian flight(humani-
taire vlucht)
HOSP = Hospital
flight(hospit aal-
vlucht)
SAR = Search and
Rescue (zoek- en
reddingswerk)
HEAD = Head of
State (staatshoofd)
STATE = State
flight (staatsvlucht)sts
flightrule 'I' | 'V' | 'Y' | 'Z' De vluchtregelindi-
cator van een
vlucht.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'Hett ype vlucht
zoals aangegeven
door de gebruikte
ICAO-aanduiding.flttyp
flighttypechg 'OAT' | 'GAT' De aanduiding op
de route van een
vluchtvan een
verandering in het
type vlucht naar
„OAT” of „GAT”.chgrul ptrulchg
fulldate century ! year !
month ! dayEen datumnotatie in
de structuur
EEJJMMDD
bijv.
19970801 = 1 aug.
1997fulldate-
time2000R2082 — NL — 15.06.2002 — 001.001 — 101
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
fulldatetime fulldate ! timehhmm Een datum, zoals
beschreven in „full-
date” en onmiddel-
lijk gevolgd door de
tijd in de notatie
UUMM
bijv.
199708010930 = 09-
30 uur op 1 aug.
1997mesval-
period
geoname "GEO" !
2{DIGIT}2De identificatie die
wordtgegeven een
geografische positie
uitgedrukt in
breedte- en lengte-
graad.geoid
heading 3{DIGIT}3 Een driecijferig
nummer in het
bereik 001 tot 360.ahead
icaoaerodrome 4{ ALPHA }4 Een vierletterige
ICAO-aanduiding
voor een lucht-
haven.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Joker-vorm van
icaoaerodrome, voor
gebruik in Query-
berichten:
„?” vervangteen
teken
„+” vervangtelk
aantal tekens.adepk
adesk
icaoaircrafttype ALPHA ! 1{
ALPHANUM }3Een ICAO-aandui-
ding van een vlieg-
tuigtype.arctyp
icaomsg { CHARACTER } Een ICAO-bericht.
(conformeertaan de
syntaxis beschreven
in Ref. {4})msgtxt
ifpuid 1{ ALPHANUM } De identificatie van
een IFPS-eenheid.ifpuresp
latitudelong 6{ DIGIT }6 Een breedtegraad
uitgedrukt in zes
cijfers.lattd
latitudeside 'N' | 'S' Een indicator voor
„Noorder” of
„Zuider” breedte-
graad.lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4De ICAO-indicator
van hett ype
reddingsvesten dat
aan boord is. Kan
een of meer van de
gedefinieerde tekens
zijn in elke volg-
orde, maar zonder
herhaling.splj
longitudelong 7{ DIGIT }7 Een lengtegraad
uitgedrukt in zeven
cijfers.longtd2000R2082 — NL — 15.06.2002 — 001.001 — 102
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
longitudeside 'E' | 'W' Een indicator voor
„Ooster” of
„Wester” lengte-
graad.longtd
machnumber 'M' ! 3{ DIGIT }3 HetMach-nummer. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Aanduiding van het
type wijziging dat
in een veld wordt
aangebracht.ifpsmod
month ('0' | '1' ) ! DIGIT Maand, uitgedrukt
in een tweecijferig
nummer.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')De aanduiding van
de dagen van de
week waarop een
RPL actief is.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7De indicatie van de
dagen van de week
waarop een RPL
actief is. Joker-
tekens mogen ook
worden gebruikt.daysk
originatorid 1{ ALPHANUM
}10Identificatie van de
maker van een
bericht.orgnid
qrorgn
point2{ ALPHANUM }5 De aanduiding van
een belangrijk punt.
Kan een gepubli-
ceerd puntzijn, een
geografisch punt,
een referentiepunt
of een puntdat
kunstmatig wordt
gegeven, zoals een
„hernoemd” punt
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Referentiepositie-
waarde.brng
refname "REF" ! 2{DIGIT}2 De identificatie die
aan een puntwordt
gegeven uitgedrukt
door een positie en
afstand vanaf een
gepubliceerd puntrefid
regulid 1{ ALPHANUM
}20De aanduiding van
een ATFM-regeling
met betrekking tot
een vlucht.regul regid
renameid "REN" !
2{DIGIT}2Identificatie van een
hernoemd punt.renid
rrteid 1{ ALPHANUM}
20De identificatie van
een omleiding.rrteref
rtf 6{DIGIT}6 Een radiofrequentie
uitgedrukt in MHz
tot drie decimalen.freq
rulechg VFR' | 'IFR' De indicators die in
de route van een
vluchtworden
gebruiktom een
wijziging in de
vluchtregels aan te
geven.chgrul ptrulchg2000R2082 — NL — 15.06.2002 — 001.001 — 103
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSeconden.
Twee cijfers tussen
„00” en „59”.eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Snelheid.
Uitgedrukt als „K”
of „N” gevolgd
door vier cijfers.aspeed
speedcrspeed
ptspeed
ssrequipment1 {ALPHA} 2 De ICAO-aandui-
ding van de SSR-
apparatuur aan
boord en eventueel
de aanduiding van
een datalink-capaci-
teit.seqpt
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Aanduiding van een
„blijf” periode, een
periode van
„speciale activiteit”
binnen de route van
een vlucht.ptstay
stayident
survivaleqpt1 {'P' | 'D' | 'M' | 'J'
}4De ICAO-aandui-
ding van de overle-
vingsapparatuur aan
boord. Kan een of
meer van de gedefi-
nieerde tekens zijn
in elke volgorde
maar zonder herha-
ling.spls
text20 1{ LIM_CHAR }20 Tekst bestaande uit
1 tot 20 tekens, met
uitzondering van het
koppelteken.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITTijd, uitgedrukt in
uren (2 cijfers 00-
23) en minuten (2
cijfers 00-59). Kan
het tijdstip van de
dag zijn of een
tijdsduur.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_e-
lapsedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITEen onbeperkt
aantal uren en
minuten, gebruikt
voor tijdsduren.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Joker-vorm van een
timehhmm.eobtk2000R2082 — NL — 15.06.2002 — 001.001 — 104
▼B
Hulpterm Syntaxis SemantiekGebruikt
in
primair
veldGebruikt
in
subveldGebruikt
in hulp-
veld
titleid 1{ ALPHA }10 Een geldige
ADEXP-berichttitel
(zie Bijlage B).msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' De aanduiding van
de categorie ICAO-
volgturbulentie.wktrc
year 2{ DIGIT }2 Twee laatste cijfers
van een jaar.date
fulldate
A.3.ADEXP primaire velden
ADEXP
primair
veldType Syntaxis Semantiek
ad c '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]De aanduiding van een luchthaven.
In gevallen waarin de luchthaven
onderdeel vormtvan de rout ebe-
schrijving kan aanvullende route-
informatie worden geleverd.
ada b '-' "ADA" date Feitelijke datum van aankomst.
adarr b '-' "ADARR" (icaoaerodrome |
'ZZZZ')Feitelijke luchthaven van
aankomst.
adarrz b '-' "ADARRZ" text20 Naam van feitelijke luchthaven van
aankomstals geen ICAO- locat ie-
indicator bestaat.
add b '-' "ADD" date Feitelijke datum van vertrek.
addr c '-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Lijstmetgeadresseerden.
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')ICAO -locatie-indicator van de
luchthaven van vertrek of de
aanduiding „AFIL” die een in de
lucht ingediend vluchtplan betekent
of „ZZZZ” als geen ICAO-locatie-
indicator is toegewezen aan de
luchthaven van vertrek.
adepk b '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Bij gebruik van de luchthaven van
vertrek als databasesleutel in een
query kunnen jokers worden
gebruikt. Kan een ICAO-locatie-
indicator bevatten of de aanduiding
„AFIL” die een in de luchtinge-
diend vluchtplan betekent of
„ZZZZ” als geen ICAO-locatie-
indicator is toegewezen aan de
luchthaven van vertrek of een
combinatie van alfabetische en
joker-tekens.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')De „vorige” luchthaven van
vertrek. Kan de ICAO-locatie-indi-
cator bevatten of de aanduiding
„AFIL” die een in de luchtinge-
diend vluchtplan betekent of
„ZZZZ” als geen ICAO locatie-
indicator is toegewezen aan de
luchthaven van vertrek.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')De ICAO-locatie-indicator van de
luchthaven van bestemming of
„ZZZZ” als geen ICAO-locatie-
indicator is toegewezen aan de
luchthaven van bestemming.2000R2082 — NL — 15.06.2002 — 001.001 — 105
▼B
ADEXP
primair
veldType Syntaxis Semantiek
adesk b '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)Bij gebruik van de luchthaven van
bestemming als databasesleutel in
een query kunnen jokers worden
gebruikt.
Kan een ICAO-locatie-indicator
bevatten of „ZZZZ” als geen
ICAO-locatie-indicator is toege-
wezen aan de luchthaven van
bestemming of een combinatie van
alfabetische en joker-tekens.
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')De „vorige” luchthaven van
bestemming. Kan de ICAO-locatie-
indicator bevatten of „ZZZZ” als
geen ICAO-locatie-indicator is
toegewezen aan de luchthaven van
bestemming.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Bevateen ADEXP-bericht .
afildata c '-' "AFILDATA" ptid fl eto Geschatte gegevens voor een in de
luchtingediend vlucht plan.
Een puntidentificatie, het verbin-
dende vluchtniveau en de geschatte
datum-tijd op het punt.
Opmerking: hetaangegeven
vluchtniveau is het niveau waarop
de vluchtis vrijgegeven om het
geregelde luchtruim boven het
aangegeven puntbinnen t e gaan.
Dit hoeft niet hetzelfde te zijn als
de RFL.
ahead b '-' "AHEAD" (heading | "ZZZ") De koers die aan een vluchtis
toegewezen, uitgedrukt in graden.
Dienteen driecijferig numeriek
getal te zijn of de waarde „ZZZ”
die aangeeftdatgeen koers is
toegewezen.
altnz b '-' "ALTNZ" text20 Naam van alternatieve luchthaven
als geen ICAO-locatie bestaat.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')De ICAO-locatie-indicator van de
eerste alternatieve luchthaven vanbestemming of de indicator
„ZZZZ” als geen ICAO-locatie-
indicator aan de luchthaven is
toegewezen.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')De ICAO-locatie-indicator van de
tweede alternatieve luchthaven van
bestemming of de indicator
„ZZZZ” als geen ICAO-locatie-
indicator aan de luchthaven is
toegewezen.
aobd b '-' "AOBD" date Feitelijke Off_Block datum.aobt b '-' "AOBT" timehhmm Feitelijke Off_Block tijd.arcid b '-' "ARCID" aircraftid Vliegtuigidentificatie.
Kan de registratiemarkering van het
vliegtuig zijn of de ICAO-aandui-
ding van de luchtvaartmaatschappij
gevolgd door de vluchtidentificatie.
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Bij gebruik van een vliegtuigiden-
tificatie als een databasesleutel in
een query mogen jokers worden
gebruikt.
Dienteen combinat ie van alfanu-
merieke en joker-tekens te zijn tot
een totaal van maximaal 7 tekens.2000R2082 — NL — 15.06.2002 — 001.001 — 106
▼B
ADEXP
primair
veldType Syntaxis Semantiek
arcidold b '-' ARCIDOLD aircraftid Het „vorige” vliegtuig-id. Als het
vliegtuig-id. dient te worden
geamendeerd, wordtde nieuwe
waarde gegeven in „ARCID”.
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Type vliegtuig (ICAO-aanduiding
van hett ype) of ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")De op ditmomentaan hetvliegt uig
toegewezen snelheid, in kilometers
per uur, knopen of Mach-nummer.
Dienteen „M” t e zijn gevolgd door
drie cijfers, „K” of „N” gevolgd
door vier cijfers of „ZZZ” dat
aangeeftdatgeen snelheidsbeper-
king is toegewezen.
ata b '-' "ATA" timehhmm Feitelijke tijd van aankomst.
atd b '-' "ATD" timehhmm Feitelijke tijd van vertrek.
atot b '-' "ATOT" timehhmm Feitelijke tijd van opstijgen
atsrt b '-' "ATSRT" atsroute point point ATS-routeaanduiding en identifica-
ties van eerste en laatste punten.
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Adressen waaraan ATFM-berichten
dienen te worden geadresseerd.
ceqptb '-' "CEQPT" aidequipment Hulpapparat uur voor radiocommu-
nicatie, navigatie en nadering (als
ICAO-veld 10).
cfl c '-' "CFL" fl [ptid] Vrijgegeven vluchtniveau. Het op
ditmomentdoor ATC aan de
piloot toegewezen vluchtniveau
(vluchtniveaunummer).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointAanduiding van een wijziging in
ofwel de „vluchtregels” (VFR/IFR)
of het „type vlucht” (OAT/GAT) of
beide tezamen met het punt waarop
de wijziging plaatsvindt.
cobd b '-' "COBD" date Berekende Off-Block datum.
cobt b '-' "COBT" timehhmm Berekende Off-Block tijd.
com b '-' "COM" text20 Communicatieapparatuur (als
ICAO-veld 18 COM/).
commentb '-' "COMMENT" 1 { LIM_CHAR
}Een algemeen commentaar in vrije
tekst zonder koppelteken.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Aanduiding van een „buitengewone
omstandigheid” die in de context
van ATFM is ontstaan.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]De overdrachtsvoorwaarden van
een vlucht. Een punt-id., het
vluchtniveau en de geschatte tijd
op dat punt en facultatieve supple-
mentaire vluchtniveau-informatie.
cop b '-' "COP" point Een coördinatiepuntidentificatie,
ofwel een gecodeerde aanduiding
van een gegeven puntof een
kunstmatig gegeven naam (GEOxx,
RENxx of REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Aanduiding van een klim op kruis-
snelheid. Geefthetpuntwaarop het
klimmen zal beginnen, snelheid of
mach-nummer en de twee niveaus
die de vluchtniveauband aangeven
die tijdens het klimmen dient te
worden gebruikt. Het tweede
niveau mag „PLUS” zijn als het
bovenste niveau onbekend is.2000R2082 — NL — 15.06.2002 — 001.001 — 107
▼B
ADEXP
primair
veldType Syntaxis Semantiek
cstat c '-' "CSTAT" statid [statreason] Een indicator die de nieuwe
coördinatiestatus van een vlucht
bevestigt en, facultatief, de reden
voor de wijziging.
ctod b '-' "CTOD" date Calculated Take-Off Date [bere-
kende datum van opstijgen].
ctot b '-' "CTOT" timehhmm Calculated Take-Off Time [bere-
kende tijd van opstijgen] (CTOT):
referentietijd van een ATFM-beurt.
dat b '-' "DAT" datalink Aanduiding van de datalink-capaci-
teit die in het vliegtuig aanwezig is.
days b '-' "DAYS" numdays Operationele dagen voor een
herhaald vluchtplan (1234567
waarbij 1 staat voor maandag, 2
voor dinsdag, …, met0 in
kolommen waarin hetplan niet
operationeel is).
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Als operationele dagen voor een
herhaald vluchtplan worden
gebruikt als databasesleutel in een
query-berichtkunnen jokers
worden gebruikt.
daysold b '-' "DAYSOLD" numdays De „vorige” operationele dagen.
Gebruikt als een databasesleutel.
Als de operationele dagen van een
RPL dienen te worden geamen-
deerd zullen de nieuwe waarden
worden gegeven in „DAYS”.
dct b '-' "DCT" point point Geeft een directe route tussen twee
punten aan.
De punten kunnen ofwel een
geldige ICAO-aanduiding van eenpuntzijn of een puntdatverschijnt
in een GEO-, REN- of REF-vield
in de vorm GEOxx, RENxx of
REFxx.
delay b '-' "DELAY" timehhmm Een tijdsperiode die een vertraging
vertegenwoordigt. De aard van de
vertraging, d.w.z. vertraging tot een
vlucht, verwerkingsvertraging etc.
is afhankelijk van de context.
depz b '-' "DEPZ" text20 Naam van luchthaven van vertrek
als geen ICAO-locatie-indicator
bestaat.
desc b '-' "DESC" 1 {LIM_CHAR} Beschrijving van een omstandig-
heid of entiteit die van belang is
voor de inhoud van hetbericht .
destz b '-' "DESTZ" text20 Naam van luchthaven van bestem-
ming als geen ICAO-locatie-indi-
cator bestaat.
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedFIR-identificatie en de geaccumu-
leerde verlopen tijd (in uren en
minuten) tot aan de FIR-grens.
eetlat c '-' "EETLAT" lattd time Aanduiding van een verlopen tijd
tot een positie die alleen door een
breedtegraad wordt gegeven.
eetlong c '-' "EETLONG" longtd time Aanduiding van een verlopen tijd
tot een positie die alleen door een
lengtegraad wordt gegeven.
eetpt b '-' "EETPT" point timehhmm_e-
lapsedPuntidentificatie en de geaccumu-
leerde verlopen tijd tot het punt.
endtime b '-' "ENDTIME" day ! timehhmm De tijd waarop een tijdsperiode
eindigt.2000R2082 — NL — 15.06.2002 — 001.001 — 108
▼B
ADEXP
primair
veldType Syntaxis Semantiek
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]De vluchtplangegevens die van
toepassing zijn op een vlucht op
hetgegeven puntof bij hetbinnen-
gaan van de vluchtin hetbet ref-
fende luchtruim. Een of beide van
de velden; „ptid”, „airspdes”
dienen aanwezig te zijn.
eobd b '-' "EOBD" date Estimated Off-Block Date
[geschatte afblokdag].
eobdk b '-' "EOBDK" date Bij gebruik van Estimated Off-
Block Date als een databasesleutel
in een query kunnen jokers worden
gebruik.
Dienteen combinat ie van cijfers en
joker-tekens te zijn van in totaal
maximaal 6 tekens.
eobdold b '-' "EOBDOLD" date De „vorige” geschatte Off Block
Date. Gebruikt als een database-
sleutel. Als de Estimated Off Block
Date dient te worden geamendeerd
wordtde nieuwe waarde gegeven
in „EOBD”.
eobt b '-' "EOBT" timehhmm Estimated Off-Block Time
[geschatte afbloktijd] (EOBT)
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Als Estimated Off-Block Time
wordtgebruiktals een dat abase-
sleutel in een query mogen jokers
worden gebruikt.
eobtold b '-' "EOBTOLD" timehhmm De „vorige” Estimated Off Block
Time. Gebruiktals een dat abase-
sleutel. Als de Estimated Off Block
Date dient te worden geamendeerd
wordtde nieuwe waarde gegeven
in „EOBT”.
eqcstb '-' "BEGIN" "EQCST" 1 {eqpt }
'-' "END" "EQCST"Lijstvan codes waarmee de capa-
citeit van apparatuur wordt aange-
geven, telkens gevolgd door een
statuswaarde waarmee de huidige
status van de capaciteit wordt
aangegeven.
errfield b '-' "ERRFIELD" fieldid ADEXP-naam van foutief veld/
foutieve velden.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Foutberichttekst. Kan facultatief
een foutidentificatiecode bevatten.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Geschatte gegevens. Een punt-id.,
het geschatte vluchtniveau (vlucht-
niveaunummer) en de geschatte
datum-tijd op dit punt gevolgd door
het supplementaire vluchtniveau
(vluchtniveaunummer gevolgd door
de indicator A of B).
etod b '-' "ETOD" date Estimated Take_Off Date
[geschatte opstijgdatum].
etot b '-' "ETOT" timehhmm Estimated Take_Off Time
[geschatte opstijgtijd].
extaddr c '-' "EXTADDR" num | { fac } |
(num {fac})Adressen die worden geleverd als
aanvulling op die welke automa-
tisch worden bepaald d.w.z. „extra
adressen”. Kunnen alleen hetaant al
adressen of de feitelijke adressen of
beide bevatten.2000R2082 — NL — 15.06.2002 — 001.001 — 109
▼M1
▼B
▼B
ADEXP
primair
veldType Syntaxis Semantiek
filrte b '-' "FILRTE" {LIM_CHAR} De route exact zoals deze is inge-
diend, d.w.z. zonder enige verwer-
king.
filtim b '-' "FILTIM" day ! timehhmm Dag-tijd-groep die specificeert
wanneer hetberichtwerd ingediend
voor verzending.
flband c '-' "FLBAND" fl fl Een vluchtniveauband die het
luchtruim verticaal definieert, met
inbegrip van de gegeven vluchtni-
veaus.
fltrul b '-' "FLTRUL" flightrule Vluchtregel, als ICAO-veld 8.
flttyp b '-' "FLTTYP" flighttype Type vlucht, als ICAO-veld 8.
fmp b '-' "FMP" 4{ ALPHA }4 Identificatie van een „Flow Mana-
gement Position” [verkeersstroom-
beheerpositie].
fmplistc '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Lijstvan FMP's en hun bijbeho-
rende ATFM-regelingen.
freq b '-' "FREQ" rtf Radiofrequentie.
fstday b '-' "FSTDAY" date Eerste operationele dag van een
herhaald vluchtplan. Dit wordt
gebruikt om de feitelijke eerste dag
te geven vanaf welke vluchtplannen
zullen worden gegenereerd vanaf
een RPL (zie valfrom-veld) of de
eerste dag waarop een amendement
op een RPL van krachtwordt .
furthrte b '-' "FURTHRTE" {LIM_CHAR} De verdere routebepaling van een
vlucht. Voor gebruik binnen
berichten die geschatte gegevens
bevatten om de verdere routebepa-
ling van de vluchtaan t e geven
volgend op het geschatte punt. Dit
kan alleen hetvolgende punt
bevatten of de complete verdere
routebepaling tot aan de bestem-
ming.
geo c '-' "GEO" geoid lattd longtd Punt op een route gedefinieerd door
breedtegraad en lengtegraad en
gegeven in hetvlucht plan als
GEOxx (waarbij xx een volg-
nummer is).
ifp b '-' "IFP" 1{ALPHA} Aanduiding van bekende fouten
binnen een FPL.
ifpdlistc '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Lijstmetcomplet e IFPD's die
overeen komen metde dat abase-
sleutel die is opgegeven in een
query-bericht.
Bevateen lijstmetvolledige infor-
matie voor elke individuele vlucht
die overeenkomtmetde opgegeven
query-sleutels.
ifpdslistc '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Lijstmetifpdsum die overeen-
komen met de databasesleutel die
is opgegeven in een query-bericht.
Bevat een lijst met samengevatte
informatie voor elke individuele
vluchtdie overeenkomtmetde
opgegeven query-sleutels.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8Een unieke vluchtplanidentificatie,
toegewezen door de IFPS.
ifpsmod b '-' "IFPSMOD" fieldid modifind Een aanduiding door de IFPS van
de velden die zijn gewijzigd en de
aard van de wijziging.2000R2082 — NL — 15.06.2002 — 001.001 — 110
▼B
ADEXP
primair
veldType Syntaxis Semantiek
ifpuresp b '-' "IFPURESP" ifpuid Identificatie van de IFPU die
verantwoordelijk is voor een query.
Deze dientde query t e verwerken
en te beantwoorden.
ignore c '-' “BEGIN” "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
"END" "IGNORE"Aanduiding van omstandigheden
die zijn „genegeerd” of overge-
slagen bij de verwerking van het
betreffende bericht. Een „gene-
geerde” omstandigheid kan beperkt
zijn tot een specifiek gedeelte van
de route beperkt door de gegeven
routepunten. Een omstandigheid
kan bijvoorbeeld een tijdsbeperking
zijn (routetoegangsomstandigheid),
een vluchtniveaubeperking of een
TOS-overtreding.
iobd b '-' "IOBD" date De „eerste” Off Block Date — de
„Off-Block Date” zoals gegeven in
de FPL en bijgewerktdoor bij het
vluchtplan behorende berichten
(DLA, CHG etc.). Dit is de refe-
rentiedatum die wordt gebruikt om
toegang te krijgen tot het vlucht-
plan in de database en is de enige
„Off-Block Date” die bekend is bij
de betreffende ATS-eenheden.
Opmerking: de IOBD wordtniet
beïnvloed door wijzigingen die
worden aangevraagd of medege-
deeld door de uitwisseling van
ATFM-berichten.
iobt b '-' "IOBT" timehhmm De „eerste” Off Block Time — de
„Off-Block Time” zoals gegeven in
de FPL en bijgewerktdoor bij het
vluchtplan behorende berichten
(DLA, CHG etc.). Dit is de refe-
rentietijd die wordt gebruikt om
toegang te krijgen tot het vlucht-
plan in de database en is de enige
„Off-Block Time” die bekend is bij
de betreffende ATS-eenheden.
Opmerking: de IOBT wordtniet
beïnvloed door wijzigingen die
worden aangevraagd of medege-
deeld door de uitwisseling van
ATFM-berichten.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Lijst van Active Conditional
Routes [actieve voorwaardelijke
routes].
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Lijstvan Act ive Temporary Segre-
gated Areas [actieve tijdelijk afge-
scheiden gebieden].
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Lijstvan Closed ATS Rout es
[gesloten ATS-routes].
lfir c '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Lijstvan FIR's, metinbegrip van
de naam van de regio gevolgd door
ofwel de lijstvan Available Condi-
tional Routes of de lijsten met
Available Conditional Routes,
Closed ATS Routes, Active
Temporary Segregated Areas,
Reduced Airspace Restrictions en
Reduced Co-ordination Airspaces.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Lijstvan Reduced Airspace
Restrictions [gereduceerde lucht-
ruimbeperkingen].2000R2082 — NL — 15.06.2002 — 001.001 — 111
▼B
ADEXP
primair
veldType Syntaxis Semantiek
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Lijstvan Reduced Co-ordinat ion
Areas [gereduceerde coördinatiege-
bieden].
lstday b '-' "LSTDAY" date Laatste operationele dag voor een
herhaald vluchtplan. Dit wordt
gebruikt om de feitelijke laatste
dag te geven waarop vluchtplannen
worden gegenereerd vanaf een RPL
(zie valuntil-veld) of de laatste dag
waarop een amendementop een
RPL van krachtis
=> Dient een datum te zijn tussen
VALFROM en VALUNTIL.
mach b '-' "MACH" machnumber [ point] Mach-nummer, in honderdst en van
een eenheid en facultatief het punt
waarop de wijziging wordtaange-
vraagd.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimeDe geldigheidsperiode van een
bericht, inclusief de gegeven tijden.
minlineup b '-' "MINLINEUP" timehhmm De minimumtijd die voor een
vluchtbenodigd is, die zichzelf
gereed heeftverklaard om t e
vertrekken, om van de huidige
wachtpositie in de lucht te komen.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Aantal aanpassingen dat noodzake-
lijk was om een oorspronkelijk
berichtt e corrigeren.
msgref c '-' "MSGREF" sender recvr
seqnumReferentiegegevens voor bijbeho-
rende, eerder verzonden berichten.
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Bevat een samenvatting van een
bericht.
Opmerking: moeteen of meer* van
de velden arcid, adep, ades, eobtof
orgn bevatten, maar zonder herha-
ling.
* een of meer van de velden in het
ontvangen bericht kunnen
ontbreken of verdraaid zijn.
msgtxt b '-' "MSGTXT" icaomsg Bevat een compleet ICAO-bericht.
msgtyp b '-' "MSGTYP" titleid Bevat de titel van het bericht
waarnaar wordtverwezen of dat
wordtgekopieerd.Kan elke geldige ADEXP-bericht-
titel zijn (zie Bijlage B).
nav b '-' "NAV" text20 Belangrijke navigatieapparatuur, als
ICAO-veld 18 NAV/.
nbarc b '-' "NBARC" 1{ DIGIT }2 Aantal vliegtuigen indien meer dan
een.
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Aantal vluchtplangegevens dat
overeenkomtmeteen query.
Dient tussen 0 en 999 te liggen.
newctot b '-' "NEWCTOT" timehhmm Een nieuwe Calculated Take-Off
Time, zoals bijgewerktdoor TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmEen nieuwe tijd waarop een tijds-
periode eindigt.
neweobd b '-' "NEWEOBD" date Een nieuwe Estimated Off-Block
Date.
neweobt b '-' "NEWEOBT" timehhmm Een nieuwe Estimated Off-Block
Time.
newptot b '-' "NEWPTOT" timehhmm Een nieuwe Provisional Take-Off
Time.2000R2082 — NL — 15.06.2002 — 001.001 — 112
▼B
ADEXP
primair
veldType Syntaxis Semantiek
newrte b '-' "NEWRTE" { LIM_CHAR } Een nieuwe route tussen dezelfde
luchthavens van vertrek en
aankomstals in hetoorspronkelijke
bericht.
newstart-
timeb -' "NEWSTARTTIME" day !
timehhmmEen nieuwe tijd waarop een tijds-
periode begint.
oldmsg b '-' "OLDMSG" { CHARACTER } Een compleetoorspronkelijke
bericht, exact (en in dezelfde struc-
tuur) als waarin het werd
ontvangen.
opr b '-' "OPR" 1 { LIM_CHAR } Naam van de maatschappij die of
hetagent schap datde vlucht
uitvoert, als ICAO-veld 18 element
OPR/.
orgmsg b '-' "ORGMSG" titleid De ADEXP-titel van een foutief
bericht, zoals het door TACT is
ontvangen.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Hetadres van de indiener van een
bericht.
orgnid b '-' "ORGNID" originatorid De aanduiding van een geadres-
seerde die een berichtheeftopge-
steld.
orgrte b '-' "ORGRTE" { LIM_CHAR } Oorspronkelijke route tussen de
luchthavens van vertrek en
aankomst.
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Informatie met betrekking tot de
indiener van een bericht. Kan het
gebruikte type netwerk omvatten ofhetbet reffende adres of beide.
origindt b '-' "ORIGINDT" datetime Datum en tijd van ontvangst van
oorspronkelijk berichtdoor de
IFPS.
Opmerking: ditis nietde t ijd
waarop hetberichtwerd ingediend.
Structuur is JJMMDDUUMM.
part c '-' "PART" num lastnum Identificatie van het deel van het
berichtdatwordtgeïdent ificeerd
door de titel, tijd van indiening en
geldigheidsperiode.
per b '-' "PER" text20 Vliegtuigprestatiegegevens, als
ICAO-veld 18 PER/.
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]De positie van een vliegtuig als
ofwel een puntof een lucht haven
met facultatieve informatie over
tijd en vluchtniveau.
prevarcid b '-' "PREVARCID" aircraftid Het vorige callsign dat werd
gebruikt.
prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4Door de vluchtgebruikt e SSR-
modus en -code onmiddellijk voor-
afgaand aan de SSR-modus en -
code gegeven in veld „-
SSRCODE”.
propfl c '-' "PROPFL" tfl [sfl] Een vluchtniveau voorgesteld door
een accepterende eenheid voor de
overdrachtvan een vlucht .
ptot b '-' "PTOT" timehhmm Provisional Take-Off Time. Voor-
lopige referentietijd voor een
ATFM-beurt.
qrorgn b '-' "QRORGN" originatorid Identificatie van de indiener van de
Query.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Naam van alternatieve luchtha-
ven(s) onderweg.2000R2082 — NL — 15.06.2002 — 001.001 — 113
▼B
ADEXP
primair
veldType Syntaxis Semantiek
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Veranderingssnelheid: de klim- of
daalsnelheid die aan een vliegtuig
is toegewezen, uitgedrukt in
honderden voeten per minuut.
=> Moet„C” zijn om een klim-
snelheid aan te duiden, of „D” om
een daalsnelheid aan te duiden,
gevolgd door een tweecijferig
nummer datde t oegewezen snel-
heid in honderden voeten per
minuut aangeeft. Als alternatief kan
de aanduiding „ZZZ” worden
gebruiktom aan t e geven dater
geen toegewezen klim- of daalsnel-
heid bestaat.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Lijstmett ijdsperioden en hun
respectievelijke doorstroomsnel-
heden voor een ATFM-omstandig-
heid.
reason b '-' "REASON" 4{ALPHA}12 Reden voor ofwel afwijzing van
een berichtof annulering van een
beurtdoor TACT.
Informatie ter ondersteuning van
hetberichtafhankelijk van de
context daarvan.
ref c '-' "REF" refid ptid brng distnc Punt op een route dat is gedefini-
eerd in termen van magnetische
positie en afstand vanaf een ander
punten datde aanduiding REFxx
krijgt.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumReferentiegegevens voor bericht
datwordtverzonden.
reg b '-' "REG" 1{ LIM_CHAR }7 Registratiemarkeringen, als ICAO-
veld 18 REG/.
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Referentielocatie voor een ATFM-
regeling.
regul b '-' "REGUL" regulid Identificatie van een regeling met
betrekking tot een vlucht.
rejctot b '-' "REJCTOT" timehhmm Rejected Calculated Take-Off Time
[afgewezen berekende opstijgtijd]:
negatief antwoord op een Slot
Improvement Proposal [voorstel tot
verbetering van beurt].
release b '-' "RELEASE" 1{ALPHA}1 Een aanduiding datde vluchtdoor
de overdragende verkeersleider is
vrijgegeven aan de ontvangende
verkeersleider.
C = vrijgegeven voor klimmen
D = vrijgegeven voor dalen
T = vrijgegeven voor bochten
F = vrijgegeven voor alle acties
rename c '-' "RENAME" renid ptid Aanduiding van een tijdelijke,
nieuwe naam gegeven aan een
„belangrijk punt” dat meer dan
eenmaal in de routebeschrijving
voorkomt teneinde verwarring te
voorkomen. Deze tijdelijke naam
wordtalleen t oegepastvanwege de
duidelijkheid in de weergave van
de route en impliceert geen feite-
lijke wijziging van de echte
aanduiding van hetpunt .
respby b '-' "RESPBY" timehhmm Respond By: tijdstip waarop een
antwoord op een Slot Improvement
Proposal dient plaats te vinden.2000R2082 — NL — 15.06.2002 — 001.001 — 114
▼B
ADEXP
primair
veldType Syntaxis Semantiek
rfl b '-' "RFL" flightlevel [point] Aangevraagd vluchtniveau (in
vluchtniveaunummer, tientallen
meters of honderden voeten) en
facultatief het punt waarop een
wijziging van RFL is vereist.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Aanduiding van een Replacement
FlightPlan (RFP).
Moet„Q” zijn, gevolgd door een
cijfer (1 - 9).
rfpdlistc '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Lijstmetcomplet e RFPD's die
overeenkomen metde dat abase-
sleutels die in een Query zijn
opgegeven.
rfpdslistc '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Lijstmetrfpdsum (RFPD samen-
gevatte informatie) die overeen-
komt met de databasesleutels die in
een Query zijn opgegeven.
rif b '-' "RIF" 4{LIM_CHAR} Herziene route onderworpen aan
vrijgave tijdens de vlucht en eindi-
gend metde ICAO-aanduiding van
de herziene luchthaven van
bestemming.
rmk b '-' "RMK" 1{ LIM_CHAR } Opmerkingen in gewone taal, als
ICAO-veld 18 RMK/.
route b '-' "ROUTE" {LIM_CHAR} Complete ICAO-veld 15 informatie
metsnelheid, RFL en rout e (over-
eenkomstig de syntaxis in Ref. 4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlstflblockBeschrijving van een verkeers-
stroom die dient te worden omge-
leid.
rrteref b '-' "RRTEREF" rrteid Omleidingreferentie.rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockBeschrijving van een verkeers-
stroom waarnaar verkeer dient te
worden omgeleid.
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Lijst met routepunten. Kan ook een
luchthavenidentificatie bevatten.
rvr b '-' "RVR" 1{ DIGIT }3 Runway Visual Range (RVR).
Operationele minima als speciale
meteorologische omstandigheden
bestaan. Uitgedrukt in meters.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Lijstmett ijdsperioden en hun
toepasselijke RVR-limieten.
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitDe tijdsperiode waarbinnen de
geleverde RVR-limietvan t oepas-
sing is.
sector b '-' "SECTOR" 1{ ALPHANUM }8 Identificatie van een ATC-sector.
sel b '-' "SEL" 4{ ALPHA }5 SELCAL-code als ICAO-veld 18
element„SEL/”.
sendto c '-' "BEGIN" "SENDTO" {unit} '-'
"END" "SENDTO"Lijst met luchtvaarteenheden
waaraan een berichtdientt e
worden gezonden.
seqptb '-' "SEQPT" ssrequipment Bewakingsapparat uur, als ICAO-
veld 10.
sid b '-' "SID" point! 1{DIGIT}1 !
0{ALPHA}1Aanduiding van een Standard
Instrument Departure procedure.
speed b '-' "SPEED" spd [ point] Werkelijke lucht snelheid (in kilo-
meters per uur of knopen) en
facultatief het punt waarop een
wijziging van luchtsnelheid wordt
aangevraagd.2000R2082 — NL — 15.06.2002 — 001.001 — 115
▼B
ADEXP
primair
veldType Syntaxis Semantiek
spla b '-' "SPLA" 1{ LIM_CHAR }50 Kleurmarkeringen op vliegtuig, als
ICAO-veld 19 element„A/”.
spladdr c '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Contactgegevens, waar supplemen-
taire informatie over vluchtplan
kan worden verkregen.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Naam van bevelvoerende piloot, als
ICAO-veld 19 element„C/”.
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Totale capaciteit rubberboten, als
ICAO-veld 19 element„D/”.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Kleur reddingsboten, als ICAO-
veld 19 element„D/”.
spldcov b '-' "SPLDCOV" ('T' | 'F') Reddingsboten: aanduiding of ze
overdektzijn, als ICAO-veld 19
element„D/”.
T = True (=> „C” in ICAO)
F = False, nietoverdekt .
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Rubberboten: aantal, als ICAO-veld
19 element„D/”.
sple b '-' "SPLE" timehhmm_elapsed Resterende brandstof, als ICAO-
veld 19 element„E/”.
splj b '-' "SPLJ" lifejackets Reddingsvesten, als ICAO-veld 19
element„J/”.
spln b '-' "SPLN" 1{ LIM_CHAR } Alle andere overlevingsapparatuur
en nuttige opmerkingen, als ICAO-
veld 19 element„N/”.
splp b '-' "SPLP" 1{DIGIT}3 Personen aan boord, als ICAO-veld
19 element„P/”.
splr b '-' "SPLR" emergradio Noodradioapparatuur, als ICAO-
veld 19 element„R/”.
spls b '-' "SPLS" survivaleqptOverlevingsapparat uur, als ICAO-
veld 19 element„S/”.
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Aanduiding van de gegevensbron.
Inhoud afhankelijk van hetveld
TITLE.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Ofwel;
- SSR-modus en -code, als ICAO-
veld 7 elementen b en c.
of
- de letters „REQ”, wat betekent
datde code is aangevraagd.
star b '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Aanduiding van een standaard
aankomstprocedure.
starttime b '-' "STARTTIME" day !
timehhmmTijd waarop een tijdsperiode
begint.
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Aanduiding in de vliegroute van
een periode van „speciale activi-
teit” als het vliegtuig voor de
aangegeven tijdsduur „blijft” in het
gebied gedefinieerd door de
gegeven punten en/of luchthavens,
d.w.z. voor training, brandstof bijt-
anken in de lucht, fotografische
missie etc.
Opmerking: de volgorde waarin de
punten en/of luchthavens zijn
gegeven is belangrijk.
stayinfo c '-' "STAYINFO" stayident remark Informatie met betrekking tot het
type activiteit (training, fotografi-
sche missie etc.) dat dient te
worden uitgevoerd tijdens een
„blijf” periode op de route van een
vlucht.2000R2082 — NL — 15.06.2002 — 001.001 — 116
▼B
ADEXP
primair
veldType Syntaxis Semantiek
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Reden voor speciale behandeling,
als ICAO-veld 18 STS/. Kan
„PROTECTED” zijn om voorzich-
tige behandeling aan te geven of
een van de erkende labels EMER,
HOSP etc. of vrije tekst.
taxitime b '-' "TAXITIME" timehhmm Het verschil in tijd tussen de „Off
Blocks Time” en de „Take-Off
Time”. Afhankelijk van de context
kunnen de tijden waarnaar wordt
verwezen feitelijke of geschatte
tijden zijn.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Aanduiding van een „verkeersvo-
lume”.
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockBeschrijving van een verkeersvo-
lume.
title b '-' "TITLE" titleid Berichttitel.
ttleet b '-' "TTLEET" timehhmm_elapsed Totale geschatte verlopen tijd in
uren en minuten.
typz b '-' "TYPZ" text20 Type vliegtuig als geen ICAO-code
bestaat.
unit c '-' "UNIT" unitid [addrinfo] Informatie met betrekking tot een
„luchtvaarteenheid” d.w.z. een
ATC-eenheid, een luchtvaartmaat-
schappij of indiener van een
vluchtplan. Bevat de identificatie
van de eenheid en facultatief
adresgegevens.
valfrom b '-' "VALFROM" date Eerste datum van waaraf de vlucht
gepland is om te functioneren (in
jaar, maand en dag).
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Bij gebruik als een databasesleutel
in een query kunnen voor de eerste
dag van waaraf hetvlucht schema
gepland is om te functioneren
jokers worden gebruikt.
Dient een geldige datum te zijn of
een combinatie van een geldige
datum en joker-tekens.
valfromold b '-' "VALFROMOLD" date De „vorige”„valfrom” datum.
Gebruikt als een databasesleutel.
Als de begindatum voor de geldig-
heid dientt e worden geamendeerd
wordtde nieuwe waarde gegeven
in „VALFROM”.
validitydate b '-' "VALIDITYDATE" date Datum van geldigheid.
valuntil b '-' "VALUNTIL" date Laatste datum van waaraf de vlucht
gepland is om te functioneren (in
jaar, maand en dag).
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Bij gebruik als een databasesleutel
in een query kunnen voor de laatste
datum van waaraf de vlucht
gepland is om te functioneren
jokers worden gebruikt.
Dient een geldig teken te zijn of
een combinatie van een geldige
datum en joker-tekens.
valuntilold b '-' "VALUNTILOLD" date De „vorige”„valuntil” datum.
Gebruikt als een databasesleutel.
Als de einddatum van de geldig-
heid dientt e worden geamendeerd
wordtde nieuwe waarde gegeven
in „VALUNTIL”.2000R2082 — NL — 15.06.2002 — 001.001 — 117
▼B
ADEXP
primair
veldType Syntaxis Semantiek
wktrc b '-' "WKTRC" waketurbcat Volgturbulentiecategorie.
A.4.ADEXP-subvelden
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
addrinfo c '-' "ADDRINFO"
networktype facAdresinformatie unit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'De aanduiding van
een luchthaven. Kan
de ICAO-locatie-indi-
cator bevatten of de
tekens „ZZZZ” als
geen locatie-indicator
is toegewezen.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Beschrijving van het
geheel of een
gedeelte van een
ATS-route tijdens een
gespecificeerde
periode.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit[remark]Beschrijving van het
geheel of een
gedeelte van een
luchtruim gedurende
een gespecificeerde
periode.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Duidteen lucht ruim
aan anders dan een
ATS-route.entrydata airspace
brng b '-' "BRNG" refbea-
ringPositie van een punt
vanaf een navigatie-
hulpmiddel in
magnetische graden.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Type voorwaarde of
beperking, bijv. TOS,
FL-beperking.ignore
crfl1 b '-' "CRFL1" flight-
levelDe onderste limiet
van de vluchtniveau-
band waarbinnen een
klim op kruissnelheid
wordtaangevraagd.crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")De bovenste limiet
van de vluchtniveau-
band waarbinnen een
klim op kruissnelheid
wordtaangevraagd.
„PLUS” als de
bovenste limiet niet
bekend is.crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberHetMach-Nr. dat
gedurende een klim
op kruissnelheid
wordtaangehouden.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd De snelheid die
tijdens een klim op
kruissnelheid dientt e
worden aangehouden.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Calculated Time
Over a point[bere-
kende tijd boven een
punt].ad
positionpt2000R2082 — NL — 15.06.2002 — 001.001 — 118
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
distnc b '-' "DISTNC" 1{
DIGIT }3Afstand van een punt
vanaf een navigatie-
hulpmiddel in
zeemijlen.
Dientuit1 t ot3
cijfers te bestaan,
mogelijk metvoor-
loopnullen.ref
efl b '-' "EFL" flightlevel Geschat vluchtni-
veau.Gereser-
veerd voor
toekomstig
gebruik.
endreg b '-' "ENDREG" day!ti-
mehhmmDe tijd waarop een
ATFM-regeling
eindigt.exccond
regulation
eqptb '-' "EQPT" eqpt code !
'/' ! eqptstatusCode waarmee de
capaciteit van appa-
ratuur wordt aange-
geven, gevolgd door
een statuswaarde
waarmee de huidige
status van de capaci-
teit wordt aange-
geven.eqcst
eto b '-' "ETO" date !
timehhmm ! secondsEstimated Time Over
[geschatte tijd boven]
een puntin jaar,
maand, dagen, uren,
minuten en seconden.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc regre-
ason startreg endreg
[flblock] [rvrlimit]
[remark]Een „uitzonderlijke
omstandigheid” die
in de context van
ATFM is ontstaan,
bijv. mistop een
luchthaven.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Adresgegevens. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALPHA
}7Duidteen FIR of
UIR aan.lfir
fl b '-' " FL" flightlevel Een algemeen vlucht-
niveauveld.
Kan een „SFL”,
„EFL”, „CFL”,
„RFL”, etc. zijn,
afhankelijk van de
context.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt
flblock c '-' "FLBLOCK" fl fl Een vluchtniveaublok
dateen lucht ruim
verticaal definieert,
metinbegrip van de
gegeven vluchtni-
veaus. Een blok dat
is gedefinieerd als
onder of boven een
vluchtniveau zal
respectievelijk
worden uitgedrukt als
van vluchtniveau 000
tot het gespecifi-
ceerde niveau of als
van hetgespecifi-
ceerde niveau tot
vluchtniveau 999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond2000R2082 — NL — 15.06.2002 — 001.001 — 119
▼M1
▼B
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleBeschrijving van een
„stroom” met het
brongebied, faculta-
tief de routes of
punten waarover
dientt e worden
gevlogen vanaf het
brongebied, het
bestemmingsgebied
en facultatief de
routes of punten
waarover dientt e
worden gevolgen
naar hetbest em-
mingsgebied.flowlst
flowlstc '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Lijstvan verkeers-
stromen.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7De „snelheid” die
door een ATFM-
regeling wordtopge-
legd.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Een aanduiding van
de „rol” van een
stroom.
EX = uitgesloten
IE = ingesloten
uitgezonderd
EM = uitgesloten
IN = ingeslotenflow
from b '-' "FROM" day!ti-
mehhmmDe tijd van waaraf
een tijdsperiode
begint.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15Een positie van
waaraf een route, een
deel van een route,
een „pad” of een
stroom begint.
Kan een regio zijn,
een luchthaven of een
belangrijk punt.flow
geoid b '-' "GEOID" geoname Aanduiding van een
geografisch punt
bestaande uit „GEO”gevolgd door een
volgnummer
(voorbeeld:
„GEO12”).geo
ifpdlong c '-' "BEGIN" "IFPD-
LONG" adexpmsg '-'
"END" "IFPDLONG"Complete informatie
met betrekking tot
een individueel
vluchtplan.ifpdlist
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobtorgnSamengevatte infor-
matie met betrekking
tot een individueel
vluchtplan. Het bevat
de velden arcid, adep,
ades, eobten orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Een driecijferig
nummer datheteinde
van een reeks
aangeeft.
lattd b '-' "LATTD" latitude-
long ! latitudesideBreedtegraad in
graden, minuten,
seconden en richting
(Noord of Zuid).eetlat
geo2000R2082 — NL — 15.06.2002 — 001.001 — 120
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
longtd b '-' "LONGTD" long-
itudelong ! longitude-
sideLengtegraad in
graden, minuten,
seconden en richting
(Oostof West ).eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALPHANUM}10Aanduiding van het
type netwerk dat
wordtgebruiktvoor
uitwisseling van een
bericht.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Een driecijferig
nummer.extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7Het„wacht percen-
tage”, gebruikt voor
ATFM-doeleinden.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgBevateen compleet
ADEXP-berichtnadat
hetis verwerkt .adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgBevateen compleet
ADEXP-berichtvoor-
afgaand aan de
verwerking ervan,
d.w.z. zoals hetwas
ontvangen.adexptxt
ptc '-' "PT" pt id [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Puntop een rout e.
=> Bevateen punt i-
dentificatie en facul-
tatief:
- een vluchtniveau of
vluchtniveaublok,
- een supplementair
vluchtniveau,
- een of meer tijdre-
ferenties,
- een klim op kruis-
snelheid
- een routeaanduiding
- een aanduiding van
een periode van
„speciale activiteit”,
d.w.z. datde vlucht
gedurende een tijds-
periode in hetgebied
„blijft”
Wijziging in:
- RFL, vluchtregels,
snelheid/Mach-Nr.rtepts
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Aanduiding in de
route van een vlucht
van een klim op
kruissnelheid. Geeft
de snelheid of het
mach-nr. gevolgd
door de twee niveaus
die de vluchtniveau-
band aangeven die
tijdens de klim dient
te worden gebruikt.
Hett weede niveau
kan „PLUS” zijn als
hetbovenst e niveau
onbekend is.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Een aanduiding van
de vluchtregels die
van toepassing zijn
op hetbet reffende
punt.entrydata2000R2082 — NL — 15.06.2002 — 001.001 — 121
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
ptid b '-' "PTID" point Puntidentificatie,
ofwel gecodeerde
aanduiding of een
kunstmatig gegeven
naam (GEOxx,
REFxx of RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberMach-nummer, in
honderdsten, geasso-
cieerd meteen punt
op de route.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Een aanduiding van
de „militaire” vlucht-
regels die van
toepassing zijn op het
betreffende punt.entrydata
ptrfl b '-' "PTRFL" flight-
levelAangevraagd vlucht-
niveau, geassocieerd
meteen puntop de
route.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}De vliegroute die
volgtop hetaange-
geven punt. Kan de
complete route zijn
naar de luchthaven
van bestemming of
eenvoudig hetrout e-
bepalingselement
naar hetvolgende
punt.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgAanduiding van een
wijziging in ofwel de
„vluchtregels” (VFR/
IFR) of het„t ype
vlucht” (OAT/GAT)
of beide en geassoci-
eerd meteen puntop
de route.ad pt
ptspeed b '-' "PTSPEED" spd Werkelijke luchtsnel-
heid (in kilometers
per uur of knopen)
geassocieerd meteenpuntop de rout e.ad
entrydatapt
ptstay b '-' "PTSTAY" stay-
identifier timehhmmAanduiding binnen
de ingediende vlucht-
route van een periode
van „speciale activi-
teit” als het vliegtuig
voor de gegeven
tijdsduur in het gede-
finieerde gebied
„blijft”, d.w.z. voor
training, brandstof
bijtanken in de lucht
etc.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penrateEen tijdsperiode
gedurende welke de
gegeven doorstroom-
snelheden van
toepassing zijn op
een ATFM-regeling.ratepdlst regcond
recvr b '-' "RECVR" fac De ontvanger van het
berichtwaarnaar
wordtverwezen.msgref
refdata2000R2082 — NL — 15.06.2002 — 001.001 — 122
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
refatsrte b '-' "REFATSRTE"
atsroute point[country] point
[country]ATS-routeaanduiding
en identificaties vaneerste en laatste
punten. De afge-
beelde punten kunnen
ICAO-identificaties
zijn of kunstmatig
gegeven GEOxx-,
RENxx- of REFxx-
punten. De identifi-
catie van het land
waarbinnen hetpunt
zich bevindtkan
facultatief worden
opgenomen.
De eindpunten dienen
consistent te zijn met
de route-informatie.airroute
refid b '-' "REFID" refname Identificatie van een
referentiepunt samen-
gesteld uit „REF”
gevolgd door een
volgnummer (voor-
beeld: „REF02”).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Referentielocatie van
een ATFM-regeling.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Lijstmett ijdspe-
rioden en hun respec-
tievelijke door-
stroomsnelheden voor
een bepaalde rege-
ling.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Beschrijving van een
ATFM-regulering.regulation
regid b '-' "REGID" regulid Aanduiding van een
doorstroombeheer
„Regeling”.regulation
reglistc '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Lijstmet„Rege-
lingen” ten behoeve
van doorstroombe-
heer.fmplist
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Een referentie-
nummer voor een
ATFM „Regeling”.
Bevateen unieke
referentie gevolgd
door een geldigheids-
aanduiding.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12De reden voor een
ATFM-regeling.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]Een „Regeling”
opgelegd ten behoeve
van doorstroombe-
heer.reglist
remark b '-' "REMARK"
1{LIM_CHAR}Een opmerking over
hetonderdeel, de
beschrijving waarvan
ditveld een onder-
deel is.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identificatie gegeven
aan een puntdat
wordtherhaald in de
routebeschrijving.rename2000R2082 — NL — 15.06.2002 — 001.001 — 123
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
respunitb '-' "RESPUNIT"
12{ALPHA}12De verantwoordelijke
ATC-eenheid.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Complete informatie
met betrekking tot
een herhaald vlucht-
plan.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobtorgndays valfrom valuntilSamenvatting van de
informatie metbetrekking tot een
herhaald vluchtplan.
Hetbevatde velden
arcid, adep, ades,
eobt, orgn, days,
valfrom en valuntil.rfpdslist
rvrlimitb '-' "RVRLIMIT"
3{DIGIT}3Runway Visual
Range [visueel bereik
start-/landingsbaan]:
operationele minima
bij speciale meteoro-
logische omstandig-
heden. Uitgedrukt in
meters.rvrperiod exccond
sender b '-' "SENDER" fac De verzender van het
berichtwaarnaar
wordtverwezen.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Hetserienummer van
hetberichtdatwordt
verzonden (een drie-
cijferig nummer dat
uniek is voor de
combinatie
verzender/ontvanger).msgref
refdata
sfl b '-' SFL flightlevel !
('A'|'B')Supplementair
vluchtniveau. Het
vluchtniveau waarop
of waarboven, of
waarop of waaronder
een vluchtis of wordt
gecoördineerd om
een puntt e passeren.
Bestaat uit een
vluchtniveaunummer
en een passeervoor-
waarde (ofwel „A”als hetvliegt uig het
puntop of boven het
niveau zal passeren,
of „B” als hetvlieg-
tuig het punt op of
onder hetniveau zal
passeren).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmDe tijd waarop een
ATFM-regeling van
krachtwordt .exccond
regulation
statid b '-' "STATID" coorsta-
tusidentDe indicator van de
coördinatiestatus van
een vlucht.cstat
statreason b '-' "STATREASON"
coorstatusreasonDe reden voor een
verandering in de
coördinatiestatus van
een vlucht.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentificatie van een
periode van „speciale
activiteit” of een
„blijf” binnen de
route van een vlucht.stay
stayinfo2000R2082 — NL — 15.06.2002 — 001.001 — 124
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
sto b '-' "STO" timehhmm
! secondsEen algemeen tijd-
veld datde t ijd kan
bevatten voor een
puntof voor een
luchthaven. Afhanke-
lijk van de context
kan de tijd een
geschatte, berekende
of feitelijke tijd zijn.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Transfer Flight Level.
Hetvlucht niveau
waarop een vluchtis
of wordtgecoördi-
neerd om een puntt e
passeren (vluchtnive-
aunummer), indien in
horizontale vlucht, of
hetvrijgegeven
niveau waar de
vluchtnaart oe gaat
indien klimmend of
dalend bij hetgrens-
punt.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identificatie van een
„verkeersvolume”.rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Een tijdsaanduiding.
Kan een feitelijke tijd
zijn of een tijdspe-
riode, afhankelijk van
de berichtcontext.stay
to b '-' "TO" timehhmm „Time Over/Off”.
Een algemeen tijd-
veld datde t ijd voor
een puntof voor een
luchthaven kan
bevatten. Afhankelijk
van de context kan de
tijd een geschatte,
berekende of feite-
lijke tijd zijn.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15Een positie tot
waartoe een route,
een gedeelte van een
route, een „pad” of
een stroom zich
uitstrekt.
Kan een regio, een
luchthaven of een
belangrijk puntzijn.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Identificatie van een
luchtvaarteenheid,
d.w.z. een ATC-
eenheid, luchtvaart-
maatschappij of
indiener van een
vluchtplan.unit
until b '-' "UNTIL" day!ti-
mehhmmDe tijd waarop een
tijdsperiode eindigt.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeEen geldigheidspe-
riode, inclusief de
gegeven tijden.airroute
airspace2000R2082 — NL — 15.06.2002 — 001.001 — 125
▼B
Subveld Type Syntaxis SemantiekGebruikt in
primair
veldGebruikt in
subveld
via1 b '-' "VIA1" 1
{ALPHANUM} 15Een punt, een ATS-
route of een lucht-
ruim datofwel op de
vluchtroute ligt of
daarop dientt e
liggen. Als hetnodig
is om er meer dan
een aan te geven
bevatditveld het
eerste van de reeks.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Een punt, een ATS-
route of een lucht-
ruim datofwel op de
vluchtroute ligt of
daarop dientt e
liggen. Als hetnodig
is om er meer dan
een aan te geven
bevatditveld het
tweede in de reeks.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Een punt, een ATS-
route of een lucht-
ruim datofwel op de
vluchtroute ligt of
daarop dientt e
liggen. Als hetnodig
is om er meer dan
een aan te geven
bevatditveld het
derde in de reeks.flow
via4 b '-' "VIA4" 1
{ALPHANUM} 15Een punt, een ATS-
route of een lucht-
ruim datofwel op de
vluchtroute ligt of
daarop dientt e
liggen. Als hetnodig
is om er meer dan
een aan te geven
bevatditveld het
vierde in de reeks.flow2000R2082 — NL — 15.06.2002 — 001.001 — 126
▼B
BIJLAGE B (Normatief)
CENTRALE INDEX VAN ADEXP-BERICHTTITELS
Titel DefinitieBesproken in
Sectie
ABI Advance Boundary Information Message [voorafgaand
berichtmetgrensinformat ie]E.3
ACK Acknowledge Message [bevestigingsbericht] E.1
ACP Acceptance Message [acceptatiebericht] E.5
ACT Activation Message [activeringsbericht] E.3
AUP Airspace Use Plan Message [berichtmetplan voor gebruik
van luchtruim]E.4
BFD Basic Flight Data Message [bericht met basisvluchtgege-
vens]E.5
CDN Co-ordination Message [coördinatiebericht] E.3
CFD Change to Flight Data Message [bericht met wijziging in
vluchtgegevens]E.5
CNLCOND ATFM Exceptional Condition Cancellation Message
[bericht met annulering ATFM uitzonderlijke omstandig-
heid]E.2.3
CNLREG ATFM Regulation Cancellation Message [bericht met annu-
lering ATFM-regeling]E.2.3
COD SSR Code AssignmentMessage [berichtmett oewijzing
SSR-code]E.3
COF Change of Frequency Message [berichtmetwijziging van
frequentie]E.3
CRAM Conditional Route Availability Message [bericht met
beschikbaarheid voorwaardelijke route]E.4
DES De-Suspension Message [berichtmetannulering van
opschorting]E.2.2
ERR Error Message [foutbericht] E.2.2
EXCOND ATFM Exceptional Condition Notification Message [mede-
delingsbericht met ATFM uitzonderlijke omstandigheid]E.2.3
FCM Flight Confirmation Message [bericht met vluchtbevesti-
ging]E.2.2
FLS Flight Suspension Message [bericht met vluchtopschorting] E.2.2
FSA First System Activation Message [bericht met eerste
systeemactivering]E.2.3
HOP Hand-Over Proposal Message [berichtmetoverdracht svoor-
stel]E.3
IACH Individual ATC Modification Message [individueel ATC-
wijzigingsbericht]E.1
IAFP Individual ATC FlightPlan Proposal Message [individueel
bericht met ATC vluchtplanvoorstel]E.1
IAPL Individual ATC FlightPlan Message [individueel bericht
metATC vlucht plan]E.1
IARR Individual Arrival Message [individueel aankomstbericht] E.1
ICHG Individual Modification Message [individueel wijzigingsbe-
richt]E.1
ICNL Individual Cancellation Message [individueel annulerings-
bericht]E.1
IDEP Individual Departure Message [individueel vertrekbericht] E.1
IDLA Individual Delay Message [individueel vertragingsbericht] E.1
IFPL Individual FlightPlan Message [individueel vlucht planbe-
richt]E.1
INF Information Message [informatiebericht] E.32000R2082 — NL — 15.06.2002 — 001.001 — 127
▼B
Titel DefinitieBesproken in
Sectie
IRPL Individual Repetitive Flight Plan [individueel herhaald
vluchtplan]E.1
IRQS Individual RequestSupplement ary FlightPlan [individueel
verzoek supplementair vluchtplan]E.1
ISPL Individual Supplementary Flight Plan [individueel supple-
mentair vluchtplan]E.1
LAM Logical AcknowledgementMessage [logisch bevest igings-
bericht]E.3, E.5
LRM Logical Rejection Message [logisch afwijzingsbericht] E.3
MAC Message for Abrogation of Co-ordination [bericht voor
opheffing van coördinatie]E.3
MAN Manual Processing Pending Message [berichtdathandma-
tige verwerking wacht]E.1
MAS Manual Assumption of Communications Message [bericht
van handmatige overname van communicatie]E.3
MODCOND ATFM Exceptional Condition Modification Message
[bericht van wijziging uitzonderlijke ATMF-omstandigheid]E.2.3
MODREG ATFM Regulation Modification Message [bericht van wijzi-
ging van ATMF-regeling]E.2.3
MRA Mandatory Route Activation Message [bericht van
verplichte routeactivering]E.2.3
MRCNL Mandatory Route Cancellation Message [bericht van
verplichte routeannulering]E.2.3
MRMOD Mandatory Route Modification Message [bericht van
verplichte routewijziging]E.2.3
NEWREG New ATFM Regulation Notification Message [nieuw mede-
delingsberichtvan ATMF-regeling]E.2.3
NTA No Traffic Accepted Message [bericht dat geen verkeer
wordtgeaccept eerd]E.2.3
NTACNL No Traffic Accepted Cancellation Message [bericht dat niet
accepteren van verkeer is geannuleerd]E.2.3
NTAMOD No Traffic Accepted Modification Message [bericht dat niet
accepteren van verkeer wordt gewijzigd]E.2.3
OLRA Off-Load Route Activation Message [bericht van activering
aflaadroute]E.2.3
OLRCNL Off-Load Route Cancellation Message [bericht van annule-
ring aflaadroute]E.2.3
OLRMOD Off-Load Route Modification Message [bericht van wijzi-
ging aflaadroute]E.2.3
PAC Preliminary Activation Message [bericht van voorlopige
activering]E.3
RAP Referred Activate Proposal Message [bericht van doorver-
wezen activeringsvoorstel]E.3
RCHG Repetitive Flight Plan Data Modification Message [bericht
van wijziging herhaalde vluchtplangegevens]E.1
RCNL Repetitive Flight Plan Data Cancellation Message [bericht
van annulering herhaalde vluchtplangegevens]E.1
RDY Ready Message [berichtvan gereedheid] E.2.2
REJ Rejection Message [bericht van afwijzing] E.1
REV Revision Message [berichtvan herziening] E.3
RJC RejectCo-ordinat ion Message [berichtvan afwijzing
coördinatie]E.5
RJT Re-Routing Rejection Message [bericht van afwijzing
omleiding]E.2.2
ROF RequestOn Frequency Message [berichtmetvraag over
frequentie]E.32000R2082 — NL — 15.06.2002 — 001.001 — 128
▼B
Titel DefinitieBesproken in
Sectie
RRP Re-Routing Proposal Message [bericht met omleidingvoor-
stel]E.2.2
RRV Referred Revision Proposal Message [berichtmetdoorver-
wezen herzieningsvoorstel]E.3
SAM Slot Allocation Message [bericht met beurttoewijzing] E.2.2
SBY Stand-by Message [stand-by-bericht] E.3
SDM Supplementary Data Message [bericht met supplementaire
gegevens]E.3
SIP SlotImprovementProposal Message [berichtmetvoorst el
beurtverbetering]E.2.2
SLC SlotRequirementCancellat ion Message [berichtmetannu-
lering benodigde beurt]E.2.2
SMM SlotMissed Message [berichtdatbeurtwerd gemist ] E.2.2
SPA Slot Proposal Acceptance Message [bericht met acceptatie
beurtvoorstel]E.2.2
SRJ SlotProposal Reject ion Message [berichtmetafwijzing
beurtvoorstel]E.2.2
SRM SlotRevision Message [berichtmetherzien beurt ] E.2.2
SRR SlotRevision RequestMessage [berichtmetverzoek om
herzien beurt]E.2.2
TIM Transfer Initiation Message [bericht voor start overdracht] E.3
UUP Updated Airspace Use Plan Message [bericht met bijge-
werktplan lucht ruimgebruik]E.4
XAP Crossing Alternate Proposal Message [bericht met alterna-
tief passeervoorstel]E.5
XCM Crossing Cancellation Message [bericht met passeerannule-
ring]E.5
XIN Crossing Intention Notification Message [bericht met mede-
deling passeerintentie]E.5
XRQ Crossing RequestMessage [berichtmetpasseerverzoek] E.52000R2082 — NL — 15.06.2002 — 001.001 — 129
▼B
BIJLAGE C (Normatief)
CENTRALE INDEX VAN GERESERVEERDE BERICHTTITELS
C.1.Inleiding
Deze bijlage bevat een centrale index van gereserveerde berichttitels die
nog nietzijn gedefinieerd voor gebruik in ADEXP. Hun opname in deze
bijlage geeft aan dat ze ofwel zijn voorzien voor toekomstig gebruik of
datze reeds in gebruik zijn maar dathun gebruik beperktis t otlokale
systemen.
C.2.Doel
Het doel van het voorzien in een overzicht van titels die nog niet formeel
zijn aanvaard voor gebruik binnen deze ADEXP-norm is om, in zoverre
mogelijk, te voorkomen dat redundantie ontstaat als een nieuwe titel
nodig is voor een bepaald doel of dat een titel wordt gemaakt die reeds
in gebruik is binnen een lokaal systeem.
C.3.Gereserveerde berichttitels
Gereserveerde
titelBerichttypeGereserveerd
door
ACTARR Activation Message for an Arrival [activeringbericht
voor een aankomst]FRANKRIJK
ACTDEP Activation Message for a Departure [activeringsbericht
voor een vertrek]FRANKRIJK
ADMFPL ADMAR2000 FlightPlan Message [berichtvan
ADMAR2000 vluchtplan]DUITSLAND
ADMFPT ADMAR2000 FlightPlan Terminat ion Message
[berichtvan beëindiging ADMAR2000 vlucht plan]DUITSLAND
ADMFPU ADMAR2000 FlightPlan Updat e Message [berichtvan
bijwerken ADMAR2000 vluchtplan]DUITSLAND
ANM ATFM Notification Message [ATFM-mededelingsbe-
richt]CFMU
ANSWERCT Response Message [antwoordbericht] (Terminal Control
System)FRANKRIJK
ANSWM Response Message [antwoordbericht] (ODS) FRANKRIJK
ANSXFPLCT Response Message [antwoordbericht] FRANKRIJK
ATT Landing Message [landingsbericht] FRANKRIJK
BEGINPROC Begin Processing Message [berichtvan begin van
verwerking]FRANKRIJK
BEGPROC Verkeersleider Working Position Initialisation Proce-
dure Message [bericht van initialisatieprocedure
verkeersleider-werkplek] (ODS)FRANKRIJK
BEGPROCCT Verkeersleider Working Position Initialisation Message
[bericht van initialisatie verkeersleider-werkplek]
(Terminal Control System)FRANKRIJK
CDA Departure Clearance Message [bericht van vrijgave
voor vertrek] (ARINC 623)FRANKRIJK
CDAFTX Departure Clearance [vrijgave voor vertrek] (ARINC
620)FRANKRIJK
CHGDEP Modification message for a Departure flight [wijzi-
gingsbericht voor een vertrekkende vlucht]FRANKRIJK
CLD Departure Clearance [vrijgave voor vertrek] (ARINC
623)FRANKRIJK
CLDFTX Departure Clearance [vrijgave voor vertrek]
(ARINC620)FRANKRIJK
CNLARR Cancellation of an Arrival [annulering van aankomst] FRANKRIJK
CNLCOND Cancellation of Exceptional Condition [annulering van
uitzonderlijke omstandigheid]CFMU2000R2082 — NL — 15.06.2002 — 001.001 — 130
▼B
Gereserveerde
titelBerichttypeGereserveerd
door
CNLDEP Cancellation of a Departure [annulering van een
vertrek]FRANKRIJK
CNLREG Cancellation of an ATFM Regulation [annulering van
een ATFM-regeling]CFMU
CONFEND End Message to a change of Operational Configuration
[eindeberichtvoor een wijziging in operat ionele confi-
guratie]FRANKRIJK
CONFIDM Operational Configuration Message [bericht van opera-
tionele configuratie] (ODS)FRANKRIJK
CONFIDMCT Operational Configuration Message [bericht van opera-
tionele configuratie] (Terminal Control System)FRANKRIJK
DEC Take-Off Message [berichtvan opst ijgen] FRANKRIJK
DOUBM Duplication Flight Plan Message [bericht van duplicaat
vluchtplan]FRANKRIJK
DRT Modification of Destination Message [bericht van
wijziging van bestemming]FRANKRIJK
EATARR Update of Estimated Arrival Time Message [bericht
van bijwerken geschatte aankomsttijd]FRANKRIJK
ENDPROC Verkeersleider Working Position Initialisation Proce-
dure Last Message [laatste bericht initialisatieprocedure
verkeersleider-werkplek] (ODS)FRANKRIJK
ENDPROCCT Verkeersleider Working Position Initialisation Proce-
dure Last Message [laatste bericht initialisatieprocedure
verkeersleider-werkplek] (Terminal Control System)FRANKRIJK
EVLARR Pre-Activation Message for Arrival [pre-activeringsbe-
richtvoor aankomst ]FRANKRIJK
EVLDEP Pre-Activation Message for Departure [pre-activerings-
berichtvoor vert rek]FRANKRIJK
EXCOND Activation of an Exceptional Condition [activering van
een uitzonderlijke omstandigheid]CFMU
FICM Flight Data Creation Message [bericht van aanmaak
vluchtgegevens]FRANKRIJK
FLXVIVO „Flexible Track” Description Display Message
[„Flexible Track” beschrijving display-bericht]FRANKRIJK
FPCLOSE Flight Plan Data Close Message [bericht van sluiten
vluchtplangegevens] (ODS)FRANKRIJK
FPCLOSECT Flight Plan Data Close Message [bericht van sluiten
vluchtplangegevens] (Terminal Control System)FRANKRIJK
FPCLOSED Duplication of Flight Plan Data Close Message [bericht
van sluiten duplicaat van vluchtplangegevens] (ODS)FRANKRIJK
FPCRD Activation of Flight Plan Message [bericht van active-
ring van vluchtplan] (ODS)FRANKRIJK
FPCRDCT Activation of Flight Plan Message [bericht van active-
ring van vluchtplan] (Terminal Control System)FRANKRIJK
FPCRDD Duplication of Flight Plan Data Activation Message
[bericht van activering duplicaat van vluchtplangege-
vens] (ODS)FRANKRIJK
FPCRE Creation of Flight Plan Message [bericht van aanmaak
vluchtplan] (ODS)FRANKRIJK
FPCRECT Creation of Flight Plan Message [bericht van aanmaak
vluchtplan] (Terminal Control System)FRANKRIJK
FPINI Pre-Activation of Flight Plan Message [bericht van pre-
activering van vluchtplan] (ODS)FRANKRIJK
FPINICT Pre-Activation of Flight Plan Message [bericht van pre-
activering van vluchtplan] (Terminal Control System)FRANKRIJK
FPINID Duplication of Pre-Activation of Flight Plan Message
[bericht van duplicaat van pre-activering van vlucht-
plan]FRANKRIJK2000R2082 — NL — 15.06.2002 — 001.001 — 131
▼B
Gereserveerde
titelBerichttypeGereserveerd
door
FPNTF Pre-Activation of Flight Plan Message [bericht van pre-
activering van vluchtplan] (ODS)FRANKRIJK
FPNTFD Duplication of Pre-Activation of Flight Plan Message
[bericht van duplicaat van pre-activering van vlucht-
plan] (ODS)FRANKRIJK
FPRDU Flight Data Information Message for a Non-Concerned
Sector [bericht met vluchtgegevensinformatie voor een
niet-betrokken sector] (ODS)FRANKRIJK
FPRDUCT Flight Data Information Message for a non-concerned
Sector [bericht met vluchtgegevensinformatie voor een
niet-betrokken sector] (Terminal Control System)FRANKRIJK
FSM Departure Clearance System Message [bericht vrijgave-
systeem voor vertrek] (ARINC 623)FRANKRIJK
FSMFTX Departure Clearance System Message [bericht vrijgave-
systeem voor vertrek] (ARINC 620)FRANKRIJK
FSR FlightSuspension RequestMessage [berichtmet
verzoek om opschorting vlucht]CFMU
IACHD Individual ATC Modification Message [individueel
ATC-wijzigingsbericht]DUITSLAND
ICHGD Individual Modification Message [individueel wijzi-
gingsbericht]DUITSLAND
IDEPD Individual Departure Message [individueel vertrekbe-
richt]DUITSLAND
IDLAD Individual Delay Message [individueel vertragingsbe-
richt]DUITSLAND
IFPDQ Individual FlightPlan Dat a Query Message [bericht
metgegevens-query voor individueel vlucht plan]CFMU
IFPDQR Individual FlightPlan Dat a Query Reply Message
[berichtmetant woord op gegevens-query voor indivi-
dueel vluchtplan]CFMU
IFPDSQ Individual FlightPlan Dat a Summary Query Message
[bericht met gegevenssamenvatting-query voor indivi-
dueel vluchtplan]CFMU
IFPDSQR Individual FlightPlan Dat a Summary Query Reply
Message [bericht met antwoord op gegevenssamenvat-
ting-query voor individueel vluchtplan]CFMU
IFPLD Individual FlightPlan [individueel vlucht plan] DUITSLAND
INFOM Information Message [informatiebericht] FRANKRIJK
IRQS Individual Request for Supplementary Information
Message [berichtmetindividuele aanvraag voor supple-
mentaire informatie]CFMU
ISPL Individual Supplementary Flight Plan Message [bericht
met individueel supplementair vluchtplan]CFMU
LGR Flight Plan Message List [lijst met vluchtplanberichten] FRANKRIJK
LISTFP Flight Plan Message List [lijst met vluchtplanberichten]
(ODS)FRANKRIJK
LISTFPCT Flight Plan Message List [lijst met vluchtplanberichten]
(Terminal Control System)FRANKRIJK
LOGON Identification of Flight Plan Message [bericht met iden-
tificatie van vluchtplan]FRANKRIJK
MAJVIVO Daily Movements Message [bericht met dagelijkse
verplaatsingen]FRANKRIJK
MCOM Co-ordination Message [coördinatiebericht] FRANKRIJK
MODCOND Modification of an Exceptional Condition [wijziging
van een uitzonderlijke omstandigheid]CFMU
MODREG Modification of an ATFM Regulation [wijziging van
een ATFM-regeling]CFMU
MRA Activation of a Mandatory Route [activering van een
verplichte route]CFMU2000R2082 — NL — 15.06.2002 — 001.001 — 132
▼B
Gereserveerde
titelBerichttypeGereserveerd
door
MRCNL Cancellation of a Mandatory Route [annulering van een
verplichte route]CFMU
MRMOD Modification of a Mandatory Route [wijziging van een
verplichte route]CFMU
MRR Mandatory Re-Routing Message [bericht van verplichte
omleiding]CFMU
MVTVIVO Movements Information Message [bericht met infor-
matie over verplaatsingen]FRANKRIJK
NEWREG Activation of an ATFM Regulation [activering van een
ATFM-regeling]CFMU
NTA Activation of a „Not Allowed” Traffic Flow [activering
van een „niet toegestane” verkeersstroom]CFMU
NTACNL Cancellation of a „Not Allowed” Traffic Flow [annule-
ring van een „niet toegestane” verkeersstroomCFMU
NTAMOD Modification of a „Not Allowed” Traffic Flow [wijzi-
ging van een „niet toegestane” verkeersstroom]CFMU
OCLM Oceanic Clearance Message [berichtmetoceaanvrij-
gave]FRANKRIJK
OCLMD Duplication of Oceanic Clearance Message [duplicaat
van berichtmetocaanvrijgave]FRANKRIJK
OLRA Activation of an Off-Load Route [activering van een
aflaadroute]CFMU
OLRCNL Cancellation of an Off-Load Route [annulering van een
aflaadroute]CFMU
OLRMOD Modification of an Off-Load Route [wijziging van een
aflaadroute]CFMU
PAMAER Runway Application Message [bericht van toepassing
start/landingsbaan]FRANKRIJK
PAMARB „On-Stand” Confirmation Message [„On-Stand” beves-
tigingsbericht]FRANKRIJK
PAMARRANN Cancellation of Parking Allocation for an Arrival
[annulering van parkeertoewijzing voor een aankomst]FRANKRIJK
PAMARRCRE Allocation of Parking Position for an Arrival [toewij-
zing van parkeerpositie voor een aankomst]FRANKRIJK
PAMARRPST Modification of Parking Allocation for an Arrival
[wijziging van parkeertoewijzing voor een aankomst]FRANKRIJK
PAMDAPARB Parking Message for Arrival Aircraft[parkeerbericht
voor aankomend vliegtuig]FRANKRIJK
PAMDAPCRE Allocation of a Parking Position [toewijzing van een
parkeerpositie]FRANKRIJK
PAMDEPANN Cancellation of Parking Allocation for a Departure
[annulering van parkeertoewijzing voor een vertrek]FRANKRIJK
PAMDEPCRE Parking Allocation for a Departure [parkeertoewijzing
voor een vertrek]FRANKRIJK
PAMDEPPST Modification of Parking Allocation for a Departure
[wijziging van parkeertoewijzing voor een vertrek]FRANKRIJK
PAMDRB „Off-Stand” Confirmation Message [„Off-Stand” beves-
tigingsbericht]FRANKRIJK
QTAARR Return to Original „Created” Status for an Arrival
[terug naar oorspronkelijke „Created” status voor een
aankomst]FRANKRIJK
QTADEP Return to Original „Created” Status for a Departure
[terug naar oorspronkelijke „Created” status voor een
vertrek]FRANKRIJK
RCD RequestDepart ure Clearance Message [Berichtmet
aanvraag vrijgave vertrek] (AIRINC 623)FRANKRIJK
RCDFTX RequestDepart ure Clearance Message [Berichtmet
aanvraag vrijgave vertrek] (AIRINC 620)FRANKRIJK2000R2082 — NL — 15.06.2002 — 001.001 — 133
▼B
Gereserveerde
titelBerichttypeGereserveerd
door
REVARR Revision Message for an Arrival [revisieberichtvoor
een aankomst]FRANKRIJK
RFPDQ Repetitive Flight Plan Data Query Message [bericht
metgegevens-query voor herhaald vlucht planCFMU
RFPDQR Repetitive Flight Plan Data Query Reply Message
[berichtmetant woord op gegevens-query voor herhaald
vluchtplan]CFMU
RFPDSQ Repetitive Flight Plan Data Summary Query Message
[bericht met gegevenssamenvatting-query voor herhaald
vluchtplan]CFMU
RFPDSQR Repetitive Flight Plan Data Summary Query Reply
Message [bericht met antwoord op gegevenssamenvat-
ting-query voor herhaald vluchtplan]CFMU
RIEM Flight Data Information Message [bericht met vluchtge-
gevensinformatie]FRANKRIJK
RMG Missed Approach Message [berichtvan gemist e bena-
dering]FRANKRIJK
RRA Re-Routing Acceptance Message [bericht met accep-
tatie van omleiding]CFMU
RREC Repetitive Flight Plan Recovery Message [bericht van
herstel van herhaald vluchtplan]CFMU
RRN Re-Routing Notification Message [bericht met medede-
ling van omleiding]CFMU
RSUS Repetitive Flight Plan Suspension Message [bericht van
opschorting van herhaald vluchtplan]CFMU
RWYCHGCT Runway Configuration Message [bericht van configu-
ratie start/landingsbaan]FRANKRIJK
TRACT Request for Flight Plan Activation [aanvraag voor acti-
vering vluchtplan] (ODS)FRANKRIJK
TRACTCT Request for Flight Plan Activation [aanvraag voor acti-
vering vluchtplan] (Terminal Control System)FRANKRIJK
TRCNL Requestfor FlightPlan Cancellat ion [aanvraag voor
annulering vluchtplan] (ODS)FRANKRIJK
TRCNLCT Requestfor FlightPlan Cancellat ion [aanvraag voor
annulering vluchtplan] (Terminal Control System)FRANKRIJK
TRCOR Requestfor Manual Correlat ion [aanvraag voor hand-
matige correlatie]FRANKRIJK
TRDECOR Requestfor Manual De-Correlat ion [aanvraag voor
handmatige decorrelatie]FRANKRIJK
TRFIC Request for Creation of Flight Plan Data [aanvraag
voor aanmaak vluchtplangegevens] (ODS)FRANKRIJK
TRFICCT Request for Creation of Flight Plan Data [aanvraag
voor aanmaak vluchtplangegevens] (Terminal Control
System)FRANKRIJK
TRFLRQT RequestFlightLevel Message [berichtmetaanvraag
vluchtniveau]FRANKRIJK
TRMOD Requestfor FlightPlan Modificat ion [aanvraag voor
wijziging vluchtplan] (ODS)FRANKRIJK
TRMODCT Requestfor FlightPlan Modificat ion [aanvraag voor
wijziging vluchtplan] (Terminal Control System)FRANKRIJK
TRMODH Request for Time Modification [aanvraag voor tijdswij-
ziging]FRANKRIJK
TRMODHD Requestfor Time Modificat ion for Delayed Flight
[aanvraag voor tijdswijziging voor vertraagde vlucht]FRANKRIJK
TRMVT Co-ordination Request for Exiting Flight [coördinatie-
aanvraag voor uitgaande vlucht] (ODS)FRANKRIJK
TRMVTCT Co-ordination Request for Exiting Flight [coördinatie-
aanvraag voor uitgaande vlucht (Terminal Control
System)FRANKRIJK2000R2082 — NL — 15.06.2002 — 001.001 — 134
▼B
Gereserveerde
titelBerichttypeGereserveerd
door
TRPOINT Specific FlightDat a RequestMessage [berichtmet
aanvraag specifieke vluchtgegevens]FRANKRIJK
TRRET Request for Revision of Flight Plan to „Created” Status
[aanvraag voor herziening van vluchtplan naar status
„Created”] (ODS)FRANKRIJK
TRRETCT Request for Revision of Flight Plan to „Created” Status
[aanvraag voor herziening van vluchtplan naar status
„Created”] (Terminal Control System)FRANKRIJK
TRRIP Request for Display of Flight Data Information
[aanvraag voor afbeelding van vluchtgegevensinfor-
matie] (ODS)FRANKRIJK
TRRIPCT Request for Display of Flight Data Information
[aanvraag voor afbeelden van vluchtgegevensinfor-
matie] (Terminal Control System)FRANKRIJK
TRRQT FlightPlan Request[vlucht planaanvraag] (ODS) FRANKRIJK
TRRQTCT FlightPlan Request[vlucht planaanvraag] (Terminal
Control System)FRANKRIJK
TRSHRQT Requestfor SHOOT Act ion [aanvraag voor SHOOT-
actie]FRANKRIJK
TRSTAR Verkeersleider Working Position Initialisation Request
[aanvraag voor initialisatie verkeersleider-werkplek]
(ODS)FRANKRIJK
TRSTARCT Verkeersleider Working Position Initialisation Request
[aanvraag voor initialisatie verkeersleider-werkplek]
(Terminal Control System)FRANKRIJK
TRTRP Transfer Position Message [bericht van positieover-
dracht]FRANKRIJK
UNKFP Suppression of FlightPlan Message [onderdrukking van
vluchtplanbericht] (ODS)FRANKRIJK
UNKFPCT Suppression of FlightPlan Message [onderdrukking van
vluchtplanbericht] (Terminal Control System)FRANKRIJK2000R2082 — NL — 15.06.2002 — 001.001 — 135
▼B
BIJLAGE D (Normatief)
CENTRALE INDEX VAN GERESERVEERDE VELDEN
D.1.Inleiding
Deze bijlage bevateen cent rale index van gereserveerde velden, Primair,
Subveld en Hulptermen, die nog niet zijn gedefinieerd voor gebruik in
ADEXP. Hun opname in deze bijlage geeftaan datze ofwel zijn voor-
zien van toekomstig gebruik of dat ze reeds in gebruik zijn maar dat hun
gebruik is beperkt tot lokale systemen.
D.2.Doel
Het doel van het ter beschikking stellen van een overzicht van velden die
nog nietformeel geaccept eerd zijn voor gebruik binnen deze ADEXP-
norm is, in zoverre mogelijk, om te voorkomen dat ofwel redundantie
ontstaat telkens als een nieuw veld voor een bepaald doel nodig is of
dateen sleut elwoord wordtgemaaktdatreeds in gebruik is binnen een
lokaal systeem.
D.3.Gereserveerde hulptermen
Gereserveerde
hulptermSyntaxis SemantiekGebruiktin
primair veldGebruiktin
subveldGebruikt
in hulp-
veld
centreidentifi-
cation1{ALPHA}4 Aanduiding
centrum.ctsrc
ripsrc
ctripectdest
contextfdpsid 'OPEPAL' |
'OPESOS' |
'EVALPAL' |
'TSTOPEPAL'
|'TSTOPESOS'Werkmodus van
een FDPS- appli-
catie.
(operationeel, test
etc.)ctxtfdps
contextphidi-
asid'OPE'|'EVA-
L1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Specifiek voor het
Franse systeemctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Ingangspuntvoor
de controlepositie
(„E”). Uitgangs-
puntvoor de
controle-positie
(„S”),
XFL-punt(X),
OCL-punt(O)coorpt
eoidentifica-
tion1{ALPHANU-
M}6Aanduiding van
een „operationele
entiteit”.eosrc eoid
fl3 'F' ! 3{DIGIT}3 Vluchtniveau
uitgedrukt in
honderden
voeten.autfl1
autfl2curfl
flightten-
dancy'U'|'D'|'S' Geprojecteerde
tendens van het
vluchtprofiel.
U voor UPD voor DownS voor Stableetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Vluchtplanstatus
binnen een ACC.fpctst2000R2082 — NL — 15.06.2002 — 001.001 — 136
▼B
Gereserveerde
hulptermSyntaxis SemantiekGebruiktin
primair veldGebruiktin
subveldGebruikt
in hulp-
veld
latitude 4{ DIGIT }4 Een breedtegraad
uitgedrukt als vier
cijfersGereserveerd
voor
toekomstig
gebruik
latitudeshort 2{ DIGIT }2 Een breedtegraad
uitgedrukt als
twee cijfers.Gereserveerd
voor
toekomstig
gebruik
longitude 5{ DIGIT }5 Een lengtegraad
uitgedrukt als vijf
cijfers.Gereserveerd
voor
toekomstig
gebruik
longitudes-
hort3{ DIGIT }3 Een lengtegraad
uitgedrukt als drie
cijfers.Gereserveerd
voor
toekomstig
gebruik
pointcautra 1{ALPHANU-
M}5Specifiek voor het
Franse systeemfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Werkpositie feite-
lijk of logischposid
qfuid ('0'|'1'|'2'|'3')!1{
DIGIT }1!('L'|'C'
|'R'|NIL)QFU voor een
start/landings-
baan.
L = Links
C= Centrum
R = Rechtsqfu qful
secidentifica-
tion1{ALPHANU-
M}2Sector- aandui-
ding.secdest
secsrcsecid
sendingre-
ason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|
'MVTSEC'|'COO-
RAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'I-
NIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|'PKG'Reden voor
verzenden vlucht-
plan-gegevens.event
starreason 'TOTAL' Het type initiali-
satie van een
positie met
vluchtplan-gege-
vensstreason
temperature ("N" | "P") !
2{DIGIT}2Temperatuur
uitgedrukt in
graden Celsius
(00-99) metde
aanduiding van
hett eken (Nega-
tief of Positief)temp2000R2082 — NL — 15.06.2002 — 001.001 — 137
▼B
Gereserveerde
hulptermSyntaxis SemantiekGebruiktin
primair veldGebruiktin
subveldGebruikt
in hulp-
veld
updatereason ('T'!('R'|NIL)|'R') Type van laatste
bijwerking van
een vlucht-
gegeven.
Operator-trans-
actie („T”).
Radar-bijwerking
(„R”).udpt
D.4.Gereserveerde primaire velden
Gereser-
veerd
primair
veldType Syntaxis Semantiek
aabd b '-' "AABD" date Feitelijke aankomst on-block datum
aabt b '-' "AABT" timehhmm Feitelijke aankomst on-block tijd
acnf c '-' "ACNF" ad rcnf [qfulist] Configuratie start-/landingsbaan
aobd b '-' "AOBD" date Feitelijke off-block datum
aobt b '-' "AOBT" timehhmm Feitelijke off-block tijd
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Benaderingstype van de vlucht (1
cijfer, waarden: 1, 2, 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Vliegtuigidentificatie gebruikt door
luchtvaartmaatschappijen
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Lokaal uniek vliegtuigidentificatie-
nummer gebruiktdoor ATC
atis b '-' "ATIS" 1{ALPHA}1 Aanduiding Automatic Terminal
Information Service.
autfl1 b '-' "AUTFL1" fl3 Geautoriseerd vluchtniveau 1
autfl2 b '-' "AUTFL2" fl3 Geautoriseerd vluchtniveau 2
automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Bevatde gegevens die dienen t e
worden verzonden in een coördina-
tiebericht:
verzendtijd, uitgangspunt, vluchtni-
veau boven uitgangspunt, gepland
vluchtniveau en informatie met
betrekking tot het feit of het niveau
in overeenstemming is met
afspraken.
avail b '-' "AVAIL" 'YES'|'NO' Aanduiding of heteen sect or al dan
niet is toegestaan om een vlucht-
plangegeven te wijzigen.
bkrow b '-' "BKROW" 1{DIGIT}2 De positie van een referentiepunt in
een lijst met routepunten.
bkt b '-' "BKT" datetime Tijd boven het referentiepunt voor
een transactie.
codetr b '-' "CODETR" 'YES'|'NO' Aanduiding of de ssrcode dient te
worden verzonden (of niet) voor de
piloot door de controlepositie.
confid b '-' "CONFID" 1{DIGIT}5 Operationele configuratie-identifi-
catie (sectoren|posities).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"Lijst met sectoren/posities-associa-
ties voor een centrum en-route.
crspd b '-' "CRSPD" 1{DIGIT}4 Kruissnelheid in knopen
ctripe b '-' "CTRIPE" centreidentification Naam van het ontvangende
centrum voor een transactie2000R2082 — NL — 15.06.2002 — 001.001 — 138
▼B
Gereser-
veerd
primair
veldType Syntaxis Semantiek
ctrow b '-' "CTROW" 1{DIGIT}1 De positie van een centrum in een
lijstmetcent ra.
ctsrc b '-' "CTSRC" centreidentification Aanduiding van zendende centrum.ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Operationele modus van Terminal
Control System.
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Operationele modus van een FPDS.
ctxtpos b '-' "CTXTPOS" contextphidiasid Operationele modus voor ODS
curfl b '-' "CURFL" fl3 Huidig vluchtniveaucurpos c '-' "CURPOS" ptid | (lattd longtd) Huidige positiecurpost b '-' "CURPOST" datetime Datum en tijd bij huidige positiecurptt b '-' "CURPTT" datetime Datum en tijd van overvliegen van
huidig punt
curptx b '-' "CURPTX" 1{DIGIT}2 Genummerde positie van huidig
punt in een lijst met routepunten.
dcatcid b '-' "DCATCID" icaoaerodrome Luchthaven verantwoordelijk voor
vrijgave vertrek indien gegeven
door FDPS aan hetvliegt uig via
datalink.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Basistekst voor ARINC 623
vertrekvrijgaveberichten. „ACK”
voor bevestigingsbericht.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Basistekst voor ARINC 620
vertrekvrijgaveberichten. „ACK”
voor bevestigingsbericht.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Vertrekvrijgavestatus voor een
vlucht.
dcid b '-' "DCID" 1{DIGIT}3 Systeemnummer voor vertrekvrij-
gave.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Berichttype voor vertrekvrijgave.dcref b '-' "DCREF" 1{ALPHANUM}5 Contextreferentie voor een vertrek-
vrijgave.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Opmerking voor een vertrekvrij-
gave.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Supplementaire tekst voor Depar-
ture Clearance System Message
(ARINC 623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Tweede supplementaire tekst voor
Departure Clearance Message
(ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Dagen, uren, minuten, seconden
voor de vertrekvrijgave.
delcode b -' “DELCODE”
1{ALPHANUM}20Reden voor een vertraging
dfdpsid b '-' "DFDPSID datetime ! seconds Gegevens van Flight Data Proces-
sing System Identification
doubid b '-' "DOUBID" 1{ALPHANUM}2 Aanduiding van een „dubbele”
entiteit.
ecurptt b '-' "ECURPTT" datetime Geschatte tijd van overvliegen
huidig punt
eda b '-' "EDA" date Geschatte aankomsttijd
elastptt b '-' "ELASTPTT" datetime Geschatte tijd van overvliegen
laatste punt op de route2000R2082 — NL — 15.06.2002 — 001.001 — 139
▼B
Gereser-
veerd
primair
veldType Syntaxis Semantiek
endhldt b '-' "ENDHLDT" datetime Eindtijd wachtpatroon.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Aantal malen dat een vluchtplan
binnen een centrum voorkomt.
entryt b '-' "ENTRYT" datetime Ingangstijd voor de positie.
enxtptt b '-' "ENXTPTT" datetime Geschatte tijd van overvliegen van
volgende punt(nietgegeven als
huidig punt het laatste punt is).
eobdt b '-' "EOBDT" datetime Datum en geschatte off-block tijd.
eosrc b '-' "EOSRC" eoidentification Aanduiding operationele „entiteit”espfl b '-' "ESPFL" flightlevel Supplementair overdrachtsniveau
voor de voorgaande controlepositie.
eta b '-' "ETA" timehhmm Geschatte aankomsttijd.
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyIngangsvluchtniveau of vluchtpro-
fieltendens.
eventb '-' "EVENT" sendingreason Act iverings-event voor FDPS.firstpid b '-' "FIRSTPID" pointcautra Specifiek voor het Franse systeem
flbk b '-' "FLBK" flightlevel Vluchtniveau van het laatste trans-
actie-referentiepunt voor een geac-
tiveerde vlucht, of gewijzigd
niveau voor referentiepunt voor een
transactie.
fpbaseid b '-' "FPBASEID" datetime!seconds Aanduiding vluchtplandatabase
fpctst b '-' "FPCTST" fpcentrestate Vluchtplanstatus binnen een
centrum.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Lijstvan de bekende maar nog niet
overgedragen vluchtplannen voor
een positie.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Vluchtcategorie:
T = overvlucht
E = inkomend
S = uitgaand
I = intern.
fplistc '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Lijst met vluchtplaninformatie voor
een callsign.
fpllistc '-' BEGIN "FPLLIST" fpllgr
'-' "END"Lijstmetvlucht planvelden.
fplnb b '-' "FPLNB" 1{DIGIT}1 Aantal vluchtplannen
van 0 tot 5
fplstat b '-' "FPLSTAT" "T" | "C" Vluchtstatus:
T = terminated [beëindigd]
C = active [actief].
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Initiële vluchtplanopmerkingen.fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT"“|FIC-
PAC"|'FPL"|"RPL"|"NKW")Bron van vluchtplan.
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Lijstmet„onbekende” vlucht -
plannen.
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Vrije-tekstbericht.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Flex-track identiteit.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Flex-track naam.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Flex-track aanmaaknummer.2000R2082 — NL — 15.06.2002 — 001.001 — 140
▼B
Gereser-
veerd
primair
veldType Syntaxis Semantiek
grspd b '-' "GRSPD" 1{DIGIT}4 Grondsnelheid in knopen.
hldbkrw b '-' "HLDBKRW" 1{DIGIT}2 Nummerpositie van een referentie-
punt voor een wachtpatroon in een
lijst met routepunten.
icing b '-' "ICING" 1{ALPHA}8 IJsafzetting.
„TRACE” [sporen] of „LIGHT”
[licht] of „MODERATE” [matig]
of 'SEVERE' [ernstig].
indstip b '-' "INDSTIP" 'STIP' Specifiek voor het Franse systeem
initid b '-' "INITID" 1{DIGIT}1 Initialisatienummer.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Aanduiding van FDPS/ODS of
FDPS/Terminal systeeminterface.
lalglistc '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Lijst met breedtegraad en lengte-
graad van punten op de route.
lang b '-' "LANG" '?' Aanduiding conversatietaal.
„?” = de taal is niet gebruikelijk bijde maatschappij
lastradt b '-' "LASTRADT" datetime Tijdstip laatste bijwerking door
radarinformatie.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Lichtencode.
maintb '-' "MAINT" 'YES'|'NO' Aanduiding of de gegevensinfor-
matie voor een controlepositie al
dan nietcont inu wordtbijge-
houden.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4SSR-modus A informatie
modec b '-' "MODEC" flightlevel SSR-modus C informatie
msgbody b '-' "MSGBODY"
1{CHARACTER}Bevat een tekenreeks die identiek
is aan de body van hetgelijklui-
dende en bestaand niet-ADEXP-
bericht.
msgct b '-' "MSGCT" datetime ! seconds Tijdstempel van het bericht in de
notatie: dag, uren, minuten,
seconden.
nat b '-' "NAT" 1{ALPHA}1 Aanduiding van een Noord-Atlanti-
sche route.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Volgende frequentiecontact.
nxtfir b '-' "NXTFIR" icaoaerodrome Volgende FIR waarmee contact
dientt e worden opgenomen
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Volgende positie.
nxtpost b '-' "NXTPOST" datetime Tijd boven de volgende positie.
oclfl b '-' "OCLFL" flightlevel Oceanic Clearance Limit (OCL)
vluchtniveau.
oprfl b '-' "OPRFL" flightlevel Aangevraagd vluchtniveau gewij-
zigd door een operator.
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Lijstmetopmerkingen van
operator.
oprmkctb '-' "OPRMKCT"
1{LIM_CHAR}20Opmerkingen van operator.
oriented b '-' "ORIENTED" 'YES'|'NO' Georiënteerde vlucht of niet.
pfl b '-' "PFL" flightlevel Planned Flight Level [gepland
vluchtniveau] (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpistvypistRadarspoorcoördinaten en snel-
heidsvector-coördinaten.
pistid b '-' "PISTID" 1{DIGIT}4 Aanduiding radarspoor.2000R2082 — NL — 15.06.2002 — 001.001 — 141
▼B
Gereser-
veerd
primair
veldType Syntaxis Semantiek
pkarr c '-' "PKARR" [pka] [pkc] pkatt Parkeerpositie voor een aanko-
mende vlucht
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Parkeerpositie voor een vertrek-
kende vlucht.
plnid b '-' "PLNID" 4{DIGIT}4 Aanduiding vluchtplan
plnold b '-' "PLNOLD" 4{DIGIT}4 Aanduiding oud vluchtplan
posstb '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Coördinatiebewegingstatus voor de
positie:
Accepted Movement for the Entry
[geaccepteerde beweging voor de
ingang] (MAE) of voor de uitgang
(MAS) of Proposed Movementfor
the Exit ]voorgestelde beweging
voor de uitgang] (MPS) of
Proposed MovementExitAlarm
[voorgestelde beweging uitgangs-
alarm] (MPSA) of Position not yet
Movement Co-ordinated [positie
nog nietbewegingsgecoördineerd]
(NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Aantal punten op de route.
qfu b '-' "QFU" qfuid Aanduiding gebruikte start-/
landingsbaan (QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Quebec-vluchtof niet .
radioid b '-' "RADIOID"
1{ALPHANUM}20Radio-identificatie.
reqid b '-' "REQID" 1{DIGIT}5 Nummer van een aanvraag.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Type vluchtplanaanvraag.
ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Lijst met entiteiten die vluchtplan-
gegevens dienen te ontvangen.
ripsrc b '-' "RIPSRC" centreidentification Aanduiding van het centrum dat
verantwoordelijk is voor het starten
van de verzending van vluchtplan-
gegevens.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' IFPS-transactienummer in een
vluchtplanaanvraag.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Lijstmetde CAUTRA-punt en van
niet-aangegeven route.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Lijst met routepunten voor
bepaalde transacties.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Lijst met luchthavenconfiguraties.
secdest b '-' "SECDEST" secidentification Aanduiding ontvangende sector.
seclistc '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Wereldwijde lijstvan sect oren.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Wereldwijde lijstvan de sect oren.
secsrc b '-' "SECSRC" secidentification Aanduiding opstellende sector.
spfl b '-' "SPFL" flightlevel Supplementair vluchtniveau.
ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Verzonden SSR-code.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmAanduiding stempel.
streason b '-' "STREASON" starreason Reden voor een initialisatieaan-
vraag vanaf een werkplek.2000R2082 — NL — 15.06.2002 — 001.001 — 142
▼B
Gereser-
veerd
primair
veldType Syntaxis Semantiek
strid b '-' "STRID" 1{DIGIT} RDPS-aanduiding.
temp b '-' "TEMP" temperature Temperatuurterminal b '-' "TERMINAL"
1{ALPHANUM}2Naam van de terminal.
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Lijst met mogelijke transacties
voor de controlepositie en voor het
gespecificeerde vluchtplan.
trfl b '-' "TRFL" flightlevel | flightten-
dancyOverdrachtsvluchtniveau of
tendensinformatie over een vlucht-
profiel
turb b '-' "TURB" 1{ALPHA}8 Turbulentie = LIGHT [licht] of
MODERATE [matig] of SEVERE
[zwaar]
validend b '-' "VALIDEND" datetime Eindtijd van afbeelding.
validst b '-' "VALIDST" datetime Begintijd van afbeelding.
visi b '-' "VISI" 1{ALPHANUM}20 Zicht.
wddir b '-' "WDDIR" 1{DIGIT}3 Windrichting uitgedrukt in graden
van 0 tot 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Windsnelheid uitgedrukt in knopen.
xfl b '-' "XFL" flightlevel Exit Flight Level [uitgangsvlucht-
niveau] (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Antwoordbericht op een vlucht-
planaanvraag.
D.5.Gereserveerde subvelden
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
actc '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Vluchtplanvelden die
kunnen worden
gewijzigd op het
momentvan act ive-
ring van een vlucht.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxImplicietFL,
minimum FL en
maximum FL voor
hetreferent iepunt
voor een transactie.
HetFL is algemeen,
kan RFL, PFL etc.
zijn.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2De waarde (+/-)
waarmee een tijds-
wijziging voor een
punt is toegestaan.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxImplicitCleared
FlightLevel [impli-
cietvrijgegeven
vluchtniveau] (CFL),
minimum CFL en
maximum CFL voor
hetreferent iepunt
voor een transactie.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-modus en toege-
wezen code.ssrcodes2000R2082 — NL — 15.06.2002 — 001.001 — 143
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-modus en code
die beschikbaar is
voor gebruik.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-7'}4Eerder toegekende
SSR-modus en code.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4SSR-modus en code
die zijn gereserveerd
voor gebruik en
derhalve niet
beschikbaar.ssrcodes
coorptb '-' "COORPT" coord-
pointsKenmerk van coördi-
natiepunt: Initial,
Exit, OCL, XFLptc
ctdest b '-' "CTDEST"
centreidentificationOntvangend centrum
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTijdsinterval voor de
berekening van een
minimumtijd.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITTijdsinterval voor de
berekening van een
maximumtijd.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Snelheidsinterval
voor de berekening
van een minimum-
snelheid.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Snelheidsinterval
voor de berekening
van een maximum-
snelheid.spdchg
destid c '-' "DESTID" ctdest
secripATC-centrum en lijst
metsect oren waar-
naar vluchtplangege-
vens dienen te
worden gezonden.ripel
edto b '-' "EDTO" dateti-
me|"WT"Geschatte tijd boven
een puntin jaar,
maand, dag, uren,
minuten of aandui-
ding „pointwit hout
time” [punt zonder
tijd] „WT”.ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationOperationele „enti-
teit” naam.eolist
eolistc '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Lijstmetoperat ionele
entiteiten geassoci-
eerd meteen cont ro-
lepositie.eopos
eopos c '-' "EOPOS" posid
[eolist]Controlepositienaam
en lijstmetoperat io-
nele entiteiten geas-
socieerd metdeze
position.confl2000R2082 — NL — 15.06.2002 — 001.001 — 144
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
fieldid c '-' "FIELDID"
'TYPA'|'ADES'|'-
RTE'|'ADEP'|'CO-
DE'|'LANG'|'-
BK'|spdchg|rflchg|cfl-
chg|pflchg|tflchg|sflc-
hg|xflchg|bkchg|bktc-
hg|'QFU'|'PKDEP'|'-
SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Aanduiding van
wijzigbare velden
voor een transactie.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Berekend vluchtni-
veau bij uitgangs-
coördinatiepunt dat
kan worden
verzonden in het
automatische coördi-
natiebericht aan het
volgende centrum.automsg
flimp b '-' "FLIMP" flight-
levelImplicietvlucht ni-
veau.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" flight-
levelMaximum flight
level.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" flight-
levelMinimum vluchtni-
veau.bkchg
rflchg
pflchg
cflchgtflchg
sflchg
xflchg
fpidentc '-' "FPIDENT" plnid
stamp ctrow entrnbVluchtplanidentifi-
catie in een bericht.fpunkl
fpkwl
fpllgr c '-' "FPLLGR" arci-
datc arcid adep ades
eobd eobt„Samengevatte”
vluchtplangegevens.fpllist
fpsum c '-' "FPSUM" plnid
eobdtadep ades
ctrow firstpidAanduiding vlucht-
plan.fplist
lalg c '-' "LALG" lattd
longtdBreedtegraad en
lengtegraad van elk
puntop de rout e.laglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Lijstmetvelden die
wijzigbaar zijn na
activering.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Lijstmetvelden die
wijzigbaar zijn in een
tijdbijwerkingstrans-
actie na activering.transid
mvtc '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Lijstmetvelden die
wijzigbaar zijn in een
handmatig geacti-
veerde coördinatie
tussen sectoren.transid
pflchg c '-' "PFLCHG" flimp
flmin flmaxImpliciet, minimum-
en maximumniveau
voor wijziging van
PFL.fieldid2000R2082 — NL — 15.06.2002 — 001.001 — 145
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
pfltb '-' "PFLT" flight le-
vel!('NA'|NIL)Gepland vluchtniveau
dat in het automati-
sche coördinatiebe-
richtaan het
volgende centrum
wordtverzonden.
Plus een aanduiding
of hetniveau over-
eenkomtmetde
toepasselijke operati-
onele afspraken.
NA = Notaccording
agreement[nietover-
eenkomstig
afspraken].automsg
pka b '-' "PKA"
1{ALPHANUM}3Gereserveerde
parkeerpositie, nog
niett oegewezen.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Aanduiding dathet
vliegtuig wacht op
een parkeerpositie.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Toegewezen parkeer-
positie.pkarr
pointid b '-' "POINTID" point-
cautraSpecifiek voor het
Franse systeem.ptpro
posid b '-' "POSID" position-
identificationNaam controlepositie. eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Kenmerken van een
routepunt.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameSpecifiek voor het
Franse systeem.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Beschrijving van
voorgestelde route-
punten.rtetr
qful c '-' "QFUL" qfuid Geldige QFU voor
een gegeven start-/
landingsbaan van een
luchthaven.qfulist
qfulistc '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Lijstmetgeldige
QFU's voor een
luchthaven.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Algemene opstijg- en
landingsrichting voor
een luchthaven.
(Oost, West etc.)acnf
ref c '-' "REF" (refi-
d|ref1id)Kenmerken van een
referentiepunt voor
een transactie.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Aanduiding van een
mogelijk referentie-
puntvoor een t rans-
actie.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Aanduiding van het
meestwaarschijnlijke
referentiepunt voor
een transactie.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Regelinginformatie
specifiek voor de
Franse systemen.regul2000R2082 — NL — 15.06.2002 — 001.001 — 146
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Regelinginformatie
specifiek voor de
Franse systemen.regul
regultb '-' "REGULT" dat e-
timeRegelinginformatie
specifiek voor de
Franse systemen.regul
retc '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Lijstmetvelden die
wijzigbaar zijn in een
transactie om de
vluchtplangegevens
terug te zetten naar
hun oorspronkelijke
status.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxImpliciet, minimum-
en maximumniveau
voor de wijziging van
de RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Tekstvan een
verkeersleideropmer-
king.oprmk
sec c '-' "SEC" secid
[seccar]Aanduiding en
kenmerken van ACC-
sectoren waaraan
vluchtplangegevens
dienen te worden
gezonden.seclistsecrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Kenmerk van een
ACC-sector:
— Eerste sector („F”)
— Laatste sector
(„L”)
— Geaccepteerd voor
ingang („M”)
— bronsector voor
„duplicatie” („D”)sec
seccarctb '-' "SECCARCT"
('F'!('L'!('M'!('V'/
NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Kenmerk van een
Terminal Area-sector:
— Eerste sector („F”)
— Laatste sector
(„L”)
— Geaccepteerd voor
ingang („M”)secct
secctc '-' "SECCT" secid
[seccarct]Aanduiding en
kenmerken van
Terminal Area-
sectoren.seclistct
secid b '-' "SECID" seciden-
tificationAanduiding sector. secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Lijstmetont van-
gende entiteiten
(sectoren of vertrek/
aankomstcont role-
entiteiten) waaraan
vluchtplangegevens
dienen te worden
gezonden.destid
sendt b '-' "SENDT" datetime Tijd voor zenden van
coördinatiebericht.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxImpliciet, minimum-
en maximumniveau
voor wijziging van
Supplementary Flight
Level [supplementair
vluchtniveau] (SFL)fieldid2000R2082 — NL — 15.06.2002 — 001.001 — 147
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
spdchg c '-' "SPDCHG" deltsp1
deltsp2Laagste en hoogste
snelheidsintervallen
voor de wijziging van
de vluchtplansnelheid
tijdens een transactie.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxImpliciet, minimum-
en maximumniveau
voor wijziging van
Transfer FlightLevel
[overdrachts-vluchtni-
veau](TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Kenmerken van een
punt in relatie tot de
baan van een vlucht:
S = Splitpoint [split-
spunt]
M = Mergepoint
[samenvoegpunt]
T = Abeam point
[dwarspunt]
A = STAR point
[STAR-punt]ptc
ptpro
transid b '-' " TRANSID" (act |
mod | mvt| ret|
modh | 'CNL' | 'RIP')
| 'NO'Aanduiding van
mogelijke transactie
voor de controlepo-
sitie voor dit vlucht-
plan of aanduiding
„NO” welke betekent
dat transactie niet
mogelijk is.translist
txt b '-' "TXT"
1{LIM_CHAR}80Vrije tekst. freetxt
udptb '-' "UDPT" updat ere-
asonLaatste bijwerking
aangebrachtdoor
operator en/of radar-
informatie.ptc
view b '-' "VIEW"
('V'|'VNX')Aanduiding van
„zichtbare” aard van
een punt.
V = viewable [zicht-
baar]
VNX = notviewable
[nietzicht baar](-
kunstmatig punt)ptc
vxpistb '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeX-coördinaatvan de
snelheidsvector van
een radarpositie.pistcoord
vypistb '-' "VYPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeY-coördinaatvan de
snelheidsvector van
een radarpositie.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxMinimum- en maxi-
mumniveau voor
wijziging van een
ExitFlightLevel
[uitgaand vluchtni-
veau] (XFL).fieldid
xpistb '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positif
N:= NegativeX-coördinaatvan een
radarpositie.pistcoord2000R2082 — NL — 15.06.2002 — 001.001 — 148
▼B
Gereser-
veerde
subveldenType Syntaxis SemantiekGebruiktin
primair
veldGebruikt in
subveld
ypistb '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= NegativeY-coördinaatvan een
radarpositie.pistcoord2000R2082 — NL — 15.06.2002 — 001.001 — 149
▼B
BIJLAGE E (Ter informatie)
INTRODUCTIE VAN BERICHTGROEPEN
INLEIDING
Deze bijlage bevateen inleiding op de verschillende groepen of cat egorieën van
berichten die in ADEXP kunnen worden uitgewisseld. Bijlage B bevat een
volledig overzicht van alle ADEXP-berichttitels.
Opmerking Voor de exacte voorwaarden, toepassingsregels en veldgebruik, in
het bijzonder het gebruik van facultatieve velden, wordt verwezen
naar de betreffende documentatie (bijv. Interface Specification-
document) van de betreffende systemen.
E.1. Vluchtplanberichten
E.1.1. Inleiding
Berichten binnen deze categorie worden primair uitgewisseld tussen
de AO, IFPS en de relevante ATS-eenheden.
E.1.2. Definitie van berichttitels
De berichttitels binnen deze categorie zijn:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQP, MAN, RCHG, RCNL, REJ.
DocumentRef. 3 bevatal hetdefiniërende mat eriaal voor deze
berichten.
E.1.3. Samenstelling van primaire velden
Document Ref.3. bevat een gedetailleerde definitie van berichtinhoud,
regels voor invoegen van gegevens en hetgebruik van verplicht e en
facultatieve velden.
Voorbeeld:Vluchtplanbericht
-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 — NL — 15.06.2002 — 001.001 — 150
▼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. Berichten voor beheer van luchtverkeersstromen
E.2.1. Inleiding
Berichten binnen deze categorie worden primair uitgewisseld tussen
het TACT-systeem van Eurocontrol CFMU, luchtvaartmaatschappijen
en ATS-eenheden.
E.2.2. Computer Assisted Slot Allocation Messages [berichten met door
computer gesteunde beurttoewijzingen] (CASA)
Berichttitels binnen deze categorie zijn:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Definitie van berichttitels
DocumentRef. 5 bevatal hetdefiniërende mat eriaal voor deze
berichten.
E.2.2.2. Samenstelling primaire velden
Document Ref. 5 bevat een gedetailleerde definitie van berichtinhoud,
regels voor hetinvoegen van gegevens en hetgebruik van verplicht e
en facultatieve velden.
Voorbeeld:-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3. Informatieberichten
Berichttitels binnen deze categorie zijn:
FSA
E.2.3.1. Definitie van berichttitels
Document Ref. 5 bevat al het definiërende materiaal voor dit bericht.
E.2.3.2. Samenstelling primaire velden
Document Ref. 5 bevat een definitie van de berichtinhoud, regels
voor hetinvoegen van gegevens en hetgebruik van verplicht e en
facultatieve velden.
Voorbeeld:
Eerste bericht voor systeemactivering
-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — NL — 15.06.2002 — 001.001 — 151
▼B
E.3. ATC-coördinatieberichten
E.3.1. Inleiding
Coördinatieberichten worden gebruikt om operationele coördinatie te
automatiseren en om informatie uit te wisselen tussen ATC-eenheden.
De berichten zorgen voor de tijdige levering van operationele infor-
matie die betrekking heeft op coördinatie door middel van
genormaliseerde gegevensextractie en verzendmogelijkheden.
E.3.2. Definitie van berichttitels
Berichttitels binnen deze categorie zijn:
ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
DocumentRef. 6 bevatal hetdefiniërende mat eriaal voor deze
berichten.
E.3.3. Samenstelling van primaire velden
DocumentRef. 6 bevatal hetdefiniërende mat eriaal voor deze
berichten.
Voorbeelden:
Bericht met voorstel tot overdracht-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Activeringsbericht
-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. Berichten voor luchtruimbeheer
E.4.1. Inleiding
Berichten gebruikt voor de coördinatie van luchtruimbeheer. Deze
berichten hebben betrekking op het beheer van de omgeving waarin
het verkeer zich beweegt: de permanente en conditionele routes, tijde-
lijk afgescheiden gebieden, gevaarlijke en verboden gebieden etc.
E.4.2. Definitie van berichttitels
Berichttitels binnen deze categorie zijn:
AUP, CRAM, UUP.
DocumentRef. 7 bevatal hetdefiniërende mat eriaal voor deze
berichten.
E.4.3. Samenstelling primaire velden
DocumentRef. 7 bevatal hetdefiniërende mat eriaal voor deze
berichten.
Voorbeeld:
Berichtmetbeschikbaarheid voorwaardelijke rout e-TITLE CRAM -PART -NUM 001 -LASTNUM 010
-FILTIME 281353 -MESVALPERIOD 199803290600
1998703300600
-BEGIN LACDR-AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803300600
-AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP2000R2082 — NL — 15.06.2002 — 001.001 — 152
▼B
-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. Civiele / Militaire coördinatieberichten
E.5.1. Inleiding
Berichten gebruikt voor de coördinatie van vluchtgegevens en
aanvragen om het luchtruim te doorkruisen tussen civiele en militaire
ATS-eenheden.
E.5.2. Definitie van berichttitels
Berichttitels binnen deze categorie zijn:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.
DocumentRef. 7 bevatal hetdefiniërende mat eriaal voor deze
berichten.
E.5.3. Samenstelling primaire velden
DocumentRef. 7 bevatal hetdefiniërende mat eriaal voor deze
berichten.
Voorbeeld:
Berichtmetaanvraag voor vrijgave doorkruising
-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
Bericht van acceptatie
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — NL — 15.06.2002 — 001.001 — 153
▼B
BIJLAGE F (Ter informatie)
VOORBEELDEN VAN ADEXP-BERICHTSTRUCTUUR
De volgende voorbeelden worden geleverd als demonstratie van de ADEXP-
structuur, niet als een voorbeeld van berichtinhoud. Het gebruikte bericht is
een IFPL en hoewel correct ten tijde van publicatie wordt de nauwkeurigheid
van de veldsamenstelling etc. niet gegarandeerd.
HetVOORBEELD 1 hieronder wordtgepresent eerd op een manier die het
gemakkelijk leesbaar maakt. Dit is bereikt door het gebruik van wagenterug-
lopen, regelopschuiving, inspringingen etc. Een dergelijke opmaak maakt
echter geen deel uit van de ADEXP-structuurregels.
De presentatie van een voorbeeld wordt daarom bepaald door het ontvangende
systeem. VOORBEELD 2 en VOORBEELD 3 zijn beide geldige weergaven van
hetzelfde bericht als dat in VOORBEELD 1.
VOORBEELD 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 TALAS2000R2082 — NL — 15.06.2002 — 001.001 — 154
▼B
-ALTRNT1 LBSF
-EETFIR EDUU 0014-EETFIR LOVV 0035
-EETFIR LJLA 0054
-EETFIR LHCC 0057
-EETFIR LYBA 0113
-EETFIR LWSS 0148-EETFIR LGGG 0159
-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414-PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130
-PT -PTID MUN -FL F330 -ETO 980317074449-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830
-PT -PTID DIMLO -FL F330 -ETO 980317081443
-PT -PTID BABIT -FL F330 -ETO 980317083107-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204
-PT -PTID VAL -FL F330 -ETO 980317084629
-PT -PTID KAVOR -FL F330 -ETO 980317085329-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D
-ATSRT UW70 NDG MUN
-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT
-ATSRT UR26 BABIT SAVIN
-ATSRT UG18 SAVIN BUI
-ATSRT UB1 BUI TALAS
VOORBEELD 2
-TITLE IFPL -BEGIN ADDR -FAC CFMUTACT -FAC LFFFSTIP -FAC
EDFFZRZL -FAC EDZZZQZA -FAC EDUUZQZA -FAC LOVVZQZX -FAC
LHBPZEZX -FAC LYBAZQZX -FAC LWSSZQZX -FAC LGTSZAZX -END
ADDR -ADEP EDDF -ADES LGTS -ARCID DLH3728 -ARCTYP B73A -
CEQPT SDMR -EOBD 980517 -EOBT 0715 -FILTIM 170421 -IFPLID
AA05966101 -ORGNID DLHAOCC -ORIGIN -NETWORKTYPE SITA -FAC
FRAOXLH -REG DABHM -SEL KMGJ -SRC FPL -FLTTYP S -WKTRC M
-TTLEET 0210 -RFL F330 -SPEED N0417 -FLTRUL I -SEQPT C -ROUTE
N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26
SAVIN UG18 BUI UB1 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -
EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR
LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -
PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -
ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID
MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO
980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID
UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO
9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID
BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO
980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID
KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO
980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID
BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO2000R2082 — NL — 15.06.2002 — 001.001 — 155
▼B
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
VOORBEELD 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 — NL — 15.06.2002 — 001.001 — 156
▼B
BIJLAGE G (Ter informatie)
TOEKOMSTIGE ONTWIKKELINGEN
G.1.Inleiding
Deze bijlage is bedoeld om een indicatie te geven van de voorgestelde
toekomstige ontwikkeling van ADEXP en de redenen en doelstellingen
achter de ontwikkeling.
G.2.Doelstellingen
Een van de belangrijkste doelstellingen tijdens de ontwikkeling van
ADEXP was de vereiste om een structuur te ontwikkelen die een ontvan-
gend systeem in staat zou stellen om met succes een onbekend of niet-
herkend veld te „negeren” of „over te slaan” zonder noodzakelijkerwijs
hetberichtdatwordtverwerktongeldig t e hoeven maken. Deze imple-
mentatie maakt de toevoeging van een nieuw veld binnen een bericht
mogelijk zonder dathetvereistis om van t evoren alle ont vangende
systemen aan te passen gevolgd door een zeer zorgvuldig gecoördineerde
„overschakeling”. De enorme flexibiliteit die hierdoor kan ontstaan is
een van de voordelen van de ADEXP-structuur.
In de huidige norm wordtdeze doelst elling bereiktdoor hetgebruik van
vooraf gedefinieerde primaire velden en subvelden, ingeleid door unieke
sleutelwoorden. Een lexicale analysator of parser die een sleutelwoord
niet „herkend” is vereist om alle tekst tot aan het volgende bekende
primaire veld te negeren dat zich niet binnen een lijstveld bevindt.
Herstel vindt daarom plaats op het niveau van primaire velden.
Huidige en toekomstige ontwikkelingen in de definitie van nieuwe
berichten geven aan dat in bepaald gebieden een hoger niveau van
complexiteit vereist is, waarbij nesten van velden op het derde en zelfs
vierde niveau nodig is. (Het Conditional Route Allocation Message
[bericht van voorwaardelijke routetoewijzing] (CRAM) is een voorbeeld
van deze behoefte). Vandaag de dag beschikt ADEXP over de mogelijk-
heid om een bericht samen te stellen met elke gewenst niveau van
nesten. Er bestaat echter geen herstelmogelijkheid voor een niet-herkend
subveld, datmisschien voorkomtop hetderde of vierde genest e niveau,
zonder de kans op verkeerde interpretatie van gegevens of de noodzaak
om het bericht ongeldig te verklaren. De voorgestelde vereiste wijzi-
gingen in de ADEXP-structuur zijn ontworpen om ervoor te zorgen dat
een lexicale analysator of parser in staat is om te allen tijde te bepalen
waar deze zich in de structuur van een bericht of individueel veld
bevindt en om als zodanig herstel mogelijk te maken op elk genest
niveau zonder gevaar voor verkeerde interpretatie van gegevens.
G.3.Voorstel
Teneinde de doelstelling van herstel op elk niveau binnen een bericht te
bereiken is hetnoodzakelijk datde lexicale analysat or in st aatis om
zowel heteinde als hetbegin van een veld t e bepalen. De huidige st ruc-
t uur maakthetalleen mogelijk om hetbegin van een veld t e bepalen
door gebruik van hett eken „-”.
In een toekomstige versie van ADEXP zal worden voorgesteld om het
gebruik van haakjes te introduceren om respectievelijk het begin en het
einde van een veld aan te duiden. Het huidige gebruik van het teken „-”
om hetbegin van een veld aan t e duiden zou worden vervangen door het
teken „(”. Het einde van het veld, dat op dit moment niet expliciet wordt
aangeduid, zou in de toekomst worden aangeduid door het teken „)”. De
volgende voorbeelden zijn bedoeld om het principe te demonstreren.
VOORBEELDEN
Huidige structuur Voorgestelde structuur
Voorbeeld van basisveld: -RFL F330 (RFL F330)Voorbeeld van samengesteld veld: -CRSCLIMB
-PTID DUB-CRSPEED M084
-CRFL1 F370
-CRFL2 F430(CRSCLIMB
(PTID DUB)(CRSPEED M084)
(CRFL1 F370)
(CRFL2 F430))2000R2082 — NL — 15.06.2002 — 001.001 — 157
▼B
BIJLAGE III
FLIGHT DATA EXCHANGE — INTERFACE CONTROL DOCUMENT
(FDE-ICD), EDITIE 1.0
(Eurocontrol-referentiedocument COM.ET1.ST12-STD)2000R2082 — NL — 15.06.2002 — 001.001 — 158
▼B
INHOUDSOPGAVE
AUTEURSRECHT
VOORWOORD1. INLEIDING2. REIKWIJDTE
3. REFERENTIES
3.1. Inleiding3.2. Referenties
4. DEFINITIES, SYMBOLEN EN AFKORTINGEN
4.1. Definities4.2. Symbolen en afkortingen4.3. Notaties
5. Technisch overzicht
5.1. Protocolstapeling
5.2. Structuur van het profiel5.3. Relatie met eerdere versies van de specificatie
6. PROFIELVEREISTEN
6.1. Conformiteitvereisten6.2. Vereisten voor de bovenste laag6.3. Vereisten voor de onderste laag6.3.1. Vereisten voor de transportlaag6.3.2. Vereisten voor de netwerklaag6.3.3. Vereisten voor de datalink-laag6.3.4. Vereisten voor de fysieke laag
7. TESTMETHODEN
BIJLAGE A (NORMATIEF) PROTOCOL VOOR BERICHTENOVERDRACHT (MESSAGE
TRANSFER PROTOCOL)
A.1. InleidingA.2. Geïmplementeerde dienst
A.3. Veronderstelde dienst
A.4. ProtocolspecificatieA.4.1. InleidingA.4.2. Typen dataA.4.3. Tot stand brengen van associatieA.4.4. DataoverdrachtA.4.5. Ordelijke vrijgave van de associatieA.4.6. Opnieuw tot stand brengen van de associatieA.4.7. Integriteit van de associatieA.4.8. Onordelijke vrijgave van de associatie2000R2082 — NL — 15.06.2002 — 001.001 — 159
▼B
A.4.9. Herstel bij fouten
A.4.10. BerichtstructurenA.5. Tabellen met protocolstatusovergangen
A.5.1. Inleiding
A.5.2. StatusdefinitiesA.5.3. Mogelijke gebeurtenissenA.5.4. AftelklokkenA.5.5. Tabel met statusovergangenA.5.6. Diagram met statusovergangen
BIJLAGE B (NORMATIEF) BERICHTKOPPROTOCOL (MESSAGE HEADER PROTOCOL)
B.1. InleidingB.2. Geïmplementeerde dienstB.3. Veronderstelde dienstB.4. ProtocolspecificatieB.4.1. Totst and brengen van de verbindingB.4.2. Vermijden van redundante netwerkverbindingenB.4.3. Vrijgeven van de verbindingB.4.4. Dataoverdracht
BIJLAGE C (NORMATIEF) NETWERKPROTOCOL
C.1. InleidingC.2. Geleverde dienstC.3. Veronderstelde dienstC.4. NSAP-adresseringC.4.1. InleidingC.4.2. NSAP-adresstructuurC.4.3. Toewijzing van ATC-eenheid-aanduidingen en selectorsC.5. ProtocolspecificatieC.5.1. OverzichtC.5.2. Adrescodering
C.5.3. Codering van hetveld User Dat a
C.5.4. Behandeling van adressen in INCOMING CALL-pakkettenC.5.5. Dataoverdracht
BIJLAGE D (NORMATIEF) PROFIELSPECIFIEKE PICS-PROFORMA'S
D.1. Inleiding
D.2. Instructies voor het invullen van de PICS-proforma'sD.2.1. Algemene structuur van de PICS-proforma'sD.2.2. Aanvullende informatieD.2.3. UitzonderingsinformatieD.2.4. Voorwaardelijke itemsD.3. PICS-proforma voor het protocol voor berichtenoverdracht2000R2082 — NL — 15.06.2002 — 001.001 — 160
▼B
D.3.1. Afkortingen en speciale symbolen
D.3.2. AanduidingD.3.3. Protocolimplementatie
D.4. PICS-proforma voor het berichtkopprotocol
D.4.1. Afkortingen en speciale symbolenD.4.2. AanduidingD.4.3. ProtocolimplementatieD.5. PICS-proforma voor het netwerkprotocol
D.5.1. Afkortingen en speciale symbolen
D.5.2. AanduidingD.5.3. Protocolimplementatie
BIJLAGE E (NORMATIEF) LIJST MET PROFIELVEREISTEN
E.1. Inleiding
E.2. De rol van de PRL en de PICS-proforma'sE.3. NotatieE.4. Instructies voor het invullen van de PICS-proforma's
E.5. Referenties
E.6. ConformiteitverklaringE.6.1. Overzichtvan conformeringE.6.2. Dynamische conformiteitvereistenE.7. Vereisten voor de bovenste laag
E.8. Vereisten voor de onderste laag
E.8.1. Vereisten voor de transportlaagE.8.2. Vereisten voor de netwerklaagE.8.3. Vereisten voor de datalink-laagE.8.4. Vereisten voor de fysieke laag
BIJLAGE F (TER INFORMATIE) METHODE VOOR HET TESTEN VAN CONFORMITEIT
F.1. InleidingF.2. Doelstelling en reikwijdte
F.3. Bibliografie
F.4. Ontwikkelingsmethoden en -praktijkenF.5. TestsF.5.1. InleidingF.5.2. Testen van de lagere lagen (lagen 1-3)
F.5.3. Testen van de applicatielaag
F.5.4. BevestigingF.5.5. Mededeling
BIJLAGE G (TER INFORMATIE) TOEWIJZING VAN AANDUIDINGEN VOOR ATC-
EENHEDEN2000R2082 — NL — 15.06.2002 — 001.001 — 161
▼B
BIJLAGE H (TER INFORMATIE) ADVIEZEN MET BETREKKING TOT BETROUWBAARHEID,
BESCHIKBAARHEID EN BEVEILIGING
H.1. InleidingH.2. Doelstelling en reikwijdteH.3. BibliografieH.4. Implementaties van huurlijnenH.4.1. BetrouwbaarheidH.4.2. BeschikbaarheidH.4.3. BeveiligingH.4.4. ConfiguratievoorbeeldH.5. NetwerkimplementatieH.5.1. BetrouwbaarheidH.5.2. BeschikbaarheidH.5.3. BeveiligingH.6. Algemene richtlijnen voor huurlijn- en netwerkimplementatiesH.6.1. BetrouwbaarheidH.6.2. Beschikbaarheid
H.6.3. Systeembeheer
H.6.4. Voorbeeldconfiguratie2000R2082 — NL — 15.06.2002 — 001.001 — 162
▼B
AUTEURSRECHT
Ditdocumentis geproduceerd door Eurocont rol Agency.
Het auteursrecht berust bij Eurocontrol Agency.De inhoud, of enig deel daarvan, is dus vrijelijk beschikbaar voor vertegen-
woordigers van de lidstaten, maar kopiëren of openbaar maken aan derden
vereist voorafgaande schriftelijke toestemming van Eurocontrol Agency.2000R2082 — NL — 15.06.2002 — 001.001 — 163
▼B
VOORWOORD
1. Verantwoordelijke instantie
Ditnormdocumentis opgest eld door en wordtonderhouden door
de Flight Plan related Data Exchange (FPDE) Task Force van de
European Organisation for the Safety of Air Navigation (Euro-
control).
2. EATCHIP Work Programme Document
Deze norm heeftbet rekking op hetEATCHIP Work Programme
Document (EWPD), Communications Domain, Executive Task
01, SpecialistTask 12
3. Goedkeuring van de norm
3.1. Deze norm is aanvaard overeenkomstig de procedures zoals
uiteengezet in de Directives for Eurocontrol Standardisation Ref.
000-2-93.
3.2. Deze norm wordtvan krachtna aanvaarding door de Permanent e
Commissie van Eurocontrol en komt in de plaats van de Eurocon-
trol Standard for On-Line Data Interchange (OLDI), Edition 1,
Part3: TECHNICAL REQUIREMENTS (ShortTerm Int erface
Control Document) Ref. 001-3-92.
4. Technische correcties en amendementen
Deze norm wordtvoort durend bijgewerktmetde benodigde
amendementen en technische correcties. De procedure voor het
onderhoud van deze norm is vastgelegd in Bijlage H van de
Directives for the Uniform Drafting and Presentation of Eurocon-
trol Standard Documents [richtlijnen voor de uniforme opstelling
en presentatie van Eurocontrol-normdocumenten] Ref. 000-1-92.
5. Redactionele gebruiken
5.1. Het formaat van deze norm voldoet aan de Directives for the
Uniform Drafting and Presentation of Eurocontrol Standard
Documents.
5.2. De volgende notatie is gebruikt om de status van de diverse
formuleringen aan te geven:
— Voor normatieve formuleringen, die worden afgedrukt in tekst
met een licht lettertype, worden de (hulp)werkwoorden
„zullen” of „dienen” gebruikt;
— VoorAanbevolen formuleringen , die worden afgedruktin een
cursief licht lettertype, worden de (hulp)werkwoorden
„zouden” of „dienen” gebruikt, waarbij de status wordt aange-
geven door hetprefix Aanbeveling .
5.3. Alle andere informatie die als essentieel wordt beschouwd voor
hetbegrip van een bepaalde inspringende t ekstwordtbinnen de
tekst geïntegreerd als een OPMERKING. Een opmerking wordt
uitsluitend als informatief beschouwd en bevat daarom geen
specificaties en is onmiddellijk achter de inspringing geplaatst
waarnaar de opmerking verwijst.
5.4. Teneinde de Profile Requirements Lists [lijsten met profielver-
eisten] (PRL's) in Bijlage E in een geschikt formaat te
presenteren springen sommige tabellen bij uitzondering niet in
en lopen ze nietover naar de volgende pagina's.
6. Relatie met andere normdocumenten
6.1. Dit Eurocontrol-normdocument komt in de plaats van het OLDI
Short Term Interface Control Document (ST-ICD), Part 3,
Edition 1 van de OLDI Eurocontrol Standard [Referentie 13].
6.2. Dit Eurocontrol-normdocument is het eerste deel in een
verwachte reeks van Eurocontrol Standard Interface Control
Documents (ICD's) voor de uitwisseling van vluchtgegevens.
7. Status van de bijlagen bij deze norm
De bijlagen bij deze norm hebben de volgende status:
— Bijlage A — normatief2000R2082 — NL — 15.06.2002 — 001.001 — 164
▼B
— Bijlage B — normatief
— Bijlage C — normatief
— Bijlage D — normatief
— Bijlage E — normatief— Bijlage F — ter Informatie— Bijlage G — ter informatie— Bijlage H — ter informatie
8. Taal
Het origineel van deze norm is gesteld in de Engelse taal.2000R2082 — NL — 15.06.2002 — 001.001 — 165
▼B
1. INLEIDING
Deze Eurocontrol-norm is gebaseerd op het Short Term Interface
Control Document dat werd ontwikkeld door de voormalige
OLDI Technical Sub-Group die opdrachthad gekregen om
nieuwe interfacenormen te definiëren voor de toekomstige toepas-
sing van OLDI tussen Area Control Centres.
Eerdere OLDI-verbindingen waren gebaseerd op eigen proto-
collen zoals INTERCAUTRA of Datenübertragungs- und
Verteilungssystem (DÜV), die lopen via speciale punt-puntver-
bindingen of beperkte netwerken en die het gebruik vereisen van
gespecialiseerde apparatuur en programmatuur.
Voor de meerderheid van de nieuw geplande verbindingen werd
het gewenst geacht om over te stappen op een architectuur op
netwerkbasis en de internationale telecommunicatienormen toe te
passen. Hierdoor kunnen verbindingen op een goedkopere wijze
worden geïmplementeerd, omdat het aantal aansluitingen bij elk
Centre vermindert en het mogelijk wordt om gebruik te maken
van normaal verkrijgbare apparatuur en programmatuur.
Deze Eurocontrol-norm zorgt voor formalisering en uitbreiding
van de ShortTerm ICD. De ST-ICD is opnieuw geschreven
teneinde een meer nauwgezette specificatie te bieden die de
onderlinge samenwerking zal verbeteren en die daarnaast geschikt
is om de basis te vormen voor toekomstige ICD's om tegemoet te
komen aan de zich ontwikkelende vereisten voor Flight Data
Exchange (FDE), metinbegrip van een breder gebruik van geza-
menlijke netwerken en de introductie van nieuwe normen voor
onderste lagen. Deze Eurocontrol-norm bevat een minimumverza-
meling met functionaliteiten die met minimale aanpassingen
kunnen worden ondersteund door bestaande OLDI-implementa-
ties, waarbij ofwel gebruik wordt gemaakt van punt-
puntverbindingen of van pakketgeschakelde netwerken op basis
van Aanbeveling X.25 van het Comité Consultatif des Téléphones
etTélégraphes (CCITT), 1980 of lat er. Voor aanschaf kunnen
meer mogelijkheden worden gespecificeerd. Deze ICD vormt
geen beletsel voor overeenkomsten op bilaterale basis om verder
te gaan.
Voor installaties waarop men andere applicatieprotocollen wenst
te gebruiken naast of in de plaats van die welke in dit document
worden beschreven, kan ofwel een aanvraag voor een amende-
mentop hethuidige prot ocol worden ingediend of kan het
toegepaste protocol worden afscheiden door het gebruik van
andere virtuele verbindingen.
2. REIKWIJDTE
2.1. In dit Eurocontrol-normdocument wordt een interface voor data-
communicatie gespecificeerd voor de uitwisseling van
databerichten die betrekking hebben op vluchten tussen Area
Control Centres (ACC's). Een en ander wordt gepresenteerd in
de vorm van een Open Systems Interconnection (OSI) profiel
zoals gedefinieerd in het International Organisation for Standar-
disation/International Electrotechnical Commission (ISO/IEC)
Technical Report(TR) 10000-2 [Referent ie 3]. Hetprofiel heeft
zowel betrekking op onderste lagen (T-profiel) als op bovenste
lagen (A-profiel).
2.2. Dit Eurocontrol-normdocument is van toepassing op de volgende
scenario's:
— ondersteuning van OLDI zoals beschreven in Eurocontrol
Standard No001-92 Edition 1;
— ondersteuning van verzending van OLDI-applicatieberichten
van ACC's naar de Central Flow Management Unit (CFMU)
systemen.
2.3. De norm is van toepassing op verbindingen die gebruik maken
van ofwel:
— punt-puntverbindingen via huurlijnen, of
— punt-puntverbindingen via het openbare telefoonnet (Public
Switched Telephone Network, PSTN), of
— pakketgeschakelde datanetwerken of onderling verbonden
pakketgeschakelde datanetwerken die een interface bieden
conform CCITT-aanbeveling X.25, 1980 of later.2000R2082 — NL — 15.06.2002 — 001.001 — 166
▼B
OPMERKINGEN
1. De overeenkomst tussen Flight Plan Processing Systems
(FPPS's) wordt weergegeven in Figuur 1.
2. Figuur 1 illustreert geen potentiële back-up-verbindingen,
zoals PSTN, met betrekking waartoe wordt geadviseerd in
Bijlage 1.
Figuur 1
Overzicht van de interface
2.4. Gedetailleerde beveiligingsaspecten van de gespecificeerde data-
communicatie-interface worden niet verplicht gesteld door deze
norm. Bijlage bevat echter een specificatie van een basisbepaling
en van deze Eurocontrol-norm bevat aanvullend advies.
3. REFERENTIES
3.1. Inleiding
De volgende documenten en normen bevatten bepalingen die,
doordater in deze t ekstnaar wordtverwezen, bepalingen vormen
van deze Eurocontrol-norm.
Ten tijde van publicatie van deze Eurocontrol-norm waren de
genoemde uitgaven van de documenten waarnaar wordt verwezen
correct.
Met elke revisie van de International Civil Aviation Organisation
(ICAO) documenten waarnaar wordt verwezen wordt onmiddel-
lijk rekening gehouden door dit Eurocontrol-normdocument te
herzien.
Revisies van de andere documenten waarnaar wordt verwezen
zullen geen deel uitmaken van de bepalingen van deze Eurocon-
trol-norm totdat ze formeel zijn beoordeeld en in dit Eurocontrol-
normdocumentzijn opgenomen.
In het geval van conflicten tussen de vereisten van dit Eurocon-
trol-normdocument en de inhoud van deze andere documenten
waarnaar wordtverwezen, zal deze Eurocont rol-norm prevaleren.
3.2. Referenties
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
pakket mode and connected to public data networks by dedi-
cated circuit [ITU-T-aanbeveling X.25 (1993) (Rev. 1),
Interface tussen data terminal equipment (DTE) en data
circuit-terminating equipment (DCE) voor terminals die func-
tioneren in de pakket-modus en die via een speciale
verbinding zijn verbonden met openbare datanetwerken].2000R2082 — NL — 15.06.2002 — 001.001 — 167
▼B
2. ISO/IEC TR 10000-1:1992, Information technology —
Framework and taxonomy of International Standardized
Profiles: — Part1: Framework (2nd edit ion) [ISO/IEC TR
10000-1:1992, Informatietechnologie — Raamwerk en taxo-
nomie van internationaal genormaliseerde profielen: — Deel
1: Raamwerk (2e uitgave)].
3. ISO/IEC TR 10000-2:1994, Information technology —
Framework and taxonomy of International Standardized
Profiles — Part2: Principles and Taxonomy for OSI Profiles
(3rd edition) [ISO/IEC TR 10000-2:1994, Informatietechno-
logie — Raamwerk en taxonomie van internationale
genormaliseerde profielen — Deel 2: Principes en taxonomy
voor OSI-profielen (3e uitgave)].
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. [ITU-T-aanbeveling X.21 (1992) (Rev.
1), Interface tussen data terminal equipment (DTE) en data
circuit-terminating equipment (DCE) voor synchroon gebruik
van openbare datanetwerken].
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
[CCITT-aanbeveling X.21bis (1988), Gebruik op openbare
datanetwerken van data terminal equipment (DTE)
ontworpen voor samenwerking met synchrone 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) [ISO/IEC 7776:1994, Informatietechnologie — Tele-
communicatie en informatie-uitwisseling tussen systemen —
High-level beheerprocedures voor datalinks — Beschrijving
van de X.25 LAPB-compatibele DTE datalink-procedures
(2e uitgave)].
7. ISO/IEC 8208:1993, Information Technology — Data
communications — X.25 Pakket Layer Protocol for Data
Terminal Equipment(3rd edit ion) [ISO/IEC 8208:1993,
Informatietechnologie — Datacommunicatie — X.25 Pakket-
laagprotocol voor Data Terminal Equipment (3e uitgave)].
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 pakket-
switched data network using virtual calls [ISO/IEC ISP
10609-9:1992, Informatietechnologie — Internationaal genor-
maliseerde profielen TB, TC, TD en TE — Connection-mode
Transport Service over Connection-mode Network Service —
Deel 9: Van het subnetwerktype afhankelijke vereisten voor
netwerklaag, datalink-laag en fysieke laag ten aanzien van
permanente toegang tot een pakketgeschakeld datanetwerk
datgebruiktmaaktvan virt uele oproepen).
9. ISO/IEC 7498-1:1994, Information technology — Open
Systems Interconnection — Basic Reference Model: The
Basic Model (2nd edition) [ISO/IEC 7498-1:1994, Informa-
tietechnologie — Open Systems Interconnection —
Basisreferentiemodel: Het basismodel (2e uitgave)].
10. ISO/IEC 8348:1993, Information technology — Open
Systems Interconnection — Network Service Definition (1st
edition) [ISO/IEC 8348:1993, Informatietechnologie —
Open Systems Interconnection — Netwerkdienstdefinitie
(1e uitgave)].
11. ISO/IEC 8072:1994, Information technology — Open
Systems Interconnection — Transport service definition (2nd
edition) [ISO/IEC 8072:1994, Informatietechnologie — Open
Systems Interconnection — Transportdienstdefinitie
(2e uitgave)].
12. ISO/IEC 8878:1992, Information Technology — Telecommu-
nications and information exchange between systems — Use
of X.25 to provide the OSI connection-mode Network2000R2082 — NL — 15.06.2002 — 001.001 — 168
▼B
Service (2nd edition) [ISO/IEC 8878:1992, Informatietechno-
logie — Telecommunicatie en informatie-uitwisseling tussen
systemen — Gebruik van X.25 voor het leveren van de OSI
connection-mode netwerkdienst (2e uitgave)].
13. Eurocontrol Standard for On-Line Data Interchange (OLDI),
No001-92, Edition 1, 1992 [Eurocontrol-norm voor On-Line
Data Interchange (OLDI), No001-92, Uitgave 1, 1992].
14. ISO/IEC 9646-1:1994, Information technology — Open
Systems Interconnection — Conformance testing methodo-
logy and framework — Part1: General concept s (2nd
edition) [ISO/IEC 9646-1:1994, Informatietechnologie —
Open Systems Interconnection — Methodologie en raamwerk
voor testen van conformiteit — Deel 1: Algemene concepten
(2e uitgave)].
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Part 1 Integration Test Plan Version 1.0,
dated 10 May 1996 [Eurocontrol (Maastricht Upper Area
Control (UAC) Systems Division) FDE ICD Deel 1 Integratie
testplan versie 1.0, gedateerd 10 mei 1996].
16. Eurocontrol FDE ICD Part 1— Reliability, Availability and
Security — Technical Report version 1.0, dated 20 April
1997 [Eurocontrol FDE ICD Deel 1 — Betrouwbaarheid,
beschikbaarheid en beveiliging — Technisch rapportversie
1.0, gedateerd 20 april 1997].
17. ITU-T Recommendation X.32 (1993) (Rev. 1), Interface
between DTE and DCE for terminals operating in the pakket
mode and accessing a pakket switched public data through a
public switched telephone network or an integrated services
digital network or a circuit switched public data network
[ITU-T-aanbeveling X.32 (1993) (Rev. 1), Interface tussen
DTE en DCE voor terminals die functioneren in de pakket-
modus en toegang zoeken tot openbare pakketgeschakelde
data via een openbaar telefoonnetwerk of Integrated Services
Digital Network of een geschakeld openbaar datanetwerk].
18. ITU-T Recommendation E.164 (1991) (Rev. 1), Numbering
plan for the ISDN era [ITU-T-aanbeveling E.164 (1991)
(Rev. 1), Nummeringsplan voor hetISDN-t ijdperk].
19. ITU-T Recommendation X.75 (1993) (Rev. 1), Pakket-swit-
ched signalling system between public network providing
data transmission service [ITU-T-aanbeveling X.75 (1993)
(Rev. 1), Pakketgeschakeld signaleringssysteem tussen open-
bare netwerken die een dienst voor dataoverdracht leveren].
20. ITU-T Recommendation X.121 (1993), International numbe-
ring plan for public data networks [ITU-T-aanbeveling X.121
(1993), Internationaal nummeringsplan voor openbare data-
netwerken].
4. DEFINITIES, SYMBOLEN EN AFKORTINGEN
4.1. Definities
4.1.1. Ten behoeve van ditEurocont rol-normdocumentzullen de
volgende definities gelden:
4.1.2. Profile [profiel] : een verzameling van een of meer basisnormen
en, waar van toepassing, de aanduiding van gekozen klassen,
deelverzamelingen, opties en parameters van die basisnormen,
noodzakelijk voor het tot stand brengen van een bepaalde functie
[Referentie 2].
4.1.3. Profile Requirements List (PRL) [lijst met profielvereisten] :d e
profielvereisten worden uitgedrukt in de vorm van conformiteit-
vereisten en worden gepresenteerd in tabelvorm [Referentie 2].
4.1.4. T-profile [T-profiel] : transportprofiel dat een Connection mode
TransportService biedt[Referent ie 3].
4.1.5. A-profile [A-profiel] : applicatieprofiel dat een Connection-mode
TransportService vereist[Referent ie 3].
4.1.6. Protocol Implementation Conformance Statement (PICS)
[Conformiteitverklaring voor protocolimplementatie] : een verkla-
ring afgegeven door de leverancier van een OSI-systeem, waarin
wordt verklaard welke capaciteiten voor een gegeven OSI-
protocol zijn geïmplementeerd [Referentie 14].2000R2082 — NL — 15.06.2002 — 001.001 — 169
▼B
4.2. Symbolen en afkortingen
Ten behoeve van ditEurocont rol-normdocumentworden de
volgende symbolen en afkortingen gebruikt:
ACC Area Control Centre [gebiedscontrolecen-
trum]
AFI Authority and Format Identifier [instantie-
en formaataanduiding]
ASCII American Standard Code for Information
Interchange [Amerikaanse normcode voor
informatie-uitwisseling]
ATC Air Traffic Control [luchtverkeersleiding]ATCC Air Traffic Control Centre [luchtverkeerslei-
dingcentrum]
CAUTRA Coordinateur Automatique du Trafic Aérien
[automatische coördinator van luchtverkeer]
CCITT Comité consultatif international télégrap-
hique ett éléphonique (nu ITU-T)
[internationaal adviserend comité voor tele-
grafie en telefonie]
CFMU Central Flow Management Unit [centrale
eenheid voor verkeersstroombeheer]
CUG Closed User Group [gesloten gebruikers-
groep]
DCE Data Circuit-terminating Equipment [afsluit-
apparatuur voor datacircuits]
DCTS Digital Communications Terminal System
[terminal-systeem voor digitale communi-
catie]
DSP Domain Specific Part[domein-specifiek
onderdeel]
DTE Data Terminal Equipment [data-terminal-
apparatuur]
DÜV Datenübertragungs- und Verteilungssystem
[systeem voor dataoverdracht en -verzen-
ding]
FDE Flight Data Exchange [uitwisseling van
vluchtgegevens]
FEP Front-End Processor [front-eind-verwerker]FPDE Flight Plan related Data Exchange [gege-
vensuitwisseling met betrekking tot
vluchtplannen]
FPPS FlightPlan Processing Syst em [verwerkings-
systeem voor vluchtplannen]
ICAO International Civil Aviation Organisation
[internationale organisatie voor de burger-
luchtvaart]
ICD Interface Control Document [document voor
interfacebeheer]
IDI Initial Domain Identifier [eerste domeinaan-
duiding]
IDP Initial Domain Part [eerste domeinonder-
deel]
IEC International Electrotechnical Commission
[internationale elektrotechnische commissie]
INTERCAUTRA Inter-CAUTRA protocolISO International Organization for Standardiza-
tion [internationale organisatie voor
normalisatie]
ITU-T International Telecommunication Union —
Telecommunication Standardization Sector
[internationale telecommunicatie-unie —
sector voor normalisatie van telecommuni-
catie]
ISDN Integrated Services Digital Network [digi-
taal netwerk met geïntegreerde diensten]
LAPB Link Access Procedure Balanced
LSB Least Significant Bit [minst significante bit]2000R2082 — NL — 15.06.2002 — 001.001 — 170
▼B
M, m Mandatory [verplicht]
MSB Most Significant Bit [meest significante bit]MT Message Transfer [berichtenoverdracht]
NA NotApplicable [nietvan t oepassing]
NS Network Service [netwerkdienst]NSAP Network Service Access Point [toegangs-
punt tot netwerkdienst]
NSDU Network Service Data Unit [gegevenseen-
heid voor netwerkdienst]
O, O. <n> Optional, where <n> is a numeral for refe-
rencing [optioneel, waarbij <n> een getal is
voor referentie]
o, o. <n> Optional, where <n> is a numeral for refe-
rencing [optioneel, waarbij <n> een getal is
voor referentie]
OLDI On-Line Data Interchange [on-line gege-
vensuitwisseling]
OSI Open Systems Interconnection [onderlinge
verbinding tussen open systemen]
PICS Protocol Implementation Conformance
Statement [conformiteitverklaring voor
protocolimplementatie]
PLP Pakket Layer Protocol [pakketlaagprotocol]PRL Profile Requirements List [lijst met profiel-
vereisten]
PSTN Public Switched Telephone Network [open-
baar telefoonnetwerk]
ST-ICD Short Term Interface Control Document
[interfacebeheerdocument voor de korte
termijn]
SUT System Under Test [systeem wordt getest]
T<x> Timer (where <x> is a single or double
letter for referencing) [aftelklok (waarbij
<x> een enkele of dubbele letter voor refe-
rentiedoeleinden is]
TA Terminal Adaptor [terminal-adapter]
TSDU Transport Service Data Unit [transportdienst
gegevenseenheid]
TPDU Transport Protocol Data Unit [transportpro-
tocol gegevenseenheid]
TR ISO Technical Report[ISO t echnisch
rapport]
X Prohibited [verboden]
x Excluded [uitgesloten]<item> Conditional Item [voorwaardelijk item]
(afhankelijk van de waarde van hetit em)
4.3. Notaties
4.3.1. Ten behoeve van ditEurocont rol-normdocumentworden binaire
waarden of een reeks bits aangeduid in hexadecimalen met
gebruik van de notatie 'd'H, waarbij de letter d staat voor een
cijfer of een reeks hexadecimale cijfers.
4.3.2. Ten behoeve van ditEurocont rol-normdocumentwordtde hexa-
decimale weergave van een bitreeks gevormd door 4 bits
tegelijk over te brengen van het meest significante bit (MSB)
naar hetminstsignificant e bit(LSB).
OPMERKING Tenzij anders gespecificeerd in de internationale
normen waarnaar wordt verwezen wordt een
reeks bits verzonden van MSB naar LSB.
4.3.3. Ten behoeve van dit Eurocontrol-normdocument zal de status van
de ondersteuning voor functies van een basisnorm, of deze Euro-
control-norm, worden afgebeeld in hoofdletters (bijv. M, O, O.
<n>, X). De exacte betekenis van elke statusaanduiding staat
beschreven in de bijlagen van deze Eurocontrol-norm vooraf-
gaand aan hetgebruik.2000R2082 — NL — 15.06.2002 — 001.001 — 171
▼B
4.3.4. Ten behoeve van hetdefiniëren van hetFDE ICD Part1 profiel
in dit Eurocontrol-normdocument zal de status van de ondersteu-
ning voor functies van een basisnorm of deze Eurocontrol-norm
worden afgebeeld in kleine letters (bijv. m, o, o. <n>, x).
OPMERKING Het resultaat is een verdere verfijning van de
functies van de basisnormen die voorwaardelijk,
optioneel of waardeafhankelijk zijn (zie E.3.1).
5. TECHNISCH OVERZICHT
5.1. Protocolstapeling
OPMERKING De protocolstapeling voor het profiel van deze
Eurocontrol-norm staat afgebeeld in Figuur 1.
De figuur plaatst de protocollen in het kader van
het OSI Basic Reference Model [Referentie 9]
door de stapeling op een lijn te brengen met de
bijbehorende OSI-lagen. De protocolstapeling is
echter een specificatie voor pre-OSI systemen en
ondersteunt niet de vele functies die zijn toege-
staan in de OSI-protocollen van de bijbehorende
OSI-lagen.
Figuur 2
Profiel protocolstapeling
5.2. Structuur van het profiel
OPMERKINGEN
1. Zoals afgebeeld in Figuur 2 combineert de profielstapeling
diverse protocollen voor lagere lagen, waarvan alleen het
X.25-pakketlaagprotocol (PLP) [Referentie 1] en de daarbijbehorende ondersteunende protocollen, X.21 [Referentie 4]
en X.21bis [Referentie 5] zijn gedefinieerd in bestaande ISO/
IEC en International Telecommunication Union-Telecommuni-
cation Standardization Sector (ITU-T) normen. De andere
protocollen voor hogere lagen zijn gedefinieerd in bijlagen
(Bijlagen A, B en C) bij dit Eurocontrol-normdocument.
2. Conformiteitvereisten voor het profiel kunnen naar deze speci-
ficaties verwijzen op een gelijk niveau met externe normen enstaan vermeld in Sectie 6. De gedetailleerde vereisten worden
vermeld met gebruik van het tabelformaat van PRL's
(Bijlage E) en PICS-proforma's (proforma's voor protocollen
gedefinieerd in de bijlagen staan aangegeven in). Het gebruik
van deze PRL's en PICS-proforma's bij ontwikkeling en/of
aanschaf wordt verklaard in Bijlage E.2000R2082 — NL — 15.06.2002 — 001.001 — 172
▼B
5.3. Relatie met eerdere versies van de specificatie
OPMERKINGEN
1. Dit profiel is gebaseerd op de ST-ICD ontwikkeld door de
voormalige OLDI Technical Sub-Group. De protocollen en
pakketstructuren die in dit Eurocontrol-normdocument zijn
gedefinieerd vormen een compatibele deelverzameling van die
van de ST-ICD, met uitzondering van het feit dat deze Euro-
control-norm meer gedetailleerde eisen stelt aan het gebruik
van de X.25 PLP, verplichte ondersteuning van het M-bit
omvat en correcties aanbrengt in de inconsistente specificatie
van de Authority and Format Identifier (AFI) waarde in het
Network Service Access Point (NSAP) adres.
2. De grootste verandering in de stijl van dit Eurocontrol-norm-
document heeft betrekking op de structuur van de ICD-
specificatie. Het Message Transfer Protocol (Bijlage A) is
gescheiden van het ondersteunende T-profiel. Dit zal het
gebruik van andere T-profielen vergemakkelijken als dit nood-
zakelijk wordt voor ondersteuning van zich ontwikkelende
FDE-vereisten.
3. Die gedeelten van de ST-ICD-specificatie die te maken hebben
met beheer van X.25-virtuele verbindingen en begrenzende
applicatieberichten kunnen nu worden gevonden in het
Berichtkopprotocol (Bijlage B), dat een minimale transport-
laag voor FDE vormt.
6. PROFIELVEREISTEN
6.1. Conformiteitvereisten
6.1.1. Een implementatie waarvan wordt geclaimd dat deze conform is
aan deze specificatie zal aan de vereisten voldoen zoals aange-
geven in de secties 6.2 en 6.3 hieronder.
6.1.2. Een conformiteitclaim zal worden ondersteund door een Profile
Implementation Conformance Statement [conformiteitverklaring
voor profielimplementatie] zoals beschreven in Bijlage D en
Bijlage E.
6.2. Vereisten voor de bovenste laag
6.2.1. Een conformerende implementatie zal voldoen aan de vereisten
van de basisnorm, zoals aangegeven in Bijlage A.
6.2.2. Een conformerende implementatie zal voldoen aan de beper-
kingen zoals aangegeven in de Profile Requirements List [lijst
metprofielvereist en] in Bijlage E.7.
6.3. Vereisten voor de onderste laag
6.3.1. Vereisten voor de transportlaag
6.3.1.1. Een conformerende implementatie zal voldoen aan de vereisten
van de basisnorm, zoals aangegeven in Bijlage B.
6.3.1.2. Een conformerende implementatie zal voldoen aan de beper-
kingen zoals aangegeven in de Profile Requirements List [lijst
metprofielvereist en] in Bijlage E.8.1.
6.3.1.3. Een conformerende implementatie zal voldoen aan de vereiste
van ondersteuning voor Transport Service Data Unit (TSDU)-
structuren tot en met 4 097 bytes.
OPMERKING De eerste byte van de TSDU komt overeen met
een veld van de Berichtkop (zie A.4.10 en B.4.4),
waardoor maximaal 4096 bytes overblijven voor
gebruikersgegevens.
6.3.2. Vereisten voor de netwerklaag
6.3.2.1. Een conformerende implementatie zal voldoen aan de vereisten
van ISO/IEC 8208 [Referentie 7] overeenkomstig de protocoltoe-
kenning zoals aangegeven in Bijlage C.
6.3.2.2. Een conformerende implementatie zal voldoen aan de beper-
kingen zoals aangegeven in de Profile Requirements List [lijst
metprofielvereist en] in Bijlage E.8.2.2000R2082 — NL — 15.06.2002 — 001.001 — 173
▼B
6.3.2.3. Een conformerende implementatie zal, als data terminal equi-
pment (DTE)-DTE-gebruik wordt ondersteund, in staat zijn om
door middel van systeembeheermechanismen de keuze van de
rol van DTE of data circuit-terminating equipment (DCE) voor
hetDTE-DTE gebruik t e configureren.
6.3.2.4. Een conformerende implementatie zal, in elk van de beide rollen
zoals gedefinieerd in 6.3.2.3, in staat zijn om een verbinding te
starten volgens de specificatie van Bijlage C d.w.z. het protocol
is volledig symmetrisch.
OPMERKINGEN Sommige bestaande implementaties op basis
van de ST-ICD zijn mogelijk niet in staat om
netwerkverbindingen te starten volgens het
protocol van Bijlage C.
6.3.2.5. Een conformerende implementatie zal gedurende een tijdsperiode
overeenkomen met de faciliteit voor Non-standard Default Pakket
Sizes, metde waarde 256 voor beide verzendricht ingen.
6.3.2.6. Een conformerende implementatie zal NSAP-adressen gebruiken
zoals gedefinieerd in Bijlage C.
6.3.2.7. Een conformerende implementatie zal het D-bit op 0 zetten in
CALL REQUEST, CALL ACCEPTED en DATA-pakketten.
OPMERKINGEN Als D=0 wordt ingesteld in CALL REQUEST
en CALL ACCEPTED-pakketten heeft dit tot
gevolg dat geen afleveringsbevestiging wordt
gebruikt.
6.3.3. Vereisten voor de datalink-laag
6.3.3.1. Een conformerende implementatie zal voldoen aan de conformi-
teitvereisten van ISO/IEC 7776 [Referentie 6] voor het Link
Access Protocol Balanced (LAPB) Single Link Protocol.
6.3.3.2. Een conformerende implementatie zal ook voldoen aan de beper-
kingen zoals aangegeven in de Profile Requirements List [lijst
metprofielvereist en] in Bijlage E.8.3.
6.3.4. Vereisten voor de fysieke laag
Een conformerende implementatie zal voldoen aan de conformi-
teitvereisten van ISO/IEC ISP 10609-9 clausule 7 [Referentie 8].
7. TESTMETHODEN
OPMERKINGEN
1. Een benadering voor het testen van de conformiteit van imple-
mentaties van deze specificatie wordt beschreven in Bijlage F.
2. Het gebruik van de PRL's en PICS-proforma's die ten behoeve
van documentconformiteit bij deze specificatie worden gele-
verd wordt beschreven in Bijlage E.2000R2082 — NL — 15.06.2002 — 001.001 — 174
▼B
BIJLAGE A (Normatief)
PROTOCOL VOOR BERICHTENOVERDRACHT (MESSAGE
TRANSFER PROTOCOL)
A.1. Inleiding
Deze specificatie bevat een definitie van een protocol voor het
implementeren van een eenvoudige dienst voor berichtenoverdracht
voor applicaties waar de noodzaak bestaat voor het uitwisselen van
vluchtgegevens.
A.2. Geïmplementeerde dienst
Het Message Transfer (MT) protocol implementeert de volgende
niet-bevestigde diensten:
MT-Associate: breng een overdrachtsassociatie tot stand voor appli-
catieberichten;
MT-Data: draag een applicatiebericht over dat bestaat uit tekens
volgens de American Standard Code for Information Interchange
(ASCII);
MT-Abort: beëindig een overdrachtsassociatie voor applicatiebe-
richten.
A.3. Veronderstelde dienst
Dit Message Transfer protocol veronderstelt een deelverzameling
van de Connection-mode Transport Service zoals gedefinieerd in
ISO/IEC 8072 [Referentie 11], zoals die welke wordt geboden door
het protocol gedefinieerd in Bijlage B van deze Eurocontrol-norm.
A.4. Protocolspecificatie
A.4.1. Inleiding
In de hierna volgende tekst wordt alleen de werking van een door
een applicatie gestarte Message Transfer-associatie beschreven.
Verdere associaties kunnen worden ondersteund het dezelfde
netwerkinterface door herhaling van deze procedures voor elke
onderliggende transportverbinding.
A.4.2. Typen data
In deze bijlage worden vier typen applicatieberichten onderscheiden
die equivalentzijn aan die welke zijn gedefinieerd in Eurocont rol
Standard No001-3-92 Edition 1:
Systeemberichten: deze berichten zullen worden gebruikt voor
bewaking van verbindingen (HEARTBEAT-bericht) en applicatiebe-
heer (STARTUP- en SHUTDOWN-berichten).
Operationele berichten: deze berichten zullen worden gekoppeld
aan een specifieke operationele context en worden gedefinieerd in
de Eurocontrol-normen en -documenten die gebruik maken van
deze norm voor gegevensuitwisseling. In het Eurocontrol-normdocu-
ment voor On-Line Data Interchange worden operationele berichten
zoals de Activation (ACT), Advanced Boundary Information (ABI)
en Logical Acknowledgement(LAM) bericht en gedefinieerd.
Operator-berichten: deze berichten zullen vrije tekst bevatten. Hun
gebruik zal bilateraal worden overeengekomen. Ze kunnen bijvoor-
beeld worden gebruikt om testinformatie uit te wisselen of om de
andere kant te informeren over acties van de operator.
Statusberichten: hetgebruik en de inhoud van deze bericht en zal
bilateraal worden overeengekomen. Ze kunnen bijvoorbeeld worden
gebruikt om informatie over systeembeheer uit te wisselen.
OPMERKINGEN1. Het gebruik van Systeemberichten vormt onderdeel van de
werking van dit protocol en hun formaat wordt gespecificeerd
in paragraaf A.4.10.3 van deze bijlage.
2. Het gebruik en formaat van Statusberichten is onderworpen aan
bilaterale overeenkomsten en wordt in deze Eurocontrol-norm
niet verder gespecificeerd.2000R2082 — NL — 15.06.2002 — 001.001 — 175
▼B
3. De status van het protocol bepaalt welke typen berichten kunnen
worden verzonden, zoals gespecificeerd in de volgende para-
grafen.
A.4.3. Tot stand brengen van associatie
A.4.3.1. Het protocol bevindt zich bij aanvang in de IDLE-status.A.4.3.2. De MT-Associate-Request-primitieve wordt uitgevoerd om een
applicatieassociatie tot stand te brengen en het protocol in de status
DATA_READY te brengen. De primitieve dient zowel door de
lokale applicaties als door de applicaties op afstand te worden
aangeroepen.
A.4.3.3. Het is allereerst noodzakelijk om een onderliggende transportverbin-
ding tot stand te brengen, volgens de T-connect-primitieve-
procedures beschreven in Bijlage B, paragraaf B.4.1, waarna het
protocol in de status READY komt. Op dit punt kunnen alleen
Systeemberichten (en mogelijk, door bilaterale overeenkomst,
Operator-berichten) worden verzonden. Om een Systeem- of
Operator-bericht te verzenden gebruikt de verzender de T-Data-
primitieve (zie B.4.4), met het bericht als parameter.
A.4.3.4. Er wordt dan een STARTUP-bericht (systeembericht) verzonden,
aftelklok Tr (zie A.4.7) wordt gestart en het protocol komt in de
status ASSOCIATION_PENDING. Als aftelklok Tr afloopt terwijl
het protocol zich nog steeds in deze status bevindt, zal het
STARTUP-berichtopnieuw worden verzonden en zal de aft elklok
opnieuw worden gestart.
OPMERKING Het protocol blijft in de status ASSOCIATION_PEN-
DING totdat een STARTUP-bericht is ontvangen.
Continue tijdsoverschrijdingen van de Tr aftelklok
kunnen lokaal worden gesignaleerd.
A.4.3.5. Ontvangst van het STARTUP-bericht zal de volgende acties veroor-
zaken:
— in de status ASSOCIATION_PENDING wordt een verder
STARTUP-bericht verzonden, het protocol komt in de status
DATA_READY en de MT-Associate-Indication-primitieve
wordtgesignaleerd;
— in elke andere status wordt het bericht genegeerd.
A.4.3.6. Ontvangst van het STARTUP-bericht in de status ASSOCIATION_-
PENDING correspondeertmetofwel:
— de applicatie op afstandgaf een MT-Associate-Request-primi-
tieve af en het Message Transfer protocol ervan is in de status
ASSOCIATION_PENDING gekomen, of
— het Message Transfer protocol op afstand reageert op een eerder
ontvangen STARTUP-bericht en is in de status DATA_READY
State gekomen.
OPMERKING Deze onzekerheid ontstaat omdat hetzelfde bericht
wordt gebruikt voor STARTUP en voor reactie op
STARTUP. Als gevolg daarvan ontvangt het
Message Transfer protocol dat eerst in de status
DATA_READY kwam een verder STARTUP-bericht.
Zoals gespecificeerd in A.4.3.5 wordt dit STARTUP-
bericht genegeerd.
A.4.3.7. Nadat STARTUP-berichten zijn uitgewisseld komt de associatie tot
stand en kunnen alle aangegeven typen berichten worden overge-
dragen (DATA_READY status).
A.4.4. Dataoverdracht
Andere typen berichten worden op dezelfde manier overgebracht als
Systeemberichten, met gebruik van de T-Data-dienst, waarbij het
bericht als parameter fungeert. Dit correspondeert met de MT-
Data-Request en de MT-Data-Indication dienstprimitieven.
OPMERKING Elk bericht wordt als een enkele TSDU verzonden:
op dit niveau vindt geen aaneenschakeling of
segmentatie van berichten plaats.2000R2082 — NL — 15.06.2002 — 001.001 — 176
▼B
A.4.5. Ordelijke vrijgave van de associatie
A.4.5.1. De Message Transfer-associatie tussen twee applicaties kan door elk
van beide worden vrijgegeven. Ditcorrespondeertmetde MT-
Abort-Request dienstprimitieve.
A.4.5.2. De volgende acties zullen plaatsvinden:
— in de status DATA_READY zal een SHUTDOWN-bericht
(systeembericht) worden verzonden, de aftelklokken Tr en Ts
zullen worden gestopt en de transportverbinding zal worden vrij-
gegeven;
— in de status ASSOCIATION_PENDING zal een SHUTDOWN-
bericht (systeembericht) worden verzonden, aftelklok Tr zal
worden gestopt en de transportverbinding zal worden vrijge-
geven;
— in de status READY zal de transportverbinding worden vrijge-
geven;
— voor het overige vindt geen actie plaats.
OPMERKING Het SHUTDOWN-bericht is geen vroege waarschu-
wing — de associatie wordt onmiddellijk beëindigd.
Er komt geen bevestiging van dit bericht van de
andere zijde.
A.4.5.3. Ontvangst van een SHUTDOWN-bericht zal de volgende acties
veroorzaken:
— in de status DATA_READY zal aftelklok Ts (zie A.4.7) worden
gestopt, wordt MT-Abort-Indication gesignaleerd en komt de
interface in de status ASSOCIATION_PENDING zonder een
STARTUP-berichtt e verzenden;
— in elke andere status wordt geen actie ondernomen.
A.4.6. Opnieuw tot stand brengen van de associatie
De applicatie die de vrijgave van de associatie heeft gestart heeft de
verantwoordelijkheid, als ze gereed is, om de applicatieassociatie en
eventuele lagere niveaus opnieuw tot stand te brengen (indien nood-
zakelijk).
OPMERKING Als de vrijgave van de associatie heeft geresulteerd
in de vrijgave van de onderliggende netwerkverbin-
ding dient de procedure voor het tot stand brengen
van de associatie zoals gespecificeerd in
paragraaf A.4.3 te worden gevolgd.
A.4.7. Integriteit van de associatie
A.4.7.1. De integriteit van de associatie tussen twee applicaties wordt
verzorgd door de idle heartbeat-faciliteit.
A.4.7.2. Bij het ingaan van de status DATA_READY en bij verzending van
elk type bericht over de transportverbinding zal een configureerbare
aftelklok Ts (opnieuw) worden gestart. Als de klok Ts afloopt in de
status DATA_READY zal een HEARTBEAT-bericht (Systeembe-
richt) worden verzonden (en zal de klok opnieuw worden gestart).
A.4.7.3. Op soortgelijke wijze zal bij het ingaan van de status DATA_-
READY en bij ontvangst van elk bericht behalve een STARTUP-berichtover de verbinding een configureerbare aft elklok Tr
(opnieuw) worden gestart. Als de aftelklok Tr afloopt in de status
DATA_READY wordt MT-Abort-Indication gesignaleerd, wordt de
verzending van alle berichten gestopt, wordt klok Ts gestopt en
wordt klok Tr opnieuw gestart. De interface bevindt zich in de
status ASSOCIATION_PENDING.
OPMERKING De applicaties zullen zich herstellen en opnieuw
synchroniseren door middel van de uitwisseling van
STARTUP-berichten (zie A.4.3).
A.4.8. Onordelijke vrijgave van de associatie
A.4.8.1. Een abnormale vrijgave van de associatie kan plaatsvinden als:
— de transportverbinding faalt (bijv. lijnuitval, protocolfout),
— een van de twee applicaties of systemen faalt (dit kan worden
veroorzaakt door fouten in apparatuur of programmatuur; in
sommige gevallen kan de onderliggende transportverbinding
nog steeds werken).2000R2082 — NL — 15.06.2002 — 001.001 — 177
▼B
OPMERKING Volgens de definitie van het transportprocotol in
bijlage B bestaat er geen end-to-end transportver-
binding. Als gevolg daarvan is het falen van de
transportverbinding een direct gevolg van de
netwerkverbindingsfout.
A.4.8.2. Een applicatie- of systeemfout kan worden gedetecteerd door de
afloop van een aftelklok voor de ontvangst van een verwacht
HEARTBEAT-bericht(zie A.4.7) van deze applicat ie.
A.4.9. Herstel bij fouten
A.4.9.1. Er dienen twee gevallen te worden overwogen:
— na een mislukking van een transportverbinding;
— na een applicatiefout.
A.4.9.2. In beide gevallen omvat het opnieuw tot stand brengen de normale
procedure voor het tot stand brengen van associatie (zie A.4.3), met
inbegrip van de uitwisseling van STARTUP-berichten.
OPMERKING In het geval van een fout op het applicatieniveau die
er niet toe leidt dat de onderliggende verbinding
wordt vrijgegeven kan het foute systeem een SHUT-
DOWN-bericht verzenden (d.w.z. L_shutdown
handmatig aangeroepen of als onderdeel van de
applicatielogica) alvorens te trachten om de verbin-
ding opnieuw te starten. Hierdoor wordt de
aflooptijd Tr van de applicatie op afstand bekort,
wat kan resulteren in een sneller herstel met minder
kans op verlies van gegevens.
A.4.10. Berichtstructuren
A.4.10.1. Algemene berichtstructuur
Alle berichten bestaan uit een veld van het type geheel getal
(„TYP”) in hetbereik 1…63 gevolgd door de body van hetbericht .
Het veld „TYP” is gecodeerd in een byte als een ASCII-teken door
toevoeging van '40'H aan de binaire weergave van het veld (bijv. de
waarde 3 wordtgecodeerd als '43'H, t eken „C”). De body van het
bericht bestaat uit ASCII-tekens gecodeerd een per byte. Hierdoor
ontstaat het volgende formaat:
TYP Body van bericht
byte 1 byte 2 … byte n
A.4.10.2. Lengte van bericht- body
Bericht-bodies met een lengte tot en met 4 096 bytes zullen worden
ondersteund.
A.4.10.3. Formaten systeemberichten
Systeemberichten worden gecodeerd met TYP = 4, gecodeerd als
'44'H. De bericht-body bestaat uit twee bytes, als volgt gecodeerd:
— STARTUP-bericht: '3031'H (ASCII digits "01");
— SHUTDOWN-bericht: '3030'H (ASCII digits "00");— HEARTBEAT-bericht: '3033'H (ASCII digits "03
A.4.10.4. Overige berichtstructuren
Het veld TYP definieert het berichttype, gecodeerd zoals hierboven
beschreven:
— waarde 1 (gecodeerd als
'41'H)Operationele berichten;
— waarde 2 (gecodeerd als
'42'H)Operator-berichten;
— waarde 5 (gecodeerd als
'45'H)Statusberichten.2000R2082 — NL — 15.06.2002 — 001.001 — 178
▼B
OPMERKINGEN
1. Het formaat van de bericht-body voor Statusberichten valt buiten
het bestek van dit Eurocontrol-normdocument.
2. Het formaat voor Operationele berichten wordt gespecificeerd in
Eurocontrol-normen en documenten waarin berichtenapplicaties
zoals On-Line Data Interchange worden gedefinieerd
[Referentie 13].
3. Operator-berichten bestaan uit afdrukbare ASCII-tekst. Als deze
berichten worden ondersteund dient een gebruikersinterface te
worden geleverd om ontvangen berichten af te beelden en om
berichten te kunnen opstellen voor verzending.
A.5. Tabellen met protocolstatusovergangen
A.5.1. Inleiding
Onderstaande statustabellen bevatten de definitieve specificatie van
hetprot ocol. In hetgeval van verschil metde hierboven vermelde
hoofdtekst zal onderstaande specificatie prevaleren.
OPMERKING De gebruikte notatie om status, gebeurtenissen,
aftelklokken en acties te beschrijven is gebaseerdop de ST-ICD. De volgende definities en daaruit
resulterende acties zijn echter herzien en kunnen
afwijken van de ST-ICD.
A.5.2. Statusdefinities
Tabel 1
Statusdefinities
Status Statusbeschrijving Aanvullende statusinformatie
status 0 IDLE Geen transportverbinding
status 1 READY Transportverbinding tot stand
gebracht, lokale gebruiker down,
gebruiker op afstand down
status 2 ASSOCIATION_PEN-
DINGTransportverbinding tot stand
gebracht, lokale gebruiker up,
gebruiker op afstand down
status 3 DATA_READY Lokale gebruiker up, gebruiker op
afstand up
A.5.3. Mogelijke gebeurtenissen
Tabel 2
Mogelijke gebeurtenissen
Gebeurtenisbeschrij-
vingAanvullende statusinformatie
L_data Aanduiding dat data (Operationeel-, Operator- of Statusbericht)
dientt e worden verzonden van de lokale naar de gebruiker op
afstand (MT-Data Request-primitieve)
L_shutdown Er is een opdracht gegeven om de lokale gebruiker te stoppen
(MT-AbortRequest )
L_startup Er is een opdracht gegeven om de lokale gebruiker te starten (MT-
Associate Request)
R_data Geeft aan dat data zijn ontvangen van de gebruiker op afstand (T-
Data Indication, TYP ≠„System”)
R_heartbeat Er is een HEARTBEAT-bericht ontvangen van de gebruiker op
afstand (T-Data Indication, TYP = „System”, Berichtcode =
HEARTBEAT)
R_shutdown Er is een SHUTDOWN-bericht ontvangen van de gebruiker op
afstand (T-Data Indication, TYP = „System”, Berichtcode =
SHUTDOWN)2000R2082 — NL — 15.06.2002 — 001.001 — 179
▼B
Gebeurtenisbeschrij-
vingAanvullende statusinformatie
R_startup Er is een STARTUP-bericht ontvangen van de gebruiker op
afstand (T-Data Indication, TYP = „System”, Berichtcode =
STARTUP)
Ts_timeout Afloop van aftelklok Ts
Tr_timeout Afloop van aftelklok Tr
TC_disconnect Er is een aanduiding van een vrijgave van een transportverbinding
ontvangen (T-Disconnect Indication)
TC_setup Gebeurtenis (bijv. expliciete opdracht, applicatieverzoek) dat een
T-Connect Request-primitieve veroorzaakt
A.5.4. Aftelklokken
Tabel 3
Aftelklokken
Aftelklok Aftelklok-informatie
Tr Time-outals een HEARTBEAT of een dat aberichtwordt
verwacht
Ts Time-outvoor verzenden van een HEARTBEAT naar de
gebruiker op afstand
De waarde van deze aftelklokken zal zodanig zijn dat Tr = 2Ts +
doorzendtijd.
OPMERKING Gebruikelijke waarden voor deze aftelklokken zijn:
Ts = 30s, Tr = 70s.
A.5.5. Tabel met statusovergangen
Tabel 4
Statusovergangen
Status Gebeurtenis Te ondernemen acties Nieuwe status
state 0 TC_setup De transportlaag tracht de verbin-
ding(en) voor de onderste laag in
te stellen tussen de lokale en de
gebruikers op afstand; als de
verbinding met succes tot stand is
gebrachtwordtde gebruiker daar-
over geïnformeerd (1)status 1
TC_disconnectHet syst eem neemt de benodigde
acties maar blijft in status 0status 0
L_data Genegeerd status 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Negeren (gebeurtenis dient niet
voor te komen)status 0
R_heartbeat
R_shutdown
R_startup2000R2082 — NL — 15.06.2002 — 001.001 — 180
▼B
Status Gebeurtenis Te ondernemen acties Nieuwe status
state 1 L_startup De lokale gebruiker zendt een
STARTUP-berichtnaar de
gebruiker op afstand, aftelklok Tr
wordtgest art(2)status 2
R_startup De lokale gebruiker ontvangt een
STARTUP-berichtvan de
gebruiker op afstand, dit
STARTUP-berichtwordtgene-
geerd aangezien een L_startup
gebeurtenis niet heeft plaatsge-
vondenstatus 1
L_data Genegeerd status 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Genegeerd status 1
Ts_timeout
L_shutdown De transportverbinding is vrijge-
gevenstatus 0
TC_disconnectDe lokale gebruiker wordt
geïnformeerd dat de transportver-
binding is verbroken (bijv. als
gevolg van een foutof een
afsluiten van het systeem op
afstand)status 02000R2082 — NL — 15.06.2002 — 001.001 — 181
▼B
Status Gebeurtenis Te ondernemen acties Nieuwe status
state 2 R_startup De lokale gebruiker ontvangt een
STARTUP-berichtvan de
gebruiker op afstand; de aftel-
klokken Tr en Ts worden gestart;
de lokale gebruiker wordtgeïnfor-
meerd datdat a kunnen worden
verzonden via de associatie en de
ontvangst van het STARTUP-
berichtwordtexplicietmedege-
deeld door te antwoorden met een
ander STARTUP-bericht(3)status 3
Tr_timeout De lokale gebruiker zendt opnieuw
een STARTUP-berichtals hij
binnen een gespecificeerde tijds-
periode Tr geen STARTUP-bericht
van de gebruiker op afstand heeft
ontvangen, aftelklok Tr wordt
opnieuw gestartstatus 2
L_startup Genegeerd status 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeoutTC_setup
L_shutdown De lokale gebruiker krijgt opdracht
om de associatie af te sluiten: er
wordteen SHUTDOWN-bericht
verzonden, aftelklok Tr wordt
gestopt en de transportverbinding
wordtvrijgegevenstatus 0
TC_disconnectDe lokale gebruiker wordt
geïnformeerd dat de transportver-
binding verbroken is (bijv. als
gevolg van een fout), aftelklok Tr
wordt gestopt en de associatie
wordtafgebrokenstatus 02000R2082 — NL — 15.06.2002 — 001.001 — 182
▼B
Status Gebeurtenis Te ondernemen acties Nieuwe status
state 3 L_data Aftelklok Ts wordt opnieuw
gestartstatus 3
R_data Aftelklok Tr wordt opnieuw
gestartstatus 3
R_heartbeat
R_startup Als een STARTUP-bericht is
ontvangen van de gebruiker op
afstand wordt dit beschouwd als
een bevestiging van een eerder
verzonden STARTUP-bericht;
aftelklok Tr wordt niet opnieuw
gestartstatus 3
Ts_timeout Er wordt een HEARTBEAT-
berichtverzonden en aft elklok Ts
wordtopnieuw gest artstatus 3
L_startup Genegeerd status 3 (4)
TC_setup
R_shutdown Aftelklok Ts wordt gestopt; MT-
Abort-Indication wordt gesigna-
leerd aan de lokale gebruikerstatus 2
Tr_timeout Aftelklok Ts wordt gestopt. MT-
Abort-Indication wordt gesigna-
leerd aan de lokale gebruiker;
aftelklok Tr wordt opnieuw gestartstatus 2
L_shutdown Er wordt een SHUTDOWN-
berichtverzonden; de aft elklokken
Tr en Ts worden gestopt en de
transportverbinding wordt vrijge-
gevenstatus 0
TC_disconnectDe lokale gebruiker wordt
geïnformeerd dat de transportver-
binding verbroken is (bijv. als
gevolg van een fout); de aftel-
klokken Tr en Ts worden gestopt
en de associatie wordt afgebrokenstatus 0
OPMERKINGEN
(1) Bij het ingaan van status 0 kan worden verondersteld dat de TC_setup gebeurtenis automatisch
wordtgegenereerd.
(2) Alleen als status 1 ingaat via een automatisch gegenereerde TC_setup gebeurtenis zoals
beschreven in status 0 kan de L_startup gebeurtenis automatisch worden gegenereerd.
(3) Deze methode garandeert dat een ontvangen STARTUP-bericht van een gebruiker op afstand altijd
wordt bevestigd door een STARTUP-bericht.
(4) Sommige bestaande implementaties, die dateren van voor dit Eurocontrol-normdocument kunnen
deze gebeurtenis behandelen als TC_disconnect, d.w.z. terug naar status 0.2000R2082 — NL — 15.06.2002 — 001.001 — 183
▼B
A.5.6. Diagram met statusovergangen
OPMERKING Het protocol is beschreven in Figuur A.1 in de vorm
van een statusovergangdiagram. Het diagram is
alleen bedoeld ter informatie: in het geval van
tegenstrijdigheid tussen het diagram en boven-
staande statustabellen zullen laatstgenoemden
prevaleren.
Figuur A.1
Protocol voor bestandsoverdracht: diagram met statusovergangen2000R2082 — NL — 15.06.2002 — 001.001 — 184
▼B
BIJLAGE B (Normatief)
BERICHTKOPPROTOCOL (MESSAGE HEADER PROTOCOL)
B.1. Inleiding
Deze bijlage bevat een definitie van het Berichtkopprotocol, een
minimaal transportprotocol dat dient te worden gebruikt voor applica-
ties zoals OLDI.
B.2. Geïmplementeerde dienst
B.2.1. Het Berichtkopprotocol komt overeen met een deelverzameling van
de Connection-mode transport Service, zoals gedefinieerd in ISO/
IEC 8072 [Referentie 11] en omvat de volgende dienstprimitieven.
T-Connect: breng een transportverbinding tot stand voor een appli-
catie
T-Data: breng ASCII data over
T-Disconnect: beëindig de transportverbinding van een applicatie
B.2.2. De dienst biedt geen ondersteuning voor multiplexing, foutherstel of
segmentatie en opnieuw samenvoegen.
B.3. Veronderstelde dienst
Het protocol veronderstelt de aanwezigheid van een betrouwbare
basisnetwerkdienst zoals geleverd door het X.25 Pakket Layer
Protocol.
OPMERKING: Slechts één enkele transportverbinding wordt onder-
steund op elke netwerkverbinding.
B.4. Protocolspecificatie
B.4.1. Tot stand brengen van de verbinding
De T-Connect-primitieve zal worden geïmplementeerd door het
gebruik van de N-Connect-dienst van de onderliggende netwerk-
dienst. Er is sprake van een directe correspondentie tussen de twee
verzamelingen (verzoek, aanduiding) primitieven. Als alternatief kaneen bestaande netwerkverbinding worden gebruikt (bijv. een die tot
stand is gekomen door systeembeheermechanismen).
Aanbevelingen
1. In het laatste bovengenoemde geval dient de netwerkverbinding
voor gebruik in de uitgangstoestand te worden teruggebracht. De
N-Connect-primitieve kan automatisch opnieuw worden afgegeven
als binnen een bepaalde tijd geen antwoord wordt ontvangen.
2. Als dit automatisch opnieuw proberen is geïmplementeerd dient
ongeveer elke 15 seconden een nieuwe poging te worden onder-
nomen.
B.4.2. Vermijden van redundante netwerkverbindingen
Als er een N-Connect-Request-primitieve uitstaat (d.w.z. er is geen
bijbehorende N-Connect-Confirm of N-Disconnect-primitieve gesig-
naleerd) en er een N-Connect-Indication wordt gesignaleerd, dan zal
de binnenkomende poging om een netwerk op te zetten worden afge-
wezen of gewist door te antwoorden met een N-Disconnect-Request-
primitieve, alleen als aan beide volgende voorwaarden is voldaan:
— het aanroepende NSAP-adres van de N-Connect-Indication is
hetzelfde als het aangeroepen NSAP-adres van het uitstaande N-
Connect-Request;
— het aanroepende NSAP-adres van het uitstaande N-Connect-
Requestis grot er dan hetaangeroepen NSAP-adres van het
uitstaande N-Connect-Request, waarbij de vergelijking plaatsvindt
op de bitst rings die worden gevormd door de binaire voorkeurs-
codering van elk NSAP-adres, zoals gedefinieerd in ISO/IEC 8348
Bijlage A [Referentie 10] (een string zal worden beschouwd als
groter dan elk van zijn eigen initiële substrings, bijv.
'8800'H>'88'H).2000R2082 — NL — 15.06.2002 — 001.001 — 185
▼B
B.4.3. Vrijgeven van de verbinding
B.4.3.1. Voor vrijgave van de verbinding zal gebruik worden gemaaktvan de
N-Disconnect en N-Reset dienstprimitieven van de onderliggende
netwerkdienst.
B.4.3.2. Om een T-Disconnect-Request te implementeren zal een N-Discon-
nect-Request worden gesignaleerd. Anderzijds, als het tot stand
brengen van netwerkverbindingen met gebruik van N-Connect-primi-
tieven niet wordt ondersteund zal de netwerkverbinding niet expliciet
worden vrijgegeven.
Aanbeveling In het laatste hierboven genoemde geval dient de
netwerkverbinding in de uitgangstoestand te worden teruggebracht.
B.4.3.3. Er zal een T-Disconnect-Indication worden gesignaleerd bij ontvangst
van een van de volgende netwerk dienstprimitieven op een netwerk-
verbinding die overeenkomt met een geheel of gedeeltelijk tot stand
gekomen transportverbinding:
— N-Disconnect-Indication;
— N-Reset-Indication.
B.4.4. Dataoverdracht
B.4.4.1. De T-Data-primitieve zal worden geïmplementeerd door gebruik van
de N-Data-primitieve van de onderliggende netwerkdienst. Er bestaat
een directe correspondentie tussen de twee verzamelingen (verzoek,
aanduiding) primitieven. De correspondentie gebruikt een Transport
Protocol Data Unit (TPDU) die wordt overgedragen door de netwerk-
dienst.
B.4.4.2. De TPDU zal hetvolgende formaathebben, verzonden van links naar
rechts, waarbij de berichtstructuur gedefinieerd in A.4.10.1 dient te
worden ingevoegd in de velden data(1), data(2)…data(n).
STX LENG ADEST DEST AEMM EMM data(1) ADR data(2) …
data(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
OPMERKINGEN
1. Deze kop is zodanig gedefinieerd dat ze identiek is aan die welke
wordt gebruikt in de procedure INTERCAUTRA gedefinieerd voor
de uitwisseling van ACT-berichten tussen CAUTRA Paris, het
9020D-systeem van het London Air Traffic Control Centre en het
Digital Communications Terminal System (DCTS) Maastricht/
Karlsruhe, bij het transport van berichtstructuren gedefinieerd in
; in dit geval komt het veld „data(1)” overeen met het veld TYP.
2. Het gebruik van de velden ADEST, DEST, AEMM, EMM en ADR
met waarden anders dan '40'H valt buiten het bestek van dit Euro-
control-normdocument, maar kan het onderwerp zijn van
bilaterale overeenkomst.
B.4.4.3. De T-Data-dienst zal beperkt zijn tot de overdracht van afdrukbare
ASCII-tekengegevens. In het bijzonder zal geen van de databytes de
waarde '03'H (hett eken ETX) hebben.
B.4.4.4. Een zich conformerende implementatie zal voldoen aan de vereiste
om Network Service Data Unit (NSDU)-structuren tot en met 4 105
bytes te ondersteunen.
B.4.4.5. Een zich conformerende implementatie zal aaneenschakeling van
meerdere TSDU's tot een enkele NSDU verbieden.
B.4.4.6. Een zich conformerende implementatie zal segmentatie van een
enkele TSDU tot meervoudige NSDU's verbieden.2000R2082 — NL — 15.06.2002 — 001.001 — 186
▼B
BIJLAGE C (Normatief)
NETWERKPROTOCOL
C.1. Inleiding
Deze bijlage bevat een specificatie van een basis netwerkprotocol dat
gebruik maaktvan hetX.25 pakketlayer prot ocol, voor gebruik in
zowel punt-punt- als pakket-switched netwerkomgevingen, ter onder-
steuning van de overdracht van vluchtgegevens. De
protocoldeelverzameling is compatibel met die welke is gedefinieerd
in versies van [Referentie 1] vanaf de uitgave van 1980.
C.2. Geleverde dienst
C.2.1. Het protocol implementeert de OSI Network Service voor de verbin-
dingsmodus zoals gedefinieerd in ISO/IEC 8348 [Referentie 10], met
de volgende uitzonderingen.
— NSAP-adressen zijn beperktt otde vorm zoals gedefinieerd in;
— er is geen faciliteit voor het tot stand brengen van overeenkomst
tussen de gebruikers van Network Service (NS) en de NS
provider over de kwaliteit van de dienst die behoort bij een
netwerkaansluiting;
— overdracht van NS-User-Data tijdens het tot stand brengen en de
vrijgave van een netwerkaansluiting wordt niet ondersteund
behalve voor bepalingen beschreven in C.5.3.
C.2.2. De volgende NS provider-opties worden niet aangeboden:
— Bevestiging van ontvangst;
— Versnelde gegevensoverdracht.
C.3. Veronderstelde dienst
Het protocol veronderstelt dat is voorzien in een OSI Datalink
Service, zoals die welke wordtgeboden door ISO/IEC 7776 (LAPB)
[Referentie 6].
C.4. NSAP-adressering
C.4.1. Inleiding
C.4.1.1. De structuur van de NSAP-adressen volgt die welke is gedefinieerd
in ISO/IEC 8348 Annex A [Referentie 10], zoals hieronder geïllu-
streerd.
C.4.1.2. De onderdelen van hetNSAP-adres worden hieronder gedefinieerd:
IDP: Initial Domain Part [eerste domeinonderdeel], omvat de
velden AFI en IDI
AFI: Authority and Format Identifier [aanduiding van autoriteit en
formaat], en
IDI: Initial Domain Identifier [eerste domeinaanduiding]
DSP: Domain Specific Part[domeinspecifiek onderdeel]
C.4.2. NSAP-adresstructuur
C.4.2.1. Ten behoeve van ditEurocont rol-normdocumentzullen de adreson-
derdelen worden beperktt otde volgende vorm.
C.4.2.2. De AFI-waarde 48 zal worden gebruikt, wat een IDI in lokaal
formaat aanduidt met een decimale abstracte syntaxis.
C.4.2.3. De IDI is nul, volgens hetlokale formaat .2000R2082 — NL — 15.06.2002 — 001.001 — 187
▼B
C.4.2.4. De DSP zal uit twee paar decimale cijfers bestaan, als volgt:
— het eerste paar is een aanduiding voor een Air Traffic Control
(ATC) eenheid, die een ATC-systeem aanduidt en dus indirect
een locatie;
— het tweede paar is een selector voor de ATC-eenheid, die kan
worden gebruiktom een bepaald eindpuntbinnen een ATC-
eenheid aan te duiden.
C.4.2.5. De resulterende NSAP-adresstructuur wordt hieronder geïllustreerd.
AFI DSP
48 aanduiding ATC-eenheid selector ATC-eenheid
C.4.3. Toewijzing van ATC-eenheid-aanduidingen en selectors
C.4.3.1. Toewijzing van unieke ATC-eenheid-aanduidingen aan elk ATC-
systeem zal de verantwoordelijkheid zijn van Eurocontrol, terwijl
ATC-eenheid selectors zullen worden toegewezen door de betref-
fende instantie binnen de ATC-administratie of -organisatie.
C.4.3.2. De toewijzing van ATC-eenheid-aanduidingen ten tijde van de voor-
bereiding voor deze norm staat vermeld in.
C.5. Protocolspecificatie
C.5.1. Overzicht
Het protocol is gebaseerd op het Subnetwork-Dependent Conver-
gence Protocol for X.25 (1980) gedefinieerd in van ISO/IEC 8878
[Referentie 12], met de volgende verschillen:
— de gebruikersfaciliteit Fast Select wordt niet gebruikt; echter, de
codering gedefinieerd in Annex A van ISO/IEC 8878
[Referentie 12] voor gebruik met het veld User Data met uitge-
breid formaatdatbeschikbaar is bij de facilit eitFastSelect
wordthier gebruiktmethetbasisformaatUser Dat a-veld in
CALL REQUEST en INCOMING CALL-pakketten, aangezien
beperkingen met betrekking tot de toegestane netwerkdienstpara-
meters ervoor zorgen dat de gecodeerde informatie in 16 bytes
past;
— van de netwerkdienstparameters waarvoor coderingen zijn gedefi-
nieerd in ISO/IEC 8878 [Referentie 12] worden alleen de
aangeroepen en aanroepende NSAP-adressen (en alleen in de
vorm zoals gedefinieerd in ) in hetCALL REQUEST pakket
verzonden;
— hetveld User Dat a wordtnietgebruiktin de CALL ACCEPTED,
CALL CONNECTED, CLEAR REQUEST of CLEAR INDICA-
TION-pakketten;
— de alternatieve procedures voor de totstandkoming en vrijgave
van netwerkaansluitingen worden niet gebruikt;
— ontvangstbevestiging met gebruik van het D-bit wordt niet onder-
steund.
NOTADe eerste drie van deze beperkingen zorgen ervoor dat alle
informatie die wordt verzonden tussen twee DTE's de beper-
kingen van het veld User Data in X.25 (1980) PLP zal
respecteren.
C.5.2. Adrescodering
De aanroepende en aangeroepen NSAP-adressen zullen worden geco-
deerd metbehulp van de binaire voorkeurcodering zoals gedefinieerd
in ISO/IEC 8348 Annex A [Referentie 10].
C.5.3. Codering van het veld User Data
C.5.3.1. Als resultaat van de hierboven vermelde vereisten zal het veld User
Data in CALL REQUEST en INCOMING CALL-pakketten worden
gecodeerd zoals hieronder aangegeven. Alle 16 bytes zullen worden
verzonden.2000R2082 — NL — 15.06.2002 — 001.001 — 188
▼B
Tabel 1
Codering van hetveld User Dat a
VeldbeschrijvingMeestsignificant e
semi-byteMinstsignificant e
semi-byte
Octet 0: Protocolidentiteit bin (1000) bin (0100)
Byte 1: Type berichtcode bin (0010) bin (0000)
Byte 2: Waarde berichtcode (N CR) bin (0000) bin (0001)
Byte 3: Parametertype = aangeroepen
NSAPbin (1100) bin (1001)
Byte 4: Parameterlengte bin (0000) bin (0110)
Byte 5: Parameterwaarde (1e byte) = AFI-
waardebin (0100) bin (1000)
Byte 6: Parameterwaarde (2e byte) = iden-
tificatie ATC-eenheidmeestsignificant e
cijferminstsignificant e
cijfer
Byte 7: Parameterwaarde (3e byte) =
selector ATC-eenheidmeestsignificant e
cijferminstsignificant e
cijfer
Byte 8: Parametertype = aanroepende
NSAPbin (1100) bin (1011)
Byte 9: Parameterlengte bin (0000) bin (0110)
Byte 10: Parameterwaarde (1e byte) = AFI-
waardebin (0100) bin (1000)
Byte 11: Parameterwaarde (2e byte) =
aanduiding ATC-eenheidmeestsignificant e
cijferminstsignificant e
cijfer
Byte 12: Parameterwaarde (3e byte) =
selector ATC-eenheidmeestsignificant e
cijferminstsignificant e
cijfer
Byte 13: Gereserveerd voor toekomstig
gebruikbin (0000) bin (0000)
Byte 14: Gereserveerd voor toekomstig
gebruikbin (0000) bin (0000)
Byte 15: Gereserveerd voor toekomstig
gebruikbin (0000) bin (0000)
C.5.3.2. Andere parameters beschreven in ISO/IEC 8878 [Referentie 12]
zullen nietworden gebruikt .
C.5.4. Behandeling van adressen in INCOMING CALL-pakketten
C.5.4.1. DTE-adressen
Hetaanroepende DTE-adres in een INCOMING CALL-pakketzal
worden gevalideerd aan de hand van een lokale lijstmetgeldige
DTE-adressen op afstand voor het systeem. Als een ongeldig adres
wordt ontdekt zal de oproep worden gewist.
OPMERKINGEN1. Het aangeroepen DTE-adres, indien aanwezig, in een INCOMING
CALL pakket, indien aanwezig, kan optioneel ook worden gevali-
deerd aan de hand van een lijst met geldige lokale DTE-adressen
voor het systeem (gewoonlijk van één item).
2. In sommige gevallen kan het DTE-adres van een eenheid
verschillen in waarde en/of lengte als de eenheid fungeert als het
aanroepende of aangeroepen systeem. Daarom dient bijzondere
aandacht aan deze kwestie te worden besteed bij het specificeren
of implementeren van de functionaliteit voor het valideren van het
DTE-adres.
C.5.4.2. NSAP-adressen
Hetaanroepende NSAP-adres datis gecodeerd zoals hierboven
beschreven in een INCOMING CALL pakketzal worden gevalideerd
aan de hand van een lokale lijstvan geldige NSAP-adressen op
afstand voor het systeem. Als een ongeldig adres wordt ontdekt zal
de oproep worden gewist.2000R2082 — NL — 15.06.2002 — 001.001 — 189
▼B
OPMERKING Het aangeroepen NSAP-adres kan optioneel ook
worden gevalideerd aan de hand van een lijst met
geldige lokale NSAP-adressen voor het systeem
(gewoonlijk één item).
C.5.5. Dataoverdracht
C.5.5.1. Zoals beschreven in ISO/IEC 8878 Annex A.5.3 [Referentie 12]
worden NSDU's overgedragen in hetveld User Dat a van een DATA
pakket.
OPMERKING Als gevolg daarvan is het verboden om meer dan één
gebruikersbericht, zoals een OLDI-bericht, per X.25
pakket of M-bit reeks te verzenden.
C.5.5.2. NSDU's die langer zijn dan de maximum User Data die voor de
virtuele verbinding zijn toegestaan zullen worden gesegmenteerd en
verzonden in de User Data-velden van een reeks DATA-pakketten
waarbij alle pakketten behalve het laatste zowel de maximumlengte
als hetM-bithebben (d.w.z. een More-bit -reeks).
C.5.5.3. Bij ontvangst zullen de User Data-velden van een More-bit-reeks
weer op volgorde worden gelegd om de ontvangen NSDU te vormen.2000R2082 — NL — 15.06.2002 — 001.001 — 190
▼B
BIJLAGE D (Normatief)
PROFIELSPECIFIEKE PICS-PROFORMA'S
D.1. Inleiding
D.1.1. De leverancier van een protocolimplementatie waarvan wordt
geclaimd datdeze zich conformeertaan de specificat ies in de
Bijlagen A-C zal de volgende PICS-proforma's invullen.
OPMERKING: Auteursrecht-vrijgave voor PICS-proforma's: gebrui-
kers van dit Eurocontrol-normdocument mogen de
PICS-proforma's in deze bijlage vrijelijk reprodu-
ceren, zodat deze voor het bedoelde gebruik kunnen
worden toegepast en mogen de ingevulde PICS
verder publiceren.
D.1.2. Een ingevulde PICS-proforma is de PICS voor de betreffende imple-
mentatie. De PICS is een verklaring over welke capaciteiten en opties
van het protocol zijn geïmplementeerd.
D.1.3. De PICS kunnen een aantal gebruiksmogelijkheden hebben, met
inbegrip van:
— door degene die het protocol implementeert, als een check-list om
hetrisico t e verkleinen datnietaan de norm wordtvoldaan als
gevolg van een vergissing;
— door de leverancier en verkrijger, of potentiële verkrijger, van de
implementatie, als een gedetailleerde aanduiding van de capaci-
teiten van de implementatie, relatief ten opzichte van de
gemeenschappelijke begripsbasis zoals geleverd door de norm
PICS-proforma;
— door de gebruiker, of potentiële gebruiker, van de implementatie,
als een basis voor een eerste controle van de mogelijkheden voor
samenwerking met een andere implementatie (merk op dat
hoewel samenwerking nooitkan worden gegarandeerd, de onmo-
gelijkheid om samen te werken vaak kan worden voorspeld aan
de hand van incompatibele PICS');
— door een protocoltester, als basis voor het kiezen van de juiste
tests om de claim van conformiteit van de implementatie te
beoordelen.
D.2. Instructies voor het invullen van de PICS-proforma's
D.2.1. Algemene structuur van de PICS-proforma's
D.2.1.1. De Implementatie-identificatie en de Protocolsamenvatting vormen
het eerste gedeelte van elke PICS-proforma en dienen zoals aange-
geven te worden ingevuld met de benodigde informatie om zowel
de leveranciers als de implementatie volledig te identificeren.
D.2.1.2. Het grootste gedeelte van de PICS-proforma bestaat uit een vragen-
lijst met een vaste samenstelling. Antwoorden op de items in de
vragenlijst dienen te worden ingevuld in de meest rechtse kolom,
ofwel door eenvoudig een antwoord aan te kruisen om een beperkte
keuze aan te geven (gewoonlijk Ja of Nee), of door een waarde in te
voeren of een verzameling of reeks van waarden.
OPMERKINGEN1. Elk item wordt aangeduid door een unieke itemreferentie in de
eerste kolom; de tweede kolom bevat de vraag die dient te worden
beantwoord; de derde kolom bevat de referentie of referenties
naar het materiaal dat het item in deze Eurocontrol-norm specifi-
ceert. De resterende kolommen bevatten de status van het item (of
ondersteuning verplicht, optioneel, verboden of voorwaardelijk is)
en bieden ruimte voor de antwoorden: zie ook D.2.4. hieronder.
2. Een leverancier kan verdere informatie leveren, of kan worden
vereist om verdere informatie te leveren, die wordt gecategori-
seerd als ofwel Aanvullende informatie of
Uitzonderingsinformatie. Indien aanwezig dient elk type verdere
informatie te worden geleverd in een verdere subclausule van
items met respectievelijk het label A<i> of X<i> ten behoeve
van kruisverwijzingen, waarbij <i> elke ondubbelzinnige aandui-
ding voor het item is (bijv. eenvoudig een getal): er gelden geen
verdere beperkingen ten aanzien van het formaat en de presen-
tatie.2000R2082 — NL — 15.06.2002 — 001.001 — 191
▼B
D.2.1.3. Naar een ingevulde PICS-proforma, metinbegrip van event uele
Aanvullende informatie en Uitzonderingsinformatie, zal worden
verwezen als de Protocol Implementation Conformance Statement
[verklaring van conformiteit van de protocolimplementatie] voor de
betreffende implementatie.
OPMERKING Als een implementatie op meer dan een wijze kan
worden geconfigureerd, kan een enkele PICS volstaan
om al dergelijke configuraties te beschrijven. De
leverancier heeft echter de keuze om meer dan een
PICS te leveren, die elk betrekking hebben op een
deelverzameling van de configuratiecapaciteiten van
de implementatie, in het geval dat dit de presentatie
van de informatie gemakkelijker en duidelijker maakt.
D.2.2. Aanvullende informatie
Items met Aanvullende informatie stellen een leverancier in staat om
verdere informatie te leveren die bedoeld is als hulpmiddel bij de
interpretatie van de PICS.
OPMERKINGEN1. Het is niet de bedoeling, noch wordt verwacht, dat een grote
hoeveelheid van dergelijke informatie wordt geleverd en een
PICS kan ook zonder dergelijke informatie als compleet worden
beschouwd. Voorbeelden kunnen zijn een overzicht van de
manieren waarop een (enkele) implementatie kan worden inge-
steld om in diverse omgevingen en configuraties te functioneren;
of een korte reden (misschien gebaseerd op specifieke applicatie-
behoeften) voor de uitsluiting van functies die, hoewel optioneel,
niettemin gewoonlijk aanwezig zijn in implementaties van dit
protocol.
2. Verwijzingen naar items met Aanvullende informatie kunnen
worden ingevuld naast elk antwoord in de vragenlijst en kunnen
worden opgenomen in items met Uitzonderingsinformatie.
D.2.3. Uitzonderingsinformatie
D.2.3.1. Hetkan nu en dan voorkomen dateen leverancier een it em meteen
verplichte of verboden status wenst te beantwoorden (nadat alle even-
tuele voorwaarden zijn toegepast) op een wijze die in conflict is met
het aangegeven vereiste. De kolom Ondersteund bevat hiervoor geen
voorgedrukt antwoord: in plaats daarvan zal de leverancier het
ontbrekende antwoord in de kolom Ondersteund schrijven, samen
met een X<i> verwijzing naar een item met Uitzonderingsinformatie.
D.2.3.2. De leverancier zal de betreffende reden in het Uitzonderingsitem zelf
plaatsen.
D.2.3.3. Een implementatie waarvoor op die manier een Uitzonderingsitem is
vereistvoldoetnietaan deze specificat ie.
OPMERKING Een mogelijke reden voor de hierboven geschetste
situatie is dat een defect in de norm is gerapporteerd
waarvan wordt verwacht dat de correctie de vereiste
waaraan door de implementatie niet wordt voldaan
zal veranderen.
D.2.4. Voorwaardelijke items
D.2.4.1. Individuele voorwaardelijke items worden aangeduid door een voor-
waardelijk symbool in de vorm „<item>: 
” in de kolom Status,
waarbij „<item>” een itemverwijzing is die verschijnt in de eerste
kolom van de tabel voor een ander item en „
” een statusaandui-
ding M, O, O.<n> of X is.
OPMERKING Een PICS-proforma kan een aantal voorwaardelijke
items bevatten. Dit zijn items waarvan zowel de
toepasselijkheid van het item zelf als de status ervan
als het van toepassing is (verplicht, optioneel of
verboden) afhankelijk is van het feit of bepaalde
andere items al dan niet worden ondersteund.
D.2.4.2. Als hetit em waarnaar door hetvoorwaardelijke symbool wordt
verwezen wordtgemarkeerd als onderst eund, is hetvoorwaardelijke
item van toepassing en wordt de status ervan aangeduid door „
”:
de kolom Ondersteund zal op de gebruikelijke manier worden inge-
vuld. In hetandere geval is hetvoorwaardelijke it em nietrelevant2000R2082 — NL — 15.06.2002 — 001.001 — 192
▼B
en zal het antwoord Not Applicable [niet van toepassing] (NA)
worden aangekruist.
D.2.4.3. Elk item waarvan de referentie wordt gebruikt in een voorwaardelijk
symbool wordt aangeduid door een sterretje in de kolom Item.
D.3. PICS-proforma voor het protocol voor berichtenoverdracht
D.3.1. Afkortingen en speciale symbolen
D.3.1.1. Statusaanduidingen
M: Mandatory [verplicht]O: Optional [optioneel]
D.3.1.2. Itemreferenties
Items in de PICS-proforma worden aangeduid met mnemonische
itemreferenties. PICS-items die te maken hebben met gerelateerde
functies worden aangeduid met itemreferenties die dezelfde begin-
letter of hetzelfde beginletterpaar hebben (in hoofdletters). Hier
volgt een overzicht van die beginletters, in de volgorde waarin de
groepen items in de PICS-proforma voorkomen.
— MTsy, MTop, MTst, MTor berichttypen
— MAE, MAR, MCI, MDT,
MAVprocedures
— MEsu, MEsd, MEhb, MEty coderingen
— MNmsg berichtgrootte— Ts, Tr aftelklokken
D.3.2. Aanduiding
2000R2082 — NL — 15.06.2002 — 001.001 — 193
▼B
D.3.3. Protocolimplementatie
D.4. PICS-proforma voor het berichtkopprotocol
D.4.1. Afkortingen en speciale symbolen
D.4.1.1. Statusaanduidingen
M mandatory [verplicht]
O optional [optioneel]O.<n> optioneel, maar ondersteuning van ten minste een van de
groep opties die door hetzelfde cijfer <n> wordt gelabeld
is vereist
X prohibited [verboden]
<item> symbool voor voorwaardelijk item, afhankelijk van de
ondersteuning die is gemarkeerd voor <item> (zie D.2.4)
D.4.1.2. Afkortingen
NA notapplicable [nietvan t oepassing]2000R2082 — NL — 15.06.2002 — 001.001 — 194
▼B
D.4.1.3. Itemreferenties
Items in de PICS-proforma worden aangeduid met mnemonische
itemreferenties. PICS-items die te maken hebben met gerelateerde
functies worden aangeduid met itemreferenties die dezelfde begin-
letter of hetzelfde beginletterpaar hebben (in hoofdletters). Hier
volgt een overzicht van die beginletters, in de volgorde waarin de
groepen items in de PICS-proforma voorkomen
— IHC1, IHC2, IHC3, IHC4,
IHCCtotstandkoming van verbinding
— IHR1, IHR2 vrijgave van verbinding
— IHT1, IHTx dataoverdracht
— Tcr aftelklok
D.4.2. Aanduiding
2000R2082 — NL — 15.06.2002 — 001.001 — 195
▼B
D.4.3. Protocolimplementatie
D.5. PICS-proforma voor het netwerkprotocol
D.5.1. Afkortingen en speciale symbolen
D.5.1.1. Statusaanduidingen
M mandatory [verplicht]
O optional [optioneel]
D.5.1.2. Itemreferenties
Items in de PICS-proforma worden aangeduid door mnemonische
itemreferenties. PICS-items die te maken hebben met gerelateerde
functies worden aangeduid met itemreferenties die dezelfde begin-2000R2082 — NL — 15.06.2002 — 001.001 — 196
▼B
letter of hetzelfde beginletterpaar hebben (in hoofdletters). Hier volgt
een overzicht van die beginletters, in de volgorde waarin de groepen
items in de PICS-proforma voorkomen.
— SNDCP1 protocol ID-veld
— NCRdae, NCRgae, NCCx,
NDRxparameters in protocolberichten
— NCD1, NCD2, NCN1, NCN2 validatie van adressen
— NDT dataoverdracht
D.5.2. Aanduiding
2000R2082 — NL — 15.06.2002 — 001.001 — 197
▼B
D.5.3. Protocolimplementatie
2000R2082 — NL — 15.06.2002 — 001.001 — 198
▼B
BIJLAGE E (Normatief)
LIJST MET PROFIELVEREISTEN
E.1. Inleiding
E.1.1. Deze bijlage bevatde PRL voor hetFDE ICD-profiel datin ditEuro-
control-normdocument wordt gedefinieerd. De Implementation
Conformance Statement voor een implementatie welke claimt zich
aan ditprofiel t e conformeren zal worden gegenereerd conform
onderstaande instructies.
OPMERKING De proforma's in deze bijlage zijn gebaseerd op die
welke behoren bij de basisnormen waarnaar wordt
verwezen.
E.1.2. Een zich conformerende implementatie zal voldoen aan de verplichte
conformiteitvereisten van de basisnormen waarnaar in dit profiel
wordtverwezen.
E.2. De rol van de PRL en de PICS-proforma's
De status van deze sectie (E.2) is informatief: ze vormt geen bepaling
van dit gedeelte van deze Eurocontrol-norm.
— De doelstelling van de presentatie van de conformiteitvereisten in
de vorm van een tabel van de PRL en de PICS-proforma's is om
een check-list te bieden voor de functies die moeten of mogen
worden geïmplementeerd. De daaraan ten grondslag liggende
concepten zijn gedefinieerd en beschreven in ISO/IEC 9646-1
[Referentie 14] (ITU-T-aanbeveling X.290 is equivalent) en ISO/
IEC TR 10000-1 [Referentie 2]
— In een profiel worden de opties van verschillende basisnormen
gecombineerd en gekozen teneinde aan een specifieke functie
voor informatieverwerking te voldoen. Elke basisnorm heeft een
PICS-proforma waarin de vereisten van de norm staan vermeld.
De PRL omvatde deelverzameling van de PICS-proforma-it ems
van de basisnorm die door hetprofiel worden beperkt , samen
met de specifieke profielvereisten; de PRL definieert antwoorden
op grond waarvan de PICS-proforma's van de basisnorm aan het
profiel kunnen voldoen. Daarnaastzal de PRL it ems van het
type PICS bevatten die specifiek zijn voor het profiel (ten minste
zal er een item zijn dat test of alle vereiste PICS-proforma's
correct zijn ingevuld); deze items dienen te worden ingevuld
samen metde PICS-proforma's van de basisnorm. De ingevulde
proforma's vormen samen de Implementation Conformance State-
ment [verklaring van conformiteit van de implementatie] (ICS)
voor hetprofiel.
— Op grond van de methodologie van ISO/IEC TR 10000-1
[Referentie 2], dient een conformiteitclaim voor een profiel te
worden ondersteund door PICS-proforma's die zijn ingevuld in
overeenstemming met de PRL. Het gebruik van dit materiaal zal
afhankelijk zijn van de benadering voor hetverkrijgen van een
FDE ICD-implementatie.
— Er zijn verschillende benaderingen mogelijk voor een FDE-imple-
mentatie:
— In-house implementatie door een nationale instantie of organi-
satie: de PRL dient te worden gebruikt als de basis voor de
specificatie van de vereisten en de specificatie van de accepta-
tietest voor de implementatie; de ingevulde ICS dient te
worden geproduceerd als onderdeel van de acceptatieproce-
dure.
— Implementatie van het profiel door een aannemer: het mate-
riaal wordtgebruikten geproduceerd als voor een in-house
implementatie, maar de aannemer dient de ICS te leveren en
de noodzaak daarvoor dient een contractuele vereiste te zijn.
— Implementatie van het profiel door een aannemer als onder-
deel van een turn-key contract of een contract voor
systeemintegratie: het materiaal wordt gebruikt en geprodu-
ceerd als voor een in-house implementatie, maar de aannemer
moet worden vereist om dit intern te doen, alsmede om de
voltooide ICS te leveren. Conformiteit aan het profiel verze-
kert, bijvoorbeeld, dat een leverancier die voor twee
instanties werkt niet zijn eigen protocollen mag introduceren2000R2082 — NL — 15.06.2002 — 001.001 — 199
▼B
om aan de FDE-vereisten te voldoen en helpt dus om het
beheer in handen te leggen van de uitbestedende instanties.
— Integratie van off-the-shelf producten in een profielimplemen-
tatie in een van de vorige gevallen: van de leverancier van een
productdientt e worden vereistdathij de PICS-proforma's
levertdie relevantzijn voor hetproduct , ingevuld in overeen-
stemming met de hier gegeven PRL en dat hij de conformiteit
van het product aan de toepasselijke profielvereisten garan-
deert; deze PICS kunnen dan worden verzonden als
onderdeel van de ICS voor hetprofiel.
— Na implementatie dient de ICS te worden onderhouden als onder-
deel van de documentatie van de implementatie; het kan worden
gebruikt om onderlinge samenwerking met andere instanties te
voorspellen en om wijzigingen aan te geven die mogelijk nodig
zijn bij de overgang naar andere protocollen.
E.3. Notatie
E.3.1. De volgende notaties van ISO/IEC TR 10000-1 [Referentie 2] worden
in de PRL gebruikt om de status van functies aan te duiden:
m: mandatory [verplicht]
o: optional [optioneel]
–: notapplicable [nietvan t oepassing] (d.w.z. logisch onmogelijk
binnen de reikwijdte van het profiel)
x: excluded [uitgesloten]
OPMERKINGEN
1. Combinaties van twee tekens mogen worden gebruikt, in welk
geval het eerste teken verwijst naar de statische (implementatie)
status en het tweede naar het dynamische (gebruik); dus „mo”
betekent „mandatory [verplicht] om te worden geïmplementeerd,
optioneel om te worden gebruikt”
2. De notatie „o.<n>” wordt gebruikt om een verzameling opties te
tonen waaruit een keuze kan worden gemaakt (d.w.z. tenminste een
uit de verzameling moet worden geïmplementeerd) met dezelfde
identificatie n.
3. Een functie met de markering „x” kan niettemin onderdeel
uitmaken van een implementatie zolang de functie niet wordt
gebruikt terwijl de implementatie functioneert conform het profiel.
4. Het gebruik van functies met de markering „x” vereist bilaterale
overeenkomst. In dat geval dient de status van de functies te
worden herzien, aangezien ze van belang kunnen zijn voor andere
implementaties.
E.3.2. De volgende predikaatnotatie wordt gebruikt:
<predikaat>: introduceert een groep items, die alle voorwaardelijk
zijn voor <predikaat> (de reikwijdte van de groep wordt aangegeven
door de layout).
<predikaat>: introduceert een enkel item dat voorwaardelijk is voor
<predikaat>.
OPMERKING In elk geval kan het predikaat de aanduiding zijn van
een profielfunctie of een booleanse combinatie van
predikaten („ ¬” is het symbool voor logische ontken-
ning).
E.3.3. Basisnormvereisten worden afgebeeld door gebruik van de equiva-
lente notaties in hoofdletters (d.w.z. M, O, O.<n>, X).
E.4. Instructies voor het invullen van de PICS-proforma's
E.4.1. Ten behoeve van de ICS van hetprofiel dienen de PICS-proforma's
voor de basisnormen waarnaar wordtverwezen t e worden ingevuld,
samen met de aanvullende profiel-gerelateerde PICS-items die in
deze bijlage worden geleverd.
E.4.2. Als in ditprofiel de funct ies van de basisnormen worden verscherpt
zullen de vereisten zoals uitgedrukt in deze PRL worden toegepast
(zoals aangegeven in PRL-items met een kolom „Profielfuncties”)
om de toegestane reacties in de PICS-proforma's van de basisnorm
te beperken.
E.4.3. Als in dit profiel aanvullende eisen worden gesteld dient de reactie-
kolom voor dergelijke items te worden ingevuld. In deze kolom zal2000R2082 — NL — 15.06.2002 — 001.001 — 200
▼B
elke reactie ofwel worden gekozen uit de aangegeven verzameling
reacties of bestaan uit een parameterwaarde of -waarden of een reeks
van waarden zoals gevraagd.
E.4.4. Als niet aan een verplichte vereiste wordt voldaan dient uitzonde-
ringsinformatie te worden ingevuld door een referentie X<i> in te
voeren, waarbij <i> een unieke identificatie is, die verwijst naar een
bijbehorende reden waarom nietaan hetvereist e wordtvoldaan.
OPMERKING Een mogelijke reden voor een dergelijke uitzondering
is het voldoen aan een in behandeling zijn defectrap-
port met betrekking tot een bepaling van het profiel;
als het defectrapport wordt geaccepteerd zal de
implementatie daarna conform zijn.
E.5. Referenties
E.5.1. Dit profiel refereert aan de volgende protocolspecificaties:
— Message Transfer Protocol (Bijlage A bij dit Eurocontrol-normdo-
cument);
— Message Header Protocol (Bijlage B bij dit Eurocontrol-normdo-
cument);
— Connection-mode Network Protocol using ISO/IEC 8208
(Bijlage C bij dit Eurocontrol-normdocument);
— ISO/IEC 7776 [Referentie 6];
— Normen voor fysieke lagen vereistdoor ITU-T-aanbeveling X.25
(1993) clausule 1 [Referentie 1].
E.5.2. Aangezien er geen expliciete PICS-proforma's voor de relevante
normen voor fysieke lagen zijn, zullen de PICS-proforma's voor de
interim fysieke laag in ISO/IEC ISP 10609-9 clausule A.4
[Referentie 8] worden gebruikt.2000R2082 — NL — 15.06.2002 — 001.001 — 201
▼B
E.6. Conformiteitverklaring
E.6.1. Overzicht van conformering
2000R2082 — NL — 15.06.2002 — 001.001 — 202
▼B
E.6.2. Dynamische conformiteitvereisten
E.7. Vereisten voor de bovenste laag
Tabel 3
Protocol voor berichtenoverdracht
Basisnormfuncties Profielfuncties
ItemProtocol voor berichten-
overdrachtReferenties Status Referenties Status
MTst — statusberichten A.4.2 O ox
MTor — operatorberichten A.4.2 O ox
E.8. Vereisten voor de onderste laag
E.8.1. Vereisten voor de transportlaag
Tabel 4
Berichtkopprotocol
Basisnormfuncties Profielfuncties
ItemProtocol voor berichten-
aanhefReferenties Status Referenties Status
IHTx Gebruik van de velden
ADEST, DEST,
AEMM, EMM en
ADR metwaarden
anders dan '40'HB.4.4 O ox
E.8.2. Vereisten voor de netwerklaag
De PRL's in deze sectie zijn gebaseerd op de PICS-proforma voor
ISO/IEC 8208:1993 [Referentie 7]. De vermeldingen in de kolom
„Referenties” onder „Basisnormfuncties” van de volgende tabellen
zijn verwijzingen naar clausules in die norm.2000R2082 — NL — 15.06.2002 — 001.001 — 203
▼B
E.8.2.1. Algemene DTE-kenmerken
Tabel 5
Algemene DTE-kenmerken
Basisnormfuncties Profielfuncties
Item Algemene DTE-kenmerken Referenties Status Referenties Status
Ondersteunde dienst:
Vs — virtuele oproep O.1 mVp — permanente virtuele
verbindingO.1 x
Ondersteunde omge-
vingen:3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2
Ec/8 — DTE/DCE(1988) O.2 6.3.2 o.2
Ec/4 — DTE/DCE(1984) O.2 6.3.2 o.2
Ec/0 — DTE/DCE(1980) O.2 6.3.2 o.2
Et/t — DTE/DTE in vaste
rol als DTEO.2 6.3.2 o.2
Et/c — DTE/DTE in vaste
rol als DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE met
dynamische rolkeuze4.5 Vs: O.2 x
Ondersteunde nummer-
ingvolgorde voor
pakketten:
M8 — Modulo 8 13.2, 12.1.1,
Tabel 3O.3 m
M128 — Modulo 128 13.2, 12.1.1,
Tabel 3O.3 x
Referentienummer van
ondersteunde optionele
gebruikersfaciliteit,
voor toewijzing van
alternatieve Logical
Channel Identifier:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig. 31
RNa — zonder terugkeer
naar gebruik van
logische kanaalbe-
reiken13.29.2.1 Et:O
¬Et:Xx
RNb — metmogelijke
terugkeer naar
gebruik van logi-
sche kanaalbe-
reiken13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Procedures, pakket-typen en pakket-structuren
Tabel 6
Pakketlaagfuncties onafhankelijk van logische kanalen
Basisnormfuncties Profielfuncties
ItemPakketlaagfuncties onafhan-
kelijk van logische kanalenReferenties Status Referenties Status
Worden de volgende
pakketlaagfuncties
ondersteund:
Z2s Zenden van diagnose-
pakket12.7, Tabel 24 Et:O
¬Et:Xx2000R2082 — NL — 15.06.2002 — 001.001 — 204
▼B
Basisnormfuncties Profielfuncties
ItemPakketlaagfuncties onafhan-
kelijk van logische kanalenReferenties Status Referenties Status
Z4i Starten van On-line
Facility Registration:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— REGISTRATION
REQUEST zenden12.9.1
— REGISTRATION
CONFIRMATION
ontvangen12.9.2, Tabel 10
Z4r Reageren op On-line
Facility Registration:13.1, 13.1.1.1,
13.1.1.4Et:O –
— REGISTRATION
REQUEST ontvangen12.9.1
— REGISTRATION
CONFIRMATION
zenden12.9.2, Tabel 10
Tabel 7
Oproepinstelling
Basisnormfuncties Profielfuncties
Item Oproepinstelling Referenties Status Referenties Status
Worden uitgaande
Virtuele oproepen
ondersteund:5.2.1, 5.2.5,
Tabel 33
S1a — FastSelect , geen
beperking op reactie?5.2.4, 13.16 O x
S1b — FastSelectmet
beperkte reactie?13.16 O x
S1c — niet-Fast Select? 5.2.4 O m
SP1b CALL REQUEST,
basisformaat12.2.3.1 S1c:M
S1ab: O.4m
SP1e CALL REQUEST
zenden, uitgebreid
formaat12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b CALL CONNECTED
ontvangen, basisfor-
maat12.2.4.1 S1ac:M m
SP2e CALL CONNECTED
ontvangen, uitgebreid
formaat12.2.4.1,
12.2.4.2S1a:M –
Wordt alternatieve
adressering onder-
steund voor uitgaande
Virtuele oproepen:13.28
— metgebruik A = 1
en uitgebreid Address
Block-formaat?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— metgebruik van de
Called Address Exten-
sion Facility?13.28.2.2. Ec/3:O
¬Ec/3:Xx
Worden inkomende
Virtuele oproepen
ondersteund:5.2.2, 5.2.5,
Tabel 33
S2a — FastSelectmet
acceptatie mogelijk?5.2.3, 13.17 O –
S2b — Fast Select, altijd
vrijgegeven?13.17 O m2000R2082 — NL — 15.06.2002 — 001.001 — 205
▼B
Basisnormfuncties Profielfuncties
Item Oproepinstelling Referenties Status Referenties Status
S2c — niet-Fast Select met
acceptatie mogelijk?5.2.3 O m
S2d — niet-Fast Select,
altijd vrijgegeven?5.2.3 O x
SP3b INCOMING CALL
ontvangen, basisfor-
maat12.2.3.1 S2:M m
SP3e INCOMING CALL
ontvangen, uitgebreid
formaat12.2.3.1,
12.2.3.2S2ab:M
S2axc :
O.5–
SP4b CALL ACCEPTED
zenden, basisformaat12.2.4.1 S2c:M
S2axc :
O.5m
SP4e CALL ACCEPTED
zenden, uitgebreid
formaat12.2.4.1,
12.2.4.2S2axc :
O.5
S2anc :O–
WordtD-bit -onderhan-
deling ondersteund:
DN1 — voor uitgaande
Virtuele oproepen6.3 S1ac:O m
DN2 — voor inkomende
Virtuele oproepen6.3 S1ac:O m
Opm. Het D-bit zal altijd worden onderhandeld tot 0.
Tabel 8
Oproepen vrijgeven
Basisnormfuncties Profielfuncties
Item Oproepen vrijgeven Referenties Status Referenties Status
Wordtvrijgeven van
oproepen ondersteund
voor:5.5.4, Tabel 33
C1 — antwoord op
aanduiding van vrij-
gave5.5.2 O m
C2a — afbreken van
poging tot uitgaande
Virtuele oproep?5.4, 5.5.1, 5.5.3 S1:O o
C2b — afwijzen van een
inkomende Virtuele
oproep?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd :
Om
C2c — beginnen van vrij-
geven van een tot
stand gekomen
Virtuele oproep?5.5.1, 5.5.3 O o
CP1b CLEAR INDICATION
ontvangen, basisfor-
maat12.2.5.1 Cany :M m
CP1e CLEAR INDICATION
ontvangen, uitgebreid
formaat12.2.5.1,
12.2.5.2Cany :M –
CP2b CLEAR CONFIRMA-
TION zenden, basis-
formaat12.2.6.1 C1:M m
CP2e CLEAR CONFIRMA-
TION zenden, uitge-
breid formaat12.2.6.1,
12.2.6.2C1rn:M x2000R2082 — NL — 15.06.2002 — 001.001 — 206
▼B
Basisnormfuncties Profielfuncties
Item Oproepen vrijgeven Referenties Status Referenties Status
CP3b CLEAR REQUEST
zenden, basisformaat12.2.5.1 C2a:M
C2bcxa :
O.6m
CP3e CLEAR REQUEST
zenden, uitgebreid
formaat12.2.5.1,
12.2.5.2C2bcxa :
O.6
C2axbc :
Xx
CP4b CLEAR CONFIRMA-
TION ontvangen,
basisformaat12.2.6.1 C2:M m
CP4e CLEAR CONFIRMA-
TION ontvangen,
uitgebreid formaat12.2.6.1,
12.2.6.2C2rnci :M –
Tabel 9
In de uitgangstoestand terugbrengen van logische kanalen
Basisnormfuncties Profielfuncties
ItemIn de uitgangstoestand
terugbrengen van logische
kanalenReferenties Status Referenties Status
Wordthetin de
uitgangstoestand terug-
brengen ondersteund:8, 8.4, Tabel 34
RSi — als initiator? 8.1, 8.3 O mm
RESET REQUEST
zenden12.5.1
RESET CONFIRMA-
TION/INDICATION
ontvangen12.5.2, 12.5.1
RSr — als responder? 8.2 O mm
RESET INDICATION
ontvangen12.5.1
RESET CONFIRMA-
TION zenden12.5.2
Tabel 10
Foutprocedures
Basisnormfuncties Profielfuncties
ItemFoutprocedures (virtuele
oproepdienst)Referenties Status Referenties Status
Is ERROR-C proce-
dure:5.2.1, 5.4, 8.1,
Tabel 33
W1a — virtuele oproep
vrijgeven?O.7 m
W1b — pakketlaag opnieuw
starten?O.7 x
Is ERROR-R proce-
dure voor virtuele
oproepen?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,
Tabellen 34-36
W2sc — de pakketlaag
opnieuw starten?O.8 x2000R2082 — NL — 15.06.2002 — 001.001 — 207
▼B
Tabel 11
Interruptoverdracht
Basisnormfuncties Profielfuncties
Item Interruptoverdracht Referenties Status Referenties Status
Is Wordtzenden van
interrupts ondersteund?6.8, 6.8.1, 6.8.3,
Tabel 35Oo x
— INTERRUPT
REQUEST zenden12.3.2
INTERRUPT
CONFIRMATION
ontvangen12.3.3
Ir Wordtont vangen van
interrupts ondersteund?6.8, 6.8.2, 6.8.3,
Tabel 35O–
— INTERRUPT
INDICATION
ontvangen12.3.2
— INTERRUPT
CONFIRMATION
zenden12.3.3
Tabel 12
Data zenden
Basisnormfuncties Profielfuncties
Item Data zenden Referenties Status Referenties Status
DS1 Wordtzenden van
DATA-pakketten
ondersteund?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Wordthetvolgende
ondersteund:
DS2 — rotatie van verzend-
venster bij ontvangstbijgewerkte P(R)
waarden?7.1, 7.1.2, 7.1.3 O mm
DS4a — M = 0 in DATA-
pakketten zenden?6.4, 6.5, 6.7 M mo.9
DS4b — M = 1 in DATA-
pakketten zenden?6.4, 6.5, 6.7 O mo.9
DS5a — Q = 0 in DATA-
pakketten zenden?6.6 O.10 mm
DS5b — Q = 1 in DATA-
pakketten zenden?6.6 O.10 ox
DS6 — reageren op
verzoeken om pakket
opnieuw te zenden
(ontvangen REJECT-
pakketten)?13.4.2, 12.8 Et:O –
— Window Rotation
Aftelklok-procedure:
DS7a — ERROR-R-actie bij
afloop11.2.1(a) O ox
DS7b — pakketopnieuw
zenden bij afloop11.2.1(b) Et:O
¬Et:Xox
DS8 — te lange flow
control-pakketten
wegdoen (in plaats van
ERROR-R)?Tabel 36 Opm.
2Oo x2000R2082 — NL — 15.06.2002 — 001.001 — 208
▼B
Tabel 13
Data ontvangen
Basisnormfuncties Profielfuncties
Item Data ontvangen Referenties Status Referenties Status
DR1 Wordtont vangen van
DATA-pakketten
ondersteund?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
Wordthetvolgende
ondersteund:
DR2 — rotatie van
ontvangstvenster bij
zenden van bijge-
werkte P(R) waarden?7.1.2, 7.1.3 O mm
DR3 — flow control door
zenden van RECEIVE
NOT READY en
RECEIVE READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — M = 1 in DATA-
pakketten ontvangen?6.4, 6.5, 6.7 O mm
DR5a — Q = 0 in DATA-
pakketten ontvangen?6.6 O.11 mm
DR5b — Q = 1 in DATA-
pakketten ontvangen?6.6 O.11 –
DR6 — opnieuw zenden
van pakketten vragen
door zenden van
REJECT-pakketten?13.4.1, 12.8 O ox
— herstel van
ontvangst van DATA-
pakketten die ongel-
dige P(S) bevatten,
door:
DR7a — ERROR-R-actie? 11.3(a) O.12 mm
DR7b — verzoek om pakket
opnieuw te zenden?11.3(b) O.12 ox
DR7c — pakketnegeren en
wachten op correct
opnieuw verzonden
pakket?11.3(c) O.12 ox
— herstel van
ontvangst van DATA-
pakketten met ongeldig
User Data-veld, door:
DR8a — ERROR-R-actie? 11.3(a) O.13 mmDR8b — verzoek om pakket
opnieuw te zenden?11.3(b) O.13 ox
DR8c — pakketnegeren en
wachten op een correct
opnieuw verzonden
pakket?11.3(c) O.13 ox
DR9 — Window Status
Transmission Aftel-
klok-procedure?11.2.2 O ox2000R2082 — NL — 15.06.2002 — 001.001 — 209
▼B
Tabel 14
Bevestiging van aflevering
Basisnormfuncties Profielfuncties
Item Bevestiging van aflevering Referenties Status Referenties Status
DC Wordtbevest iging van
aflevering onder-
steund?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Diverse functies en opties
Tabel 15
Waarden van oorzaak- en diagnostische codes
Basisnormfuncties Profielfuncties
ItemWaarden van oorzaak- en
diagnostische codesReferenties Status Referenties Status
In verzonden
RESTART REQUEST-
pakketten:12.6.1.1,
12.6.1.2,
Tabellen 24-25
Y1d — Oorzaak = 128,
private diagnostische
codesO.14 ox
In ontvangen
RESTART INDICA-
TION-pakketten:12.6.1.1, Tabel
9, 12.6.1.2
Y2b — Oorzaak niet0 of
128, elke diagnostische
codewaardeEC:M
¬EC:Om
In verzonden CLEAR
REQUEST-pakketten:12.2.3.1.1,
12.2.3.1.2,Tabellen 24-25
Y3d — Oorzaak = 128,
private diagnostische
codesO.15 ox
In ontvangen CLEAR
INDICATION-
pakketten:12.2.3.1.1, Tabel
7 12.2.3.1.2,
Y4b — Oorzaak niet0 of
128, elke diagnostische
codewaardeEC:M
¬EC:Om
In verzonden RESET
REQUEST-pakketten:12.5.1.1,
12.5.1.2,
Tabellen 24-25
Y5d — Oorzaak = 128,
private diagnostische
codesO.16 ox
In ontvangen RESET
INDICATION-
pakketten:12.5.1.1, Tabel
8, 12.5.1.2
Y6b — Oorzaak niet0 of
128, elke diagnostische
codewaardeEC:M
¬EC:Om2000R2082 — NL — 15.06.2002 — 001.001 — 210
▼B
E.8.2.4. Faciliteiten
Tabel 16
Faciliteiten verzonden in CALL REQUEST-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten verzonden in
CALL REQUEST-
pakkettenReferenties Status Referenties Status
FS1pi Flow Control Para-
meter Negotiation,
pakket-grootte13.12, 15.2.2.1.1 O x
FS1wi Flow Control Para-
meter Negotiation,
venstergrootte13.12, 15.2.2.1.2 O x
FS2ib Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Tabel
20aOx
FS2ie Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Tabel
20bOx
FS3b Closed User Group
Selection, basisformaat13.14.6,
15.2.2.3.1Oo
FS3e Closed User Group
Selection, uitgebreid
formaat13.14.6,
15.2.2.3.2Ox
FS4b Closed User Group
With Outgoing Access
Selection, basisformaat13.14.7,
15.2.2.4.1Ox
FS4e Closed User Group
With Outgoing Access
Selection, uitgebreid
formaat13.14.7,
15.2.2.4.2Ox
FS5 Bilateral Closed User
Group Selection13.15, 15.2.2.5 O x
FS6a FastSelect 13.16, 15.2.2.6 O x
FS6b Reverse Charging 13.18, 15.2.2.6 O x
FS6c ICRD Status Selection 13.25.4.2,
15.2.2.6Ox
FS7i Network User Identifi-
cation13.21, 13.21.3,
15.2.2.7Ox
FS8i Charging Information,
aanvraagdienst13.22, 15.2.2.8.1 O x
FS9b RPOA-keuze, basisfor-
maat13.23, 13.23.2,
15.2.2.9.1Ox
FS9e RPOA-keuze, uitge-
breid formaat13.23, 13.23.2,
15.2.2.9.2Ox
FS12 TransitDelay Select ion
and Indication13.27, 15.2.2.13 O x
FS99i Local non-X.25-facili-
teiten, Facility Marker
volgend15.1, Tabel 18 O x
FS98i Niet-X.25 faciliteiten
op afstand, Facility
Marker volgend15.1, Tabel 18 O x
FS20i Facility Marker, door
CCITT gespecificeerde
DTE-faciliteiten15.1 O x
FS21i Calling Address Exten-
sion14.1, 15.3.2.1 x
FS22i Called Address Exten-
sion14.2, 15.3.2.2 x2000R2082 — NL — 15.06.2002 — 001.001 — 211
▼B
Basisnormfuncties Profielfuncties
ItemFaciliteiten verzonden in
CALL REQUEST-
pakkettenReferenties Status Referenties Status
FS23ib Minimum Throughput
Class Negotiation,
basisformaat14.3, 15.3.2.3.1,
Tabel 20aOx
FS23ie Minimum Throughput
Class Negotiation,
uitgebreid formaat14.3, 15.3.2.3.2,
Tabel 20bO
FS24i End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FS25i Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FS26i Prioriteit 14.5, 15.3.2.5 O x
FS27i Bescherming 14.6, 15.3.2.6 O x
Tabel 17
Faciliteiten verzonden in CALL ACCEPT-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten verzonden in
CALL ACCEPT-pakkettenReferenties Status Referenties Status
FS1pr Flow Control Para-
meter Negotiation,
pakket-grootte13.12,
15.2.2.1.1, Tabel
13Ox
FS1wr Flow Control Para-
meter Negotiation,
venstergrootte13.12,
15.2.2.1.2, Tabel
13Ox
FS2rb Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Tabel
20aOx
FS2re Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Tabel
20bOx
FS7r Network User Identifi-
cation13.21, 13.21.3
15.2.2.7Ox
FS8r Charging Information,
requesting service13.22, 15.2.2.8.1 O x
FS10r Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FS99r Lokale niet-X.25-faci-
liteiten, volgens Faci-
lity Marker15.1, Tabel 18 O x
FS98r Niet-X.25-faciliteiten
op afstand, volgens
Facility Marker15.1, Tabel 18 O x
FS20r Facility Marker, door
CCITT gespecificeerde
DTE-faciliteiten15.1 O x
FS22r Called Address Exten-
sion14.2, 15.3.2.2 O x
FS24r End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FS25r Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FS26r Prioriteit 14.5, 15.3.2.5 O x
FS27r Bescherming 14.6, 15.3.2.6 O x2000R2082 — NL — 15.06.2002 — 001.001 — 212
▼B
Tabel 18
Faciliteiten verzonden in CLEAR REQUEST-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten verzonden in
CLEAR REQUEST-
pakkettenReferenties Status Referenties Status
FS10d Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FS13 Call Deflection Selec-
tion13.25.2.2,
15.2.2.10Ox
FS99d Lokale niet-X.25-faci-
liteiten, volgens Faci-
lity Marker15.1, Tabel 18 O x
FS98d Niet-X.25 faciliteiten
op afstand, volgens
Facility Marker15.1, Tabel 18 O x
FS20d Facility Marker, door
CCITT gespecifieerde
DTE-faciliteiten15.1 O x
FS22d Called Address Exten-
sion14.2, 15.3.2.2 O x
Tabel 19
Faciliteiten ontvangen in INCOMING CALL-pakketten
Basisnorm functies Profielfuncties
ItemFaciliteiten ontvangen in
INCOMING CALL-
pakkettenReferenties Status Referenties Status
FR1pi Flow Control Para-
meter Negotiation,
pakket-grootte13.12, 15.2.2.1.1 O x
FR1wi Flow Control Para-
meter Negotiation,
venstergrootte13.12, 15.2.2.1.2 O x
FR2ib Basic Throughput
Class Negotiation13.13, 15.2.2.2.1
Tabel 20aOx
FR2ie Extended Throughput
Class Negotiation13.13, 15.2.2.2.2
Tabel 20bOx
FR3b Closed User Group
Selection, basisformaat13.14.6,
15.2.2.3.1Oo
FR3e Closed User Group
Selection, uitgebreid
formaat13.14.6,
15.2.2.3.2Ox
FR4b Closed User Group
With Outgoing Access
Selection, basisformaat13.4.7,
15.2.2.4.1Ox
FR4e Closed User Group
With Outgoing Access
Selection, uitgebreid
formaat13.4.7,
15.2.2.4.2Ox
FR5 Bilateral Closed User
Group Selection13.15, 15.2.2.5 O x
FR6a FastSelect 13.16, 13.17,
15.2.2.6Ox
FR6b Reverse Charging 13.18, 13.19,
15.2.2.6Ox
FR11 Call Redirection of
Call Deflection Notifi-
cation13.25.3,
15.2.2.11Ox2000R2082 — NL — 15.06.2002 — 001.001 — 213
▼B
Basisnorm functies Profielfuncties
ItemFaciliteiten ontvangen in
INCOMING CALL-
pakkettenReferenties Status Referenties Status
FR12i TransitDelay Select ion
and Indication13.27, 15.2.2.13 O x
FR99i Lokale niet-X.25-faci-
liteiten, volgens Faci-
lity Marker15.1, Tabel 18 O x
FR20i Facility Marker, door
CCITT gespecificeerde
DTE-faciliteiten15.1 O x
FR21 Calling Address Exten-
sion14.1, 15.3.2.1 x
FR22i Called Address Exten-
sion14.2, 15.3.2.2 x
FR23b Minimum Throughput
Class Negotiation,
basisformaat14.3, 15.3.2.3.1,
Tabel 20aOx
FR23e Minimum Throughput
Class Negotiation,
uitgebreid formaat14.3, 15.3.2.3.2,
Tabel 20bOx
FR24i End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FR25i Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FR26i Prioriteit 14.5, 15.3.2.5 O x
FR27i Bescherming 14.6, 15.3.2.6 O x
Tabel 20
Faciliteiten ontvangen in CALL CONNECTED-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten ontvangen in
CALL CONNECTED-
pakkettenReferenties Status Referenties Status
FR1pr Flow Control Para-
meter Negotiation,
pakket-grootte13.12,
15.2.2.1.1, Tabel
14Ox
FR1wr Flow Control Para-
meter Negotiation,
venstergrootte13.12,
15.2.2.1.2, Tabel
14Ox
FR2rb Basic Throughput
Class Negotiation13.13,
15.2.2.2.1, Tabel
20aOx
FR2re Extended Throughput
Class Negotiation13.13,
15.2.2.2.2, Tabel
20bOx
FR10r Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FR12r TransitDelay Select ion
and Indication13.27, 15.2.2.13 O x
FR99r Lokale niet-X.25-faci-
liteiten, volgens Faci-
lity Marker15.1, Tabel 18 O x
FR20r Facility Marker, door
CCITT gespecificeerde
DTE-faciliteiten15.1 O x
FR22r Called Address Exten-
sion14.2, 15.3.2.2 O x2000R2082 — NL — 15.06.2002 — 001.001 — 214
▼B
Basisnormfuncties Profielfuncties
ItemFaciliteiten ontvangen in
CALL CONNECTED-
pakkettenReferenties Status Referenties Status
FR24r End-to-end Transit
Delay Negotiation14.4, 15.3.2.4 O x
FR25r Expedited Data Nego-
tiation14.7, 15.3.2.7 O x
FR26r Prioriteit 14.5, 15.3.2.5 O x
FR27r Bescherming 14.6, 15.3.2.6 O x
Tabel 21
Faciliteiten ontvangen in CLEAR INDICATION-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten ontvangen in
CLEAR INDICATION-
pakkettenReferenties Status Referenties Status
FR8ad Charging information,
monetaire eenheid13.22, 15.2.2.8.2 O x
FR8bd Charging information,
segmenttelling13.22, 15.2.2.8.3 O x
FR8cd Charging information,
oproep-duur13.22, 15.2.2.8.4 O x
FR10d Called Line Address
Modified Notification13.26, 15.2.2.12 O x
FR99d Lokale niet-X.25-faci-
liteiten, volgens Faci-
lity Marker15.1, Tabel 18 O x
FR20d Facility Marker, door
ITU-T gespecificeerde
DTE-faciliteiten15.1 O x
FR22d Called Address Exten-
sion14.2, 15.3.2.2 O x
Tabel 22
Faciliteiten ontvangen in CLEAR CONFIRMATION-pakketten
Basisnormfuncties Profielfuncties
ItemFaciliteiten ontvangen in
CLEAR CONFIRMA-
TION-pakkettenReferenties Status Referenties Status
FR8af Factureringsinformatie,
monetaire eenheid13.22, 15.2.2.8.2 O x
FR8bf Factureringsinformatie,
segmenttelling13.22, 15.2.2.8.3 O x
FR8cf Factureringsinformatie,
oproep-duur13.22, 15.2.2.8.4 O x2000R2082 — NL — 15.06.2002 — 001.001 — 215
▼B
E.8.2.5. Parameterwaarden en -bereiken
Tabel 23
Parameterwaarden en -bereiken
Basisnormfuncties Profielfuncties
ItemParameterwaarden en -
bereikenReferenties Status Referenties Status
Welke waarden
worden ondersteund:
V1s — Standaard pakket-
grootten (zendend)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
bytes6.3.2 Ten-
minste
128 en
256
V1r — Standaard pakket-
grootten (ontvangend)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
bytes6.3.2 Ten-
minste
128 en
256
V2s — Standaard venster-
grootten, zendend?16.2.2.6 (M8: in
hetbereik
1-7)2
V2r — Standaard venster-
grootten, ontvangend?16.2.2.6 (M8: in
hetbereik
1-7)2
E.8.3. Vereisten voor de datalink-laag
De PRL's in deze sectie zijn gebaseerd op de PICS-proforma voor
ISO/IEC 7776:1994 [Referentie 6]. De vermeldingen in de kolom
„Referenties” onder „Basisnormfuncties” van de volgende tabellen
zijn verwijzingen naar clausules in die norm.
Tabel 24
Datalink-protocol
Basisnormfuncties Profielfuncties
Item Datalink-protocol Referenties Status Referenties Status
Lm Multilink-procedure 6 O ox
Lc DTE/DCE-bewerking 1, 5.1 M mo.1
LtDTE/DTE-bewerking 1, 5.1 O mo.1
M8 Basis (Modulo 8)-
bewerking1, 3, 4.1.1 O.1 mm
M128 Uitgebreide (Modulo
128)-bewerking1, 3, 4.1.1 O.1 ox
T4 Aftelklok T4-proce-
dure5.3.2, 5.6.1 O mm
SPN1 Maximum aantal (N1)
bits in een I-frame5.7.3 N1 ≥
1 080N1≥
2 104
SPk Maximum aantal open-
staande frames (k)5.7.4 1 ≤k≤
7k=7
E.8.4. Vereisten voor de fysieke laag
Zie ISO/IEC TR 10609-9 clausule A.4 [Referentie 8].2000R2082 — NL — 15.06.2002 — 001.001 — 216
▼B
BIJLAGE F (Ter informatie)
METHODE VOOR HET TESTEN VAN CONFORMITEIT
F.1. Inleiding
F.1.1. Het is belangrijk dat implementaties van dit ICD zodanig plaats-
vinden dat er een hoog niveau van vertrouwen bestaat voor
onderlinge samenwerking tussen Air Traffic Control Centres
(ATCC's) binnen de gehele interface.
F.1.2. Implementaties van de interface vinden plaats door lidstaten op een
wijze die waarschijnlijk gebaseerd is op verkrijging uitdiverse
bronnen. Om een hoog niveau van vertrouwen te bereiken dat zulke
implementaties met elkaar samen zullen werken is een gemeenschap-
pelijke verzameling conformiteitstestvereisten nodig om de
voorbereiding voor tests, het testen zelf en de presentatie van de
resultaten te normaliseren.
F.2. Doelstelling en reikwijdte
F.2.1. Deze bijlage bevat een definitie van de benodigdheden voor het testen
van de conformiteit van implementaties van deze Eurocontrol-norm
waarvan deze bijlage een onderdeel vormt.
F.2.2. Deze bijlage geeftmechanismen aan via welke vert rouwen in de
aangenomen interface wordt gevestigd door middel van een procedure
met tests om de claim te valideren.
F.3. Bibliografie
Het volgende document is relevant voor het testen van implementaties
van dit Eurocontrol-normdocument:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Part 1 Integration Test Plan Version 1.0, gedateerd
10 mei 1996 [Referentie 15].
F.4. Ontwikkelingsmethoden en -praktijken
F.4.1. Implementaties van het ICD kunnen plaatsvinden met gebruik van
bepaalde opties en versies van het ICD zelf. Teneinde het potentieel
voor onderlinge samenwerking vast te stellen dient een lidstaat die de
interface implementeert aan te geven welke onderdelen van het ICD
worden ondersteund, vergezeld van een gedefinieerde verklaring met
betrekking tot de mogelijkheden en eventuele beperkingen welke
worden ondersteund voor variabele parameters.
F.4.2. Elke implementatie dient te worden onderworpen aan een conformi-
teittest zoals hieronder beschreven.
F.5. Tests
F.5.1. Inleiding
F.5.1.1. Teneinde vertrouwen in en ondersteuning voor een FDE-interface
binnen een ATCC te bewerkstelligen voor de onderlinge samenwer-
king tussen samenwerkende FDE-applicaties is het gewenst dat elk
wordt getest op conformiteit aan de normen waarvan deze bijlage
een onderdeel vormt. Dergelijke tests vinden plaats aan de hand van
de externe gedragingen van het System Under Test (SUT) en zijn
eerder bedoeld om de onderlinge samenwerking uit te testen dan de
bruikbaarheid van heteindsyst eem.
F.5.1.2. De resultaten van dergelijke tests kunnen als bewijs dienen ter onder-
steuning van claims van conformiteit in overeenstemming met Sectie
5.1 van dit Eurocontrol-normdocument. De PICS proforma's en PRL's
die door deze profielspecificatie worden aangeroepen kunnen worden
gebruikt als basis voor conformiteittests; daarnaast kunnen in interna-
tionale normen (bijv. ISO/IEC 8208 [Referentie 7]) reeds abstracte
testsuites gedefinieerd zijn die kunnen worden gebruikt bij conformi-
teittests.
F.5.1.3. Hetdoel van ditdocumentis om t e voorzien in een genormaliseerd
programma van tests dat berust op een genormaliseerde testsuite
waarvan het gebruik dient te leiden tot een vergelijkbaarheid van test-
resultaten, brede acceptatie van dergelijke testresultaten en een2000R2082 — NL — 15.06.2002 — 001.001 — 217
▼B
minimalisering van de benodigde conformiteittests. De genormali-
seerde testsuite is, gedeeltelijk, ontwikkeld door Eurocontrol.
F.5.1.4. Op basis van Figuur 2 neemt het testen van het complete eindsysteem
de vorm aan van tests van de onderste drie lagen. Geadviseerd wordt
om tijdens het testen ook tests op te nemen van de berichten van de
FDE-applicatie en van status-, systeem- en operator-berichten.
F.5.1.5. Elke hieronder beschreven test dient op volgorde te worden uitge-
voerd. De laatste test kan alleen succesvol zijn als de lagere lagen
correctfunct ioneren en hetis waarschijnlijk datditmetde eerdere
tests kan worden geverifieerd.
F.5.1.6. Niettegenstaande het bovenstaande zijn de in deze sectie beschreven
tests vrijwillig.
F.5.2. Testen van de lagere lagen (lagen 1-3)
Ter ondersteuning van de vereiste voor onderlinge samenwerking
tussen elk van de ATCC's en hun gelijken wordt aanbevolen dat alle
tests zullen zijn gebaseerd op het gebruik van het testplan zoals
beschreven in het Eurocontrol (Maastricht UAC Systems Division)
FDE ICD Integration Test Plan. Testprocedures dienen bilateraal te
worden overeengekomen tussen samenwerkende ATCC's.
F.5.3. Testen van de applicatielaag
Er dient een reeks bilateraal overeengekomen tests te worden afge-
sproken en uitgevoerd door de samenwerkende ATCC's.
F.5.4. Bevestiging
De resultaten van tests dienen te worden geregistreerd en overeenge-
komen tussen de samenwerkende partijen.
F.5.5. Mededeling
Lidstaten dienen gegevens met betrekking tot de resultaten van alle
test mede te delen aan Eurocontrol.2000R2082 — NL — 15.06.2002 — 001.001 — 218
▼B
BIJLAGE G (Ter informatie)
TOEWIJZING VAN AANDUIDINGEN VOOR ATC-EENHEDEN
De volgende tabel toont de aanduidingen voor de ATC-eenheden zoals die per
22 april 1997 zijn toegewezen. Eurocontrol kan informatie leveren over de
huidige toewijzing van aanduidingen. De tabel toont eveneens in hexadecimale
notatie de binaire codering van de aanduiding als onderdeel van de NSAP-adres-
codering zoals gedefinieerd in Bijlage C.
Tabel 1
Aanduidingen van ATC-eenheden
Aanduiding ATC-eenheid Codering Beschrijving
00 Gereserveerd
01 '01'H CATCAS, Kopenhagen
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Brussel
05 '05'H Algemeen CAUTRA, Frankrijk
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, Londen
09 '09'H Oslo ATCC
10 '10'H Karlsruhe ATCC
11 '11'H Langen (toekomstig Duits systeem)
12 '12'H FATMI-systeem, Tampere
13 '13'H ROVA-systeem, Rovaniemi14 '14'H VAS, Wenen
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H Geneve ACC/FMP
18 '18'H Zürich ACC/FMP
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milaan
23 '23'H Rome
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 Praag2000R2082 — NL — 15.06.2002 — 001.001 — 219
▼B
Aanduiding ATC-eenheid Codering Beschrijving
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Duits militair systeem
42 '42'H Duits militair systeem
43 '43'H Duits militair systeem
44 '44'H Duits militair systeem
45 '45'H Duits militair systeem
46 '46'H Duits militair systeem
47 '47'H Duits militair systeem
48 '48'H Duits militair systeem
49 '49'H Duits militair systeem
50 '50'H München (toekomstig Duits systeem)
51 '51'H Zagreb
52 '52'H Hahn Airport, Duitsland
53 '53'H Santa Maria FIR
54 '54'H Ljubljana
55 '55'H Belgisch militair systeem
56 '56'H Budapest57 '57'H Warschau2000R2082 — NL — 15.06.2002 — 001.001 — 220
▼B
BIJLAGE H (Ter informatie)
ADVIEZEN MET BETREKKING TOT BETROUWBAARHEID,
BESCHIKBAARHEID EN BEVEILIGING
H.1. Inleiding
Naar verwachting zullen ATC-applicaties zoals OLDI gebruik maken
van onderling verbonden X.25-netwerken en/of openbare of besloten
telecommunicatiediensten. Als gevolg daarvan wordt het noodzake-
lijk geacht om richtlijnen te bieden voor FDE ICD Part 1
implementaties.
H.2. Doelstelling en reikwijdte
H.2.1. Hetdoel van deze bijlage is om adviezen t e geven over zaken
aangaande betrouwbaarheid, beschikbaarheid en beveiliging.
H.2.2. De reikwijdte van deze bijlage is gebaseerd op twee scenario's. Het
eerste scenario is een punt-punt-verbinding over een huurlijn. Het
tweede scenario is gebaseerd op een onderling verbonden X.25-
netwerkomgeving.
OPMERKING Voor het tweede scenario worden zaken met betrek-
king tot de onderlinge verbinding van de X25-
netwerken niet in beschouwing genomen.
H.2.3. Er zal voor worden gezorgd dat implementaties fysiek beschermd
zijn tegen binnendringing, stroomuitval en andere externe bedrei-
gingen die de normale werking kunnen verstoren.
H.3. Bibliografie
Het volgende document bevat een gedetailleerde technische analyse
waarvan deze bijlage een overzichtis:
Eurocontrol FDE ICD Part 1: Reliability, Availability and Security
— Technical Report[Referent ie 16].
H.4. Implementaties van huurlijnen
H.4.1. Betrouwbaarheid
Om de betrouwbaarheid van de dienst te verhogen dienen kabels voor
huurlijnen, PSTN, Integrated Services Digital Network (ISDN) fysiek
verschillende paden te volgen en te worden aangesloten op verschil-
lende switches van telecommunicatie-aanbieders (dit dient aan de
telecommunicatie-aanbieder te worden gespecificeerd).
H.4.2. Beschikbaarheid
H.4.2.1. Als gevolg van lange insteltijden op PSTN die incompatibel zijn met
applicaties met tijdsbeperkingen dient ISDN als backup-medium te
worden gebruikt.
H.4.2.2. In hetgeval van een DTE-omschakeling dientde DTE die st and-by is
een DISC frame te genereren om herstel van de verbinding te bespoe-
digen.
H.4.3. Beveiliging
H.4.3.1. Bij gebruik van ISDN als backup-medium dientde ISDN t erminal
adapter (TA) waaraan de oproep is gericht het E.164-adres
[Referentie 18] te valideren van degene waarvan de oproep uitgaat.
H.4.3.2. De DTE waarvan de oproep uitgaat dient te voldoen aan ITU-T-
aanbeveling X.32 [Referentie 17] door opname van oproeper-identifi-
catie en identificatie-informatie.2000R2082 — NL — 15.06.2002 — 001.001 — 221
▼B
H.4.4. Configuratievoorbeeld
Figuur H.1
Voorbeeld van een huurlijnconfiguratie
H.5. Netwerkimplementatie
H.5.1. Betrouwbaarheid
Om de betrouwbaarheid van de dienst te verhogen dienen de hosts op
een gegeven site te worden verbonden met twee DCE's die behoren
bij verschillende netwerk-switches (deze vereiste dient aan de
netwerkbeheerder te worden gespecificeerd).
H.5.2. Beschikbaarheid
H.5.2.1. De hunt group-faciliteit dient zodanig te worden gebruikt dat het
mogelijk is om een enkel X.121-adres [Referentie 20] toe te wijzen
aan de DCE's die zich op een gegeven site bevinden, waardoor de
netwerkroutering wordt geoptimaliseerd en niet-succesvolle oproepen
worden beperkt.
H.5.2.2. In hetgeval datandere aanroepmechanismen worden geïmplemen-
teerd die resulteren in een andere aangeroepen DTE-adreswaarde in
de CALL REQUEST- en CALL ACCEPT-pakketten, dient de DTE
waarvan de oproep afkomstig is zodanig te zijn geconfigureerd dat
er geen invloed bestaat op het opstellen van de oproep.
H.5.2.3. Als zich een DCE-ontkoppeling als gevolg van een netwerkfout voor-
doet en er een tweede toegang tot het netwerk beschikbaar is, dient
de oproep via deze tweede toegang te worden hersteld.
H.5.3. Beveiliging
Binnen de reikwijdte van deze bijlage is de Closed User Group
(CUG) faciliteit de enige toepasselijke netwerkfaciliteit die dient te
worden gebruikt.
H.6. Algemene richtlijnen voor huurlijn- en netwerkimplementaties
H.6.1. Betrouwbaarheid
H.6.1.1. Aangezien een volledige host-omschakeling lang kan duren, kan het
voordeel hebben om het gebruik te overwegen van een front-end
processor (FEP) om host-fouten op te vangen.
H.6.1.2. Een architectuur op basis van een FEP kan de betrouwbaarheid van
de dienstverhogen.
OPMERKING: Opname van een transportstapeling in de profielspe-
cificatie kan worden ontwikkeld in de context van
een toekomstige FDE ICD Part 2 norm.2000R2082 — NL — 15.06.2002 — 001.001 — 222
▼B
H.6.2. Beschikbaarheid
Als een oproep nietsuccesvol is, dienthetsyst eem waarvan de
oproep afkomstig is een tweede oproep uit te voeren met gebruik
van hett weede X.121-adres (indien beschikbaar).
H.6.3. Systeembeheer
H.6.3.1. Waar mogelijk dienen schakelaars te worden toegepast die automa-
tisch worden omgezet door het scannen van de interfacesignalen.
H.6.3.2. Een lokale foutaanduiding tijdens datatransmissie kan worden
gebruikt om een hostoverschakeling te activeren.
H.6.3.3. Hetoverschakelen van een FEP dienteen TC-disconnectt e genereren
om ervoor te zorgen dat de lokale host in de IDLE-state staat.
H.6.3.4. Na verloop van de afteltijd op het X.25-netwerk of de gegevensver-
bindingslagen dienen de hogere lagen te worden vrijgegeven.
H.6.3.5. Een totale FEP-fout dient een TC-disconnect te genereren.
H.6.3.6. Het beheersysteem dient voortdurend de Message Transfer Protocol-
laag (bijlage A) te bevragen en de machinestatus te controleren om
verschil te maken tussen een Message Transfer Protocol-fout en een
applicatiefout.
H.6.4. Voorbeeldconfiguratie
Figuur H.2
Voorbeeld van een netwerkconfiguratie2000R2082 — NL — 15.06.2002 — 001.001 — 223