Komisijas Regula (EK) Nr. 2082/2000 (2000. gada 6. septembris), ar kuru pieņem Eurocontrol standartus un groza Direktīvu 97/15/EK, ar ko pieņem Eurocontrol standartus un groza Padomes Direktīvu 93/65/EEK
Oficiālais Vēstnesis L 254 , 09/10/2000 Lpp. 0001 - 0234
CS.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
ET.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
HU.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
LT.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
LV.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
MT.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
PL.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
SK.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
SL.ES Nodaļa 07 Sējums 005 Lpp. 104 - 337
Komisijas Regula (EK) Nr. 2082/2000 (2000. gada 6. septembris), ar kuru pieņem Eurocontrol standartus un groza Direktīvu 97/15/EK, ar ko pieņem Eurocontrol standartus un groza Padomes Direktīvu 93/65/EEK EIROPAS KOPIENU KOMISIJA, ņemot vērā Eiropas Kopienas dibināšanas līgumu, ņemot vērā Padomes 1993. gada 19. jūlija Direktīvu 93/65/EEK par saderīgu tehnisko specifikāciju noteikšanu un piemērošanu iekārtu un sistēmu iepirkumam gaisa satiksmes pārvaldības vajadzībām [1] un jo īpaši tās 3. pantu, ņemot vērā Komisijas 1997. gada 25. marta Direktīvu 97/15/EK, ar ko pieņem Eurocontrol standartus un groza Padomes Direktīvu 93/65/EEK par saderīgu tehnisko specifikāciju noteikšanu un piemērošanu iekārtu un sistēmu iepirkumam gaisa satiksmes pārvaldības vajadzībām [2], tā kā: (1) Ar Direktīvu 97/15/EK ir pieņemts Eurocontrol standarts datu apmaiņai tiešsaistē (OLDI), redakcija 1.0, un Eurocontrol standarts gaisa satiksmes pakalpojumu datu apmaiņas atveidei (ADEXP), redakcija 1.0. (2) Eiropas Aeronavigācijas drošības organizācija (Eurocontrol) ir pieņēmusi abus iepriekš minētos standartus jaunākā redakcijā, proti, OLDI redakcijā 2.2 un ADEXP redakcijā 2.0, kā arī jaunu Eurocontrol standartu ar nosaukumu "Saskarnes kontroldokuments lidojumu datu apmaiņai" (FDE-ICD). (3) Šie Eurocontrol standarti ietilpst Direktīvas 93/65/EEK darbības jomā un veicina dalībvalstu gaisa satiksmes pārvaldības sistēmu saskaņošanu, jo īpaši attiecībā uz lidojumu nodošanu starp gaisa satiksmes vadības centriem (OLDI), gaisa satiksmes plūsmas pārvaldību (ADEXP) un sakariem starp attiecīgo valstu sistēmām (FDE-ICD). (4) OLDI redakcija 2.2 un ADEXP redakcija 2.0 aizstāj to iepriekšējās redakcijas, kas pašlaik ir spēkā saskaņā ar Direktīvas 97/15/EK 1. panta noteikumiem, un tādēļ minētais pants ir jāatceļ. (5) Šīs regulas noteikumi ir saskaņā ar atzinumu, ko pieņēmusi komiteja, kas izveidota saskaņā ar Direktīvu 93/65/EEK, IR PIEŅĒMUSI ŠO REGULU. 1. pants Eurocontrol specifikāciju obligātās sastāvdaļas, kas ietilpst tālāk norādītajos Eurocontrol standartos, tiek pieņemtas saskaņā ar Direktīvu 93/65/EEK, ciktāl tās ir nepieciešamas vienotas gaisa satiksmes pārvaldības sistēmas ieviešanai Eiropā: - Eurocontrol standarts datu apmaiņai tiešsaistē (OLDI), redakcija 2.2 (Eurocontrol dokumentu šifrs DPS.ET1.ST06-STD), kura teksts iekļauts šīs regulas I pielikumā, - Eurocontrol standarts gaisa satiksmes pakalpojumu datu apmaiņas atveidei (ADEXP), redakcija 2.0 (Eurocontrol dokumentu šifrs DPS.ET1.ST09-STD), kura teksts iekļauts šīs regulas II pielikumā, - Eurocontrol standarts saskarnes kontroldokumentam lidojumu datu apmaiņai (FDE-ICD), redakcija 1.0 (Eurocontrol dokumentu šifrs COM.ET1.ST12-STD), kura teksts iekļauts šīs regulas III pielikumā. 2. pants Ar šo atceļ Direktīvas 97/15/EK 1. pantu. 3. pants Šī regula stājas spēkā trešajā dienā pēc tās publicēšanas Eiropas Kopienu Oficiālajā Vēstnesī.. Šī regula uzliek saistības kopumā un ir tieši piemērojama visās dalībvalstīs. Briselē, 2000. gada 6. septembrī Komisijas vārdā — priekšsēdētāja vietniece Loyola De Palacio [1] OV L 187, 29.7.1993., 52. lpp. [2] OV L 95, 10.4.1997., 16. lpp. -------------------------------------------------- I PIELIKUMS DATU APMAIŅA TIEŠSAISTĒ (OLDI), REDAKCIJA 2.2 (Eurocontrol dokumentu šifrs DPS.ET1.ST06-STD) SATURS AUTORTIESĪBU ATRUNA … PRIEKŠVĀRDS … 1. IEVADS … 1.1. Mērķis … 1.2. Darbības joma … 2. NORĀDES … 3. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI … 3.1. Definīcijas … 3.2. Simboli un saīsinājumi … 4. VISPĀRĪGĀS PRASĪBAS … 4.1. Ievads … 4.2. Lidojumu datu apstrādes sistēmas prasības … 4.2.1. Lidojumu datu bāze … 4.2.2. Darbība reālajā laikā … 4.2.3. Datu komunikācijas spēja … 4.2.4. Lietojumfunkcijas … 4.2.5. Cilvēka — mašīnas saskarne (HMI) … 4.2.6. Ziņojumu ierosināšana … 4.2.7. Ziņojumu saņemšana … 4.3. Datu atjaunināšana, izmantojot novērošanas datus … 4.4. OLDI datu reģistrēšana … 4.4.1. Saturs … 4.4.2. Tehniskais nodrošinājums … 4.5. Pieejamība, uzticamība, datu drošība un datu integritāte … 4.5.1. Pieejamība … 4.5.2. Uzticamība … 4.5.3. Datu drošība … 4.5.4. Datu integritāte … 4.6. Darbības novērtējums … 4.6.1. Novērtēšanas laiks … 4.6.2. Darbības uzsākšanas datums … 5. ZIŅOJUMU KATEGORIJAS … 5.1. Vispārējā daļa … 5.1.1. Mērķis … 5.1.2. Ziņojumu kategorijas … 5.2. Transakciju ilgums … 5.2.1. Transakciju ilguma nosacījumi … 5.3. Ziņojumu klasifikācija un sistematizācija … 5.3.1. Ziņojumu klasifikācija — obligātie un komplementārie ziņojumi … 5.3.2. Ziņojumu iedalījums kategorijās … 6. PAMATPROCEDŪRA — OBLIGĀTIE ZIŅOJUMI … 6.1. Vispārējā daļa … 6.1.1. Prasību apraksts … 6.1.2. Lietojums … 6.2. Iepriekšējs ziņojums par robežas šķērsošanu (ABI) … 6.2.1. ABI ziņojuma mērķis … 6.2.2. Ziņojuma saturs … 6.2.3. Lietošanas noteikumi … 6.2.4. ABI saņemšanas apstiprinājums … 6.2.5. Piemēri … 6.3. Aktivizēšanas ziņojums (ACT) … 6.3.1. ACT ziņojuma mērķis … 6.3.2. Ziņojuma saturs … 6.3.3. Lietošanas noteikumi … 6.3.4. ACT saņemšanas apstiprinājums … 6.3.5. Piemēri … 6.4. Loģiskā apstiprinājuma ziņojums (LAM) … 6.4.1. LAM ziņojuma mērķis … 6.4.2. Ziņojuma saturs … 6.4.3. Lietošanas noteikumi … 6.4.4. LAM saņemšanas apstiprinājums … 6.4.5. Piemēri … 7. PAMATPROCEDŪRA — KOMPLEMENTĀRIE ZIŅOJUMI … 7.1. Vispārējā daļa … 7.1.1. Prasību apraksts … 7.1.2. Lietojums … 7.2. Iepriekšējas aktivizēšanas ziņojums (PAC) … 7.2.1. PAC ziņojuma mērķis … 7.2.2. Ziņojuma saturs … 7.2.3. Lietošanas noteikumi … 7.2.4. PAC saņemšanas apstiprinājums … 7.2.5. Piemēri … 7.3. Labojumu ziņojums (REV) … 7.3.1. REV ziņojuma mērķis … 7.3.2. Ziņojuma saturs … 7.3.3. Lietošanas noteikumi … 7.3.4. REV saņemšanas apstiprinājums … 7.3.5. Piemēri … 7.4. Koordinācijas atcelšanas ziņojums (MAC) … 7.4.1. MAC ziņojuma mērķis … 7.4.2. Ziņojuma saturs … 7.4.3. Lietošanas noteikumi … 7.4.4. MAC saņemšanas apstiprinājums … 7.4.5. Piemēri … 7.5. SSR koda piešķiršanas ziņojums (COD) … 7.5.1. COD ziņojuma mērķis … 7.5.2. Ziņojuma saturs … 7.5.3. Lietošanas noteikumi … 7.5.4. COD saņemšanas apstiprinājums … 7.5.5. Piemēri … 7.6. Informatīvais ziņojums (INF) … 7.6.1. INF ziņojuma mērķis … 7.6.2. Ziņojuma saturs … 7.6.3. Lietošanas noteikumi … 7.6.4. INF saņemšanas apstiprinājums … 7.6.5. Piemēri … 8. DIALOGA PROCEDŪRA — KOORDINĀCIJA … 8.1. Vispārējā daļa … 8.1.1. Ievads … 8.1.2. Filtrs … 8.1.3. Ziņojumu secība … 8.1.4. Vienlaicīgu ziņojumu apstrāde … 8.1.5. Atteikuma ziņojumu apstrāde … 8.1.6. Operacionālās atbildes taimauts … 8.1.7. Lietojums … 8.2. Aktivizēšanas ziņojums (ACT) … 8.2.1. ACT ziņojuma mērķis … 8.2.2. Ziņojuma saturs … 8.2.3. Lietošanas noteikumi … 8.2.4. ACT saņemšanas apstiprinājums … 8.3. Ierosinātās aktivizēšanas saskaņošanas ziņojums (RAP) … 8.3.1. RAP ziņojuma mērķis … 8.3.2. Ziņojuma saturs … 8.3.3. Lietošanas noteikumi … 8.3.4. RAP saņemšanas apstiprinājums … 8.3.5. Operacionālā atbilde uz RAP … 8.3.6. Piemēri … 8.4. Labojumu ziņojums (REV) … 8.4.1. REV ziņojuma mērķis … 8.4.2. Ziņojuma saturs … 8.4.3. Lietošanas noteikumi … 8.4.4. REV saņemšanas apstiprinājums … 8.4.5. Operacionālā atbilde uz REV … 8.5. Ierosināto labojumu saskaņošanas ziņojums (RRV) … 8.5.1. RRV ziņojuma mērķis … 8.5.2. Ziņojuma saturs … 8.5.3. Lietošanas noteikumi … 8.5.4. RRV saņemšanas apstiprinājums … 8.5.5. Operacionālā atbilde uz RRV … 8.5.6. Piemēri … 8.6. Rezervstāves ziņojums (SBY) … 8.6.1. SBY ziņojuma mērķis … 8.6.2. Ziņojuma saturs … 8.6.3. Lietošanas noteikumi … 8.6.4. SBY saņemšanas apstiprinājums … 8.6.5. Piemēri … 8.7. Apstiprināšanas ziņojums (ACP) … 8.7.1. ACP ziņojuma mērķis … 8.7.2. Ziņojuma saturs … 8.7.3. Lietošanas noteikumi … 8.7.4. ACP saņemšanas apstiprinājums … 8.7.5. Piemēri … 8.8. Koordinācijas ziņojums (CDN) … 8.8.1. CDN ziņojuma mērķis … 8.8.2. Ziņojuma saturs … 8.8.3. Lietošanas noteikumi … 8.8.4. CDN saņemšanas apstiprinājums … 8.8.5. Operacionālā atbilde uz CDN … 8.8.6. Piemēri … 8.9. Koordinācijas atteikuma ziņojums (RJC) … 8.9.1. RJC ziņojuma mērķis … 8.9.2. Ziņojuma saturs … 8.9.3. Lietošanas noteikumi … 8.9.4. RJC saņemšanas apstiprinājums … 8.9.5. Piemēri … 9. DIALOGA PROCEDŪRA — SAKARU NODOŠANA … 9.1. Vispārējā daļa … 9.1.1. Ievads … 9.1.2. Ziņojumu secība … 9.1.3. Sakaru nodošana … 9.2. Nodošanas ierosināšanas ziņojums (TIM) … 9.2.1. TIM ziņojuma mērķis … 9.2.2. Ziņojuma saturs … 9.2.3. Lietošanas noteikumi … 9.2.4. TIM saņemšanas apstiprinājums … 9.2.5. Piemērs … 9.3. Papilddatu ziņojums (SDM) … 9.3.1. SDM ziņojuma mērķis … 9.3.2. Ziņojuma saturs … 9.3.3. Lietošanas noteikumi … 9.3.4. SDM saņemšanas apstiprinājums … 9.3.5. Piemērs … 9.4. Pārņemšanas ierosinājums (HOP) … 9.4.1. HOP ziņojuma mērķis … 9.4.2. Ziņojuma saturs … 9.4.3. Lietošanas noteikumi … 9.4.4. HOP saņemšanas apstiprinājums … 9.4.5. Piemērs … 9.5. Frekvences maiņas pieprasījuma ziņojums (ROF) … 9.5.1. ROF ziņojuma mērķis … 9.5.2. Ziņojuma saturs … 9.5.3. Lietošanas noteikumi … 9.5.4. ROF saņemšanas apstiprinājums … 9.5.5. Piemērs … 9.6. Frekvences maiņas ziņojums (COF) … 9.6.1. COF ziņojuma mērķis … 9.6.2. Ziņojuma saturs … 9.6.3. Lietošanas noteikumi … 9.6.4. COF saņemšanas apstiprinājums … 9.6.5. Piemēri … 9.7. Ziņojums par sakaru uzņemšanu manuālajā režīmā (MAS) … 9.7.1. MAS ziņojuma mērķis … 9.7.2. Ziņojuma saturs … 9.7.3. Lietošanas noteikumi … 9.7.4. MAS saņemšanas apstiprinājums … 9.7.5. Piemērs … A PIELIKUMS (NORMATĪVS) DATU IESTRĀDES NOTEIKUMI … B PIELIKUMS (NORMATĪVS) ĪPAŠAS PRASĪBAS MARŠRUTA DATU APSTRĀDEI … C PIELIKUMS (INFORMATĪVS) DIALOGA PROCEDŪRAS (SYSCO 1. LĪMENIS) FĀZES — ZIŅOJUMU SECĪBA … AUTORTIESĪBU ATRUNA Šo dokumentu ir sagatavojusi Eiropas Aeronavigācijas drošības organizācijas (Eurocontrol) aģentūra. Autortiesības pieder Eurocontrol aģentūrai. Tādējādi dokumenta vai jebkuras tā daļas saturs ir brīvi pieejams dalībvalstu pārstāvjiem, bet tā pavairošanai vai izpaušanai jebkurai citai personai ir vajadzīga Eurocontrol aģentūras rakstiska piekrišana. PRIEKŠVĀRDS 1. Atbildīgā iestāde Eurocontrol standarts datu apmaiņai tiešsaistē (OLDI), redakcija 2.2, izstrādāts Eurocontrol Eiropas Gaisa satiksmes vadības (ATC) saskaņošanas un integrācijas programmas (EATCHIP) Attīstības direktorātā (DED), kas arī atbild par dokumenta atjaunināšanu. Piezīmes un jautājumus var sūtīt Eurocontrol ģenerāldirektoram, Rue de la Fusée, 96, B-1130 Bruxelles, adresējot tos struktūrvienībai DED-2. 2. Saistība ar EATCHIP darba programmas dokumentu Šis standarts radīts, veicot EATCHIP ATM datu apstrādes sistēmu (DPS) jomā speciālo uzdevumu DPS.ET1.ST06, kas formulēts EATCHIP darba programmas dokumenta (EWPD) redakcijā 2.0 (30.9.1994.). 3. Apstiprināšana un grozījumi Šis standarts apstiprināts, ievērojot šeit norādīto apstiprināšanas procedūru, kas atrunāta Eurocontrol standartizācijas direktīvās: - apstiprināšana EATCHIP Ekspluatācijas prasību un ATM datu apstrādes grupā (ODT), veicot saraksti, - pārrunas ar visu ECAC (Eiropas Civilās aviācijas konference) valstu pārstāvjiem pārvaldības komitejā vai EATCHIP projektu komitejā, - apstiprināšana EATCHIP projektu komitejā un pārvaldības komitejā, - apstiprināšana pastāvīgajā komisijā. Šā standarta normas piemēro pēc apstiprināšanas pastāvīgajā komisijā. Ņemot vērā gaisa satiksmes vadības (ATC) kārtības attīstību, ar ODT starpniecību var ierosināt grozījumus un papildinājumus turpmākai apspriešanai un iespējamai apstiprināšanai. Šie ierosinājumi tiks iekļauti kā grozījumi vai tos ietvers nākamajā dokumenta redakcijā, ko apstiprinās un pieņems saskaņā ar noteikto kārtību. 4. Redakcionālie principi Apzīmējot katra izteikuma statusu, tika ievēroti šādi redakcionālie principi. Normatīvās sastāvdaļas rakstītas parastiem burtiem bez izcēluma, fakultatīvās sastāvdaļas rakstītas parastajā slīprakstā, priekšā ar vārdu "Ieteikums" norādot to statusu. Specifikāciju aprakstos tika ievēroti šādi redakcionālie principi. Normatīvās sastāvdaļas parasti ir vajadzības izteiksmē (angļu tekstā lieto "shall"), bet fakultatīvās sastāvdaļas - vēlējuma izteiksmē (angļu tekstā lieto "should"). Piezīmes rakstītas slīprakstā bez izcēluma, tās ievada vārds "PIEZĪME". 5. Saistība ar Eurocontrol standarta datu apmaiņai tiešsaistē 1. redakciju Šis dokuments aizstāj Eurocontrol standarta datu apmaiņai tiešsaistē 1. redakcijas 1. un 2. daļu. Tā 3. daļa, kurā aplūkoti izmantojamie tehniskie protokoli, aizstāta ar Eurocontrol standarta saskarnes kontroldokumenta lidojumu datu apmaiņai 1. daļu. 6. Būtiskas atšķirības no 1. redakcijas Galvenās izmaiņas un papildinājumi, salīdzinot ar 1. redakciju, ir šādi: 1. Tālāk aplūkoto komplementāro (neobligāto) ziņojumu iestrāde, kas skar pamatprocedūru: - koordinācijas atcelšanas ziņojums (MAC), - ziņojums par koda piešķiršanu (COD) sekundārajam novērošanas radiolokatoram (SSR), - informatīvais (INF) ziņojums. 2. Ziņojumu satura un formāta noteikšana, lai atvieglotu robežas šķērsošanu lidojuma maršrutā, kas nav noteikts kā gaisa satiksmes pakalpojumu (ATS) maršruts, bet kuru nosaka maršruta posma sākuma un beigu punkts. 3. Dialoga procedūras iestrāde, kas ļauj: - dispečeriem, kas veic plānošanu, noskaidrot nestandarta gaisa satiksmes vadības nodošanas nosacījumus un vienoties par tiem, - nodrošināt pārņēmējam dispečeram iespēju izteikt atbildes priekšlikumu par vadības nodošanas nosacījumiem, - nodrošināt sakaru līdzekļu nodošanu vadības nodošanas gaitā. 4. Eurocontrol standartā ATS datu apmaiņas atveidei (ADEXP), tā 2. redakcijā aplūkotā formāta ieviešana. Visi ziņojumi, kas noteikti pamatprocedūrā, un ziņojumi, ko izmanto dialoga procedūras koordinācijas fāzē, ir atveidoti gan Starptautiskās civilās aviācijas organizācijas (ICAO), gan ADEXP formātā. Sakaru nodošanas ziņojumi, kas aplūkoti dialoga procedūrā, ir atveidoti tikai ADEXP formātā. 5. Tika svītroti šādi 1. redakcijas pielikumi: A : ATC struktūrvienības identifikācija. B : OLDI ziņojuma struktūra (visiem ziņojumiem 3. redakcijā ir pievienoti piemēri). D : Vēsturisks atskats. E : Ieviešanas plāns. F : Valstu atbilstība prasībām. G : Ieviešanas pamatnostādnes. H : Pamatnostādnes OLDI novērtēšanai. 6. 3. daļas "Tehniskās prasības" izdalīšana no lietojumu specifikācijas. 7. Saistība ar citiem dokumentiem Šajā dokumentā ir norādes uz divējādiem lauka formātiem, ko izmanto sastādot ziņojumus, proti, ICAO un ADEXP. ICAO lauku formāts ir aplūkots 1. norādē. Aizstājot 1. norādi ar citu dokumentu, ir jāizmanto minētajā dokumentā aplūkotā ICAO lauka tipu definīcija. ADEXP lauku formāts ir aplūkots 2. norādē. PIEZĪME: Atsauces dokumenti ir uzskaitīti 2. iedaļā. 8. Valoda Šā dokumenta oriģināls sagatavots angļu valodā. 1. IEVADS 1.1. Mērķis 1.1.1. Lidojumus, kam nodrošināti ATC pakalpojumi, ATC struktūrvienības nodod citām struktūrvienībām tā, lai tiem būtu garantēta pilnīga drošība. Lai sasniegtu šo mērķi, divas struktūrvienības parasti jau iepriekš savstarpēji koordinē katru lidojumu, kas šķērso to atbildības rajonu robežu, un nodod gaisakuģa vadību, tam sasniedzot vai tuvojoties minētajai robežai. 1.1.2. Ja to veic telefoniski, lidojuma datu pārraide koordinācijas gaitā ir ATC struktūrvienību galvenais vadības nodrošināšanas uzdevums, jo īpaši lidojumu rajonu GSV centros (ACC). Lai nebūtu jāizmanto šādas mutiskas "aplēses", astoņdesmito gadu sākumā Eiropā ekspluatācijas vajadzībām sāka savstarpēji savienot lidojumu rajonu GSV centru lidojumu datu apstrādes sistēmas (FDPS), ko dēvē par datu apmaiņu tiešsaistē (OLDI). 1.1.3. Lai atvieglotu tās ieviešanu, ieinteresētās institūcijas izstrādāja un saskaņoja kopīgus noteikumus un ziņojumu formātu, kā arī iestrādāja tos Eurocontrol standarta datu apmaiņai tiešsaistē 1. redakcijā; šā dokumenta 2.2. redakcija sagatavota ar mērķi nodrošināt šādu pakalpojumu turpmāko attīstību atbilstīgi EATCHIP prasībām. 1.2. Darbības joma 1.2.1. Šis dokuments nosaka, kādam jābūt ATC struktūrvienību FDPS tehniskajam nodrošinājumam un ziņojumiem, lai savstarpēji veiktu: - nepieciešamo koordināciju pirms lidojumu nodošanas divu struktūrvienību starpā, - šo lidojumu sakaru nodošanu. 1.2.2. Šis dokuments: - nosaka ziņojumu formātu un reglamentē to saturu, - aplūko nepieciešamo tehnisko nodrošinājumu šajās struktūrvienībās, bez kura nav iespējama datu apmaiņa. 1.2.3. Šo standartu Eurocontrol dalībvalstis savstarpēji piemēro starptautiskiem OLDI pakalpojumiem starp struktūrvienībām, kas nodrošina gaisa satiksmes vadību noteiktā lidojumu rajonā. 1.2.4. Ieteikums. Eiropas Civilās aviācijas konferences (ECAC) valstīm šis standarts būtu jāpiemēro: - OLDI iekārtām un pakalpojumiem struktūrvienībās, kas ECAC teritorijā savstarpēji nodrošina starpvalstu gaisa satiksmes vadību kādā noteiktā rajonā, - OLDI iekārtām un pakalpojumiem struktūrvienībās, kas attiecīgās valsts iekšienē savstarpēji nodrošina gaisa satiksmes vadību kādā noteiktā rajonā. 2. NORĀDES 2.1. Šeit minētie dokumenti ietver noteikumus, kas pēc norādes šajā tekstā veido šā Eurocontrol standarta noteikumus. Šā Eurocontrol standarta publicēšanas brīdī atsauces dokumenti bija spēkā tajās norādītajā redakcijā. Jebkura atsaucē minēta ICAO dokumenta pārskatīšana tūlīt nozīmē Eurocontrol standarta pārskatīšanu. Pārējo atsauces dokumentu labojumus neiekļauj šā Eurocontrol standarta noteikumos, kamēr tie nav oficiāli izskatīti un iestrādāti šajā Eurocontrol standartā. Rodoties pretrunām starp šā Eurocontrol standarta prasībām un pārējo atsauces dokumentu saturu, prioritāte ir šim Eurocontrol standartam. 2.2. Šis standarts ietver atsauces uz šādiem dokumentiem: 1. Aeronavigācijas pakalpojumu kārtība — Lidojumu un gaisa satiksmes pakalpojumu noteikumi, ICAO dokuments 4444, 13. izdevums 1996. gada 7. novembra redakcijā. 2. Eurocontrol standarts (redakcija 2.0) ATS datu apmaiņas atveidei (ADEXP), šifrs DPS-ET1-ST09-STD-01-00, datēts ar 1998. gada jūniju. 3. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI 3.1. Definīcijas Šajā Eurocontrol standartā lieto šādas definīcijas. Pārņēmēja struktūrvienība — struktūrvienība, kas nodrošina ATC pakalpojumus, kurai jāpārņem lidojuma vadība vai kura to ir pārņēmusi brīdī, kad jānotiek vadības nodošanai no vienas struktūrvienībai nākamajai vai tā jau ir notikusi. Saņemšanas apstiprinājums — apstiprinājums tam, ka ziņojums ir saņemts un to var pienācīgi apstrādāt. Aktivizēšana — process ATC saņēmējā struktūrvienībā, kad koordinēšanas gaitā, kas noris starp divām struktūrvienībām, precizē lidojuma plānu attiecīgajam reisam, iekļaujot tajā nododošās struktūrvienības sniegtos datus, un pēc tam šos datus nodod dispečeru rīcībā. Absolūtais augstums — perpendikulārs attālums no plaknes, punkta vai par punktu uzskatīta priekšmeta līdz vidējam jūras līmenim. Lietojumsistēma — ATS apakšsistēmas daļa, kas atbilst šim standartam un veido saskarni ar tādām pašām daļām citās ATS sistēmās. Atbildības rajons — noteiktu izmēru gaisa telpa, kurā ATC struktūrvienība nodrošina gaisa satiksmes pakalpojumus. Sasaiste — process, kura gaitā sistēma saista saņemto OLDI ziņojumu ar lidojuma plāna ierakstu datu bāzē. ATC struktūrvienība — struktūrvienība, kas nodrošina gaisa satiksmes vadību. Pieejamība — varbūtība, ka konkrētā brīdī iekārta būs pieejama lietotājam. Robeža — (sānu un vertikālās) plaknes, kas norobežo ATC struktūrvienības atbildības rajonu. Atļautais lidojuma līmenis — lidojuma līmenis, līdz kādam vai kādā ATC atļāvusi veikt lidojumu. ATC koordinācija — process, ko savā starpā veic ATC struktūrvienības, kuru atbildības rajoni atrodas blakus, un kas oficiāli paredz savstarpēji ziņot par plānoto robežas šķērsošanu, lai panāktu lidojumu drošību, konsekventi veicot paredzētās darbības. Koordinācijas ziņojums — vispārējs apzīmējums ziņojumiem, ko izmanto ATC koordinēšanai. Tajos ietilpst arī CDN ziņojums, kas aplūkots 8.8. punktā. Koordinācijas fāze — attiecībā uz konkrētu lidojumu tā ir fāze, kurā nododošā un saņēmēja ATC struktūrvienības vienojas par to, ar kādiem nosacījumiem (piemēram, lidojuma līmenis, robežas punkts) to starpā tiks pārņemta lidojuma vadība. Koordinācijas punkts — punkts uz robežas vai tās tuvumā, kas ir zināms koordinācijas secībā esošajām ATC struktūrvienībām un uz kuru atsaucas koordinācijas ziņojumos. Korelācija — uz noteiktiem kritērijiem balstīts process, kas paredz lidojuma plāna datu piesaisti radiolokatora ekrānā novērojamai tā paša lidojuma ceļa līnijai, kam parasti jāparādās uz dispečera ekrānpults. Eurocontrol standarts — jebkuras fizikālo īpašību, konfigurācijas, materiālu, veiktspējas, personāla vai procesa specifikācijas, kuru vienota piemērošana ir atzīta par būtisku ieviešanai ATS sistēmās Eurocontrol dalībvalstīs. Eurocontrol standarts nedrīkst būt pretrunā ICAO standartiem, bet vajadzības gadījumā tam būtu jāpapildina tie. Izpilddispečers — dispečers, kas tieši sniedz norādījumus par savā uzraudzībā esošajiem lidojumiem. Šai kategorijai pieskaita arī dispečerus, kas nodrošina rajona radiolokācijas pakalpojumus. Izejas līmenis — lidojuma līmenis, kādā gaisakuģim koordinācijas gaitā atļauts šķērsot vadības nodošanas punktu. Izejas līmeni var papildināt ar šķērsošanas papildnosacījumiem, norādot līmeņu joslu, kurā lidojums būs augšupejošs/lejupejošs. Lidojuma plāns — konkrēta informācija par paredzamo gaisakuģa lidojumu vai lidojuma posmu, ko saņem gaisa satiksmes pakalpojumu struktūrvienības. Tajā ietilpst arī informācija par konkrētu lidojumu, kas iegūta no lidojuma plāna, kurš glabājas FDPS. "Ģenerēšana" — process ATC sistēmā, kura gaitā no datu bāzes (bāzēm) iegūst datus un sagatavo ziņojumu pārraidīšanai ATC saņēmējai struktūrvienībai. ICAO formāts — formāts, ko izmanto ATS ziņojumu pārraidei "zeme-zeme" un kurā lieto 1. norādē aplūkotos lauka tipus un atdalītājus. Līmenis — vispārējs apzīmējums, kas raksturo gaisakuģa atrašanos gaisā; šajā standartā terminā līmenis vai lidojuma līmenis ietilpst absolūtais augstums, ja tas tiek izmantots. Paziņošana — process, kura gaitā nododošā struktūrvienība pārraida datus saņēmējas struktūrvienības sistēmas atjaunināšanai, gatavojoties koordinācijas fāzei. Saņēmēja struktūrvienība — ATC struktūrvienība, kurai nosūtīts ziņojums. "Uzticamība" — plānotais pieejamības laiks procentos, kad ir pieejams šis pakalpojums. Pieprasītais lidojuma līmenis — lidojuma plānā lidojumam pieprasītais lidojuma līmenis. Pārskatīšana — labojumi datos, ko ATC nododošā struktūrvienība iepriekš nosūtījusi ATC saņēmējai struktūrvienībai. Šķērsošanas papildlīmenis - līmenis, kādā vai virs kāda vai arī kādā vai zem kāda gaisakuģim pēc lidojuma koordinācijas jāšķērso vadības nodošanas punkts. Papildlīmenis, ja tāds noteikts, ir izejas līmeņa sastāvdaļa. Sistēmas lidojuma plāns - informācija par konkrētu lidojumu, kas iegūta no lidojuma plāna, kurš glabājas FDPS. Transakcijas ilgums - laika intervāls pēc ziņojuma ierosināšanas, kurā veic tā pārraidi, sākotnējo apstrādi saņēmējā sistēmā, apstiprināšanas ziņojuma ģenerēšanu un pārraidi, kā arī tā atpazīšanu nododošajā sistēmā. Vadības nodošanas punkts - noteikts punkts, kas atrodas gaisakuģa lidojuma trajektorijā, kurā atbildību par ATS nodrošināšanu gaisakuģim nodod nākamajai ATC struktūrvienībai vai kontrolpunktam. Tam nav obligāti jāsakrīt ar koordinācijas punktu. Nodošanas fāze - lidojuma fāze pēc koordinācijas fāzes, kurā notiek sakaru nodošana. Nododošā struktūrvienība - ATC struktūrvienība, kas koordinācijas secībā atbild par lidojuma apkalpošanu pirms robežas un uzsāk koordinācijas fāzi ar nākamo struktūrvienību. Pārraidīšana - ziņojuma nodošana no vienas sistēmas citai. Struktūrvienība - gaisa satiksmes pakalpojumu struktūrvienība. Brīdinājums - ziņojums, kas parādās dispečerpunktā uz ekrānpults, ja nenostrādā automātiskā koordinēšana. 3.2. Simboli un saīsinājumi Šajā Eurocontrol standartā lieto šādus simbolus un saīsinājumus: ABI Iepriekšējs informatīvais ziņojums par robežas šķērsošanu ACC Lidojumu rajona GSV centrs ACP Apstiprināšanas ziņojums ACT Aktivizēšanas ziņojums ADEXP ATS datu apmaiņas atveide ATC Gaisa satiksmes vadība ATM Gaisa satiksmes pārvaldība ATS Gaisa satiksmes pakalpojumi CDN Koordinācijas ziņojums CNL Lidojuma plāna atcelšana COD SSR koda piešķiršanas ziņojums COF Frekvences maiņas ziņojums COP Koordinācijas punkts DED Eurocontrol EATCHIP attīstības direktorāts EATCHIP Eiropas ATC saskaņošanas un integrācijas programma ECAC Eiropas Civilās aviācijas konference ETO Aprēķinātais punkta pārlidošanas laiks ETOT Aprēķinātais pacelšanās laiks EWPD EATCHIP darba programmas dokuments FDPS Lidojuma datu apstrādes sistēma FRF Turpmākais lidojuma maršruts HMI Cilvēka — mašīnas saskarne HOP Pārņemšanas ierosinājuma ziņojums ICAO Starptautiskā civilās aviācijas organizācija INF Informatīvais ziņojums LAM Loģiskā apstiprinājuma ziņojums LoA Vienošanās dokuments MAC Koordinācijas atcelšanas ziņojums MAS Sakaru uzņemšana manuālajā režīmā NM Jūras jūdze OLDI Datu apmaiņa tiešsaistē ORCAM Izcelsmes reģionu kodu piešķiršanas metode PAC Iepriekšējas aktivizēšanas ziņojums RAP Ierosinātās aktivizēšanas saskaņošanas ziņojums REV Labojumu ziņojums RJC Koordinācijas atteikuma ziņojums ROF Frekvences maiņas pieprasījuma ziņojums RRV Ierosināto labojumu saskaņošanas ziņojums SBY Rezervstāves ziņojums SDM Papilddatu ziņojums SSR Sekundārais novērošanas radiolokators SYSCO Automatizēta koordinācija TI Nodošanas ierosināšana TIM Nodošanas ierosināšanas ziņojums TWR/APP Lidlauka GSV dispečerpunkts ("tornis") un pieejas lidojumu GSV 4. VISPĀRĪGĀS PRASĪBAS 4.1. Ievads Šajā iedaļā aplūkotas vispārējās ekspluatācijas prasības, kas nepieciešamas OLDI pakalpojumu īstenošanai starp ATC struktūrvienībām, kā arī dažādu izmantojamo ziņojumu tipu klasificēšanas noteikumi un darbības prasības. 4.2. Lidojumu datu apstrādes sistēmas prasības 4.2.1. Lidojumu datu bāze Struktūrvienības, kas izmanto šajā dokumentā aplūkotās iespējas, saņem datus no FDPS, kurā glabājas visa nepieciešamā informācija norādīto ziņojumu vizualizēšanai, apstrādei un sagatavošanai. Attiecībā uz jebkuru lidojumu galvenais datu avots ir gaisakuģa kapteiņa vai viņa uzdevumā iesniegtais lidojuma plāns. Pārējos datus iegūst lidojumu plānu apstrādes gaitā, ņemot vērā attiecīgās struktūrvienības apkārtējo vidi. 4.2.2. Darbība reālajā laikā OLDI procedūra ietver norises nododošajās ATC struktūrvienībās saistībā ar tādu darbību ierosināšanu, kas vajadzīgas, lai savlaicīgi iesniegtu datus nododošajam dispečeram un pārraidītu koordinācijas datus pārņēmējai struktūrvienībai. Šim nolūkam FDPS ir jāierosina darbības, kas paredz salīdzināt koordinēto pasaules laiku un piemērojamos laika parametrus ar konkrētu lidojuma maršruta punktu laika parametriem, kuri iegūti no lidojumu datu bāzes. 4.2.3. Datu komunikācijas spēja 4.2.3.1. FDPS ir jānodrošina lidojuma datu saņemšana un pārraidīšana šajā dokumentā noteiktajā ziņojuma formātā, izmantojot datu komunikācijas vidi, kas kalpo kā OLDI funkcijas nodrošinātāja. 4.2.3.2. Ieteikums. FDPS ir jābūt attīstīties spējīgai, lai to papildinātu ar jauniem ziņojumiem, ko varētu iekļaut turpmākajās standarta redakcijās. 4.2.3.3. Kas attiecas uz šajā dokumentā noteiktajām funkcionālajām prasībām, datu komunikācijas videi ir jānodrošina ātra un droša datu apmaiņa starp lietojumprogrammām: - garantējot nevainojamu OLDI ziņojumu pārraidi, un - atkarībā no vajadzības, uzraugot divpunktu savienojumus vai sakaru tīkla statusu. 4.2.3.4. FDPS ir jābrīdina dispečerpunkti par datu komunikācijas sistēmas atklātajām nesakritībām. 4.2.4. Lietojumfunkcijas 4.2.4.1. Sistēmām, ko izmanto OLDI pakalpojumu nodrošināšanai, ir jābūt gatavām automātiski saņemt, uzglabāt, apstrādāt, izvilkt un izsniegt vizualizēšanai, kā arī pārraidīt ar OLDI saistītos datus reālā laika režīmā. 4.2.4.2. FDPS ir: - jāuzrāda kārtējie ekspluatācijas dati, kas paredzēti šajā standartā OLDI darbībai, un kuru atjaunināšana notiek automātiski, manuāli ievadot datus vai izmantojot abus šos paņēmienus, - jānodrošina šādu sastāvdaļu izvilkšana no lidojuma plāna datu bāzes, - jāatpazīst nākamā ATC struktūrvienība lidojuma maršrutā. 4.2.4.3. Jāpanāk savstarpēja vienošanās par: - koordinācijas punktiem (COP), - atskaites punktiem, ko izmanto peilējuma un attāluma apzīmēšanai, nosakot COP taisnos posmos ārpus ATS maršruta (ja tādi ir). PIEZĪME. COP ne vienmēr sakrīt ar vadības nodošanas punktiem. 4.2.5. Cilvēka — mašīnas saskarne (HMI) 4.2.5.1. HMI ir jānodrošina: - OLDI ziņojumu un attiecīgo brīdinājumu operacionālā satura vizualizēšana tūlītējai reaģēšanai saistībā ar saņemtajiem ziņojumiem, - koordinācijas un vadības nodošanas brīdinājuma ziņojumu tālāknosūtīšana apkalpojošiem punktiem, kas atbild par attiecīgo lidojumu koordinēšanu. 4.2.5.2. ATC personāla rīcībā ir jābūt līdzekļiem, kas ļauj pārveidot datus, kuri nosaka ziņojumu operacionālo saturu saskaņā ar šā dokumenta prasībām. 4.2.5.3. HMI attiecīgi jāuzrāda, ka ziņojums tiek vai jau ir veiksmīgi pārraidīts. 4.2.5.4. Ja noteiktajā laikā pēc koordinācijas vai vadības nodošanas ziņojuma pārraidīšanas nesaņem apstiprinājumu, automātiski tiek sagatavots brīdinājums vai paziņojums attiecīgajam ATC vai tehniskajam punktam(-iem). 4.2.5.5. Šim brīdinājumam vai paziņojumam jābūt tādā formā, lai tas uzreiz piesaistītu attiecīgā dispečerpunkta uzmanību. 4.2.5.6. Ieteikums. ATC punktos, kas izmanto OLDI, HMI būtu jāparedz brīdinājums gadījumos, kad OLDI pakalpojumi nav pieejami. 4.2.6. Ziņojumu ierosināšana 4.2.6.1. Katrā sistēmā jāietver sistēmparametru kopa, kas automātiski nodrošina savlaicīgu OLDI ziņojumu ierosināšanu. 4.2.6.2. Ieteikums. Būtu jānodrošina koordinācijas ziņojuma pārraides manuāla uzsākšana pirms aprēķinātā pārraides laika. 4.2.6.3. Vienmēr jānodrošina automātiskā pārraides uzsākšana, ja pārraidi neuzsāk manuāli. 4.2.6.4. Sistēmai jāizmanto laika parametri, nosakot šādus rādītājus: - sagatavošanās laiku pirms pārraides, kad nododošajā struktūrvienībā uz ekrānpults parādās ziņojumu operacionālais saturs, - kopējo sagatavošanās laiku ziņojuma pārraidei vai, attiecīgi, laiku katrā COP, - laiku pēc ziņojuma pārraides, kurā ir jāsaņem apstiprinājums lietojumprogrammu līmenī (taimautu). 4.2.6.5. Ziņojums ir jāpārraida nekavējoties, ja vajadzīgā informācija kļūst pieejama vēlāk, nevis brīdī, kas faktiski paredzēts tās pārraidīšanai. Piemērs: Lidojums sākas GAT IFR posma punktā, kas atrodas tuvu robežai, kura būs vēlāk jāšķērso; ETO šajā punktā pārraida astoņas minūtes pirms COP, tātad ACT ziņojuma pārraidīšana šajā brīdī jau ir nokavēta, ņemot vērā attiecīgo laika parametru(-s); šis ziņojums ir jānosūta nekavējoties. 4.2.7. Ziņojumu saņemšana 4.2.7.1. ATC sistēmai ir jānodrošina: - OLDI ziņojumu saņemšana, - to automātiska apstrāde saskaņā ar šo standartu, - lidojuma datu sagatavošana saskaņā ar saņemto ziņojumu un nepieciešamo brīdinājumu parādīšanās, ja saņemtie dati ir pretrunīgi, - apstiprinājuma ziņojumu automātiska sagatavošana un pārraidīšana lietojumprogrammas līmenī. 4.2.7.2. Atkarībā no apstākļiem saņemšanas apstiprinājuma ziņojums (loģiskā apstiprinājuma ( LAM ), apstiprināšanas ( ACP ) vai rezervstāves ( SBY ) ziņojums) ir jāsagatavo un jāpārraida pēc attiecīgā ziņojuma apstrādes un apstrādes rezultātu uzrādīšanas vajadzīgajā dispečerpunktā (punktos). PIEZĪME. Sīki izstrādātie apstiprinājuma sagatavošanas nosacījumi atsevišķi norādīti katram ziņojumam. 4.3. Datu atjaunināšana, izmantojot novērošanas datus Ieteikums. Lai nodrošinātu laika datu provizorisko aprēķinu precizitāti, lidojumu plānu datu bāzes atjaunināšanai būtu jāizmanto informācija, kas iegūta, vērojot lidojumus ar radiolokatora vai citu novērošanas līdzekļu palīdzību. 4.4. OLDI datu reģistrēšana 4.4.1. Saturs Ikviena OLDI ziņojuma saturs un saņemšanas laiks ir jāreģistrē. 4.4.2. Tehniskais nodrošinājums Tehniski jānodrošina reģistrēto datu ieguve un vizualizēšana. 4.5. Pieejamība, uzticamība, datu drošība un datu integritāte 4.5.1. Pieejamība 4.5.1.1. OLDI pakalpojumiem starp divām saistītajām struktūrvienībām ir jābūt pieejamiem ierastās un maksimālās satiksmes plūsmas laikā. 4.5.1.2. Ieteikums. OLDI pakalpojumiem vajadzētu būt pieejamiem 24 stundas dienā. 4.5.1.3. Par visiem dīkstāves periodiem (un, tātad, paredzamo pieejamības laiku) savstarpēji jāvienojas abām saistītajām struktūrvienībām. 4.5.2. Uzticamība 4.5.2.1. Jebkuram OLDI savienojumam ir jāuzrāda vismaz 99,86 % uzticamība (tas nozīmē, ka dīkstāve nepārsniedz 12 stundas gadā, pamatojoties uz 24 stundu pieejamību diennaktī). 4.5.2.2. Ieteikums. Ja tas ir attaisnojams no ekspluatācijas viedokļa, jānodrošina vismaz 99,99 % uzticamība (tas nozīmē, ka dīkstāve nepārsniedz 52 minūtes gadā, pamatojoties uz 24 stundu pieejamību diennaktī). 4.5.3. Datu drošība Ieteikums. OLDI pakalpojumiem vajadzētu piemērot drošības paņēmienus (piem., piekļuves tiesības, avotu pārbaude) un, vajadzības gadījumā, veikt tīkla pārvaldīšanu. 4.5.4. Datu integritāte Atteices intensitāte lietojumsistēmas līmenī nedrīkst pārsniegt vienu pārraides kļūdu uz 2000 ziņojumiem. 4.6. Darbības novērtējums 4.6.1. Novērtēšanas laiks Katrai jaunai OLDI iekārtai, arī jaunai iekārtai jau esošajā savienojumā, pirms darbības uzsākšanas jāparedz novērtēšanas laiks, lai pārliecinātos par datu integritāti, precizitāti, efektivitāti, saderību ar ATC procedūrām un vispārējo drošību. PIEZĪME. Eurocontrol OLDI sekretariātā var saņemt informāciju par procedūru, kas atvieglo jaunu OLDI iekārtu novērtēšanu. 4.6.2. Darbības uzsākšanas datums Abām struktūrvienībām savstarpēji vienojoties, oficiāli nosaka darbības uzsākšanas datumu, kas nozīmē, ka novērtēšanas laiks ir beidzies. 5. ZIŅOJUMU KATEGORIJAS 5.1. Vispārējā daļa 5.1.1. Mērķis Šajā dokumenta iedaļā: - definē ziņojumu kategorijas, - nosaka transakciju ilguma ierobežojumus kategorijām, - nosaka obligātos un komplementāros ziņojumus, - iedala ziņojumu tipus kategorijās. 5.1.2. Ziņojumu kategorijas OLDI ziņojumus iedala šādās kategorijās: - 1. kategorija — sakaru nodošana, - 2. kategorija — koordinācija, - 3. kategorija — paziņošana. 5.2. Transakciju ilgums 5.2.1. Transakciju ilguma nosacījumi 5.2.1.1. Noteiktais transakciju ilgums ietver pārraidi, sākotnējo apstrādi saņēmējā struktūrvienībā, apstiprinājuma ziņojuma sagatavošanu, tā pārraidi un saņemšanu nododošajā struktūrvienībā. Tādēļ automātiskā apstiprinājuma ziņojumiem LAM un SBY nav piešķirta ziņojumu kategorija. 5.2.1.2. Maksimālais transakcijas ilgums dažādām ziņojumu kategorijām ir norādīts tabulā 5-1. Tabula 5-1 Maksimālais transakcijas ilgums Ziņojumu kategorija | 90 % | 99,8 % | 1 | 4 sek. | 10 sek. | 2 | 10 sek. | 25 sek. | 3 | 15 sek. | 45 sek. | 5.2.1.3. Katrai ziņojumu kategorijai vai tipam nosaka taimauta ilgumu. 5.2.1.4. Ja noteiktajā laikā pēc pārraides nav saņemts apstiprinājums, uzskata, ka ziņojums ir neveiksmīgi pārraidīts vai apstrādāts, un ir jānosūta brīdinājums saskaņā ar attiecīgo šā dokumenta iedaļu. 5.2.1.5. Ieteikums. Šajās trijās kategorijās taimautam nevajadzētu pārsniegt attiecīgi 12 sekundes, 30 sekundes un 60 sekundes. 5.3. Ziņojumu klasifikācija un sistematizācija 5.3.1. Ziņojumu klasifikācija — obligātie un komplementārie ziņojumi 5.3.1.1. Šajā dokumentā aplūkotos ziņojumus iedala obligātajos vai komplementārajos. 5.3.1.2. Ja aplūkojamā ziņojuma pārraidīšana (transmission, TX) ir obligāta (mandatory, M), ir jāparedz šādu ziņojumu pārraidīšanai vajadzīgā apstrāde. 5.3.1.3. Ja aplūkojamā ziņojuma saņemšana ir obligāta ( reception, REC ), ir jāparedz šādu ziņojumu saņemšanai vajadzīgā apstrāde. PIEZĪME. Izņēmuma gadījumos, kad starp divām struktūrvienībām ir vienvirziena satiksmes plūsma, obligātie ziņojumi var attiekties tikai uz vienu virzienu. 5.3.1.4. Ja aplūkojamā ziņojuma pārraidīšana ir komplementāra ( complementary, C ), ir jāparedz šādu ziņojumu pārraidīšanai vajadzīgā apstrāde, ja to pieprasa nosūtītāja struktūrvienība un pastāv savstarpēja vienošanās ar saņēmēju struktūrvienību. PIEZĪME. Komplementāros ziņojumus var izmantot vienā virzienā tikai saskaņā ar ekspluatācijas prasībām. 5.3.1.5. Ja aplūkojamā ziņojuma saņemšana ir komplementāra, ir jāparedz saņemšanai vajadzīgā apstrāde, ja pastāv abpusēja vienošanās par tā izmantošanu. 5.3.1.6. Tabulās 5-3 un 5-4 aplūkotās prasības piemēro tikai tad, ja ATC struktūrvienības abpusēji vienojušās attiecīgi izmantot dialoga procedūru, veicot koordināciju un/vai sakaru nodošanu. 5.3.2. Ziņojumu iedalījums kategorijās 5.3.2.1. Pamatprocedūras ziņojumu iedalījums kategorijās ir noteikts tabulā 5-2. 5.3.2.2. Citu dialoga procedūras koordinācijas ziņojumu iedalījums kategorijās ir noteikts tabulā 5-3. 5.3.2.3. Dialoga procedūras sakaru nodošanas ziņojumu iedalījums kategorijās ir noteikts tabulā 5-4. Tabula 5-2 Pamatprocedūras ziņojumi Ziņojuma tips | Saīsinājums | Kategorija | Pārraide | Saņemšana | Iepriekšēja informācija par robežas šķērsošanu | ABI | 3 | M | M | Aktivizēšana | ACT | 2 | M | M | Pārskatīšana | REV | 2 | C [1] | C [1] | Iepriekšēja aktivizēšana | PAC | 2 | C | C | Koordinācijas atcelšana | MAC | 2 | C | C | SSR koda piešķiršana | COD | 2 | C | C | Informatīvais | INF | 3 | C | C | Loģiskā apstiprinājuma ziņojums | LAM | | M | M | Tabula 5-3 Dialoga procedūra — koordinācijas fāzes ziņojumi (Papildus tabulai 5-2) Ziņojuma tips | Saīsinājums | Kategorija | Pārraide | Saņemšana | Ierosinātās aktivizēšanas saskaņošana | RAP | 2 | C | M | Ierosinātie labojumi | RRV | 2 | C | M | Koordinācija | CDN | 2 | M | M | Rezervstāve [2] | SBY | | M | M | Apstiprināšana | ACP | 2 | M | M | Koordinācijas atteikšana [3] | RJC | 2 | C | C | Tabula 5-4 Dialoga procedūra - nodošanas fāzes ziņojumi Ziņojuma tips | Saīsinājums | Kategorija | Pārraide | Saņemšana | Nodošanas ierosināšana | TIM | 1 | M | M | Papilddati | SDM | 1 | [4] | [4] | Pārņemšanas ierosinājums | HOP | 1 | M | M | Frekvences maiņa [5] | COF | 1 | C | M | Frekvences maiņas pieprasījums | ROF | 1 | C | M | Sakaru uzņemšana manuālajā režīmā [5] | MAS | 1 | C | M | 6. PAMATPROCEDŪRA — OBLIGĀTIE ZIŅOJUMI 6.1. Vispārējā daļa 6.1.1. Prasību apraksts Šajā iedaļā aplūkotas obligātās prasības OLDI pakalpojumu ieviešanai lietojumprogrammu līmenī. 6.1.2. Lietojums Struktūrvienības, kas lidojumu koordinēšanai izmanto OLDI, lieto šajā iedaļā aplūkotos ABI, ACT un LAM ziņojumus, izņemot gadījumus, kad abpusēji vienojas veikt koordināciju dialoga procedūrā, kura aplūkota šā dokumenta 8. iedaļā, ievērojot minētajā iedaļā noteiktos ACT un LAM ziņojumu lietošanas nosacījumus. 6.2. Iepriekšējs ziņojums par robežas šķērsošanu (ABI) 6.2.1. ABI ziņojuma mērķis ABI ziņojums atbilst šādām ekspluatācijas prasībām: - nodrošina trūkstošos lidojuma plāna datus, - sniedz iepriekšēju informāciju par robežas šķērsošanu un tās labojumus nākamajai ATC struktūrvienībai, - atjaunina lidojuma plāna pamatdatus, - palīdz savlaicīgi koriģēt radiolokatora ekrānā novērojamās ceļa līnijas, - atvieglo sektora noslogotības precīzu īstermiņa novērtēšanu. ABI kalpo kā paziņojums. 6.2.2. Ziņojuma saturs ABI ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - gaisakuģa identifikācijas indeksu, - SSR darba režīmu un kodu (ja dati ir pieejami), - izlidošanas lidlauku, - provizoriskos aprēķinus, - galamērķa lidlauku, - gaisa kuģu skaitu un tipu, - maršrutu (fakultatīvi), - citus lidojuma plāna datus (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 6.2.3. Lietošanas noteikumi 6.2.3.1. Vispārējā daļa 6.2.3.1.1. Izņemot 6.2.3.1.3. un 6.2.3.1.4. punktā paredzētos gadījumus, saistībā ar katru lidojumu, kam paredzēts šķērsot atbildības rajonu robežu, ir jānosūta viens vai vairāki ABI ziņojumi saskaņā ar OLDI procedūrām. 6.2.3.1.2. Nosūtīšanas gadījumā pēc ABI ziņojuma, jānosūta aktivizēšanas (ACT) vai ierosinātās aktivizēšanas saskaņošanas (RAP) ziņojums. 6.2.3.1.3. ABI ziņojums netiek sagatavots, ja ir jāsūta iepriekšējas aktivizēšanas (PAC) ziņojums. 6.2.3.1.4. Ieteikums. ABI pārraidīšana būtu jāaptur, ja nekavējoties vai savstarpēji saskaņotā laika sprīdī ir jāpārraida ACT vai RAP ziņojums. PIEZĪME. Šā ieteikuma mērķis ir izvairīties no mēģinājumiem saņēmējas struktūrvienības dažādos dispečerpunktos vienlaicīgi novērst nesakritības ABI un ACT ziņojumos, kas skar vienu un to pašu lidojumu. 6.2.3.1.5. Ir jānosūta izlabots ABI ziņojums, ja nav sagatavots nākamais ACT ziņojums un: - lidojuma maršruts ir izmainīts tādā veidā, ka COP iepriekšējā ABI ziņojumā vairs neatbilst īstenībai, - ielidošanas lidlauks ir nomainīts, vai - gaisakuģa tips ir nomainīts. 6.2.3.1.6. Ieteikums. Būtu jānosūta izlabots ABI ziņojums, ja nav sagatavots nākamais ACT ziņojums un izmaiņas skar kādu no šeit norādītajiem parametriem: - paredzēto robežas šķērsošanas līmeni, - paredzēto SSR kodu vadības nodošanas punktā, - ja paredzamais COP pārlidošanas laiks (ETO) atšķiras no iepriekšējā ABI ziņojumā norādītā laika vairāk, nekā tas noteikts vienošanās dokumentā (LoA), - jebkurus citus datus pēc savstarpējas vienošanās. 6.2.3.2. Datu apstrāde saņēmējā struktūrvienībā 6.2.3.2.1. ATC sistēmai, kas saņem ABI ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgajiem lidojuma plāna datiem. 6.2.3.2.2. Ja sasaiste ar lidojuma plānu neizdodas, saņēmējā sistēmā automātiski vai manuāli jāsastāda lidojuma plāns. 6.2.3.2.3. Ja sasaiste ar lidojuma plānu noris veiksmīgi, bet atklājas neatbilstība starp ziņojuma datiem un attiecīgajiem saņēmējas sistēmas datiem, kas prasa ieviest labojumus pēc nākamā ACT ziņojuma saņemšanas, šīs neatbilstības novēršana jāuztic attiecīgajam dispečerpunktam. 6.2.3.3. Pārraides ilguma parametri 6.2.3.3.1. Ziņojums ir jāpārraida dažas minūtes pirms paredzētā COP pārlidošanas laika, kā to nosaka parametri. 6.2.3.3.2. ABI ģenerēšanas parametrs(-i) jāiekļauj attiecīgo ATC struktūrvienību LoA. 6.2.3.3.3. Ieteikums. ABI ģenerēšanas parametriem (parametram) būtu jābūt: - mainīgiem saskaņā ar LoA nosacījumiem, - atsevišķi noteiktiem katram COP. 6.2.4. ABI saņemšanas apstiprinājums 6.2.4.1. Saņemšanas apstiprināšana ABI ziņojuma saņemšanu jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. PIEZĪME. LAM ziņojums jāsagatavo neatkarīgi no rezultātiem, kas gūti mēģinājumā veikt sasaisti ar lidojuma plānu. 6.2.4.2. Saņemšana nav apstiprināta Ieteikums. Ja nesaņem LAM ziņojumu, kas apstiprina ABI ziņojuma saņemšanu, uzraudzības punktā būtu jāparādās brīdinājumam. 6.2.5. Piemēri "Air 2000" 253, Boeing 757, lido no Maltas uz Birmingemu, paredzamais ierašanās laiks BNE VOR 1221 UTC (pēc koordinētā universālā laika), lidojums norit FL350, patiesais ātrums gaisā 480 mezglu, paredzētais maršruts UB4 BNE UB4 BPK UB3 HON, sakaru nodrošināšanai izmanto A7012, pieprasa līmeni FL390. Tālāk piedāvātie piemēri ietver līdzvērtīgus ABI ziņojumus, kas nosūtīti no Reimsas ACC uz Londonas ACC. 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. Aktivizēšanas ziņojums (ACT) 6.3.1. ACT ziņojuma mērķis ACT ziņojums atbilst šādām ekspluatācijas prasībām: - tas aizstāj mutiskos robežas šķērsošanas aprēķinus, pirms vadības nodošanas automātiski nodrošinot lidojuma datu pārraidīšanu no vienas ATC struktūrvienības nākamajai, - tas precizē lidojuma plāna pamatdatus ATC saņēmējā struktūrvienībā ar jaunāko informāciju, - tas atvieglo lidojuma datu sadali vajadzīgajiem dispečerpunktiem ATC saņēmējā struktūrvienībā un to vizualizēšanu, - tas paātrina pazīšanas signāla/koda korelācijas parādīšanos uz ekrānpults ATC saņēmējā struktūrvienībā, - tas paziņo vadības nodošanas nosacījumus ATC saņēmējai struktūrvienībai. 6.3.2. Ziņojuma saturs ACT ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - gaisakuģa identifikācijas indeksu, - SSR darba režīmu un kodu, - izlidošanas lidlauku, - provizoriskos aprēķinus, - galamērķa lidlauku, - gaisakuģu skaitu un tipu, - maršrutu (fakultatīvi), - citus lidojuma plāna datus (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 6.3.3. Lietošanas noteikumi 6.3.3.1. Vispārējā daļa 6.3.3.1.1. ACT ziņojums jānosūta saistībā ar prasībām atbilstošajiem lidojumiem, kas šķērso robežu, izņemot 6.3.3.1.10. punktā paredzētos gadījumus. 6.3.3.1.2. ACT ziņojums automātiski jāsagatavo un jāpārraida LoA noteiktajā laikā, ja tas nav izdarīts jau agrāk manuālajā režīmā. 6.3.3.1.3. Ieteikums. ATC personālam būtu jānodrošina iespēja uzsākt ATC ziņojumu pārraidi pirms aprēķinātā pārraides laika. 6.3.3.1.4. Pārraidāmā ACT ziņojuma operacionālajam saturam ir jāparādās uz ekrānpults dispečerpunktā, kas atbild par lidojuma koordināciju, pirms tas tiek pārraidīts. 6.3.3.1.5. Ieteikums. Attiecībā uz 6.3.3.1.4. punktu, uz ekrānpults kopā ar ACT ziņojuma saturu būtu jāparādās arī aprēķinātajam laikam, kad tas automātiski jāpārraida. 6.3.3.1.6. ACT ziņojumā jāiekļauj jaunākā informācija par lidojumu, ieskaitot paredzētos robežas šķērsošanas nosacījumus. 6.3.3.1.7. Par ACT ziņojuma pārraidīšanu jāpaziņo attiecīgajam dispečerpunktam. 6.3.3.1.8. Uzreiz pēc LAM saņemšanas ACT ziņojuma dati kļūst operacionāli saistoši abām ATC struktūrvienībām. Koordinētie nodošanas nosacījumi un LAM saņemšanas fakts ir jādara zināmi nododošās struktūrvienības ATC personālam. 6.3.3.1.9. Uzskata, ka saņēmēja struktūrvienība ir apstiprinājusi ACT ziņojumā iekļautos nodošanas nosacījumus, ja saņēmēja struktūrvienība neierosina to grozījumu koordinēšanu. 6.3.3.1.10. Vēl vienu ACT ziņojumu tam pašam koordinācijas partnerim drīkst nosūtīt tikai tad, ja iepriekšējais ziņojums tika ATCelts ar MAC. 6.3.3.1.11. Maršruts un citi lidojuma plāna dati ir jāiekļauj, ja pastāv abpusēja vienošanās. 6.3.3.2. Datu apstrāde saņēmējā struktūrvienībā 6.3.3.2.1. ATC sistēmai, kas saņem ACT ziņojumu, ir jāmēģina veikt tā sasaisti ar atbilstīgo lidojuma plānu. 6.3.3.2.2. Ja atrod atbilstīgu lidojuma plānu, un ziņojums nesatur pretrunas, kas var traucēt pareizu apstrādi: - operacionālais saturs jāiekļauj lidojuma plānā, - nepieciešamie dati pēc vajadzības jāizvada apkalpojošajā ATC un citos punktos, - ir jānosūta LAM. 6.3.3.2.3. Ja atbilstīgs lidojuma plāns nav atrodams vai atklājas pretrunas, kas traucē pareizu ziņojuma apstrādi: - ja izdodas noteikt sektoru, kas atbild par lidojuma vadības pārņemšanu: - šajā sektorā uz ekrānpults jāparādās ziņojuma operacionālajam saturam, - ir jānosūta LAM, - ir jāsastāda lidojuma plāns, - visos pārējos gadījumos LAM nav jāsūta. 6.3.3.3. Pārraidīšanas parametri 6.3.3.3.1. Ziņojums jāpārraida cik vien ātri iespējams, iestājoties agrākajam no termiņiem, kas noteikti, izmantojot šādus kritērijus: - saskaņā ar parametru aprēķināto minūšu skaitu pirms paredzamā COP pārlidošanas laika, - laiku, kad gaisakuģis atrodas abpusēji saskaņotajā attālumā no COP. 6.3.3.3.2. ACT sagatavošanas parametrs(-i) ir jāiekļauj attiecīgo ATC struktūrvienību LoA. 6.3.3.3.3. ACT sagatavošanas parametram(-iem) ir jābūt mainīgiem atkarībā no LoA nosacījumiem. 6.3.3.3.4. Ieteikums. ACT sagatavošanas parametri būtu jānosaka atsevišķi katram COP. 6.3.3.3.5. Norādītajiem parametriem jāparedz pietiekams laiks, lai: - nododošā struktūrvienība varētu precizēt lidojuma nodošanas līmeni, ņemot vērā paredzētos nosacījumus COP, un - saņēmēja struktūrvienība varētu apstrādāt ACT, kā arī sagatavot un pārraidīt LAM, neliedzot nododošajai struktūrvienībai iespēju mutiski veikt koordināciju un pārņēmējai struktūrvienībai attiecīgi rīkoties, ja datu apmaiņa cieš neveiksmi. 6.3.4. ACT saņemšanas apstiprinājums 6.3.4.1. Saņemšanas apstiprināšana ACT ziņojuma saņemšanu ir jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 6.3.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina ACT ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojuma koordinēšanu, jāparādās brīdinājumam. 6.3.5. Piemēri Šeit aplūkotie piemēri papildina ABI ziņojuma piemērus, kas iekļauti 6.2. punktā; visi dati sakrīt, izņemot COP ETO, kas norādītajā ACT ziņojumā ir 1226. 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. Loģiskā apstiprinājuma ziņojums (LAM) 6.4.1. LAM ziņojuma mērķis LAM kalpo kā pārraidīta ziņojuma saņemšanas un nodrošināšanas apstiprinājums, ko saņēmēja struktūrvienība nosūta sūtītājai struktūrvienībai. LAM apstrāde nodrošina ATC personālu nododošajā struktūrvienībā ar: - brīdinājumu, ja netiek atsūtīts saņemšanas apstiprinājums, - informāciju, ka apstiprināmais ziņojums ir saņemts, veiksmīgi apstrādāts, nesatur kļūdas, noglabāts atmiņā un vajadzības gadījumā ir pieejams attiecīgajam dispečerpunktam (punktiem). 6.4.2. Ziņojuma saturs LAM ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 6.4.3. Lietošanas noteikumi 6.4.3.1. Vispārējā daļa 6.4.3.1.1. LAM nosūtīšanas noteikumi ir norādīti šā dokumenta iedaļās, kurās aplūko katra ziņojuma apstrādi. 6.4.3.1.2. LAM ziņojums jāsagatavo un jāpārraida bez cilvēka iejaukšanās. 6.4.3.1.3. LAM ziņojums nedrīkst aizstāt tehniskos ziņojumus, kas vajadzīgi, lai nodrošinātu datu pārraides integritāti. 6.4.3.1.4. LAM ziņojums ir jāsagatavo un jāpārraida nekavējoties, lai tiktu ievērots apstiprināmā ziņojuma transakcijas ilguma ierobežojums. 6.4.3.1.5. Izņemot ABI ziņojumus, pārraidošai ATC sistēmai ir jāinformē dispečers, kas atbild par koordināciju, ja LAM ziņojums nav saņemts šādiem brīdinājumiem noteiktajā termiņā. 6.4.4. LAM saņemšanas apstiprinājums LAM ziņojumam nav nepieciešams apstiprinājums. 6.4.5. Piemēri 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. PAMATPROCEDŪRA — KOMPLEMENTĀRIE ZIŅOJUMI 7.1. Vispārējā daļa 7.1.1. Prasību apraksts Šajā iedaļā aplūko pamatprocedūras iespējas, kas ir pieejamas papildus tām, kuras aplūkotas 6. iedaļā "Pamatprocedūra — obligātie ziņojumi". 7.1.2. Izmantošana 7.1.2.1. Par visu šajā iedaļā aplūkoto iespēju izmantošanu ir abpusēji jāvienojas pirms to ieviešanas. 7.1.2.2. Ja šāda vienošanās pastāv, ir jāievēro šajā iedaļā aplūkotie noteikumi. 7.2. Iepriekšējas aktivizēšanas ziņojums (PAC) 7.2.1. PAC ziņojuma mērķis PAC ziņojums atbilst šādām ekspluatācijas prasībām: - lidojuma izziņošana un pirmslidojuma koordinācija, ja lidojuma laiks no izlidošanas līdz COP ir īsāks, nekā būtu nepieciešams, lai iekļautos saskaņotajos ACT ziņojuma pārraides ilguma parametros, - lidojuma izziņošana un pirmslidojuma koordinācija, ko pirms izlidošanas veic vietējā (lidlauka/pieejas lidojumu dispečerkontroles) struktūrvienība, kopā ar nākamo struktūrvienību, kas pārņems lidojuma vadību, - trūkstošo lidojuma plāna datu iegūšana, ja sākotnēji izdalītie lidojuma plāna dati satur pretrunas, - vajadzības gadījumā SSR koda piešķiršanas pieprasīšana struktūrvienībai, kurai adresēta iepriekš minētā izziņošana/koordinācija. 7.2.2. Ziņojuma saturs PAC ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu (fakultatīvi), - gaisakuģa identifikācijas indeksu, - SSR darba režīmu un kodu, - izlidošanas lidlauku, - paredzamo pacelšanās laiku vai provizoriskos aprēķinus, - galamērķa lidlauku, - gaisakuģa tipu, - maršrutu (fakultatīvi), - citus lidojuma plāna datus (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 7.2.3. Lietošanas noteikumi 7.2.3.1. Vispārējā daļa 7.2.3.1.1. Saistībā ar katru lidojumu, kam jāšķērso atbildības rajonu robeža, ir jānosūta vismaz viens PAC ziņojums, ja laika sprīdis no izlidošanas līdz COP neļauj vajadzīgajā brīdī nosūtīt ACT ziņojumu. 7.2.3.1.2. Saistībā ar katru izlidojošo reisu, kam nepieciešama izziņošana vai koordinācija, lidlauka/pieejas lidojumu dispečerkontroles struktūrvienībai ir jānosūta vismaz viens PAC ziņojums nākamajai struktūrvienībai. 7.2.3.1.3. Ieteikums. Lai izmantotu PAC/LAM ziņojumus starp struktūrvienībām, attiecīgajām TWR/APP sistēmām būtu jānodrošina iespēja ievadīt un pārraidīt "start-up", "push-back", "taxi" vai tamlīdzīgu informāciju, ko var izmantot ETOT noteikšanai CPO ETO aprēķiniem un PAC ziņojuma pārraides uzsākšanai. 7.2.3.1.4. Atkarībā no abpusējas vienošanās, ziņojumā ir jāiekļauj: - paredzamais pacelšanās laiks, vai - provizoriskie aprēķini. 7.2.3.1.5. Ja saskaņā ar abpusēju vienošanos ir ietverta atsauce uz ziņojumu: - tajā jāiekļauj saistībā ar šo lidojumu nosūtītā pirmā PAC ziņojuma reģistrācijas numurs, - kas jānorāda otrajā un turpmākajos PAC ziņojumos. 7.2.3.1.6. Vajadzības gadījumā abpusēji jāvienojas par koda pieprasījuma procedūras izmantošanu. 7.2.3.1.7. Izlabots PAC ziņojums ir jānosūta, ja pirms izlidošanas ir spēkā kāds no šādiem nosacījumiem: - lidojuma maršruts ir izmainīts tā, ka iepriekšējā ziņojumā minētais COP vairs neatbilst īstenībai, - ir nomainīts gaisakuģa tips, - iepriekšējā PAC ziņojumā konstatēts, ka ir nepareizi norādīts galamērķa lidlauks. 7.2.3.1.8. Ieteikums. Izlabots PAC ziņojums būtu jānosūta tad, ja šeit norādītie dati atšķiras pirms izlidošanas no datiem iepriekšējā PAC ziņojumā: - lidojuma līmenis (pēc provizoriskiem aprēķiniem, ja tādi ir), - paredzētais SSR kods vadības nodošanas punktā, - paredzamais pacelšanās laiks vai COP ETO atšķiras vairāk, nekā tas ir abpusēji saskaņots, - ir izmainīti jebkuri citi dati, uz kuriem attiecas abpusēja vienošanās. 7.2.3.2. Datu apstrāde saņēmējā struktūrvienībā 7.2.3.2.1. ATC sistēmai, kas saņem PAC ziņojumu, ir jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 7.2.3.2.2. Ja atrod atbilstīgu lidojuma plānu, un ziņojums nesatur pretrunas, kas var traucēt pareizu apstrādi: - operacionālo saturu iekļauj lidojuma plānā, - nepieciešamie dati pēc vajadzības jāizvada apkalpojošajā ATC punktā un citos punktos, - ir jānosūta LAM. 7.2.3.2.3. Ja atbilstīgs lidojuma plāns nav atrodams vai atklājas pretrunas, kas traucē pareizu ziņojuma apstrādi: - ja izdodas noteikt sektoru, kas atbild par lidojuma vadības pārņemšanu: - šajā sektorā uz ekrānpults jāparādās ziņojuma operacionālajam saturam, - ir jānosūta LAM, - ir jāsastāda lidojuma plāns, - visos pārējos gadījumos LAM nav jāsūta. 7.2.3.2.4. Otrā un turpmāko PAC ziņojumu datiem ir jāaizstāj iepriekšējā ziņojuma dati. 7.2.3.2.5. Ja PAC ziņojums satur pieprasījumu piešķirt SSR kodu un pakļaujas pareizai apstrādei, kā tas izklāstīts jau iepriekš 7.2.3.2.2. punktā, papildus LAM ziņojumam ir jānosūta arī COD ziņojums. PIEZĪME. Tā kā koda piešķiršana nav iespējama bez sīkākas informācijas lidojuma plānā par maršrutu, šis dokuments nesatur prasību, ka saņēmējai struktūrvienībai ir jānosūta COD ziņojums, ja šādi lidojuma dati nav pieejami. Tas neliedz šādos apstākļos nosūtīt ziņojumu, ja konkrētā vietā pastāv tāda iespēja, un ir panākta abpusēja vienošanās par šo procedūru. 7.2.3.3. Pārraides ilguma parametri Pārraides ilguma parametru nepiemēro, jo ziņojumu nosūta pēc manuāli ievadīta ziņojuma, kurā norāda gaidāmo reisa izlidošanu. 7.2.4. PAC saņemšanas apstiprinājums 7.2.4.1. Saņemšanas apstiprināšana Ziņojumi, kas ir jānosūta, atbildot uz PAC ziņojumu, aplūkoti jau iepriekš punktā 7.2.3.2. 7.2.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina PAC ziņojuma saņemšanu, ATC struktūrvienības punktā, kurš atbild par lidojuma koordināciju ar nākamo struktūrvienību, jāparādās brīdinājumam. 7.2.4.3. LAM nav saņemts Ja LAM nav saņemts, koordinācija jāuzsāk mutiski. 7.2.4.4. Nav saņemts COD ziņojums 7.2.4.4.1. Ja nav saņemts COD ziņojums kā atbilde uz PAC ziņojumā iekļauto koda pieprasījumu, attiecīgajā punktā ir jāparādās brīdinājumam. 7.2.4.4.2. Kad ir jāizmanto koda pieprasījuma procedūra, abpusēji vienojas par piemērojamo taimauta ilgumu. 7.2.5. Piemēri 7.2.5.1. Paredzamais pacelšanās laiks un koda pieprasījums 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. Laiks 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. Labojumu ziņojums (REV) 7.3.1. REV ziņojuma mērķis REV ziņojumu izmanto, lai pārraidītu iepriekš ar ACT ziņojumu nosūtīto koordinācijas datu labojumus, ar nosacījumu, ka labojumu dēļ netiek nomainīta pārņēmēja struktūrvienība. 7.3.2. Ziņojuma saturs REV ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu (fakultatīvi), - gaisakuģa identifikācijas indeksu, - SSR darba režīmu un kodu (fakultatīvi), - izlidošanas lidlauku, - provizoriskos aprēķinus, - koordinācijas punktu (fakultatīvi), - galamērķa lidlauku, - maršrutu (fakultatīvi), - citus lidojuma plāna datus (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 7.3.3. Lietošanas noteikumi 7.3.3.1. Vispārējā daļa 7.3.3.1.1. Struktūrvienībai, ar ko pašreiz notiek lidojuma koordinācija, izmantojot aktivizēšanas ziņojumu, var nosūtīt vienu vai vairākus REV ziņojumus. 7.3.3.1.2. Izmaiņas skar šādas sastāvdaļas: - COP ETO, - vadības nodošanas līmeni(-ņus), - SSR kodu. 7.3.3.1.3. REV ziņojums ir nosūtāms, ja: - COP ETO atšķirības, salīdzinot ar iepriekšējo ziņojumu, pārsniedz abpusēji saskaņoto lielumu, kas noapaļots līdz tuvākajam veselam skaitlim, - izmaiņas skar nodošanas līmeni(-ņus) vai SSR kodu. 7.3.3.1.4. Ja pastāv abpusēja vienošanās, REV ziņojums ir jānosūta, kad notikušas izmaiņas: - COP, - maršrutā - citos lidojuma plāna datos (ICAO 8., 10. un 18. lauka dati). PIEZĪME. Ekspluatācijas noteikumi var paredzēt, ka labojumi, kas izdarīti pēc ACT ziņojuma, iepriekš jākoordinē attiecīgo struktūrvienību starpā. 7.3.3.1.5. Ja pastāv abpusēja vienošanās, REV ziņojumā ir jāiekļauj atsauce uz ziņojumu. 7.3.3.1.6. Iekļaujot atsauci uz ziņojumu, tajā jānorāda iepriekšējā ACT ziņojuma reģistrācijas numurs. 7.3.3.1.7. Uzskata, ka ATC saņēmēja struktūrvienība ir apstiprinājusi REV ziņojumā iekļautos nodošanas nosacījumus, ja ATC saņēmēja struktūrvienība neierosina to grozījumu koordinēšanu. 7.3.3.2. Labojumu ziņojumu formatēšana 7.3.3.2.1. ICAO formāts Visi labojumu ziņojumi satur 3., 7., 13., 14. un 16. lauku. Minētajos laukos novieto šāda veida labojumus: - COP ETO vai nodošanas līmeņa(-u) izmaiņas ir jāiekļauj, iestrādājot izlabotos datus 14. laukā, - SSR koda izmaiņas ir jāiekļauj 7. laukā, - maršruta izmaiņas kopā ar COP izmaiņām ir jāiekļauj 14. un 15. lauka datos, kas ietverti 22. lauka formātā aiz pirmajiem pieciem laukiem. Šajos ziņojumos jāiekļauj divi 14. lauki, pirmais no kuriem satur tikai sastāvdaļu a), proti COP, caur kuru līdz šim tika koordinēts lidojums. Šādu izmaiņu koordinācijas noteikumi, ieskaitot tiešos maršruta virzienus, ir izklāstīti B pielikumā "Īpašas prasības maršruta datu apstrādei", - 8., 10. un 18. lauka izmaiņas ir jāiekļauj kā 22. lauka dati aiz pirmajiem pieciem laukiem. 7.3.3.2.2. ADEXP formāts Visos labojumu ziņojumos ADEXP formātā ir jābūt šādiem primārajiem laukiem: TITLE REFDATAARCID ADEP ADES. Spēkā ir šādi noteikumi: - COP ETO vai nodošanas līmeņa(-u) izmaiņas ir jāiekļauj, norādot izmainītos datus primārajā laukā COORDATA, - maršruta izmaiņas kopā ar COP izmaiņām ir jāiekļauj primārajos laukos COORDATA un ROUTE. Šādos ziņojumos jāiekļauj primārais lauks COP, kurā ietilpst koordinācijas punkts, caur kuru līdz šim tika koordinēts lidojums. Šādu izmaiņu koordinācijas noteikumi, ieskaitot tiešos maršruta virzienus, ir izklāstīti B pielikumā, - SSR koda izmaiņas ir jānorāda, iekļaujot tos primārajā laukā SSRCODE, - citu lidojuma plāna datu labojumi ir jāiekļauj, ietverot vajadzīgo(-s) primāro(-s) lauku(-s), kā tas noteikts citiem lidojuma plāna datiem A pielikumā. Ja labojumu ziņojums tiek nosūtīts tikai SSR koda un/vai citu lidojuma plāna datu koordinēšanai, COORDATA vietā tajā ir jāiekļauj primārais lauks COP. 7.3.3.2.3. SSR kods SSR darba režīmu un kodu iekļauj REV ziņojumā tikai tad, ja ir jākoordinē SSR koda maiņa. 7.3.3.3. Datu apstrāde saņēmējā struktūrvienībā 7.3.3.3.1. Saņemot ACT ziņojumu saistībā ar konkrētu lidojumu no tās pašas ATC struktūrvienības, ATC sistēmai, kas saņem REV ziņojumu, jāmēģina veikt sasaisti ar attiecīgo lidojuma plānu. 7.3.3.3.2. Ja atrod atbilstīgu lidojuma plānu, un ziņojums nesatur pretrunas, kas var traucēt pareizu apstrādi: - operacionālais saturs jāiekļauj lidojuma plānā, - nepieciešamie dati pēc vajadzības jāizvada apkalpojošajā ATC punktā un citos punktos. 7.3.3.4. Pārraides uzsākšana 7.3.3.4.1. REV ziņojumu nosaka apstākļi, un tas jāpārraida tūlīt pēc attiecīgo datu ievades vai precizēšanas. 7.3.3.4.2. Nedrīkst ieviest izmaiņas ar REV ziņojuma palīdzību, gaisakuģim sasniedzot noteiktu laika intervālu/attālumu no vadības nodošanas punkta. Par šo laika intervālu un attālumu abpusēji jāvienojas. 7.3.3.4.3. Ieteikums. REV parametri būtu jānosaka atsevišķi katram COP. 7.3.3.5. ATC saņēmējas struktūrvienības nomaiņa REV ziņojumu nedrīkst izmantot, ja lidojuma datu pārskatīšana noved pie ATC saņēmējas struktūrvienības nomaiņas (skatīt "Koordinācijas ATCelšanas ziņojumu"). 7.3.4. REV saņemšanas apstiprinājums 7.3.4.1. Saņemšanas apstiprināšana Ja REV ziņojumu: - var sasaistīt ar lidojuma plānu saņēmējā sistēmā, tā saņemšanu apstiprina, nosūtot LAM ziņojumu, - nevar sasaistīt ar lidojuma plānu saņēmējā sistēmā, LAM ziņojums nav jāsūta. 7.3.4.2. Saņemšana nav apstiprināta 7.3.4.2.1. Ja nav saņemts LAM ziņojums, kas apstiprina REV ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojumu koordināciju, jāparādās brīdinājumam. 7.3.4.2.2. Nesaņemot LAM, nododošajai ATC vienībai ir jāierosina mutiski labojumi. 7.3.5. Piemēri 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. Koordinācijas atcelšanas ziņojums (MAC) 7.4.1. MAC ziņojuma mērķis MAC ziņojumu lieto, lai darītu zināmu saņēmējai struktūrvienībai, ka tiek atcelta iepriekš veiktā lidojuma koordinēšana vai izziņošana. MAC neaizstāj ICAO noteikto atcelšanas (CNL) ziņojumu, un tādēļ to neizmanto lidojuma plāna pamatdatu dzēšanai. 7.4.2. Ziņojuma saturs MAC ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu (fakultatīvi), - gaisakuģa identifikācijas indeksu, - izlidošanas lidlauku, - koordinācijas punktu, - galamērķa lidlauku, - koordinācijas statusu un pamatojumu (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 7.4.3. Lietošanas noteikumi 7.4.3.1. Vispārējā daļa 7.4.3.1.1. MAC ziņojumu nosūta struktūrvienībai, ar kuru līdz šim tika veikta lidojuma koordinācija, izmantojot ACT vai RAP ziņojumu, ja ir spēkā kāds no šiem nosacījumiem: - paredzētais līmenis vadības nodošanas punktā atšķiras no iepriekšējā ziņojumā iekļautā līmeņa, kā dēļ nomainās koordinācijas secības nākamā struktūrvienība, - ir mainīts lidojuma maršruts, kā dēļ nomainās koordinācijas secības nākamā struktūrvienība, - ir atcelts lidojuma plāns sūtītājas struktūrvienības sistēmā, un pastāvošā koordinācija vairs nav spēkā, - no iepriekšējās struktūrvienības ir saņemts MAC ziņojums saistībā ar lidojumu. 7.4.3.1.2. Nosūtot MAC ziņojumu sakarā ar lidojuma līmeņa vai maršruta maiņu, vajadzības gadījumā izziņošanu un/vai koordināciju veic ar jauno koordinācijas secības struktūrvienību. 7.4.3.1.3. MAC ziņojums ir jānosūta tad, ja ar PAC ziņojuma palīdzību ir atcelta izlidojošā reisa koordinācija. 7.4.3.1.4. Ieteikums. MAC ziņojums būtu jānosūta, ja kādu 7.4.3.1.1. punktā minēto iemeslu dēļ ir atcelta iepriekš veiktā lidojuma izziņošana (ABI ziņojums) vai ja lidojums ir aizkavējies ceļā un nav iespējams automātiski veikt jaunus provizoriskos aprēķinus. 7.4.3.1.5. Atsauce uz ziņojumu ir jāiekļauj, ja pastāv abpusēja vienošanās. 7.4.3.1.6. Iekļaušanas gadījumā atsaucē uz ziņojumu jāietver saistībā ar lidojumu nosūtītā un apstiprinātā pēdējā ABI, PAC vai ACT ziņojuma reģistrācijas numurs. 7.4.3.1.7. Koordinācijas punkts atbilst COP, caur kuru līdz šim veikta lidojuma izziņošana vai koordinēšana. 7.4.3.1.8. Ieteikums. MAC ziņojumā būtu jānorāda statuss, kurā jāatsāk koordinēšana vai izziņošana, un atcelšanas pamatojums. 7.4.3.1.9. Norādot statusu un pamatojumu, ir jābūt vienai no šādām kombinācijām: - ja saņēmēja struktūrvienība vairs nav nākamais koordinācijas partneris: - norāda statusu INI (sākotnējais statuss), - tam var būt šāds pamatojums: - TFL, ja mainīts vadības nodošanas līmenis, - RTE, ja mainīts maršruts, - CSN, ja mainīts pazīšanas signāls, - CAN, ja notikusi atcelšana, - OTH, jebkurš cits iemesls vai ja iemesls nav zināms, - kad ir spēkā kāds no šeit minētajiem nosacījumiem: - atcelta koordinācija, ko veica izmantojot iepriekšējo PAC vai ACT ziņojumu (kas pārveidots ar jebkuru nākamo REV ziņojumu), bet sagaidāms, ka lidojumu vadīs tā pati struktūrvienība jaunā koordinācijas secībā, vai - pēc ABI ziņojuma pārraidīšanas lidojums ir gaidīšanas statusā uz nenoteiktu laiku, un sagaidāms, ka atkarībā no apstākļiem uz to attieksies pārskatītais ABI vai ACT ziņojums: - norāda statusu NTF (izziņošana), - tam var būt šāds pamatojums: - DLY, ja tā ir aizkavēšanās, - HLD, ja tā ir gaidīšana, - OTH, jebkurš cits iemesls vai ja iemesls nav zināms. 7.4.3.1.10. Ja lidojums ir jāizziņo vai jākoordinē no jauna: - atkarībā no apstākļiem ir jānosūta jauns paziņojums un/vai koordinācijas ziņojum, - lidojuma plāna pamatdatus, kas glabājas ATC saņēmējā struktūrvienībā, neskar MAC ziņojums, - sistēmai arī turpmāk jāspēj pareizi apstrādāt jaunu paziņojumu un/vai koordinācijas ziņojumu no iepriekšējās nododošās struktūrvienības vai citas koordinācijas secības struktūrvienības. 7.4.3.2. Datu apstrāde saņēmējā struktūrvienībā ATC saņēmējas struktūrvienības dispečerpunkts (punkti), kas saņem informāciju par lidojumu, ir jābrīdina par atcelšanu. 7.4.4. MAC saņemšanas apstiprinājums 7.4.4.1. Saņemšanas apstiprināšana 7.4.4.1.1. Ja MAC ziņojumu var sasaistīt ar lidojuma plānu saņēmējā sistēmā un to var apstrādāt, ir jānosūta LAM ziņojums, apstiprinot tā saņemšanu. 7.4.4.1.2. Ja MAC ziņojumu nevar sasaistīt ar lidojuma plānu saņēmējā sistēmā vai to nevar apstrādāt, LAM ziņojums nav jāsūta. 7.4.4.2. Saņemšana nav apstiprināta 7.4.4.2.1. Ja ATC koordinācija tiek atcelta, un LAM ziņojums nav saņemts, ATC punktā, kas atbild par koordināciju, ir jāparādās brīdinājumam. 7.4.4.2.2. Šādos gadījumos nododošajai ATC struktūrvienībai mutiski jāatceļ koordinācija. 7.4.5. Piemēri Amsterdamas ACC nosūta ABI ziņojumu Briseles ACC saistībā ar lidojumu HOZ3188, paredzētais līmenis FL190; vēlāk pilots pieprasa atļauju pacelties līdz FL270, un atļauja tiek saņemta, tādējādi lidojums turpinās Māstrihtas, nevis Briseles gaisa telpā. Piemēri 7.4.5.1 a) un 7.4.5.2 a) rāda, kā no Amsterdamas uz Briseli nosūtītais MAC ziņojums izskatās gan ICAO, gan ADEXP formātā. Uz Māstrihtu tiek nosūtīts ABI un, vēlāk, ACT ziņojums, bet dažas minūtes pirms sasniegt COP gaisakuģis atgriežas Amsterdamas lidostā, un sūtītājas struktūrvienības sistēma lidojuma plānu atceļ; uz Māstrihtu nosūta MAC ziņojumu, kas parādīts piemēros (7.4.5.1 b) un 7.4.5.2 b). 7.4.5.1. ICAO a) (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL) b) (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN) 7.4.5.2. ADEXP a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN 7.5. SSR koda piešķiršanas ziņojums (COD) 7.5.1. COD ziņojuma mērķis 7.5.1.1. Kodu piešķiršanas metode attiecībā uz izcelsmes reģionu (ORCAM) nodrošina gaisakuģim iespēju sazināties ar secīgām struktūrvienībām līdzdalības rajonā, izmantojot vienu un to pašu kodu. Ja kodu nepiešķir centralizēti, piemēram, ACC, var rasties vajadzība piešķirt lidostām noteiktu skaitu atsevišķu SSR kodu. Šāda kodu piešķiršana ir visai izšķērdīga. 7.5.1.2. COD ziņojums atbilst šādai ekspluatācijas prasībai: viena gaisa satiksmes pakalpojumu struktūrvienība uz pieprasījumu izsniedz A veida SSR kodu citai struktūrvienībai attiecībā uz konkrētu lidojumu. Fakultatīva iespēja ļauj izsniedzējai struktūrvienībai iekļaut lidojuma maršrutu, ja pastāv abpusēja vienošanās. 7.5.2. Ziņojuma saturs COD ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu (fakultatīvi), - gaisakuģa identifikācijas indeksu, - SSR darba režīmu un kodu, - izlidošanas lidlauku, - galamērķa lidlauku, - maršrutu (fakultatīvi). PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 7.5.3. Lietošanas noteikumi 7.5.3.1. Vispārējā daļa 7.5.3.1.1. COD ziņojums jāsagatavo un jāpārraida automātiski, atbildot uz saņemtajā ziņojumā iekļauto koda piešķiršanas pieprasījumu. 7.5.3.1.2. SSR kods sakrīt ar lidojumam piešķirto kodu. 7.5.3.1.3. Ja nepastāv individuāls kods, ir jānorāda piesātinājuma kods, kas noteikts aeronavigācijas plānā Eiropas reģionam. 7.5.3.1.4. Ja pastāv abpusēja vienošanās, jāiekļauj atsauce uz ziņojumu, norādot tā ziņojuma reģistrācijas numuru, atbildot uz kuru ir sagatavots COD ziņojums. 7.5.3.1.5. Ja pastāv abpusēja vienošanās, ir jānorāda maršruts. 7.5.3.1.6. Uzskata, ka struktūrvienība, saņemot COD ziņojumu, tādējādi apstiprina SSR kodu. 7.5.3.2. Datu apstrāde saņēmējā struktūrvienībā 7.5.3.2.1. Ja ziņojums nesatur pretrunas, kas var traucēt tā pareizu apstrādi, ir jānosūta LAM. 7.5.3.2.2. Ja nevar sasaistīt ziņojumu ar lidojuma plānu vai tajā atklājas pretrunas, kas var traucēt pareizu ziņojuma apstrādi, LAM nav jāsūta. 7.5.3.2.3. Maršruta dati, tos iekļaujot, nevar būt iemesls tam, ka netiek nosūtīts LAM, ja vien tie atbilst A pielikumā izklāstītajām prasībām attiecībā uz formātu. 7.5.3.3. Pārraides ilguma parametri Pārraides ilguma parametrus nepiemēro, jo COD ziņojumu nosūta, saņemot ziņojumu ar pieprasījumu piešķirt SSR kodu. 7.5.4. COD saņemšanas apstiprinājums 7.5.4.1. Saņemšanas apstiprināšana COD ziņojuma saņemšana jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 7.5.4.2. Saņemšana nav apstiprināta Ja nesaņem LAM ziņojumu, kas apstiprina COD ziņojuma saņemšanu, attiecīgajā punktā jāparādās brīdinājumam. 7.5.5. Piemēri 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. Informatīvais ziņojums (INF) 7.6.1. INF ziņojuma mērķis 7.6.1.1. INF ziņojumu izmanto, lai sniegtu ziņas par konkrētiem lidojumiem iestādēm, kas tieši nepiedalās koordinēšanā starp divām secīgām ATC struktūrvienībām lidojuma maršrutā. 7.6.1.2. INF ziņojumus var izmantot, lai nodrošinātu šādas iestādes ar ziņojumu kopijām un paziņotu tām koordinācijas nosacījumus, par kurām dialoga gaitā vienojušies dispečeri. INF ziņojumus šim nolūkam var sagatavot nododošās vai saņēmējas struktūrvienības sistēmā. 7.6.1.3. Šo ziņojumu var arī izmantot, lai sniegtu iestādei ziņas par jebkuru punktu lidojuma maršrutā. 7.6.1.4. Šis formāts ļauj pārraidīt sākotnējus datus, labojumus un paziņot par atcelšanu. 7.6.2. Ziņojuma saturs INF ziņojums satur šādas datu vienības šajā dokumentā aplūkotajā ziņojuma formātā: - ziņojuma tipu, - ziņojuma numuru, - visu to operacionālo datu kopijas, kuri iekļauti sākotnējā ziņojumā vai radušies koordinācijas rezultātā, - pieminētā ziņojuma tipu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 7.6.3. Lietošanas noteikumi 7.6.3.1. Ziņojumu tipi Tas, kāda ziņojuma tipa (ziņojumu tipu) kopija(-s) būtu jāiekļauj INF ziņojumā, ir atkarīgs no lietotāju vajadzībām un sūtītājas struktūrvienības spējām. Parasti abpusēji vienojas par ziņojuma tipu (ziņojumu tipiem) un to lietošanas noteikumiem. 7.6.3.2. Ziņojumu adresāti Vienam vai vairākiem adresātiem var nosūtīt vienu vai vairākus INF ziņojumus saistībā ar vienu un to pašu lidojumu. 7.6.3.3. Operacionālais saturs INF ziņojuma operacionālajam saturam jābūt kādā no esošo ziņojumu formātā. 7.6.3.4. Ieteikumi 1. Nosacījumus, kas pārraidīti ar kādu sākotnēju dialoga ziņojumu (piem., ACT, RAP, REV, RRV ziņojumu), drīkst mainīt vai noraidīt, kamēr turpinās dialogs. Sūtītājai struktūrvienībai būtu jābūt gatavai pārraidīt galīgi saskaņotos koordinācijas nosacījumus 2. INF ziņojums būtu jānosūta nekavējoties vai brīdī, kas atkarīgs no COP sasniegšanas laika, par ko abpusēji vienojas ar saņēmēju iestādi. 7.6.4. INF saņemšanas apstiprinājums Ieteikumi 1. INF ziņojuma saņemšanu var apstiprināt atkarībā no koordinācijas partnera, sagatavojot un pārraidot LAM ziņojumu. 2. Atkarībā no ieinteresēto struktūrvienību abpusējas vienošanās, ja nav saņemts LAM ziņojums, kas apstiprina INF ziņojuma saņemšanu, attiecīgajā punktā būtu jāparādās brīdinājumam. 7.6.5. Piemēri Gaisakuģis B747 ar pazīšanas zīmi BAW011, kas lido no EGLL uz OMDB lidojuma līmenī FL290, pieprasa FL410, paredzamā ierašanās Koksy (KOK) VOR 1905, uztvērējraidītāja frekvence A5437, tālākais lidojums caur UG1 un UB6. No Londonas uz Māstrihtu nosūtīts ACT ziņojums saistībā ar šo lidojumu. No Londonas nosūtīta kopija struktūrvienībai ar apzīmējumu IT. Šeit ir aplūkojami INF ziņojuma paraugi. 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. DIALOGA PROCEDŪRA — KOORDINĀCIJA 8.1. Vispārējā daļa 8.1.1. Ievads 8.1.1.1. Dialoga procedūra nodrošina dispečeriem sazināšanās un apspriešanās iespējas koordinācijas fāzē un sazināšanās iespējas vadības nodošanas fāzē. 8.1.1.2. Šajā iedaļā aplūkoti ziņojumi, ko lieto dialoga procedūras koordinācijas fāzē, saskaņojot vadības nodošanas nosacījumus. Nodošanas fāzes ziņojumi, kad notiek lidojuma vadības pārņemšana, aplūkoti 9. iedaļā "Dialoga procedūra — sakaru nodošana". 8.1.1.3. Abu šo fāžu procedūras ir savstarpēji neatkarīgas; tās var izmantot katru atsevišķi vai kopā. 8.1.1.4. Ieviesti vairāki papildu ziņojumi, un abiem partneriem nodrošinātas iespējas uzsākt dialogu. 8.1.1.5. Dialoga procedūra koordinācijas fāzē ļauj atšķirt: - vadības nodošanas gadījumus, kas ir saskaņā ar LoA un kurus var automātiski, un - gadījumus, kuri nosūtāmi saņēmējas struktūrvienības dispečeriem, kas lemj par to apstiprināšanu. 8.1.1.6. Šī procedūra arī ļauj pārraudzīt LoA interpretāciju abās sistēmās un atklāt jebkuras nesaskaņas to starpā. 8.1.2. Filtrs 8.1.2.1. Vispārējā daļa 8.1.2.1.1. Dialoga procedūra koordinācijas fāzē paredz, ka sistēmām ir jānosaka, vai vadības nodošana ir saskaņā ar LoA. 8.1.2.1.2. Šādu atbilstības pārbaudes mehānismu šajā dokumentā dēvē par "filtru". Filtra datu bāzē vajadzības gadījumā jābūt šādiem datiem: - saskaņotiem koordinācijas punktiem, - pieļaujamiem (vai nepieļaujamiem) lidojuma līmeņiem, kas var būt arī sasaistīti ar koordinācijas punktiem, - izlidošanas lidlaukiem, - galamērķiem, - saskaņotiem tiešajiem maršrutiem, - laika un/vai attāluma ierobežojumiem attiecībā uz COP, pēc kura visi koordinācijas ziņojumi uzskatāmi par nestandarta ziņojumiem, - jebkuriem citiem nosacījumiem saskaņā ar abpusējo vienošanos. 8.1.2.1.3. Visus šā saraksta datus var dažādi kombinēt, piemērojoties sarežģītākiem apstākļiem. 8.1.2.1.4. Šā dokumenta 8. iedaļā termins "standarta nosacījumi" nozīmē "saskaņā ar LoA", un termins "nestandarta nosacījumi" nozīmē "nav saskaņā ar LoA". Ja abpusēji nevienojas citādi, nododošās struktūrvienības, nosūtot koordinācijas ziņojumus, kuros, kā zināms, aprakstīti standarta nosacījumi, izmanto citus ziņojuma tipus, kas atšķiras no ziņojumiem, kuros aprakstīti nestandarta nosacījumi. 8.1.2.2. Apstrāde nododošajā struktūrvienībā 8.1.2.2.1. Nododošajā struktūrvienībā ar filtra palīdzību pārbauda vadības nodošanas nosacījumus, kas nosūtāmi pārņēmējai struktūrvienībai. 8.1.2.2.2. Ieteikums. Ja konstatē, ka vadības nodošanas nosacījumi neatbilst standartam, šim faktam vajadzētu pievērst nododošā dispečera uzmanību, kuram tie jāapstiprina vai jāpārskata. 8.1.2.3. Apstrāde pārņēmējā struktūrvienībā 8.1.2.3.1. Visi ACT un REV ziņojumi ir jāpārbauda ar filtra palīdzību. 8.1.2.3.2. Ja pārbaudē konstatē, ka saņemtie nodošanas nosacījumi neatbilst standartam, tos nodod dispečeram lēmuma pieņemšanai, citādi tie automātiski jāapstiprina. 8.1.2.4. Filtru sinhronizācija 8.1.2.4.1. Dažādu ziņojumu izmantošana vadības nodošanas standarta un nestandarta nosacījumiem ļauj atpazīt jebkuras pretrunas standarta nosacījumos nododošās un pārņēmējas struktūrvienības sistēmās. 8.1.2.4.2. Konstatējot vadības nodošanas nestandarta nosacījumus pārņēmējas struktūrvienības ziņojumā, ko izmanto tikai nodošanas koordinēšanai standarta gadījumos, tas norāda uz abu filtru nesakritību. Šāda nesakritība būtu jānovērš, lai nodrošinātu efektīvu dialoga procedūras norisi. 8.1.3. Ziņojumu secība 8.1.3.1. Vispārējā daļa 8.1.3.1.1. Ir jāievēro daži noteikumi, lai pārliecinātos, ka koordinācija ir pabeigta, pirms notiek jebkura labojumu vai sakaru nodošanas ziņojumu apmaiņa, un lai nepieļautu, ka abu struktūrvienību dispečeri vienlaicīgi nāk klajā ar priekšlikumiem saistībā ar vienu un to pašu lidojumu. 8.1.3.1.2. ATC struktūrvienībai ir jāpārraida labojumu (REV vai RRV) ziņojums vai jāapstiprina tā saņemšana tikai pēc lidojuma koordinācijas, tas ir, kad ar LAM vai ACP ziņojumu pabeidz ACT vai RAP dialogu. 8.1.3.1.3. Tikai pārņēmēja struktūrvienība ir tiesīga pārraidīt CDN ziņojumus. 8.1.3.1.4. CDN ziņojumus drīkst pārraidīt un apstiprināt tikai: - dialoga ietvaros, kas uzsākts pēc aktivizēšanas (ACT, RAP) vai labojumu (REV vai RRV) ziņojuma saņemšanas, vai - beidzoties lidojuma plāna koordinācijai minētajam lidojumam. 8.1.4. Vienlaicīgu ziņojumu apstrāde 8.1.4.1. Vispārēja daļa 8.1.4.1.1. Struktūrvienība, kas iesaistīta lidojuma koordinācijas vai nodošanas ziņojumu apmaiņā, nedrīkst uzsākt šā lidojuma koordinācijas vai nodošanas ziņojumu turpmāku apmaiņu ar to pašu struktūrvienību, kamēr nav saņemts LAM, ACP vai RJC ziņojums vai nav beidzies taimauts. 8.1.4.1.2. Var gadīties, ka CDN ziņojuma nosūtīšana sakrīt ar REV, RRV vai MAC ziņojumu, ko sūta nododošā struktūrvienība saistībā ar to pašu lidojumu. Šādu situāciju var konstatēt nododošā struktūrvienība, ja CDN pienāk pirms pārraidītā koordinācijas ziņojuma apstiprinājuma, un pārņēmēja struktūrvienība, ja nododošās struktūrvienības ziņojums pienāk pirms CDN apstiprinājuma. Šajā gadījumā CDN saņemšana nav jāapstiprina un REV, RRV vai MAC ziņojums nav jāapstrādā. 8.1.5. Atteikuma ziņojumu apstrāde RJC ziņojums noslēdz dialogu starp sistēmām. Jāuzsāk jauna starpsistēmu koordinācija, vajadzības gadījumā veicot koordināciju arī telefoniski. 8.1.6. Operacionālais atbildes taimauts 8.1.6.1. Vispārējā daļa 8.1.6.1.1. Atbildot uz dispečeriem nododamiem ziņojumiem, nosūtītājos un saņēmējos punktos ir jāpiemēro taimauta mehānisms. 8.1.6.1.2. Par taimauta ilgumu abpusēji jāvienojas. 8.1.6.1.3. Beidzoties taimautam nododošajā struktūrvienībā, nododošajam dispečeram jāsaņem brīdinājums, kas norāda uz to, ka ir jāuzsāk telefoniska koordinācija. 8.1.6.1.4. Ieteikumi 1. Kad taimauts nododošajā struktūrvienībā tuvojas beigām, ATC punktā pārņēmējā struktūrvienībā, kas atbild par lidojumu, būtu jāparādās brīdinājumam. 2. Pārraidot brīdinājumu, būtu jāņem vērā atbildes pārraides ilgums. 8.1.6.1.5. Sistēmām ir jānodrošina to atbilžu apstrāde, kas saņemtas beidzoties taimautam. 8.1.7. Izmantošana 8.1.7.1. Dialoga procedūras skar divas fāzes, proti, koordināciju un vadības nodošanu. Veicot dialogu, katrā fāzē izmanto dažādus ziņojumus, atšķiras arī nepieciešamais transakciju ilgums. Koordinācijas ziņojumus atveido ICAO un ADEXP formātā, sakaru nodošanas ziņojumus tikai ADEXP formātā. 8.1.7.2. Prasību minimums attiecībā uz HMI atšķiras koordinācijas un vadības nodošanas dialogā: - vadības nodošanas dialogs galvenokārt skar vadības kontroles funkciju un prasa ātrdarbīgu un lietotājdraudzīgu HMI, - koordinācijas dialogs nav tik steidzami risināms, un tādēļ tas neparedz tik stingras prasības attiecībā uz HMI. 8.1.7.3. Dialoga procedūra jāīsteno, izmantojot vienu no šeit piedāvātajiem variantiem: - dialoga procedūra koordinācijas fāzē kopā ar abpusēji saskaņotiem komplementārajiem ziņojumiem (7. un 8. iedaļa), - koordinācijas pamatprocedūra un dialoga procedūra vadības nodošanas fāzē (6., 7. un 9. iedaļa), - dialoga procedūra koordinācijas un vadības nodošanas fāzē kopā ar jebkuriem abpusēji saskaņotiem komplementāriem koordinācijas ziņojumiem (7., 8. un 9. iedaļa). Iepriekšējs ziņojums par robežas šķērsošanu ir jānosūta jebkurā gadījumā. 8.1.7.4. Par izraudzīto īstenošanas variantu abpusēji jāvienojas. 8.2. Aktivizēšanas ziņojums (ACT) 8.2.1. ACT ziņojuma mērķis ACT ziņojuma mērķis aplūkots 6.3.1. punktā. ACT ziņojumu dialoga procedūrā izmanto, lai izpildītu šīs prasības, ja lidojuma nodošanas nosacījumi atbilst standartam un nododošajam dispečeram nav vajadzīgs pārņēmēja dispečera apstiprinājums lidojumam. 8.2.2. Ziņojuma saturs ACT ziņojuma saturam dialoga procedūrā jābūt saskaņā ar ACT ziņojuma aprakstu 6.3.2. punktā. 8.2.3. Lietošanas noteikumi 8.2.3.1. Vispārējā daļa 8.2.3.1.1. Lietošanas noteikumi saskan ar 6.3. punktā aplūkotajiem ACT lietošanas noteikumiem, izņemot īpašos noteikumus, kas aplūkoti šajā punktā. 8.2.3.1.2. ACT ziņojums ir jānosūta saistībā ar lidojumu, kura nodošanas nosacījumi atbilst standartam, un nododošajam dispečeram nav vajadzīgs pārņēmēja dispečera apstiprinājums. PIEZĪME. Pretējā gadījumā ir jānosūta RAP ziņojums (skatīt 8.3. punktu "Ierosinātās aktivizēšanas saskaņošanas ziņojums"). 8.2.3.1.3. Ieteikums. Saņemot koordinācijas atteikuma (RJC) ziņojumu kā atbildi uz ACT ziņojumu, būtu jāuzsāk jauna koordinācijas procedūra. 8.2.3.2. Datu apstrāde saņēmējā struktūrvienībā 8.2.3.2.1. Ziņojumu pārbauda ar filtra palīdzību, lai pārliecinātos, ka piedāvātie nosacījumi atbilst standartam. 8.2.3.2.2. Ziņojums ir jāapstrādā kā RAP ziņojums, ja: - konstatē, ka nodošanas nosacījumi neatbilst standartam, - sistēmā nevar atrast atbilstīgu lidojuma plānu, un pieejamā informācija nav pietiekama, lai noteiktu nodošanas nosacījumu atbilstību vai neatbilstību standartam. 8.2.3.2.3. ACT ziņojumi, kas atbilst standartam, ir jāapstrādā saskaņā ar 6.3.3.2. punktu. 8.2.3.2.4. Ieteikums. Ja konstatē, ka nodošanas nosacījumi ACT ziņojumā neatbilst standartam, pastāv filtru nesakritība starp abām sistēmām. Tam, ka ACT ziņojums neatbilst standartam, ir jāpievērš pārraudzības personāla uzmanība, lai novērstu šo nesakritību. 8.2.4. ACT saņemšanas apstiprinājums 8.2.4.1. Saņemšanas apstiprināšana 8.2.4.1.1. Dialoga procedūrā ACT ziņojuma saņemšana ir jāapstiprina, nosūtot: - LAM, ja konstatē, ka nodošanas nosacījumi atbilst standartam, - SBY ziņojumu visos pārējos gadījumos. 8.2.4.1.2. Saņemot LAM, ACT ziņojuma operacionālais saturs kļūst saistošs abām ATC struktūrvienībām. 8.2.4.1.3. Ja pastāv abpusēja vienošanās, LAM vietā var izmantot ACP, lai norādītu, ka pārņēmēja struktūrvienība ir apstiprinājusi ACT, kurā nodošanas nosacījumi atbilst standartam. 8.2.4.2. Saņemšana nav apstiprināta Ja ACT ziņojuma saņemšana nav apstiprināta, ATC punktā, kas atbild par lidojuma koordināciju, jāparādās brīdinājumam. 8.3. Ierosinātās aktivizēšanas apstiprināšanas ziņojums (RAP) 8.3.1. RAP ziņojuma mērķis Papildus tam, kas izklāstīts 6.3. punktā attiecībā uz ACT ziņojumu, RAP ziņojums vēl atbilst šādām ekspluatācijas prasībām: - nodrošina nododošajam dispečeram iespēju nosūtīt apstiprināšanai pārņēmējam dispečeram lidojumus, kuru nodošanas nosacījumi neatbilst standartam, - vajadzības gadījumā nodrošina nododošajam dispečeram iespēju piespiedu kārtā nosūtīt apstiprināšanai pārņēmējam dispečeram konkrēta lidojuma nodošanas nosacījumus, kas atbilst standartam. 8.3.2. Ziņojuma saturs RAP ziņojumā jāietver tie paši dati, kas aplūkoti saistībā ar ACT ziņojumu (6.3. punkts), tajā var fakultatīvi iekļaut arī šādu informāciju: - manuālās nosūtīšanas pamatojumu (iespējams tikai ADEXP formātā). 8.3.3. Lietošanas noteikumi 8.3.3.1. Vispārējā daļa 8.3.3.1.1. RAP ziņojums ir nosūtāms ACT ziņojuma vietā, ja lidojumi, kas šķērso robežu, atbilst kādam no šeit minētajiem nosacījumiem: - nododošā sistēma noteikusi, ka nodošanas nosacījumi neatbilst standartam, - nododošais dispečers norādījis, ka nodošanas nosacījumi ir jānodod pārņēmējam dispečeram apstiprināšanai. 8.3.3.1.2. Pārraidāmā RAP ziņojuma operacionālajam saturam, pirms tas tiek pārraidīts, jāparādās uz ekrānpults dispečerpunktā, kas atbild par lidojuma koordināciju. 8.3.3.1.3. Ieteikums. Laikam, kad automātiski jāpārraida RAP ziņojums, būtu jāparādās uz ekrānpults kopā ar tā saturu. 8.3.3.1.4. Par RAP ziņojuma pārraidīšanu jāpaziņo attiecīgajam dispečerpunktam. 8.3.3.2. Datu apstrāde saņēmējā struktūrvienībā 8.3.3.2.1. ATC sistēmai, kas saņem RAP ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 8.3.3.2.2. Ja atrod atbilstīgu lidojuma plānu, un ziņojums nesatur pretrunas, kas var traucēt pareizu apstrādi: - operacionālais saturs ir jānodod pārņēmējam dispečeram apstiprināšanai, - ir jānosūta SBY ziņojums. 8.3.3.2.3. Ieteikums. Būtu jānorāda arī tālāknosūtīšanas iemesls (nestandarta nosacījumi vai manuāla nodošana). 8.3.3.2.4. Ja nevar veikt ziņojuma sasaisti ar lidojuma plānu vai atklājas pretrunas, kas traucē pareizu ziņojuma apstrādi: - šajā sektorā uz ekrānpults jāparādās ziņojuma operacionālajam saturam, un - jānosūta SBY ziņojums, un - jāsastāda lidojuma plāns. 8.3.3.2.5. Visos pārējos gadījumos ziņojuma saņemšana nav jāapstiprina. 8.3.3.3. Manuāla palaišana 8.3.3.3.1. Kad to izmanto, lai piespiedu kārtā nosūtītu pārņēmējam dispečeram apstiprināšanai ierosināto koordināciju, nodošanas nosacījumiem atbilstot standartam, nododošais dispečers manuāli uzsāk RAP ziņojumu un uzreiz pārraida to. 8.3.3.3.2. Ieteikums. RAP ziņojuma manuāla palaišana pirms aprēķinātā pārraides laika būtu pieļaujama dispečerpunktā, kas atbild par lidojuma koordināciju. 8.3.3.4. Automātiskās pārraides ilguma parametri Laika intervāls/attālums, kādā pirms robežas automātiski jāpārraida RAP ziņojumi, sakrīt ar ACT ziņojumu parametriem. 8.3.4. RAP saņemšanas apstiprinājums 8.3.4.1. Saņemšanas apstiprināšana Ziņojuma saņemšana jāapstiprina, sagatavojot un pārraidot SBY ziņojumu. 8.3.4.2. Saņemšana nav apstiprināta Ja nav saņemts SBY ziņojums, kas apstiprina RAP ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojumu koordināciju, jāparādās brīdinājumam. 8.3.5. Operacionālā atbilde uz RAP Pārņēmējs dispečers nodošanas nosacījumus var apstiprināt, noraidīt vai piedāvāt atbildes priekšlikumu. 8.3.5.1. Apstiprināšana 8.3.5.1.1. Ja pārņēmējs dispečers nolemj apstiprināt ierosinātos nodošanas nosacījumus, ir jānosūta ACP ziņojums. 8.3.5.1.2. Uzreiz pēc ACP ziņojuma saņemšanas RAP ziņojuma dati kļūst operacionāli saistoši abām ATC struktūrvienībām. Koordinētie nodošanas nosacījumi un ACP saņemšanas fakts jādara zināmi nododošajam dispečeram. 8.3.5.2. Atbildes priekšlikums Ja pārņēmējs dispečers nolemj piedāvāt savus nodošanas nosacījumus, ir jānosūta CDN ziņojums. 8.3.5.3. Ieteikums. Ja pārņēmējs dispečers nolemj noraidīt ierosinātos nodošanas nosacījumus, būtu jānosūta RJC ziņojums. Tādā gadījumā būtu jāuzsāk jauns koordinācijas process. PIEZĪME. Kas attiecas uz ieteikumu 8.3.5.3. punktā, jaunā koordinācija visbiežāk notiek ar citu struktūrvienību. 8.3.6. Piemēri 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. Labojumu ziņojums (REV) 8.4.1. REV ziņojuma mērķis REV ziņojuma mērķis ir aplūkots 7.3.1. punktā. REV ziņojumu dialoga procedūrā izmanto, lai izpildītu šīs prasības, ja lidojuma nodošanas nosacījumi atbilst standartam un nododošajam dispečeram nav vajadzīgs pārņēmēja dispečera apstiprinājums lidojumam. 8.4.2. Ziņojuma saturs REV ziņojuma saturam jābūt saskaņā ar REV ziņojuma aprakstu 7.3.2. punktā. 8.4.3. Lietošanas noteikumi 8.4.3.1. Vispārējā daļa 8.4.3.1.1. Struktūrvienībai, ar ko pašreiz notiek lidojuma koordinācija, izmantojot aktivizēšanas vai RAP ziņojumu, var nosūtīt vienu vai vairākus REV ziņojumus. 8.4.3.1.2. REV ziņojumi saistībā ar lidojumiem, kuru nodošanas nosacījumi atbilst standartam un kuri nododošajam dispečeram nav jānodod pārņēmējam dispečeram apstiprināšanai, ir jānosūta saskaņā ar 7.3.3.1. punktā izklāstītajiem nosacījumiem. 8.4.3.2. Pārraides uzsākšana REV ziņojums ir jāpārraida nekavējoties, tiklīdz atklājas, ka ir izmainīti koordinācijas dati, kas koordinējami saskaņā ar aprakstu 7.3.3. punktā. 8.4.3.3. Datu apstrāde saņēmējā struktūrvienībā 8.4.3.3.1. Ja atbilstīgu lidojuma plānu atrod jau koordinētā stāvoklī, un ziņojums nesatur pretrunas, kas varētu traucēt pareizu ziņojuma apstrādi: - REV ziņojuma saņemšana ir jāapstiprina, - visos pārējos gadījumos ziņojuma saņemšana nav jāapstiprina. 8.4.3.3.2. Nodošanas nosacījumi ir jāpārbauda, lai pārliecinātos, ka tie atbilst standartam. 8.4.3.3.3. Ja nodošanas nosacījumi neatbilst standartam, tie jānosūta pārņēmējam dispečeram apstiprināšanai. 8.4.3.3.4. Ja konstatē, ka nodošanas nosacījumi atbilst standartam, tie jāiekļauj lidojuma plānā un nepieciešamie dati pēc vajadzības jāizvada apkalpojošajā ATC punktā un citos punktos. 8.4.3.3.5. Ieteikums. Ja konstatē, ka nodošanas nosacījumi REVziņojumā neatbilst standartam, pastāv filtru nesakritība starp divām sistēmām. Tam, ka REV ziņojums neatbilst standartam, ir jāpievērš pārraudzības personāla uzmanība, lai novērstu šo nesakritību. 8.4.4. REV saņemšanas apstiprinājums 8.4.4.1. Saņemšanas apstiprināšana 8.4.4.1.1. Ja REV ziņojuma saņemšana ir jāapstiprina, jānosūta: - LAM ziņojums, ja konstatē, ka nodošanas nosacījumi atbilst standartam, - SBY ziņojums, ja konstatē, ka nodošanas nosacījumi neatbilst standartam. 8.4.4.1.2. Saņemot LAM, REV ziņojuma operacionālais saturs kļūst saistošs abām ATC struktūrvienībām. 8.4.4.1.3. Ja pastāv abpusēja vienošanās, LAM vietā var izmantot ACP, lai paziņotu, ka pārņēmēja struktūrvienība ir apstiprinājusi REV, kurā ietvertie nodošanas nosacījumi atbilst standartam. 8.4.4.2. Saņemšana nav apstiprināta Ja nav saņemts REV ziņojuma apstiprinājums, ATC punktā, kas atbild par lidojumu koordināciju, jāparādās brīdinājumam. 8.4.5. Operacionālā atbilde uz REV Tā kā REV ziņojums kalpo tādu nodošanas nosacījumu paziņošanai, kas atbilst standartam, pārņēmējas struktūrvienības sistēma to parasti apstiprina. Ja ar pārņēmējas struktūrvienības filtra palīdzību konstatē, ka nodošanas nosacījumi neatbilst standartam, ziņojumu ir jāapstrādā kā RRV ziņojumu. 8.5. Ierosināto labojumu saskaņošanas ziņojums (RRV) 8.5.1. RRV ziņojuma mērķis RRV ziņojumam ir jānodrošina iepriekš nosūtīto un saskaņoto nodošanas nosacījumu pārskatīšana šādos gadījumos: - ja labojumu ziņojumā ierosinātie nodošanas nosacījumi neatbilst standartam, - ja ierosinātie labojumi atbilst standartam, bet nododošais dispečers vēlas nodod labojumus pārņēmējam dispečeram apstiprināšanai. 8.5.2. Ziņojuma saturs RRV ziņojuma saturam ir jābūt saskaņā ar REV ziņojuma aprakstu (7.3.2. punkts), un tajā var fakultatīvi iekļaut šādu informāciju: - manuālās nosūtīšanas pamatojumu (iespējams tikai ADEXP formātā). 8.5.3. Lietošanas noteikumi 8.5.3.1. Vispārējā daļa REV ziņojuma vietā jānosūta vismaz viens RRV ziņojums saistībā ar katru datu pārskatīšanu, ja: - nododošā sistēma noteikusi, ka vadības nodošanas nosacījumi neatbilst standartam, vai - nododošais dispečers norādījis, ka nodošanas nosacījumi ir jānodod pārņēmējam dispečeram apstiprināšanai. RRV izmantošana ir fakultatīva. 8.5.3.2. Pārraides uzsākšana RRV ziņojums jāpārraida nekavējoties, tiklīdz konstatē, ka koordinācijas dati ir izmainīti, vai manuāli uzsākot pārraidi. 8.5.3.3. Datu apstrāde saņēmējā struktūrvienībā 8.5.3.3.1. Ja atbilstīgu lidojuma plānu atrod jau koordinētā stāvoklī, un ziņojums nesatur pretrunas, kas varētu traucēt pareizu ziņojuma apstrādi: - RRV ziņojuma saņemšana ir jāapstiprina, - visos pārējos gadījumos ziņojuma saņemšana nav jāapstiprina. 8.5.3.3.2. Ierosinātajiem nodošanas nosacījumiem ir jāparādās uz ekrānpults ATC punktā, kas atbild par lidojuma koordināciju. 8.5.3.3.3. Ieteikums. Būtu jānorāda arī tālāknosūtīšanas iemesls (nestandarta nosacījumi vai manuāla nosūtīšana). 8.5.4. RRV saņemšanas apstiprinājums 8.5.4.1. Saņemšanas apstiprināšana Ziņojuma saņemšana jāapstiprina, sagatavojot un pārraidot SBY ziņojumu. 8.5.4.2. Saņemšana nav apstiprināta Ja nav saņemts SBY ziņojums, kas apstiprina RRV ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojuma koordināciju, jāparādās brīdinājumam. 8.5.5. Operacionālā atbilde uz RRV Pārņēmējs dispečers RRV ziņojumu var apstiprināt, noraidīt vai piedāvāt atbildes priekšlikumu. 8.5.5.1. Apstiprināšana Ja pārņēmējs dispečers nolemj apstiprināt ierosinātos saskaņoto nodošanas nosacījumu grozījumus, ir jānosūta ACP ziņojums. 8.5.5.2. Atbildes priekšlikums Ja pārņēmējs dispečers nolemj piedāvāt atbildes priekšlikumu par nodošanas nosacījumiem, ir jānosūta CDN ziņojums. 8.5.5.3. Atteikšana Ja pārņēmējs dispečers nolemj noraidīt ierosinātos saskaņoto nodošanas nosacījumu grozījumus: - jānosūta RJC ziņojums, un - jāuzsāk jauns koordinācijas process. Atteikšana izriet no fakta, ka nav saņemts ACP vai CDN ziņojums kā atbilde uz RRV ziņojumu. 8.5.6. Piemēri 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. Rezervstāves ziņojums (SBY) 8.6.1. SBY ziņojuma mērķis Ar SBY ziņojumu apstiprina tāda ziņojuma saņemšanu, ar ko ierosina nodošanas nosacījumus, un paziņo, ka ierosinājums tiek nodots dispečeram lēmuma pieņemšanai. 8.6.2. Ziņojuma saturs SBY ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 8.6.3. Lietošanas noteikumi 8.6.3.1. Vispārējā daļa SBY ziņojums automātiski jāsagatavo un jāpārraida tūlīt pēc: - RAP, RRV vai CDN ziņojuma saņemšanas, - ACT vai REV ziņojuma saņemšanas, kas neiztur filtra pārbaudi. 8.6.4. SBY saņemšanas apstiprinājums SBY ziņojuma saņemšana nav jāapstiprina. 8.6.5. Piemēri 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. Apstiprināšanas ziņojums (ACP) 8.7.1. ACP ziņojuma mērķis ACP ziņojums atbilst šādām ekspluatācijas prasībām ATC koordinācijas un nodošanas fāzē: - tas norāda, ka vienas struktūrvienības dispečers manuāli apstiprinājis nodošanas nosacījumus, ko ierosinājis citas struktūrvienības dispečers ar kādu no šeit uzskaitītajiem ziņojumiem: - RAP, - RRV, - CDN, - ACT un REV, ja konstatē, ka kāds no tiem neatbilst standartam, - ja panākta abpusēja vienošanās, tas nodrošina tādu ACT vai REV ziņojumu automātisku apstiprināšanu, kas izturējuši filtra pārbaudi pārņēmējā struktūrvienībā (LAM vietā), - ja panākta abpusēja vienošanās, tas norāda uz HOP ziņojuma apstiprināšanu manuālā režīmā (ROF ziņojuma vietā). 8.7.2. Ziņojuma saturs ACP ziņojums satur šādas datu vienības: - obligātos datus - ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - atsauce uz ziņojumu, - fakultatīvos datus - ziņojumā var arī norādīt: - frekvenci, - ICAO formāta ziņojumu fakultatīvos datus — ziņojumā var arī norādīt šādas ziņas: - gaisakuģa identifikācijas indeksu, - izlidošanas lidlauku, - galamērķa lidlauku. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 8.7.3. Lietošanas noteikumi 8.7.3.1. Vispārējā daļa 8.7.3.1.1. ACP atsaucē uz ziņojumu ir jānorāda tā ziņojuma reģistrācijas numurs, kam par atbildi tas sagatavots. 8.7.3.1.2. Frekvences laukā, ja tāds ir, jānorāda frekvence, kurā gaisakuģim ir jāsazinās ar pārņēmēju struktūrvienību vadības pārņemšanas laikā. 8.7.3.1.3. ACP ziņojums ir jānosūta pēc tam, kad dispečers manuālā režīmā apstiprinājis nodošanas nosacījumus, kas ierosināti ar ACT, RAP, REV, RRV vai CDN ziņojumu. 8.7.3.1.4. ACP ziņojumu var nosūtīt ROF ziņojuma vietā, atbildot uz HOP ziņojumu. 8.7.3.1.5. Ja pastāv abpusēja vienošanās, sistēmai automātiski jāsagatavo un jāpārraida ACP ziņojums, atbildot uz ACT/REV ziņojumu, kas iztur filtra pārbaudi. 8.7.3.1.6. Saņemot ACP ziņojumu, saskaņotie nodošanas nosacījumi kļūst saistoši abām struktūrvienībām. 8.7.3.2. Datu apstrāde saņēmējā struktūrvienībā 8.7.3.2.1. ATC sistēmai, kas saņem ACP ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 8.7.3.2.2. Ja izdodas sasaistīt ACP ar lidojuma plānu, par apstiprināšanu jāpaziņo dispečeram. 8.7.3.2.3. Ja ACP nevar sasaistīt ar lidojuma plānu: - attiecīgajā punktā jāparādās brīdinājumam, un - LAM nav jānosūta. 8.7.4. ACP saņemšanas apstiprinājums 8.7.4.1. Saņemšanas apstiprināšana 8.7.4.1.1. LAM nav jānosūta, ja ACP kalpo kā automātiska atbilde uz ACT vai REV ziņojumu, kas iztur filtra pārbaudi. 8.7.4.1.2. Manuālās apstiprināšanas gaitā nosūtītā ACP ziņojuma saņemšana ir jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 8.7.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apliecina manuālās apstiprināšanas gaitā nosūtītā ACP ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojuma koordināciju, jāparādās brīdinājumam. 8.7.5. Piemēri 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. Koordinācijas ziņojums (CDN) 8.8.1. CDN ziņojuma mērķis CDN ziņojums atbilst šādām ekspluatācijas prasībām: - pārņēmēja dispečera atbildes priekšlikuma nosūtīšanai nododošajam dispečeram, atbildot uz ACT, RAP, REV vai RRV ziņojumu, - labojumu ierosināšanai saskaņotajos nodošanas nosacījumos, ko pārņēmējs dispečers iesniedz nododošajam dispečeram. 8.8.2. Ziņojuma saturs CDN ziņojums satur šādas datu vienības: - obligātos datus — ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - atsauce uz ziņojumu (tikai atbildot uz citu ziņojumu), - gaisakuģa identifikācijas indekss, - izlidošanas lidlauks, - galamērķa lidlauks, PIEZĪME. Ziņojumā jāiekļauj vismaz viena no šādām datu vienībām: - provizoriskie aprēķini (ja tas ir ICAO ziņojums) vai lidojuma vadības nodošanas līmenis (ja tas ir ADEXP ziņojums), - tiešā maršruta pieprasījums, - abpusēji saskaņoti dati — ja panākta abpusēja vienošanās, var norādīt arī šādus datus: - frekvenci. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 8.8.3. Lietošanas noteikumi 8.8.3.1. Vispārējā daļa 8.8.3.1.1. CDN ziņojumu pārraidi drīkst uzsākt tikai pārņēmējs dispečers. 8.8.3.1.2. Tas izmantojams, lai pārraidītu pārņēmēja dispečera atbildes priekšlikumu nododošajam dispečeram. PIEZĪME. Tas var risināties dialogā, atbildot uz ierosinājumu, kas nosūtīts ar ACT, RAP, REV vai RRV ziņojumu, vai uzsākot dialogu, lai grozītu iepriekš saskaņotos nodošanas nosacījumus. 8.8.3.1.3. Atsauce uz ziņojumu ir jāiekļauj tikai tad, ja CDN ziņojums ir atbilde uz citu ziņojumu. 8.8.3.1.4. Iekļaujot to, atsaucē uz ziņojumu ir jānorāda tā ziņojuma numurs, kam par atbildi sagatavots CDN. 8.8.3.1.5. Tiešā maršruta pieprasījuma iespējas (tuvāk aplūkotas A pielikumā): - drīkst izmantot tikai pēc abpusējas vienošanās, un - ja tāda pastāv, jānosaka ekspluatācijas ierobežojumi to izmantošanai. 8.8.3.1.6. CDN ziņojumu nedrīkst sūtīt, kad ir sasniegts iesaistīto struktūrvienību LoA noteiktais laika intervāls/attālums līdz robežai. 8.8.3.1.7. Ja saistībā ar vienu un to pašu lidojumu CDN ir pārraidīts praktiski vienlaicīgi ar nododošās struktūrvienības ziņojumu, piem., labojumu vai koordinācijas atcelšanas ziņojumu, nav jāsūta nedz tā saņemšanas apstiprinājums, nedz operacionālā atbilde uz to. PIEZĪME. Tas nozīmē, ka, vienlaicīgi nosūtot divus ziņojumus, nododošās struktūrvienības ziņojums kļūst prioritārs, bet CDN abas puses neņem vērā. Abas struktūrvienības var nojaust šādu situāciju, pirms apstiprinājuma saņemšanas saņemot ziņojumu no citas puses. 8.8.3.1.8. Uzreiz pēc apstiprināšanas ziņojuma saņemšanas CDN ziņojuma dati kļūst operacionāli saistoši abām ATC struktūrvienībām. Koordinētos nodošanas nosacījumus un ACP saņemšanas faktu dara zināmus attiecīgajam ATC personālam. 8.8.3.2. Datu apstrāde saņēmējā struktūrvienībā 8.8.3.2.1. Ja atrod atbilstīgu lidojuma plānu, un ziņojums nesatur pretrunas, kas varētu traucēt pareizu apstrādi: - operacionālajam saturam jābūt pieejamam ATC punktā, kas atbild par lidojuma koordināciju, un - jānosūta SBY ziņojums. 8.8.3.2.2. Ja nav CDN nevar sasaistīt vai atklājas pretrunas, kas traucē pareizu ziņojuma apstrādi, SBY nav jānosūta. 8.8.4. CDN saņemšanas apstiprinājums 8.8.4.1. Saņemšanas apstiprināšana Iepriekš minētajos apstākļos CDN ziņojuma saņemšana ir jāapstiprina, sagatavojot un pārraidot SBY ziņojumu. 8.8.4.2. Saņemšana nav apstiprināta Ja nav saņemts SBY ziņojums, kas apstiprina CDN ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojuma koordināciju, jāparādās brīdinājumam. 8.8.5. Operacionālā atbilde uz CDN Dispečers var apstiprināt vai noraidīt CDN ziņojumā ierosinātos nodošanas nosacījumus. 8.8.5.1. Apstiprināšana Ja nododošais dispečers nolemj apstiprināt ierosinātos nodošanas nosacījumus, ir jānosūta ACP ziņojums. 8.8.5.2. Ieteikums. Ja nododošais dispečers nolemj noraidīt ierosinātos nodošanas nosacījumus, būtu jānosūta RJC ziņojums (nepārprotams atteikums). PIEZĪME. Ierosinātā koordinācija tiek netieši atteikta, ja, beidzoties CDN ziņojuma taimautam, nav saņemts apstiprināšanas ziņojums. 8.8.6. Piemēri 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. Koordinācijas atteikuma ziņojums (RJC) 8.9.1. RJC ziņojuma mērķis RJC ziņojums norāda uz to, ka vienas struktūrvienības dispečers ir noraidījis nodošanas nosacījumus, ko ierosinājis citas struktūrvienības dispečers kādā no šeit uzskaitītajiem ziņojumiem: - RAP, - RRV, - CDN, - ACT un REV, ja konstatē, ka kāds no tiem neatbilst standartam. RJC ziņojumu var izmantot tikai kā tiešu atbildi uz vienu no iepriekš minētajiem ziņojumiem. 8.9.2. Ziņojuma saturs RJC ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - atsauci uz ziņojumu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 8.9.3. Lietošanas noteikumi 8.9.3.1. Vispārējā daļa 8.9.3.1.1. RJC pēc vajadzības jānosūta kā atbilde uz RAP, RRV vai CDN ziņojumu, kā arī uz ACT vai REV ziņojumu, kas pēc pārņēmējas struktūrvienības atzinuma neatbilst standartam. 8.9.3.1.2. RJC ziņojums noslēdz dialogu starp sistēmām un jebkura iepriekš panāktā koordinācija paliek spēkā. 8.9.3.1.3. Ieteikums. Pēc RJC ziņojuma saņemšanas būtu jāievieš jauna koordinācijas secība, vajadzības gadījumā balstoties uz telefonisku koordināciju. 8.9.3.2. Datu apstrāde saņēmējā struktūrvienībā 8.9.3.2.1. Ja atrod atbilstīgu ziņojumu, uz kuru atsaucas RJC ziņojums: - ATC punktā, kas atbild par konkrētā lidojuma koordināciju, jāparādās atteikumam, un - apstiprinājumam jānosūta LAM. 8.9.3.2.2. Ja šāda veida ziņojumu, uz ko būtu jādod atbilde, neatrod, vai ziņojumā ir pretrunas, kas traucē apstrādi, saņemšanas apstiprinājums nav jāsūta. 8.9.4. RJC saņemšanas apstiprinājums 8.9.4.1. Saņemšanas apstiprināšana RJC ziņojuma saņemšana ir jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 8.9.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina RJC ziņojuma saņemšanu, ATC punktā, kurš atbild par lidojumu koordināciju, jāparādās brīdinājumam. 8.9.5. Piemēri 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. DIALOGA PROCEDŪRA — SAKARU NODOŠANA 9.1. Vispārējā daļa 9.1.1. Ievads 9.1.1.1. Šajā iedaļā ir aplūkotas tehniskās iespējas un ziņojumi, kas nodrošina radiolokatoru maiņu vadības nodošanas gaitā. Tie jāizmanto, ja pastāv abpusēja vienošanās. 9.1.1.2. Sakaru nodošanas mehānismu drīkst lietot tikai tad, ja struktūrvienība izmanto 6. iedaļā (Pamatprocedūra - obligātie ziņojumi) vai 8. iedaļā (Dialoga procedūra — koordinācija) aplūkotās koordinācijas iespējas. 9.1.1.3. Šajā iedaļā aplūkotie ziņojumi ir pieejami tikai ADEXP formātā, un nav paredzēts, ka tie būs pieejami ICAO formātā. 9.1.2. Ziņojumu secība 9.1.2.1. Sakaru nodošanas ziņojumu apmaiņa (tas neattiecas uz papilddatu ziņojumiem, SDM) nevar notikt, kamēr nav pabeigta koordinācija, tas ir, ar LAM vai ACP ziņojuma palīdzību noslēgts ACT vai RAP dialogs. 9.1.2.2. Kamēr turpinās koordinācija, nedrīkst sūtīt saņemšanas apstiprinājumu. 9.1.3. Sakaru nodošana 9.1.3.1. Abām iesaistītajām struktūrvienībām abpusēji jāvienojas par to, kādā veidā paziņos lidojumu sakaru faktisko nodošanu. 9.1.3.2. Jāievēro vismaz viens no šeit minētajiem nosacījumiem: - COF ), - MAS ). 9.1.3.3. Abām struktūrvienībām par šo veidu jāvienojas attiecībā uz katru satiksmes plūsmu. PIEZĪME. Dažādām plūsmām var izmantot atšķirīgus veidus, piemēram, viena struktūrvienība var gatavot COF ziņojumus saistībā ar gaisakuģiem, kas atstāj tās gaisa telpu, un MAS ziņojumus saistībā ar gaisakuģiem, kas ierodas tās gaisa telpā. Šajā gadījumā otrai struktūrvienībai nav vajadzības sniegt ziņojumus, lai paziņotu par sakaru nodošanu. 9.2. Nodošanas ierosināšanas ziņojums (TIM) 9.2.1. TIM ziņojuma mērķis TIM kalpo šādiem mērķiem: - TI ) (koordinācijas fāzes beigas un nodošanas fāzes sākumu), - tas vienlaicīgi nodrošina vadības kontroles datu nosūtīšanu no nododošās struktūrvienības pārņēmējai struktūrvienībai. 9.2.2. Ziņojuma saturs TIM ziņojums satur šādas datu vienības: - obligātos datus — ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - pieejamos datus — ziņojumā jānorāda arī šādi dati, ja tie ir pieejami: - atļautais lidojuma līmenis, - noteiktais kurss vai tiešā lidojuma atļauja, - noteiktais ātrums, - noteiktais augstuma uzņemšanas/samazināšanas ātrums, - fakultatīvos datus - ziņojumā var arī norādīt: - atrašanās vietu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.2.3. Lietošanas noteikumi 9.2.3.1. Vispārējā daļa 9.2.3.1.1. Nododošajai struktūrvienībai ir jāsagatavo TIM ziņojums un jāpārraida tas pārņēmējai struktūrvienībai bez cilvēka līdzdalības, gaisakuģim atrodoties abpusēji saskaņotā laika intervālā/attālumā no robežas. 9.2.3.1.2. TIM ziņojums automātiski jānosūta arī tad, kad nododošā struktūrvienība saņem frekvences maiņas pieprasījuma ziņojumu (ROF). 9.2.3.1.3. TIM ziņojumu nedrīkst sūtīt, kamēr nav veikta lidojuma koordinācija. 9.2.3.1.4. TIM ziņojumā jāiekļauj visjaunākie dati, kas pieejami sistēmā. 9.2.3.2. Pārraides ilguma parametri 9.2.3.2.1. TIM sagatavošanas parametriem ir jābūt mainīgiem sistēmlielumiem, ko var grozīt atkarībā no LoA nosacījumiem. 9.2.3.2.2. Ieteikums. TIM sagatavošanas sistēmparametri būtu jānosaka atsevišķi katram COP. 9.2.3.2.3. Koordinācijas partneriem TIM sagatavošanas parametri jāiekļauj savā LoA. 9.2.3.2.4. Sistēmparametri, kas iedarbina TIM ziņojuma palaides mehānismu, var būt saistīti ar aprēķināto gaisakuģa ātrumu attiecībā pret zemi. Tomēr TIM ziņojuma pārraide vienmēr jāuzsāk, pirms gaisakuģis saskaņā ar pašreizējo lidojuma plānu ir sasniedzis abpusēji noteikto minimālo attālumu no COP. 9.2.3.2.5. TIM pārraidei noteiktajiem sistēmparametriem jāparedz pietiekams laiks, lai nodrošinātu mutisku koordināciju pirms vadības pārņemšanas. 9.2.3.3. Datu apstrāde saņēmējā struktūrvienībā 9.2.3.3.1. Datiem, kas saņemti ar TIM ziņojumu, jābūt pieejamiem pārņēmējam dispečeram. 9.2.4. TIM saņemšanas apstiprinājums 9.2.4.1. Saņemšanas apstiprināšana Ja TIM ziņojumu: - var nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana jāapstiprina, sagatavojot un pārraidot LAM ziņojumu, - nevar nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana nav jāapstiprina. 9.2.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina TIM ziņojuma saņemšanu, attiecīgajā punktā jāparādās brīdinājumam. 9.2.5. Piemērs -TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 029 -ARCID AMM253 9.3. Papilddatu ziņojums (SDM) 9.3.1. SDM ziņojuma mērķis 9.3.1.1. Vispārējā daļa 9.3.1.1.1. SDM ziņojumu galvenokārt izmanto, lai pārraidītu vadības datus un to labojumus no nododošās struktūrvienības pārņēmējai struktūrvienībai, ja vien pastāv abpusēja vienošanās, ka šie labojumi nav jāapstiprina pārņēmējam dispečeram. 9.3.1.1.2. SDM ziņojumu var izmantot arī pārņēmēja struktūrvienība, lai paziņotu nododošajai struktūrvienībai radiotelefonijas frekvenci pēc lidojuma vadības nodošanas. 9.3.2. Ziņojuma saturs 9.3.2.1. Nododošās struktūrvienības ziņojumi SDM ziņojums satur šādas datu vienības: - obligātos datus — ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - papildu datus — ziņojumā arī jāiekļauj vismaz viena no šādām datu vienībām: - noteiktais kurss vai tiešā lidojuma atļauja, - noteiktais ātrums, - noteiktais augstuma uzņemšanas/samazināšanas ātrums, - atļautais lidojuma līmenis. 9.3.2.2. Pārņēmējas struktūrvienības ziņojumi SDM ziņojumā ir jāiekļauj šādi dati: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - frekvence. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.3.3. Lietošanas noteikumi 9.3.3.1. Nododošās struktūrvienības ziņojumi 9.3.3.1.1. SDM ziņojumi jāpārraida pēc nodošanas fāzes ierosināšanas (skatīt TIM, 9.2. punkts), ja izmaiņas skar šādās datu pozīcijas: - atļauto lidojuma līmeni, - noteikto ātrumu, - noteikto augstuma uzņemšanas/samazināšanas ātrumu, - noteikto kursu, vai - atļaujas tiešā lidojuma turpinājumam uz kādu noteiktu punktu izsniegšanu vai grozīšanu. PIEZĪME. HOP ziņojums ir jāizmanto, kad ir nepieciešams pārņēmēja dispečera apstiprinājums pirms sakaru nodošanas. 9.3.3.1.2. Ziņojumā jāiekļauj tikai izmainīti lauki. 9.3.3.1.3. SDM ziņojumi, kas satur 9.3.3.1.1. punktā aplūkotos datus, ir jāpārraida pirms pārņemšanas ierosināšanas (TI), ja pastāv abpusēja vienošanās. 9.3.3.1.4. Šādu ziņojumu pārraide jāuzsāk abpusēji saskaņotā laikā attiecībā uz TI, ja vien sistēmā ir pieejami attiecīgie dati. 9.3.3.2. Pārņēmējas struktūrvienības ziņojumi 9.3.3.2.1. SDM ziņojumi var tikt pārraidīti, lai paziņotu frekvenci, kurā gaisakuģim jāsazinās ar pārņēmēju struktūrvienību. PIEZĪME. Struktūrvienības var, abpusēji vienojoties, sūtīt arī citas ziņas. Šāda apmaiņa nav atrunāta šajā standartā un tādēļ nav iekļauta tajā. 9.3.3.2.2. Pārņēmējai struktūrvienībai, ja pastāv abpusēja vienošanās, SDM ziņojumi ir jāpārraida koordinācijas fāzē. 9.3.3.3. Datu apstrāde saņēmējā struktūrvienībā 9.3.3.3.1. ATC sistēmai, kas saņem SDM ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 9.3.3.3.2. Ja atbilstīgais lidojuma plāns ir jau koordinēts: - ir jānosūta LAM, un - SDM ziņojuma operacionālajam saturam jābūt pieejamam attiecīgajam dispečeram. 9.3.3.3.3. Ja atbilstīgs lidojuma plāns nav atrodams vai atklājas pretrunas, kas traucē pareizu ziņojuma apstrādi: - LAM nav jānosūta, un - attiecīgajā punktā jāparādās brīdinājumam. 9.3.4. SDM saņemšanas apstiprinājums 9.3.4.1. Saņemšanas apstiprināšana SDM ziņojuma saņemšana ir jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 9.3.4.2. Saņemšana nav apstiprināta Ja nesaņem LAM ziņojumu, kas apstiprina SDM ziņojuma saņemšanu, attiecīgajā punktā ir jāparādās brīdinājumam. 9.3.5. Piemērs -TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 028 -ARCID AMM253 -AHEAD 290 9.4. Pārņemšanas ierosinājums (HOP) 9.4.1. HOP ziņojuma mērķis HOP ziņojumu izmanto, lai: - nododošais dispečers varētu pievērst pārņēmēja dispečera uzmanību konkrētam lidojumam saistībā ar tā nodošanu, - nododošais dispečers vajadzīgajā brīdī varētu ierosināt lidojuma vadības pārņemšanu pārņēmējam dispečeram, - saskaņā ar abpusēju vienošanos nosūtītu izmaiņas vadības kontroles datos, kurām vajadzīgs pārņēmēja dispečera apstiprinājums. PIEZĪME. Kas attiecas uz iepriekšminēto c) punktu, SDM izmanto, lai nosūtītu izmaiņas vadības kontroles datos, kurām nav vajadzīgs pārņēmēja dispečera apstiprinājums. 9.4.2. Ziņojuma saturs HOP ziņojums satur šādas datu vienības: - obligātos datus - ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - pieejamos datus — ziņojumā jānorāda arī šādi dati, ja tie ir pieejami: - atļautais lidojuma līmenis, - noteiktais kurss/tiešā lidojuma atļauja, - noteiktais ātrums, - noteiktais augstuma uzņemšanas/samazināšanas ātrums, - fakultatīvos datus — ziņojumā var arī norādīt: - atrašanās vietu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.4.3. Lietošanas noteikumi 9.4.3.1. Vispārējā daļa 9.4.3.1.1. Ja lieto HOP ziņojumu, tā pārraidi ierosina nododošais dispečers manuālajā režīmā. 9.4.3.1.2. Ziņojumā ir jāiekļauj visi 9.4.2. punktā norādītie lidojuma dati, kas izmainīti salīdzinot ar iepriekšējo ziņojumu. 9.4.3.1.3. PIEZĪME. Papildus HOP ziņojumam nav nepieciešams nodošanas ierosināšanas ziņojums (TIM). 9.4.3.1.4. Abām pusēm jāvienojas, kādā laika intervālā vai attālumā no COP vai pirms robežas šķērsošanas var sākt sūtīt HOP ziņojumu. 9.4.3.1.5. Ieteikums. Šis laika intervāls/attālums būtu jānosaka atsevišķi katram COP. 9.4.3.2. Datu apstrāde saņēmējā struktūrvienībā 9.4.3.2.1. ATC sistēmai, kas saņem HOP ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 9.4.3.2.2. Lidojuma datiem, kas saņemti ar šo ziņojumu, uzreiz jāparādās uz pārņēmēja dispečera ekrānpults. 9.4.3.2.3. Ja pārņēmējs dispečers apstiprina lidojumu ar HOP ziņojumā ierosinātajiem nosacījumiem, kā atbildi nododošajai struktūrvienībai var nosūtīt ROF ziņojumu. Abpusēji vienojoties, kā atbildi uz HOP var nosūtīt ACP. 9.4.3.2.4. Ja pārņēmējs dispečers nespēj apstiprināt lidojumu, par nodošanu vienojas mutiski. PIEZĪME. Ņemot vērā pārņemšanas procedūras steidzamību, šis standarts neparedz ROF (vai ACP) automatizētu uzraudzību; uzskata, ka nododošais dispečers tāpat apzināsies, ka nav saņemta atbilde no pārņēmēja dispečera, un attiecīgi rīkosies. Šis standarts tomēr neizslēdz iespēju nosūtīt brīdinājumu nododošajam dispečeram, ja tas ir operacionāli nepieciešams. 9.4.3.2.5. Uzreiz pēc ROF (vai ACP) saņemšanas HOP ziņojuma dati kļūst operacionāli saistoši abām ATC struktūrvienībām. 9.4.4. HOP saņemšanas apstiprinājums 9.4.4.1. Saņemšanas apstiprināšana Ja HOP ziņojumu var sasaistīt ar lidojuma plānu, tas automātiski jāapstiprina, nosūtot LAM. 9.4.4.2. Saņemšana nav apstiprināta Ja nesaņem LAM ziņojumu, kas apstiprina HOP ziņojuma saņemšanu, attiecīgajā punktā jāparādās brīdinājumam. 9.4.5. Piemērs -TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STJ 9.5. Frekvences maiņas pieprasījuma ziņojums (ROF) 9.5.1. ROF ziņojuma mērķis Pārņēmēja struktūrvienība nosūta ROF ziņojumu nododošajai struktūrvienībai, kad jāpieprasa nododošajam dispečeram dot norādījumu gaisakuģim pāriet uz pārņēmēja dispečera frekvenci. Šo ziņojumu var izmantot: - kā atbildi uz HOP ziņojumu, paziņojot par ierosināto nosacījumu apstiprināšanu lidojumam, - pieprasot pirms laika nodot lidojuma vadību. 9.5.2. Ziņojuma saturs ROF ziņojums satur šādas datu vienības: - obligātos datus — ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - fakultatīvos datus — ziņojumā var arī norādīt: - frekvenci. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.5.3. Lietošanas noteikumi 9.5.3.1. Vispārējā daļa 9.5.3.1.1. ROF ziņojuma pārraide pārņēmējam dispečeram jāierosina manuālajā režīmā. 9.5.3.1.2. Pārņēmējs dispečers var uzsākt ROF pārraidi: - ja pārņēmējam dispečeram pirms laika jāpārņem gaisakuģis savā frekvencē, - atbildot uz HOP ziņojumu. 9.5.3.2. Datu apstrāde saņēmējā struktūrvienībā 9.5.3.2.1. ATC sistēmai, kas saņem ROF ziņojumu, jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 9.5.3.2.2. Par ROF saņemšanu nekavējoties jāpaziņo nododošajam dispečeram. 9.5.3.2.3. Ja lidojums nav nodošanas fāzē, ir jāierosina nodošanas fāze un jāpārraida TIM ziņojums. 9.5.4. ROF saņemšanas apstiprinājums 9.5.4.1. Saņemšanas apstiprināšana 9.5.4.1.1. Ja ROF ziņojumu var nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 9.5.4.1.2. Ja ROF ziņojumu nevar nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana nav jāapstiprina. 9.5.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina ROF ziņojuma saņemšanu, attiecīgajā ATC punktā jāparādās brīdinājumam. 9.5.5. Piemērs -TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.6. Frekvences maiņas ziņojums (COF) 9.6.1. COF ziņojuma mērķis 9.6.1.1. Vispārējā daļa 9.6.1.1.1. Nododošā struktūrvienība nosūta COF ziņojumu pārņēmējai struktūrvienībai, lai paziņotu, ka gaisakuģis ir saņēmis norādījumu sazināties ar pārņēmēju dispečeru. 9.6.1.1.2. Šis ziņojums var paredzēt iespēju, ka nododošais dispečers atbrīvo gaisakuģi no saskaņotajiem nodošanas nosacījumiem, tam nodibinot sakarus ar pārņēmēju dispečeru. 9.6.2. Ziņojuma saturs COF ziņojums satur šādas datu vienības: - obligātos datus — ziņojumā ir jānorāda: - ziņojuma tips, - ziņojuma numurs, - gaisakuģa identifikācijas indekss, - pieejamos datus — ziņojumā jānorāda arī šādi dati, ja tie ir pieejami: - atbrīvojuma norāde, - frekvence, - atļautais lidojuma līmenis, - noteiktais kurss vai tiešā lidojuma atļauja, - noteiktais ātrums, - noteiktais augstuma uzņemšanas/samazināšanas ātrums, - fakultatīvos datus — ziņojumā var arī norādīt: - atrašanās vietu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.6.3. Lietošanas noteikumi 9.6.3.1. Vispārējā daļa 9.6.3.1.1. COF ziņojuma pārraide nododošajam dispečeram jāierosina manuālajā režīmā. 9.6.3.1.2. COF ziņojuma izmantošana ir obligāta, ja abpusēji vienojas neizmantot MAS ziņojumu. 9.6.3.1.3. Ja COF ziņojums nosūtīts pirms TI , ir jāierosina nodošanas fāze. PIEZĪME. Papildus COF ziņojumam nav jāsūta nodošanas ierosināšanas ziņojums (TIM). 9.6.3.2. Datu apstrāde saņēmējā struktūrvienībā 9.6.3.2.1. ATC sistēmai, kas saņem COF ziņojumu, ir jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 9.6.3.2.2. Par COF saņemšanu nekavējoties jāpaziņo pārņēmējam dispečeram. 9.6.4. COF saņemšanas apstiprinājums 9.6.4.1. Saņemšanas apstiprināšana 9.6.4.1.1. Ja COF ziņojumu var nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 9.6.4.1.2. Ja COF ziņojumu nevar nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana nav jāapstiprina. 9.6.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina COF ziņojuma saņemšanu, attiecīgajā ATC punktā jāparādās brīdinājumam. 9.6.5. Piemēri -TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 9.7. Ziņojums par sakaru uzņemšana manuālajā režīmā (MAS) 9.7.1. MAS ziņojuma mērķis Pārņēmēja struktūrvienība nosūta MAS ziņojumu nododošajai struktūrvienībai, lai paziņotu, ka ar gaisakuģi nodibināti divvirzienu radiosakari. 9.7.2. Ziņojuma saturs MAS ziņojums satur šādas datu vienības: - ziņojuma tipu, - ziņojuma numuru, - gaisakuģa identifikācijas indeksu. PIEZĪME. Datu iestrādes noteikumi, lauku formāts un saturs ir norādīti A pielikumā. 9.7.3. Lietošanas noteikumi 9.7.3.1. Vispārējā daļa 9.7.3.1.1. MAS ziņojuma pārraide pārņēmējam dispečeram jāierosina manuālajā režīmā. 9.7.3.1.2. MAS ziņojuma izmantošana ir obligāta, ja abpusēji vienojas neizmantot COF ziņojumu. 9.7.3.2. Datu apstrāde saņēmējā struktūrvienībā 9.7.3.2.1. ATC sistēmai, kas saņem MAS ziņojumu, ir jāmēģina veikt tā sasaisti ar attiecīgo lidojuma plānu. 9.7.3.2.2. Par MAS saņemšanu nekavējoties jāpaziņo dispečeram. 9.7.4. MAS saņemšanas apstiprinājums 9.7.4.1. Saņemšanas apstiprināšana 9.7.4.1.1. Ja MAS ziņojumu var nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana jāapstiprina, sagatavojot un pārraidot LAM ziņojumu. 9.7.4.1.2. Ja MAS ziņojumu nevar nepārprotami sasaistīt ar lidojuma plānu, tā saņemšana nav jāapstiprina. 9.7.4.2. Saņemšana nav apstiprināta Ja nav saņemts LAM ziņojums, kas apstiprina MAS ziņojuma saņemšanu, attiecīgajā ATC punktā vajadzības gadījumā jāparādās brīdinājumam. 9.7.5. Piemērs -TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -SEQNUM 030 -ARCID AMM253 [1] Izmantojot dialoga procedūrā, TX un REC ir obligāta. [2] Skatīt 5.2.1.1. punktu "Transakciju ilguma nosacījumi". [3] Izmanto ne visās gaisa telpas konfigurācijās. [4] M, ja sūtītājs ir nododošā struktūrvienība; C, ja sūtītājs ir pārņēmēja struktūrvienība. [5] Savstarpēja vienošanās nosaka, ka, ja nodošana skar konkrētu satiksmes plūsmas virzienu, nododošajai struktūrvienībai vismaz jānosūta COF ziņojums vai pārņēmējai struktūrvienībai jānosūta MAS ziņojums. -------------------------------------------------- II PIELIKUMS GAISA SATIKSMES PAKALPOJUMU DATU APMAIŅAS ATVEIDE (ADEXP), VERSIJA 2.0 (odkaz na dokument Eurocontrol DPS.ET1.ST09-STD) SATURS AUTORTIESĪBU ATRUNA … PRIEKŠVĀRDS … 1. DARBĪBAS JOMA … 2. NORĀDES … 3. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI … 3.1. Notācija … 3.2. Definīcijas … 3.3. Uzbūve … 3.4. Norunas … 3.5. Operatori … 3.6. Saīsinājumi … 4. ADEXP PRINCIPI … 4.1. Viegli lasāms teksta formāts … 4.2. Atpazīstami un atgūstami lauki … 4.3. Neatpazīti lauki … 5. ADEXP SINTAKSES NOTEIKUMI … 5.1. Leksiskās sastāvdaļas … 5.2. Lauki … 6. NORMALIZĒTS ADEXP ZIŅOJUMU APRAKSTS … 6.1. Ievads … 6.2 Palīgtermi … 6.3. Primāro lauku definīcija … 6.4. Apakšlauku definīcija … 6.5. Ziņojumu grupa … A PIELIKUMS (NORMATĪVS) LAUKA DEFINĪCIJAS … B PIELIKUMS (NORMATĪVS) GALVENAIS ADEXP ZIŅOJUMU VIRSRAKSTU INDEKSS … C PIELIKUMS (NORMATĪVS) GALVENAIS REZERVĒTU ADEXP ZIŅOJUMU VIRSRAKSTU INDEKSS … D PIELIKUMS (NORMATĪVS) GALVENAIS REZERVĒTU LAUKU INDEKSS … E PIELIKUMS (INFORMATĪVS) ZIŅOJUMU GRUPU IEVIEŠANA … F PIELIKUMS (INFORMATĪVS) ADEXP ZIŅOJUMU FORMĀTA PARAUGI … G PIELIKUMS (INFORMATĪVS) TURPMĀKĀ ATTĪSTĪBA … AUTORTIESĪBU ATRUNA Šis dokuments sagatavots Eiropas Aeronavigācijas drošības organizācijas (Eurocontrol) aģentūrā. Autortiesības pieder Eurocontrol aģentūrai. Tādējādi dokumenta vai jebkuras tā daļas saturs ir brīvi pieejams dalībvalstu pārstāvjiem, bet tā pavairošanai vai izpaušanai jebkurai citai personai ir vajadzīga Eurocontrol aģentūras rakstiska piekrišana. PRIEKŠVĀRDS 1. Atbildīgā iestāde Šis standarts izstrādāts Eiropas Aeronavigācijas drošības organizācijas (Eurocontrol) Centrālās gaisa satiksmes plūsmu pārvaldības institūcijas (CFMU) Lietojumspecifikāciju nodaļā, kas arī uzrauga tā pārskatīšanu. 2. EATCHIP darba programmas dokuments Šis standarts radīts, veicot EATCHIP darba programmas dokumenta (EWPD) datu apstrādes sistēmu (DPS) jomā vadības nodrošināšanas uzdevumu 09. 3. Standarta apstiprināšana 3.1. Šis standarts pieņemts saskaņā ar kārtību, kas izklāstīta Eurocontrol standartizācijas direktīvās, reģ. Nr. 000-2-93, redakcija 1.0. 3.2. Šā standarta nosacījumi stājās spēkā pēc redakcijas 1.0 apstiprināšanas Eurocontrol pastāvīgajā komisijā 1995. gadā, un to piemērošana noteikta no 1997. gada 1. decembra. 4. Tehniskie labojumi un grozījumi Šo standartu pastāvīgi pārskata, veicot nepieciešamos grozījumus vai tehniskos labojumus. Šā standarta pārskatīšanas kārtība izklāstīta H pielikumā, kas pievienots Eurocontrol standartizācijas dokumentu vienotās sagatavošanas un noformēšanas direktīvām. Grozījumi vai papildinājumi, kas skar ADEXP formāta pamatprincipus vai gramatiku, ir izdarāmi tikai saskaņā ar oficiālo pārskatīšanas procedūru, kura paredzēta Eurocontrol standartizācijas dokumentu vienotās sagatavošanas un noformēšanas direktīvās. Šā standarta grozījumi vai papildinājumi jāiesniedz rakstveidā Eurocontrol aģentūras CFMU Lietojumspecifikāciju nodaļā (ADEXP). 5. Redakcionālās norunas 5.1. Šā standarta noformējums ir saskaņā ar Eurocontrol standartizācijas dokumentu vienotās sagatavošanas un noformēšanas direktīvām, lai gan tajā ir dažas atkāpes no šīm direktīvām. Nelielas atkāpes no šīm direktīvām ir ieviestas, lai izvairītos no pārpratumiem, lietojot ATS datu apmaiņas atveides (ADEXP) notāciju. 5.2. Norādot uz katra izteikuma statusu, izmanto šādu notāciju: - normatīvajās sastāvdaļās, kas rakstītas parastiem burtiem bez izcēluma, izmanto darbības vārdus tagadnes formā (angļu tekstā lieto "shall"), - sastāvdaļās, kam ir ieteikuma raksturs un kas iespiestas slīprakstā bez izcēluma, izmanto vēlējuma izteiksmi (angļu tekstā lieto "should"), priekšā ar vārdu "Ieteikums" norādot uz to statusu. 6. Saistība ar citiem standartizācijas dokumentiem Šis standarts ir saistīts ar: Eurocontrol standartu datu apmaiņai tiešsaistē (OLDI). 7. Šā standarta pielikumu statuss Šajā direktīvā ir 6 pielikumi, un to statuss noteikts šādi: A pielikums | normatīvs | B pielikums | normatīvs | C pielikums | normatīvs | D pielikums | normatīvs | E pielikums | informatīvs | F pielikums | informatīvs | G pielikums | informatīvs | 8. Valoda Šā standarta sākotnējais teksts sagatavots angļu valodā. 1. DARBĪBAS JOMA 1.1. ADEXP ir formāts nevis protokols. Uz datu pārraides vidi vai protokoliem neattiecas nekādi ierobežojumi, tie skar tikai rakstzīmju kopu. 1.2. ADEXP formāts izmantojams galvenokārt ziņojumu apmaiņai starp datoriem tiešsaistē. 1.3. Šajā dokumentā noteikti ADEXP formāta principi un sintakses noteikumi. To piemērošana paredz vispusīgi definēt ADEXP laukus. 1.4. ADEXP formāts noteikts izmantošanai šādās ziņojumu apmaiņas jomās (uzziņas par atsauces dokumentiem atrodamas 2. iedaļas 3. lpp.): - lidojumu plānošana — lidojuma plānu datu un ar tiem saistīto ziņojumu apmaiņa starp integrēto lidojuma plānu sākotnējās apstrādes sistēmu (IFPS), gaisa satiksmes dienestiem (ATS) un gaisa kuģu ekspluatantiem (AO). (Norāde Nr. 3), - gaisa satiksmes plūsmas pārvaldība (ATFM) — ziņojumu apmaiņa starp CFMU taktikas sistēmu (TACT), AO un ATS. (Norāde Nr. 5), - gaisa satiksmes vadības koordinācija — taktiskās koordinācijas ziņojumu apmaiņa starp gaisa satiksmes vadības struktūrvienībām (ATCU). (Norāde Nr. 6), - gaisa telpas pārvaldība — gaisa telpas pieejamības datu apmaiņa starp atsevišķu valstu ATS struktūrvienībām, CFMU un AO. (Norāde Nr. 7), - civilā/militārā koordinācija — ziņojumi, kas satur civilo/militāro lidojumu datus, un gaisa telpas šķērsošanas ziņojumi. (Norāde Nr. 7). 1.5. Sīki izstrādātas ziņojumu lietojuma un saturu specifikācijas katrai iepriekšminētajai grupai atrodamas atsauces dokumentos. 2. NORĀDES 2.1. Šeit minētie dokumenti un standarti ietver noteikumus, uz kuriem atsaucas šajā tekstā un kas ir iekļauti šā Eurocontrol standarta noteikumos. Šā Eurocontrol standarta publicēšanas brīdī atsauces dokumenti un standarti bija spēkā tajās norādītajā redakcijā. Jebkura atsaucē minētā Starptautiskās civilās aviācijas organizācijas (ICAO) dokumenta pārskatīšana tūlīt nozīmē šā Eurocontrol standarta pārskatīšanu. Pārējo atsauces dokumentu labojumus neiekļauj šā Eurocontrol standarta noteikumos, kamēr tie nav oficiāli izskatīti un iestrādāti šajā Eurocontrol standartā. Rodoties pretrunām starp šā Eurocontrol standarta prasībām un pārējo atsauces dokumentu saturu, prioritāte ir šim Eurocontrol standartam. 2.2. Publicēšanas brīdī šā standarta atsaucēs pieminēti tālāk uzskaitītie dokumenti, tomēr lietotājiem būtu ieteicams ielūkoties lietošanas un ziņojumu lauku satura tabulās minēto dokumentu jaunākajā redakcijā. 1. ICAO Čikāgas konvencijas 10. pielikums, I sējums, 1985. gada novembra redakcija; 2. ICAO Čikāgas konvencijas 10. pielikums, II sējums, 1995. gada jūlija redakcija; 3. IFPS and RPL Dictionary of Messages, redakcija 1.0, 1998. gada marts; 4. "Lidojumu un gaisa satiksmes dienestu noteikumi", PANS-RAC Doc 4444, 1985. gada novembra redakcija (ieskaitot 1995. gada novembra grozījumu Nr. 6); 5. Guide To ATFM Message Exchange, Eurocontrol dokumentu šifrs TACT/USD/MSGGUID, redakcija 6.0, spēkā no 1998. gada marta; 6. Eurocontrol standarts datu apmaiņai tiešsaistē, redakcija 2.0, 1996. gada oktobris; 7. Functional Specifications for System Support to Airspace Data Distribution and Civil Military Co-ordination, redakcija 1.0, 1996. gada maijs. 3. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI 3.1. Notācija Sintakses aprakstam izmantojamo notāciju dēvē par Backus Naur Form (BNF). BNF definē noteikumu kopu, kas nosaka rakstzīmju virkņu klasi. Šajā gadījumā rakstzīmju virkņu klase atbilst ziņojumu kopai, kas dēvējama par sintaktiski derīgu ADEXP ziņojumu. 3.2. Definīcijas Šajā Eurocontrol standartizācijas dokumentā lieto šādas definīcijas: Pilnvara : — rakstzīme vai rakstzīmju kopa, ko ar atdalītāju palīdzību var "izdalīt" leksiskais analizators. Simbols : — jebkurš "termins" BNF noteikumā, kas nav rakstzīme. Noteiktais simbols : — simbols, kas attēlots kā rakstzīmju secība. Nenoteiktais simbols : — simbols, kas veidots no viena vai vairākiem noteiktajiem simboliem. PIEZĪME. Nenoteiktu simbolu var veidot arī noteikto un nenoteikto simbolu savienojums. 3.3. Uzbūve 3.3.1. BNF sastāv no noteikumu kopas vai tipveida struktūrām: simbols::= izteiksme PIEZĪMES 1) Notācija "::=" lasāma kā "var aizstāt ar"; 2) "Simbols" pieskaitāms pie nenoteiktajām sastāvdaļām; 3) "Izteiksme" ir sastāvdaļa, kas sastāv no noteiktajiem un nenoteiktajiem simboliem. 3.3.2. Noteiktos simbolus var tieši atveidot kā rakstzīmju secību, ko ar atdalītāju palīdzību analītiskais analizators var atpazīt kā pilnvaru. 3.4. Norunas Šajā Eurocontrol standartā ievēro šādas norunas: - Noteiktos simbolus atveido lielajiem burtiem. PIEZĪME. Ievērojot norunu, noteiktais simbols NIL norāda, ka "noteiktā simbola nav". To lieto, kad pastāv izvēles iespēja, piemēram: a::= b (c | NIL), kur a var aizstāt ar (b, aiz kura stāv c) vai tikai ar b. - Nenoteiktos simbolus (piem., gramatiskā pagarinājuma kreisā puse) atveido ar mazajiem burtiem. - Noteikumos sastopamās rakstzīmes un virknes literāļus attiecīgi liek vienpēdiņās (') vai pēdiņās (").: Piemēri 1) HYPHEN::= '-' 2) title::= '-' "TITLE" titleid Atsevišķos datu modelēšanas gadījumos var būt nepieciešams atšķirt noteiktos un nenoteiktos simbolus citādā veidā, nevis izmantojot lielos un mazos burtus. Kad rodas vajadzība skaidri nošķirt noteiktos un nenoteiktos simbolus citādā veidā, nevis izmantojot lielos un mazos burtus, iesaka pievienot šādus sufiksus: "_at" palīgtermam, "_pf" primārajam laukam un "_sf" apakšlaukam. 3.5. Operatori Šajā Eurocontrol standartā ir izmantojami šādi operatori: Fakultatīvie — kad ir pieļaujams, ka daži simboli var parādīties vai neparādīties kādā vietā, kā tas noteikts gramatikā. Fakultatīvos simbolus liek kvadrātiekavās "[" un "]". Slēgums - kad simbolu grupa var parādīties nulle reižu vai biežāk. Šos simbolus liek figūriekavās "{" un "}". Skaitlis pirms "{" norāda uz minētās simbolu grupas minimāli atļauto parādīšanās biežumu. Skaitlis aiz "}" norāda uz minētās simbolu grupas maksimāli atļauto parādīšanās biežumu. Izvēles iespēja - kad dažādi alternatīvi simboli var parādīties kādā vietā, kā tas noteikts gramatikā. Uz izvēles iespēju norāda "|". Konkatenācija - cits aiz cita izvietotu simbolu atveide neatkarīgi no viena vai vairāku atdalītāju klātbūtnes. Šeit nepastāv skaidri formulēta atveide. Atšķir divus tās veidus: - stingrā konkatenācija - leksiskajā līmenī noteikumi var paredzēt simbolu konkatenāciju, norādot, ka tie izvietoti tieši cits aiz cita (bez atdalītājiem), šajā gadījumā jāizmanto simbols "!" . Piemērs. datetime:: = date! timehhmm piemēram, "9912251200" nozīmē 1999. gada 25. decembrī, plkst. 12:00, - brīvā konkatenācija - starp simboliem atļauts izmantot atdalītājus. Brīvās konkatenācijas atveide noteikuma ietvaros var būt netieša vai skaidra. Piemēri 1) netieša: dct::= '-' "DCT" point point 2) skaidra: dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point piemēram, | "-DCT NTM HMS". | PIEZĪMES 1) Konkatenācijai vienmēr ir prioritāte pār izvēles iespēju. Apaļās iekavas "(" un ")" lieto, lai mainītu izteiksmes novērtēšanas kārtību. Piemērs a::= B C | D | ir līdzvērtīgs: | a::= (B C) | D | | un NEVIS: | a::= B (C | D) | 2) Lasāmības saglabāšanas labad visos noteikumos atļautā atdalītāju izmantošana starp simboliem paliek netieši noteikta. Ieteikums. Ja pastāv pārpratumu risks iepriekš minēto operatoru prioritātes dēļ, ieteicams lietot apaļās iekavas, lai ieviestu skaidrību vēlamajā novērtēšanas kārtībā. 3.6. Saīsinājumi Šajā Eurocontrol standartā lieto šādus saīsinājumus: ACH | Šajā Eurocontrol standartā lieto šādus saīsinājumus: | ADEG | ATS datu apmaiņas grupa | ADEXP | ATS datu apmaiņas atveide | AFIL | gaisa kuģa raidīts lidojuma plāns | AFP | ATC lidojuma plāna ierosinājums | AFTN | stacionārais aeronavigācijas sakaru tīkls | ANM | ATFM paziņojums | AO | gaisa kuģa ekspluatants(-i) | APL | ATC lidojuma plāns | ATC | gaisa satiksmes vadība | ATCU | gaisa satiksmes vadības struktūrvienība(-s) | ATFM | gaisa satiksmes plūsmas pārvaldība | ATS | gaisa satiksmes vadības dienesti | BNF | Backus Naur Form | CASA | datorizēta laika nišu sadale | CIDIN | Kopējais ICAO datu apmaiņas tīkls | CFL. | atļautais lidojuma līmenis | CFMU | Centrālā gaisa satiksmes plūsmu pārvaldības institūcija | CMTP | kopējais vidēja termiņa plāns | CNL | atcelšanas ziņojums | CTOT | aprēķinātais pacelšanās laiks | DPS | datu apstrādes sistēmu domēns | ECAC | Eiropas Civilās aviācijas konference | EFL | aprēķinātais lidojuma līmenis | EOBT | aprēķinātais bremžu paliktņu noņemšanas laiks | ETO | nozīmīga punkta pārlidošanas aprēķinātais laiks | Eurocontrol | Eiropas Aeronavigācijas drošības organizācija | EWPD | EATCHIP darba programmas dokuments | FIR | Lidojumu informācijas rajons | FIW | lidojuma plānu ievades darbstacija | FMP | satiksmes plūsmas pārvaldības punkts | FNM | lidojuma pieteikuma ziņojums | FPL | lidojuma plāna ziņojums (ICAO formātā) | GAT | vispārējas nozīmes gaisa satiksme | IA | starptautiskais alfabēts | IAFP | atsevišķs ATC lidojuma plāna ierosinājums | ICAO | Starptautiskā civilās aviācijas organizācija | IFPD | atsevišķa lidojuma plāna dati | IFPS | sākotnējā lidojuma plāna integrētā apstrādes sistēma | IFPU | IFPS struktūrvienība | IFR | instrumentālo lidojumu noteikumi | ISO | Starptautiskā standartizācijas organizācija | ITA | starptautiskais telegrāfa alfabēts | LAM | loģiskā apstiprinājuma ziņojums | LRM | loģiskā atteikuma ziņojums | MAC | koordinācijas atcelšanas ziņojums | MFS | ziņojums no Šanvikas | OAT | operatīvie gaisa pārvadājumi | OLDI | datu apmaiņa tiešsaistē | RFL | pieprasītais lidojuma līmenis | RFP | rezerves lidojuma plāns | RFPD | daudzkārtēja lidojuma plāna dati | RPL | daudzkārtējs lidojuma plāns | RVR | redzamība uz skrejceļa | SFL | lidojuma papildus līmenis | SRD | programmatūras specifikācijas dokuments | SSR | sekundārais novērošanas radiolokators | TACT | CFMU taktikas sistēma | TOS | satiksmes orientācijas shēma | UIR | augšējās gaisa telpas lidojumu informācijas rajons | VFR | vizuālo lidojumu noteikumi | 4. ADEXP PRINCIPI 4.1. Viegli lasāms teksta formāts 4.1.1. ADEXP formāts ir teksta formāts, kam pamatā ir rakstzīmes. 4.1.2. Dispečers var viegli izlasīt ADEXP ziņojumu, kas atvieglo ekspluatācijas jautājumu risināšanu vai saskaņošanu. 4.1.3. Turklāt teksta formāts ir pieejamāks un saprotamāks. 4.2. Atpazīstami un izgūstami lauki 4.2.1. Ziņojums ADEXP formātā sastāv no laukiem. 4.2.2. Laukiem jābūt norobežotiem ar īpašu lauka sākumzīmi, savienojuma zīmi ( "-" ), un tos atpazīt palīdz īpaši atslēgvārdi. PIEZĪME. Būtu jāpiebilst, ka dažos laukos (kas saskaņā ar sintakses definīciju satur leksisko vienību "CHARACTER") ir pieļaujama rakstzīme "-", kas ietilpst lauka saturā. 4.2.3. Šāda pieeja piešķir šim formātam paplašināšanas iespējas un robustumu. (Ja kāds lauks nav atrodams vai tas ir nepareizs, var veikt pārlēcienu, kas netraucē uztvert atlikušo ziņojuma daļu.) (Skatīt 4.3. iedaļu). 4.2.4. Tāpēc pēc lauku secības ziņojumā nevar spriest par tā derīgumu, tas neattiecas uz pirmo lauku (obligātais virsraksta lauks), kas nosaka atļautos laukus. 4.2.5. Var atšķirt vienkāršos un saliktos laukus. 4.2.6. Salikto lauku sastāvdaļas dēvē par apakšlaukiem - uz tiem norāda atslēgvārdi, un tos norobežo ar lauka sākumzīmi. 4.2.7. Vienkāršie lauki ir lauki, kas nesatur apakšlaukus. 4.2.8. Vienkāršos un saliktos laukus, kas veido ziņojuma definīcijas pirmo līmeni, dēvē par tā primārajiem laukiem. 4.2.9. Pēc definīcijas visas zemāka līmeņa sastāvdaļas ir apakšlauki, kas savukārt var būt vienkāršie vai saliktie lauki. 4.2.10. Saliktie lauki var būt divējādi - strukturēti lauki un sarakstlauki. 4.2.11. Strukturētiem laukiem ir iepriekš noteikts saturs, un tie sastāv tikai no apakšlaukiem. Strukturēta lauka apakšlauku secībai NAV noteicošas nozīmes. 4.2.12. Sarakstlaukus ievada atslēgvārds BEGIN un noslēdz atslēgvārds END. Starp tiem var atkārtoti atrasties viens un tas pats apakšlauks vai apakšlauku kombinācija. To atkārtošanās secībai sarakstlaukā ir semantiska nozīme. 4.2.13. Turpmāk terminu "lauks" lietos vispārējā nozīmē primāro lauku un/vai apakšlauku apzīmēšanai, ja vien nav skaidri noteikts citādi. 4.2.14. Ziņojumā iekļauti lauki var būt fakultatīvi vai obligāti, atkarībā no sintakses. 4.3. Neatpazīti lauki 4.3.1. Ja ziņojumā parādās nezināms lauks, tas tiek ignorēts. 4.3.2. Tātad, ja sistēma, kas analizē ziņojumu, neatpazīst atslēgvārdu, tā ignorēs visu tekstu līdz nākamajam pazīstamajam primārajam laukam, kurš neietilpst sarakstlaukā. 4.3.3. Atkarībā no ziņojuma virsraksta, lauka ignorēšana var būt iespējamais iemesls analizējamā ziņojuma atteikšanai. PIEZĪME. Būtu jāpiezīmē, ka, lai gan ADEXP piemīt šāda elastība, tomēr to personu ziņā, kuru pienākums ir noteikt saskarnes specifikāciju, ir norādīt, kā sistēmai būtu jāreaģē uz neatpazītu lauku katrā atsevišķā ziņojumā. 4.3.4. Ja nezināmais lauks ir sarakstlauks (ko konstatē pēc atslēgvārda -BEGIN), tad viss tā saturs (līdz attiecīgajam atslēgvārdam -END) tiek ignorēts. 4.3.5. Lai novērstu jebkuru neskaidrību atkopšanas laikā, kas seko neatpazīta lauka pārlēkšanai, primārajam laukam vai apakšlaukam jāsākas ar atslēgvārdu. 4.3.6. Tas ļauj definēt divējādus atslēgvārdus: - primāros atslēgvārdus, - apakšatslēgvārdus. 4.3.7. Tiklīdz nosaka atslēgvārda veidu, to nedrīkst turpmāk izmantot citā ziņojumu grupā kā cita veida atslēgvārdu, izņemot gadījumus, kad tas ietilpst sarakstlaukā. Primārais atslēgvārds var atrasties jebkurā vietā sarakstlauka iekšienē, neradot pārpratumus, jo atslēgvārds BEGIN norāda, ka tā atrašanās sarakstlauka iekšienē ļauj to uzskatīt par apakšlauku. Piemēri (abu atslēgvārdu veidu lietojumam) 1) primārais lauks -RFL F330 2) apakšlauks - vienmēr atrodas "saliktā lauka" iekšienē -GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W kur -GEO ir primārais saliktais lauks, bet -GEOID, -LATTD un LONGTD ir apakšlauki; 3) sarakstlauks -BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID … -END RTEPTS kur "-BEGIN" ir sarakstlauka indikators, bet "RTEPTS" ir primārais lauks. PIEZĪME. "RFL" ir definēts kā primārais lauks. Primārā lauka iekļaušana sarakstlaukā ir vienīgais gadījums, kad to var izmantot kā apakšlauku. (Skatīt 3. piemēru.) 5. ADEXP SINTAKSES NOTEIKUMI 5.1. Leksiskās sastāvdaļas 5.1.1. Rakstzīmju kopa 5.1.1.1. Ziņojumu apmaiņai ADEXP formātā izmantojamā rakstzīmju kopa ir starptautiskais alfabēts Nr. 5 (IA-5), kā tas noteikts norādē Nr. 1. 5.1.1.2. ADEXP formāts radīts kā datu apmaiņas formāts starp datoriem, ko var pārraidīt dažādos datortīklos vai īpašās starpdatoru saitēs. Turklāt pastāv prasība, ka ir jānodrošina dažu ADEXP ziņojumu apmaiņa, parasti saistībā ar lidojumu plānošanu un ATFM, Stacionārajā aeronavigācijas sakaru tīklā (AFTN). 5.1.1.3. Ziņojumos, kas ir nosūtāmi ar AFTN starpniecību, jāizmanto rakstzīmju kopa, kas satur tikai tās rakstzīmes, kuras tieši atbilst starptautiskajam telegrāfa alfabētam Nr. 2 ( ITA-2 ) un IA-5 , kā tas definēts norādē Nr.1. PIEZĪME. Bez turpmāk definētajām grafiskajām rakstzīmēm un izkārtojuma rakstzīmēm rakstzīmju kopā ITA-2 definēti arī "signāli" (piemēram, perfolente). Tie nav iekļauti atļautajā ADEXP ziņojumu rakstzīmju kopā. 5.1.1.4. ADEXP ziņojumos, ko var pārraidīt ar AFTN starpniecību, atļauts izmantot šādas grafiskās rakstzīmes un izkārtojuma rakstzīmes: grafiskās rakstzīmes a) lielos burtus (no A līdz Z) b) ciparus (no 0 līdz 9) c) īpašas grafiskās rakstzīmes: 1) atstarpes rakstzīmi "" 2) kreiso iekavu "(" 3) labo iekavu ")" 4) defisi "-" 5) jautājuma zīmi "?" 6) kolu ":" 7) punktu "." 8) komatu "," 9) apostrofu "'" 10) vienādības zīmi "=" 11) plusa zīmi "+" 12) slīpsvītru "/" izkārtojuma zīmes a) rakstatgriezi b) rindpadevi 5.1.2. Leksiskās pamatvienības Šajā specifikācijā noteikts šādu leksisko pamatvienību lietojums: - 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 PIEZĪME. LIM_CHAR apzīmē jebkuru atļautu rakstzīmi, izņemot HYPHEN, kas vienīgi kalpo, lai norādītu lauka sākumu. Turpretim CHARACTER apzīmē jebkuru atļautu rakstzīmju kopas sastāvdaļu. 5.1.3. Rindas, atdalītāji un norobežotāji 5.1.3.1. Ziņojuma teksta sadalījums rindās neietekmē tā sintaksi. 5.1.3.2. Atdalītājs var būt atstarpes zīme vai izkārtojuma zīme. 5.1.3.3. Laukus norobežo tikai ar lauka sākumzīmes palīdzību, aiz kuras stāv atslēgvārds. 5.1.3.4. Tātad visu ziņojumu var ar pilnām tiesībām izvietot vienā rindiņā. 5.1.4. Vērtības ar "+" vai "-" zīmi 5.1.4.1. Atsevišķos gadījumos ir jānorāda, ka skaitlim ir negatīva vērtība. 5.1.4.2. To lauku sintakses definīcijā, kas nepieciešami negatīvas vērtības apzīmēšanai, skaidri jānorāda, ka vērtība ir ar "+" vai "-" zīmi, proti, tā ir pozitīva vai negatīva. Lauks, kas nav šādi definēts, nevar apzīmēt negatīvu vērtību. 5.1.4.3. Vērtību ar "+" vai "-" zīmi vienmēr ievada burts "N" vai "P", kas attiecīgi norāda uz negatīvu vai pozitīvu vērtību. Lielumu ar nulles vērtību var ievadīt gan "N", gan "P". 5.1.4.4. Laukam, kas pieļauj vērtību ar "+" vai "-" zīmi, ir šāda sintakse: '-' "KEYWORD" ("P" | "N") ! 1{DIGIT} Piemērs.Lauks ar apzīmējumu "NUMBER", kurā var ietilpt negatīva vērtība, kas sastāv no viena līdz astoņiem cipariem, būtu jāatveido šādi: '-' "NUMBER" ("P" | "N") ! 1{DIGIT}8 Tādēļ: -NUMBER P5 - atbilst vērtībai + 5 -NUMBER N5 - atbilst vērtībai -5 -NUMBER 5 - nederīga sintakse, obligāti jābūt burtam "P" vai "N" 5.1.5. Atslēgvārdi 5.1.5.1 Atslēgvārds ir jebkura lielo burtu vai ciparu secība. Tas ievada lauku tikai tad, ja tam priekšā ir lauka sākumzīme ("-"). keyword::= 1{ ALPHANUM } 5.1.5.2. Atslēgvārdu sintaksei jābūt šādai: '-'!{SEP}!"KEYWORD"!1{SEP}! < subfield/s or contained value > proti, atslēgvārds tiek nodalīts no attiecīgās "lauka sākumzīmes" ar nulles atdalītāju vai vairākiem atdalītājiem. Uzreiz aiz tā jābūt vienam vai vairākiem atdalītājiem un attiecīgajam apakšlaukam(-iem) vai iekļautajam lielumam. PIEZĪME. Svarīgi atzīmēt, ka atslēgvārdu var nošķirt no priekšā novietotās lauka sākumzīmes ar jebkuru skaitu atdalītāju, arī nevienu. Piemēri (visas šīs secības var ievadīt lauku) 1) -TITLE IFPL 2) - TITLE IFPL 3) - TITLE IFPL 4) - TITLE IFPL 5.1.5.3. Ieteikums. Neiesaka izmantot atdalītāju starp lauka sākumzīmi "-"un nākamo atslēgvārdu. PIEZĪME 1) No iepriekš minētajiem paraugiem iesaka izvēlēties pirmo variantu. 2) Turklāt ir jāpiezīmē, ka uzreiz aiz atslēgvārda jābūt vismaz vienam atdalītājam. 5.1.5.4. Uz to vienību konkatenāciju, kas nošķirtas vismaz ar vienu atdalītāju, visā dokumentā netieši norāda notācijas sistēma "brīvā konkatenācija" (skatīt 3.5. punktu). PIEZĪME. Kā tiks paskaidrots tālāk, atslēgvārdi ievada arī sarakstlaukus, ja tiem priekšā ir atslēgvārds BEGIN. 5.1.5.5. Atslēgvārdiem jābūt pēc iespējas īsākiem, tajā pašā laikā saglabājot savu semantisko nozīmi. 5.1.5.6. Iepriekš definētos ADEXP formāta atslēgvārdi, kas uzskaitīti tālāk, nedefinē no jauna un neizmanto citā nolūkā īpašos formāta lietojumos. TITLE: | apzīmē ziņojumu kategoriju un nosaka attiecīgo atļauto primāro lauku kopu; | BEGIN: | apzīmē sarakstlauka sākumu; | END: | apzīmē sarakstlauka beigas; | COMMENT: | apzīmē lauku COMMENT. | 5.1.5.7. Lai izvairītos no nenoteiktības (viena un tā paša atslēgvārda paralēlas lietošanas ar citu nozīmi) vai redundances (vairākiem atslēgvārdiem ar vienādu nozīmi), šā standarta A pielikumā (A3) ir ietverta primāro lauku definīciju pamattabula, kā arī A pielikumā (A4) ietverta apakšlauku (tas ir, apakšatslēgvārdu) definīciju pamattabula. 5.2. Lauki 5.2.1. Lauku sintakse 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 PIEZĪME. Kā būs redzams sarakstlauku gadījumā, atslēgvārdam tieši priekšā atrodas nevis "-", bet struktūra "-""BEGIN". 5.2.2. Ziņojumu struktūra lauku līmenī 5.2.2.1. ADEXP ziņojumā pirmajam laukam vienmēr jābūt laukam TITLE (tātad laukam, ko ievada atslēgvārds TITLE). 5.2.2.2. Kas attiecas uz ziņojuma primārajiem laukiem, tā pārējo saturu nosaka lauks TITLE. 5.2.2.3. Konkrētam TITLE atbilstīgo ziņojumu sintaksi nosaka tajā ietilpstošie lauki (ko definē to atslēgvārdi): - to primāro lauku vārds un atļautais saturs, - to apakšlauku vārds un atļautais saturs. 5.2.3. Vienkāršie lauki 5.2.3.1. Vienkāršo lauku sintakse ir šāda: basic_field::= '-' keyword contained_values 5.2.3.2. "Contained_values" (iekļautās vērtības) nosaka tekstu, kas nodrošina lauka vērtību, un to nedrīkst izmantot apakšlauku ievadīšanai. Noteikuma piemērs. arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ") PIEZĪME 1) Tai skaidri līdzvērtīgs noteikums ir: arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ"). 2) Ziņojuma daļas paraugs: "-ARCTYP ZZZZ". 5.2.3.3. Ieteikums. Ja vienkāršais lauks satur vairāk nekā divas iekļautās vērtības, un turklāt ir jānorāda uz vērtību "izvēles iespēju" jeb "opciju", būtu ieteicams pārvērst lauku strukturētā laukā un ietvert iekļautās vērtības apakšlaukos. 5.2.4. Sarakstlauki 5.2.4.1. Sarakstlaukiem ir šāda sintakse: list_field ::='-' "BEGIN" keyword { subfields } '-' "END" keyword 5.2.4.2. "Apakšlaukus" var veidot jebkura apakšlauku kombinācija, to sastopamība sarakstlauka iekšienē var būt vienāda ar nulli vai lielāka. 5.2.4.3. Konkrētā sarakstlaukā ietilpstošo apakšlauku saraksts veido sakārtotu kopu (apakšlauku secībai ir būtiska nozīme). Noteikuma piemērs. addr ::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR" PIEZĪME 1) No šā parauga izriet, ka lauks "addr" ir sarakstlauks, kurā apakšlauka "fac" (ATS iekārta), sastopamība ir vienāda ar 0 vai lielāka. 2) Ziņojuma daļas paraugs, kurā ADDR ir sarakstlauks, kas satur apakšlaukus FAC: -BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR. 3) Ziņojuma daļas paraugs, kas sastāv no apakšlauku kombinācijas: xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX". 5.2.5. Strukturēti lauki 5.2.5.1. Strukturētiem laukiem ir šāda sintakse: structured_field::= '-' keyword field_1 field_2…field_n 5.2.5.2. Atļautie iekļautie apakšlauki konkrētā strukturētā laukā ir atkarīgi tikai no paša strukturētā lauka. 5.2.5.3. Apakšlauku secībai strukturētā laukā nav būtiskas nozīmes, tas ļauj tos turpmāk viegli paplašināt (pievienojot jaunus iekļautos apakšlaukus). Noteikuma piemērs. pt::= '-' "PT" ptid [fl] [eto] PIEZĪMES 1) Lauks "pt" šeit ir definēts kā strukturēts lauks, kas satur punktu (apakšlauks "ptid"), aiz kura var fakultatīvi atrasties aprēķinātais lidojuma līmenis (apakšlauks "fl"), aiz kura var fakultatīvi atrasties nozīmīga punkta pārlidošanas aprēķinātais laiks (apakšlauks "eto"). 2) Minētā lauka sastopamība, piemēram, var būt: "-PT -PTID RMS -FL F250 -ETO 921225120000". 5.2.5.4. Ieteikums. Ja nojauš, ka lauka saturs var mainīties nākotnē, būtu vēlams to pārvērst strukturētā laukā. Tad būs iespējams pakāpeniski paplašināt tā apakšlaukus. Tajā pašā laikā vienkāršo lauku var vieglāk un ērtāk izmantot, bet tas paredz nemainīgu sastāvdaļu (vērtību) secību ar visai ierobežotām paplašināšanas iespējām. 5.2.6. Lauks COMMENT 5.2.6.1. Lauks COMMENT (piezīmes) ievada brīvi izvēlēta teksta zonu, kurā var izmantot visas pieejamās rakstzīmes, izņemot lauka sākumzīmi ("-"), un kas sniedzas līdz nākamajam laukam. comment::= '-' "COMMENT" { LIM_CHAR } Piemērs COMMENT THIS IS THE BEGINNING OF A FREE ROUTE TEXT AREA (komentář: Toto je začátek oblasti volného textového popisu tratě) 5.2.7. Lauks TITLE (virsraksts) 5.2.7.1. ADEXP ziņojums vienmēr sākas ar lauku TITLE. Tam ir šāda sintakse: title::= '-' "TITLE" 1{ ALPHA }10 5.2.7.2. Lauka TITLE iespējamās vērtības aptver ADEXP ziņojumu virsrakstu kopu, kas uzskaiti šā standarta B pielikumā. Piemērs -TITLE IFPL 6. ADEXP ZIŅOJUMU NORMALIZĒTS APRAKSTS 6.1. Ievads 6.1.1. Turpmākajos punktos aplūkots, kā normalizētā veidā jāapraksta dažādu ziņojumu kategoriju ADEXP formāts saistībā ar šo standartu. 6.1.2 Normalizētajā aprakstā ietilpst: - palīgtermu noteikšana, - katra atsevišķa primārā lauka sintakses un semantikas noteikšana, - katra atsevišķa apakšlauka sintakses un semantikas noteikšana, - katras ziņojumu grupas noteikšana, ņemot vērā reglamentējošos dokumentus. 6.1.3. Šajā standartā nav tuvāk aplūkota katra ziņojuma virsraksta lauku struktūra un datu iestrādes noteikumi. 6.1.4. Būtu jānorāda reglamentējošie dokumenti (saskarnes specifikācija), kas skar attiecīgo ziņojumu grupu (skatīt 6.5.7. iedaļu). 6.1.5. Reglamentējošiem dokumentiem normalizētā veidā jānodrošina šāda informācija par katra ziņojuma virsrakstu: - obligāto primāro lauku uzskaitījums, - fakultatīvo primāro lauku uzskaitījums, - datu iestrādes noteikumi katram laukam un jo īpaši to apakšlauku izmantošanas noteikumi, kas šajā standartā definēti kā fakultatīvi apakšlauki, - atkopšanas noteikumi pēc neatpazīta lauka konstatēšanas. 6.1.6. Eurocontrol dalībvalstīs pašlaik noteiktie un saskaņotie lauki, kas paredzēti izmantošanai dažādās ADEXP ziņojumu kategorijās, ir apkopoti šā dokumenta A pielikumā. 6.1.7. Jebkuru lauku drīkst izmantot tikai tā semantiskajā aprakstā norādītajam nolūkam. 6.1.8. Centrālais rezervēto lauku indekss ir iekļauts D pielikumā. Nav panākta vienošanās par "rezervēto lauku" izmantošanu pašlaik noteiktajos ADEXP ziņojumos. Tie ir galvenokārt lauki, kas paredzēti varbūtējai izmantošanai nākotnē vai kurus izmanto tikai atsevišķu valstu sistēmās. To iekļaušana šajā standartā palīdzētu nodrošināt lauku virsrakstu unikalitāti un izvairīties no nevajadzīgas redundances. 6.2. Palīgtermi 6.2.1. Lai lauku definīcija būtu nolasāma, bieži vien gramatikas aprakstā der ieviest palīgtermus. 6.2.2. Palīgtermi neievada lauku vai apakšlauku, tātad tie nav saistīti ar kādu konkrētu atslēgvārdu. Tomēr tie var būt sastopami vairāk nekā viena lauka, apakšlauka vai palīgterma definīcijā. Piemēram, tādu palīgtermu kā "date" (datums) var izmantot, definējot daudzus laukus. 6.2.3. Visi vajadzīgie palīgtermi jāiekļauj alfabēta kārtībā, un tie definēti šā standarta A pielikumā (A2). 6.2.4. To aprakstu var apkopot šādā tabulā, ievērojot alfabēta kārtību: Palīgterms | Syntaxe | Semantika | Izmanto primārajā laukā | Izmanto apakšlaukā | Izmanto palīgdaļā | adexpmsg | { CHARACTER } | Brīvi izvēlēts teksts, kurā ievēro ADEXP ziņojuma sintaksi. | | ifpdlong rfpdlong preproctxt postproctxt | | aidequipment | ( ('N' | 'S') ! [ equipmentcode ] ) | equipmentcode | Radiosakaru, navigācijas un pieejas vadības iekārtas. | ceqpt | | | aircraftid | 1{ ALPHANUM }7 | Gaisa kuģa identifikācijas indekss. | arcid arcidk arcidold prevarcid | | | 6.3. Primāro lauku definīcija 6.3.1. Visos primārajos laukos, ko izmanto ADEXP ziņojumos, jāievēro sintakse un semantika saskaņā ar šā standarta A pielikumu (A3). 6.3.2. Vispirms tiks aplūkota katra lauka sintakse, tad semantika, izmantojot skaidrus un nepārprotamus terminus. 6.3.3. Lauku sintakses atveidošanai tiks izmantota BNF notācija, kas aplūkota šā standarta 3. iedaļā. 6.3.4. Šo aprakstu var apkopot šādā tabulā, ievērojot alfabēta kartību, kurā: - pirmajā slejā attēlota BNF noteikuma kreisā daļa (proti, noteikuma daļa, kas atrodas pa kreisi no simbola "::="), un trešajā slejā attēlota tā labā daļa, - otrajā slejā (Veids) norādīts, vai tas ir vienkāršais ("b") vai saliktais ("c") lauks. Primārais lauks | Veids | Sintakse | Semantika | eobt | b | '-' "EOBT" timehhmm | Aprēķinātais bremžu paliktņu noņemšanas laiks | 6.4. Apakšlauku noteikšana 6.4.1. Visos apakšlaukos, ko izmanto ADEXP ziņojumos, jāievēro sintakse un semantika saskaņā ar šā standarta A pielikumu (A4). 6.4.2. Turklāt, lai atvieglotu mijnorādes, minēti primārie lauki, kuros atrodams konkrēts apakšlauks. 6.4.3. Tā kā apakšlauks var būt arī apakšlauks citos apakšlaukos, nodrošināta mijnorāde arī šiem apakšlaukiem. 6.4.4. Šo aprakstu var apkopot šādā tabulā, ievērojot alfabēta kartību: Apakšlauks | Veids | Sintakse | Semantika | Izmanto primārajā laukā | Izmanto apakšlaukā | brng | b | '-' "BRNG" refbearing | Punkta peilējums no aeronavigācijas līdzekļa (grādos attiecībā pret magnētisko meridiānu) | ref | | 6.5. Ziņojumu grupa 6.5.1. Operacionālās ziņojumu kategorijas (grupas), kas noteiktas izmantošanai ADEXP formātā, ir aplūkotas šā standarta E pielikumā. 6.5.2. Šīs grupas noteiktas pēc apmaināmo ziņojumu operacionālā satura, un tās bieži raksturojamas saistībā ar izmantoto sistēmu. 6.5.3. Katrai ziņojumu grupai jānorāda reglamentējošie dokumenti. 6.5.4. Vērtību TITLE, kas jau izmantota kādā ziņojumu grupā, nedrīkst no jauna izmantot ar citu nozīmi citā grupā. 6.5.5. Centrālais ziņojumu virsrakstu indekss iekļauts šā standarta B pielikumā. 6.5.6. Katram ziņojumu virsrakstam, kas uzskaitīts centrālajā ziņojumu virsrakstu indeksā, nodrošināta norāde uz saistīto grupu. Tādēļ norādi uz reglamentējošajiem dokumentiem katram ziņojuma virsrakstam nodrošina ar šīs ziņojumu grupas starpniecību. 6.5.7. C pielikumā ietverts arī centrālais rezervēto lauku indekss. Nav panākta vienošanās par "rezervēto" ziņojumu virsrakstu izmantošanu pašlaik noteiktajās ADEXP ziņojumu grupās. Tie ir galvenokārt ziņojumi, kas paredzēti varbūtējai izmantošanai nākotnē kādā no noteiktajām grupām vai kurus izmanto tikai atsevišķu valstu sistēmās. To iekļaušana šajā standartā palīdzētu nodrošināt ziņojumu virsrakstu unikalitāti un izvairīties no nevajadzīgas redundances. -------------------------------------------------- III PIELIKUMS SASKARNES KONTROLDOKUMENTS LIDOJUMU DATU APMAIŅAI (FDE-ICD), REDAKCIJA 1.0 (Eurocontrol dokumentu šifrs COM.ET1.ST12-STD) SATURS AUTORTIESĪBU ATRUNA… PRIEKŠVĀRDS… 1. IEVADS… 2. DARBĪBAS JOMA… 3. NORĀDES… 3.1. Ievads… 3.2. Norādes… 4. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI… 4.1. Definīcijas… 4.2. Simboli un saīsinājumi… 4.3. Notācijas… 5. TEHNISKAIS APSKATS… 5.1. Protokolu steks… 5.2. Profila struktūra… 5.3. Saistība ar iepriekšējām specifikācijas versijām… 6. PROFILA PARAMETRI… 6.1. Standartatbilstības parametri… 6.2. Augšējo slāņu parametri… 6.3. Apakšējo slāņu parametri… 6.3.1. Transporta slāņa parametri… 6.3.2. Tīkla slāņa parametri… 6.3.3. Datu posma slāņa parametri… 6.3.4. Fizikālā slāņa parametri… 7. PĀRBAUDES METODES… A PIELIKUMS (NORMATĪVS) ZIŅOJUMA PĀRSŪTĪŠANAS PROTOKOLS… A.1. Ievads… A.2. Sniegtais pakalpojums… A.3. Pārņemtais pakalpojums… A.4. Protokola specifikācija… A.4.1. Ievads… A.4.2. Datu tipi… A.4.3. Asociācijas izveidošana… A.4.4. Datu pārsūtīšana… A.4.5. Sakārtotā asociācijas izjaukšana… A.4.6. Asociācijas atjaunošana… A.4.7. Asociācijas integritāte… A.4.8. Nesakārtotā asociācijas izjaukšana… A.4.9. Pēckļūmes atkopšana… A.4.10. Ziņojumu formāti… A.5. Protokola stāvokļu tabulas… A.5.1. Ievads… A.5.2. Stāvokļa definīcijas… A.5.3. Iespējamie notikumi… A.5.4. Taimeri… A.5.5. Stāvokļu tabula… A.5.6. Stāvokļu diagramma… B PIELIKUMS (NORMATĪVS) ZIŅOJUMA GALVENES PROTOKOLS… B.1. Ievads… B.2. Sniegtais pakalpojums… B.3. Požadované služby… B.4. Protokola specifikācija… B.4.1. Savienojuma izveidošana… B.4.2. Nodrošināšanās pret liekiem tīkla savienojumiem… B.4.3. Savienojuma izjaukšana… B.4.4. Datu pārsūtīšana… C PIELIKUMS (NORMATĪVS) TĪKLA PROTOKOLS… C.1. Ievads… C.2. Sniegtais pakalpojums… C.3. Pārņemtais pakalpojums… C.4. NSAP adresēšana… C.4.1. Ievads… C.4.2. NSAP adrešu struktūra… C.4.3. ATC struktūrvienību identifikatoru un selektoru piešķiršana… C.5. Protokola specifikācija… C.5.1. Īss apskats… C.5.2. Adrešu šifrēšana… C.5.3. Lietotāja datu lauka šifrēšana… C.5.4. Adrešu apstrāde INCOMING CALL paketēs… C.5.5. Datu pārsūtīšana… D PIELIKUMS (NORMATĪVS) PROFILRAKSTURĪGĀS PICS PROFORMAS… D.1. Ievads… D.2. PICS proformu aizpildīšanas norādījumi… D.2.1. Vispārējā PICS proformu struktūra… D.2.2. Papildinformācija… D.2.3. Izņēmumi… D.2.4. Nosacītie vienumi… D.3. Ziņojuma pārsūtīšanas protokola PICS proforma… D.3.1. Saīsinājumi un īpaši simboli… D.3.2. Apraksts… D.3.3. Protokola implementēšana… D.4. Ziņojuma galvenes protokola PICS proforma… D.4.1. Saīsinājumi un īpaši simboli… D.4.2. Apraksts… D.4.3. Protokola implementēšana… D.5. Tīkla protokola PICS proforma… D.5.1. Saīsinājumi un īpaši simboli… D.5.2. Apraksts… D.5.3. Protokola implementēšana… E PIELIKUMS (NORMATĪVS) PROFILA PARAMETRU SARAKSTS… E.1. Ievads… E.2. PRL un PICS proformu nozīme… E.3. Notācija… E.4. PICS proformu aizpildīšanas norādījumi… E.5. Norādes… E.6. Standartatbilstības formulējums… E.6.1. Īss standartatbilstības apskats… E.6.2. Dinamiskās standartatbilstības prasības… E.7. Augšējo slāņu parametri… E.8. Apakšējo slāņu parametri… E.8.1. Transporta slāņa parametri… E.8.2. Tīkla slāņa parametri… E.8.3. Datu posma slāņa parametri… E.8.4. Fizikālā slāņa parametri… F PIELIKUMS (INFORMATĪVS) STANDARTATBILSTĪBAS TESTĒŠANAS METODIKA… F.1. Ievads… F.2. Mērķis un darbības joma… F.3. Bibliogrāfija… F.4. Pilnveidošanas paņēmieni un prakse… F.5. Pārbaudes… F.5.1. Ievads… F.5.2. Apakšējo slāņu (1. līdz 3. slānis) pārbaude… F.5.3. Lietojumprogrammas slāņa pārbaude… F.5.4. Sertificēšana… F.5.5. Izziņošana… G PIELIKUMS (INFORMATĪVS) IDENTIFIKATORU PIEŠ-IRŠANA ATC STRUKTŪRVIENĪBĀM… H PIELIKUMS (INFORMATĪVS) UZTICAMĪBAS, PIEEJAMĪBAS UN DROŠĪBAS IETEIKUMI… H.1. Ievads… H.2. Mērķis un darbības joma… H.3. Bibliogrāfija… H.4. Implementācijas, kurās izmanto nomātas līnijas… H.4.1. Uzticamība… H.4.2. Pieejamība… H.4.3. Drošība… H.4.4. Konfigurācijas piemērs… H.5. Tīkla implementēšana… H.5.1. Uzticamība… H.5.2. Pieejamība… H.5.3. Drošība… H.6. Vispārēji ieteikumi nomātas līnijas un tīkla implementēšanai… H.6.1. Uzticamība… H.6.2. Pieejamība… H.6.3. Sistēmu pārvaldība… H.6.4. Konfigurācijas piemērs… AUTORTIESĪBU ATRUNA Šis dokuments sagatavots Eiropas Aeronavigācijas drošības organizācijas (Eurocontrol) aģentūrā. Autortiesības pieder Eurocontrol aģentūrai. Tādējādi dokumenta vai jebkuras tā daļas saturs ir brīvi pieejams dalībvalstu pārstāvjiem, bet tā pavairošanai vai izpaušanai jebkurai citai personai ir vajadzīga Eurocontrol aģentūras rakstiska piekrišana. PRIEKŠVĀRDS 1. Atbildīgā iestāde Šo standartu sagatavojusi un tā atjaunināšanu veic Eiropas Aeronavigācijas drošības organizācijas (Eurocontrol) Lidojuma plāna datu apmaiņas (FPDE) darba grupa. 2. EATCHIP darba programmas dokuments Šis standarts ir saistīts ar EATCHIP darba programmas dokumenta (EWPD) sakaru jomā vadības nodrošināšanas uzdevuma 01 speciālo uzdevumu Nr. 12. 3. Standarta apstiprināšana 3.1. Šis standarts pieņemts saskaņā ar kārtību, kas izklāstīta Eurocontrol standartizācijas direktīvās, reģ. Nr. 000-2-93. 3.2. Šis standarts stājas spēkā pēc apstiprināšanas Eurocontrol pastāvīgajā komisijā un aizstāj Eirocontrol standarta datu apmaiņas tiešsaistē (OLDI), redakcija 1, 3. daļu: TEHNISKĀS PRASĪBAS (Saskarnes īstermiņa kontroldokuments), reģ. Nr. 001-3-92. 4. Tehniskie labojumi un grozījumi Šo standartu pastāvīgi pārskata, veicot nepieciešamos grozījumus vai tehniskos labojumus. Šā standarta precizēšanas kārtība izklāstīta H pielikumā, kas pievienots Eurocontrol standartizācijas dokumentu vienotās sagatavošanas un noformēšanas direktīvām, reģ. Nr. 000-1-92. 5. Redakcionālās norunas 5.1. Šā standarta formāts ir saskaņā ar Eurocontrol standartizācijas dokumentu vienotās sagatavošanas un noformēšanas direktīvām. 5.2. Norādot uz katra izteikuma statusu, izmantota šāda notācija: - normatīvos formulējumos, kas iespiesti parastiem burtiem bez izcēluma, parasti izmanto vajadzības izteiksmi (angļu tekstā lieto "shall"), - formulējumos, kam ir ieteikuma raksturs un kas iespiesti slīprakstā bez izcēluma, izmanto vēlējuma izteiksmi (angļu tekstā lieto "should"), priekšā ar vārdu "Ieteikums" norādot to statusu. 5.3. Jebkuru citu informāciju, kam var būt būtiska nozīme, lai gūtu pareizu izpratni par konkrēta ievilkuma tekstu, iekļauj PIEZĪMES veidā. Uzskata, ka piezīmei ir tikai informatīvs raksturs, tāpēc tajā neietver nekādas specifikācijas, to novieto uzreiz aiz attiecīgā ievilkuma. 5.4. Izņēmuma kārtā, lai būtu iespējams pienācīgi atveidot E pielikumā profila parametru sarakstus (PRL), dažas tabulas ir bez ievilkuma, un to garums nepārsniedz vienu lappusi. 6. Saistība ar citiem standartizācijas dokumentiem 6.1. Šis Eurocontrol standarts aizstāj OLDI īstermiņa saskarnes kontroldokumenta (ST-ICD) 3. daļu, Eurocontrol standarta OLDI 1. redakciju [13. norāde]. 6.2. Šis Euroconrol standarts veido paredzamās Eurocontrol standartu kopas pirmo daļu, kas attiecas uz saskarnes kontroldokumentiem (ICD) lidojumu datu apmaiņai. 7. Šā standarta pielikumu statuss Šā standarta pielikumiem ir šāds statuss: - A pielikums — normatīvs - B pielikums — normatīvs - C pielikums — normatīvs - D pielikums — normatīvs - E pielikums — normatīvs - F pielikums — informatīvs - G pielikums — informatīvs - H pielikums — informatīvs 8. Valoda Šā standarta sākotnējais teksts sagatavots angļu valodā. 1. IEVADS Šis Eurocontrol standarts balstās uz īstermiņa saskarnes kontroldokumentu, ko izstrādājusi kādreizējā OLDI tehniskā apakšgrupa, kurai tika uzdots noteikt jaunus saskarnes standartus OLDI ekspluatācijai nākotnē starp lidojumu rajonu GSV centriem. Agrāk OLDI saites balstījās uz tādiem patentētiem protokoliem kā INTERCAUTRA vai Datenübertragungs- und Verteilungssystem (DÜV), kas darbojas īpašās divpunktu shēmās vai ierobežotos tīklos un kam vajadzīga piemērota datortehnika un programmatūra. Plānojot lielāku skaitu jaunu saišu, uzskatīja, ka būtu lietderīgi pāriet uz tīklveida arhitektūru un pārņemt starptautiskos sakaru standartus, kas ļauj rentablāk izmantot saites, samazinot savienojumu skaitu katrā centrā dodot iespēju izmantot "gatavo" datortehniku un programmatūru. Šis Eurocontrol standarts formalizē un paplašina īstermiņa ICD. Jaunajai ST-ICD versijai ir pamatīgāk izstrādāta specifikācija, kas uzlabos tās sadarbspēju, un turklāt to varēs izmantot nākotnē kā ICD pamatu, kas ļautu piemēroties mainīgajām lidojumu datu apmaiņas (FDE) prasībām, kā arī plašāk izmantot koplietošanas tīklus un ieviest jaunus zemāko slāņu standartus. Šis Eurocontrol standarts piedāvā nepieciešamās funkcionālās iespējas, kuras, izdarot minimālus labojumus, var nodrošināt esošās OLDI implementācijas, izmantojot divpunktu saites vai pakešu komutācijas tīklus saskaņā ar Comité Consultatif des Téléphones et Télégraphes (CCITT) Rekomendāciju X.25 (1980. vai vēlāko gadu redakcija). Saistībā ar valsts piegādēm var minēt vēl citas iespējas. Šis ICD neizslēdz iespēju panākt arī citas abpusējas vienošanās. Iestādes, kas vēlas izmantot citus lietojumprotokolus papildus šajā dokumentā aplūkotajam protokolam vai tā vietā, var iesniegt esošā protokola grozījumus vai sadalīt savu protokolu, izmantojot dažādas virtuālās ķēdes. 2. DARBĪBAS JOMA 2.1. Šis Eurocontrol standarts nosaka specifikāciju datu komunikācijas saskarnei, kas kalpo lidojuma datu ziņojumu apmaiņai starp lidojumu rajonu GSV centriem (ACC). To atveido kā atvērto sistēmu sadarbības (OSI) profilu saskaņā ar Starptautiskās standartizācijas organizācijas/Starptautiskās elektrotehnikas komisijas (ISO/IEC) Tehnisko ziņojumu (TR) 10000-2 [3. norāde]. Šis profils skar gan apakšējos (T-profils), gan augšējos (A-profils) slāņus. 2.2. Šis Eurocontrol standartizācijas dokuments ir piemērojams šādiem mērķiem: - OLDI nodrošināšana saskaņā ar Eurocontrol standartu Nr. 001-92, 1. redakcija, - OLDI lietojumziņojumu pārraides nodrošināšana no ACC uz Centrālās gaisa satiksmes plūsmu pārvaldības institūcijas (CFMU) sistēmām. 2.3. Šis standarts ir piemērojams savienojumiem, kas izmanto: - nomātas līnijas divpunktu shēmas, vai - publiskā komutējamā telefonu tīkla (PSTN) divpunktu shēmas, vai - pakešu komutācijas datu tīklus vai savstarpēji savienotus pakešu komutācijas datu tīklus, kas nodrošina saskarni saskaņā ar CCITT Rekomendāciju X.25 (1980. vai vēlāko gadu redakcija). PIEZĪMES 1. Lidojuma plāna apstrādes sistēmu (FPPS) savienojuma shēma aplūkota 1. attēlā. 2. Iespējamie dublējumsavienojumi, piemēram, izmantojot PSTN, kas minēti H pielikumā, nav minēti 1. attēlā. +++++ TIFF +++++ 1. attēlsSaskarnes shēma 2.4. Aplūkotās datu komunikācijas saskarnes drošības jautājumu detalizēts izklāsts nav paredzēts šajā standartā. Tomēr pamatnoteikumi ir atrunāti C pielikuma 5.4. punktā, un papildu uzziņas atrodamas šā Eurocontrol standarta H pielikumā. 3. ATSAUCES 3.1. Ievads Šeit minētie dokumenti un standarti ietver noteikumus, uz kuriem atsaucas šajā tekstā un kas ir iekļauti šā Eurocontrol standarta noteikumos. Šā Eurocontrol standarta publicēšanas brīdī atsauces dokumenti un standarti bija spēkā tajās norādītajā redakcijā. Jebkura atsaucē minētā Starptautiskās civilās aviācijas organizācijas (ICAO) dokumenta pārskatīšana tūlīt nozīmē šā Eurocontrol standarta pārskatīšanu. Pārējo atsauces dokumentu labojumus neiekļauj šā Eurocontrol standarta noteikumos, kamēr tie nav oficiāli izskatīti un iestrādāti šajā Eurocontrol standartā. Rodoties pretrunām starp šā Eurocontrol standarta prasībām un pārējo atsauces dokumentu saturu, prioritāte ir šim Eurocontrol standartam. 3.2. Norādes 1. ITU-T rekomendācija X.25 (1993. gads) (1. pārstrādātais izd.), Datu galiekārtu (DTE) un datu ķēdes galiekārtu (DCE) saskarne pakešrežīma termināļos, kas savienoti ar publiskajiem datu tīkliem, izmantojot īpašo shēmu. 2. ISO/IEC TR 10000-1:1992, Informācijas tehnoloģija - Starptautisko standartizēto profilu satvars un taksonomija. - 1. daļa, Satvars (2. izdevums). 3. ISO/IEC TR 10000-2:1994, Informācijas tehnoloģija - Starptautisko standartizēto profilu satvars un taksonomija. - 2. daļa, OSI profilu principi un taksonomija (3. izdevums). 4. ITU-T rekomendācija X.21 (1992. gads) (1. pārstrādātais izd.), Datu galiekārtu (DTE) un datu ķēdes galiekārtu (DCE) saskarne publiskajos datu tīklos, kas strādā sinhronajā režīmā. 5. CCITT rekomendācija X.21bis (1988. gads), Datu galiekārtu (DTE) izmantošana publiskajos datu tīklos, lai nodrošinātu pieslēgumu sinhronajiem V-sērijas modemiem. 6. ISO/IEC 7776:1994, Informācijas tehnoloģija - Telekomunikācija un informācijas apmaiņa starp sistēmām - Datu posmu augsta līmeņa vadības procedūras - X.25 LAPB saderīgo DTE datu posmu procedūru apraksts (2. izdevums). 7. ISO/IEC 8208:1993, Informācijas tehnoloģija - Datu komunikācija - Datu galiekārtu X.25 pakešu slāņa protokols (3. izdevums). 8. ISO/IEC ISP 10609-9:1992, Informācijas tehnoloģija - Starptautiskie standartizētie profili TB, TC, TD un TE - Transporta pakalpojumi savienojuma režīmā, izmantojot savienojuma režīma tīklu - 9. daļa, No apakštīkla atkarīgās prasības tīkla slānim, datu posma slānim un fiziskajam slānim attiecībā uz piekļuvi pakešu komutācijas tīklam, izmantojot virtuālos izsaukumus. 9. ISO/IEC 7498-1:1994, Informācijas tehnoloģija - Atvērto sistēmu sadarbība - Bāzes pamatmodelis, Pamatmodelis (2. izdevums). 10. ISO/IEC 8348:1993, Informācijas tehnoloģija - Atvērto sistēmu sadarbība - Tīkla pakalpojumu definīcija (1. izdevums). 11. ISO/IEC 8072:1994, Informācijas tehnoloģija - Atvērto sistēmu sadarbība - Transporta pakalpojumu definīcija (2. izdevums). 12. ISO/IEC 8878:1992, Informācijas tehnoloģija - Telekomunikācija un informācijas apmaiņa starp sistēmām - X.25 izmantošana savienojumrežīma OSI tīkla pakalpojumu nodrošināšanai (2. izdevums). 13. Eurocontrol standarts datu apmaiņai tiešsaistē (OLDI), Nr. 001-92, 1. izdevums, 1992. gads. 14. ISO/IEC 9646-1:1994, Informācijas tehnoloģija - Atvērto sistēmu sadarbība - Standartatbilstības testēšanas metodika un satvars - 1. daļa, Vispārīgie jēdzieni (2. izdevums). 15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD 1. daļa Saskaņošanas pārbaužu plāna versija 1.0, kas datēta ar 1996. gada 10. maiju. 16. Eurocontrol FDE ICD 1. daļa — Uzticamība, pieejamība un drošība - Tehniskā ziņojuma versija 1.0, kas datēta ar 1997. gada 20 aprīli. 17. ITU-T rekomendācija X.32 (1993. gads) (1. pārstrādātais izdevums), DTE un DCE saskarne pakešrežīma termināļos ar piekļuvi publiskajiem pakešu komutācijas datiem, izmantojot publisko komutējamo telefonu tīklu, integrēto pakalpojumu cipartīklu vai ķēžu komutācijas publisko datu tīklu. 18. ITU-T rekomendācija E.164 (1991. gads) (1. pārstrādātais izdevums), Numuru piešķiršanas plāns ISDN laikmetam. 19. ITU-T rekomendācija X.75 (1993. gads) (1. pārstrādātais izdevums), Pakešu komutācijas signalizācijas sistēma starp publiskajiem tīkliem, kas nodrošina datu pārraides pakalpojumus. 20. ITU-T rekomendācija X.121 (1993. gads), Starptautiskais numuru piešķiršanas plāns publiskajiem datu tīkliem. 4. DEFINĪCIJAS, SIMBOLI UN SAĪSINĀJUMI 4.1. Definīcijas 4.1.1. Šajā Eurocontrol standartā lieto šādas definīcijas: Profils : - vienas vai vairāku pamatnormu kopa un vajadzības gadījumā šo izraudzīto pamatnormu klašu, apakškopu, opciju un parametru raksturojums, kas nepieciešams konkrētas funkcijas veikšanai [2. norāde]. Profila parametru saraksts (PRL) : - profila parametri atveidoti kā standartatbilstības prasības un sakārtoti tabulsaraksta formātā [2. norāde]. T-profils : - transporta profils, kas nodrošina transporta pakalpojumus savienojuma režīmā [3. norāde]. A-profils : lietojumprofils, kas nodrošina transporta pakalpojumus savienojuma režīmā [3. norāde]. Protokola implementācijas standartatbilstības formulējums (PICS) : - OSI sistēmas piegādātāja paziņojums, kurā norādīts, kādas potenciālas iespējas implementētas konkrētā OSI protokolā [14. norāde]. 4.2. Simboli un saīsinājumi Šajā Eurocontrol standartā lieto šādus simbolus un saīsinājumus: ACC | Lidojumu rajona GSV centrs | AFI | Iestādes un formāta identifikators | ASCII | Amerikas informācijas apmaiņas standartkods | ATC | gaisa satiksmes vadība | ATCC | gaisa satiksmes vadības centrs | CAUTRA | Coordinateur Automatique du Trafic Aérien | CCITT | (tagad ITU-T) | CFMU | Centrālā gaisa satiksmes plūsmu pārvaldības institūcija | CUG | ierobežota lietotāju grupa | DCE | datu ķēdes galiekārta | DCTS | ciparsakaru terminālsistēma | DSP | domēnam raksturīgā daļa | DTE | datu galiekārta | DÜV | Datenübertragungs- und Verteilungssystem | FDE | lidojumu datu apmaiņa | FEP | priekšgala procesors | FPDE | lidojuma plāna datu apmaiņa | FPPS | lidojuma plānu apstrādes sistēma | ICAO | Starptautiskā civilās aviācijas organizācija | ICD | saskarnes kontroldokuments | IDI | sākotnējā domēna identifikators | IDP | sākotnējā domēna daļa | IEC | Starptautiskā elektrotehnikas komisija | INTER-CAUTRA | Inter-CAUTRA protokols | ISO | Starptautiskā standartizācijas organizācija | ITU-T | Starptautiskā elektrosakaru savienība - Elektrosakaru standartizācijas sektors | ISDN | integrēto pakalpojumu ciparsignālu tīkls | LAPB | balansēts datu posma piekļuves protokols | LSB | visnenozīmīgākais bits | M, m | obligāts | MSB | visnozīmīgākais bits | MT | ziņojuma pārsūtīšana | NA | nepiemēro | NS | tīkla pakalpojumi | NSAP | tīkla servisa piekļuves punkts | NSDU | tīkla servisa datu bloks | O, O.<n> | pēc izvēles, kur <n> ir bāzes skaitlis | o, o.<n> | pēc izvēles, kur <n> ir bāzes skaitlis | OLDI | Datu apmaiņa tiešsaistē | OSI | atvērto sistēmu sadarbība | PICS | protokola implementācijas standartatbilstības formulējums | PLP | pakešu slāņa protokols | PRL | profila parametru saraksts | PSTN | publiskais komutējamais telefonu tīkls | ST-ICD | īstermiņa saskarnes kontroldokuments | SUT | pārbaudāmā sistēma | T<x> | taimeris (kur <x> ir viens vai divi bāzes burti) | TA | termināļa adapteris | TSDU | transporta servisa datu bloks | TPDU | transporta protokola datu bloks | TR | ISO tehniskais ziņojums | X | aizliegts | X | noraidīts | <item>: | nosacītais vienums (atkarīgs no vienuma vērtības) | 4.3. Notācijas 4.3.1. Šajā Eurocontrol standartā bināro vērtību vai bitu secības atveidošanai heksadecimālajā sistēmā izmanto notāciju 'd'H, kur burts d apzīmē kādu atsevišķu ciparu vai heksadecimālo ciparu secību. 4.3.2. Šajā Eurocontrol standartā bitu secības heksadecimālo atveidi veic, paņemot vienā reizē 4 bitus, sākot no visnozīmīgākā bita ( MSB ) un beidzot ar visnenozīmīgāko bitu ( LSB ). PIEZĪME. Ja atsaucēs minētajos starptautiskajos standartos nav noteikts citādi, bitu secību pārceļ no MSB uz LSB. 4.3.3. Šajā Eurocontrol standartā pamatnormas vai šā Eurocontrol standarta īpašību nodrošinājuma statusu norāda lielajiem burtiem (piem., M, O, O.< n >, X). Katra statusa apzīmējuma precīzā nozīme aplūkota šā Eurocontrol standarta pielikumos pirms to lietojuma. 4.3.4. Definējot profila FDE ICD 1. daļu šajā Eurocontrol standartā, pamatnormas vai šā Eurocontrol standarta īpašību nodrošinājuma statusu norāda mazajiem burtiem (piemēram, m, o, o.< n >, x). PIEZĪME. Tā rezultātā panāk pamatnormu nosacīto, fakultatīvo vai vērtībatkarīgo īpašību vēl tālāku precizēšanu (skat. E.3.1). 5. TEHNISKAIS APSKATS 5.1. Protokolu steks PIEZĪME. Šā Eurocontrol standarta profila protokolu steks ir aplūkojams 2. attēlā. Šajā attēlā protokolus saskaņā ar OSI bāzes pamatmodeli [9. norāde] sakārto kopā ar attiecīgo OSI slāni. Tomēr protokolu steks ir tādu sistēmu specifikācija, kas pastāvējušas pirms OSI sistēmām, un tas nenodrošina daudzas funkcijas, kuras atļautas attiecīgo OSI slāņu OSI protokolos. +++++ TIFF +++++ 2. attēlsProfila protokolu steks 5.2. Profila struktūra PIEZĪMES 1. Kā redzams 2. attēlā, profila stekā ir apvienoti vairāki apakšējo slāņu protokoli, no kuriem tikai pakešu slāņa protokols (PLP) X.25 [1. norāde] un nodrošinājuma protokoli X.21 [4. norāde] un X.21bis [5. norāde] ir definēti pašreizējos ISO/IEC un Starptautiskās elektrosakaru savienības Standartizācijas sektora (ITU-T) standartos. Pārējie augstāko slāņu protokoli definēti šā Eurocontrol standarta pielikumos (A, B un C pielikums). 2. Profila standartatbilstības prasības, kas izklāstītas 6. iedaļā, var būt vienlīdz saistīti ar minētajām specifikācijām, kā arī ar ārējiem standartiem. Sīki izstrādātās prasības ir izklāstītas PRL tabulformātā (E pielikums) un kā PICS proformas (pielikumos noteikto protokolu proformas ir iekļautas D pielikumā). Šo PRL un PICS proformu izmantošana attīstībai un/vai sagādei ir paskaidrota E pielikumā. 5.3. Saistība ar iepriekšējām specifikācijas redakcijām PIEZĪMES 1. Šis profils balstās uz ST-ICD, ko izstrādājusi OLDI tehniskā apakšgrupa. Šajā Eurocontrol standartā noteiktie protokoli un paketes formāti ir ST-ICD saderīgo protokolu un formātu apakškopa, vienīgā atšķirība ir tā, ka Eurocontrol standartā ir sīkāk izstrādāti PLP X.25 lietošanas nosacījumi, tajā ietilpst obligātais M-bita nodrošinājums un novērstas nekonsekvences iestādes un formāta identifikatora (AFI) vērtības specifikācijā tīkla servisa piekļuves punkta (NSAP) adresē. 2. Galvenās stila atšķirības šajā Eurocontrol standartā skar ICD specifikācijas uzbūvi. Ziņojuma pārsūtīšanas protokols A pielikumā ir nodalīts no nodrošināšanas T-profila. Tas atvieglos citu T-profilu izmantošanu, jo rodas vajadzība nodrošināt mainīgās FDE prasības. 3. ST-ICD specifikācijas daļas, kas attiecas uz X.25 virtuālo ķēžu vadību un ierobežo lietojumziņojumus, tagad atrodamas ziņojumu galvenes protokolā (B pielikums), kas veido FDE minimālo transporta slāni. 6. PROFILA PARAMETRI 6.1. Standartatbilstības prasības 6.1.1. Ja implementācija pretendē uz standartatbilstību šai specifikācijai, ir jāievēro 6.2. un 6.3. iedaļā izklāstītās prasības. 6.1.2. Standartatbilstība jānodrošina ar profila implementācijas standartatbilstības formulējumu, kas aplūkots D un E pielikumā. 6.2. Augšējo slāņu parametri 6.2.1. Atbilstīga implementēšana paredz A pielikumā norādīto pamatnormas prasību ievērošanu. 6.2.2. Atbilstīga implementēšana paredz profila parametru sarakstā (pielikums E.7) minēto ierobežojumu ievērošanu. 6.3. Apakšējo slāņu parametri 6.3.1. Transporta slāņa parametri 6.3.1.1. Atbilstīga implementēšana paredz B pielikumā norādīto pamatnormas prasību ievērošanu. 6.3.1.2. Atbilstīga implementēšana paredz profila parametru sarakstā (pielikums E.8.1) minēto ierobežojumu ievērošanu. 6.3.1.3. Atbilstīga implementēšana paredz nodrošināt transporta servisa datu bloka (TSDU) izmērus līdz 4 097 oktetiem, šo izmēru ieskaitot. PIEZĪME. Pirmais TSDU oktets atbilst ziņojuma galvenes laukam (skat. A.4.10 un B.4.4), atvēlot lietotāja datiem ne vairāk kā 4 096 oktetus. 6.3.2. Tīkla slāņa parametri 6.3.2.1. Atbilstīga implementēšana paredz ISO/IEC 8208 [7. norāde] prasību ievērošanu saskaņā ar C pielikumā norādīto protokola shēmu. 6.3.2.2. Atbilstīga implementēšana paredz profila parametru sarakstā (pielikums E.8.2) minēto ierobežojumu ievērošanu. 6.3.2.3. Ja datu galiekārtas (DTE)-DTE darbība ir nodrošināta, atbilstīga implementēšana paredz, izmantojot sistēmas vadības mehānismus, konfigurēt DTE vai datu ķēdes galiekārtas (DCE) līdzdalības pakāpi DTE-DTE darbībā. 6.3.2.4. Neatkarīgi no 6.3.2.3. punktā noteiktās līdzdalības, atbilstīga implementēšana paredz iespēju ierosināt savienojumu saskaņā ar C pielikuma specifikāciju, tātad protokols ir pilnīgi simetrisks. PIEZĪME. Dažas esošās implementācijas, kas balstās uz ST-ICD, neparedz tīkla savienojumu ierosināšanu saskaņā ar protokolu C pielikumā. 6.3.2.5. Atbilstīga implementēšana paredz abos virzienos kādu noteiktu laiku nestandarta izmēru pakešu funkcijai pēc noklusējuma, kuras vērtība ir 256. 6.3.2.6. Atbilstīga implementēšana paredz C pielikumā noteikto NSAP adrešu izmantošanu. 6.3.2.7. Saskaņā ar atbilstīgu implementēšanu D-bits CALL REQUEST, CALL ACCEPTED un DATA paketēs ir vienāds ar 0. PIEZĪME. Nosakot, ka CALL REQUEST and CALL ACCEPTED paketēs D= 0, tas nozīmē, ka neizmanto pārsūtīšanas apstiprinājumu. 6.3.3. Datu posma slāņa parametri 6.3.3.1. Atbilstīga implementēšana paredz ISO/IEC 7776 standartatbilstības prasību ievērošanu [6. norāde] attiecībā uz balansētu datu posma piekļuves protokola (LAPB) viensaites protokolu. 6.3.3.2. Atbilstīga implementēšana paredz profila parametru sarakstā (pielikums E.8.3) minēto ierobežojumu ievērošanu. 6.3.4. Fizikālā slāņa parametri Atbilstīga implementēšana paredz ISO/IEC ISP 10609-9 7. panta [8. norāde] standartatbilstības prasību ievērošanu. 7. PĀRBAUDES METODES PIEZĪMES 1. Šīs specifikācijas implementāciju standartatbilstības pārbaužu apraksts iekļauts F pielikumā. 2. Šajā specifikācijā standartatbilstības dokumentēšanai paredzēto PRL un PICS proformu izmantošana aplūkota E pielikumā. --------------------------------------------------