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
Publicatieblad Nr. L 254 van 09/10/2000 blz. 0001 - 0234
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 betreffende de vaststelling en het gebruik van compatibele technische normen en specificaties voor de aanschaf van apparatuur en van systemen 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 Richtlijn 93/65/EEG van de Raad betreffende de vaststelling en het gebruik van compatibele 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-norm voor Air Traffic Services Data Exchange Presentation (presentatie 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 Data Exchange - 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 tussen verkeersleidingscentra (OLDI), de afhandeling van luchtverkeersstromen (ADEXP) en de communicatie tussen nationale systemen (FDE-ICD). (4) De edities 2.2 van OLDI en 2.0 van ADEXP treden in de plaats van de voorgaande uitgaven, die momenteel van kracht zijn op grond 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 overeenstemming met het advies van het comité dat conform Richtlijn 93/65/EEG is ingesteld, HEEFT DE VOLGENDE VERORDENING VASTGESTELD: Artikel 1 De bindende elementen van de Eurocontrol-specificaties die opgenomen 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 Europees systeem 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 Data Exchange Presentation) (ADEXP), editie 2.0 (Eurocontrol-referentiedocument DPS.ET1.ST09-STD), waarvan de tekst in bijlage II bij deze verordening is opgenomen, - de Eurocontrol-norm voor uitwisseling van vluchtgegevens - interfacebesturingsdocument (Flight Data Exchange - Interface Control Document) (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. Gedaan te Brussel, 6 september 2000. Voor de Commissie Loyola De Palacio Vice-Voorzitter (1) PB L 187 van 29.7.1993, blz. 52. (2) PB L 95 van 10.4.1997, blz. 16. BIJLAGE I ON-LINE DATA INTERCHANGE (OLDI), EDITIE 2.2 (Eurocontrol-referentiedocument DPS.ET1.ST06-STD) INHOUDSOPGAVE >RUIMTE VOOR DE TABEL> AUTEURSRECHT Dit document is geproduceerd door Eurocontrol Agency. Het auteursrecht berust bij Eurocontrol Agency. De inhoud of enig deel daarvan is derhalve vrijelijk beschikbaar voor vertegenwoordigers van de lidstaten, maar kopiëren of openbaar maken aan derden vereist voorafgaande schriftelijke toestemming van Eurocontrol Agency. VOORWOORD 1. Verantwoordelijke instantie De Eurocontrol-norm voor On-Line Data Interchange (OLDI), Uitgave 2.2 is opgesteld door het Directorate of European ATC Harmonisation and Integration Programme (EATCHIP) Development (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, Eurocontrol, 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 vormt een te realiseren onderdeel op grond van de Specialist Task DPS.ET1.ST06 van het ATM Data Processing Systems (DPS) domein van EATCHIP zoals gespecificeerd in het EATCHIP Work Programme Document (EWPD) Edition 2.0, gedateerd 30/09/94. 3. Goedkeuring en amendementen Deze norm is onderworpen aan de volgende goedkeuringsprocedure zoals beschreven in de richtlijnen voor normalisatie van Eurocontrol: - goedkeuring door het EATCHIP Operational Requirement and 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 Project Board en de Committee of Management; - aanvaarding door de Permanente Commissie. De bepalingen van deze norm worden van kracht na 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 bespreking en mogelijke goedkeuring. De vereisten worden ofwel opgenomen als een amendement of als een volgende uitgave van het document ter bekrachtiging en goedkeuring conform gespecificeerde 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 het prefix Aanbeveling. Het volgende redactionele gebruik is gehanteerd bij het opstellen van de specificaties: voor normatieve elementen zijn de (hulp)werkwoorden "zullen" of "dienen" gebruikt en voor Aanbevolen elementen zijn de (hulp)werkwoorden "zouden" of "dienen" gebruikt. Opmerkingen staan afgedrukt in een cursief licht lettertype, voorafgegaan door het prefix "Opmerking". 5. Relatie met Uitgave 1 van de Eurocontrol Standard for On Line Data Interchange Dit document vervangt de delen 1 en 2 van Uitgave 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. 6. Belangrijke wijzigingen ten opzichte van Uitgave 1 Hier volgt een overzicht van de belangrijkste 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) [bericht voor de opheffing van coördinatie]; - Secondary Surveillance Radar (SSR) Code Assignment (COD) Message [secundaire bewakingsradar codetoewijzingsbericht]; - Information (INF) Message [informatiebericht]. 2. Definitie van inhoud en structuur van berichten ter ondersteuning van het overschrijden van een grens door een vlucht op een route die geen gedefinieerde Air Traffic Services (ATS)-route is, maar die wordt gedefinieerd door de begin- en eindpunten van het routesegment. 3. Integratie van een dialoogprocedure die het volgende mogelijk maakt: - de aanwijzing en totstandkoming van niet-standaard transfervoorwaarden 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 overdracht van de controle. 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 met gebruik van de structuren van zowel de International Civil Aviation Organisation (ICAO) als de ADEXP. Transfer of Communication-berichten die zijn beschreven op grond van de dialoogprocedure worden alleen beschreven met gebruik 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 voorbeelden). 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 dit document wordt gerefereerd aan het gebruik van twee typen veldstructuren bij de samenstelling van berichten; namelijk ICAO en ADEXP. ICAO-veldstructuren worden beschreven in Referentie 1. In het geval dat Referentie 1 wordt vervangen 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. 8. Taal Het origineel van dit document is gesteld in de Engelse taal. 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 verantwoordelijkheidsgebieden van de twee eenheden door hen tevoren wordt gecoördineerd en dat de controle over de vlucht wordt 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 met als doel om dergelijke verbale "schattingen" 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 Eurocontrol 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 voor ATC-eenheden werken met als doel het volgende te 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. Dit document bevat: - definities van de berichtenstructuren en de regels voor de inhoud daarvan; - een beschrijving van de bij zulke eenheden vereiste faciliteiten 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-dienst voor 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 Eurocontrol-normdocument. Ten tijde van publicatie van dit Eurocontrol-normdocument waren de genoemde uitgaven van de documenten waarnaar wordt verwezen correct. Met elke herziening van de ICAO-documenten waarnaar wordt verwezen wordt onmiddellijk rekening gehouden door 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 dit Eurocontrol-normdocument zijn opgenomen. In het geval van conflicten tussen de vereisten van dit Eurocontrol-normdocument en de inhoud van deze andere documenten waarnaar wordt verwezen, prevaleert dit Eurocontrol-normdocument. 2.2. In dit normdocument wordt verwezen naar de volgende documenten: 1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services [procedures voor luchtvaartnavigatiediensten - 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-dienst levert en de controle dient over te nemen of heeft overgenomen van een vlucht als de overdracht van de ene eenheid naar de andere dient plaats te vinden of heeft plaatsgevonden. 3.1.2. Bevestiging: mededeling dat een bericht is ontvangen en dat is gebleken dat het op de juiste manier kan worden verwerkt 3.1.3. Activering: het proces in een ontvangende 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 gegevens 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: dat onderdeel van een ATS-subsysteem dat zich conformeert aan deze norm en samenwerkt met zulke eenheden in andere ATS-systemen. 3.1.6. Verantwoordelijkheidsgebied: een luchtruim met gedefinieerde afmetingen waarbinnen een ATC-eenheid luchtverkeersleidingdiensten levert. 3.1.7. Associatie: een procedure waarbij een systeem een ontvangen OLDI-bericht associeert met een in de database ingevoerd vluchtplan. 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 verantwoordelijkheidsgebied van een ATC-eenheid afbakenen. 3.1.11. Vrijgegeven vluchtniveau: het vluchtniveau waarnaar of waarop een vlucht op dit moment door ATC is vrijgegeven. 3.1.12. Coördinatie, ATC: het proces, uitgevoerd tussen ATC-eenheden met aangrenzende verantwoordelijkheidsgebieden, waarbij deze elkaar formeel op de hoogte brengen van de geplande passage van vluchten over de grens, teneinde de vluchtveiligheid te garanderen door middel van consistentie van voorgenomen acties. 3.1.13. Coördinatiebericht: een algemene term die verwijst naar een bericht dat wordt gebruikt voor het tot stand brengen van ATC-coördinatie. Daartoe behoort de CDN, wat een specifiek bericht is dat wordt besproken 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) waaronder een vlucht van de leiding van de ene eenheid overgaat naar die van de andere. 3.1.15. Coördinatiepunt: een punt op of naast de grens bekend bij de ATC-eenheden in een coördinatiereeks en waarnaar wordt verwezen in coördinatieberichten. 3.1.16. Correlatie: het proces gebaseerd op gedefinieerde criteria 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 essentieel 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: het niveau waarop een vlucht is gecoördineerd om een controleoverdrachtspunt te passeren. Tot een exit-niveau kunnen aanvullende passeervoorwaarden behoren die de niveauband definiëren waarbinnen een klimmende/dalende vlucht zich zal bevinden. 3.1.20. Vluchtplan: gespecificeerde informatie geleverd aan luchtverkeersdiensteenheden, 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 uit de database(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 gebruikt ook de hoogte. 3.1.24. Mededeling: het proces waarbij de overdragende eenheid gegevens 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 wordt verzonden. 3.1.26. Betrouwbaarheid: het percentage van de geplande beschikbaarheid gedurende welke de dienst beschikbaar dient te zijn. 3.1.27. Aangevraagd vluchtniveau: een vluchtniveau dat voor de vlucht in het vluchtplan wordt aangevraagd. 3.1.28. Herziening: een amendement op eerder door de overdragende ATC-eenheid aan de ontvangende ATC-eenheid verzonden gegevens. 3.1.29. Supplementair passeerniveau: een niveau, waarop of waarboven, of waarop of waaronder een vlucht gecoördineerd is om het controleoverdrachtspunt te passeren. Het supplementaire niveau, indien aanwezig, is een onderdeel van het exit-niveau. 3.1.30. Systeemvluchtplan: informatie afkomstig uit het vluchtplan van een specifieke vlucht die plaatsvindt binnen een FDPS. 3.1.31. Transactietijd: een tijdsinterval volgend op de start van een bericht gedurende welke de verzending, de eerste verwerking in het ontvangende systeem, het genereren en het verzenden van een bevestigingsbericht en de identificatie daarvan in het overdragende systeem plaatsvinden. 3.1.32. Controleoverdrachtspunt: een gedefinieerd punt dat zich bevindt op een vliegroute van een vliegtuig, waarop de verantwoordelijkheid voor de levering van ATS aan het vliegtuig wordt overgedragen van de ene ATC-eenheid of controlepost aan de volgende. Valt niet noodzakelijkerwijze samen met het coördinatiepunt. 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 vlucht voor de grens en die de coördinatiefase met de volgende eenheid start. 3.1.35. Verzenden: een bericht van het ene systeem naar het andere overbrengen. 3.1.36. Eenheid: diensteenheid voor luchtverkeer. 3.1.37. Waarschuwing: een bericht dat op een werkplek wordt afgebeeld 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 [voorafgaand bericht met grensinformatie] ACC Area Control Centre [gebiedscontrolecentrum] ACP Accept Message [bericht accepteren] ACT Activate Message [bericht activeren] ADEXP ATS Data Exchange Presentation [presentatie uitwisseling ATS-gegevens] ATC Air Traffic Control [luchtverkeersleiding] ATM Air Traffic Management [luchtverkeersbeheer] ATS Air Traffic Service [luchtverkeersdienst] CDN Co-ordination Message [coördinatiebericht] CNL Flight Plan Cancellation [annulering vluchtplan] COD SSR Code Assignment Message [toewijzingsbericht SSR-code] COF Change of Frequency Message [frequentiewijzigingsbericht] COP Co-ordination Point [coördinatiepunt] DED Directorate of EATCHIP Development, Eurocontrol [directoraat van EATCHIP-ontwikkeling, Eurocontrol] 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 [internationale organisatie voor de burgerluchtvaart] INF Information Message [informatiebericht] LAM Logical Acknowledgement Message [logisch bevestigingsbericht] LoA Letter of Agreement [overeenkomstbrief] MAC Message for the Abrogation of Co-ordination [bericht voor de opheffing van coördinatie] MAS Manual Assumption of Communications [handmatige overname van communicatie] NM Nautical Mile [zeemijl] OLDI On-Line Data Interchange [on-line gegevensuitwisseling] ORCAM Originating Region Code Assignment Method [codetoewijzingsmethode voor herkomstregio] PAC Preliminary Activate Message [bericht van voorlopige activering] RAP Referred Activate Proposal Message [bericht met voorstel tot activering waarnaar wordt verwezen] REV Revision Message [herzien bericht] RJC Reject Co-ordination Message [bericht met afwijzing van coördinatie] ROF Request on Frequency Message [bericht met vraag over frequentie] RRV Referred Revision Message [herzien bericht waarnaar wordt verwezen] SBY Stand-by Message [stand-by-bericht] SDM Supplementary Data Message [supplementair gegevensbericht] SSR Secondary Surveillance Radar [secundaire bewakingsradar] SYSCO System Supported Co-ordination [systeemondersteunde 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 prestatievereisten 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 dit document beschreven faciliteit zullen worden voorzien van gegevens afkomstig van een FDPS die alle benodigde informatie bevat voor de gespecificeerde afbeelding, verwerking en samenstelling van de berichten. De primaire gegevensbron voor elke vlucht is het vluchtplan 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 omvat gebeurtenissen 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 accepterende eenheid. Voor dat doel zal het FDPS in staat zijn 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. 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 garanderen; 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 datacommunicatie 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. Het FDPS 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. Het volgende wordt bilateraal overeengekomen: - Coördinatiepunten (COP's); - Referentiepunten gebruikt voor koers- en afstandnotaties voor het identificeren van het COP op directe, niet-ATS-routesegmenten, 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 aandacht behoeven af te beelden; - waarschuwingen met betrekking tot routecoördinatie- en overdrachtsberichten door te geven aan de operationele posities die verantwoordelijk zijn voor de coördinatie van de betreffende 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 het bericht plaatsvindt of dat het met succes 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. 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 verzending 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 wordt afgebeeld; - aanlooptijd, globaal of per COP, om het bericht te verzenden, waar van toepassing; - tijd na verzending van een bericht waarbinnen een applicatieniveaubevestiging 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 het anders zou zijn verzonden. Voorbeeld: een vlucht begint een GAT IFR-segment op een punt dichtbij de grens die de vlucht dan zal passeren; de ETO op dat punt wordt acht minuten voor het COP 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 gegenereerd en verzonden als het bijbehorende bericht is verwerkt en de presentatie van de resultaten van de verwerking aan de betreffende positie(s), waar nodig, is verzekerd.OPMERKING de gedetailleerde voorwaarden voor het genereren 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. 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 beschikbaar te zijn. 4.5.1.3. Alle geplande uitvalperioden (en dus de geplande beschikbaarheidtijd) 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-faciliteiten te worden toegepast. 4.5.4. Gegevensintegriteit Het aantal fouten op applicatieniveau zal niet meer bedragen dan een (1) verzendfout per 2000 berichten. 4.6. Operationele evaluatie 4.6.1. Evaluatieperiode Elke nieuwe OLDI-faciliteit, met inbegrip van een nieuwe faciliteit op een bestaande verbinding, zal voorafgaand aan de operationele implementatie worden onderworpen aan een evaluatieperiode 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 Eurocontrol. 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; - wordt vermeld welke berichten verplicht en welke complementair 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. 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 bevestigingsbericht, de verzending daarvan en de ontvangst bij de overdragende eenheid. De automatische bevestigingsberichten LAM en SBY zijn daarom niet aan een berichtencategorie toegewezen. 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 >RUIMTE VOOR DE TABEL> 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 ontvangen zal een bericht als niet met succes verzonden of verwerkt worden beschouwd en zal een waarschuwing worden afgegeven zoals gespecificeerd in het betreffende gedeelte van dit document. 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 dit document beschreven berichten worden geclassificeerd als verplicht of complementair. 5.3.1.2. Als een bericht wordt omschreven als verplicht (V) voor verzending (TX), omvat dit ook de verwerking om dergelijke berichten te kunnen verzenden. 5.3.1.3. Als een bericht wordt omschreven als verplicht voor ontvangst (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 bericht wordt omschreven als complementair (C) voor verzending, omvat dit ook de verwerking om dergelijke berichten te verzenden indien vereist door de verzendende eenheid en bilateraal 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 bericht wordt omschreven als complementair voor ontvangst, omvat dit ook de verwerking om ontvangen berichten te kunnen verwerken als dergelijk gebruik bilateraal is overeengekomen. 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 communicatie 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. 5.3.2.2. De categorisatie van de aanvullende coördinatieberichten voor de dialoogprocedure wordt gespecificeerd in Tabel 5-3. 5.3.2.3. De categorisatie van berichten voor overdracht van communicatie voor de dialoogprocedure wordt gespecificeerd in Tabel 5-4. Tabel 5-2 Basisprocedureberichten >RUIMTE VOOR DE TABEL> Tabel 5-3 Dialoogprocedure - Coördinatiefaseberichten (aanvulling op Tabel 5-2) >RUIMTE VOOR DE TABEL> Tabel 5-4 Dialoogprocedure - Overdrachtsfaseberichten >RUIMTE VOOR DE TABEL> 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 het gebruik van ACT- en LAM-berichten zullen gelden zoals in dat gedeelte 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. Het ABI-bericht is een mededelingbericht. 6.2.2. Inhoud van 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; - Route (optioneel); - Overige vluchtplangegevens (optioneel). OPMERKING Regels voor invoegen van gegevens, structuren en inhoud van velden worden gespecificeerd in Bijlage A. 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 het ABI-bericht vooraf gaan aan het ACT- (Activate) of RAP-bericht (Referred Activate Proposal). 6.2.3.1.3. Er zal geen ABI-bericht worden 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 tijdsinterval.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-bericht zal worden verzonden als het daarop volgende ACT-bericht niet is gegenereerd en: - de vliegroute zodanig is gewijzigd dat het COP in het vorige ABI-bericht niet langer accuraat is; - de luchthaven van bestemming is gewijzigd; of - het type vliegtuig is gewijzigd. 6.2.3.1.6. Aanbeveling: Een herzien ABI-bericht dient te worden verzonden als het daaropvolgende ACT-bericht niet is gegenereerd 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 afwijking wordt geconstateerd tussen de gegevens in het bericht en bijbehorende gegevens in het ontvangende systeem die zou resulteren 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 Het ABI-bericht zal worden bevestigd door het genereren en verzenden van een LAM-bericht. 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 bevestiging 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 het ABl-bericht dat van Reims naar Londen ACC wordt gezonden. 6.2.5.1. ICAO (ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON) 6.2.5.2. ADEXP -TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON 6.3. 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 vlucht van de ene ATC-eenheid naar de volgende voorafgaand aan de overdracht van de controle; - Het basisvluchtplangegevens in de ontvangende ATC-eenheid bijwerken met de meest recente informatie; - Binnen de ontvangende ATC-eenheid de distributie en afbeelding van vluchtplangegevens aan de betrokken werkplekken vergemakkelijken; - Afbeelden van oproepletters/code-correlatie in de ontvangende ATC-eenheid bespoedigen; - De ontvangende ATC-eenheid voorzien van overdrachtsvoorwaarden. 6.3.2. Inhoud van 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; - Route (optioneel); - Overige vluchtplangegevens (eventueel). OPMERKING Regels voor invoegen van gegevens, structuren en inhoud van velden worden gespecificeerd in Bijlage A. 6.3.3. Regels voor toepassing 6.3.3.1. Algemeen 6.3.3.1.1. Voor daarvoor in aanmerking komende vluchten die de grens overschrijden zal een ACT-bericht worden 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 voorafgaand aan de berekende verzendtijd. 6.3.3.1.4. De operationele inhoud van het ACT-bericht dat op het punt staat om te worden verzonden zal worden afgebeeld op de werkplek die verantwoordelijk is voor de coördinatie van de vlucht voorafgaand 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 het ACT-bericht. 6.3.3.1.8. Zodra een LAM-bericht is ontvangen worden de ACT-berichtgegevens operationeel bindend voor beide ATC-eenheden. De gecoördineerde overdrachtsvoorwaarden en het feit dat het LAM-bericht is ontvangen 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-bericht geïmpliceerde overdrachtsvoorwaarden zal worden verondersteld, tenzij de ontvangende eenheid coördinatie start om deze te amenderen. 6.3.3.1.10. Een volgend ACT-bericht mag alleen naar dezelfde coördinatiepartner 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 eenheid 6.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 afwijking in het bericht voorkomt die een correcte verwerking zou verhinderen: - zal de operationele inhoud worden opgenomen in het vluchtplan; - zullen de vereiste gegevens beschikbaar worden gesteld op de daarvoor in aanmerking komende operationele ATC- en andere posities; - zal een LAM-bericht worden teruggezonden. 6.3.3.2.3. Als geen bijbehorend vluchtplan kan worden gevonden, of als een afwijking wordt aangetroffen die de juiste verwerking van het bericht verhindert: - 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 afgebeeld bij de sector; - zal een LAM-bericht worden teruggezonden; - zal een vluchtplan worden aangemaakt; - in alle andere gevallen zal geen LAM-bericht worden teruggestuurd. 6.3.3.3. Parameters voor verzending 6.3.3.3.1. Het bericht zal op of zo snel mogelijk na de eerdere van de als volgt bepaalde tijden worden verzonden: - een parameter-aantal minuten voor de geschatte tijd bij het COP; - de tijd waarop de vlucht zich op een bilateraal overeengekomen 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 het overdrachtsniveau van de vlucht bij te werken met de te verwachten omstandigheden op het COP; 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 Het ACT-bericht zal worden bevestigd door het genereren en verzenden van een LAM-bericht. 6.3.4.2. Gevallen zonder bevestiging Als geen LAM-bericht wordt ontvangen ter bevestiging van een ACT-bericht zal 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 het ABI-bericht in paragraaf 6.2; alle details zijn hetzelfde behalve de ETO op het COP, die in het afgebeelde ACT-bericht 1226 is. 6.3.5.1. ICAO (ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON) 6.3.5.2. ADEXP -TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON 6.4. LAM-bericht (Logical Acknowledgement Message) 6.4.1. Doel van het LAM-bericht Het LAM-bericht is het middel waarmee door de ontvangende eenheid aan de verzendende eenheid de ontvangst en beveiliging van een verzonden bericht wordt aangegeven. De verwerking van het LAM-bericht voorziet de ATC-medewerkers van de overdragende eenheid van het volgende: - een waarschuwing als geen bevestiging werd ontvangen; - een indicatie dat het bericht dat wordt bevestigd is ontvangen, met succes is verwerkt, foutvrij is bevonden, is opgeslagen en, indien relevant, beschikbaar is voor presentatie aan de betreffende 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. Algemeen 6.4.3.1.1. De regels voor het terugzenden van een LAM-bericht zijn gespecificeerd in de gedeelten van dit document waarin de verwerking van elke bericht wordt gedefinieerd. 6.4.3.1.2. Het LAM-bericht zal worden gegenereerd en verzonden zonder menselijke tussenkomst. 6.4.3.1.3. Het LAM-bericht zal niet worden gebruikt voor het vermijden van de behoefte aan technische berichten bedoeld om de integriteit van gegevensoverdracht te garanderen. 6.4.3.1.4. Het LAM-bericht zal onmiddellijk worden gegenereerd en verzonden zodat de vereiste transactietijd van het bericht dat wordt bevestigd 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 Het LAM-bericht zal geen bevestiging 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 overeengekomen. 7.1.2.2. Als een dergelijk gebruik is overeengekomen zullen de in dit gedeelte beschreven regels worden toegepast. 7.2. PAC-bericht (Preliminary Activate Message) 7.2.1. Doel van het PAC-bericht Het PAC-bericht voldoet aan de volgende operationele vereisten: - mededeling en coördinatie voorafgaand aan vertrek van een vlucht waarvan de vluchtduur van vertrek tot aan het COP minder bedraagt dan die welke vereist zou zijn om te voldoen aan de overeengekomen tijdparameters voor verzending van een ACT-bericht; - mededeling en coördinatie voorafgaand aan vertrek van een vlucht door een lokale (luchthaven/naderingscontrole) eenheid naar de volgende eenheid die de controle over de vlucht overneemt; - zorgt voor ophalen van ontbrekende vluchtplangegevens in het geval van afwijkingen in de eerste verzending van vluchtplangegevens; - vraagt, indien nodig, de toewijzing van een SSR-code van de eenheid waaraan de bovengenoemde mededeling/coördinatie is verzonden. 7.2.2. Inhoud van bericht Het PAC-bericht zal de volgende gegevens bevatten: - berichttype; - berichtnummer; - berichtreferentie (optioneel); - vliegtuigidentificatie; - SSR-modus en -code; - luchthaven van vertrek; - geschatte vertrektijd of geschatte gegevens; - luchthaven van bestemming; - type vliegtuig; - route (optioneel); - overige vluchtplangegevens (optioneel). OPMERKING Regels voor invoegen van gegevens, structuren en inhoud van velden worden gespecificeerd in Bijlage A. 7.2.3. Regels voor toepassing 7.2.3.1. Algemeen 7.2.3.1.1. Voor elke vlucht die gepland is om de grenzen van verantwoordelijkheidsgebieden 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ördinatie is vereist zullen door de luchthaven-/naderingseenheid een of 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 ontleend in 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 vlucht wordt verzonden; - zijn opgenomen in tweede en daarop volgende PAC-berichten. 7.2.3.1.6. Indien vereist zal het gebruik van de codeaanvraagfaciliteit bilateraal worden overeengekomen. 7.2.3.1.7. Als, voorafgaand aan vertrek, aan een van de volgende voorwaarden wordt voldaan zal een herzien PAC-bericht worden verzonden: - de vliegroute is zodanig gewijzigd dat het COP in het vorige bericht niet langer accuraat is; - het type vliegtuig is gewijzigd; - de luchthaven van bestemming in het vorige PAC-bericht is onjuist bevonden. 7.2.3.1.8. Aanbeveling: Als, voorafgaand aan vertrek, de volgende gegevens verschillen van die in het vorige PAC-bericht dient een herzien PAC-bericht te 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 eenheid 7.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 afwijking in het bericht voorkomt die een correcte verwerking zou verhinderen: - zal de operationele inhoud worden opgenomen in het vluchtplan; - zullen de vereiste gegevens beschikbaar worden gesteld op de betreffende operationele ATC- en andere posities; - zal een LAM-bericht worden teruggezonden. 7.2.3.2.3. Als geen bijbehorend vluchtplan kan worden gevonden of als er een afwijking wordt geconstateerd die een juiste verwerking van het bericht verhinderd: - 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-bericht worden teruggezonden; - zal een vluchtplan worden aangemaakt; - in alle andere gevallen zal geen LAM-bericht worden teruggezonden. 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 het PAC-bericht een verzoek voor de toewijzing van een SSR-code bevat en op correcte wijze verwerkbaar is zoals beschreven in paragraaf 7.2.3.2.2 hierboven zal naast het LAM-bericht ook een COD-bericht worden teruggezonden.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 overeengekomen. 7.2.3.3. Tijdparameters voor verzending Een verzendtijdparameter is niet van toepassing aangezien het bericht wordt verzonden als het resultaat van een handmatig ingevoerd bericht dat het op handen zijnde vertrek van de vlucht aangeeft. 7.2.4. Bevestiging van PAC-bericht 7.2.4.1. Bevestiging De berichten die dienen te worden verzonden als antwoord op een PAC-bericht worden 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 verantwoordelijk 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ördinatie worden gestart. 7.2.4.4. Geen COD-bericht 7.2.4.4.1. Als geen COD-bericht wordt ontvangen in antwoord op een codeverzoek dat is opgenomen in het PAC-bericht zal op een daartoe 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. Doel van het REV-bericht Het REV-bericht wordt gebruikt voor het verzenden van herzieningen op eerder in een ACT-bericht verzonden coördinatiegegevens mits de accepterende eenheid niet verandert als gevolg van de aanpassing. 7.3.2. Inhoud van bericht Het REV-bericht zal de volgende gegevens bevatten: - berichttype; - berichtnummer; - berichtreferentie (optioneel); - vliegtuigidentificatie; - SSR-modus en -code (optioneel); - luchthaven van vertrek; - geschatte gegevens; - coördinatiepunt (optioneel); - luchthaven van bestemming; - route (optioneel); - overige vluchtplangegevens (optioneel). OPMERKING Regels voor invoegen van gegevens, structuren en inhoud van velden worden gespecificeerd in Bijlage A. 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 vlucht op dit moment is gecoördineerd. 7.3.3.1.2. De volgende elementen zullen zijn onderworpen aan herzieningen: - ETO bij het COP; - overdrachtsniveau(s); - SSR-code. 7.3.3.1.3. Een REV-bericht zal worden verzonden als: - de ETO bij het COP meer dan een bilateraal overeengekomen waarde verschilt van die in het vorige bericht, afgerond op de dichtst bijgelegen gehele getalswaarde; - er sprake is van een wijziging in het/de overdrachtsniveau(s) of de SSR-code. 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; - overige vluchtplangegevens (ICAO-veld 8-, 10- en 18-gegevens). OPMERKING Operationele regels kunnen vereisen dat aanpassingen die na ACT plaatsvinden zijn onderworpen aan voorafgaande coördinatie tussen de betreffende eenheden. 7.3.3.1.5. Indien bilateraal overeengekomen zal de berichtreferentie in het REV-bericht worden 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 overdrachtsvoorwaarden die zijn geïmpliceerd in het REV-bericht zal worden 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. ICAO-format Alle herzieningsberichten bevatten de Veldtypen 3, 7, 13, 14 en 16. De volgende typen herzieningen worden in die velden geplaatst: - een wijziging in de ETO bij het COP of het/de overdrachtsniveau(s) zal worden verwerkt door de opname van de herziene gegevens in veld 14; - een wijziging in de SSR-code zal worden opgenomen in veld 7; - routewijzigingen die veranderingen in het COP teweegbrengen zullen worden verwerkt in de velden 14- en 15-gegevens opgenomen in veld 22-structuur na de eerste vijf velden. Dergelijke berichten zullen twee velden 14 bevatten, waarbij het eerste alleen element a) bevat, het COP via welke de vlucht voorheen was gecoördineerd. Regels voor de coördinatie van zulke wijzingen, met inbegrip van directe routebepalingen, worden gespecificeerd in Bijlage B Speciale vereisten voor routeverwerking; - aanpassingen in de velden 8, 10 en 18 zullen worden opgenomen als veld 22-gegevens na de eerste vijf velden. 7.3.3.2.2. ADEXP-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 overdrachtsniveau(s) zal worden verwerkt door de opname van de herziene gegevens in het primaire veld COORDATA; - routewijzigingen, met inbegrip van wijzigingen in het COP, zullen worden opgenomen in de primaire velden COORDATA en ROUTE. Dergelijke berichten zullen het primaire veld COP omvatten dat het coördinatiepunt bevat waar via de vlucht voorheen was gecoördineerd. Regels voor de coördinatie van zulke wijzigingen, met inbegrip van directe routebepalingen, worden gespecificeerd in Bijlage B; - een wijziging in de SSR-code zal worden aangegeven door de opname van het primaire veld SSRCODE; - aanpassingen aan andere vluchtplangegevens zullen worden verwerkt door de opname van het/de vereiste veld(en) zoals gedefinieerd voor Overige vluchtplangegevens in Bijlage A. Als een herzieningsbericht wordt verzonden voor het coördineren van alleen SSR-code en/of Overige vluchtplangegevens, zal het primaire veld COP worden opgenomen in plaats van COORDATA. 7.3.3.2.3. SSR-code SSR-modus en -code zal alleen in een REV-bericht worden opgenomen als het vereist is om een wijziging in SSR-code te 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 het ATC-systeem dat een 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 afwijking in het bericht wordt geconstateerd die een correcte verwerking zou verhinderen: - zal de operationele inhoud worden opgenomen in het vluchtplan; - zullen de vereiste gegevens waar van toepassing ter beschikking 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 overdrachtspunt bevindt mogen door het gebruik van het REV-bericht geen wijzigingen worden doorgevoerd. De tijd- 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. 7.3.3.5. Wijziging van de ontvangende ATC-eenheid Het REV-bericht zal niet worden gebruikt als een herziening van vluchtplangegevens leidt tot een wijziging van de ontvangende ATC-eenheid (zie Bericht voor de opheffing van coördinatie). 7.3.4. Bevestiging van REV-bericht 7.3.4.1. Bevestiging Als het REV-bericht: - kan worden geassocieerd met een vluchtplan binnen het ontvangende systeem zal ter bevestiging een LAM-bericht worden verzonden; - niet kan worden geassocieerd met een vluchtplan binnen het ontvangende systeem zal geen LAM-bericht worden verzonden. 7.3.4.2. Geen bevestiging 7.3.4.2.1. Als geen LAM-bericht ter bevestiging van een REV-bericht wordt ontvangen 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-bericht wordt ontvangen zal door de overdragende ATC-eenheid een verbale herziening worden gestart. 7.3.5. Voorbeelden 7.3.5.1. ICAO a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB) b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB) 7.3.5.2. ADEXP a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317 7.4. MAC-bericht (Message for the Abrogation of Co-ordination) 7.4.1. Doel van het MAC-bericht Een MAC-bericht wordt gebruikt om aan de ontvangende eenheid kenbaar te maken dat de eerder voor een vlucht geleverde coördinatie of mededeling wordt opgeheven. Het MAC-bericht is 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); - 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: - het verwachte niveau op het overdrachtspunt verschilt van het niveau in het vorige bericht hetgeen resulteert in een wijziging 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 het MAC-bericht is verzonden als gevolg van een wijziging in het vluchtniveau of de route, zal, waar van toepassing, mededeling en/of coördinatie plaatsvinden met de nieuwe eenheid in de coördinatievolgorde. 7.4.3.1.3. Een MAC-bericht zal worden verzonden als de coördinatie 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 gespecificeerd 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. Het coördinatiepunt zal het COP zijn via welke eerder de mededeling 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ördinatiepartner is: - de status is INI (initieel); - de reden is een van de volgende: - TFL als de reden een wijziging van het overdrachtsniveau is; - RTE als de reden een routewijziging is; - CSN als de reden een wijziging in het oproepteken is; - CAN als de reden een annulering is; - OTH voor alle andere redenen of als de reden onbekend is; - als een van de volgende voorwaarden van toepassing is: - de coördinatie door het gebruik van het vorige PAC- of ACT-bericht (zoals gewijzigd door volgende REV-berichten) wordt opgeheven maar de vlucht zal naar verwachting het onderwerp zijn van een nieuwe coördinatiereeks bij dezelfde eenheid; of - volgend op de verzending van een ABI-bericht is de vlucht voor een ongedefinieerde periode in de wacht gezet 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 vlucht wordt afgegeven of als deze opnieuw wordt gecoördineerd: - zal, waar van toepassing, een nieuw mededelingsbericht en/of coördinatiebericht worden verzonden; - zal het basisvluchtplan dat is opgeslagen in de ontvangende ATC-eenheid niet worden 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 het MAC-bericht kan worden geassocieerd met een vluchtplan binnen het ontvangende systeem en kan worden verwerkt, zal ter bevestiging een LAM-bericht worden verzonden. 7.4.4.1.2. Als het MAC-bericht niet kan worden geassocieerd met een 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-bericht verzonden door Amsterdam ACC aan Brussel ACC voor vlucht HOZ3188, 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 voorbeelden 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 blijkt uit de voorbeelden (7.4.5.1 b en 7.4.5.2 b) wordt een MAC-bericht naar Maastricht gezonden. 7.4.5.1. ICAO a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL) b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN) 7.4.5.2. ADEXP a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN 7.5. 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 deelnemend gebied. Tenzij de codetoewijzing centraal plaatsvindt, bijvoorbeeld door een ACC, kan het nodig zijn om aan vliegvelden 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 vlucht indien 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. Algemeen 7.5.3.1.1. Een COD-bericht zal automatisch worden gegenereerd en verzonden als antwoord op een verzoek voor het toewijzen van een code dat binnen een bericht wordt ontvangen. 7.5.3.1.2. De SSR-code zal de code zijn die aan de vlucht wordt toegewezen. 7.5.3.1.3. De goedgekeurde verzadigingscode, zoals gespecificeerd in het Air Navigation Plan for the European Region, zal worden ingevoegd als een afzonderlijke code niet beschikbaar is. 7.5.3.1.4. Indien bilateraal overeengekomen zal de berichtreferentie, die het berichtnummer bevat van het bericht waarop het COD-bericht een reactie is, worden opgenomen. 7.5.3.1.5. Indien bilateraal overeengekomen zal de route worden opgenomen. 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 eenheid 7.5.3.2.1. Mits het bericht geen afwijking bevat die een correcte verwerking zou verhinderen zal een LAM-bericht worden teruggezonden. 7.5.3.2.2. Als het bericht niet kan worden geassocieerd met een vluchtplan of als een afwijking wordt geconstateerd die een correcte verwerking van het bericht verhindert zal geen LAM-bericht worden 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-bericht wordt verzonden als gevolg van de ontvangst van een bericht waarin om de toewijzing van een SSR-code wordt verzocht. 7.5.4. Bevestiging van COD-bericht 7.5.4.1. Bevestiging Het COD-bericht zal worden bevestigd door het genereren 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 waarschuwing 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. Het INF-bericht wordt gebruikt om informatie 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. Het INF-bericht kan worden gebruikt om kopieën van berichten 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 gegenereerd door de systemen van de overdragende of accepterende eenheid. 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 gegevens, herzieningen en annuleringen. 7.6.2. Inhoud van bericht Het INF-bericht zal de volgende gegevens bevatten in de structuur van een bericht zoals beschreven in dit document: - berichttype; - berichtnummer; - alle onderdelen van operationele gegevens zoals die zich bevinden in het oorspronkelijke bericht of daaruit volgende 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 gedupliceerd door een INF-bericht zal/zullen gebaseerd zijn op vereisten van gebruikers en de mogelijkheden van de verzendende eenheid. Type(n) bericht(en) en toepassingsregels zullen, in het algemeen, bilateraal worden overeengekomen. 7.6.3.2. Geadresseerden van bericht Voor dezelfde vlucht kunnen een of meer INF-berichten worden verzonden naar een of meer geadresseerden. 7.6.3.3. Operationele inhoud 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 dialoogbericht (bijv. ACT-, RAP-, REV-, RRV-bericht) kunnen worden gewijzigd of afgewezen voordat de dialoog is voltooid. Verzendende 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 instelling. 7.6.4. Bevestiging van INF-bericht Aanbevelingen 1. 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 betreffende eenheden, dient als er geen LAM-bericht als bevestiging voor een INF-bericht wordt ontvangen, op een daartoe geschikte plaats een waarschuwing te worden afgebeeld. 7.6.5. Voorbeelden Een vlucht met oproepteken BAW011, B747 van EGLL naar OMDB op FL290, aanvraag voor FL410, schat Koksy (KOK) VOR om 1905, transponder op A5437, voortgang via UG1 en UB6. Voor de vlucht wordt door Londen een ACT-bericht naar Maastricht gezonden. Vanuit Londen wordt een kopie gezonden naar een eenheid die wordt geïdentificeerd als IT. Hier volgen enkele voorbeelden van het INF-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 gebruikt in de dialoogprocedure in de coördinatiefase 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. 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 wordt ondersteund. 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. Het proces waarbij dit wordt gecontroleerd wordt in dit document "het filter" genoemd. De database die voor het filter wordt gebruikt zal, indien vereist, het volgende bevatten: - overeengekomen coördinatiepunten; - in aanmerking komende (of niet in 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 lijst kunnen 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 overeenstemming met de LoA". Tenzij bilateraal overeengekomen, zullen berichten verzonden door overdragende eenheden voor coördinaties 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 overdrachtsvoorwaarden 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 overdrachtsvoorwaarden 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 gecontroleerd. 8.1.2.3.2. Als de controle aangeeft dat de ontvangen overdrachtsvoorwaarden 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 afwijkingen 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 om 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 plaatsvindt 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 vlucht verzenden of bevestigen 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 verzending door de accepterende eenheid. 8.1.3.1.4. CDN-berichten zullen alleen worden verzonden en bevestigd: - als onderdeel van een dialoog die wordt gestart door de ontvangst van een Activate- (ACT, RAP) of Revision-bericht (REV of RRV); of - als het vluchtplan voor die vlucht zich 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 uitwisseling 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. Het is mogelijk dat een CDN-bericht een REV-, RRV- of MAC-bericht voor dezelfde vlucht kruist dat is verzonden door de overdragende eenheid. Deze situatie kan in de overdragende eenheid worden geconstateerd door het CDN-bericht dat arriveert voorafgaand aan de bevestiging voor het verzonden coördinatiebericht en in de accepterende eenheid door het bericht van de overdragende eenheid dat arriveert voorafgaand aan de bevestiging van het CDN-bericht. In dat geval zal het CDN-bericht niet worden bevestigd en zal het REV-, RRV- of MAC-bericht worden verwerkt. 8.1.5. Behandeling van afwijzing Het RJC-bericht beëindigt een systeemdialoog. Er dient een nieuwe systeemcoördinatie te worden gestart die waar van toepassing 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 overeengekomen. 8.1.6.1.3. De afloop van de time-out bij de verzendende eenheid zal resulteren 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. 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 uitvoerende 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 complementaire berichten zoals bilateraal overeengekomen (Secties 7 en 8); - basis coördinatieprocedure en overdrachtsfase dialoogprocedure (Secties 6, 7 en 9); - coördinatie- en overdrachtsfase dialoogprocedure plus eventuele complementaire coördinatieberichten zoals bilateraal overeengekomen (Secties 7, 8 en 9). Het Advance Boundary Information-bericht zal 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 Het doel van het ACT-bericht staat beschreven in paragraaf 6.3.1. In een dialoogprocedure wordt het ACT-bericht gebruikt om 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 het ACT-bericht dat in de dialoogprocedure wordt gebruikt zal zijn zoals beschreven voor het ACT-bericht in paragraaf 6.3.2. 8.2.3. Regels voor toepassing 8.2.3.1. Algemeen 8.2.3.1.1. De regels voor toepassing zijn zoals beschreven voor het ACT-bericht in paragraaf 6.3 met uitzondering van de speciale regels die worden beschreven in deze paragraaf. 8.2.3.1.2. Er zal een ACT-bericht worden verzonden voor een vlucht met standaard overdrachtsvoorwaarden waarvoor de overdragende vluchtleider niet vereist dat deze wordt verwezen naar de accepterende 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 eenheid 8.2.3.2.1. Het bericht wordt door het filter gecontroleerd om te bevestigen dat de voorgestelde voorwaarden standaard zijn. 8.2.3.2.2. Het bericht zal worden verwerkt als een RAP-bericht als: - 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 verwerkt overeenkomstig 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-standaard 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-bericht worden bevestigd door: - een LAM-bericht als de overdrachtsvoorwaarden standaard blijken te zijn; - een SBY-bericht in alle andere gevallen. 8.2.4.1.2. Als een LAM-bericht is ontvangen zal de operationele inhoud van het ACT-bericht operationeel 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, naast die welke zijn gespecificeerd voor het ACT-bericht in paragraaf 6.3: - het voorstel van de overdragende vluchtleider en verwijzing naar de accepterende vluchtleider van vluchten met niet-standaard overdrachtsvoorwaarden; - het de overdragende vluchtleider mogelijk maken om, indien hij/zij dit wenst, de verwijzing van standaard overdrachtsvoorwaarden voor een specifieke vlucht naar de accepterende vluchtleider te forceren. 8.3.2. Inhoud van bericht De inhoud van het RAP-bericht zal bestaan uit dezelfde gegevens zoals beschreven voor het ACT-bericht (paragraaf 6.3) en kan optioneel het volgende gegevenselement bevatten: - reden, duidt handmatige 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-bericht worden verzonden in plaats van het ACT-bericht: - het overdragende systeem heeft bepaald dat de overdrachtsvoorwaarden niet-standaard zijn; - de overdragende vluchtleider heeft aangegeven dat de voorgestelde overdrachtsvoorwaarden dienen te worden verwezen naar de accepterende vluchtleider. 8.3.3.1.2. De operationele inhoud van het RAP-bericht dat op het punt staat om te worden verzonden zal worden afgebeeld op de werkplek die verantwoordelijk is voor de coördinatie van de vlucht voorafgaand 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 het RAP-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 afwijking in het bericht wordt geconstateerd die een correcte verwerking zou verhinderen: - zal de operationele inhoud worden verwezen naar de accepterende vluchtleider; - zal een SBY-bericht worden teruggezonden. 8.3.3.2.3. Aanbeveling: Er dient een aanwijzing voor de reden van de verwijzing (niet-standaard voorwaarden of handmatige verwijzing) te worden opgenomen. 8.3.3.2.4. Als het bericht niet kan worden geassocieerd met een vluchtplan of als een afwijking wordt geconstateerd die een correcte verwerking van het bericht verhindert, dan: - zal de operationele inhoud van het bericht bij de sector worden afgebeeld; en - zal een SBY-bericht worden teruggezonden; en - zal een vluchtplan worden aangemaakt. 8.3.3.2.5. In alle andere gevallen zal het bericht niet worden bevestigd. 8.3.3.3. Handmatig starten 8.3.3.3.1. Als het gebruikt wordt om de verwijzing van een voorgestelde coördinatie met standaard overdrachtsvoorwaarden naar de accepterende vluchtleider te forceren, wordt het RAP-bericht handmatig gestart door de overdragende vluchtleider en onmiddellijk 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 Het bericht zal worden bevestigd door het genereren en verzenden van een SBY-bericht. 8.3.4.2. Gevallen zonder bevestiging Als geen SBY-bericht wordt ontvangen ter bevestiging van een RAP-bericht zal 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. Acceptatie 8.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 het ACP-bericht is ontvangen worden de gegevens van het RAP-bericht operationeel bindend voor beide ATC-eenheden. De gecoördineerde overdrachtsvoorwaarden en het feit dat het ACP-bericht is ontvangen zullen aan de overdragende vluchtleider worden gepresenteerd. 8.3.5.2. Tegenvoorstel Als de accepterende vluchtleider ervoor kiest om een tegenvoorstel te doen met betrekking tot de overdrachtsvoorwaarden zal een CDN-bericht worden teruggezonden. 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 Het doel van het REV-bericht staat beschreven in paragraaf 7.3.1. In een dialoogprocedure wordt het REV-bericht gebruikt om 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 het REV-bericht zal zijn zoals beschreven voor het REV-bericht in 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 dit moment een vlucht is 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 standaard overdrachtsvoorwaarden waarvan de overdragende vluchtleider niet vereist dat ze worden verwezen naar de accepterende vluchtleider. 8.4.3.2. Verzending starten Het REV-bericht zal onmiddellijk worden verzonden volgend op de ontdekking van een wijziging in de coördinatiegegevens die vereist zijn om te worden gecoördineerd zoals beschreven in paragraaf 7.3.3. 8.4.3.3. Verwerking in de ontvangende eenheid 8.4.3.3.1. Als een bijbehorend vluchtplan is gevonden in de gecoördineerde staat en geen afwijking is geconstateerd die een correcte verwerking van het bericht zou verhinderen, dan: - zal het REV-bericht worden bevestigd; - zal in alle andere gevallen het bericht niet worden bevestigd. 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. 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-standaard 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. Bevestiging 8.4.4.1.1. Als het REV-bericht dient te worden bevestigd zal het worden bevestigd door: - een LAM-bericht als blijkt dat de overdrachtsvoorwaarden standaard zijn; - een SBY-bericht als blijkt dat de overdrachtsvoorwaarden niet-standaard zijn. 8.4.4.1.2. Als een LAM-bericht is ontvangen wordt de operationele inhoud van het REV-bericht operationeel 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 overdrachtsvoorwaarden 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 bericht worden verwerkt als een RRV-bericht. 8.5. RRV-bericht (Referred Revision Proposal) 8.5.1. Doel van het RRV-bericht In de volgende gevallen dient het RRV-bericht voor herziening van eerder verzonden en overeengekomen overdrachtsvoorwaarden: - als de voorgestelde overdrachtsvoorwaarden in de herziening niet-standaard zijn; - als de voorgestelde herziening standaard is, maar de overdragende vluchtleider de herziening naar de accepterende vluchtleider wil verwijzen. 8.5.2. Inhoud van bericht De inhoud van het RRV-bericht zal zijn zoals beschreven voor het REV-bericht (paragraaf 7.3.2) en kan optioneel het volgende gegevenselement bevatten: - reden, duidt handmatige 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 overdrachtsvoorwaarden niet-standaard zijn; of - de overdragende vluchtleider heeft aangegeven dat de voorgestelde overdrachtsvoorwaarden dienen te worden verwezen naar de accepterende vluchtleider. Dit gebruik van het RRV-bericht is optioneel. 8.5.3.2. Verzending starten Het RRV-bericht zal onmiddellijk worden verzonden volgend op de ontdekking van een wijziging in de coördinatiegegevens of bij een 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ördineerde staat en geen afwijking wordt geconstateerd die een correcte verwerking van het bericht zou verhinderen, dan: - zal het RRV-bericht worden bevestigd; - zal in alle andere gevallen het bericht niet worden bevestigd. 8.5.3.3.2. De voorgestelde overdrachtsvoorwaarden zullen worden afgebeeld 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 verwijzing (niet-standaard voorwaarden of handmatige verwijzing) te worden meegezonden. 8.5.4. Bevestiging van RRV-bericht 8.5.4.1. Bevestiging Het bericht zal worden bevestigd door het generen en verzenden van een SBY-bericht. 8.5.4.2. Gevallen zonder bevestiging Als geen SBY-bericht wordt ontvangen ter bevestiging van een RRV-bericht zal 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. Tegenvoorstel Als de accepterende vluchtleider ervoor kiest om met een tegenvoorstel te komen voor de overdrachtsvoorwaarden, zal een CDN-bericht worden teruggezonden. 8.5.5.3. Afwijzing Als de accepterende vluchtleider ervoor kiest om het voorgestelde amendement op de overeengekomen overdrachtsvoorwaarden af te wijzen: - zal een RJC-bericht worden teruggezonden; en - zal een nieuw coördinatieproces worden gestart. Als noch een ACP-, noch een CDN-bericht wordt ontvangen als reactie op het RRV-bericht zal een afwijzing worden verondersteld. 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 EGBB 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 gegenereerd en verzonden, in antwoord op: - een RAP-, RRV- of CDN-bericht; - een ACT- of REV-bericht dat niet aan het filter voldoet. 8.6.4. Bevestiging van SBY-bericht Het SBY-bericht zal niet worden bevestigd. 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-bericht aangeven (in plaats van het ROF-bericht). 8.7.2. Inhoud van bericht Het ACP-bericht bestaat uit de volgende gegevens: - Verplichte gegevens - het bericht zal bevatten: - berichttype; - berichtnummer; - berichtreferentie; - Optionele gegevens - het bericht kan ook bevatten: - frequentie; - 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. Het ACP-bericht zal worden verzonden volgend op de handmatige 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 automatisch door het systeem worden gegenereerd en verzonden als antwoord op een ACT/REV-bericht dat door het filter is goedgekeurd. 8.7.3.1.6. Als een ACP-bericht is ontvangen 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 het ACP-bericht kan worden geassocieerd met een vluchtplan zal de acceptatie aan de vluchtleider worden medegedeeld. 8.7.3.2.3. Als het ACP-bericht niet kan worden geassocieerd met een vluchtplan: - zal een waarschuwing worden gegeven op de daartoe aangewezen positie; en - zal geen LAM-bericht worden verzonden. 8.7.4. Bevestiging van ACP-bericht 8.7.4.1. Bevestiging 8.7.4.1.1. Er zal geen LAM-bericht worden teruggezonden als het ACP-bericht is gebruikt als een automatisch antwoord op een ACT- of REV-bericht dat door het filter is goedgekeurd. 8.7.4.1.2. Een ACP-bericht dat is verzonden als een gevolg van een handmatige 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-bericht dat is verzonden als gevolg van een handmatige acceptatie, 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 242150 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 overdrachtsvoorwaarden van de accepterende vluchtleider naar de overdragende vluchtleider starten. 8.8.2. Inhoud van bericht Het CDN-bericht bestaat uit de 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 overdrachtvluchtniveau (bij een ADEXP-bericht); - directe routeaanvraag. - Bilateraal overeengekomen gegevens - de volgende gegevens 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. Algemeen 8.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 overdrachtsvoorwaarden 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 gebruikt indien bilateraal 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 het geval dat een CDN-bericht effectief gelijktijdig wordt verzonden met een bericht voor dezelfde vlucht van de overdragende eenheid, bijvoorbeeld een herziening of een opheffing van coördinatie, zal noch een bevestiging, noch een operationeel antwoord worden teruggezonden.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 situatie 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-berichtgegevens operationeel bindend voor beide ATC-eenheden. De gecoördineerde overdrachtsvoorwaarden en het feit dat het ACP-bericht is ontvangen zullen worden gepresenteerd aan de betreffende ATC-medewerkers. 8.8.3.2. Verwerking in de ontvangende eenheid 8.8.3.2.1. Als een bijbehorend vluchtplan wordt gevonden en geen afwijking 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-bericht worden teruggezonden. 8.8.3.2.2. Als het CDN-bericht niet kan worden geassocieerd, of als een afwijking wordt geconstateerd die een correcte verwerking van het bericht verhindert, zal geen SBY-bericht worden teruggezonden. 8.8.4. Bevestiging van CDN-bericht 8.8.4.1. Bevestiging Onder de hierboven gespecificeerde voorwaarden zal het CDN-bericht worden bevestigd door het genereren en verzenden van een SBY-bericht. 8.8.4.2. Gevallen zonder bevestiging Als geen SBY-bericht wordt ontvangen ter bevestiging van een CDN-bericht zal 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 afgewezen 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 F110A 8.9. RJC-bericht (Reject Co-ordination) 8.9.1. Doel van het RJC-bericht Het RJC-bericht geeft de afwijzing aan door een vluchtleider 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. Het RJC-bericht kan alleen worden gebruikt als 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. Het RJC-bericht zal waar vereist worden verzonden als antwoord op een RAP-, RRV-, CDN-bericht of op een ACT- of REV-bericht dat door de accepterende eenheid niet-standaard is bevonden. 8.9.3.1.2. Het RJC-bericht beëindigt de systeemdialoog en alle eerder overeengekomen 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 bericht wordt aangetroffen waarnaar het RJC-bericht verwijst; - 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 verwerking verhindert, dan zal er geen bevestiging worden teruggestuurd. 8.9.4. Bevestiging van RJC-bericht 8.9.4.1. Bevestiging Het RJC-bericht zal worden bevestigd door het genereren 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 324 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 het aspect van de radaroverdracht van de controleprocedureoverdracht 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 plaatsvinden 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 zendt een 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 overeengekomen 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 Het doel van het TIM-bericht is 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 Het TIM-bericht zal bestaan uit de volgende gegevens: - Verplichte gegevens - het bericht zal bevatten: - berichttype; - berichtnummer; - vliegtuigidentificatie; - Beschikbare gegevens - het bericht zal ook, indien beschikbaar, een of meer van de volgende onderdelen bevatten: - 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.2.3. Regels voor toepassing 9.2.3.1. Algemeen 9.2.3.1.1. Het TIM-bericht zal worden gegenereerd en verzonden door de overdragende eenheid aan de accepterende eenheid zonder menselijke tussenkomst op een bilateraal overeengekomen tijdstip/afstand van de vlucht tot de grens. 9.2.3.1.2. Een TIM-bericht zal ook automatisch worden verzonden als het ROF-bericht (Request On Frequency) door de overdragende eenheid is ontvangen. 9.2.3.1.3. Er zal geen TIM-bericht worden verzonden voordat de vlucht is 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 verzending 9.2.3.2.1. De parameter voor het genereren van TIM-berichten zal een Variabele 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 gerelateerd 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 eenheid 9.2.3.3.1. De gegevens die in een TIM-bericht worden ontvangen zullen beschikbaar worden gesteld aan de accepterende vluchtleider. 9.2.4. Bevestiging van TIM-bericht 9.2.4.1. Bevestiging Als het TIM-bericht: - ondubbelzinnig met een vluchtplan kan worden geassocieerd zal het worden bevestigd door het genereren en verzenden van een LAM-bericht; - niet ondubbelzinnig met een vluchtplan kan worden geassocieerd 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 waarschuwing worden afgebeeld. 9.2.5. Voorbeeld -TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253 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. Het primaire doel van het SDM-bericht is om controlegegevens 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. Het SDM-bericht kan ook worden gebruikt door de accepterende eenheid om de overdragende eenheid in kennis te stellen van de radiotelefoniefrequentie waaraan de vlucht zal worden overgedragen. 9.3.2. Inhoud van bericht 9.3.2.1. Berichten van de overdragende eenheid Het SDM-bericht zal bestaan uit de volgende gegevens: - Verplichte gegevens - het bericht zal bevatten: - berichttype; - berichtnummer; - vliegtuigidentificatie; - Aanvullende gegevens - het bericht zal 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 wijziging 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 punt te gaan. OPMERKING Het HOP-bericht is vereist als goedkeuring door de accepterende vluchtleider is vereist voorafgaand 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 overeengekomen tijdstip relatief ten opzichte van TI, mits er gegevens zijn waarvoor een waarde in het systeem 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.OPMERKING Eenheden kunnen bilateraal overeenkomen om andere informatie te zenden. Een dergelijke overdracht 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ördinatiefase. 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-bericht worden teruggezonden; en - zal de operationele inhoud van het SDM-bericht beschikbaar worden gemaakt voor 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 het bericht verhindert: - zal geen LAM-bericht worden teruggezonden; en - zal een waarschuwing worden gegeven op een daartoe aangewezen positie. 9.3.4. Bevestiging van SDM-bericht 9.3.4.1. Bevestiging Het SDM-bericht zal worden bevestigd door het genereren 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 waarschuwing 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 Het doel van het HOP-bericht is: - 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 overdracht voor te dragen aan de accepterende vluchtleider op het moment dat dit nodig 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; het gebruik wordt bepaald 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 Het HOP-bericht zal bestaan uit de volgende gegevens: - Verplichte gegevens - het bericht zal bevatten: - berichttype; - berichtnummer; - vliegtuigidentificatie; - Beschikbare gegevens - het bericht zal 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. Algemeen 9.4.3.1.1. Het HOP-bericht zal, indien gebruikt, handmatig worden gestart door de overdragende vluchtleider. 9.4.3.1.2. Het bericht zal 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-bericht wordt verzonden 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-bericht kan worden gezonden zal bilateraal 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 eenheid 9.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 voorwaarden zoals voorgesteld in het HOP-bericht, kan als antwoord een ROF-bericht naar de overdragende eenheid worden verzonden. Indien bilateraal overeengekomen kan als antwoord op een HOP-bericht een ACP-bericht worden 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 overdrachtsprocedure 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 accepterende vluchtleider en de benodigde actie zal ondernemen. Deze norm verbiedt echter niet dat een waarschuwing wordt verzonden naar de overdragende 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 het HOP-bericht operationeel bindend worden voor beide ATC-eenheden. 9.4.4. Bevestiging van HOP-bericht 9.4.4.1. Bevestiging Als het HOP-bericht kan worden geassocieerd met een vluchtplan zal het HOP-bericht automatisch worden bevestigd door een LAM-bericht. 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 waarschuwing 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 overdracht van de vlucht te vragen. 9.5.2. Inhoud van bericht Het ROF-bericht zal bestaan uit de 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. Algemeen 9.5.3.1.1. Het ROF-bericht zal handmatig worden gestart door de accepterende 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 medegedeeld aan de overdragende vluchtleider. 9.5.3.2.3. Als de vlucht zich niet in de overdrachtsfase bevindt zal de overdrachtsfase worden gestart en zal een TIM-bericht worden verzonden. 9.5.4. Bevestiging van ROF-bericht 9.5.4.1. Bevestiging 9.5.4.1.1. Als het ROF-bericht ondubbelzinnig 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 het ROF-bericht niet ondubbelzinnig kan worden geassocieerd 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-bericht zal een waarschuwing worden afgebeeld op de daartoe aangewezen ATC-positie. 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. Het COF-bericht wordt door 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 overdrachtsvoorwaarden nadat de vlucht radiocontact heeft gemaakt met de accepterende vluchtleider. 9.6.2. Inhoud van bericht Het COF-bericht zal bestaan uit de volgende gegevens: - Verplichte gegevens - het bericht zal bevatten: - berichttype; - berichtnummer; - vliegtuigidentificatie; - Beschikbare gegevens - het bericht zal ook, indien beschikbaar, 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. Algemeen 9.6.3.1.1. Het COF-bericht zal handmatig worden gestart door de overdragende vluchtleider. 9.6.3.1.2. Het gebruik van het COF-bericht is verplicht als, volgens bilaterale overeenkomst, het MAS-bericht niet wordt gebruikt. 9.6.3.1.3. Als een COF-bericht wordt verzonden 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 eenheid 9.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 accepterende vluchtleider worden medegedeeld. 9.6.4. Bevestiging van COF-bericht 9.6.4.1. Bevestiging 9.6.4.1.1. Als het COF-bericht ondubbelzinnig 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 het COF-bericht niet ondubbelzinnig kan worden geassocieerd met een vluchtplan zal geen bevestiging worden verzonden. 9.6.4.2. Gevallen zonder bevestiging Als geen LAM-bericht wordt ontvangen ter bevestiging van een COF-bericht zal 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 Het MAS-bericht wordt door de accepterende 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 accepterende vluchtleider. 9.7.3.1.2. Het gebruik van het MAS-bericht is verplicht als, door bilaterale 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. Het feit dat het MAS-bericht is ontvangen zal onmiddellijk ter kennis worden gebracht van de vluchtleider. 9.7.4. Bevestiging van MAS-bericht 9.7.4.1. Bevestiging 9.7.4.1.1. Als het MAS-bericht ondubbelzinnig 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 het MAS-bericht niet ondubbelzinnig kan worden geassocieerd 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-bericht zal, zoals vereist, een waarschuwing worden afgebeeld op de daartoe aangewezen ATC-positie. 9.7.5. Voorbeeld -TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 BIJLAGE A (Normatief) REGELS VOOR HET INVOEGEN VAN GEGEVENS INHOUD >RUIMTE VOOR DE TABEL> A.1. Doel Deze bijlage bevat een beschrijving van de algemene regels voor het invoegen van gegevens in de berichten 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. 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.3. Alle in dit document beschreven berichten kunnen worden verzonden met gebruik van het Eurocontrol ADEXP-structuur. Inhoud, structuur en gebruik van ADEXP-gegevensvelden zal plaatsvinden overeenkomstig Referentie 2.OPMERKINGEN 1. 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, Dialoogprocedure - 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-codetoewijzing]. COF: Change of Frequency [wijziging van frequentie]. HOP: Hand-Over Proposal [overdrachtsvoorstel]. INF: Information [informatie]. LAM: Logical Acknowledgement Message [logisch bevestigingsbericht]. 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 waarnaar wordt verwezen]. REV: Revision [herziening]. RJC: Reject Co-ordination [afwijzing van coördinatie]. ROF: Request on Frequency [vraag over frequentie]. RRV: Referred Revision Proposal [ voorstel tot herziening waarnaar wordt verwezen]. SBY: Stand-by. SDM: Supplementary Data Message [aanvullend gegevensbericht]. TIM: Transfer Initiation Message [bericht van start van overdracht]. A.3.1. ICAO Veldtype 3, element (a). 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 document 4444). De inhoud van element (c) zal zijn die van Veldtype 3, element (b), van het OLDI-bericht waarnaar wordt verwezen. A.5.2. ADEXP Primair field "msgref". De waarden van de Subvelden "sender", "recvr", en "seqnum", binnen het Primaire veld "msgref", zullen zijn die van dezelfde Subvelden binnen het Primaire veld "refdata" van het OLDI-bericht waarnaar wordt verwezen. 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 ontvangende 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 het aanvragen van een SSR-code/modus, zullen de elementen b) en c) de waarde "A9999" bevatten. A.7.2. ADEXP Primair veld "ssrcode". Als geen geldige SSR-code is toegewezen of als de modus/code niet bekend is, zal het veld worden weggelaten. Bij het aanvragen van een SSR-code/modus via het PAC-bericht zal 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 het COP en het overdrachtsniveau. A.9.1.2. Het coördinatiepunt zal worden gedefinieerd als ofwel een bekend referentiepunt, een afstand en koers vanaf een bekend referentiepunt of een breedte- en lengtegraad. A.9.1.3. Het vrijgegeven (overdracht)niveau zal overeenkomen met de voorgestelde 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 gebruikt zullen de supplementaire 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. Het coördinatiepunt waarnaar wordt verwezen door de overdragende en ontvangende ATC-eenheden ten behoeve van de betreffende overdracht. A.10.1.2. Het coördinatiepunt zal 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). A.10.3. ADEXP Primair veld "cop" dat bevat: - 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 opgenomen. 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 gedefinieerd 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 ingevoegd na onderdeel c). Zie ook Bijlage B 'Speciale vereisten voor routeverwerking' voor de regels voor het invoegen van routegegevens. 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); - het COP; - 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 routesegment; - het element 'DCT'; - het punt waarnaar de vlucht zich beweegt op het directe routesegment. A.13.2. Structuur A.13.2.1. ICAO Veldtype 15, in veldtype 22-structuur. A.13.2.2. ADEXP Primair veld "route". A.14. Overige vluchtplangegevens A.14.1. ICAO Veldtypen 8, 10 en 18, in het veldtype 22-structuur. A.14.2. ADEXP Primaire velden: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "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 specificeert als een van de volgende: - TFL, als de reden een wijziging van het overdrachtsniveau 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". 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-bericht wordt gebruikt om aan te geven dat een 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-bericht wordt gebruikt om aan te geven dat een 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 het cijfergedeelte van het veld, bijv. als een SDM-bericht wordt gebruikt om aan te geven dat een eerder toegewezen klim-/daalsnelheid niet langer van toepassing 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 referentiepunt. Alle gebruikte eindpuntaanduidingen zullen bilateraal worden overeengekomen, d.w.z. bekend zijn bij beide systemen. Primair veld "DCT" zal bevatten: - het punt waarop 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 niet vereist dat het afwijkingspunt wordt aangewezen. - 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 overeengekomen, d.w.z. bekend bij beide systemen. A.20.1. ICAO Veldtype 15, exclusief de initiële snelheids-/niveaugroep, in veld 22-structuur. Dit type zal bevatten: - het punt waarop de afwijking aangevraagd is om te 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, gedefinieerd als: - een bekend referentiepunt; of - een afstand en koers vanaf een bekend referentiepunt. A.20.2. ADEXP Primair veld "DCT" dat bevat: - het punt waarop de afwijking is aangevraagd om te 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 aangewezen 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 bilateraal worden overeengekomen, d.w.z. bekend zijn bij beide systemen. Primair veld "position" zal het subveld "ptid" bevatten dat verwijst naar het gedefinieerde referentiepunt of 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 vlucht wordt vrijgegeven om te klimmen; - D, als de vlucht wordt vrijgegeven om te dalen; - T, als de vlucht wordt vrijgegeven voor bochten; - F, als de vlucht volledig wordt vrijgegeven voor alle acties. 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", dat de waarde "MANUAL" bevat voor handmatig 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". BIJLAGE B (Normatief) SPECIALE VEREISTEN VOOR ROUTEVERWERKING B.1. Inleiding B.1.1. Algemeen B.1.1.1. Deze bijlage bevat een beschrijving van de regels en vereisten voor het invoegen van gegevens in de volgende gevallen, waar toegestaan: - een vlucht volgt een directe koers, buiten de route, over de grens als het gevolg van een direct routesegment dat is opgenomen in het vluchtplan; - na verzending van het ABI- of ACT-bericht wordt een 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 het gebruik van OLDI voor de coördinatie van vluchten op directe routes zullen bilateraal worden overeengekomen. B.2.1.2. De gegevens die vereist zijn voor de mededeling en coördinatie 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-bericht worden verzonden met gegevens die overeenkomen met de nieuwe route. B.2.4. Omleiding na ACT-verzending B.2.4.1. Een REV-bericht zal worden gebruikt om aan te geven dat omleidingen 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 accepterende 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. 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 wordt gecoördineerd; 13 Luchthaven van vertrek; 14 Alleen element a, dat het vorige COP bevat voor referentiedoeleinden; 16 Bestemming; 22 Veld 14 dat de geschatte gegevens voor de nieuwe grensoverschrijdingvoorwaarden 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 berichttype en -nummer, de vliegtuigidentificatie, de luchthaven van vertrek, de bestemming en, indien bilateraal overeengekomen, het berichtreferentienummer: - het vorige COP in het COP-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 dialoogprocedure 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 grensoverschrijdingpunt zijn uitgedrukt als een koers en afstand vanaf een rapportagepunt. Zulke punten zullen bilateraal worden overeengekomen. 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: - het punt op de oorspronkelijke route van waaraf het vliegtuig 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 het verzendende systeem. 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). >PIC FILE= "L_2000254NL.008401.EPS"> Het volgende ABI-bericht wordt verzonden: - 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 Vlucht HZT2051 was eerder het onderwerp van het volgende ACT-bericht (of ADEXP-equivalent): (ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M >PIC FILE= "L_2000254NL.008501.EPS"> 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. Het volgende herzieningsbericht wordt verzonden: (REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY) >PIC FILE= "L_2000254NL.008502.EPS"> Het ADEXP-equivalent van het bericht is: -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 herzieningsbericht zou TDS240026 worden aangeduid als het COP. 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. Het volgende ACT-bericht wordt verzonden: (ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M) >PIC FILE= "L_2000254NL.008601.EPS"> De vlucht wordt vervolgens omgeleid via ATS route 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 herzieningsbericht wordt verzonden: (REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124) >PIC FILE= "L_2000254NL.008602.EPS"> De vlucht wordt dan vrijgegeven voor FL290 hetgeen resulteert in het volgende bericht (dat het nieuwe COP bevat): (REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA) >PIC FILE= "L_2000254NL.008701.EPS"> 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 DTTA BIJLAGE C (Ter informatie) DIALOOGPROCEDURE (SYSCO NIVEAU 1) FASEN - BERICHTENVOLGORDE Berichtenvolgorde >PIC FILE= "L_2000254NL.008802.EPS"> BIJLAGE II AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION (ADEXP), EDITIE 2.0 (Eurocontrol-referentiedocument DPS.ET1.ST09-STD) INHOUDSOPGAVE >RUIMTE VOOR DE TABEL> AUTEURSRECHT Dit document is geproduceerd door Eurocontrol Agency. Het auteursrecht berust bij Eurocontrol Agency. De inhoud, of enig deel daarvan, is dus vrijelijk beschikbaar voor vertegenwoordigers van de lidstaten, maar voor kopiëren of openbaarmaking aan derden is voorafgaand schriftelijke toestemming vereist van Eurocontrol Agency. 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 het EATCHIP Work Programme Document (EWPD), Data Processing Systems Domain (DPS), Executive Task 09. 3. Goedkeuring van de norm 3.1. Deze norm wordt aanvaard in overeenstemming met de procedures zoals beschreven in de Directives for Eurocontrol Standardisation, Ref. 000-2-93, Edition 1.0. 3.2. De bepalingen van deze norm werden van kracht na 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 wordt bijgehouden om er zeker van te zijn dat vereiste amendementen of technische correcties worden opgenomen. De procedure voor het onderhoud van deze norm staat 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 basisprincipes of grammatica van de ADEXP-structuur zullen alleen plaatsvinden na de formele beoordelingsprocedure zoals vastgelegd 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 formulering aan te geven: - Voor normatieve elementen worden de (hulp)werkwoorden "zullen" of "dienen" gebruikt, afgedrukt in lichte Romeinse letters; - Voor Aanbevolen 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 >RUIMTE VOOR DE TABEL> 8. Taal Het origineel van deze norm is gesteld in de Engelse taal. 1. REIKWIJDTE 1.1. ADEXP is een structuur, geen protocol. Er gelden geen beperkingen 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 syntaxisregels 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 voor informatie 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 luchtverkeersstromen] (ATFM): uitwisseling van berichten tussen het Tactical System (TACT) van de CFMU, AO en ATS. (Documentref. 5) - Coördinatie van luchtverkeersleiding: uitwisseling van tactische 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 beschikbaarheid 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, doordat er in deze tekst naar wordt verwezen, bepalingen vormen van dit Eurocontrol-normdocument. Ten tijde van publicatie van dit Eurocontrol-normdocument waren de genoemde uitgaven van de documenten en normen waarnaar wordt verwezen 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 dit Eurocontrol-normdocument zijn opgenomen. In het geval van conflicten tussen de vereisten van dit Eurocontrol-normdocument en de inhoud van deze andere documenten waarnaar wordt verwezen, zal dit Eurocontrol-normdocument prevaleren. 2.2. Ten tijde van publicatie zijn de hieronder vermelde documenten die waarnaar in deze norm wordt verwezen. Gebruikers kunnen echter desgewenst de tabellen voor het gebruik en de samenstelling van berichtenvelden controleren in de laatste nieuwe uitgaven van deze documenten. 1. ICAO Chicago Convention Annex 10 Volume I, uitgave gedateerd 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 maart 1998; 4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, uitgave gedateerd november 1985 (inclusief Amendment nr. 6 gedateerd november 1995); 5. Guide To ATFM Message Exchange Eurocontrol Documentref. TACT/USD/MSGGUID, uitgave 6.0, geldend vanaf maart 1998, 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 definieert een reeks regels die een klasse tekenreeksen bepaalt. In dit geval is de klasse tekenreeksen de reeks berichten die een syntactisch geldig ADEXP-bericht kan worden genoemd. 3.2. Definities Ten behoeve van dit Eurocontrol-normdocument gelden 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 dat wordt weergegeven in termen van een reeks tekens. Niet-terminalsymbool: Een symbool dat wordt weergegeven door een of meer terminalsymbolen. OPMERKING Een niet-terminalsymbool kan ook worden weergegeven 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 ::= expressie OPMERKINGEN 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-terminalsymbolen. 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 dit Eurocontrol-normdocument gelden de volgende conventies: - Terminalsymbolen staan in hoofdletters.OPMERKING Volgens conventie betekent het NIL-terminalsymbool "geen terminalsymbool". Het wordt gebruikt in keuzen, zoals in onderstaand voorbeeld: a ::= b ( c | NIL ) waar a kan worden vervangen door (b gevolgd door c) of door alleen b. - Niet-terminalsymbolen (bijv. de linkerkant van een grammaticaproductie) staan in kleine letters. - Tekens en letterreeksen die binnen regels voorkomen worden respectievelijk omsloten door enkele (') of dubbele aanhalingstekens ("). Voorbeelden 1) HYPHEN ::= '-' 2) title ::= '-' "TITLE" titleid Voor sommige toepassingen voor gegevensmodellering kan het nodig zijn om verschil te maken tussen terminal- en niet-terminalsymbolen met andere middelen dan door het gebruik 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 hulpterm, "_pf" voor een primair veld en "_sf" voor een subveld. 3.5. Operators Ten behoeve van dit Eurocontrol-normdocument gelden de volgende operatoren: Facultatief: Als sommige symbolen legitiem al dan niet op een bepaald punt binnen de grammatica kunnen voorkomen. De facultatieve symbolen staan tussen vierkante haakjes "[" en "]". Sluiting: Als een groep symbolen nul of meer keren mag voorkomen. 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 voorkomen. Als na de "}" een getal wordt gespecificeerd geeft dit het maximum aantal keren aan dat de groep symbolen mag voorkomen. Keuze: Als een aantal alternatieve symbolen op een bepaald punt binnen de grammatica mag voorkomen. Keuze wordt weergegeven 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 het lexicale niveau kunnen de regels aaneenschakeling van terminals omvatten, waarbij wordt aangegeven dat ze strikt op elkaar volgen (geen scheidingsteken in het midden), in dat geval zal het symbool '!' 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 impliciet of expliciet zijn.Voorbeelden 1) Impliciet: dct ::= '-' "DCT" point point 2) Expliciet dct ::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point >RUIMTE VOOR DE TABEL> OPMERKINGEN 1) Aaneenschakeling zal altijd prioriteit hebben boven Keuze. Haakjes "(" en ")" worden gebruikt om de evaluatievolgorde van de expressie te veranderen.Voorbeeld >RUIMTE VOOR DE TABEL> 2) In alle regels zal de toegestane aanwezigheid van scheidingstekens tussen de symbolen impliciet worden gelaten, teneinde de leesbaarheid te behouden. 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 evaluatievolgorde te verduidelijken. 3.6. Afkortingen >RUIMTE VOOR DE TABEL> 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. 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 onderdeel 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 het resterende deel van het bericht nog steeds worden geïnterpreteerd (zie sectie 0). 4.2.4. Een ander gevolg is dat de 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 toegestane 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 aanwezigheid 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 definitieniveau 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 beurt basisvelden of samengestelde velden kunnen zijn. 4.2.10. Er zijn twee soorten samengestelde velden, namelijk gestructureerde velden en lijstvelden. 4.2.11. Gestructureerde velden hebben een vooraf gedefinieerde inhoud die exclusief bestaat uit subvelden. De volgorde van subvelden in 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 herhaaldelijk 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 gebruikt om primaire en/of subvelden aan te duiden, behalve indien expliciet anders 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 bericht een onbekend bericht verschijnt, zal dit worden genegeerd. 4.3.2. Met andere woorden, als het systeem dat het bericht analyseert 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 niet een afwijzing veroorzaken van het bericht dat wordt 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 het onbekende veld een lijstveld is (dit is afgeleid uit het trefwoord -BEGIN), dan wordt de gehele inhoud (tot aan 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 is vereist dat een trefwoord voorafgaat aan een primair veld of een subveld. 4.3.6. Hierdoor kunnen twee soorten trefwoorden worden gedefinieerd: - Primaire trefwoorden; - Subtrefwoorden. 4.3.7. Nadat is gedefinieerd dat een trefwoord van de ene soort is zal het niet verder opnieuw worden gebruikt in 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 dubbelzinnigheid 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 0150000W waarbij -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 RTEPTS waarbij "-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 gelegenheid waarbij een primair veld kan worden gebruikt als een subveld (zie Voorbeeld 3 hierboven). 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 uitwisseling van berichten in ADEXP-structuur zal het International Alphabet Number 5 (IA-5) zijn zoals gedefinieerd in Referentie 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 Alphabet Number 2 (ITA-2) en IA-5, zoals gedefinieerd in Referentie 1.OPMERKING Naast grafische tekens en structuureffectors zoals hieronder gedefinieerd, definieert de tekenverzameling ITA-2 "signalen" (zoals geperforeerde band). Deze maken geen deel uit van de toegestane 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 grafische tekens en de structuureffectors die hieronder worden gedefinieerd: 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 structuureffector. 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 het hele bericht geldig op één regel staan. 5.1.4. Waarden met voortekens 5.1.4.1. Het kan nodig zijn aan te geven dat een numerieke waarde negatief is. 5.1.4.2. Velden waarvoor vereist is dat ze een negatieve waarde aanduiden zullen, binnen hun syntaxisdefinitie, de waarde expliciet aanduiden als een "waarde met voorteken" d.w.z. als positief of negatief. Een veld dat niet als zodanig is gedefinieerd mag geen negatieve waarde weergeven. 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" dat een negatieve 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" dient aanwezig te zijn 5.1.5. Trefwoorden 5.1.5.1. Een trefwoord is elke reeks van hoofdletters of cijfers. Dit vormt alleen het begin 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 trefwoord 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 trefwoord en het daaraan voorafgaande begin-van-veld teken door elk willekeurig aantal scheidingstekens kan worden gescheiden, inclusief door geen tekens. Voorbeelden (de volgende reeksen vormen alle op geldige wijze het begin van een veld) 1) -TITLE IFPL 2) - TITLE IFPL 3) - TITLE IFPL 4) - 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 aanbevolen keuze. 2) Het is ook belangrijk om op te merken dat een trefwoord onmiddellijk moet worden gevolgd door ten minste één scheidingsteken. 5.1.5.4. Binnen het gehele document wordt de aaneenschakeling van onderdelen die worden gescheiden door ten minste één scheidingsteken impliciet aangegeven door de notatie "Losse aaneenschakeling" (zie 0).OPMERKING Zoals later zal worden uitgelegd vormen trefwoorden eveneens het begin van lijstvelden als ze worden voorafgegaan door het trefwoord BEGIN. 5.1.5.5. Trefwoorden zullen zo kort mogelijk zijn zonder dat hun semantische betekenis wordt aangetast. 5.1.5.6. >RUIMTE VOOR DE TABEL> 5.1.5.7. Teneinde dubbelzinnigheid (dubbel gebruik van hetzelfde trefwoord 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_field basic_field ::= '-' keyword contained_values contained_values ::= {CHARACTER} list_field ::= '-' "BEGIN" keyword {subfields} '-' "END" keyword structured_field ::= '-' keyword field_1 field_2 ....field_n OPMERKING Zoals zal blijken wordt in het geval van lijstvelden het trefwoord niet onmiddellijk 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 dat wordt voorafgegaan door het trefwoord 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 het bericht bevat (gedefinieerd 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 levert en mag niet het begin zijn van een subveld.Voorbeeldregel arctyp ::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ") OPMERKING: 1) Een expliciet equivalente 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, 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 het lijstveld kunnen voorkomen. 5.2.4.3. De lijst met subvelden die een gegeven lijstveld bevat zal een geordende set vormen (de volgorde van de subvelden is belangrijk).Voorbeeldregel addr::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"OPMERKINGEN 1) 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, wat de mogelijkheid biedt voor gemakkelijke toekomstige uitbreidingen (door het toevoegen van nieuwe subvelden).Voorbeeldregel pt::= '-' "PT" ptid [fl] [eto] OPMERKINGEN 1) Dit definieert het veld "pt" als een gestructureerd veld dat een punt (subveld "ptid") bevat, eventueel gevolgd door een berekend vluchtniveau (subveld "fl"), eventueel gevolgd door een geschatte tijd boven het punt (subveld "eto"). 2) Een voorbeeld van dat veld 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 gestructureerd veld van te maken. Dit maakt een progressieve uitbreiding van de subvelden van het veld mogelijk. Anderzijds kan een basisveld 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. Het commentaarveld vormt het begin van een gebied met vrije 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 }10 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 wordt gedefinieerd hoe de ADEXP-structuur van verschillende categorieën berichten zal worden beschreven op een genormaliseerde wijze, binnen het kader 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 veldsamenstelling en de regels voor het invoegen van gegevens voor elke berichttitel. 6.1.4. Verwezen dient te worden naar de definitiedocumentatie (Interfacespecificatie) 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 lijst met verplichte primaire velden; - een lijst met facultatieve primaire velden; - de regels voor het invoegen 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 facultatief; - de regels met betrekking tot herstel volgend op de constatering 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 met ADEXP zijn die welke in Bijlage A van dit document staan vermeld. 6.1.7. Een veld zal niet worden gebruikt voor een ander doel dan hetgeen is gespecificeerd in de semantische beschrijving van dat veld. 6.1.8. Bijlage D bevat een centrale index van gereserveerde velden. "Gereserveerde velden" zijn niet overeengekomen voor gebruik binnen de op dit moment gedefinieerde ADEXP-berichten. 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 veldtitels 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 introduceren. 6.2.2. Hulptermen vormen geen begin van een veld of subveld en zijn daarom niet geassocieerd met een bepaald trefwoord. 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. 6.2.4. >RUIMTE VOOR DE TABEL> 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. >RUIMTE VOOR DE TABEL> 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 uitdrukking gebracht in Bijlage A (A4) van deze norm. 6.4.2. Daarnaast worden, om reden van kruisverwijzing, de primaire velden waarbinnen een gegeven subveld verschijnt aangegeven. 6.4.3. Een subveld kan ook een subveld van andere subvelden zijn, daarom wordt ook een kruisverwijzing naar deze subvelden gegeven. 6.4.4. >RUIMTE VOOR DE TABEL> 6.5. Groep van berichten 6.5.1. De operationele categorieën (groepen) berichten die zijn gedefinieerd 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 definitiedocumentatie. 6.5.4. Er zal geen titelwaarde voor een groep berichten opnieuw worden gebruikt voor een andere groep met een andere betekenis. 6.5.5. In Bijlage B van deze norm zal een centrale index van berichttitels worden bijgehouden. 6.5.6. Voor elke berichttitel die staat vermeld in de centrale index van berichttitels wordt een verwijzing naar de gerelateerde groep gegeven. 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 overeengekomen voor gebruik binnen de op dit moment gedefinieerde 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 redundantie. BIJLAGE A (Normatief) ADEXP-VELDDEFINITIES A.1. Inleiding Deze bijlage bevat een overzicht van alle velden; hulptermen, primaire velden en subvelden die zijn gedefinieerd voor gebruik in ADEXP. A.2. ADEXP-hulptermen >RUIMTE VOOR DE TABEL> A.3. ADEXP primaire velden >RUIMTE VOOR DE TABEL> A.4. ADEXP-subvelden >RUIMTE VOOR DE TABEL> BIJLAGE B (Normatief) CENTRALE INDEX VAN ADEXP-BERICHTTITELS >RUIMTE VOOR DE TABEL> BIJLAGE C (Normatief) CENTRALE INDEX VAN GERESERVEERDE BERICHTTITELS C.1. Inleiding Deze bijlage bevat een centrale index van gereserveerde berichttitels die nog niet zijn gedefinieerd voor gebruik in ADEXP. Hun opname in deze bijlage geeft aan dat ze ofwel zijn voorzien voor toekomstig gebruik of dat ze reeds in gebruik zijn maar dat hun gebruik beperkt is tot lokale 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 >RUIMTE VOOR DE TABEL> BIJLAGE D (Normatief) CENTRALE INDEX VAN GERESERVEERDE VELDEN D.1. Inleiding Deze bijlage bevat een centrale index van gereserveerde velden, Primair, Subveld en Hulptermen, die nog niet zijn gedefinieerd voor gebruik in ADEXP. Hun opname in deze bijlage geeft aan dat ze ofwel zijn voorzien 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 niet formeel geaccepteerd 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 dat een sleutelwoord wordt gemaakt dat reeds in gebruik is binnen een lokaal systeem. D.3. Gereserveerde hulptermen >RUIMTE VOOR DE TABEL> D.4. Gereserveerde primaire velden >RUIMTE VOOR DE TABEL> D.5. Gereserveerde subvelden >RUIMTE VOOR DE TABEL> BIJLAGE E (Ter informatie) INTRODUCTIE VAN BERICHTGROEPEN INLEIDING Deze bijlage bevat een inleiding op de verschillende groepen of categorieë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. Document Ref. 3 bevat al het definiërende materiaal 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 het gebruik van verplichte 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 980305123152 -PT -PTID LOTEE -FL F330 -ETO 980305124401 -PT -PTID AVS -FL F330 -ETO 980305125357 -PT -PTID KORET -FL F330 -ETO 980305130137 -PT -PTID BARKO -FL F330 -ETO 980305130734 -PT -PTID CANAR -FL F330 -ETO 980305131544 -PT -PTID VIS -FL F330 -ETO 980305132220 -PT -PTID FTM -FL F234 -ETO 980305133230 -PT -PTID LPPT -FL F000 -ETO 980305134529 -END RTEPTS -ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS -ATSRT UG41 AVS FTM E.2. 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 Document Ref. 5 bevat al het definiërende materiaal voor deze berichten. E.2.2.2. Samenstelling primaire velden Document Ref. 5 bevat een gedetailleerde definitie van berichtinhoud, regels voor het invoegen van gegevens en het gebruik van verplichte 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 het invoegen van gegevens en het gebruik van verplichte en facultatieve velden. Voorbeeld: Eerste bericht voor systeemactivering -TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646 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 informatie 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. Document Ref. 6 bevat al het definiërende materiaal voor deze berichten. E.3.3. Samenstelling van primaire velden Document Ref. 6 bevat al het definiërende materiaal 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, tijdelijk afgescheiden gebieden, gevaarlijke en verboden gebieden etc. E.4.2. Definitie van berichttitels Berichttitels binnen deze categorie zijn: AUP, CRAM, UUP. Document Ref. 7 bevat al het definiërende materiaal voor deze berichten. E.4.3. Samenstelling primaire velden Document Ref. 7 bevat al het definiërende materiaal voor deze berichten. Voorbeeld: Bericht met beschikbaarheid voorwaardelijke route -TITLE CRAM -PART -NUM 001 -LASTNUM 010 -FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600 -BEGIN LACDR -AIRROUTE -NUM 001 -REFATSRTE UA23 ELVAR LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803300600 -AIRROUTE -NUM 002 -REFATSRTE UA44 ESP LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730 -AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP -FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600 -AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730 -AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600 -AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP -FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530 -AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL -FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330 -END LACDR E.5. 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. Document Ref. 7 bevat al het definiërende materiaal voor deze berichten. E.5.3. Samenstelling primaire velden Document Ref. 7 bevat al het definiërende materiaal voor deze berichten. Voorbeeld: Bericht met aanvraag 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 012 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. Het VOORBEELD 1 hieronder wordt gepresenteerd op een manier die het gemakkelijk leesbaar maakt. Dit is bereikt door het gebruik van wagenteruglopen, 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 TALAS -ALTRNT1 LBSF -EETFIR EDUU 0014 -EETFIR LOVV 0035 -EETFIR LJLA 0054 -EETFIR LHCC 0057 -EETFIR LYBA 0113 -EETFIR LWSS 0148 -EETFIR LGGG 0159 -BEGIN RTEPTS -PT -PTID EDDF -FL F000 -ETO 980317071500 -PT -PTID NDG -FL F311 -ETO 9803173414 -PT -PTID RIDER -FL F327 -ETO 980317073726 -PT -PTID MAH -FL F330 -ETO 980317074130 -PT -PTID MUN -FL F330 -ETO 980317074449 -PT -PTID CHIEM -FL F330 -ETO 980317074754 -PT -PTID UNKEN -FL F330 -ETO 980317075109 -PT -PTID GRZ -FL F330 -ETO 9803170080830 -PT -PTID DIMLO -FL F330 -ETO 980317081443 -PT -PTID BABIT -FL F330 -ETO 980317083107 -PT -PTID SAVIN -FL F330 -ETO 980317083613 -PT -PTID UPIVO -FL F330 -ETO 980317084054 -PT -PTID KLENA -FL F330 -ETO 980317084204 -PT -PTID VAL -FL F330 -ETO 980317084629 -PT -PTID KAVOR -FL F330 -ETO 980317085329 -PT -PTID BUI -FL F330 -ETO 980317090135 -PT -PTID SARAX -FL F330 -ETO 980317090650 -PT -PTID PEP -FL F312 -ETO 980317091414 -PT -PTID TALAS -FL F241 -ETO 980317091746 -PT -PTID LGTS -FL F000 -ETO 980317093138 -END RTEPTS -SID NDG3D -ATSRT UW70 NDG MUN -ATSRT UB103 MUN UNKEN -ATSRT UT23 UNKEN BABIT -ATSRT UR26 BABIT SAVIN -ATSRT UG18 SAVIN BUI -ATSRT UB1 BUI TALAS 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 -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 3 -TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS 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 ontvangend systeem in staat zou stellen om met succes een onbekend of niet-herkend veld te "negeren" of "over te slaan" zonder noodzakelijkerwijs het bericht dat wordt verwerkt ongeldig te hoeven maken. Deze implementatie maakt de toevoeging van een nieuw veld binnen een bericht mogelijk zonder dat het vereist is om van tevoren alle ontvangende 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 wordt deze doelstelling bereikt door het gebruik 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 mogelijkheid om een bericht samen te stellen met elke gewenst niveau van nesten. Er bestaat echter geen herstelmogelijkheid voor een niet-herkend subveld, dat misschien voorkomt op het derde of vierde geneste niveau, zonder de kans op verkeerde interpretatie van gegevens of de noodzaak om het bericht ongeldig te verklaren. De voorgestelde vereiste wijzigingen 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 het noodzakelijk dat de lexicale analysator in staat is om zowel het einde als het begin van een veld te bepalen. De huidige structuur maakt het alleen mogelijk om het begin van een veld te bepalen door gebruik van het teken "-". 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 het begin van een veld aan te 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 >RUIMTE VOOR DE TABEL> BIJLAGE III FLIGHT DATA EXCHANGE - INTERFACE CONTROL DOCUMENT (FDE-ICD), EDITIE 1.0 (Eurocontrol-referentiedocument COM.ET1.ST12-STD) INHOUDSOPGAVE >RUIMTE VOOR DE TABEL> AUTEURSRECHT Dit document is geproduceerd door Eurocontrol Agency. Het auteursrecht berust bij Eurocontrol Agency. De inhoud, of enig deel daarvan, is dus vrijelijk beschikbaar voor vertegenwoordigers van de lidstaten, maar kopiëren of openbaar maken aan derden vereist voorafgaande schriftelijke toestemming van Eurocontrol Agency. VOORWOORD 1. Verantwoordelijke instantie Dit normdocument is opgesteld door en wordt onderhouden door de Flight Plan related Data Exchange (FPDE) Task Force van de European Organisation for the Safety of Air Navigation (Eurocontrol). 2. EATCHIP Work Programme Document Deze norm heeft betrekking op het EATCHIP Work Programme Document (EWPD), Communications Domain, Executive Task 01, Specialist Task 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 wordt van kracht na aanvaarding door de Permanente Commissie van Eurocontrol en komt in de plaats van de Eurocontrol Standard for On-Line Data Interchange (OLDI), Edition 1, Part 3: TECHNICAL REQUIREMENTS (Short Term Interface Control Document) Ref. 001-3-92. 4. Technische correcties en amendementen Deze norm wordt voortdurend bijgewerkt met de 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 Eurocontrol 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; - Voor Aanbevolen formuleringen, die worden afgedrukt in een cursief licht lettertype, worden de (hulp)werkwoorden "zouden" of "dienen" gebruikt, waarbij de status wordt aangegeven door het prefix Aanbeveling. 5.3. Alle andere informatie die als essentieel wordt beschouwd voor het begrip van een bepaalde inspringende tekst wordt binnen 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 profielvereisten] (PRL's) in Bijlage E in een geschikt formaat te presenteren springen sommige tabellen bij uitzondering niet in en lopen ze niet over 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 - normatief - 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. 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 opdracht had gekregen om nieuwe interfacenormen te definiëren voor de toekomstige toepassing van OLDI tussen Area Control Centres. Eerdere OLDI-verbindingen waren gebaseerd op eigen protocollen zoals INTERCAUTRA of Datenübertragungs- und Verteilungssystem (DÜV), die lopen via speciale punt-puntverbindingen 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 Short Term 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), met inbegrip van een breder gebruik van gezamenlijke netwerken en de introductie van nieuwe normen voor onderste lagen. Deze Eurocontrol-norm bevat een minimumverzameling met functionaliteiten die met minimale aanpassingen kunnen worden ondersteund door bestaande OLDI-implementaties, 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 et Télégraphes (CCITT), 1980 of later. 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 amendement op het huidige protocol 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 datacommunicatie 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 Standardisation/International Electrotechnical Commission (ISO/IEC) Technical Report (TR) 10000-2 [Referentie 3]. Het profiel 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 No 001-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. 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 >PIC FILE= "L_2000254NL.017801.EPS"> 2.4. Gedetailleerde beveiligingsaspecten van de gespecificeerde datacommunicatie-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, doordat er in deze tekst naar wordt verwezen, 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 onmiddellijk 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 Eurocontrol-norm totdat ze formeel zijn beoordeeld en in dit Eurocontrol-normdocument zijn opgenomen. In het geval van conflicten tussen de vereisten van dit Eurocontrol-normdocument en de inhoud van deze andere documenten waarnaar wordt verwezen, zal deze Eurocontrol-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 dedicated circuit [ITU-T-aanbeveling X.25 (1993) (Rev. 1), Interface tussen data terminal equipment (DTE) en data circuit-terminating equipment (DCE) voor terminals die functioneren in de pakket-modus en die via een speciale verbinding zijn verbonden met openbare datanetwerken]. 2. ISO/IEC TR 10000-1:1992, Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework (2nd edition) [ISO/IEC TR 10000-1:1992, Informatietechnologie - Raamwerk en taxonomie 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 - Part 2: Principles and Taxonomy for OSI Profiles (3rd edition) [ISO/IEC TR 10000-2:1994, Informatietechnologie - 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 - Telecommunications and information exchange between systems - High-level data link control procedures - Description of the X.25 LAPB-compatible DTE Data Link procedures (2nd edition) [ISO/IEC 7776:1994, Informatietechnologie - Telecommunicatie 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 edition) [ISO/IEC 8208:1993, Informatietechnologie - Datacommunicatie - X.25 Pakketlaagprotocol voor Data Terminal Equipment (3e uitgave)]. 8. ISO/IEC ISP 10609-9:1992, Information technology - International Standardized Profiles TB, TC, TD and TE - Connection-mode Transport Service over Connection-mode Network Service - Part 9: Subnetwork-type dependent requirements for Network Layer, Data Link Layer and Physical Layer concerning permanent access to a pakket-switched data network using virtual calls [ISO/IEC ISP 10609-9:1992, Informatietechnologie - Internationaal genormaliseerde 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 dat gebruikt maakt van virtuele 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, Informatietechnologie - 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 - Telecommunications and information exchange between systems - Use of X.25 to provide the OSI connection-mode Network Service (2nd edition) [ISO/IEC 8878:1992, Informatietechnologie - 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), No 001-92, Edition 1, 1992 [Eurocontrol-norm voor On-Line Data Interchange (OLDI), No 001-92, Uitgave 1, 1992]. 14. ISO/IEC 9646-1:1994, Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts (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 rapport versie 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 pakketmodus 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 het ISDN-tijdperk]. 19. ITU-T Recommendation X.75 (1993) (Rev. 1), Pakket-switched signalling system between public network providing data transmission service [ITU-T-aanbeveling X.75 (1993) (Rev. 1), Pakketgeschakeld signaleringssysteem tussen openbare netwerken die een dienst voor dataoverdracht leveren]. 20. ITU-T Recommendation X.121 (1993), International numbering plan for public data networks [ITU-T-aanbeveling X.121 (1993), Internationaal nummeringsplan voor openbare datanetwerken]. 4. DEFINITIES, SYMBOLEN EN AFKORTINGEN 4.1. Definities 4.1.1. Ten behoeve van dit Eurocontrol-normdocument zullen 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]: de profielvereisten worden uitgedrukt in de vorm van conformiteitvereisten en worden gepresenteerd in tabelvorm [Referentie 2]. 4.1.4. T-profile [T-profiel]: transportprofiel dat een Connection mode Transport Service biedt [Referentie 3]. 4.1.5. A-profile [A-profiel]: applicatieprofiel dat een Connection-mode Transport Service vereist [Referentie 3]. 4.1.6. Protocol Implementation Conformance Statement (PICS) [Conformiteitverklaring voor protocolimplementatie]: een verklaring afgegeven door de leverancier van een OSI-systeem, waarin wordt verklaard welke capaciteiten voor een gegeven OSI-protocol zijn geïmplementeerd [Referentie 14]. 4.2. Symbolen en afkortingen >RUIMTE VOOR DE TABEL> 4.3. Notaties 4.3.1. Ten behoeve van dit Eurocontrol-normdocument worden 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 dit Eurocontrol-normdocument wordt de hexadecimale weergave van een bitreeks gevormd door 4 bits tegelijk over te brengen van het meest significante bit (MSB) naar het minst significante 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 Eurocontrol-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 voorafgaand aan het gebruik. 4.3.4. Ten behoeve van het definiëren van het FDE ICD Part 1 profiel in dit Eurocontrol-normdocument zal de status van de ondersteuning 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 toegestaan in de OSI-protocollen van de bijbehorende OSI-lagen. Figuur 2 Profiel protocolstapeling >PIC FILE= "L_2000254NL.018201.EPS"> 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 daarbij behorende ondersteunende protocollen, X.21 [Referentie 4] en X.21bis [Referentie 5] zijn gedefinieerd in bestaande ISO/IEC en International Telecommunication Union-Telecommunication 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 specificaties verwijzen op een gelijk niveau met externe normen en staan 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. 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 Eurocontrol-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-normdocument 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 noodzakelijk 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 transportlaag 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 aangegeven 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 beperkingen zoals aangegeven in de Profile Requirements List [lijst met profielvereisten] 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 beperkingen zoals aangegeven in de Profile Requirements List [lijst met profielvereisten] 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 4097 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 protocoltoekenning zoals aangegeven in Bijlage C. 6.3.2.2. Een conformerende implementatie zal voldoen aan de beperkingen zoals aangegeven in de Profile Requirements List [lijst met profielvereisten] in Bijlage E.8.2. 6.3.2.3. Een conformerende implementatie zal, als data terminal equipment (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 het DTE-DTE gebruik te 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, met de waarde 256 voor beide verzendrichtingen. 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 conformiteitvereisten 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 beperkingen zoals aangegeven in de Profile Requirements List [lijst met profielvereisten] in Bijlage E.8.3. 6.3.4. Vereisten voor de fysieke laag Een conformerende implementatie zal voldoen aan de conformiteitvereisten van ISO/IEC ISP 10609-9 clausule 7 [Referentie 8]. 7. TESTMETHODEN OPMERKINGEN 1. Een benadering voor het testen van de conformiteit van implementaties 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 geleverd wordt beschreven in Bijlage E. 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 applicatieberichten; 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 applicatieberichten. 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 equivalent zijn aan die welke zijn gedefinieerd in Eurocontrol Standard No 001-3-92 Edition 1: Systeemberichten: deze berichten zullen worden gebruikt voor bewaking van verbindingen (HEARTBEAT-bericht) en applicatiebeheer (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-normdocument voor On-Line Data Interchange worden operationele berichten zoals de Activation (ACT), Advanced Boundary Information (ABI) en Logical Acknowledgement (LAM) berichten gedefinieerd. Operator-berichten: deze berichten zullen vrije tekst bevatten. Hun gebruik zal bilateraal worden overeengekomen. Ze kunnen bijvoorbeeld worden gebruikt om testinformatie uit te wisselen of om de andere kant te informeren over acties van de operator. Statusberichten: het gebruik en de inhoud van deze berichten zal bilateraal worden overeengekomen. Ze kunnen bijvoorbeeld worden gebruikt om informatie over systeembeheer uit te wisselen. OPMERKINGEN 1. 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. 3. De status van het protocol bepaalt welke typen berichten kunnen worden verzonden, zoals gespecificeerd in de volgende paragrafen. 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 transportverbinding 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-bericht opnieuw worden verzonden en zal de aftelklok opnieuw worden gestart.OPMERKING Het protocol blijft in de status ASSOCIATION_PENDING 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 veroorzaken: - 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 wordt gesignaleerd; - in elke andere status wordt het bericht genegeerd. A.4.3.6. Ontvangst van het STARTUP-bericht in de status ASSOCIATION_PENDING correspondeert met ofwel: - de applicatie op afstandgaf een MT-Associate-Request-primitieve 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 overgedragen (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. 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. Dit correspondeert met de 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 vrijgegeven; - in de status ASSOCIATION_PENDING zal een SHUTDOWN-bericht (systeembericht) worden verzonden, aftelklok Tr zal worden gestopt en de transportverbinding zal worden vrijgegeven; - in de status READY zal de transportverbinding worden vrijgegeven; - voor het overige vindt geen actie plaats. OPMERKING Het SHUTDOWN-bericht is geen vroege waarschuwing - 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-bericht te 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 noodzakelijk).OPMERKING Als de vrijgave van de associatie heeft geresulteerd in de vrijgave van de onderliggende netwerkverbinding 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 (Systeembericht) 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-bericht over de verbinding een configureerbare aftelklok 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). OPMERKING Volgens de definitie van het transportprocotol in bijlage B bestaat er geen end-to-end transportverbinding. 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 applicatie. 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 SHUTDOWN-bericht verzenden (d.w.z. L_shutdown handmatig aangeroepen of als onderdeel van de applicatielogica) alvorens te trachten om de verbinding 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 >RUIMTE VOOR DE TABEL> A.4.10.2. Lengte van bericht-body Bericht-bodies met een lengte tot en met 4096 bytes zullen worden ondersteund. A.4.10.3. Formaten systeemberichten >RUIMTE VOOR DE TABEL> A.4.10.4. Overige berichtstructuren >RUIMTE VOOR DE TABEL> 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 het protocol. In het geval van verschil met de hierboven vermelde hoofdtekst zal onderstaande specificatie prevaleren.OPMERKING De gebruikte notatie om status, gebeurtenissen, aftelklokken en acties te beschrijven is gebaseerd op 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 >RUIMTE VOOR DE TABEL> A.5.3. Mogelijke gebeurtenissen Tabel 2 Mogelijke gebeurtenissen >RUIMTE VOOR DE TABEL> A.5.4. Aftelklokken Tabel 3 Aftelklokken >RUIMTE VOOR DE TABEL> 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 >RUIMTE VOOR DE TABEL> 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 bovenstaande statustabellen zullen laatstgenoemden prevaleren. Figuur A.1 Protocol voor bestandsoverdracht: diagram met statusovergangen >PIC FILE= "L_2000254NL.019301.EPS"> 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 applicaties 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 applicatie 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 ondersteund 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 netwerkdienst. Er is sprake van een directe correspondentie tussen de twee verzamelingen (verzoek, aanduiding) primitieven. Als alternatief kan een 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 ondernomen. 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 gesignaleerd) en er een N-Connect-Indication wordt gesignaleerd, dan zal de binnenkomende poging om een netwerk op te zetten worden afgewezen 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-Request is groter dan het aangeroepen NSAP-adres van het uitstaande N-Connect-Request, waarbij de vergelijking plaatsvindt op de bit strings die worden gevormd door de binaire voorkeurscodering 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). B.4.3. Vrijgeven van de verbinding B.4.3.1. Voor vrijgave van de verbinding zal gebruik worden gemaakt van 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-Disconnect-Request worden gesignaleerd. Anderzijds, als het tot stand brengen van netwerkverbindingen met gebruik van N-Connect-primitieven 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 netwerkverbinding 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 netwerkdienst. B.4.4.2. >RUIMTE VOOR DE TABEL> 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 Eurocontrol-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 (het teken 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 4105 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. BIJLAGE C (Normatief) NETWERKPROTOCOL C.1. Inleiding Deze bijlage bevat een specificatie van een basis netwerkprotocol dat gebruik maakt van het X.25 pakket layer protocol, voor gebruik in zowel punt-punt- als pakket-switched netwerkomgevingen, ter ondersteuning 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 verbindingsmodus zoals gedefinieerd in ISO/IEC 8348 [Referentie 10], met de volgende uitzonderingen. - NSAP-adressen zijn beperkt tot de 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 wordt geboden 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ïllustreerd. >PIC FILE= "L_2000254NL.019702.EPS"> C.4.1.2. De onderdelen van het NSAP-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 dit Eurocontrol-normdocument zullen de adresonderdelen worden beperkt tot de 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 het lokale formaat. 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 gebruikt om een bepaald eindpunt binnen een ATC-eenheid aan te duiden. C.4.2.5. >RUIMTE VOOR DE TABEL> 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 betreffende instantie binnen de ATC-administratie of -organisatie. C.4.3.2. De toewijzing van ATC-eenheid-aanduidingen ten tijde van de voorbereiding voor deze norm staat vermeld in. C.5. Protocolspecificatie C.5.1. Overzicht Het protocol is gebaseerd op het Subnetwork-Dependent Convergence 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 uitgebreid formaat dat beschikbaar is bij de faciliteit Fast Select wordt hier gebruikt met het basisformaat User Data-veld in CALL REQUEST en INCOMING CALL-pakketten, aangezien beperkingen met betrekking tot de toegestane netwerkdienstparameters ervoor zorgen dat de gecodeerde informatie in 16 bytes past; - van de netwerkdienstparameters waarvoor coderingen zijn gedefinieerd in ISO/IEC 8878 [Referentie 12] worden alleen de aangeroepen en aanroepende NSAP-adressen (en alleen in de vorm zoals gedefinieerd in ) in het CALL REQUEST pakket verzonden; - het veld User Data wordt niet gebruikt in de CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST of CLEAR INDICATION-pakketten; - de alternatieve procedures voor de totstandkoming en vrijgave van netwerkaansluitingen worden niet gebruikt; - ontvangstbevestiging met gebruik van het D-bit wordt niet ondersteund. NOTA De eerste drie van deze beperkingen zorgen ervoor dat alle informatie die wordt verzonden tussen twee DTE's de beperkingen van het veld User Data in X.25 (1980) PLP zal respecteren. C.5.2. Adrescodering De aanroepende en aangeroepen NSAP-adressen zullen worden gecodeerd met behulp 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. Tabel 1 Codering van het veld User Data >RUIMTE VOOR DE TABEL> C.5.3.2. Andere parameters beschreven in ISO/IEC 8878 [Referentie 12] zullen niet worden gebruikt. C.5.4. Behandeling van adressen in INCOMING CALL-pakketten C.5.4.1. DTE-adressen Het aanroepende DTE-adres in een INCOMING CALL-pakket zal worden gevalideerd aan de hand van een lokale lijst met geldige DTE-adressen op afstand voor het systeem. Als een ongeldig adres wordt ontdekt zal de oproep worden gewist. OPMERKINGEN 1. Het aangeroepen DTE-adres, indien aanwezig, in een INCOMING CALL pakket, indien aanwezig, kan optioneel ook worden gevalideerd 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 Het aanroepende NSAP-adres dat is gecodeerd zoals hierboven beschreven in een INCOMING CALL pakket zal worden gevalideerd aan de hand van een lokale lijst van geldige NSAP-adressen op afstand voor het systeem. Als een ongeldig adres wordt ontdekt zal de oproep worden gewist. 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 het veld User Data 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 het M-bit hebben (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. BIJLAGE D (Normatief) PROFIELSPECIFIEKE PICS-PROFORMA'S D.1. Inleiding D.1.1. De leverancier van een protocolimplementatie waarvan wordt geclaimd dat deze zich conformeert aan de specificaties in de Bijlagen A-C zal de volgende PICS-proforma's invullen.OPMERKING: Auteursrecht-vrijgave voor PICS-proforma's: gebruikers van dit Eurocontrol-normdocument mogen de PICS-proforma's in deze bijlage vrijelijk reproduceren, 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 implementatie. 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 het risico te verkleinen dat niet aan de norm wordt voldaan als gevolg van een vergissing; - door de leverancier en verkrijger, of potentiële verkrijger, van de implementatie, als een gedetailleerde aanduiding van de capaciteiten 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 nooit kan worden gegarandeerd, de onmogelijkheid 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 aangegeven 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 vragenlijst 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.OPMERKINGEN 1. 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 specificeert. 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 gecategoriseerd 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 aanduiding voor het item is (bijv. eenvoudig een getal): er gelden geen verdere beperkingen ten aanzien van het formaat en de presentatie. D.2.1.3. Naar een ingevulde PICS-proforma, met inbegrip van eventuele 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.OPMERKINGEN 1. 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 ingesteld om in diverse omgevingen en configuraties te functioneren; of een korte reden (misschien gebaseerd op specifieke applicatiebehoeften) 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. Het kan nu en dan voorkomen dat een leverancier een item met een verplichte of verboden status wenst te beantwoorden (nadat alle eventuele 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 vereist voldoet niet aan deze specificatie.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 voorwaardelijk symbool in de vorm "< item >: < s >" in de kolom Status, waarbij "< item >" een itemverwijzing is die verschijnt in de eerste kolom van de tabel voor een ander item en "< s >" een statusaanduiding 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 het item waarnaar door het voorwaardelijke symbool wordt verwezen wordt gemarkeerd als ondersteund, is het voorwaardelijke item van toepassing en wordt de status ervan aangeduid door "< s >": de kolom Ondersteund zal op de gebruikelijke manier worden ingevuld. In het andere geval is het voorwaardelijke item niet relevant 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 beginletter 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. >RUIMTE VOOR DE TABEL> D.3.2. Aanduiding >PIC FILE= "L_2000254NL.020301.EPS"> D.3.3. Protocolimplementatie >PIC FILE= "L_2000254NL.020401.EPS"> 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 not applicable [niet van toepassing] D.4.1.3. Itemreferenties >RUIMTE VOOR DE TABEL> D.4.2. Aanduiding >PIC FILE= "L_2000254NL.020501.EPS"> D.4.3. Protocolimplementatie >PIC FILE= "L_2000254NL.020601.EPS"> 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 >RUIMTE VOOR DE TABEL> D.5.2. Aanduiding >PIC FILE= "L_2000254NL.020701.EPS"> D.5.3. Protocolimplementatie >PIC FILE= "L_2000254NL.020702.EPS"> BIJLAGE E (Normatief) LIJST MET PROFIELVEREISTEN E.1. Inleiding E.1.1. Deze bijlage bevat de PRL voor het FDE ICD-profiel dat in dit Eurocontrol-normdocument wordt gedefinieerd. De Implementation Conformance Statement voor een implementatie welke claimt zich aan dit profiel te 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 wordt verwezen. 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 omvat de deelverzameling van de PICS-proforma-items van de basisnorm die door het profiel 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. Daarnaast zal de PRL items 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 met de PICS-proforma's van de basisnorm. De ingevulde proforma's vormen samen de Implementation Conformance Statement [verklaring van conformiteit van de implementatie] (ICS) voor het profiel. - 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 het verkrijgen van een FDE ICD-implementatie. - Er zijn verschillende benaderingen mogelijk voor een FDE-implementatie: - In-house implementatie door een nationale instantie of organisatie: de PRL dient te worden gebruikt als de basis voor de specificatie van de vereisten en de specificatie van de acceptatietest voor de implementatie; de ingevulde ICS dient te worden geproduceerd als onderdeel van de acceptatieprocedure. - Implementatie van het profiel door een aannemer: het materiaal wordt gebruikt en 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 onderdeel van een turn-key contract of een contract voor systeemintegratie: het materiaal wordt gebruikt en geproduceerd 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 verzekert, bijvoorbeeld, dat een leverancier die voor twee instanties werkt niet zijn eigen protocollen mag introduceren 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 profielimplementatie in een van de vorige gevallen: van de leverancier van een product dient te worden vereist dat hij de PICS-proforma's levert die relevant zijn voor het product, ingevuld in overeenstemming met de hier gegeven PRL en dat hij de conformiteit van het product aan de toepasselijke profielvereisten garandeert; deze PICS kunnen dan worden verzonden als onderdeel van de ICS voor het profiel. - Na implementatie dient de ICS te worden onderhouden als onderdeel 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] -: not applicable [niet van toepassing] (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 ontkenning). E.3.3. Basisnormvereisten worden afgebeeld door gebruik van de equivalente 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 het profiel dienen de PICS-proforma's voor de basisnormen waarnaar wordt verwezen te worden ingevuld, samen met de aanvullende profiel-gerelateerde PICS-items die in deze bijlage worden geleverd. E.4.2. Als in dit profiel de functies 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 reactiekolom voor dergelijke items te worden ingevuld. In deze kolom zal 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 uitzonderingsinformatie te worden ingevuld door een referentie X< i > in te voeren, waarbij < i > een unieke identificatie is, die verwijst naar een bijbehorende reden waarom niet aan het vereiste wordt voldaan.OPMERKING Een mogelijke reden voor een dergelijke uitzondering is het voldoen aan een in behandeling zijn defectrapport 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-normdocument); - Message Header Protocol (Bijlage B bij dit Eurocontrol-normdocument); - Connection-mode Network Protocol using ISO/IEC 8208 (Bijlage C bij dit Eurocontrol-normdocument); - ISO/IEC 7776 [Referentie 6]; - Normen voor fysieke lagen vereist door 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. E.6. Conformiteitverklaring E.6.1. Overzicht van conformering >PIC FILE= "L_2000254NL.021101.EPS"> E.6.2. Dynamische conformiteitvereisten >PIC FILE= "L_2000254NL.021201.EPS"> E.7. Vereisten voor de bovenste laag Tabel 3 Protocol voor berichtenoverdracht >RUIMTE VOOR DE TABEL> E.8. Vereisten voor de onderste laag E.8.1. Vereisten voor de transportlaag Tabel 4 Berichtkopprotocol >RUIMTE VOOR DE TABEL> 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. E.8.2.1. Algemene DTE-kenmerken Tabel 5 Algemene DTE-kenmerken >RUIMTE VOOR DE TABEL> E.8.2.2. Procedures, pakket-typen en pakket-structuren Tabel 6 Pakketlaagfuncties onafhankelijk van logische kanalen >RUIMTE VOOR DE TABEL> Tabel 7 Oproepinstelling >RUIMTE VOOR DE TABEL> Tabel 8 Oproepen vrijgeven >RUIMTE VOOR DE TABEL> Tabel 9 In de uitgangstoestand terugbrengen van logische kanalen >RUIMTE VOOR DE TABEL> Tabel 10 Foutprocedures >RUIMTE VOOR DE TABEL> Tabel 11 Interruptoverdracht >RUIMTE VOOR DE TABEL> Tabel 12 Data zenden >RUIMTE VOOR DE TABEL> Tabel 13 Data ontvangen >RUIMTE VOOR DE TABEL> Tabel 14 Bevestiging van aflevering >RUIMTE VOOR DE TABEL> E.8.2.3. Diverse functies en opties Tabel 15 Waarden van oorzaak- en diagnostische codes >RUIMTE VOOR DE TABEL> E.8.2.4. Faciliteiten Tabel 16 Faciliteiten verzonden in CALL REQUEST-pakketten >RUIMTE VOOR DE TABEL> Tabel 17 Faciliteiten verzonden in CALL ACCEPT-pakketten >RUIMTE VOOR DE TABEL> Tabel 18 Faciliteiten verzonden in CLEAR REQUEST-pakketten >RUIMTE VOOR DE TABEL> Tabel 19 Faciliteiten ontvangen in INCOMING CALL-pakketten >RUIMTE VOOR DE TABEL> Tabel 20 Faciliteiten ontvangen in CALL CONNECTED-pakketten >RUIMTE VOOR DE TABEL> Tabel 21 Faciliteiten ontvangen in CLEAR INDICATION-pakketten >RUIMTE VOOR DE TABEL> Tabel 22 Faciliteiten ontvangen in CLEAR CONFIRMATION-pakketten >RUIMTE VOOR DE TABEL> E.8.2.5. Parameterwaarden en -bereiken Tabel 23 Parameterwaarden en -bereiken >RUIMTE VOOR DE TABEL> 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 >RUIMTE VOOR DE TABEL> E.8.4. Vereisten voor de fysieke laag Zie ISO/IEC TR 10609-9 clausule A.4 [Referentie 8]. 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 plaatsvinden 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 uit diverse bronnen. Om een hoog niveau van vertrouwen te bereiken dat zulke implementaties met elkaar samen zullen werken is een gemeenschappelijke 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 geeft mechanismen aan via welke vertrouwen 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 Division) 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 conformiteittest 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 samenwerking 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 het eindsysteem. F.5.1.2. De resultaten van dergelijke tests kunnen als bewijs dienen ter ondersteuning 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 internationale normen (bijv. ISO/IEC 8208 [Referentie 7]) reeds abstracte testsuites gedefinieerd zijn die kunnen worden gebruikt bij conformiteittests. F.5.1.3. Het doel van dit document is om te voorzien in een genormaliseerd programma van tests dat berust op een genormaliseerde testsuite waarvan het gebruik dient te leiden tot een vergelijkbaarheid van testresultaten, brede acceptatie van dergelijke testresultaten en een minimalisering van de benodigde conformiteittests. De genormaliseerde 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 uitgevoerd. De laatste test kan alleen succesvol zijn als de lagere lagen correct functioneren en het is waarschijnlijk dat dit met de 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 afgesproken en uitgevoerd door de samenwerkende ATCC's. F.5.4. Bevestiging De resultaten van tests dienen te worden geregistreerd en overeengekomen tussen de samenwerkende partijen. F.5.5. Mededeling Lidstaten dienen gegevens met betrekking tot de resultaten van alle test mede te delen aan Eurocontrol. 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-adrescodering zoals gedefinieerd in Bijlage C. Tabel 1 Aanduidingen van ATC-eenheden >RUIMTE VOOR DE TABEL> 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 noodzakelijk geacht om richtlijnen te bieden voor FDE ICD Part 1 implementaties. H.2. Doelstelling en reikwijdte H.2.1. Het doel van deze bijlage is om adviezen te 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 betrekking 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 bedreigingen die de normale werking kunnen verstoren. H.3. Bibliografie Het volgende document bevat een gedetailleerde technische analyse waarvan deze bijlage een overzicht is: Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [Referentie 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 verschillende 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 het geval van een DTE-omschakeling dient de DTE die stand-by is een DISC frame te genereren om herstel van de verbinding te bespoedigen. H.4.3. Beveiliging H.4.3.1. Bij gebruik van ISDN als backup-medium dient de ISDN terminal 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-identificatie en identificatie-informatie. H.4.4. Configuratievoorbeeld Figuur H.1 Voorbeeld van een huurlijnconfiguratie >PIC FILE= "L_2000254NL.023301.EPS"> 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 het geval dat andere aanroepmechanismen worden geïmplementeerd 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 voordoet 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 dienst verhogen.OPMERKING: Opname van een transportstapeling in de profielspecificatie kan worden ontwikkeld in de context van een toekomstige FDE ICD Part 2 norm. H.6.2. Beschikbaarheid Als een oproep niet succesvol is, dient het systeem waarvan de oproep afkomstig is een tweede oproep uit te voeren met gebruik van het tweede X.121-adres (indien beschikbaar). H.6.3. Systeembeheer H.6.3.1. Waar mogelijk dienen schakelaars te worden toegepast die automatisch 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. Het overschakelen van een FEP dient een TC-disconnect te 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 gegevensverbindingslagen 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 netwerkconfiguratie >PIC FILE= "L_2000254NL.023401.EPS">