32000R2082

Komission asetus (EY) N:o 2082/2000,

annettu 6 päivänä syyskuuta 2000,

Eurocontrol-standardien hyväksymisestä sekä Eurocontrol-standardien hyväksymisestä annetun neuvoston direktiivin 93/65/ETY muuttamisesta annetun direktiivin 97/15/EY muuttamisesta

EUROOPAN YHTEISÖJEN KOMISSIO, joka

ottaa huomioon Euroopan yhteisön perustamissopimuksen,

ottaa huomioon yhteensopivien teknisten eritelmien määrittelemisestä ja käytöstä lentoliikenteen hallinnan (ATM) laitteiden ja järjestelmien hankinnassa 19 päivänä heinäkuuta 1993 annetun neuvoston direktiivin 93/65/ETY(1) ja erityisesti sen 3 artiklan,

ottaa huomioon Eurocontrol-standardien hyväksymisestä sekä yhteensopivien teknisten ritelmien määrittelemisestä ja käytöstä lentoliikenteen hallinnan (ATM) laitteiden ja järjestelmien hankinnassa annetun neuvoston direktiivin 93/65/ETY muuttamisesta 25 päivänä maaliskuuta 1997 annetun komission direktiivin 97/15/EY(2),

sekä katsoo seuraavaa:

(1) Direktiivillä 97/15/EY hyväksyttiin Eurocontrol-standardi online-tiedonsiirrosta (On-Line Data Interchange, OLDI), 1. versio, ja Eurocontrol-standardi ilmaliikennepalveluiden tiedonsiirrosta (Air Traffic Services Data Exchange Presentation, ADEXP), 1. versio.

(2) Eurocontrol on hyväksynyt mainittujen kahden standardin uudet versiot, jotka ovat OLDI, versio 2.2, ja ADEXP, versio 2.0, sekä uuden Eurocontrol-standardin lentotietojen siirron rajapinnan kontrollista (Flight Data Exchange - Interface Control Document, FDE-ICD).

(3) Nämä Eurocontrol-standardit kuuluvat direktiivin 93/65/ETY soveltamisalaan, ja niillä edistetään jäsenvaltioiden kansallisten ilmaliikenteen hallintajärjestelmien yhdenmukaistamista erityisesti lennonjohtoyksiköiden välillä tapahtuvan lentojen siirron (OLDI), lentoliikenteen kulun hallinnan (ADEXP) ja kansallisten järjestelmien välisen televiestinnän (FDE-ICD) osalta.

(4) OLDI-standardin versio 2.2 ja ADEXP-standardin versio 2.0 korvaavat kyseisten standardien edelliset versiot, jotka ovat toistaiseksi voimassa direktiivin 97/15/EY 1 artiklan säännösten nojalla, minkä vuoksi kyseinen artikla on kumottava.

(5) Tämän asetuksen säännökset ovat direktiivillä 93/65/ETY perustetun komitean lausunnon mukaiset,

ON ANTANUT TÄMÄN ASETUKSEN:

1 artikla

Hyväksytään neuvoston direktiivin 93/65/ETY mukaisesti seuraaviin Eurocontrol-standardeja koskeviin asiakirjoihin sisältyvät Eurocontrol-eritelmien pakolliset tiedot sikäli kuin ne ovat tarpeellisia integroidun eurooppalaisen lentoliikenteen hallintajärjestelmän (ATM) täytäntöön panemiseksi:

- Eurocontrol-standardi online-tiedonsiirrosta (On-Line Data Interchange, OLDI), versio 2.2 (Eurocontrolin asiakirjaviite DPS.ET1.ST06-STD), joka on tämän asetuksen liitteenä I,

- Eurocontrol-standardi ilmaliikennepalveluiden tiedonsiirrosta (Air Traffic Services Data Exchange Presentation, ADEXP), versio 2.0 (Eurocontrolin asiakirjaviite DPS.ET1.ST09-STD), joka on tämän asetuksen liitteenä II,

- Eurocontrol-standardi lentotietojen siirron rajapinnan kontrollista (Flight Data Exchange - Interface Control Document, FDE-ICD), versio 1.0 (Eurocontrolin asiakirjaviite COM.ET1.ST12-STD), joka on tämän asetuksen liitteenä III.

2 artikla

Kumotaan komission direktiivin 97/15/EY 1 artikla.

3 artikla

Tämä asetus tulee voimaan kolmantena päivänä sen jälkeen, kun se on julkaistu Euroopan yhteisöjen virallisessa lehdessä.

Tämä asetus on kaikilta osiltaan velvoittava, ja sitä sovelletaan sellaisenaan kaikissa jäsenvaltioissa.

Tehty Brysselissä 6 päivänä syyskuuta 2000.

Komission puolesta

Loyola De Palacio

Varapuheenjohtaja

(1) EYVL L 187, 29.7.1993, s. 52.

(2) EYVL L 95, 10.4.1997, s. 16.

LIITE I

ONLINETIEDONSIIRTO (ON-LINE DATA INTERCHANGE, OLDI), VERSIO 2.2

(Eurocontrolin asiakirjaviite DPS.ET1.ST06-STD)

SISÄLLYSLUETTELO

>TAULUKON PAIKKA>

TEKIJÄNOIKEUSTIEDOT

Tämän asiakirjan on laatinut Euroopan lennonvarmistusjärjestö (Eurocontrol).

Eurocontrol omistaa asiakirjan tekijänoikeudet.

Asiakirjan sisältö kokonaisuudessaan tai osin on siten vapaasti jäsenvaltioiden edustajien käytettävissä, mutta asiakirjan kopiointi tai toimittaminen ulkopuolisille edellyttää Eurocontrolin antama kirjallista lupaa.

ESIPUHE

1. Vastuunalainen elin

Eurocontrol-standardin on-line-tiedonsiirrosta (OLDI), painos 2.2, on julkaissut Euroopan lennonjohdon yhtenäistämisohjelman (EATCHIP) kehitysjaos (DED), Eurocontrol, joka on myös vastuussa asiakirjan päivittämisestä. Asiakirjaa koskevat kommentit ja kyselyt tulee osoittaa jaostolle DED-2, osoitteeseen Director General, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles.

2. Yhteys EATCHIP ohjelma-asiakirjaan

Tämä standardi muodostaa EATCHIP ohjelma-asiakirjan (EWPD) 30. syyskuuta 1994 päivätyn painoksen 2.0 mukaisen päätöksen EATCHIPin ATM- tietojenkäsittelyjärjestelmän (DPS) asiantuntijatehtävän DPS.ET1.ST06 alaisuuteen.

3. Hyväksyntä ja lisäykset

Tämä standardi on hyväksytty seuraavissa vaiheissa Eurocontrol-standardointiohjeiden mukaisesti:

- EATCHIP:n toimintavaatimus- ja ATM-tietojenkäsittelytyöryhmän (ODT) hyväksyntä kirjeenvaihdon kautta,

- Kaikkien ECAC-valtioiden kuuleminen edustajien välityksellä johtokuntakomiteassa tai EATCHIP-projektivaliokunnassa,

- EATCHIP:n projektivaliokunnan ja johtokuntakomitean hyväksyntä,

- Pysyvän komission hyväksyntä.

Tämän standardin lausekkeet astuivat voimaan pysyvän komission hyväksyttyä ne.

ODT:n kautta voidaan esittää lisäyksiä ja täydennyksiä käsittelyä ja mahdollista hyväksyntää varten, jotta järjestelmä pysyy lennonjohdon (ATC) kehityksen tasalla. Muutokset otetaan käyttöön joko lisäyksinä tai uutena painoksena asiakirjasta erikseen määriteltyjen hyväksyntä- ja lausuntokierrosmenettelyjen jälkeen.

4. Toimituskäytännöt

Kunkin selostuksen kohdalla on noudatettu seuraavaa käytäntöä: normatiiviset tiedot on ladottu normaalitekstinä; suositukset on ladottu kursiivilla ja varustettu merkinnällä Suositus.

Eritelmien kohdalla on noudatettu seuraavaa käytäntöä: normatiivisissa kohdissa käytetään verbiä "tulee" ja suosituksissa verbiä "tulisi".

Huomautukset on ladottu sisennettyinä sekä merkitty etuliitteellä "HUOM.".

5. Yhteys on-line-tiedonsiirrosta laaditun Eurocontrol-standardin painokseen 1

Tämä asiakirja korvaa on-line-tiedonsiirrosta laaditun Eurocontrol-standardin painoksen 1 osat 1 ja 2. Osan 3, joka kuvaa käytettävät tekniset protokollat, korvaa Eurocontrol-standardi lentotietojen siirrosta - rajapinnan hallinta osa 1.

6. Merkittävät muutokset painokseen 1

Seuraavassa on lueteltu merkittävimmät muutokset ja lisäykset painokseen 1:

1. Seuraavien peruskäytäntöä täydentävien (vapaaehtoisten) sanomien käyttöönotto:

- Koordinoinnin kumoamissanoma (MAC),

- Toisiovalvontatutkan (SSR) koodinantosanoma (COD),

- Informaatiosanoma (INF).

2. Sellaisen sanomasisällön ja -muodon määrittely, joka koskee rajan ylittävää lentoa reitillä, jota ei ole määritelty ilmaliikennepalveluiden (ATS) reitiksi, mutta jonka reittisegmentillä on määrätty alku- ja päätepiste.

3. Sellaisen dialogin käyttöönotto, jonka avulla:

- suunnittelutehtävissä olevat lennonjohtajat voivat tunnistaa ja selvittää tavanomaisesta poikkeavat siirto-olosuhteet,

- hyväksyvä yksikkö voi antaa vastaesityksen siirto-olosuhteista,

- kommunikoinnin siirtomenettelyt voidaan järjestää osana vastuunsiirto-menettelyä.

4. Eurocontrol-standardin ATS-tietojen vaihdosta (ADEXP) painoksen 2 mukaisen formaatin käyttöönotto. Kaikki perusmenettelyssä määritellyt ja dialogimenettelyn koordinointivaiheen aikana käytetyt sanomat on kuvattu käyttäen sekä kansainvälisen siviili-ilmailujärjestön (ICAO) että ADEXPin formaatteja. Kommunikoinnin siirtosanomat, jotka on kuvattu dialogimenettelyssä, on kuvattu ainoastaan ADEXPin mukaisesti.

5. Seuraavien painoksen 1 liitteiden poisto:

A: ATC-yksiköiden luettelo

B: OLDI-sanoman rakenne

(kaikki sanomat painoksessa 3 sisältävät esimerkin)

D: Aikaisempi kehitys

E: Käyttöönottosuunnitelma

F: Noudattaminen valtioissa

G: Käyttöönoton ohjeita

H: OLDI:n arvioinnin ohjeita.

6. Osan 3 - tekniset vaatimukset - erottaminen sovellusohjeista.

7. Yhteys muihin asiakirjoihin

Tässä asiakirjassa viitataan kahteen sanomien laadinnan kenttäformaattityyppiin: ICAO ja ADEXP.

ICAO-kenttäformaatit on kuvattu viitteessä 1. Jos viite 1 myöhemmin korvataan toisella asiakirjalla, ICAO-kenttätyyppeihin sovelletaan uudessa asiakirjassa kuvattuja määritelmiä.

ADEXP-kenttäformaatit on kuvattu viitteessä 2.

HUOM.

Viiteasiakirjat on lueteltu osuudessa 2.

8. Kieli

Asiakirjan alkukieli on englanti.

1. JOHDANTO

1.1. Päämäärä

1.1.1. Lennonjohtopalvelujen piiriin kuuluvien lentojen siirto lennonjohtoyksiköstä toiseen pyritään saamaan mahdollisimman turvalliseksi. Tämän päämäärän saavuttamiseksi yleinen käytäntö on, että lennon kulku kahden lennonjohtoyksikön välisen rajan yli koordinoidaan etukäteen yksiköiden kesken ja että lennonjohtovastuu siirtyy lennon ylittäessä tuon rajan tai välittömästi ennen sitä.

1.1.2. Silloin kun yksittäisten lentojen koordinointiin kuuluva tietojen siirto joudutaan suorittamaan puhelimen välityksellä, kokonaisuudesta muodostuu huomattavan raskas ja resursseja vievä operaatio, erityisesti aluelennonvalvontakeskuksissa (ACC). Euroopan aluelennonvalvontakeskuksissa aloitettiinkin 80-luvun alussa puhelimet korvaavan on-line-tiedonsiirron järjestelmän (OLDI) käyttö lentotietojärjestelmien (FDPS) välisessä yhteydenpidossa.

1.1.3. Käyttöönoton helpottamiseksi asiaankuuluvat tahot sopivat yhteisistä säännöistä ja sanomarakenteista ja kokosivat ne on-line-tiedonsiirtoa koskevan Eurocontrol-standardin painokseen 1. Käsillä oleva asiakirja, painos 2.2, on luotu tukemaan kyseisten toimintojen jatkokehitystä EATCHIP:n vaatimusten mukaisesti.

1.2. Soveltamisala

1.2.1. Tässä asiakirjassa määritetään ATC-yksiköitä palvelevien lentotietojärjestelmien väliset toiminnot ja sanomat, jotta saavutettaisiin:

- tarvittava koordinaatio ennen lentojen siirtoa yksiköltä toiselle,

- lentojen kommunikoinnin siirto.

1.2.2. Tässä asiakirjassa:

- määritetään sanomarakenteet ja sisältösäännöt,

- kuvataan toiminnot, jotka kyseeseen tulevilla yksiköillä tulee olla tätä tiedonsiirtotarkoitusta varten.

1.2.3. Tämä standardi on sovellettavissa Eurocontrolin jäsenvaltioiden välillä aluelennonjohtopalveluita tarjoavien yksiköiden kansainvälisiin OLDI-järjestelmiin.

1.2.4. Suositus

Suositellaan, että Euroopan siviili-ilmailukonferenssin (ECAC) jäsenvaltiot soveltaisivat tätä standardia:

- kansainvälisiin aluelennonjohtopalveluita tarjoavien yksiköiden välisiin OLDI-järjestelmiin ECAC-alueen sisällä,

- aluelennonjohtopalveluita tarjoavien yksiköiden OLDI-järjestelmiin kyseisten maiden sisällä.

2. VIITTAUKSET

2.1. Seuraavien asiakirjojen ja standardien ne kohdat, joihin viitataan tässä asiakirjassa, ovat osa tätä Eurocontrol-standardia.

Viiteasiakirjoista ja -standardeista on ilmoitettu tämän Eurocontrol-standardin julkaisuhetkellä voimassa olleet painokset.

Viitteenä oleviin kansainvälisen siviili-ilmailujärjestön (ICAO) asiakirjoihin tehdyt muutokset tulee välittömästi ottaa huomioon tässä Eurocontrol-standardissa.

Muiden viitteenä olevien asiakirjojen muutokset tulevat osaksi tätä Eurocontrol-standardia vasta kun ne on virallisesti arvioitu ja sisällytetty tähän Eurocontrol-standardiin.

Mikäli kyseiset muut viitteenä olevat asiakirjat ovat ristiriidassa tämän Eurocontrol-standardin kanssa, noudatetaan tätä Eurocontrol-standardia.

2.2. Tässä standardissa viitataan seuraaviin asiakirjoihin:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services, ICAO-asiakirja 4444, 13. painos, 7.11.1996, korjauksineen.

2. Painos 2.0 asiakirjasta Eurocontrol-standardi, ATS-tietojen vaihto (ADEXP), viitenumero DPS-ET1-ST09-STD-01-00, kesäkuu 1998.

3. MÄÄRITELMÄT, TUNNUKSET JA LYHENTEET

3.1. Määritelmät

Tässä Eurocontrol-standardissa noudatetaan seuraavia määritelmiä.

3.1.1. Hyväksyvä yksikkö (Accepting Unit): lennonjohtopalveluja tarjoava yksikkö, joka ottaa tai on ottanut vastuun, kun siirto yksiköltä toiselle on tapahtumassa tai tapahtunut.

3.1.2. Kuittaus (Acknowledgement): Ilmoitus sanoman vastaanottamisesta ja sen toteamisesta käsittelykelpoiseksi.

3.1.3. Aktivointi (Activation): Vastaanottavan lennonjohtoyksikön prosessi, jonka aikana se saa kulloisenkin lennon lentosuunnitelman päivitystiedot siirtävältä yksiköltä osana yksiköiden välistä koordinointia, minkä jälkeen tiedot luovutetaan lennonjohtajille.

3.1.4. Korkeus (Altitude): Tason, pisteen tai pisteeksi luokiteltavan kohteen pystysuora etäisyys merenpinnan tasosta.

3.1.5. Sovellus (Application): Sellainen ilmaliikennepalveluiden (ATS) alijärjestelmä, joka on tämän standardin mukainen ja joka liittyy vastaaviin kokonaisuuksiin muissa ilmaliikennepalvelujärjestelmissä.

3.1.6. Vastuualue (Area of Responsibility): Erikseen määritelty ilmatila, jonka sisällä lennonjohtoyksikkö tarjoaa lennonjohtopalveluja.

3.1.7. Yhdistäminen (Association): Menettely, jossa järjestelmä yhdistää saadun OLDI-sanoman tietokannassa olevaan lentosuunnitelmamerkintään.

3.1.8. Lennonjohtoyksikkö eli ATC-yksikkö (ATC Unit): Lennonjohtopalveluja tarjoava yksikkö.

3.1.9. Saatavuus (Availability): Todennäköisyys, jolla tietty palvelu tai ominaisuus on käyttäjän saatavilla tiettynä aikana.

3.1.10. Raja (Boundary): Tasot (lateraaliset ja vertikaaliset), jotka määräävät ATC-yksikön vastuualueen.

3.1.11. Sallittu lentokorkeus (Cleared Flight Level): Lennonvalvonnan koneelle määrittelemä sallittu lentokorkeus.

3.1.12. Koordinointi, ATC (Co-ordination, ATC): Vierekkäisten ATC-yksiköiden suorittama määrämuotoinen prosessi, jossa yksiköt tiedottavat toisilleen lentojen suunnitellun siirtymisen yli yksiköiden välisen rajan; tarkoituksena on taata lentoturvallisuus aiottujen toimenpiteiden johdonmukaisuuden avulla.

3.1.13. Koordinointisanoma (Co-ordination Message): Yleistermi, jolla tarkoitetaan ATC-koordinoinnin yhteydessä käytettäviä sanomia. Näihin kuuluu myös kappaleessa 8.8 kuvattu erikoissanoma CDN.

3.1.14. Koordinointivaihe (Co-ordination Phase): Tietyn lennon yhteydessä se vaihe, jonka aikana siirtävä ja vastaanottava ATC-yksikkö sopivat ehdoista (kuten lentokorkeudesta ja rajanylityskohdasta), joiden mukaan lennonjohtovastuu siirtyy yksiköltä toiselle.

3.1.15. Koordinointipiste, COP (Co-ordination Point): ATC-yksiköiden koordinointijaksossa yksiköiden väliselle rajalle tai sen läheisyyteen sopima piste, johon viitataan koordinointiviesteissä.

3.1.16. Korrelointi (Correlation): Tiettyjen kriteerien mukainen prosessi, jossa yhdistetään saman lennon lentosuunnitelmatiedot ja tutkajälki, useimmiten lennonvalvojan näytölle esitettäväksi.

3.1.17. Eurocontrol-standardi (Eurocontrol Standard): Mikä tahansa Eurocontrol-jäsenvaltioiden ilmaliikennepalvelujärjestelmissä käytettäväksi hyväksymä olennainen fyysisiä ominaisuuksia, rakennetta, materiaaleja, suorituskykyä, henkilöstöä tai menettelyä kuvaava määrittely. Eurocontrol-standardi ei saa olla ristiriidassa kansainvälisen siviili-ilmailujärjestön ICAOn normien kanssa, vaan sillä täydennetään näitä normeja tarvittaessa.

3.1.18. Toimeenpaneva lennonjohtaja (Executive Controller): Lennonjohtaja, joka itse suoraan antaa johdettavanaan oleville lennoille ohjeita. Näihin kuuluvat aluetutkavalvontapalveluja tarjoavat lennonjohtajat.

3.1.19. Jättökorkeus (Exit Level): Lentokorkeus, jolla lento suunnitelman mukaan ylittää lennonjohtovastuun siirtokohdan. Jättökorkeuteen voi liittyä täydentäviä ylitysolosuhteita, jotka määrittelevät korkeusalueen, jonka sisällä nouseva tai laskeutuva lento pysyttelee.

3.1.20. Lentosuunnitelma (Flight Plan): Lentokoneen koko lentoa tai sen osaa koskevaa, ilmaliikennepalveluyksiköille toimitettavaa määrämuotoista tietoa. Myös FDPS-järjestelmän sisältämää, lennon lentosuunnitelmasta saatua tietoa.

3.1.21. Generointi (Generate): ATC-järjestelmässä prosessi, jossa tietokannasta tai -kannoista poimitaan asiaankuuluvia tietoja ja luodaan sanoma lähetettäväksi vastaanottavalle ATC-yksikölle.

3.1.22. ICAO-formaatti (ICAO Format): Maasta-maahan-ilmaliikennepalvelusanomien lähetyksessä käytetty sanomarakenne, jossa käytetään viitteessä 1 kuvattuja kenttätyyppejä ja -erottimia.

3.1.23. Korkeus (Level): Yleistermi, joka viittaa lentokoneen korkeussijaintiin; tämän standardin yhteydessä termi korkeus tai lentokorkeus sisältää korkeustiedon, silloin kun sitä on käytetty.

3.1.24. Tiedoksianto (Notification): Prosessi, jonka aikana siirtävä yksikkö lähettää tietoa vastaanottavan yksikön järjestelmän päivittämiseksi koordinointivaiheen valmistelussa.

3.1.25. Vastaanottava yksikkö (Receiving Unit): ATC-yksikkö, jolle sanoma lähetetään.

3.1.26. Luotettavuus (Reliability): Prosentuaalinen osuus palvelun suunnitellusta saatavuudesta.

3.1.27. Pyydetty lentokorkeus (Requested Flight Level): Lentokorkeus, jota lento pyytää lentosuunnitelmassa.

3.1.28. Korjaus (Revision): Muutos lähettävän ATC-yksikön vastaanottavalle ATC-yksikölle aikaisemmin antamaan tietoon.

3.1.29. Täydentävä ylityskorkeus (Supplementary Crossing Level): Korkeus, jolla tai jonka yläpuolella, tai korkeus, jolla tai jonka alapuolella lento suunnitelman mukaan ylittää lennonjohtovastuun siirtokohdan. Täydentävä korkeus, mikäli sellaista käytetään, on osa jättökorkeutta.

3.1.30. Järjestelmän lentosuunnitelma (System Flight Plan): FDPS-järjestelmän sisältämää, jonkin lennon lentosuunnitelmasta peräisin olevaa tietoa.

3.1.31. Siirtotapahtuma-aika (Transaction Time): Sanoman alkuunpanon jälkeinen aika, joka kuluu sanoman siirtoon, alustavaan käsittelyyn vastaanottavassa järjestelmässä, kuittausviestin generointiin ja siirtoon sekä sen tunnistamiseen lähettäneessä järjestelmässä.

3.1.32. Lennonjohtovastuun siirtokohta (Transfer of Control Point): Lentokoneen reitillä sijaitseva piste, jossa vastuu ilmaliikennepalveluiden järjestämisestä siirtyy yhdeltä ATC-yksiköltä toiselle. Ei välttämättä ole sama kuin koordinointipiste (COP).

3.1.33. Siirtovaihe (Transfer Phase): Koordinointivaihetta seuraava lennon vaihe, jonka aikana toteutetaan kommunikoinnin siirto.

3.1.34. Siirtävä yksikkö (Transferring Unit): Koordinointijakson aikana se ATC-yksikkö, jonka vastuulla on asiaankuuluvien palvelujen tarjoaminen lennolle ennen yksiköiden välistä rajaa ja joka panee alulle koordinointivaiheen seuraavan yksikön kanssa.

3.1.35. Lähettää (Transmit): Välittää sanoma järjestelmästä toiseen.

3.1.36. Yksikkö (Unit): Ilmaliikennepalveluyksikkö.

3.1.37. Varoitus (Warning): Työpisteessä näkyvä ilmoitus silloin, kun automaattinen koordinointimenettely on epäonnistunut.

3.2. Tunnukset ja lyhenteet

Tässä Eurocontrol-standardissa noudatetaan seuraavia tunnuksia ja lyhenteitä.

ABI Advance Boundary Information Message: Rajatiedon ennakkoilmoitussanoma

ACC Area Control Centre: Aluevalvontakeskus

ACP Accept Message: Hyväksyntäsanoma

ACT Activate Message: Aktivointisanoma

ADEXP ATS Data Exchange Presentation: ATS-tietojen vaihto

ATC Air Traffic Control: Lennonjohto

ATM Air Traffic Management: Ilmaliikenteen hallinta

ATS Air Traffic Service: Ilmaliikennepalvelu

CDN Co-ordination Message: Koordinointisanoma

CNL Flight Plan Cancellation: Lentosuunnitelman peruuttaminen

COD SSR Code Assignment Message: SSR-koodinantosanoma

COF Change of Frequency Message: Taajuudenvaihtosanoma

COP Co-ordination Point: Koordinointipiste

DED Directorate of EATCHIP Development, Eurocontrol: EATCHIP-kehityksen jaos, Eurocontrol

EATCHIP European ATC Harmonisation and Integration Programme: Euroopan lennonjohdon yhtenäistämisohjelma

ECAC European Civil Aviation Conference: Euroopan siviili-ilmailukonferenssi

ETO Estimated Time Over: Arvioitu ylitysaika

ETOT Estimated Take-Off Time: Arvioitu lentoonlähtöaika

EWPD EATCHIP Work Programme Document: EATCHIP työohjelma

FDPS Flight Data Processing System: Lentotietojärjestelmä

FRF Further Route of Flight: Lennon jatkoreitti

HMI Human-Machine Interface: Käyttöliittymä

HOP Handover Proposal Message: Vastuunsiirtoehdotussanoma

ICAO International Civil Aviation Organisation: Kansainvälinen siviili-ilmailujärjestö

INF Information Message: Informaatiosanoma

LAM Logical Acknowledgement Message: Looginen kuittaussanoma

LoA Letter of Agreement: Sopimuskirje

MAC Message for the Abrogation of Co-ordination: Koordinoinnin kumoamissanoma

MAS Manual Assumption of Communications: Manuaalisen yhteyden vahvistus

NM Nautical Mile: Meripeninkulma

OLDI On-Line Data Interchange: On-line-tiedonsiirto

ORCAM Originating Region Code Assignment Method: Lähtöalueperustainen koodinmäärittelymenetelmä

PAC Preliminary Activate Message: Alustava aktivointisanoma

RAP Referred Activate Proposal Message: Ratkaistavaksi lähetetty aktivointiehdotussanoma

REV Revision Message: Korjaussanoma

RJC Reject Co-ordination Message: Koordinoinnin hylkäyssanoma

ROF Request on Frequency Message: Taajuudenvaihtopyyntösanoma

RRV Referred Revision Message: Ratkaistavaksi lähetetty korjaussanoma

SBY Stand-by Message: Valmiussanoma

SDM Supplementary Data Message: Täydentävä tietosanoma

SSR Secondary Surveillance Radar: Toisiovalvontatutka

SYSCO System Supported Co-ordination: Järjestelmän tukema koordinointi

TI Transfer Initiation: Siirron alkuunpano

TIM Transfer Initiation Message: Siirron alkuunpanosanoma

TWR/APP Tower (aerodrome control) and Approach Control: Lähi- ja lähestymislennonjohto

4. YLEISLUONTOISET VAATIMUKSET

4.1. Johdanto

Tässä jaksossa kuvataan ATC-yksiköiden välillä käytettävän OLDI-palvelun yleiset toimintavaatimukset sekä käytettävien erityyppisten sanomien luokittelu- ja suorituskykyvaatimukset.

4.2. Lentotietojärjestelmälle asetettavat vaatimukset

4.2.1. Lentotietokanta

Tässä asiakirjassa kuvattua palvelua käyttäville yksiköille toimitetaan tietoja FDPS-järjestelmästä, joka sisältää kaikki tarvittavat tiedot määriteltyjen sanomien näyttöön, käsittelyyn ja kokoamiseen. Ensisijainen lentotiedon lähde on kunkin lennon lentosuunnitelma sellaisena kuin se on arkistoitu lentäjän toimesta tai hänen puolestaan. Lisätietoja saadaan käsittelemällä lentosuunnitelmia kyseisen yksikön ympäristöolosuhteet huomioon ottaen.

4.2.2. Reaaliaikainen toiminta

OLDI-menettely sisältää siirtävässä yksikössä tapahtumia, joilla käynnistetään toimintoja, joiden perusteella siirtävä valvoja saa tarvittavat tiedot ajoissa ja joilla suoritetaan koordinoivan tiedon siirto hyväksyvälle yksikölle. Tätä tarkoitusta varten FDPS kykenee käynnistämään toimintoja vertailemalla UTC-aikaa ja tarpeellisia aikaparametrejä sekä lentotietokannasta saatuja aikoja lentoreitin eri pisteissä.

4.2.3. Tietoliikennemahdollisuudet

4.2.3.1. FDPS:n tulee kyetä vastaanottamaan ja lähettämään lentotietoa kulloisenkin sanoman vaatimalla ja tämän asiakirjan määrittämällä tavalla OLDI-yhteensopivan tiedonsiirtojärjestelmän avulla.

4.2.3.2. Suositus

FDPS:n tulisi olla laajennettavissa siten, että siihen voidaan sisällyttää tähän standardiin tulevaisuudessa mahdollisesti lisättävät sanomat.

4.2.3.3. Käytettävän tiedonsiirtojärjestelmän tulee, tämän asiakirjan määrittelemien suorituskykyvaatimusten rajoissa, tarjota nopeaa ja luotettavaa sovellusten välistä tiedonsiirtoa:

- varmistamalla OLDI-sanomanvälityksen eheys,

- tarkkailemalla joko kahdenvälisiä yhteyksiä tai koko tiedonsiirtoverkon tilaa.

4.2.3.4. FDPS:n tulee varoittaa työpisteitä, jos tiedonsiirtojärjestelmässä havaitaan poikkeavuuksia.

4.2.4. Ohjelmistotoiminnot

4.2.4.1. OLDI-palveluja tarjoavan järjestelmän tulee pystyä automaattisesti vastaanottamaan, varastoimaan, käsittelemään, poimimaan ja toimittamaan näytölle sekä lähettämään OLDI:in liittyvää tietoa reaaliajassa.

4.2.4.2. FDPS:n tulee:

- kuvastaa kulloisenkin OLDI-toiminnon kannalta merkityksellistä tietoa tämän standardin määrittelemällä tavalla joko automaattisesti, käsin tai näiden yhdistelmällä päivitettynä,

- kyetä poimimaan lentotietokannasta kyseisiä tietoja,

- pystyä osoittamaan lentoreitillä seuraava ATC-yksikkö.

4.2.4.3. Seuraavista sovitaan kahdenvälisesti:

- koordinointipisteet (COP),

- kiintopisteet, joita käytetään suunta- ja etäisyysmerkintöihin ATS:n ulkopuolisten reittilohkojen COP-määrittelyissä.

HUOM.

COP ei ole välttämättä sama kuin lennonjohtovastuun siirtokohta.

4.2.5. Käyttöliittymä (HMI)

4.2.5.1. Käyttöliittymän tulee kyetä:

- näyttämään OLDI-sanomien toiminnallinen sisältö ja välitöntä huomiota vaativat, saatuihin sanomiin liittyvät varoitukset,

- ohjaamaan koordinointi- ja siirtosanomavaroitukset kyseisten lentojen koordinoinnista vastuussa oleville työpisteille.

4.2.5.2. ATC-henkilöstön tulee voida muuttaa tietoja, joihin sanomien toiminnallinen sisältö perustuu, tämän asiakirjan määräämällä tavalla.

4.2.5.3. Käyttöliittymän tulee ilmaista, että sanoman siirto on käynnissä tai että sanoma on lähetetty asianmukaisesti.

4.2.5.4. Varoituksen tai huomautuksen tulee päätyä automaattisesti asiaankuuluvan lennonjohtajan tai teknisen henkilökunnan työpisteeseen, jos koordinointi- tai siirtosanomaa ei ole kuitattu määritellyn ajan sisällä.

4.2.5.5. Tällaisen varoituksen tai huomautuksen tulee olla muotoa, joka välittömästi herättää kyseisessä työpisteessä olevan henkilön huomion.

4.2.5.6. Suositus

OLDI:a käyttävän työpisteen käyttöliittymän tulisi hälyttää, mikäli OLDI-palvelu ei ole käytettävissä.

4.2.6. Sanomien alullepano

4.2.6.1. Jokaisen järjestelmän tulee sisältää järjestelmäparametrit, joiden avulla varmistetaan OLDI-sanomien oikea-aikainen automaattinen alullepano.

4.2.6.2. Suositus

Koordinointisanoman lähetys tulisi tarpeen vaatiessa voida aloittaa käsin ennen laskettua lähetysaikaa.

4.2.6.3. Järjestelmän tulee turvata automaattinen tapahtuman käynnistys, mikäli manuaalista käynnistystä ei ole suoritettu.

4.2.6.4. Järjestelmän tulee käyttää hyväksi aikaparametrejä seuraaviin määrittelyihin:

- lähetystä edeltävä varoaika, jona sanomien toiminnallinen sisältö on nähtävillä siirtävässä yksikössä,

- varoaika, joko yleinen tai COP:ta kohden, sanoman lähetystä varten tarvittaessa,

- sanoman lähetyksen jälkeinen aika, jonka kuluessa on saatava ohjelmallinen kuittaus (pisin sallittu vastaustauko).

4.2.6.5. Sanoman lähetyksen tulee tapahtua viivytyksettä, silloin kun siihen vaadittavat tiedot saadaan myöhemmin kuin aiottuna lähetysaikana.

Esimerkki:

Lento alkaa GAT IFR -segmentin pisteessä, joka on lähellä myöhemmin ylitettävää rajaa; pisteen ETO on ilmoitettu kahdeksan minuuttia ennen COP:tä, jolloin ACT-sanoma on aikaparametrin mukaan jo myöhässä; sanoma lähetetään välittömästi.

4.2.7. Sanomien vastaanotto

4.2.7.1. ATC-järjestelmän tulee kyetä:

- vastaanottamaan OLDI-sanomia,

- käsittelemään niitä automaattisesti tämän standardin mukaisesti,

- tulostamaan lentotietoa saatujen sanomien mukaan sekä tulostamaan tarpeellisia varoituksia, mikäli saadussa tiedossa on ristiriitaisuuksia,

- generoimaan ja lähettämään automaattisesti ohjelmallisia kuittaussanomia.

4.2.7.2. Järjestelmän tulee generoida ja lähettää kuittaussanoma (looginen kuittaus- (LAM), hyväksyntä- (ACP) tai valmiussanoma (SBY)) kun sitä vastaava alkuperäinen sanoma on käsitelty ja käsittelyn tulosten esitys asiaankuuluville työpisteille on varmistunut.HUOM.

Kuittauksen yksityiskohtaiset edellytykset on käsitelty jokaisen sanoman kohdalla erikseen.

4.3. Ajantasaistaminen valvontatiedon perusteella

Suositus

Aika-arviotiedon paikkansapitävyyden varmistamiseksi lentotietokantaa tulisi päivittää lentojen tutkavalvonnasta ja muista valvontalähteistä saadun tiedon avulla.

4.4. OLDI-tiedon tallentaminen

4.4.1. Sisältö

Kaikkien OLDI-sanomien sisältö ja vastaanottoaika tulee tallentaa.

4.4.2. Välineistö

Tallennetun tiedon hakua ja tulostamista varten tulee olla käytettävissä tarvittava välineistö.

4.5. Saatavuus, luotettavuus, tietoturva ja tiedon eheys

4.5.1. Saatavuus

4.5.1.1. OLDI-palvelun tulee olla käytettävissä yksiköiden välillä normaalin ja ruuhkaliikenteen aikana.

4.5.1.2. Suositus

OLDI-palvelun tulisi olla käytettävissä 24 tuntia vuorokaudessa joka vuorokautena.

4.5.1.3. Suunnitellut järjestelmän käyttökatkot (ja samalla suunnitellut saatavuusajat) tulee sopia molempien asianomaisten yksiköiden välillä.

4.5.2. Luotettavuus

4.5.2.1. Jokaisen OLDI-linkin luotettavuuden tulee olla vähintään 99,86 prosenttia (vastaa enintään 12 tuntia käyttökatkoja vuodessa 24 tuntia vuorokaudessa käytössä olevassa järjestelmässä).

4.5.2.2. Suositus

Jos se on toiminnan kannalta perusteltua, luotettavuuden tulisi olla vähintään 99,99 prosenttia (vastaa enintään 52 minuuttia käyttökatkoja vuoden aikana 24 tuntia vuorokaudessa käytössä olevassa järjestelmässä).

4.5.3. Tietoturva

Suositus

OLDI-järjestelmiin tulisi soveltaa tietoturvajärjestelyjä (kuten käyttörajoituksia, lähdetarkistuksia) sekä, mikäli mahdollista, verkonhallintaa.

4.5.4. Tiedon eheys

Ohjelmistotason virhetiheys ei saa ylittää yhtä siirrossa tapahtunutta virhettä 2000:ta sanomaa kohti.

4.6. Toiminnallinen arviointi

4.6.1. Arviointijakso

Jokaisen uuden OLDI-järjestelmään lisättävän osan tulee, mukaan lukien olemassa oleviin yhteyksiin lisättävät osat, ennen käyttöönottoaan läpäistä arviointijakso, jonka aikana tutkitaan sen ominaisuudet, kuten tiedon eheys, tarkkuus, suorituskyky, yhteensopivuus ATC-menettelyjen kanssa sekä yleinen turvallisuus.

HUOM.

Eurocontrolin OLDI-sihteeristöstä on saatavissa uuden osan arviointia helpottava menettelyopas.

4.6.2. Operatiivinen käyttöönottoajankohta

Operatiivisesta käyttöönotosta arviointivaiheen jälkeen tulee sopia virallisesti kahden yksikön välillä.

5. SANOMAKATEGORIAT

5.1. Yleistä

5.1.1. Päämäärä

Asiakirjan tässä osassa:

- määritellään sanomakategoriat,

- määritellään siirtotapahtuman aikavaatimukset kategorioittain,

- määrätään, mitkä sanomat ovat pakollisia ja mitkä täydentäviä,

- asetetaan sanomatyyppien kategoriat.

5.1.2. Sanomakategoriat

OLDI-sanomat on jaettu seuraaviin kategorioihin:

- Kategoria 1: Kommunikoinnin siirto,

- Kategoria 2: Koordinointi,

- Kategoria 3: Tiedoksianto.

5.2. Siirtotapahtuma-ajat

5.2.1. Ehdot siirtotapahtuma-ajoille

5.2.1.1. Siirtotapahtuma-ajat sisältävät siirron, alustavan käsittelyn vastaanottavassa yksikössä sekä kuittaussanoman laadinnan, lähetyksen ja vastaanoton siirtävässä yksikössä. Tämän vuoksi automaattisia kuittaussanomia LAM ja SBY ei ole asetettu mihinkään sanomakategoriaan.

5.2.1.2. Eri sanomakategorioille määritetyt enimmäissiirtotapahtuma-ajat on lueteltu taulukossa 5-1.

Taulukko 5-1

Enimmäissiirtotapahtuma-ajat

>TAULUKON PAIKKA>

5.2.1.3. Kullekin sanomakategorialle tai -tyypille määritellään vastaustauon enimmäispituus.

5.2.1.4. Jos sanoman lähetyksen jälkeen ei ole saatu kuittausta määritellyn ajan sisällä, tulee sanoman lähetys tai käsittely todeta epäonnistuneeksi sekä antaa varoitus tässä asiakirjassa kulloinkin määritellyllä tavalla.

5.2.1.5. Suositus

Vastaustauon pituus kolmen eri kategorian kohdalla saisi olla enintään 12, 30 ja 60 sekuntia.

5.3. Sanomien luokittelu ja kategorisointi

5.3.1. Sanomien luokittelu - pakollinen ja täydentävä

5.3.1.1. Tässä asiakirjassa kuvatut sanomat on luokiteltu joko pakollisiksi tai täydentäviksi.

5.3.1.2. Silloin kun sanoma on määritelty pakolliseksi (M) lähetykseen (TX), tulee järjestelmän mahdollistaa kyseisen sanoman lähetys.

5.3.1.3. Silloin kun sanoma on määritelty pakolliseksi vastaanottoon (REC), tulee järjestelmän mahdollistaa vastaanotettujen sanomien käsittely. HUOM.

Erityistapauksissa, kun liikennevirta on yhdensuuntainen, pakollista sanomaa voidaan soveltaa pelkästään yhteen suuntaan.

5.3.1.4. Silloin kun sanoma on määritelty täydentäväksi (C) lähetykseen, tulee järjestelmän mahdollistaa kyseisten sanomien lähetys lähettävän yksikön sitä vaatiessa ja vastaanottavan yksikön hyväksyessä.HUOM.

Täydentävät sanomat voivat olla yksisuuntaisia, mikäli toiminnalliset vaatimukset niin edellyttävät.

5.3.1.5. Silloin kun sanoma on määritelty täydentäväksi vastaanottoon, tulee järjestelmän mahdollistaa vastaanotettujen sanomien käsittely silloin, kun kyseisestä käytännöstä on sovittu osapuolten kesken.

5.3.1.6. Taulukoissa 5-3 ja 5-4 kuvatut vaatimukset ovat voimassa ainoastaan silloin, kun dialogimenettelystä koordinoinnin ja/tai kommunikoinnin siirron osalta on sovittu kahdenvälisesti ATC-yksiköiden välillä.

5.3.2. Sanomien kategorisointi

5.3.2.1. Perusmenettelyyn kuuluvien sanomien kategorisointi on määritelty taulukossa 5-2.

5.3.2.2. Dialogimenettelyn lisäkoordinointisanomien kategorisointi on määritelty taulukossa 5-3.

5.3.2.3. Dialogimenettelyn kommunikoinnin siirtosanomien kategorisointi on määritelty taulukossa 5-4.

Taulukko 5-2

Perusmenettelyn sanomat

>TAULUKON PAIKKA>

Taulukko 5-3

Dialogimenettely - Koordinointivaiheen sanomat

(Taulukon 5-2 lisäksi)

>TAULUKON PAIKKA>

Taulukko 5-4

Dialogimenettely - Siirtovaiheen sanomat

>TAULUKON PAIKKA>

6. PERUSMENETTELY - PAKOLLISET SANOMAT

6.1. Yleistä

6.1.1. Vaatimuksien määrittely

Tässä osassa kuvataan OLDI-palveluiden käyttöönoton vähimmäisvaatimukset ohjelmistotasolla.

6.1.2. Käyttöönotto

OLDI:a lentojen koordinointiin käyttävien yksiköiden tulee käyttää tässä osassa kuvattuja ABI-, ACT- ja LAM-sanomia, paitsi jos ne ovat kahdenvälisesti sopineet tämän asiakirjan osassa 8 kuvatun koordinointidialogimenettelyn käytöstä, missä tapauksessa sovelletaan kyseisessä osassa määriteltyjä ACT- ja LAM-sanomien käytön edellytyksiä.

6.2. Rajatiedon ennakkoilmoitussanoma ABI (Advance Boundary Information)

6.2.1. ABI-sanoman tarkoitus

ABI täyttää seuraavat toiminnalliset vaatimukset:

- mahdollistaa puuttuvan lentosuunnitelmatiedon hankinnan,

- tarjoaa seuraavalle ATC-yksikölle ennakkoon rajatietoja ja niihin korjauksia,

- päivittää lentosuunnitelman perustietoja,

- helpottaa tutkajälkien varhaista korrelointia,

- helpottaa lähitulevaisuuden sektorikuormituksen tarkkaa arviointia.

ABI on tiedoksiantosanoma.

6.2.2. Sanoman sisältö

ABI-sanoman tulee sisältää seuraavat tiedot:

- Sanoman tyyppi,

- Sanoman numero,

- Lentokoneen tunnistetiedot,

- SSR-toimintatila ja -koodi (mikäli saatavilla),

- Lähtölentoasema,

- Arviotieto,

- Määränpäälentoasema,

- Koneiden lukumäärä ja tyyppi,

- Reitti (valinnainen),

- Muut lentosuunnitelmatiedot (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

6.2.3. Soveltamissäännöt

6.2.3.1. Yleistä

6.2.3.1.1. Ellei kohdista 6.2.3.1.3 tai 6.2.3.1.4 muuta johdu, tulee jokaista OLDI-menettelyssä mukana olevaa vastuualueiden välisen rajan ylitystä suunnittelevaa lentoa kohti lähettää yksi tai useampi ABI-viesti.

6.2.3.1.2. ABI-sanoma tulee lähettää ennen aktivointiviestiä (ACT) tai ratkaistavaksi lähetettyä aktivointiehdotussanomaa (RAP).

6.2.3.1.3. ABI-sanomaa ei tule generoida, mikäli aiotaan lähettää alustava aktivointisanoma (PAC).

6.2.3.1.4. Suositus

ABI-sanoman lähetys tuli estää, mikäli välittömästi tai sovitun ajan sisällä ollaan lähettämässä ACT- tai RAP-sanoma.HUOM.

Tämän suosituksen tarkoituksena on välttää tilannetta, jossa vastaanottavassa yksikössä yritetään samanaikaisesti eri työpisteissä ratkaista poikkeavuuksia samaa lentoa koskevien ABI- ja ACT-sanomien suhteen.

6.2.3.1.5. Korjattu ABI-sanoma tulee lähettää, jos sitä seuraavaa ACT-sanomaa ei ole generoitu ja jos:

- lennon reittiä on muutettu siten, että edellisessä sanomassa annettu COP ei enää pidä paikkansa,

- määränpääasema on muuttunut,

tai

- konetyyppi on muuttunut.

6.2.3.1.6. Suositus

Korjattu ABI-sanoma tulisi lähettää, jos sitä seuraavaa ACT-sanomaa ei ole generoitu ja jos jokin seuraavista tekijöistä muuttuu:

- Aiottu rajanylityskorkeus,

- Oletettu SSR-koodi lennonjohtovastuun siirtokohdassa,

- Arvioitu ylitysaika (ETO) COP:ssä poikkeaa edellisestä ABI-sanomasta enemmän kuin sopimuskirjeessä (LoA) on määrätty,

- Jokin muu, kahdenvälisesti sovittu tekijä.

6.2.3.2. Käsittely vastaanottavassa yksikössä

6.2.3.2.1. ABI-sanoman vastaanottavan yksikön tulee yrittää yhdistää se vastaavaan lentosuunnitelmatietoon.

6.2.3.2.2. Vastaanottavassa järjestelmässä tulee automaattisesti tai käsin luoda uusi lentosuunnitelma, mikäli lentosuunnitelmatietoon yhdistäminen epäonnistuu.

6.2.3.2.3. Jos lentosuunnitelmatietoon yhdistäminen onnistuu, mutta sanoman tietojen ja vastaanottavassa yksikössä olevan vastaavan tiedon välillä havaitaan ristiriita, joka johtaisi seuraavan ACT-sanoman saannin yhteydessä korjaustarpeeseen, tulee ristiriita saattaa asianomaisen työpisteen tietoon sen ratkaisemista varten.

6.2.3.3. Lähetyksen aikaparametrit

6.2.3.3.1. Sanoma tulee lähettää parametrissä mainittua minuuttimäärää ennen arvioitua aikaa COP:ssä.

6.2.3.3.2. ABI-sanomien generoinnin parametrit tulee sisällyttää ATC-yksiköiden väliseen sopimuskirjeeseen.

6.2.3.3.3. Suositus

ABI-generoinnin parametrien tulisi olla:

- muunneltavissa sopimuskirjeen ehtojen perusteella,

- jokaiselle COP:lle erikseen määritettyjä.

6.2.4. ABI-sanoman kuittaus

6.2.4.1. Kuittaus

ABI-sanoma tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

HUOM.

Intentionally Blank LAM-sanoma generoidaan riippumatta siitä, onnistuiko lentosuunnitelmatietoon yhdistäminen.

6.2.4.2. Ei kuittausta

Suositus

Jos ABI-sanomaan ei saada vahvistusta LAM-sanoman muodossa, tulisi valvovassa työpisteessä näyttää varoitus.

6.2.5. Esimerkkejä

"Air 2000" 253, Boeing 757 Maltalta Birminghamiin, arvioitu BNE VOR 1221 UTC, lentokorkeus FL350, TAS 480 solmua, suunniteltu reitti UB4 BNE UB4 BPK UB3 HON, transponderi kanavalla A7012, lentokorkeuspyyntö FL390. Seuraavassa vastaavat esimerkit Reimsistä Lontoon aluelennonvalvontakeskukseen lähetetystä ABI-sanomasta.

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. Aktivointisanoma ACT (Activate)

6.3.1. ACT-sanoman tarkoitus

ACT täyttää seuraavat toiminnalliset vaatimukset:

- Korvata suullinen raja-arvio lähettämällä automaattisesti tietoja lennosta ATC-yksiköltä toiselle ennen vastuunsiirtoa,

- Päivittää vastaanottavan ATC-yksikön peruslentosuunnitelmatietoja tuoreimmalla tiedolla,

- Helpottaa lentosuunnitelmatiedon jakelua ja näyttämistä tarvittavilla työasemilla vastaanottavassa ATC-yksikössä,

- Nopeuttaa vastaanottavassa yksikössä kutsutunnuksen ja koodien korreloinnin näyttöä,

- Toimittaa vastaanottavalle ATC-yksikölle siirto-olosuhteet.

6.3.2. Sanoman sisältö

ACT-sanoman tulee sisältää seuraavat tiedot:

- Sanoman tyyppi,

- Sanoman numero,

- Lentokoneen tunnistetiedot,

- SSR-toimintatila ja -koodi

- Lähtölentoasema,

- Arviotieto,

- Määränpäälentoasema,

- Koneiden lukumäärä ja tyyppi,

- Reitti (valinnainen),

- Muut lentosuunnitelmatiedot (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

6.3.3. Soveltamissäännöt

6.3.3.1. Yleistä

6.3.3.1.1. Rajan ylittävälle lennolle tulee lähettää yksi ACT-sanoma, jollei kohdasta 6.3.3.1.10 muuta johdu.

6.3.3.1.2. ACT-sanoma tulee generoida ja lähettää automaattisesti sopimuskirjeessä määrättynä laskettuna aikana, ellei sitä ole käsin pantu alulle aikaisemmin.

6.3.3.1.3. Suositus

ATC-henkilökunnalla tulisi olla mahdollisuus käynnistää ACT-sanomien lähetys ennen laskettua lähetysaikaa.

6.3.3.1.4. Lähetettävän ACT-sanoman toiminnallisen sisällön tulee olla näkyvillä lennon koordinoinnista vastaavassa työpisteessä ennen varsinaista lähetystä.

6.3.3.1.5. Suositus

Kohtaan 6.3.3.1.4 liittyen ACT-sanoman automaattisen lähetysajan tulisi olla nähtävillä sisällön yhteydessä.

6.3.3.1.6. ACT-sanoman tulee sisältää kaikkein tuorein tieto lennosta ja kuvastaa täten aiottuja poistumisolosuhteita.

6.3.3.1.7. ACT-sanoman lähetyksestä tulee saada tieto asiaankuuluvalle työpisteelle.

6.3.3.1.8. Heti kun LAM on vastaanotettu, ACT-sanoman sisällöstä tulee molempia ATC-yksiköitä operatiivisesti sitova. Siirtävän yksikön ATC-henkilökunnalle tulee saattaa tieto koordinoiduista siirto-olosuhteista ja LAM:n vastaanotosta.

6.3.3.1.9. Vastaanottavan yksikön oletetaan hyväksyneen ACT-sanoman sisältämät siirto-olosuhteet, ellei se aloita koordinointia niiden muuttamiseksi.

6.3.3.1.10. Samalle koordinointikumppanille voidaan lähettää ylimääräinen ACT-sanoma ainoastaan, mikäli edellinen on kumottu MAC-sanomalla.

6.3.3.1.11. Reitti- ja muut lentosuunnitelmatiedot tulee sisällyttää sanomaan, mikäli niin on kahdenvälisesti sovittu.

6.3.3.2. Käsittely vastaanottavassa yksikössä

6.3.3.2.1. ACT-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmatietoon.

6.3.3.2.2. Jos vastaava lentosuunnitelma löytyy eikä sanomassa ole ristiriitoja, jotka estäisivät normaalin käsittelyn:

- toiminnallinen sisältö liitetään lentosuunnitelmaan,

- tarvittavat tiedot tulostetaan operatiiviselle ATC:lle ja muille tarpeellisille työpisteille,

- vastauksena lähetetään LAM-sanoma.

6.3.3.2.3. Jos vastaavaa lentosuunnitelmaa ei löydy tai sanomassa on ristiriita, joka estää normaalin käsittelyn:

- mikäli lennonjohtovastuun vastaanottava sektori voidaan tunnistaa, tulee

- sanoman toiminnallinen sisältö tulostaa näkyviin sektorissa,

- lähettää LAM-sanoma,

- luoda lentosuunnitelma,

- kaikissa muissa tapauksissa LAM-sanomaa ei tule lähettää.

6.3.3.3. Lähetyksen parametrit

6.3.3.3.1. Sanoma lähetetään joko heti toisen seuraavista ehdoista täytyttyä tai niin pian kuin mahdollista sen jälkeen:

- parametrissä mainittu minuuttimäärä ennen arvioitua aikaa COP:ssä,

- hetki, jolloin lento on kahdenvälisesti sovitun etäisyyden päässä COP:stä.

6.3.3.3.2. ACT-sanomien generoinnin parametrit tulee sisällyttää ATC-yksiköiden väliseen sopimuskirjeeseen.

6.3.3.3.3. ACT-sanomien generoinnin parametrien tulee olla muunneltavissa sopimuskirjeen ehtojen mukaisesti.

6.3.3.3.4. Suositus

ACT-generoinnin parametrit tulisi määritellä erikseen jokaiselle COP:lle.

6.3.3.3.5. Määriteltyjen parametrien tulee jättää riittävästi aikaa:

- lähettävälle yksikölle päivittää siirtolentokorkeutta vastaamaan oletettuja olosuhteita COP:ssä,

sekä

- vastaanottavalle yksikölle käsitellä ACT ja generoida sekä lähettää LAM niin, että aikaa jää lähettävän yksikön suorittamalle suulliselle koordinoinnille ja sitä seuraavalle toiminnalle hyväksyvässä yksikössä, mikäli tiedonsiirto epäonnistuu.

6.3.4. ACT-sanoman kuittaus

6.3.4.1. Kuittaus

ACT-sanoma kuitataan generoimalla ja lähettämällä LAM-sanoma.

6.3.4.2. Ei kuittausta

Jos ACT-sanomaan ei saada kuittauksena LAM-sanomaa, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

6.3.5. Esimerkkejä

Seuraavat esimerkit ovat jatkoa kohdassa 6.2 mainituille ABI-sanomaesimerkeille; kaikki yksityiskohdat ovat samoja lukuun ottamatta arvioitua koordinointipisteen ylitysaikaa, joka on alla olevassa ACT-sanomassa 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. Looginen kuittaussanoma LAM (Logical Acknowledgement)

6.4.1. LAM-sanoman tarkoitus

Vastaanottava yksikkö ilmaisee LAM-sanomalla lähettävälle yksikölle vastaanottaneensa lähetetyn sanoman.

LAM-käsittely antaa ATC-henkilökunnalle siirtävässä yksikössä:

- varoituksen, mikäli kuittausta ei ole saatu,

- osoituksen siitä, että kuitattava sanoma on vastaanotettu, käsitelty onnistuneesti, havaittu virheettömäksi, tallennettu ja, mikäli aiheellista, saatavilla asiaankuuluvissa työpisteissä esitettäväksi.

6.4.2. Sanoman sisältö

LAM-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

6.4.3. Soveltamissäännöt

6.4.3.1. Yleistä

6.4.3.1.1. LAM-vastaussanoman lähetyssäännöt on kuvattu kunkin sanoman käsittelyn kohdalla tässä asiakirjassa.

6.4.3.1.2. LAM-sanoma tulee generoida ja lähettää automaattisesti.

6.4.3.1.3. LAM-sanomaa ei saa käyttää teknisten sanomien sijaan tiedonsiirron eheyden ja luotettavuuden varmistamiseen.

6.4.3.1.4. LAM-sanoma tulee generoida ja lähettää välittömästi, jotta kuitattavan sanoman siirtotapahtuma-aikaa kuluu mahdollisimman vähän.

6.4.3.1.5. Lähettävän ATC-järjestelmän tulee, paitsi ABI-sanoman kohdalla, ilmoittaa koordinoinnista vastaavalle lennonvalvojalle, mikäli LAM-sanomaa ei ole vastaanotettu tällaisille varoituksille asetetun määräajan kuluessa.

6.4.4. LAM-sanoman kuittaus

LAM-sanoma ei vaadi kuittausta.

6.4.5. Esimerkkejä

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. PERUSMENETTELY - TÄYDENTÄVÄT SANOMAT

7.1. Yleistä

7.1.1. Vaatimuksien määrittely

Tässä osassa kuvataan osan 6 "Perusmenettely - pakolliset sanomat" lisäksi perusmenettelyssä käytettävät toiminnot.

7.1.2. Käyttöönotto

7.1.2.1. Kaikkien tässä osassa kuvattujen toimintojen tulee olla kahdenvälisesti sovittuja ennen käyttöönottoa.

7.1.2.2. Tämän asiakirjan osan sääntöjä sovelletaan silloin, kun edellä mainitusta käytöstä on sovittu.

7.2. Alustava aktivointisanoma PAC (Preliminary Activate)

7.2.1. PAC-sanoman tarkoitus

PAC-sanoma täyttää seuraavat toiminnalliset vaatimukset:

- tiedoksianto ja lähtöä edeltävä koordinointi lennolla, jonka lentoajan pituus lähdöstä COP:hen olisi lyhyempi kuin ACT-sanoman lähetystä varten sovitut aikaparametrit edellyttävät,

- tiedoksianto ja lähtöä edeltävä koordinointi paikallisen yksikön (kenttä- tai lähestymislennonvalvontayksikön) aloittamana ennen lähtöä seuraavalle lennonjohtovastuun vastaanottavalle yksikölle,

- puuttuvien lentosuunnitelmatietojen hankinta, mikäli lentosuunnitelmatietojen aikaisemmassa tiedottamisessa on puutteita,

- SSR-koodinantopyyntö yksiköltä, jolle edellä oleva tiedoksianto tai koordinointi on lähetetty, mikäli tarpeen.

7.2.2. Sanoman sisältö

PAC-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite (valinnainen),

- Lentokoneen tunnistetiedot,

- SSR-toimintatila ja -koodi,

- Lähtölentoasema,

- Arvioitu nousuaika tai arviotieto,

- Määränpäälentoasema,

- Koneen tyyppi,

- Reitti (valinnainen),

- Muu lentosuunnitelmatieto (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

7.2.3. Soveltamissäännöt

7.2.3.1. Yleistä

7.2.3.1.1. Yksi tai useampia PAC-sanomia tulee lähettää jokaista sellaista vastuualueiden rajan ylittäväksi suunniteltua lentoa kohti, jonka lentoajan pituus lähdöstä COP:hen on lyhyempi kuin ACT-sanoman lähettämisestä sovittu aikavaatimus.

7.2.3.1.2. Yksi tai useampi PAC-viesti tulee lähettää kenttä- tai lähestymisyksikön toimesta seuraavalle yksikölle jokaista sellaista lentoa kohden, jonka yhteydessä joko tiedoksianto tai koordinointi on tarpeen.

7.2.3.1.3. Suositus

Yksiköiden välisen PAC/LAM:n käyttöönottoa varten tulisi kyseeseen tulevat TWR/APP-järjestelmät varustaa toiminteilla, jotka mahdollistavat sellaisten "käynnistys"- ja "rullaa"-tyyppisten tietojen syötön ja edelleenvälityksen, joista voidaan johtaa arvioitu nousuaika (ETOT) ja joista voidaan sen perusteella laskea COP:n arvioitu ylitysaika (ETO) ja saattaa alulle PAC-sanoman lähetys.

7.2.3.1.4. Kahdenvälisen sopimuksen perusteella sanoman tulee sisältää joko:

- Arvioitu nousuaika (ETOT),

tai

- Arviotieto.

7.2.3.1.5. Jos sanoma sisältää kahdenvälisen sopimuksen perusteella sanomaviitteen, sen tulee:

- sisältää ensimmäisen lentoa koskeneen PAC-sanoman sanomanumero,

- sisältyä seuraavaan ja sen jälkeisiin PAC-sanomiin.

7.2.3.1.6. Koodinpyyntötoiminnosta, mikäli sellaista tarvitaan, tulee sopia kahdenvälisesti.

7.2.3.1.7. Korjattu PAC-sanoma tulee lähettää, mikäli ennen lähtöä jokin seuraavista ehdoista täyttyy:

- lennon reittiä on muutettu siten, että edellisen sanoman COP ei enää pidä paikkansa,

- konetyyppi on muuttunut,

- edellisen PAC-sanoman määränpäälentoasema on todettu virheelliseksi.

7.2.3.1.8. Suositus

Korjattu PAC-sanoma tulisi lähettää, mikäli ennen lähtöä seuraavat tiedot eroavat edellisessä PAC-sanomassa annetuista:

- korkeus (arviotiedoissa, mikäli mukana),

- aiottu SSR-koodi lennonjohtovastuun siirtokohdassa,

- arvioitu lentoonnousuaika tai ETO COP:ssä muuttunut enemmän kuin kahdenvälisesti sovitun aikarajan verran,

- muutos missä tahansa muussa kahdenvälisesti sovitussa tiedossa.

7.2.3.2. Käsittely vastaanottavassa yksikössä

7.2.3.2.1. PAC-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmatietoon.

7.2.3.2.2. Jos vastaava lentosuunnitelma löytyy eikä sanomassa ole ristiriitoja, jotka estäisivät normaalin käsittelyn:

- toiminnallinen sisältö tulee sisällyttää lentosuunnitelmaan,

- tarvittavat tiedot tulostetaan operatiiviselle ATC:lle ja muille tarpeellisille työpisteille,

- vastauksena lähetetään LAM-sanoma.

7.2.3.2.3. Jos vastaavaa lentosuunnitelmaa ei löydy tai sanomassa on ristiriita, joka estää normaalin käsittelyn:

- mikäli lennonjohtovastuun vastaanottava sektori voidaan tunnistaa, tulee:

- sanoman toiminnallinen sisältö tulostaa näkyviin sektorissa,

- lähettää LAM-sanoma,

- luoda lentosuunnitelma,

- kaikissa muissa tapauksissa LAM-sanomaa ei tule lähettää.

7.2.3.2.4. Toisen tai sitä seuraavien PAC-sanomien tiedot korvaavat edellisen sanoman tiedot.

7.2.3.2.5. Jos PAC-sanoma sisältää SSR-koodinantopyynnön ja on käsiteltävissä edellä olevan kohdan 7.2.3.2.2 mukaan, tulee LAM-sanoman lisäksi palauttaa COD-sanoma.HUOM.

Koska koodinantomenettely vaatii yksityiskohtaista reittitietoa lentosuunnitelmasta, tässä asiakirjassa ei vaadita COD-sanoman palauttamista vastaanottavan yksikön toimesta, mikäli kyseistä tietoa lennosta ei ole saatavilla. Tämä ei estä sanoman palauttamista kyseisissä olosuhteissa, mikäli siihen on paikallisesti mahdollisuus ja menettelystä on sovittu kahdenvälisesti.

7.2.3.3. Lähetyksen aikaparametrit

Lähetyksen aikaparametrit eivät tule kysymykseen tässä tapauksessa, koska sanoma on lähetetty sellaisen käsin syötetyn sanoman seurauksena, jossa ilmaistaan lennon välittömästi tapahtuva lähtö.

7.2.4. PAC-sanoman kuittaus

7.2.4.1. Kuittaus

PAC-sanomaan vastauksena lähetettävät sanomat on kuvattu edellä kohdassa 7.2.3.2.

7.2.4.2. Ei kuittausta

Jos PAC-sanomaan ei saada kuittauksena LAM-sanomaa, tulee seuraavan yksikön kanssa koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

7.2.4.3. Ei-LAM-tapaukset

Ellei LAM-sanomaa saada, tulee panna alulle suullinen koordinointi.

7.2.4.4. Ei COD-sanomaa

7.2.4.4.1. Jos PAC-sanomaan sisällytettyyn koodipyyntöön ei saada vastauksena COD-sanomaa, tulee asianomaisessa työpisteessä näyttää varoitus.

7.2.4.4.2. Vastaustauon pituudesta tulee sopia kahdenvälisesti silloin, kun aiotaan käyttää koodinpyyntötoimintoa.

7.2.5. Esimerkkejä

7.2.5.1. Arvioitu nousuaika (ETOT) ja koodipyyntö

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. Aika koordinointipisteessä (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. Korjaussanoma REV (Revision)

7.3.1. REV-sanoman tarkoitus

REV-sanomaa käytetään aikaisemman ACT-sanoman koordinointitiedon korjaukseen, mikäli hyväksyvä yksikkö ei ole vaihtunut korjauksen seurauksena.

7.3.2. Sanoman sisältö

REV-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite (valinnainen),

- Lentokoneen tunnistetiedot,

- SSR-toimintatila ja -koodi (valinnainen),

- Lähtölentoasema,

- Arviotieto,

- Koordinointipiste (valinnainen),

- Määränpäälentoasema,

- Reitti (valinnainen),

- Muu lentosuunnitelmatieto (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

7.3.3. Soveltamissäännöt

7.3.3.1. Yleistä

7.3.3.1.1. Yksi tai useampi REV-viesti voidaan lähettää yksikölle, jolle lento on koordinoitu ACT-sanomalla.

7.3.3.1.2. Seuraavat tiedot voidaan korjata:

- COP:n ylitysaika,

- Siirtokorkeus tai -korkeudet,

- SSR-koodi.

7.3.3.1.3. REV-sanoma tulee lähettää, mikäli:

- COP:n ylitysaika eroaa edellisessä sanomassa annetusta enemmän kuin on kahdenvälisesti sovittu lähimpään kokonaislukuarvoon pyöristettynä,

- siirtokorkeuteen tai SSR-koodiin tulee muutoksia.

7.3.3.1.4. Mikäli niin on kahdenvälisesti sovittu, REV-sanoma tulee lähettää, jos jossain seuraavista tapahtuu muutoksia:

- COP,

- reitti,

- muu lentosuunnitelmatieto (ICAO-määrityksen kenttien 8, 10 ja 18 tiedot).

HUOM.

Operatiiviset säännöt voivat edellyttää, että ACT-sanoman jälkeiset muutokset alistetaan ensin asianomaisten yksiköiden koordinoitavaksi.

7.3.3.1.5. Sanomaviite tulee sisällyttää REV-sanomaan, jos niin on sovittu kahdenvälisesti.

7.3.3.1.6. Jos sanomaviite on mukana, sen tulee sisältää edeltäneen ACT-sanoman sanomanumero.

7.3.3.1.7. Oletuksena vastaanottava ATC-yksikkö hyväksyy REV-sanomassa annetut siirto-ehdot, ellei vastaanottava ATC-yksikkö aloita koordinointia niiden muuttamiseksi.

7.3.3.2. Korjaussanomien rakenteet

7.3.3.2.1. ICAO-formaatti

Kaikki korjaussanomat sisältävät kenttätyypit 3, 7, 13, 14 ja 16. Seuraavankaltaiset korjaukset kuuluvat näihin kenttiin:

- muutos COP:n ylitysaikaan tai siirtokorkeuteen tulee liittää mukaan sisällyttämällä korjattu tieto kenttään 14,

- muutos SSR-koodiin tulee sisällyttää kenttään 7,

- reittimuutokset, muutokset COP:hen mukaan lukien, tulee sisällyttää kenttään 14, ja kentän 15 tiedot sisällyttää kentän 22 formaatissa viiden ensimmäisen kentän jälkeen. Näiden sanomien tulee sisältää kaksi kenttää 14, joista ensimmäinen sisältää ainoastaan tiedon a), COP:n jonka kautta lento oli aiemmin koordinoitu. Kyseisten muutosten koordinointisäännöt, mukaan lukien suorat reititykset, on määritelty liitteessä B "erityisreittikäsittelyn vaatimukset",

- muutokset kenttiin 8, 10 ja 18 tulee sisällyttää kentän 22 tietoina viiden ensimmäisen kentän jälkeen.

7.3.3.2.2. ADEXP-rakenne

Kaikkien ADEXP-rakenteisten korjaussanomien tulee sisältää seuraavat ensisijaiset kentät: TITLE REFDATA ARCID ADEP ADES. Seuraavat säännöt ovat voimassa:

- muutos COP:n ylitysaikaan tai siirtokorkeuteen tulee liittää mukaan sisällyttämällä korjattu tieto ensisijaiseen kenttään COORDATA,

- muutokset COP:hen, reittimuutokset mukaan lukien, tulee sisällyttää ensisijaisiin kenttiin COORDATA ja ROUTE. Tällaisiin sanomiin tulee kuulua ensisijainen kenttä COP, jossa annetaan lennon aikaisempi koordinointipiste. Kyseisten muutosten koordinointisäännöt, mukaan lukien suorat reititykset, on määritelty liitteessä B,

- muutos SSR-koodiin tulee ilmaista sisällyttämällä sanomaan ensisijainen kenttä SSRCODE,

- muutokset muuhun lentosuunnitelmatietoon tulee liittää mukaan sisällyttämällä tarvittavat ensisijaiset kentät liitteen A kohdan "muu lentosuunnitelmatieto" mukaisesti.

Jos korjaussanoma lähetetään koordinoimaan ainoastaan SSR-koodia ja/tai muuta lentosuunnitelmatietoa, tulee ensisijainen kenttä COP sisällyttää sanomaan COORDATA:n sijaan.

7.3.3.2.3. SSR-koodi

SSR-koodi ja -toimintatila tulee sisällyttää REV-sanomaan ainoastaan, mikäli se on tarpeen SSR-koodin muutoksen vuoksi.

7.3.3.3. Käsittely vastaanottavassa yksikössä

7.3.3.3.1. Jos kyseessä olevalle lennolle on saatu samalta ATC-yksiköltä ACT-sanoma, tulee REV-sanoman vastaanottavan yksikön yrittää yhdistää se vastaavaan lentosuunnitelmaan.

7.3.3.3.2. Jos vastaava lentosuunnitelma löytyy eikä sanomassa ole ristiriitoja, jotka estäisivät normaalin käsittelyn:

- toiminnallinen sisältö liitetään lentosuunnitelmaan,

- tarvittavat tiedot tulostetaan operatiiviselle ATC:lle ja muille tarpeellisille työpisteille.

7.3.3.4. Lähetyksen alullepano

7.3.3.4.1. REV-sanoma on tapahtumalähtöinen, ja se tulee lähettää välittömästi asiaankuuluvien tietojen syötön tai päivityksen jälkeen.

7.3.3.4.2. REV-sanoman avulla ei voida saattaa voimaan muutoksia sen jälkeen, kun lento on erikseen määritellyn aika- tai etäisyysmarginaalin sisällä siirtopisteestä. Aika- ja etäisyysparametrit tulee sopia kahdenvälisesti.

7.3.3.4.3. Suositus

REV-parametrit tulisi määritellä erikseen jokaiselle COP:lle.

7.3.3.5. Vastaanottavan ATC-yksikön muutos

REV-sanomaa ei tule käyttää, mikäli lentosuunnitelman korjaus johtaa vastaanottavan ATC-yksikön vaihtumiseen (ks. koordinoinnin kumoamissanoma).

7.3.4. REV-sanoman kuittaus

7.3.4.1. Kuittaus

Jos:

- REV-sanoma voidaan yhdistää lentosuunnitelmaan vastaanottavassa järjestelmässä, tulee kuittauksena palauttaa LAM-sanoma,

- REV-sanomaa ei voida yhdistää lentosuunnitelmaan vastaanottavassa järjestelmässä, LAM-sanomaa ei tule lähettää.

7.3.4.2. Ei kuittausta

7.3.4.2.1. Mikäli REV-sanomaan ei saada kuittauksena LAM-sanomaa, tulee lentojen koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

7.3.4.2.2. Ellei LAM-sanomaa ole saatu, tulee siirtävän ATC-yksikön aloittaa suullinen korjausmenettely.

7.3.5. Esimerkkejä

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. Koordinoinnin kumoamissanoma MAC (Abrogation of Co-ordination)

7.4.1. MAC-sanoman tarkoitus

MAC-sanomaa käytetään ilmaisemaan vastaanottavalle yksikölle, että lennolle aikaisemmin toimeenpantu koordinointi tai tiedoksianto on kumottu.

MAC ei korvaa ICAO:n määritelmän mukaista perumissanomaa (CNL), eikä sitä sen vuoksi tule käyttää peruslentosuunnitelmatiedon poistamiseen.

7.4.2. Sanoman sisältö

MAC-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite (valinnainen),

- Lentokoneen tunnistetiedot,

- Lähtölentoasema,

- Koordinointipiste,

- Määränpäälentoasema,

- Koordinoinnin tila ja syy (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

7.4.3. Soveltamissäännöt

7.4.3.1. Yleistä

7.4.3.1.1. MAC-sanoma tulee lähettää yksikölle, jonka kanssa on aikaisemmin toimeenpantu lennon koordinointi joko ACT- tai RAP-sanoman avulla, silloin kun tapahtuu jokin seuraavista:

- aiottu korkeus siirtopisteessä poikkeaa edellisessä sanomassa annetusta, mistä seuraa muutos koordinointijakson seuraavassa yksikössä,

- lentoreittiä on muutettu siten, että siitä seuraa muutos koordinointijakson seuraavassa yksikössä,

- järjestelmän lentosuunnitelma on peruttu lähettävässä yksikössä, eikä koordinointi enää ole tarpeen,

- edelliseltä lentoa käsitelleeltä yksiköltä on vastaanotettu MAC.

7.4.3.1.2. Silloin kun MAC-sanoma on lähetetty lentokorkeuden tai reitin muutoksen takia, tulee koordinointijakson uuden yksikön kanssa panna toimeen tiedoksianto- ja/tai koordinointimenettely.

7.4.3.1.3. MAC-sanoma tulee lähettää silloin, kun lähtevän lennon PAC-sanomalla toimeenpantu koordinointi kumotaan.

7.4.3.1.4. Suositus

MAC-sanoma tulisi lähettää, mikäli lennolle aiemmin toimeenpantu tiedoksianto (ABI-sanoma) kumotaan edellä kohdassa 7.4.3.1.1 mainitun syyn vuoksi tai jos lento on viivästynyt matkalla, eikä korjattua saapumisarviota voida luoda automaattisesti.

7.4.3.1.5. Sanomaviite on liitettävä mukaan, mikäli niin on sovittu kahdenvälisesti.

7.4.3.1.6. Jos sanomaviite on mukana, sen tulee sisältää viimeisen lennolle lähetetyn ja kuitatun ABI- PAC- tai ACT-sanoman sanomanumero.

7.4.3.1.7. Koordinointipisteen tulee olla sama COP, jonka kautta lento oli aikaisemmin annettu tiedoksi tai koordinoitu.

7.4.3.1.8. Suositus

MAC-sanoman tulisi ilmaista tila, johon koordinointi tai tiedoksianto palautuu, sekä syy kumoamiseen.

7.4.3.1.9. Jos tila ja syy ovat mukana, tulee niiden olla jokin seuraavista yhdistelmistä:

- kun vastaanottava yksikkö ei enää ole seuraava koordinointiosapuoli:

- tila on INI (initial),

- syynä on jokin seuraavista:

- TFL, jos syynä on siirtokorkeuden muutos,

- RTE, jos syynä on reitin muutos,

- CSN, jos syynä on muutos kutsutunnuksessa,

- CAN, jos syynä on peruminen,

- OTH muu syy tai tuntematon syy,

- kun jokin seuraavista ehdoista täyttyy:

- aikaisemmalla PAC- tai ACT-sanomalla toimeenpantu (mahdollisesti myöhemmällä REV-sanomalla korjattu) koordinointi on kumottu, mutta lennolle on tarkoitus aloittaa uusi koordinointijakso saman yksikön kanssa,

tai

- ABI-sanoman lähetyksen jälkeen lento viivästyy tai joutuu odotuskuvioon määrittelemättömäksi ajaksi ja sen on tarkoitus olla tilanteen mukaan joko korjatun ABI- tai ACT-sanoman kohteena:

- tila on NTF (notification),

- syynä on jokin seuraavista:

- DLY, jos syynä on viivästys,

- HLD, jos syynä on odotus,

- OTH muu syy tai tuntematon syy.

7.4.3.1.10. Jos lento aiotaan tiedoksiantaa tai koordinoida uudelleen:

- tulee lähettää uusi tiedoksianto- ja/tai koordinointisanoma tilanteen mukaan,

- MAC-sanoma ei saa vaikuttaa vastaanottavan yksikön peruslentosuunnitelmatietoon,

- järjestelmän tulee säilyttää kyky käsitellä oikein uusi tiedoksianto- ja/tai koordinointisanoma joko edelliseltä siirtäneeltä yksiköltä tai eri yksiköltä uuden koordinointijakson mukaan.

7.4.3.2. Käsittely vastaanottavassa yksikössä

Lentojen yksityiskohdista vastaanottavassa ATC-yksikössä vastaaville työpisteille tulee ilmoittaa kumoamisesta.

7.4.4. MAC-sanoman kuittaus

7.4.4.1. Kuittaus

7.4.4.1.1. Jos MAC-sanoma onnistutaan yhdistämään lentosuunnitelmaan vastaanottavassa järjestelmässä ja se voidaan käsitellä, tulee kuittauksena palauttaa LAM-sanoma.

7.4.4.1.2. Jos MAC-sanomaa ei voida yhdistää lentosuunnitelmaan vastaanottavassa järjestelmässä tai sitä ei voida käsitellä, LAM-sanomaa ei tule lähettää.

7.4.4.2. Ei kuittausta

7.4.4.2.1. Jos ATC-koordinointi kumotaan eikä vastauksena saada LAM-sanomaa, tulee koordinoinnista vastaavassa työpisteessä näyttää varoitus.

7.4.4.2.2. Näissä tapauksissa tulee siirtävän ATC-yksikön kumota koordinointi suullisesti.

7.4.5. Esimerkkejä

Amsterdamin ACC lähetti Brysselin ACC:lle ABI-sanoman lennosta HOZ3188, suunniteltu korkeus FL190; myöhemmin lento pyytää nousulupaa ja selvitetään korkeudelle FL270, jossa se saapuu Brysselin sijasta Maastrichtin ilmatilaan. Esimerkit 7.4.5.1 a ja 7.4.5.2 a näyttävät, miltä Amsterdamin Brysseliin lähettämä MAC näyttää sekä ICAO- että ADEXP-formaatissa.

Maastrichtiin lähetetään ABI-sanoma ja myöhemmin ACT-sanoma, mutta muutamaa minuuttia ennen COP:hen saapumista kone palaa Amsterdamin kentälle, ja lentosuunnitelma perutaan lähettävän yksikön järjestelmässä; Maastrichtiin lähetetään esimerkkien 7.4.5.1 b ja 7.4.5.2 b mukainen MAC.

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-koodinantosanoma COD (SSR Code Assignment)

7.5.1. COD-sanoman tarkoitus

7.5.1.1. Lähtöalueperustainen koodinmäärittelymenetelmä (ORCAM) on järjestelmä, jonka avulla lento voi vastata samalla koodilla useille peräkkäisille yksiköille osallistumisalueella. Mikäli koodinmäärittelyä ei suoriteta keskitetysti esimerkiksi ACC:n toimesta, voidaan lentokentille joutua erikseen jakamaan joukko irrallisia SSR-koodeja. Tämä merkitsee koodien tuhlausta.

7.5.1.2. COD-sanoma täyttää toiminnallisen vaatimuksen, jonka mukaan ilmaliikennepalveluyksikön on toisen pyytäessä myönnettävä A-tyypin SSR-koodi tietylle lennolle. Myöntävä yksikkö voi sisällyttää sanomaan lentoreitin, mikäli niin on sovittu kahdenvälisesti.

7.5.2. Sanoman sisältö

COD-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite (valinnainen),

- Lentokoneen tunnistetiedot,

- SSR-toimintatila ja -koodi,

- Lähtölentoasema,

- Määränpäälentoasema,

- Reitti (valinnainen).

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

7.5.3. Soveltamissäännöt

7.5.3.1. Yleistä

7.5.3.1.1. COD-sanoma tulee generoida ja lähettää automaattisesti vastauksena sanomaan, johon on sisältynyt koodinantopyyntö.

7.5.3.1.2. SSR-koodin tulee olla se koodi, joka lennolle on annettu.

7.5.3.1.3. Hyväksytty kyllästyskoodi [saturation code], kuten Euroopan alueen ilmailunavigointisuunnitelma (Air Navigation Plan for the European Region) edellyttää, tulee lisätä, mikäli irrallista koodia ei ole käytettävissä.

7.5.3.1.4. Sanomaviite, jonka mukana mainitaan sen sanoman sanomanumero, johon COD-sanoma on vastauksena, tulee sisällyttää, mikäli niin on sovittu kahdenvälisesti.

7.5.3.1.5. Reitti tulee sisällyttää, mikäli niin on sovittu kahdenvälisesti.

7.5.3.1.6. Oletuksena on, että COD-sanoman vastaanottava yksikkö hyväksyy annetun SSR-koodin.

7.5.3.2. Käsittely vastaanottavassa yksikössä

7.5.3.2.1. Vastauksena lähetetään LAM-sanoma, mikäli sanomassa ei ole ristiriitaisuuksia, jotka estäisivät normaalin käsittelyn.

7.5.3.2.2. Jos sanomaa ei voida yhdistää lentosuunnitelmaan tai siinä on ristiriitaisuuksia jotka estävät normaalin käsittelyn, LAM-sanomaa ei tule palauttaa.

7.5.3.2.3. Mikäli sanomassa on reittitietoa, se ei saa estää LAM-sanoman lähetystä, ellei se ole liitteen A kuvaamien muotoedellytysten vastaista.

7.5.3.3. Lähetyksen aikaparametrit

Lähetysaikaparametrit eivät tule kysymykseen, koska COD-sanoma lähetetään SSR-koodinantopyyntösanoman vastaanoton seurauksena.

7.5.4. COD-sanoman kuittaus

7.5.4.1. Kuittaus

COD-sanoma tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

7.5.4.2. Ei kuittausta -tapaukset

Jos COD-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asiaankuuluvassa työpisteessä näyttää varoitus.

7.5.5. Esimerkkejä

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. Informaatiosanoma INF (Information)

7.6.1. INF-sanoman tarkoitus

7.6.1.1. INF-sanomaa käytetään lentojen tietojen toimitukseen tahoille, jotka eivät ole suoraan osallisina lentoreitin kahden peräkkäisen ATC-yksikön välisessä koordinoinnissa.

7.6.1.2. INF-sanomaa voidaan käyttää sanomakopioiden toimittamiseen ja sovittujen koordinointiolosuhteiden ilmoittamiseen kyseisille tahoille lennonjohtajien dialogin jälkeen. Tätä tarkoitusta varten INF-sanomat voidaan generoida sekä siirtävien että hyväksyvien yksiköiden järjestelmistä.

7.6.1.3. Sanomaa voidaan käyttää myös toimittamaan tietoa lennon reitin jostain kohdasta eri tahoille.

7.6.1.4. Rakenne sallii alustavan tiedon, korjausten ja perumisten ilmoittamisen.

7.6.2. Sanoman sisältö

INF-sanoman tulee sisältää seuraavat tiedot tässä asiakirjassa kuvatun sanomarakenteen muodossa:

- Sanomatyyppi,

- Sanomanumero,

- Kaikki alkuperäisessä sanomassa olleet operatiiviset tiedot tai niitä seuranneet koordinointitiedot,

- Viitesanoman tyyppi.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

7.6.3. Soveltamissäännöt

7.6.3.1. Sanomatyypit

INF-sanomalla toistettavat sanomatyypit perustuvat käyttövaatimuksiin ja lähettävän yksikön mahdollisuuksiin. Yleensä sanomatyypeistä ja sovellussäännöistä sovitaan kahdenvälisesti.

7.6.3.2. Sanoman vastaanottajat

Yksi tai useampia INF-sanomia voidaan lähettää samaa lentoa kohti yhdelle tai useammalle vastaanottajalle.

7.6.3.3. Toiminnallinen sisältö

INF-sanoman toiminnallisen sisällön formaatin tulee vastata jotain käytetyistä sanomista.

7.6.3.4. Suositus

1. Alustavassa dialogisanomassa (esim. ACT-, RAP-, REV-, RRV-sanoma) välitetyt ehdot saatetaan vaihtaa tai hylätä ennen kuin dialogi on päättynyt. Lähettävien yksiköiden tulisi kyetä välittämään lopulliset, sovitut koordinointiehdot.

2. INF-sanoma tulisi lähettää välittömästi tai sellaisessa suhteessa COP:n ylitysaikaan, josta on kahdenvälisesti sovittu vastaanottavan tahon kanssa.

7.6.4. INF-sanoman kuittaus

Suositus

1. INF-sanoma voidaan kuitata koordinointikumppanista riippuen generoimalla ja lähettämällä LAM-sanoma.

2. Mikäli niin on kahdenvälisesti asianosaisten yksiköiden välillä sovittu, asiaankuuluvassa työpisteessä tulisi näyttää varoitus, jos INF-sanomaan ei olla saatu kuittauksena LAM-sanomaa.

7.6.5. Esimerkkejä

Lento kutsutunnuksella BAW011, B747 EGLL:stä OMDB:iin lentokorkeudella FL290, lentokorkeuspyyntö FL410, arvioitu Koksy (KOK) VOR 1905, transponderi A5437, UG1:n ja UB6:n kautta.

Lontoosta lähetetään Maastrichtiin ACT-sanoma. Lontoosta lähetetään myös kopio yksikölle, jonka tunnus on IT.

Seuraavassa esimerkit INF-sanomasta.

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. DIALOGIMENETTELY - KOORDINOINTI

8.1. Yleistä

8.1.1. Johdanto

8.1.1.1. Dialogimenettely tarjoaa toiminnot lennonjohtajien koordinointivaiheen kommunikointiin ja järjestelyyn sekä siirtovaiheen kommunikointiin.

8.1.1.2. Tässä osassa kuvataan koordinointivaiheen dialogimenettelyssä siirron olosuhteiden suunnittelussa käytetyt sanomat. Siirtovaiheen, jossa lennon luovutus tapahtuu, sanomat on kuvattu osassa 9 "dialogimenettely - kommunikoinnin siirto".

8.1.1.3. Näiden kahden vaiheen menettelyt eivät ole toisistaan riippuvaisia, vaan ne voidaan panna toimeen erikseen tai yhdessä.

8.1.1.4. Käyttöön otetaan joitakin uusia sanomia, ja molemmat osapuolet voivat panna dialogin alulle.

8.1.1.5. Koordinointidialogimenettelyn avulla voidaan tunnistaa:

- siirrot, jotka ovat sopimuskirjeen mukaisia ja jotka voidaan hyväksyä automaattisesti, sekä

- siirrot, jotka tulee lähettää vastaanottavan yksikön lennonjohtajalle hyväksyttäviksi.

8.1.1.6. Menettely mahdollistaa myös järjestelmien välisen sopimuskirjeen tulkintojen seurannan ja tulkintojen välisten ristiriitojen tunnistamisen.

8.1.2. Suodin

8.1.2.1. Yleistä

8.1.2.1.1. Koordinointidialogimenettely edellyttää järjestelmien tunnistavan sen, ovatko siirrot sopimuskirjeen mukaisia.

8.1.2.1.2. Tunnistuksen suorittavaan prosessiin viitataan tässä asiakirjassa nimellä "suodin". Suotimeen käytetyn tietokannan tulee sisältää seuraavat tiedot, mikäli tarpeen:

- sovitut koordinointipisteet,

- käytettävissä (tai ei käytettävissä) olevat lentokorkeudet, jotka voidaan myös yhdistää koordinointipisteisiin,

- lähtölentoasemat,

- määränpäät,

- sovitut suorat reitit,

- aika- ja/tai etäisyysrajat ennen COP:tä, minkä jälkeen koordinointisanoman katsotaan olevan epästandardi,

- mitkä tahansa muut kahdenvälisesti sovitut olosuhteet.

8.1.2.1.3. Mainittuja tietoja voidaan yhdistää määrittelemään monimutkaisempia ehtoja.

8.1.2.1.4. Tämän asiakirjan osassa 8 termi "standardit olosuhteet" tarkoittaa "sopimuskirjeen mukainen" ja termi "epästandardit olosuhteet" tarkoittaa "ei sopimuskirjeen mukainen". Ellei toisin ole kahdenvälisesti sovittu, tulee siirtävien yksiköiden käyttää standardien olosuhteiden koordinointien sanomissa eri sanomatyyppejä kuin epästandardien olosuhteiden.

8.1.2.2. Toiminta siirtävässä yksikössä

8.1.2.2.1. Siirtävän yksikön suotimen tulee tarkastaa hyväksyvälle yksikölle lähetettäväksi aiotut siirto-olosuhteet.

8.1.2.2.2. Suositus

Jos havaitaan, että siirto-olosuhteet ovat epästandardit, tulisi asiasta tiedottaa siirtävälle lennonjohtajalle vahvistusta tai muutosta varten.

8.1.2.3. Toiminta hyväksyvässä yksikössä

8.1.2.3.1. Kaikki ACT- ja REV-sanomat tulee tarkistaa suotimen avulla.

8.1.2.3.2. Jos tarkistuksessa havaitaan, että vastaanotetut siirto-olosuhteet ovat epästandardit, ne tulee lähettää ratkaistavaksi lennonjohtajalle; muussa tapauksessa ne hyväksytään automaattisesti.

8.1.2.4. Suotimien yhdenmukaistaminen

8.1.2.4.1. Erilaisten sanomien käyttö standardeihin ja epästandardeihin siirto-olosuhteisiin mahdollistaa ristiriitojen tunnistamisen siirtävien ja hyväksyvien järjestelmien välisissä käsityksissä siitä, mitkä ovat standardiolosuhteet.

8.1.2.4.2. Jos hyväksyvä yksikkö havaitsee epästandardeja siirto-olosuhteita sanomassa, jota käytetään ainoastaan standardien siirtojen koordinointiin se merkitsee sitä, että kahden suotimen välillä on ristiriita. Tällaiset ristiriidat tulisi ratkaista, jotta dialogimenettely voi toimia tehokkaasti.

8.1.3. Sanomajakso

8.1.3.1. Yleistä

8.1.3.1.1. Tiettyjä sääntöjä täytyy noudattaa, jotta varmistetaan, että koordinointi on saatu valmiiksi ennen korjausten tekemistä tai kommunikoinnin siirron sanomien lähettämistä ja että yksiköiden lennonjohtajat eivät tee samaa lentoa koskevia ehdotuksia samanaikaisesti.

8.1.3.1.2. ATC-yksikkö saa lähettää tai kuitata saaneensa korjaussanoman (REV tai RRV) lennolle ainoastaan silloin, kun se on koordinoidussa tilassa eli kun ACT- tai RAP-dialogi on päättynyt LAM- tai ACP-sanomaan.

8.1.3.1.3. Vain hyväksyvä yksikkö saa lähettää CDN-sanomia.

8.1.3.1.4. CDN-sanomia tulee lähettää ja hyväksyä ainoastaan:

- osana dialogia, joka on pantu alulle aktivointisanomien (ACT, RAP) tai korjaussanoman (REV tai RRV) vastaanoton jälkeen, tai

- kun kyseisen lennon lentosuunnitelma on koordinoidussa tilassa.

8.1.4. Samanaikainen sanomankäsittely

8.1.4.1. Yleistä

8.1.4.1.1. Lennon koordinointi- tai siirtosanomavaihdossa mukana oleva yksikkö ei saa panna alulle uutta koordinointi- tai siirtosanomavaihtoa samalle lennolle saman yksikön kanssa ennen kuin joko LAM, ACP tai RJC on vastaanotettu tai sallittu vastaustauko on kulunut umpeen.

8.1.4.1.2. On mahdollista, että CDN-sanoma risteää siirtävän yksikön samalle lennolle lähettämän REV-, RRV- tai MAC-sanoman kanssa. Tilanne voidaan havaita siirtävässä yksikössä CDN:n saapuessa ennen lähetetyn koordinointisanoman kuittausta ja hyväksyvässä yksikössä siirtävän yksikön sanoman saapuessa ennen CDN-sanoman kuittausta. Tässä tapauksessa CDN-sanomaa ei tule kuitata ja REV, RRV tai MAC tulee käsitellä.

8.1.5. Hylkäyksen käsittely

RJC-sanoma lopettaa järjestelmädialogin. Uusi järjestelmäkoordinointi tulee saattaa alulle (puhelinkoordinointia käyttäen, milloin tarkoituksenmukaista).

8.1.6. Toiminnallinen vastaustauko

8.1.6.1. Yleistä

8.1.6.1.1. Lähettävässä ja vastaanottavassa keskuksessa tulee soveltaa vastaustaukomekanismia lennonjohtajalle ratkaistavaksi lähetettyihin sanomiin vastaamiseen.

8.1.6.1.2. Näiden vastaustaukojen kesto tulee sopia kahdenvälisesti.

8.1.6.1.3. Vastaustauon loppuunkulumisesta siirtävässä yksikössä tulee siirtävälle lennonjohtajalle tulostaa varoitus, joka ilmaisee tarpeen aloittaa koordinointi puhelimitse.

8.1.6.1.4. Suositus

1. Lennosta hyväksyvässä yksikössä vastaavaan ATC-työpisteeseen tulisi tulostaa varoitus, kun vastaustauko on päättymässä.

2. Varoituksen tulisi jättää aikaa mahdollisen vastauksen lähettämiseen.

8.1.6.1.5. Järjestelmien tulee kyetä käsittelemään vastauksia, jotka on saatu vastaustauon päättymisen jälkeen.

8.1.7. Toteutus

8.1.7.1. Dialogimenettelyt koskevat kahta vaihetta, koordinointivaihetta ja siirtovaihetta. Dialogi käyttää näissä kahdessa vaiheessa eri sanomia ja siirtotapahtuma-aikoja. Koordinointisanomat on määritelty sekä ICAO- että ADEXP-formaatin, kommunikoinnin siirtosanomat ainoastaan ADEXP-formaatin mukaisina.

8.1.7.2. Käyttöliittymän vähimmäisvaatimukset koordinointidialogille eroavat siirtodialogin vähimmäisvaatimuksista:

- siirtodialogi kohdistuu lähinnä toimeenpanevan lennonjohtajan tehtävään ja vaatii nopean ja käyttäjäystävällisen käyttöliittymän,

- koordinointidialogi ei ole yhtä kriittinen ajan osalta, minkä vuoksi sen käyttöliittymävaatimukset eivät ole yhtä tiukat.

8.1.7.3. Dialogimenettely tulee toteuttaa käyttäen jotain seuraavista vaihtoehtoisista järjestelyistä:

- koordinointivaiheen dialogimenettely sekä kahdenvälisesti sovitut täydentävät sanomat (osat 7 ja 8),

- peruskoordinointimenettely ja siirtovaiheen dialogimenettely (osat 6, 7, 8 ja 9),

- koordinointi- ja siirtovaiheen dialogimenettely sekä kahdenvälisesti sovitut täydentävät koordinointisanomat (osat 7, 8 ja 9).

Kaikissa järjestelyissä tulee lähettää rajatiedon ennakkoilmoitussanoma (ABI).

8.1.7.4. Toteutuksessa käytettävästä järjestelystä tulee sopia kahdenvälisesti.

8.2. Aktivointisanoma ACT (Activate)

8.2.1. ACT-sanoman tarkoitus

ACT-sanoman tarkoitus on kuvattu kohdassa 6.3.1. Dialogimenettelyssä ACT-sanomaa käytetään täyttämään nämä vaatimukset edellyttäen, että lennon siirto-olosuhteet ovat standardit ja että siirtävän lennonjohtajan ei tarvitse lähettää lentoa hyväksyvälle lennonjohtajalle hyväksyntää varten.

8.2.2. Sanoman sisältö

Dialogimenettelyssä käytettävän ACT-sanoman sisältö on kuvattu kohdassa 6.3.2.

8.2.3. Soveltamissäännöt

8.2.3.1. Yleistä

8.2.3.1.1. Soveltamissäännöt ovat ACT-viestien osalta kohdassa 6.3 kuvatun kaltaiset, jollei tässä kohdassa kuvatuista erityissäännöistä muuta johdu.

8.2.3.1.2. ACT-sanoma tulee lähettää lennolle, jolla on standardit siirto-olosuhteet, joita siirtävän lennonjohtajan ei tarvitse lähettää ratkaistavaksi hyväksyvälle lennonjohtajalle.HUOM.

Jos nämä edellytykset eivät toteudu, lähetetään RAP (ks. Kappale 8.3 "ratkaistavaksi lähetetty aktivointiehdotussanoma").

8.2.3.1.3. Suositus

Jos ACT-sanomaan palautetaan vastauksena koordinoinnin hylkäyssanoma (RJC), tulisi aloittaa uusi koordinointimenettely.

8.2.3.2. Käsittely vastaanottavassa yksikössä

8.2.3.2.1. Sanoma tarkistetaan suotimen avulla, jotta voidaan varmistua, että ehdotetut olosuhteet ovat standardit.

8.2.3.2.2. Sanoma tulee käsitellä RAP-sanomana jos:

- siirto-olosuhteiden havaitaan olevan epästandardit,

- vastaavaa järjestelmälentosuunnitelmaa ei löydy eikä käytettävissä ole tarpeeksi tietoa, jotta voitaisiin todeta, ovatko siirto-olosuhteet standardit.

8.2.3.2.3. Standardeiksi havaitut ACT-sanomat tulee käsitellä kohdan 6.3.3.2. mukaisesti.

8.2.3.2.4. Suositus

Jos ACT-sanoman siirto-olosuhteet havaitaan epästandardeiksi, on järjestelmien suotimien välillä ristiriita. Tieto epästandardista ACT-sanomasta tulisi saattaa valvontahenkilökunnan tietoon, jotta ristiriita saadaan ratkaistuksi.

8.2.4. ACT-sanoman kuittaus

8.2.4.1. Kuittaus

8.2.4.1.1. Dialogimenettelyssä ACT-sanoma tulee kuitata:

- LAM-sanomalla, jos siirto-olosuhteet on todettu standardeiksi,

- kaikissa muissa tapauksissa SBY-sanomalla.

8.2.4.1.2. Kun LAM on vastaanotettu, ACT-sanoman toiminnallinen sisältö tulee molempia ATC-yksiköitä operatiivisesti sitovaksi.

8.2.4.1.3. LAM-sanoman sijaan voidaan käyttää ACP-sanomaa ilmaisemaan standardit siirto-olosuhteet sisältäneen ACT-sanoman hyväksyminen hyväksyvässä yksikössä, mikäli näin on sovittu kahdenvälisesti.

8.2.4.2. Ei kuittausta -tapaukset

Jos ACT-sanomaan ei saada kuittausta, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.3. Ratkaistavaksi lähetetty aktivointiehdotussanoma RAP (Referred Activate Proposal)

8.3.1. RAP-sanoman tarkoitus

RAP-sanoma täyttää seuraavat toiminnalliset vaatimukset kappaleessa 6.3. ACT-sanomalle määriteltyjen lisäksi:

- epästandardeja siirto-olosuhteita sisältävien lentojen siirtävän lennonjohtajan esitys ja hyväksyvän yksikön lennonjohtajalle ratkaistavaksi lähettäminen,

- siirtävän lennonjohtajan mahdollisuus niin halutessaan pakottaa standardit siirto-olosuhteet sisältävä lento lähetettäväksi hyväksyvälle lennonjohtajalle ratkaistavaksi.

8.3.2. Sanoman sisältö

RAP-sanoman tulee sisältää samat tiedot kuin mitä ACT-sanomalle on määritelty (kappale 6.3), minkä lisäksi se voi sisältää valinnaisesti seuraavan tiedon:

- syy; manuaalinen ratkaistavaksi lähettäminen (käytössä ainoastaan ADEXP:issä).

8.3.3. Soveltamissäännöt

8.3.3.1. Yleistä

8.3.3.1.1. RAP-sanoma tulee lähettää ACT-sanoman sijaan rajan ylittävälle lennolle, mikäli jokin seuraavista ehdoista täyttyy:

- siirtävä yksikkö on todennut, että siirto-olosuhteet ovat epästandardit,

- siirtävä lennonjohtaja on ilmaissut, että esitetyt siirto-olosuhteet tulee lähettää hyväksyvälle lennonjohtajalle ratkaistaviksi.

8.3.3.1.2. Lähetettäväksi aiotun RAP-sanoman toiminnallisen sisällön tulee näkyä lennon koordinoinnista vastaavassa työpisteessä ennen varsinaista lähetystä.

8.3.3.1.3. Suositus

Ajan, jolloin RAP-sanoma lähetetään automaattisesti, tulisi näkyä viestin sisällön yhteydessä.

8.3.3.1.4. Asiaankuuluvalle työpisteelle tulee ilmoittaa RAP-sanoman lähettämisestä.

8.3.3.2. Käsittely vastaanottavassa yksikössä

8.3.3.2.1. RAP-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

8.3.3.2.2. Jos vastaava lentosuunnitelma löytyy eikä sanomassa ole ristiriitoja, jotka estäisivät normaalin käsittelyn:

- toiminnallinen sisältö tulee lähettää hyväksyvälle lennonjohtajalle ratkaistavaksi,

- SBY-sanoma tulee palauttaa.

8.3.3.2.3. Suositus Maininta ratkaistavaksi lähettämisen syystä (epästandardit olosuhteet tai manuaalinen ratkaistavaksi lähettäminen) tulisi olla mukana.

8.3.3.2.4. Jos sanomaa ei voida yhdistää lentosuunnitelmaan tai sanomassa on ristiriita, joka estää normaalin käsittelyn, tulee:

- sanoman toiminnallinen sisältö näyttää sektorissa,

ja

- SBY-sanoma palauttaa,

sekä

- luoda lentosuunnitelma.

8.3.3.2.5. Kaikissa muissa tapauksissa sanomaa ei tule kuitata.

8.3.3.3. Manuaalinen lähetys

8.3.3.3.1. Kun RAP-sanomaa käytetään standardit siirto-olosuhteet sisältävän ehdotetun koordinoinnin pakkolähetykseen hyväksyvän lennonjohtajan ratkaistavaksi, se saatetaan alulle manuaalisesti siirtävän lennonjohtajan toimesta ja lähetetään välittömästi.

8.3.3.3.2. Suositus

RAP-sanoman manuaalisen lähettämisen ennen laskettua lähetysaikaa tulisi olla mahdollista lennon koordinoinnista vastaavasta työpisteestä.

8.3.3.4. Automaattisen lähetyksen aikaparametrit

Rajaa edeltävän ajan tai etäisyyden, jossa RAP-sanomat lähetetään automaattisesti, tulee olla sama kuin mitä ACT-viesteille on määritelty.

8.3.4. RAP-sanoman kuittaus

8.3.4.1. Kuittaus

Sanoma tulee kuitata generoimalla ja lähettämällä SBY-sanoma.

8.3.4.2. Ei kuittausta -tapaus

Jos RAP-sanomaan ei saada kuittauksena SBY-sanomaa, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näkyä varoitus.

8.3.5. RAP-sanoman toiminnallinen vastaus

Hyväksyvä lennonjohtaja voi joko hyväksyä tai hylätä siirto-olosuhteet tai tehdä niistä vastaehdotuksen.

8.3.5.1. Hyväksyntä

8.3.5.1.1. Kun hyväksyvä lennonjohtaja päättää hyväksyä ehdotetut siirto-olosuhteet, ACP-sanoma tulee palauttaa.

8.3.5.1.2. Heti kun ACP-sanoma on vastaanotettu, RAP-sanoman sisällöstä tulee operatiivisesti molempia ATC-yksiköitä sitova. Koordinoidut siirto-olosuhteet sekä tieto siitä, että ACP on vastaanotettu, tulee esittää siirtävälle lennonjohtajalle.

8.3.5.2. Vastaehdotus

CDN-sanoma tulee palauttaa silloin, kun hyväksyvä lennonjohtaja päättää tehdä siirto-olosuhteista vastaehdotuksen.

8.3.5.3. Suositus

RJC-sanoma tulisi palauttaa silloin, kun hyväksyvä lennonjohtaja päättää hylätä ehdotetut siirto-olosuhteet. Sen jälkeen tulisi aloittaa uusi koordinointimenettely.HUOM.

Mitä kohdan 8.3.5.3. suositukseen tulee, useimmissa tapauksissa uusi koordinointi tapahtuu eri yksikön kanssa.

8.3.6. Esimerkkejä

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. Korjaussanoma REV (Revision)

8.4.1. REV-sanoman tarkoitus

REV-sanoman tarkoitus on kuvattu kohdassa 7.3.1. Dialogimenettelyssä REV-sanomaa käytetään näiden vaatimusten täyttämiseen, edellyttäen että lennon siirto-olosuhteet ovat standardit ja ettei siirtävän lennonjohtajan tarvitse lähettää lentoa hyväksyvän lennonjohtajan ratkaistavaksi hyväksymistä varten.

8.4.2. Sanoman sisältö

REV-sanoman sisällön tulee olla kohdassa 7.3.2 kuvatun REV-sanoman kaltainen.

8.4.3. Soveltamissäännöt

8.4.3.1. Yleistä

8.4.3.1.1. Yksi tai useampi REV-sanoma voidaan lähettää yksikölle, jolle lento on koordinoitu aktivointi- tai RAP-sanoman avulla.

8.4.3.1.2. REV-sanomat tulee lähettää kohdan 7.3.3.1 mukaisissa olosuhteissa lennoille, joilla on standardit olosuhteet ja joita siirtävän lennonjohtajan ei tarvitse lähettää hyväksyvän lennonjohtajan ratkaistaviksi.

8.4.3.2. Lähetyksen alullepano

REV-sanoma tulee lähettää välittömästi sen jälkeen, kun on havaittu koordinoinnissa tarvitun koordinointitiedon muuttuminen, kuten kohdassa 7.3.3 on määritelty.

8.4.3.3. Käsittely vastaanottavassa yksikössä

8.4.3.3.1. Jos löydetään koordinoidussa tilassa oleva vastaava lentosuunnitelma, eikä sanomassa ole normaalia käsittelyä estävää ristiriitaa:

- REV-sanoma tulee kuitata,

- kaikissa muissa tapauksissa sanomaa ei tule kuitata.

8.4.3.3.2. Tulee tarkistaa, että siirto-olosuhteiden ovat standardit.

8.4.3.3.3. Siirto-olosuhteet tulee esittää hyväksyvälle lennonjohtajalle, mikäli ne eivät ole standardit.

8.4.3.3.4. Jos esitetyt siirto-olosuhteet havaitaan standardeiksi, tulee ne sisällyttää lentosuunnitelmaan ja vaadittavat tiedot tulostaa operatiivisiin ja muihin asianmukaisiin ATC-työpisteisiin.

8.4.3.3.5. Suositus

Jos REV-sanoman siirto-olosuhteet havaitaan epästandardeiksi, järjestelmien suotimissa on ristiriita. Tieto epästandardista REV-sanomasta tulisi toimittaa valvovalle henkilökunnalle ristiriidan poistamiseksi.

8.4.4. REV-sanoman kuittaus

8.4.4.1. Kuittaus

8.4.4.1.1. Jos REV-sanoma tulee kuitata, tehdään kuittaus:

- LAM-sanomalla, jos siirto-olosuhteet havaitaan standardeiksi,

- SBY-sanomalla, jos siirto-olosuhteet havaitaan epästandardeiksi.

8.4.4.1.2. Kun LAM on vastaanotettu, tulee REV-sanoman toiminnallisesta sisällöstä molempia ATC-yksiköitä sitova.

8.4.4.1.3. Silloin kun niin on kahdenvälisesti sovittu, voidaan ACP:tä käyttää LAM:in sijaan osoittamaan, että hyväksyvä yksikkö hyväksyy standardit siirto-olosuhteet sisältävän REV-sanoman.

8.4.4.2. Ei kuittausta -tapaukset

Jos REV-sanomaan ei saada kuittausta, tulee lentojen koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.4.5. REV-sanoman toiminnallinen vastaus

Koska REV-sanomaa käytetään standardien siirto-olosuhteiden lähetykseen, hyväksyvän yksikön järjestelmä yleensä hyväksyy sen. Jos hyväksyvän yksikön suodin havaitsee siirto-olosuhteiden olevan epästandardit, sanoma tulee käsitellä RRV-sanomana.

8.5. Ratkaistavaksi lähetetty korjausehdotussanoma RRV (Referred Revision Proposal)

8.5.1. RRV-sanoman tarkoitus

RRV-sanoma mahdollistaa aiemmin lähetettyjen ja sovittujen siirto-olosuhteiden korjaamisen seuraavissa tapauksissa:

- kun korjauksen ehdottamat siirto-olosuhteet ovat epästandardit,

- kun ehdotettu korjaus on standardi, mutta siirtävä lennonjohtaja haluaa lähettää korjauksen hyväksyvän lennonjohtajan ratkaistavaksi.

8.5.2. Sanoman sisältö

RRV-sanoman sisällön tulee olla kohdassa 7.3.2 kuvatun REV-sanoman kaltainen sekä mahdollisesti sisältää seuraava valinnainen tieto:

- syy, manuaalinen ratkaistavaksi lähettäminen (käytössä ainoastaan ADEXP:ssä).

8.5.3. Soveltamissäännöt

8.5.3.1. Yleistä

Yksi tai useampia RRV-sanomia tulee lähettää REV-sanoman sijaan kutakin korjausta kohti, jos joko:

- siirtävä järjestelmä on määrittänyt siirto-olosuhteet epästandardeiksi,

tai

- siirtävä lennonjohtaja on ilmaissut, että ehdotetut siirto-olosuhteet tulee lähettää hyväksyvälle lennonjohtajalle ratkaistavaksi. RRV:n käyttö tähän tarkoitukseen on vapaaehtoista.

8.5.3.2. Lähetyksen alullepano

RRV-sanoma tulee lähettää välittömästi sen jälkeen, kun koordinointitiedossa on havaittu muutos tai kun se on pantu alulle manuaalisesti.

8.5.3.3. Käsittely vastaanottavassa yksikössä

8.5.3.3.1. Jos löydetään koordinoidussa tilassa oleva vastaava lentosuunnitelma, eikä sanomassa ole normaalia käsittelyä estävää ristiriitaa:

- RRV-sanoma tulee kuitata,

- kaikissa muissa tapauksissa sanomaa ei tule kuitata.

8.5.3.3.2. Ehdotetut siirto-olosuhteet tulee näyttää lennon koordinoinnista vastaavassa ATC-työpisteessä.

8.5.3.3.3. Suositus

Maininta ratkaistavaksi lähettämisen syystä (epästandardit olosuhteet tai manuaalinen ratkaistavaksi lähettäminen) tulisi olla mukana.

8.5.4. RRV-sanoman kuittaus

8.5.4.1. Kuittaus

Sanoma tulee kuitata generoimalla ja lähettämällä SBY-sanoma.

8.5.4.2. Ei kuittausta -tapaukset

Jos RRV-sanomaan ei saada kuittauksena SBY-sanomaa, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.5.5. RRV-sanoman toiminnallinen vastaus

Hyväksyvä lennonjohtaja voi joko hyväksyä tai hylätä RRV-sanoman tai tehdä siitä vastaehdotuksen.

8.5.5.1. Hyväksyntä

ACP-sanoma tulee palauttaa silloin, kun hyväksyvä lennonjohtaja päättää hyväksyä ehdotetun lisäyksen sovittuihin siirto-olosuhteisiin.

8.5.5.2. Vastaesitys

CDN-sanoma tulee palauttaa silloin, kun hyväksyvä lennonjohtaja päättää tehdä siirto-olosuhteista vastaesityksen.

8.5.5.3. Hylkäys

Kun hyväksyvä lennonjohtaja päättää hylätä ehdotetun lisäyksen sovittuihin siirto-olosuhteisiin:

- tulee palauttaa RJC-sanoma,

sekä

- panna alulle uusi koordinointimenettely.

Mikäli RRV-sanomaan ei saada vastauksena ACP- tai CDN-sanomaa, se merkitsee hylkäystä.

8.5.6. Esimerkkejä

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. Valmiussanoma SBY (Stand-by)

8.6.1. SBY-sanoman tarkoitus

SBY-sanoma kuittaa siirto-olosuhteita ehdottavan sanoman vastaanotetuksi ja ilmaisee, että ehdotus on lähetetty ratkaistavaksi lennonjohtajalle päätöstä varten.

8.6.2. Sanoman sisältö

SBY-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

8.6.3. Soveltamissäännöt

8.6.3.1. Yleistä

SBY-sanoma tulee generoida ja lähettää välittömästi automaattisesti vastauksena:

- RAP-, RRV- tai CDN-sanomaan,

- suotimeen pysähtyneeseen ACT- tai REV-sanomaan.

8.6.4. SBY-sanoman kuittaus

SBY-sanomaa ei kuitata.

8.6.5. Esimerkkejä

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. Hyväksyntäsanoma ACP (Acceptance)

8.7.1. ACP-sanoman tarkoitus

ACP-sanoma täyttää seuraavat toiminnalliset vaatimukset ATC-koordinointi- ja siirtovaiheiden aikana:

- ilmaisee, että yksikön lennonjohtaja hyväksyy manuaalisesti vastapuolen jossain seuraavista viesteistä ehdottamat siirto-olosuhteet:

- RAP,

- RRV,

- CDN,

- ACT ja REV, jos jompikumpi on havaittu epästandardiksi,

- kahdenvälisesti sovittuna suorittaa sellaisen ACT- tai REV-sanoman automaattisen hyväksynnän, joka on läpäissyt hyväksyvän yksikön suotimen (LAM:in sijaan),

- kahdenvälisesti sovittuna ilmaisee HOP-sanoman manuaalisen hyväksymisen (ROF-sanoman sijaan).

8.7.2. Sanoman sisältö

ACP-sanoma koostuu seuraavista tiedoista:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite,

- Valinnaiset tiedot - sanoma voi sisältää myös seuraavan tiedon:

- Taajuus,

- ICAO-rakenteisen sanoman valinnaiset tiedot - sanoma voi sisältää kaikki seuraavat kohdat:

- Lentokoneen tunnistetiedot,

- Lähtölentoasema,

- Määränpäälentoasema.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

8.7.3. Soveltamissäännöt

8.7.3.1. Yleistä

8.7.3.1.1. ACP-sanoman sanomaviitteen tulee sisältää sen sanoman sanomanumero, johon sillä vastataan.

8.7.3.1.2. Taajuuskentän, silloin kun sitä käytetään, tulee sisältää taajuus, jolla lennon tulee ottaa yhteys hyväksyvään yksikköön luovutuksen yhteydessä.

8.7.3.1.3. ACP-sanoma tulee lähettää lennonjohtajan hyväksyttyä manuaalisesti ACT-, RAP-, REV-, RRV- tai CDN-sanomalla toimitetun ehdotuksen siirto-olosuhteista.

8.7.3.1.4. ACP-sanoma voidaan lähettää vaihtoehtoisena ROF-sanomalle vastauksena HOP-sanomaan.

8.7.3.1.5. ACP-sanoma tulee generoida ja lähettää automaattisesti järjestelmän toimesta vastauksena ACT- tai REV-sanomaan, joka on läpäissyt suotimen, jos niin on kahdenvälisesti sovittu.

8.7.3.1.6. Sovitut siirto-olosuhteet ovat molempia yksiköitä sitovia ACP-sanoman vastaanoton jälkeen.

8.7.3.2. Käsittely vastaanottavassa yksikössä

8.7.3.2.1. ACP-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

8.7.3.2.2. Jos ACP-sanoman yhdistäminen lentosuunnitelmaan onnistuu, tulee hyväksymisestä ilmoittaa lennonjohtajalle.

8.7.3.2.3. Jos ACP:tä ei voida yhdistää lentosuunnitelmaan:

- tulee asianmukaisessa työpisteessä tulostaa varoitus,

- LAM-sanomaa ei tule lähettää.

8.7.4. ACP-sanoman kuittaus

8.7.4.1. Kuittaus

8.7.4.1.1. LAM-sanomaa ei tule palauttaa silloin, kun ACP:tä käytetään automaattisena vastauksena suotimen läpäisseelle ACT- tai REV-sanomalle.

8.7.4.1.2. Manuaalisen hyväksymisen seurauksena lähetetty ACP-sanoma tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

8.7.4.2. Ei kuittausta -tapaukset

Jos manuaalisen hyväksymisen seurauksena lähetettyyn ACP-sanomaan ei saada kuittauksena LAM-sanomaa, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.7.5. Esimerkkejä

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. Koordinointisanoma CDN (Co-ordination)

8.8.1. CDN-sanoman tarkoitus

CDN-sanoma täyttää seuraavat toiminnalliset vaatimukset:

- hyväksyvän lennonjohtajan vastaesityksen toimittaminen siirtävälle lennonjohtajalle vastauksena ACT-, RAP-, REV- tai RRV-sanomaan,

- sovittuja siirto-olosuhteita koskevan, hyväksyvän lennonjohtajan tekemän muutosehdotuksen alulle paneminen siirtävälle lennonjohtajalle.

8.8.2. Sanoman sisältö

CDN-sanoma sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite (ainoastaan, mikäli vastauksena toiseen sanomaan),

- Lentokoneen tunnistetiedot,

- Lähtölentoasema,

- Määränpäälentoasema,

HUOM.

Sanoman tulee sisältää myös toinen tai molemmat seuraavista:

- Arviotieto (mikäli kyseessä ICAO-sanoma) tai siirtolentokorkeus (mikäli kyseessä ADEXP-sanoma),

- Suoran reitin pyyntö.

- Kahdenvälisesti sovitut tiedot - seuraavat tiedot voidaan sisällyttää, mikäli niin on kahdenvälisesti sovittu:

- Taajuus.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

8.8.3. Soveltamissäännöt

8.8.3.1. Yleistä

8.8.3.1.1. Ainoastaan hyväksyvä lennonjohtaja saa panna alulle CDN-sanomia.

8.8.3.1.2. Sitä käytetään vastaesityksen lähetykseen hyväksyvältä lennonjohtajalta siirtävälle lennonjohtajalle.HUOM.

Tämä voi dialogissa olla joko vastauksena ACT-, RAP-, REV- tai RRV-sanomalla toimitettuun ehdotukseen tai aloittamassa dialogia aiemmin sovittujen siirto-olosuhteiden korjaamiseksi.

8.8.3.1.3. Sanomaviite tulee sisällyttää vain, jos CDN-sanoma on vastaus toiseen sanomaan.

8.8.3.1.4. Mikäli se on mukana, tulee sanomaviitteen sisältää sen sanoman sanomanumero, johon CDN toimii vastauksena.

8.8.3.1.5. Suoran reitin pyyntötoimintoa (kuvattu yksityiskohtaisesti liitteessä A) tulee:

- käyttää ainoastaan, jos niin on kahdenvälisesti sovittu, sekä

- mikäli sovittu, määritellä sen käytön operatiiviset rajat.

8.8.3.1.6. CDN-sanomaa ei tule lähettää yksiköiden välisessä sopimuskirjeessä määritellyn rajaa edeltävän aika- tai etäisyysmarginaalin sisällä.

8.8.3.1.7. Jos käy niin, että CDN lähetetään käytännössä samanaikaisesti samalle lennolle siirtävältä yksiköltä tulleen sanoman kanssa, kuten koordinoinnin korjauksen tai kumoamisen, ei tule lähettää kuittausta eikä toiminnallista vastausta.HUOM.

Tästä seuraa se, että kun kaksi sanomaa risteää, etusijalle tulee siirtävältä yksiköltä saapunut viesti ja molemmat luopuvat CDN-sanomasta. Tilanne voidaan havaita molemmissa yksiköissä siitä, että vastapuolelta on saatu sanoma ennen kuittauksen vastaanottamista.

8.8.3.1.8. CDN-sanoman sisällöstä tulee molempia ATC-yksiköitä operatiivisesti sitova heti, kun hyväksyntä on saatu. Koordinoidut siirto-olosuhteet ja tieto ACP-sanoman saannista tulee esittää asiaankuuluvalle ATC-henkilöstölle.

8.8.3.2. Käsittely vastaanottavassa yksikössä

8.8.3.2.1. Jos vastaava lentosuunnitelma löytyy eikä sanomassa ole ristiriitoja, jotka estäisivät normaalin käsittelyn:

- toiminnallinen sisältö tulee esittää lennon koordinoinnista vastaavalle ATC-työpisteelle,

ja

- SBY-sanoma tulee palauttaa.

8.8.3.2.2. SBY:tä ei tule palauttaa, mikäli CDN-sanomaa ei voida yhdistää lentosuunnitelmaan tai löytyy ristiriita, joka estää normaalin käsittelyn.

8.8.4. CDN-sanoman kuittaus

8.8.4.1. Kuittaus

Yllämainittujen olosuhteiden vallitessa CDN-sanoma tulee kuitata generoimalla ja lähettämällä SBY-sanoma.

8.8.4.2. Ei kuittausta -tapaukset

Jos CDN-sanomaan ei saada vastauksena SBY-sanomaa, tulee lennon koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.8.5. CDN-sanoman toiminnallinen vastaus

Lennonjohtaja voi joko hyväksyä tai hylätä CDN-sanomassa esitetyt siirto-olosuhteet.

8.8.5.1. Hyväksyntä

ACP-sanoma tulee palauttaa silloin, kun siirtävä lennonjohtaja päättää hyväksyä esitetyt siirto-olosuhteet.

8.8.5.2. Suositus

RJC-sanoma tulisi lähettää silloin, kun siirtävä lennonjohtaja päättää hylätä esitetyt siirto-olosuhteet (suora hylkäys).

HUOM.

Esitetty koordinointi on epäsuorasti hylätty, mikäli CDN-sanoman vastaustauon päätyttyä ei ole saatu hyväksymistä.

8.8.6. Esimerkkejä

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. Koordinoinnin hylkäyssanoma RJC (Reject Co-ordination)

8.9.1. RJC-sanoman tarkoitus

RJC-sanomalla ilmaistaan, että lennonjohtaja hylkää siirto-olosuhteita koskevan ehdotuksen, joka on tullut toisessa yksikössä olevalta lennonjohtajalta jossain seuraavista viesteistä:

- RAP,

- RRV,

- CDN,

- ACT ja REV, jos jompikumpi on havaittu epästandardeiksi.

RJC-sanomaa voidaan käyttää ainoastaan suorana vastauksena johonkin edellä olevista viesteistä.

8.9.2. Sanoman sisältö

RJC-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Sanomaviite.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

8.9.3. Soveltamissäännöt

8.9.3.1. Yleistä

8.9.3.1.1. RJC-sanoma tulee lähettää tarvittaessa vastauksena RAP-, RRV- tai CDN-sanomaan tai hyväksyvässä yksikössä epästandardiksi havaittuun ACT- tai REV-sanomaan.

8.9.3.1.2. RJC-sanoma päättää järjestelmädialogin, ja aikaisemmin sovittu koordinointi jää voimaan.

8.9.3.1.3. Suositus

RJC-sanoman vastaanottamisen jälkeen tulisi aloittaa uusi koordinointijakso (puhelinkoordinointia käyttäen, mikäli tarpeen).

8.9.3.2. Käsittely vastaanottavassa yksikössä

8.9.3.2.1. Jos RJC-sanomassa mainittu sanoma löytyy

- tulee hylkäyksestä ilmoittaa kyseessä olevan lennon koordinoinnista vastaavassa ATC-työpisteessä, ja

- LAM-sanoma tulee palauttaa kuittauksena.

8.9.3.2.2. Kuittausta ei tule lähettää, jos vastausta odottavaa sanomaa ei löydy tai sanomassa on ristiriita, joka estää sen käsittelyn.

8.9.4. RJC-sanoman kuittaus

8.9.4.1. Kuittaus

RJC-sanoma tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

8.9.4.2. Ei kuittausta -tapaukset

Jos RJC-sanomaan ei saada kuittauksena LAM-sanomaa, tulee lentojen koordinoinnista vastaavassa ATC-työpisteessä näyttää varoitus.

8.9.5. Esimerkkejä

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. DIALOGIMENETTELY - KOMMUNIKOINNIN SIIRTO

9.1. Yleistä

9.1.1. Johdanto

9.1.1.1. Standardin tässä osassa kuvataan toimintoja ja sanomia, joilla hoidetaan lennonjohtovastuun siirtomenettelyn tutkaluovutuspuolta. Ne tulee ottaa käyttöön, mikäli niin on kahdenvälisesti sovittu.

9.1.1.2. Kommunikoinnin siirtotoimintoja ei tule ottaa käyttöön, ellei yksikkö käytä joko osassa 6 (perusmenettely - pakolliset sanomat) tai kohdassa 8 (dialogimenettely - koordinointi) kuvattuja koordinointitoimintoja.

9.1.1.3. Asiakirjan tässä osassa kuvatut sanomat ovat käytössä ainoastaan ADEXP-formaatin mukaisina eikä niiden saattamista käyttöön ICAO-formaatin mukaisina suunnitella.

9.1.2. Sanomajakso

9.1.2.1. Kommunikoinnin siirtosanomien vaihtoa ei tule suorittaa, lukuun ottamatta täydentävää tietosanomaa (SDM), ellei koordinointi ole valmis eli ellei ACT- tai RAP-dialogia ole päätetty LAM- tai ACP-sanomalla.

9.1.2.2. Kuittausta ei tule palauttaa, mikäli koordinointi on kesken.

9.1.3. Kommunikoinnin siirto

9.1.3.1. Lentojen kommunikoinnin varsinaisen siirtotapahtuman menettelyn tulee olla kahdenvälisesti sovittu osapuolina olevien yksiköiden välillä.

9.1.3.2. Olosuhteiden tulee täyttää jompikumpi tai molemmat seuraavista edellytyksistä:

- siirtävä yksikkö lähettää taajuudenvaihtosanoman (COF),

- hyväksyvä yksikkö lähettää manuaalisen yhteyden vahvistus -sanoman (MAS),

9.1.3.3. Menettelystä tulee sopia yksiköiden välillä jokaista liikennevirtaa kohden.HUOM.

Vaihtoehtoisia menetelmiä voidaan käyttää eri virroille, esimerkiksi jokin yksikkö voi generoida COF-sanomia sen ilmatilasta poistuville lennoille ja MAS-sanomia sen ilmatilaan saapuville lennoille. Tällaisessa tapauksessa vastapuolen yksikön ei tarvitse lainkaan lähettää sanomia kommunikoinnin siirrossa.

9.2. Siirron alkuunpanosanoma TIM (Transfer Initiation)

9.2.1. TIM-sanoman tarkoitus

TIM-sanoman on tarkoitus:

- merkitä siirron alkuunpanotapahtumaa (TI) (koordinointivaiheen loppu ja siirtovaiheen alku),

- toimittaa samanaikaisesti lennonjohdon toimeenpanotiedot siirtävältä hyväksyvälle yksikölle.

9.2.2. Sanoman sisältö

TIM-sanoman tulee sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Saatavilla olevat tiedot - sanoman tulee sisältää seuraavista saatavilla olevat:

- Sallittu lentokorkeus,

- Ilmoitettu kurssi tai sallittu suora reitti,

- Ilmoitettu nopeus,

- Ilmoitettu nousu- tai laskeutumisnopeus,

- Valinnaiset tiedot - sanoma voi sisältää myös seuraavan tiedon:

- Sijainti.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.2.3. Soveltamissäännöt

9.2.3.1. Yleistä

9.2.3.1.1. TIM-sanoma tulee generoida ja lähettää siirtävän yksikön toimesta hyväksyvälle yksikölle ilman henkilökunnan toimintaa lennon tullessa kahdenvälisesti sovitun ajan tai etäisyyden päähän rajasta.

9.2.3.1.2. TIM-sanoma tulee myös lähettää automaattisesti, kun siirtävä yksikkö on saanut taajuusvaihtopyyntösanoman (ROF).

9.2.3.1.3. TIM-sanomaa ei tule lähettää, ennen kuin lento on koordinoitu.

9.2.3.1.4. TIM-sanoman tulee sisältää kaikkein viimeisin järjestelmässä saatavilla oleva tieto.

9.2.3.2. Lähetyksen aikaparametrit

9.2.3.2.1. TIM:n generointiparametrin tulee olla tyyppiä muunneltava järjestelmäparametri, joka voidaan asettaa sopimuskirjeen ehtojen mukaan.

9.2.3.2.2. Suositus

TIM-generoinnin järjestelmäparametrin tulisi olla erikseen määritelty jokaiselle COP:lle.

9.2.3.2.3. Koordinointikumppanien tulee sisällyttää TIM-generoinnin parametrit sopimuskirjeeseensä.

9.2.3.2.4. Järjestelmäparametri, joka laukaisee TIM-sanoman, voi liittyä lentokoneen laskettuun maanopeuteen. Kuitenkin TIM-sanoman alullepanon tulee aina käynnistyä ennen kuin lentosuunnitelman osoittama koneen sijainti on kahdenvälisesti sovitun vähimmäisetäisyyden päässä COP:stä.

9.2.3.2.5. TIM-lähetyksestä sovitun järjestelmäparametrin tulee jättää aikaa suulliselle koordinoinnille ennen luovutusta.

9.2.3.3. Käsittely vastaanottavassa yksikössä

9.2.3.3.1. TIM-sanomassa saadut tiedot tulee toimittaa hyväksyvälle lennonjohtajalle.

9.2.4. TIM-sanoman kuittaus

9.2.4.1. Kuittaus

Jos:

- TIM-sanoma voidaan yksiselitteisesti yhdistää lentosuunnitelmaan, se tulee kuitata generoimalla ja lähettämällä LAM-sanoma,

- TIM-sanomaa ei voida yksiselitteisesti yhdistää lentosuunnitelmaan, ei kuittausta tule lähettää.

9.2.4.2. Ei kuittausta -tapaukset

Jos TIM-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asiaankuuluvassa työpisteessä näyttää varoitus.

9.2.5. Esimerkki

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

9.3. Täydentävä tietosanoma SDM (Supplementary Data)

9.3.1. SDM-sanoman tarkoitus

9.3.1.1. Yleistä

9.3.1.1.1. SDM:n ensisijaisena tarkoituksena on lähettää lennonvalvontatietoa ja sen muutoksia siirtävältä yksiköltä hyväksyvälle yksikölle, edellyttäen että kahdenvälisesti on sovittu siitä, että hyväksyvän lennonjohtajan ei tarvitse kuitata muutoksia.

9.3.1.1.2. SDM-sanomaa voi käyttää myös hyväksyvä yksikkö tiedottaakseen siirtävälle yksikölle radiosanomataajuudesta, jolle lento siirretään.

9.3.2. Sanoman sisältö

9.3.2.1. Sanomat siirtävältä yksiköltä

SDM-sanoman tulee sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Lisätiedot - sanoman tulee sisältää myös yksi tai useampi seuraavista tiedoista:

- Ilmoitettu kurssi tai sallittu suora reitti,

- Ilmoitettu nopeus,

- Ilmoitettu nousu- tai laskeutumisnopeus,

- Sallittu lentokorkeus.

9.3.2.2. Sanomat hyväksyvältä yksiköltä

SDM-sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Taajuus.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.3.3. Soveltamissäännöt

9.3.3.1. Sanomat siirtävältä yksiköltä

9.3.3.1.1. SDM-sanomat tulee lähettää siirtovaiheen käynnistämisen jälkeen (ks. TIM, kohta 9.2) silloin kun joihinkin seuraavista on tullut muutoksia:

- sallittu lentokorkeus,

- ilmoitettu nopeus,

- ilmoitettu nousu- tai laskeutumisnopeus,

- ilmoitettu kurssi, tai

- lupa tai muutos aikaisempaan lupaan jatkaa suoraan erikseen määrättyyn pisteeseen.

HUOM.

HOP-sanomaa tulee käyttää silloin, kun hyväksyvän lennonjohtajan suostumus on tarpeen ennen kommunikoinnin siirtoa.

9.3.3.1.2. Sanoman tulee sisältää ainoastaan kentät, jotka ovat muuttuneet.

9.3.3.1.3. SDM-sanomat, jotka sisältävät kohdassa 9.3.3.1.1 mainittuja tietoja, tulee lähettää ennen siirron alkuunpanoa (TI), jos niin on kahdenvälisesti sovittu.

9.3.3.1.4. Tällaiset sanomat tulee aloittaa kahdenvälisesti sovittuna TI:hin suhteutettuna aikana, edellyttäen että järjestelmässä on saatavilla arvot halutuille tiedoille.

9.3.3.2. Sanomat hyväksyvältä yksiköltä

9.3.3.2.1. SDM-sanomia voidaan lähettää ilmaisemaan taajuutta, jolla lennon tulee ottaa yhteys hyväksyvään yksikköön.HUOM.

Yksiköt voivat sopia kahdenvälisesti lähettävänsä muuta tietoa. Sellaista vaihtoa ei määritellä tässä standardissa, eikä se siksi kuulu tähän standardiin.

9.3.3.2.2. Hyväksyvän yksikön tulee lähettää SDM-sanomat koordinointivaiheen aikana, mikäli niin on kahdenvälisesti sovittu.

9.3.3.3. Käsittely vastaanottavassa yksikössä

9.3.3.3.1. SDM-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

9.3.3.3.2. Jos löydetään vastaava, koordinoidussa tilassa oleva lentosuunnitelma:

- vastauksena lähetetään LAM-sanoma, sekä

- SDM-sanoman toiminnallinen sisältö saatetaan asianomaisen lennonjohtajan tietoon.

9.3.3.3.3. Jos vastaavaa lentosuunnitelmaa ei löydy tai sanomassa on ristiriita, joka estää sen normaalin käsittelyn:

- LAM-sanomaa ei tule lähettää, ja

- asianmukaisessa työpisteessä tulee näyttää varoitus.

9.3.4. SDM-sanoman kuittaus

9.3.4.1. Kuittaus

SDM-sanoma tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

9.3.4.2. Ei kuittausta -tapaukset

Jos SDM-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asianomaisessa työpisteessä näyttää varoitus.

9.3.5. Esimerkki

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

9.4. Siirtoehdotussanoma HOP (Hand-Over Proposal)

9.4.1. HOP-sanoman tarkoitus

HOP-sanoman tarkoituksena on:

- että siirtävä lennonjohtaja kiinnittää hyväksyvän lennonjohtajan huomion lentoon luovutustarkoitusta varten,

- että siirtävä lennonjohtaja ehdottaa lennon luovutusta hyväksyvälle lennonjohtajalle oikealla hetkellä,

- toimittaa sellaiset muutokset lennonjohdon toimeenpanotietoihin, jotka vaativat hyväksyvän lennonjohtajan vahvistuksen, sen mukaan mitä on kahdenvälisesti sovittu.

HOP-sanomaa ei tarvitse käyttää kaikkien lentojen osalta, vaan ainoastaan siirtävän lennonjohtajan harkinnan mukaan.HUOM.

Edellä olevan kolmannen kohdan osalta SDM-sanomaa käytetään sellaisten lennonjohdon toimeenpanotietojen muutosten toimittamiseen, jotka eivät vaadi hyväksyvän lennonjohtajan suostumusta.

9.4.2. Sanoman sisältö

HOP-sanoman tulee sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Saatavilla olevat tiedot - sanoman tulee sisältää seuraavista tiedoista saatavilla olevat:

- Sallittu lentokorkeus,

- Ilmoitettu kurssi tai sallittu suora reitti,

- Ilmoitettu nopeus,

- Ilmoitettu nousu- tai laskeutumisnopeus,

- Valinnaiset tiedot - sanoma voi sisältää myös seuraavan tiedon:

- Sijainti.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.4.3. Soveltamissäännöt

9.4.3.1. Yleistä

9.4.3.1.1. Silloin kun HOP-sanomaa käytetään, siirtävän lennonjohtajan tulee saattaa se alulle manuaalisesti.

9.4.3.1.2. Sanoman tulee sisältää sellaiset yllä kohdassa 9.4.2 kuvatut lentotiedot, jotka ovat muuttuneet aikaisemmin lähetetyistä.

9.4.3.1.3. Jos HOP-sanoma lähetetään ennen TI:tä, tulee siirtovaihe aloittaa.HUOM.

HOP:n lisäksi ei tarvita siirron alkuunpanosanomaa (TIM).

9.4.3.1.4. Kahdenvälisesti tulee sopia aikaisimmasta hetkestä tai etäisyydestä ennen COP:tä tai rajaa, jolloin HOP-sanoma voidaan lähettää.

9.4.3.1.5. Suositus

Aika tai etäisyys tulisi sopia erikseen jokaiselle COP:lle.

9.4.3.2. Käsittely vastaanottavassa yksikössä

9.4.3.2.1. HOP-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

9.4.3.2.2. Sanomassa saadut lentotiedot tulee näyttää välittömästi hyväksyvälle lennonjohtajalle.

9.4.3.2.3. Jos hyväksyvä lennonjohtaja hyväksyy lennon HOP:ssä esitettyjen olosuhteiden mukaan, voidaan vastauksena siirtävälle yksikölle lähettää ROF-sanoma. Kahdenvälisesti sovittuna HOP-sanomaan voidaan lähettää vastauksena myös ACP.

9.4.3.2.4. Jos hyväksyvä lennonjohtaja ei pysty hyväksymään lentoa, tulee siirrosta sopia suullisesti.HUOM.

Koska luovutusmenettely on kiireellinen, tässä standardissa ei vaadita järjestelmän tukevan ROF:n (tai ACP:n) palautuksen seurantaa; oletuksena on, että siirtävä lennonjohtaja on tietoinen vastauksen puutteesta ja toimii sen mukaisesti. Kuitenkaan tässä standardissa ei kielletä varoituksen toimittamista siirtävälle lennonjohtajalle, mikäli se on katsottu toiminnallisista syistä välttämättömäksi.

9.4.3.2.5. HOP-sanoman sisällöstä tulee molempia ATC-yksiköitä operatiivisesti sitova heti kun ROF (tai ACP) on saatu.

9.4.4. HOP-sanoman kuittaus

9.4.4.1. Kuittaus

HOP-sanoma tulee kuitata automaattisesti LAM-sanomalla, mikäli se voidaan yhdistää lentosuunnitelmatietoon.

9.4.4.2. Ei kuittausta -tapaukset

Jos HOP-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asianmukaisessa työpisteessä näyttää varoitus.

9.4.5. Esimerkki

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

9.5. Taajuusvaihtopyyntösanoma ROF (Request on Frequency)

9.5.1. ROF-sanoman tarkoitus

ROF-sanomalla, joka lähetetään tarvittaessa hyväksyvältä yksiköltä siirtävälle yksikölle, pyydetään siirtävää lennonjohtajaa kehottamaan konetta vaihtamaan hyväksyvän lennonjohtajan antamalle taajuudelle. Sanomaa voidaan käyttää:

- vastauksena HOP-sanomaan merkitsemään lennon hyväksymistä ehdotettujen olosuhteiden mukaan,

- pyytämään lennon aikaistettua siirtoa.

9.5.2. Sanoman sisältö

ROF-sanoman tulee sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Valinnaiset tiedot - sanoma voi sisältää myös seuraavan tiedon:

- Taajuus.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.5.3. Soveltamissäännöt

9.5.3.1. Yleistä

9.5.3.1.1. Hyväksyvän lennonjohtajan tulee saattaa ROF-sanoma alulle manuaalisesti.

9.5.3.1.2. Hyväksyvä lennonjohtaja voi käynnistää ROF-sanoman joko

- silloin, kun hyväksyvä lennonjohtaja haluaa koneen oikealle taajuudelle aikaisin,

- vastauksena HOP-sanomaan.

9.5.3.2. Käsittely vastaanottavassa yksikössä

9.5.3.2.1. ROF-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

9.5.3.2.2. ROF-sanoman vastaanotosta tulee ilmoittaa siirtävälle lennonjohtajalle välittömästi.

9.5.3.2.3. Jos lento ei ole siirtovaiheessa, tulee siirtovaihe saattaa alulle ja lähettää TIM-sanoma.

9.5.4. ROF-sanoman kuittaus

9.5.4.1. Kuittaus

9.5.4.1.1. Jos ROF-sanoma voidaan yksiselitteisesti yhdistää lentosuunnitelmaan se tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

9.5.4.1.2. Jos ROF-sanomaa ei voida yksiselitteisesti yhdistää lentosuunnitelmaan, ei kuittausta tule lähettää.

9.5.4.2. Ei kuittausta -tapaukset

Jos ROF-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asianmukaisessa ATC-työpisteessä näyttää varoitus.

9.5.5. Esimerkki

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

9.6. Taajuudenvaihtosanoma COF (Change of Frequency)

9.6.1. COF-sanoman tarkoitus

9.6.1.1. Yleistä

9.6.1.1.1. Siirtävä yksikkö lähettää COF-sanoman hyväksyvälle yksikölle ilmaistaakseen, että lentoa on kehotettu ottamaan yhteyttä hyväksyvään lennonjohtajaan.

9.6.1.1.2. Sanoma voi sisältää toiminnon, jolla siirtävä lennonjohtaja vapauttaa lennon sovituista siirto-olosuhteista sen jälkeen, kun se on saanut aikaan radioyhteyden hyväksyvään lennonjohtajaan.

9.6.2. Sanoman sisältö

COF-sanoman tulee sisältää seuraavat tiedot:

- Pakolliset tiedot - sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot,

- Saatavilla olevat tiedot - sanoman tulee sisältää seuraavista tiedoista saatavilla olevat:

- Osoitus vapautuksesta,

- Taajuus,

- Sallittu lentokorkeus,

- Ilmoitettu kurssi tai sallittu suora reitti,

- Ilmoitettu nopeus,

- Ilmoitettu nousu- tai laskeutumisnopeus,

- Valinnaiset tiedot - sanoma voi sisältää myös seuraavan tiedon:

- Sijainti.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.6.3. Soveltamissäännöt

9.6.3.1. Yleistä

9.6.3.1.1. COF-sanoman panee manuaalisesti alulle siirtävä lennonjohtaja.

9.6.3.1.2. COF-sanoman käyttö on pakollista, mikäli on sovittu kahdenvälisesti, että MAS-sanomaa ei käytetä.

9.6.3.1.3. Jos COF-sanoma lähetetään ennen TI:tä, tulee siirtovaihe aloittaa.HUOM.

COF:n lisäksi ei tarvita siirron alkuunpanosanomaa (TIM).

9.6.3.2. Käsittely vastaanottavassa yksikössä

9.6.3.2.1. COF-sanoman vastaanottavan ATC-yksikön tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

9.6.3.2.2. Hyväksyvälle lennonjohtajalle tulee ilmoittaa välittömästi saapuneesta COF-sanomasta.

9.6.4. COF-sanoman kuittaus

9.6.4.1. Kuittaus

9.6.4.1.1. Jos COF-sanoma voidaan yksiselitteisesti yhdistää lentosuunnitelmaan, se tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

9.6.4.1.2. Jos COF-sanomaa ei voida yksiselitteisesti yhdistää lentosuunnitelmaan, ei kuittausta tule lähettää.

9.6.4.2. Ei kuittausta -tapaukset

Asianmukaisessa ATC-työpisteessä tulee näyttää varoitus, mikäli COF-sanomaan ei saada kuittauksena LAM-sanomaa.

9.6.5. Esimerkkejä

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

9.7. Manuaalisen yhteyden vahvistus MAS (Manual Assumption of Communications)

9.7.1. MAS-sanoman tarkoitus

Hyväksyvä yksikkö lähettää MAS-sanoman siirtävälle yksikölle ilmaistakseen, että lentoon on saatu kaksisuuntainen radioyhteys.

9.7.2. Sanoman sisältö

MAS sanoman tulee sisältää seuraavat tiedot:

- Sanomatyyppi,

- Sanomanumero,

- Lentokoneen tunnistetiedot.

HUOM.

Tiedon syöttösäännöt, rakenteet ja kenttäsisällöt on määritelty liitteessä A.

9.7.3. Soveltamissäännöt

9.7.3.1. Yleistä

9.7.3.1.1. MAS-sanoma tulee saattaa alulle manuaalisesti hyväksyvän lennonjohtajan toimesta.

9.7.3.1.2. MAS-sanoman käyttö on pakollista, mikäli kahdenvälisesti on sovittu, että COF-sanomaa ei käytetä.

9.7.3.2. Käsittely vastaanottavassa yksikössä

9.7.3.2.1. MAS-sanoman vastaanottavan ATC-järjestelmän tulee yrittää yhdistää se vastaavaan lentosuunnitelmaan.

9.7.3.2.2. MAS-sanoman vastaanotosta tulee saattaa välittömästi tieto lennonjohtajalle.

9.7.4. MAS-sanoman kuittaus

9.7.4.1. Kuittaus

9.7.4.1.1. Jos MAS-sanoma voidaan yksiselitteisesti yhdistää lentosuunnitelmaan, se tulee kuitata generoimalla ja lähettämällä LAM-sanoma.

9.7.4.1.2. Jos MAS-sanomaa ei voida yksiselitteisesti yhdistää lentosuunnitelmaan, ei kuittausta tule lähettää.

9.7.4.2. Ei kuittausta -tapaukset

Jos MAS-sanomaan ei saada kuittauksena LAM-sanomaa, tulee asianmukaisessa ATC-työpisteessä näyttää tarpeen mukaan varoitus.

9.7.5. Esimerkki

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

LIITE A (Normatiivinen)

TIEDON SYÖTTÖSÄÄNNÖT

SISÄLTÖ

>TAULUKON PAIKKA>

A.1. Tarkoitus

Tässä liitteessä kuvataan yleiset säännöt tässä standardissa kuvattujen sanomien tiedon syöttöön. Nämä säännöt pätevät kaikkiin sanomiin lukuun ottamatta niitä sanomia, joista kyseisen sanoman soveltamissäännöissä on erikseen annettu poikkeuksia tai muut vaihtoehtoja.

A.2. Yleiset sanomaformaatit

A.2.1. Kaikki seuraavissa osissa kuvatut sanomat voidaan lähettää käyttäen ICAO-formaattia:

6 Perusmenettely - Pakolliset sanomat,

7 Perusmenettely - Täydentävät sanomat,

8 Dialogimenettely - Koordinointi.

A.2.2. ICAO-sanomien kenttäformaatit on määritelty asiakirjassa Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control (Asiakirja 4444). Sanomissa, joissa niitä esiintyy, tulee seuraavat ICAO-kenttätyypit lähettää ennen muita kenttätyyppejä seuraavassa järjestyksessä: 3, 7, 13, 14 ja 16. Muiden ICAO-kenttätyyppien järjestyksellä ei muuten ole merkitystä, koska ne ovat kenttätyypin 22 formaatissa, kunhan ne eivät ole ennen edellä mainittuja kenttätyyppejä.

A.2.3. Kaikki tässä asiakirjassa kuvatut sanomat voidaan lähettää käyttämällä Eurocontrol ADEXP-formaattia. ADEXP-tietokenttien sisällön, rakenteen ja käytön tulee olla viitteen 2 mukaisia.HUOM.

1. Tässä liitteessä on lueteltu ainoastaan ADEXP-järjestelmän ensisijaiset tietokentät, jos niihin liittyvät alikentät edellyttävät erityishuomautusta. ADEXP-standardissa luetellaan kaikki kunkin ensisijaisen kentän yhteydessä vaaditut valinnaiset ja pakolliset alikentät.

2. Osassa 9, "dialogimenettely - kommunikoinnin siirto", kuvatut sanomat on kuvattu vain ADEXP-formaatilla.

A.3. Sanomatyyppi

Sanomatyypistä tulee käyttää seuraavan luettelon mukaista lyhennettä:

ABI: Rajatiedon ennakkoilmoitus.

ACP: Hyväksyntä.

ACT: Aktivointi.

CDN: Koordinointi.

COD: SSR-koodinanto.

COF: Taajuudenvaihto.

HOP: Siirtoehdotus.

INF: Informaatio.

LAM: Looginen kuittaussanoma.

MAC: Koordinoinnin kumoamissanoma.

MAS: Manuaalisen yhteyden vahvistus.

PAC: Alustava aktivointi.

RAP: Ratkaistavaksi lähetetty aktivointiehdotus.

REV: Korjaus.

RJC: Koordinoinnin hylkäys.

ROF: Taajuusvaihtopyyntö.

RRV: Ratkaistavaksi lähetetty korjaus.

SBY: Valmius.

SDM: Täydentävä tietosanoma.

TIM: Siirron alkuunpanosanoma.

A.3.1. ICAO

Kenttätyyppi 3, tieto (a).

A.3.2. ADEXP

Pääkenttä "title".

A.4. Sanomanumero

Sanomanumeron tiedot sisältävät lähettävälle ja vastaanottavalle yksikölle annetut tunnukset sekä sanomajakson numeron. Kaikkien samalle vastaanottajalle lähetettyjen sanomien sanomajakson numero etenee järjestyksessä numerosta 001 numeroon 000 (merkitsee numeroa 1000), jonka jälkeen se alkaa uudestaan numerosta 001, sanoman tyypistä riippumatta.

A.4.1. ICAO

Kenttätyyppi 3, tieto (b).

A.4.2. ADEXP

Pääkenttä "refdata".

Alikentissä "sender" ja "recvr" olevan alikentän "fac" tulee sisältää ATC-yksiköiden tunnukset. Tunnukset eivät saa olla pidempiä kuin kahdeksan merkkiä.

Alikentän "seqnum" tulee sisältää jakson numero.

A.5. Sanomaviite

A.5.1. ICAO

Kenttätyyppi 3, tieto (c) (ICAO-asiakirjassa 4444 nimellä "reference data").

Elementin (c) sisällön tulee olla OLDI-sanomaviitteen kenttätyyppi 3, tieto (b).

A.5.2. ADEXP

Pääkenttä "msgref".

Alikenttien "sender", "recvr" ja "seqnum" arvojen ensisijaisen kentän "msgref" sisällä tulee olla samat kuin OLDI-sanomaviitteen ensisijaisen kentän "refdata" sisällä olevissa samoissa alikentissä.

A.6. Lentokoneen tunnistetiedot

A.6.1. ICAO

Kenttätyyppi 7, tieto (a).

A.6.2. ADEXP

Pääkenttä "arcid".

A.7. SSR-toimintatila ja -koodi

Joko:

1. mikäli tiedossa, SSR-toimintatila/koodi, jolla vastaanottava yksikkö voi odottaa koneen vastaavan lennonjohtovastuun siirtokohdassa,

tai

2. osoitus siitä, että SSR-koodia ollaan pyytämässä vastaanottavalta yksiköltä.

A.7.1. ICAO

Kenttätyyppi 7, tiedot (b) ja (c).

Jos SSR-koodia ei ole ilmoitettu tai toimintatila/koodi ei ole tiedossa, tiedot (b) ja (c) tulee jättää pois.

Kun SSR-koodia tai -toimintatilaa ollaan pyytämässä, tulee tietojen b) ja c) sisältää arvo "A9999".

A.7.2. ADEXP

Pääkenttä "ssrcode".

Jos voimassa olevaa SSR-koodia ei ole ilmoitettu tai toimintatila/koodi ei ole tiedossa, kenttä tulee jättää pois.

Kun pyydetään SSR-koodia tai -toimintatilaa PAC-sanoman avulla, tulee ensisijaisen kentän "ssrcode" sisältää ilmaisin "REQ".

A.8. Lähtölentoasema

A.8.1. ICAO

Kenttätyyppi 13, tieto (a).

A.8.2. ADEXP

Pääkenttä "adep".

A.9. Arviotieto

A.9.1. Yleistä

A.9.1.1. Arviotiedon tulee sisältää COP, aika COP:ssä, sekä siirtokorkeus.

A.9.1.2. Koordinointipiste tulee määritellä niin, että se on joko tunnettu kiintopiste, tietty etäisyys ja suunta tunnetusta kiintopisteestä, tai leveys- ja pituusaste.

A.9.1.3. Sallitun (siirto-) korkeuden tulee vastata ehdotettuja siirto-olosuhteita.

A.9.1.4. Suositus

Arviotiedon tulisi sisältää nousevien tai laskeutuvien lentojen osalta myös täydentävät ylitystiedot ja ylitysolosuhteet.

A.9.1.5. Jos täydentävää ylitystietoa käytetään, sen tulee sisältää täydentävä ylityskorkeus lennonjohtovastuun siirtokohdassa. Ylitysolosuhteiden tulee olla:

- Kirjain "A" - jos lento tulee olemaan täydentävissä ylitystiedoissa mainitulla korkeudella tai sen yläpuolella tai

- Kirjain "B" - jos lento tulee olemaan täydentävissä ylitystiedoissa mainitulla korkeudella tai sen alapuolella.

A.9.2. ICAO

Kenttätyyppi 14.

A.9.3. ADEXP

Pääkenttä "coordata".

Pääkentän "coordata" sisällä olevan alikentän "ptid" tulee sisältää joko:

- tunnettu kiintopiste tai

- suunta ja etäisyys tietystä kiintopisteestä, sellaisena kuin se on määriteltynä samassa sanomassa ensisijaisessa kentässä "REF" tai "GEO".

A.10. Koordinointipiste

A.10.1. Yleistä

A.10.1.1. Koordinointipiste, johon siirtävä ja vastaanottava ATC-yksikkö viittaavat kyseessä olevan siirron yhteydessä.

A.10.1.2. Koordinointipiste tulee määritellä niin, että se on tunnettu kiintopiste, tietty etäisyys ja suunta tunnetusta kiintopisteestä, tai leveys- ja pituusaste.

A.10.2. ICAO

Kenttä 14, tieto (a).

A.10.3. ADEXP

Pääkenttä "cop", joka sisältää:

- tunnetun kiintopisteen tai

- suunnan ja etäisyyden tietystä kiintopisteestä, sellaisena kuin se on määriteltynä samassa sanomassa ensisijaisessa kentässä "REF" tai "GEO".

A.11. Määränpäälentoasema

A.11.1. ICAO

Kenttä 16, tieto (a).

A.11.2. ADEXP

Pääkenttä "ades".

A.12. Koneiden lukumäärä ja tyyppi

Koneiden lukumäärän ja tyypin tulee sisältää tieto koneen tyypistä. Koneiden lukumäärä tulee sisällyttää, mikäli kyseessä on muodostelmalento.

A.12.1. ICAO

Kenttätyyppi 9 kentän 22 formaatissa. Kenttätyypin 9 elementin c tulee sisältää joko konetyypin jättöturbulenssikategoria tai kirjain "Z".

A.12.2. ADEXP

Pääkenttä "arctyp". Lisäksi ensisijainen kenttä "nbarc", mikäli lennossa on enemmän kuin yksi kone.

A.13. Reitti

Molemmat formaatit tukevat ICAO-tyyppistä reittikuvausta, jossa ensimmäisenä tietona on nopeus ja pyydetty lentokorkeus tai korkeustieto. Tämän ensimmäisen nopeus- ja korkeusosan jälkeen reittitiedossa tulee olla vähintään seuraavassa kappaleessa mainitut tiedot. Lisäreittitiedot voidaan sisällyttää kohdan c) jälkeen, mikäli niitä on käytettävissä. Katso myös liite B "erityisreittikäsittelyn vaatimukset" reittitiedon syöttösäännöistä.

A.13.1. Sisältö

A.13.1.1. Tietyn COP:n kautta jatkavat lennot

- reittitiedot ennen COP:tä (ATS-reitti, SID-tunnus, DCT tai tunnettu piste),

- COP,

- reittitieto COP:n jälkeen (ATS-reitti tai tunnettu piste).

A.13.1.2. ATS-reitin ulkopuolelle jatkavat lennot

- piste josta lento jatkaa suoran reitin segmentillä,

- tieto "DCT",

- piste, johon lento jatkaa suoran reitin segmentillä.

A.13.2. Formaatti

A.13.2.1. ICAO

Kenttätyyppi 15, kenttätyypin 22 formaatissa.

A.13.2.2. ADEXP

Pääkenttä "route".

A.14. Muu lentosuunnitelmatieto

A.14.1. ICAO

Kenttätyypit 8, 10 ja 18, kenttätyypin 22 formaatissa.

A.14.2. ADEXP

Pääkentät: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts" ja "typz".

A.15. Koordinointitila ja syy

Koordinointitilan ja syyn tulee sisältää seuraavat tiedot:

- jokin seuraavista järjestelmälentosuunnitelman uuden tilan vahvistavista kolmikirjaimisista ilmaisimista:

- INI, kun järjestelmälentosuunnitelman tulee olla alustavassa tilassa, eli tiedoksiantoa ei ole saatu,

- NTF, kun järjestelmälentosuunnitelman tulee olla tiedoksiannetussa tilassa,

- CRD, kun järjestelmälentosuunnitelman tulee olla koordinoidussa tilassa, eli perus-ACT on vastaanotettu tai alustava koordinointidialogi päättynyt sovituin olosuhtein.

- jokin seuraavista tilan syyn määrittelevistä kolmikirjaimisista ilmaisimista:

- TFL, jos syy on muutos siirtokorkeudessa,

- RTE, jos syy on reittimuutos,

- HLD, ilmaisee, että lento joutuu odotuskuvioon määrittelemättömäksi ajaksi ja että sille annetaan uusi sanoma,

- DLY, ilmaisee, että lähtö on viivästynyt,

- CAN, jos syy on peruminen,

- CSN, kutsutunnuksen muutos,

- OTH, muu syy tai tuntematon syy.

A.15.1. ICAO

A.15.1.1. Koordinointitilan ja syyn tulee olla kenttätyypin 18 formaatissa.

A.15.1.2. Koordinointitilan ja syyn tulee sisältää seuraavat tiedot kymmenkirjaimisena ryhmänä:

- STA, jonka jälkeen kauttaviiva,

- tiedoksiannon tai koordinoinnin uuden tilan ilmaisin,

- syyn ilmaisin.

A.15.2. ADEXP

Pääkenttä "cstat".

Apukohdat "coordstatusident" ja "coordstatusreason", joiden tulee sisältää uusi tila ja syy edellä olevien ohjeiden mukaisesti.

A.16. Ilmoitettu kurssi (vain ADEXP)

Pääkenttä "ahead", jonka tulee sisältää joko:

- lennolle ilmoitettu kurssi asteina,

tai

- mikäli kurssia ei ole ilmoitettu, ilmaisin "ZZZ", esimerkiksi jos SDM-sanomalla ilmoitetaan, että aiemmin ilmoitettu kurssi ei enää päde.

A.17. Ilmoitettu nopeus (vain ADEXP)

Pääkenttä "aspeed", jonka tulee sisältää joko:

- lennolle ilmoitettu nopeus joko solmuina, mach-arvona tai kilometreinä tunnissa

tai

- jos nopeutta ei ole ilmoitettu, ilmaisin "ZZZ", esimerkiksi jos SDM-sanomalla ilmoitetaan, että aiemmin ilmoitettu nopeus ei enää päde.

A.18. Ilmoitettu nousu- tai laskeutumisnopeus (vain ADEXP)

Pääkenttä "rate", jonka tulee sisältää:

- lennolle ilmoitettu nousu- tai laskeutumisnopeus satoina jalkoina minuutissa

tai

- jos nousu- tai laskeutumisnopeutta ei ole ilmoitettu, ilmaisin "ZZZ" kentän numero-osassa, esimerkiksi jos SDM-sanomalla ilmoitetaan, että aiemmin ilmoitettu nousu- tai laskeutumisnopeus ei enää päde.

A.19. Sallittu suora reitti (vain ADEXP)

ATS-reitin ulkopuolinen kahden pisteen välinen suora reitti. Pisteet voidaan määritellä joko tunnettuna kiintopisteenä tai etäisyytenä ja suuntana kiintopisteestä. Kaikista käytetyistä alku- ja päätepisteiden tunnuksista tulee sopia kahdenvälisesti eli niiden tulee olla molempien järjestelmien tiedossa.

Pääkenttä "DCT", joka sisältää seuraavat tiedot:

- piste, jossa poikkeaminen alkaa tai on alkanut, määriteltynä jonain seuraavista:

- tunnettu kiintopiste,

tai

- etäisyys ja suunta tunnetusta kiintopisteestä, saman sanoman ensisijaisessa kentässä "REF" määriteltyinä,

tai

- arvo "ZZZ", jos lähettävän yksikön ei tarvitse määrittää poikkeamispistettä.

- piste alkuperäisellä lentosuunnitelman reitillä, jolle kone on selvitetty tai tullaan selvittämään määriteltynä jompanakumpana seuraavista:

- tunnettu kiintopiste,

tai

- etäisyys ja suunta tunnetusta kiintopisteestä, saman sanoman ensisijaisessa kentässä "REF" määriteltyinä.

A.20. Suoran reitin pyyntö

Pyyntö suorasta, ATS-reitin ulkopuolisesta reitistä kahden pisteen välillä. Pisteet voidaan määritellä joko tunnettuna kiintopisteenä tai etäisyytenä ja suuntana kiintopisteestä.

Kaikista käytetyistä alku- ja päätepisteiden tunnuksista tulee sopia kahdenvälisesti eli niiden tulee olla molempien järjestelmien tiedossa.

A.20.1. ICAO

Kenttätyyppi 15, pois lukien alustava nopeus- ja korkeusosa, kentän 22 formaatissa.

Sen tulee sisältää seuraavat tiedot:

- piste, jossa pyydetty poikkeama halutaan alkaa, määriteltynä jonain seuraavista:

- tunnettu kiintopiste,

tai

- etäisyys ja suunta tunnetusta kiintopisteestä,

tai

- arvo "ZZZ", jos suoraa reittiä pyytää vastaanottava ATC-yksikkö.

- lyhenne "DCT",

- jota seuraa piste alkuperäisellä lentosuunnitelmareitillä, jolle koneelle pyydetään selvitystä, määriteltynä joko:

- tunnettuna kiintopisteenä,

tai

- etäisyytenä ja suuntana tunnetusta kiintopisteestä.

A.20.2. ADEXP

Pääkenttä "DCT", joka sisältää:

- pisteen, jossa pyydetty poikkeama halutaan alkaa, määriteltynä joko:

- tunnettuna kiintopisteenä,

tai

- etäisyytenä ja suuntana tunnetusta kiintopisteestä, samassa sanomassa ensisijaisessa kentässä "REF" määriteltynä,

tai

- arvona "ZZZ" jos suoraa reittiä pyytää vastaanottava ATC-yksikkö, mutta tarkka alkukohta ei ole tiedossa.

- pisteen alkuperäisellä lentosuunnitelmareitillä, jolle koneelle pyydetään selvitystä, määriteltynä jompanakumpana seuraavista:

- tunnettu kiintopiste,

tai

- etäisyys ja suunta tunnetusta kiintopisteestä, saman sanoman ensisijaisessa kentässä "REF" määriteltyinä.

A.21. Sijainti (vain ADEXP)

A.21.1. Yleistä

A.21.1.1. Lennon senhetkinen sijainti ilmoitettuna joko maantieteellisinä koordinaatteina tai suuntana ja etäisyytenä määrätystä pisteestä.

A.21.1.2. Pääkenttä "ref" tai "geo" määrittää koneen senhetkisen horisontaalisen sijainnin. Pääkentässä "ref" käytettyjen etäisyyden ja suunnan määrittelypisteiden tulee olla kahdenvälisesti sovittuja eli molempien järjestelmien tiedossa. Pääkentän "position" tulee sisältää alikenttä "ptid", joka viittaa määrättyyn kiinto- tai maantieteelliseen pisteeseen. Jos mukaan otetaan aikatietoa, tulee käyttää kahdenvälisen sopimuksen mukaan joko alikenttää "to" (hhmm) tai "sto" (hhmmss).

A.22. Osoitus vapautuksesta (vain ADEXP)

Pääkenttä "release", jonka tulee sisältää jokin seuraavista:

- C, jos lento on vapautettu nousun suhteen,

- D, jos lento on vapautettu laskeutumisen suhteen,

- T, jos lento on vapautettu käännöksien suhteen,

- F, jos lento on vapautettu kaikkien siirtymisten suhteen.

A.23. Taajuus

A.23.1. ICAO

Kenttätyyppi 18, jonka tulee sisältää seuraavat tiedot kentän 22 formaatissa:

- FRQ, jonka jälkeen kauttaviiva,

- 6 numeroa, jotka ilmaisevat taajuutta megahertseinä kolmen desimaalin tarkkuudella.

A.23.2. ADEXP

Pääkenttä "freq".

A.24. Syy (vain ADEXP)

Pääkenttä "reason", joka sisältää arvon "MANUAL" manuaalisesti ratkaistavaksi lähetetyissä viesteissä.

A.25. Sallittu lentokorkeus (vain ADEXP)

Pääkenttä "cfl".

A.26. Ehdotettu siirtolentokorkeus (vain ADEXP)

Pääkenttä "propfl".

A.27. Arvioitu nousuaika

A.27.1. ICAO

Kenttätyyppi 13 tieto (b).

A.27.2. ADEXP

Pääkenttä "etot".

A.28. Sanomaviitteen tyyppi

Kenttä sisältää sanomatyypin, kuten tämän liitteen kappaleessa A.1 on mainittu.

A.28.1. ICAO

Kenttätyyppi 18 kenttätyypin 22 formaatissa. Elementin osoittimena on "MSG".

A.28.2. ADEXP

Pääkenttä "msgtyp".

LIITE B (Normatiivinen)

ERITYISREITTIKÄSITTELYN VAATIMUKSET

B.1. Johdanto

B.1.1. Yleistä

B.1.1.1. Tässä liitteessä kuvataan seuraavien tapausten säännöt ja tiedonsyöttövaatimukset, silloin kun sallittua:

- lento ohjaa suoralla, reitin ulkopuolisella kurssilla rajan yli lentosuunnitelmaan kirjatun suoran reittisegmentin mukaan,

- ABI- tai ACT-sanoman lähetyksen jälkeen lento reititetään uudelleen joko:

- eri ATS-reitin kautta,

- suoralle kurssille, joka yhtyy alkuperäiseen reittiin myöhemmässä pisteessä.

B.1.1.2. Lentojen uudelleen reitityksen osalta (kohta B.1.1.1) tässä liitteessä kuvattu tiedonvaihto tukee molempien järjestelmien sisältämien lentoreittien muutoksia tiedoksianto- ja koordinointisanomien avulla.

B.2. Sanomien soveltaminen

B.2.1. Suorien reittien perussäännöt

B.2.1.1. OLDI:n käytön olosuhteista suorilla reiteillä olevien lentojen koordinointiin on sovittava kahdenvälisesti.

B.2.1.2. Suorilla reiteillä olevien lentojen tiedoksiannossa ja koordinoinnissa tarvittavat tiedot on sisällytetty koordinointipisteeseen (arviotieto (ICAO-formaatti) ja koordinointitieto (ADEXP-formaatti)) ja reitti käytettäviin viesteihin.

B.2.2. Suoran reitin kirjaaminen

Jos reitistä käy ilmi, että lento tulee ylittämään rajan suoralla kurssilla, tulee suoran reitin segmentti ja siitä seuraava COP sisällyttää ABI-sanomaan/sanomiin. Tämä COP sisältyy myöhempään ACT- tai RAP-sanomaan.

COP:n ja reittitiedon tulee rakentua kohdassa B.3.2 kuvatun mukaisesti.

B.2.3. Uudelleen reititykset ABI:n jälkeen ja ennen ACT:n lähetystä

Tässä tapauksessa tulee lähettää uusi ABI-sanoma, jonka tiedot vastaavat uutta reittiä.

B.2.4. Uudelleenreititys ACT-lähetyksen jälkeen

B.2.4.1. REV-sanomaa tulee käyttää osoittamaan uudelleenreitityksiä sen jälkeen, kun ACT-sanoma on lähetetty kahdenvälisesti sovittuun aikaan ennen aikaisemmin koordinoidun COP:n ylitysaikaa.HUOM.

REV-sanomaa käytetään vain, jos hyväksyvä yksikkö ei ole vaihtunut muutoksen seurauksena. Jos se on vaihtunut, tulee alkuperäiselle hyväksyvälle yksikölle lähettää MAC-sanoma tai koordinointi perua suullisesti.

B.2.4.2. Sanoman tulee sisältää seuraavat tiedot:

- Koordinointipiste (aikaisempi COP, viitetarkoituksessa),

- Arviotieto,

- Reitti.

B.2.4.3. ICAO-formaatin mukaisen sanoman tulee sisältää seuraavat kentät:

3 Sanomatyyppi ja numero; sanomaviite, mikäli sovittu kahdenvälisesti,

7 Lentokoneen tunnistetiedot. Elementtejä b ja c ei tule sisällyttää, ellei samanaikaisesti koordinoida korjausta SSR-koodiin,

13 Lähtölentoasema,

14 Vain tieto a, joka sisältää aikaisemman COP:n viitetarkoituksessa,

16 Määränpää,

22 Kenttä 14, joka sisältää uusien rajanylitysolosuhteiden arviotiedon kentän 22 formaatissa,

22 Kenttä 15, joka sisältää uuden reitin kentän 22 formaatissa.

B.2.4.4. ADEXP-formaatin mukaisten sanomien tulee sisältää sanomatyyppi ja -numero, lentokoneen tunnistetiedot, lähtölentoasema, määränpää ja, mikäli niin on kahdenvälisesti sovittu, sanoman viitenumero, sekä lisäksi:

- aikaisempi COP COP-kentässä,

- uudet koordinointiolosuhteet COORDATA-kentässä,

- uusi reitti ROUTE-kentässä.

B.2.4.5. Reittikorjaukset, jotka lähetetään osana dialogimenettelyä, tulee lähettää RRV-viesteinä, ellei niitä ole kahdenvälisesti sovittu "standardeiksi".

B.3. Kenttäsisällöt

B.3.1. ATS-reitit

Vaihtoehtoisen ATS-reitin kautta uudelleenreititettyjen lentojen arvio- ja reittikentät ovat rakenteeltaan samanlaisia kuin ABI- ja ACT-sanomien.

B.3.2. Suorat reitit

B.3.2.1. Arviotiedon koordinointipisteen tulee olla rajanylityskohta ilmaistuna suuntana ja etäisyytenä raportointipisteestä. Kyseisistä pisteistä tulee sopia kahdenvälisesti. Silloin, jos etäisyys on nolla tai lento sivuaa pistettä kahdenvälisesti sovitun etäisyyden sisällä, tulee käyttää ainoastaan pisteen tunnistetta.

B.3.2.2. Jos asiasta on sovittu kahdenvälisesti, voidaan suoralla reitillä olevan lennon koordinointipiste ilmaista leveys- ja pituusasteena.

B.3.2.3. Reitin tulee sisältää:

- alkuperäisen reitin piste, josta kone aloittaa suoran reitin; silloin kun lento aloittaa suoran reitin "senhetkisestä sijainnista", voidaan piste ilmaista suuntana ja etäisyytenä raportointipisteestä. Jos asiasta on sovittu kahdenvälisesti, piste voidaan ilmaista leveys- ja pituusasteena,

- lyhenne "DCT",

- piste, johon koneen tulee jatkaa suoraan,

- loput jatkolentoreitistä (FRF), mikäli se on lähettävän järjestelmän tiedossa.

B.4. Esimerkkejä

B.4.1. Suorat reitit

B.4.1.1. ABI- ja ACT-sanomat

B.4.1.1.1. Lento (tunnuksella Jetset 253) aikoo ylittää rajan suoralla reitillä pisteestä A (PTA) pisteeseen C (PTC), minkä jälkeen se noudattaa ATS-reittiä UA134. Järjestelmä määrittää COP:n suunnassa 350 ja etäisyydellä 22 NM pisteestä B (PTB).

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

Lähetetään seuraava ABI-sanoma:

- ICAO

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

- ADEXP

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

B.4.1.1.2. ACT-sanoma on samankaltainen kuin ABI-sanoma lukuun ottamatta sitä, että lentoreitti on valinnainen.

B.4.1.2. REV-sanoma

Lennolle HZT2051 lähetettiin aiemmin seuraava ACT-sanoma (tai vastaava ADEXP):

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

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

Seuraavaksi lento reititetään 40 NM pisteen RQA länsipuolelta suoraan pisteeseen MYY. Rajanylitystä lähin piste on TDS, josta todelliseen rajanylityskohtaan on 26 NM suunnassa 240 astetta. Lähetetään seuraava korjaussanoma:

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

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

Sanoman ADEXP-vastine on:

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

Seuraavassa korjaussanomassa COP olisi TDS240026.

B.4.2. Uudelleenreititys ATS-reittien kautta ACT-lähetyksen jälkeen

B.4.2.1. ACT-sanoma

Lennon GKP217 on tarkoitus kulkea koordinointipisteen EMT kautta. Lähetetään seuraava ACT:

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

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

Seuraavaksi lento siirtyy reitille ATS UM247 lähettävän keskuksen ilmatilassa uuteen koordinointipisteeseen XAT asti, minkä jälkeen se aikoo seurata ATS-reittiä UJ124. Hyväksyvä keskus säilyy samana. Lähetetään seuraava korjaussanoma:

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

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

Seuraavaksi lento saa luvan siirtyä korkeudelle FL290, josta seuraa sanoma (joka sisältää uuden COP:n):

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

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

B.4.2.2. ADEXP-vastineet

Kahden korjaussanoman ADEXP-vastineet ovat:

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

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

LIITE C (Informatiivinen)

DIALOGIMENETTELYN VAIHEET (SYSCO LEVEL 1) - SANOMAJÄRJESTYS

Sanomajärjestys

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

LIITE II

ILMALIIKENNEPALVELUIDEN TIEDONSIIRTO (AIR TRAFFIC SERVICES DATA EXCHANGE PRESENTATION, ADEXP), VERSIO 2.0

(Eurocontrolin asiakirjaviite DPS.ET1.ST09-STD)

SISÄLLYSLUETTELO

>TAULUKON PAIKKA>

TEKIJÄNOIKEUSTIEDOT

Tämän asiakirjan on laatinut Euroopan lennonvarmistusjärjestö (Eurocontrol).

Eurocontrol omistaa asiakirjan tekijänoikeudet.

Asiakirjan sisältö kokonaisuudessaan tai osin on siten vapaasti jäsenvaltioiden edustajien käytettävissä, mutta asiakirjan kopiointi tai toimittaminen ulkopuolisille edellyttää Eurocontrolin antamaa kirjallista lupaa.

ESIPUHE

1. Vastuunalainen elin

Tämän standardin on laatinut ja sitä ylläpitää Euroopan lennonvarmistusjärjestön (Eurocontrol) lentoliikenteen säätelykeskuksen (Central Flow Management Unit, CFMU) käyttäjävaatimusosasto.

2. EATCHIP-työohjelma

Tämä standardi kuuluu EATCHIP-työohjelman (EWPD) tietojenkäsittelyjärjestelmän (DPS) toimeenpanotehtävän 09 alaisuuteen.

3. Standardin hyväksyntä

3.1. Tämä standardi on hyväksytty niiden menettelyjen mukaan, jotka on esitetty Eurocontrol-standardointiohjeessa, viite 000-2-93, painos 1.0.

3.2. Tämän standardin säännökset tulivat voimaan, kun Eurocontrolin pysyvä toimikunta hyväksyi painoksen 1.0 vuonna 1995. Säännöksiä on sovellettu 1.12.1997 alkaen.

4. Tekniset korjaukset ja muutokset

Tätä standardia tarkkaillaan, jotta saadaan selville tarvittavat muutokset tai tekniset korjaukset. Standardin ylläpitomenettelystä säädetään Eurocontrol-standardien yhtenäisestä laadinnasta ja esitystavasta annettujen ohjeiden liitteessä H.

Muutoksia tai lisäyksiä, jotka vaikuttavat ADEXP-formaatin perusperiaatteisiin tai kielioppiin, saa tehdä vain muodollisen tarkastusmenettelyn jälkeen Eurocontrol-standardien yhtenäisestä laadinnasta ja esitystavasta annettujen ohjeiden mukaisesti.

Ehdotukset tätä standardia koskevista muutoksista tai lisäyksistä osoitetaan kirjallisesti Eurocontrolin CFMU:n käyttäjävaatimusosastolle (ADEXP).

5. Toimituskäytännöt

5.1. Tämän standardin muoto on Eurocontrol-standardien yhtenäisestä laadinnasta ja esitystavasta annetun ohjeen mukainen eräin poikkeuksin. Vähäisten muotoilupoikkeusten tarkoituksena on välttää sekaannuksia ATS-tietojen vaihtoesityksen (ADEXP) merkitsemistapojen kanssa.

5.2. Kussakin selostuksessa noudatetaan seuraavaa käytäntöä:

- normatiivisissa osissa käytetään verbiä "tulee", ja ne on ladottu normaalitekstinä

- suositeltavissa osissa käytetään verbiä "tulisi", ja ne on ladottu kursiivilla sekä merkitty otsakkeella "Suositus".

6. Yhteys muihin standardeihin

Tämä standardi liittyy seuraavaan standardiin:

Eurocontrol-standardi, On-line-tiedonsiirto (OLDI)

7. Tämän standardin liitteiden asema

>TAULUKON PAIKKA>

8. Kieli

Asiakirjan alkukieli on englanti.

1. LAAJUUS

1.1. ADEXP on formaatti, ei protokolla. Käytettäville siirtovälineille tai -protokollille ei aseteta muita rajoituksia kuin merkistö.

1.2. ADEXP-formaattia käytetään pääasiassa suorassa tietokoneiden välisessä sanomien vaihdossa.

1.3. Tässä standardissa määritellään ADEXP-formaatin periaatteet ja muodostussäännöt. Määritelmä koostuu ADEXP-kenttien kattavasta kuvauksesta.

1.4. ADEXP-formaatti on määritelty käytettäväksi seuraavilla sanomien vaihdon alueilla (asiakirjojen viitetiedot 2 jakson sivulla 3):

- Lentosuunnittelu: lentosuunnitelmatietojen ja niihin liittyvien sanomien vaihto integroidun alustavien lentosuunnitelmien käsittelyjärjestelmän (Integrated Initial Flight Plan Processing System, IFPS), lentoliikennepalveluyksiköiden (Air Traffic Services, ATS) ja lentoliikenteen harjoittajien (Aircraft Operators, AO) välillä. (Asiakirjaviite 3)

- Lentoliikennevirtojen säätely (Air Traffic Flow Management, ATFM): sanomien vaihto CFMU:n taktisen järjestelmän (Tactical System, TACT), lentoliikenteen harjoittajien ja ATS:n välillä. (Asiakirjaviite 5)

- Lennonjohdon koordinointi: taktinen koordinointisanomien vaihto lennonjohtoyksiköiden (Air Traffic Control Unit, ATCU) välillä. (Asiakirjaviite 6)

- Ilmatilan hallinta: ilmatilan saatavuutta koskevien tietojen vaihto kansallisten ATS-yksiköiden, CFMU:n ja lentoliikenteen harjoittajien välillä. (Asiakirjaviite 7)

- Siviili- ja sotilaspuolen koordinaatio: siviili-/sotilaslentotietoja koskevat sanomat ja ilmatilan ylityssanomat. (Asiakirjaviite 7)

1.5. Yksityiskohtaiset eritelmät kunkin edellä mainitun ryhmän sanomien käytöstä ja sisällöstä esitetään mainituissa viiteasiakirjoissa.

2. VIITTEET

2.1. Seuraavien asiakirjojen ja standardien ne kohdat, joihin viitataan tässä asiakirjassa, ovat osa tätä Eurocontrol-standardia.

Viiteasiakirjoista ja -standardeista on ilmoitettu tämän Eurocontrol-standardin julkaisuhetkellä voimassa olleet painokset.

Viitteenä oleviin kansainvälisen siviili-ilmailujärjestön (ICAO) asiakirjoihin tehdyt muutokset tulee välittömästi ottaa huomioon tässä Eurocontrol-standardissa.

Muiden viitteenä olevien asiakirjojen muutokset tulevat osaksi tätä Eurocontrol-standardia vasta kun ne on virallisesti arvioitu ja sisällytetty tähän Eurocontrol-standardiin.

Mikäli kyseiset muut viitteenä olevat asiakirjat ovat ristiriidassa tämän Eurocontrol-standardin kanssa, noudatetaan tätä Eurocontrol-standardia.

2.2. Tämän standardin julkaisuhetkellä viitataan seuraaviin asiakirjoihin. Käyttäjiä kehotetaan kuitenkin tarkistamaan käyttömääräykset ja sanomakenttien rakennetaulukot asiakirjojen uusimmista painoksista.

1. ICAO Chicago Convention Annex 10 Volume I, marraskuussa 1985 päivätty painos

2. ICAO Chicago Convention Annex 10 Volume II, heinäkuussa 1995 päivätty painos

3. IFPS and RPL Dictionary of Messages, painos 1.0, maaliskuu 1998

4. "Rules of the Air and Air Traffic Services", PANS-RAC Doc 4444, painos päivätty marraskuussa 1985 (mukaan luettuna Amendment No 6 marraskuussa 1995);

5. Guide To ATFM Message Exchange Eurocontrol Document Viite TACT/USD/MSGGUID, painos 6.0, voimassa maaliskuusta 1998 lähtien,

6. Eurocontrol standard for On-Line Data Interchange, painos 2.0, lokakuu 1996.

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

3. MÄÄRITELMÄT, TUNNUKSET JA LYHENTEET

3.1. Merkitsemistapa

Muodostussääntöjen määrittelyyn käytettävä merkitsemistapa on nimeltään Backus Naur Form (BNF). BNF määrittelee sääntöjoukon, joka määrää merkkijonon luokan. Tässä tapauksessa merkkijonojen luokka kattaa joukon sanomia, joita voidaan kutsua muodostussääntöjen mukaan päteviksi ADEXP-sanomiksi.

3.2. Määritelmät

Tässä Eurocontrol-standardissa käytetään seuraavia määritelmiä:

Sanoma-alkio (token): Merkki tai merkkijono joka voidaan erottaa kokonaisuudesta leksikaalisella analysaattorilla erotinmerkkien ansiosta.

Tunnus: Mikä tahansa BNF-säännössä esiintyvä "termi", joka ei ole merkki.

Päätetunnus (terminaali): Tunnus, joka esitetään merkkijonona.

Välitunnus (nonterminaali): Tunnus, jota edustaa vähintään yksi päätetunnus.

HUOM.

Välitunnus voidaan esittää myös pääte- ja välitunnusten yhdistelmänä.

3.3. Rakenne

3.3.1. BNF koostuu joukosta seuraavan muotoisia sääntöjä tai rakenteita:

tunnus ::= lauseke

HUOMAUTUKSET

1) Merkintä "::=" luetaan "voidaan korvata seuraavalla:".

2) "Tunnus" luokitellaan välitunnukseksi.

3) Osa "lauseke" sisältää pääte- ja välitunnuksia.

3.3.2. Päätetunnukset esitetään suoraan merkkijonona, joka voidaan tunnistaa sanoma-alkioksi leksikaalisella analysaattorilla erottimien ansiosta.

3.4. Merkintätavat

Tässä Eurocontrol-standardissa käytetään seuraavia merkintätapoja:

- Päätetunnukset on kirjoitettu isoilla kirjaimilla. HUOM.

Merkintätavan mukaan päätetunnus NIL tarkoittaa "ei päätetunnusta".

Sitä käytetään vaihtoehdoissa seuraavan esimerkin tapaan:

a ::= b ( c | NIL ) jossa "a" voidaan korvata (b:llä jota seuraa c) tai pelkästään b:llä.

- Välitunnukset (esim. kieliopin säännön vasen puoli) kirjoitetaan pienellä.

- Merkit ja jonoliteraalit, jotka esiintyvät sääntöjen sisällä, on vastaavasti ympäröity yksin- (') tai kaksinkertaisilla ('') lainausmerkeillä.

ESIMERKKEJÄ

1) HYPHEN ::= '-'

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

Joissain tietojen mallintamissovelluksissa saattaa olla tarpeen erottaa pääte- ja välitunnukset toisistaan jollain muulla tavalla kuin käyttämällä isoja ja pieniä kirjaimia.

Aina kun on tarpeen erottaa pääte- ja välitunnukset selvästi toisistaan muuten kuin käyttämällä isoja ja pieniä kirjaimilla, suositellaan päätteen lisäämistä seuraavasti: aputermille "_at", ensisijaiselle kentälle "_pf" ja alikentälle "_sf".

3.5. Operaattorit

Tässä Eurocontrol-standardissa käytetään seuraavia operaattoreita:

Valinnainen: Tietty tunnus voi laillisesti esiintyä tai olla esiintymättä tietyssä kohdassa kielioppia. Valinnaiset tunnukset ympäröidään hakasulkein "[" ja "]".

Sulkeuma: Ryhmä tunnuksia voi esiintyä tai olla esiintymättä. Tunnukset on ympäröity aaltosulkein "{" ja "}". Jos "{"-sulun edellä on annettu numero, se ilmoittaa, kuinka monta kertaa tunnusten ryhmän täytyy vähintään esiintyä. Jos "}"-sulun jälkeen on annettu numero, se ilmoittaa, kuinka monta kertaa tunnusten ryhmä saa korkeintaan esiintyä.

Vaihtoehto: Tietyssä kohdassa kielioppia voi esiintyä vaihtoehtoisesti useita eri tunnuksia. Vaihtoehtoa osoitetaan merkillä "|".

Ketjutus: Tunnusten on tarkoitus seurata toisiaan, vaikka niiden välille voidaankin asettaa erottimia. Ketjutukseen ei tarvita välttämättä operaattoria. Tyyppejä on kaksi:

- Tiukka ketjutus: Leksikaalisella tasolla säännöt saattavat edellyttää päätetunnusten ketjutusta niin, että ne seuraavat toisiaan tiukasti (ei erotinta välissä); tällaisessa tapauksessa tulee käyttää operaattoria "!".Esimerkki

datetime :: = date ! timehhmm

esim. "9912251200" tarkoittaa 25.12.1999 kello 12.00.

- Löyhä ketjutus: Erottimet päätetunnusten välissä sallittuja. Löyhän ketjutuksen esitys säännössä voi olla joko implisiittinen tai eksplisiittinen.Esimerkkejä

1) Implisiittinen:

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

2) Eksplisiittinen

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

>TAULUKON PAIKKA>

HUOM.

1) Ketjutus on aina etusijalla vaihtoehtoon nähden. Sulkeita "(" ja ")" käytetään muuttamaan lausekkeen laskujärjestystä.Esimerkki

>TAULUKON PAIKKA>

2) Kaikissa säännöissä mahdollisuus käyttää erottimia ilmaistaan luettavuussyistä implisiittisesti.

Suositus:

Jos yllä mainittujen operaattoreiden arvojärjestyksen vuoksi on olemassa sekaannuksen vaara, tulisi käyttää sulkeita ilmoittamaan haluttu laskujärjestys.

3.6. Lyhenteet

>TAULUKON PAIKKA>

4. ADEXP-PERIAATTEET

4.1. Tekstimuotoinen, luettavissa oleva formaatti

4.1.1. ADEXP-formaatti on merkkeihin perustuva tekstiformaatti.

4.1.2. ADEXP-sanomat ovat suoraan luettavissa, jolloin toiminnallinen hienosäätö voidaan toteuttaa paremmin.

4.1.3. Tekstiformaatti on myös selkeämpi ja ymmärrettävämpi.

4.2. Tunnistetut ja esiinsaatavat kentät

4.2.1. ADEXP-formaatin sanoma koostuu kentistä.

4.2.2. Kenttiä rajoittaa erityinen kentän aloitusmerkki, yhdysviiva ("-"), ja ne yksilöidään erityisillä avainsanoilla.HUOM.

On huomattava, että eräät kentät (jotka on syntaktisesti määritetty sisältämään leksikaalisen alkion "CHARACTER") voivat sisältää merkin "-" osana kentän sisältöä.

4.2.3. Tämä lähestymistapa parantaa esitystavan laajennettavuutta ja virhesietoisuutta. (Jos kenttä puuttuu tai on väärä, se voidaan ohittaa ja sanoman loppuosa voidaan silti tulkita.) (Katso osa 4.3)

4.2.4. Toinen seuraus on se, että sanoman kenttien järjestys ei ole oleellinen sen laillisuuden määrittämisessä, lukuun ottamatta ensimmäistä kenttää (pakollinen otsikkokenttä), joka määrää sallitut kentät.

4.2.5. Kentät voivat olla perus- tai yhdistelmäkenttiä.

4.2.6. Yhdistelmäkenttien rakenneosia kutsutaan alikentiksi, ja ne määritetään avainsanojen avulla ja rajataan kentän alkumerkeillä.

4.2.7. Peruskentät ovat kenttiä, jotka eivät sisällä alikenttiä.

4.2.8. Sanoman ensimmäisen määrittelytason muodostavia perus- tai yhdistelmäkenttiä kutsutaan sen ensisijaisiksi kentiksi.

4.2.9. Kaikki alemman tason rakenneosat ovat määrityksen mukaan alikenttiä, jotka puolestaan voivat olla perus- tai yhdistelmäkenttiä.

4.2.10. Yhdistelmäkenttiä on kahta tyyppiä: rakenteellisia kenttiä ja luettelokenttiä.

4.2.11. Rakenteellisilla kentillä on ennalta määrätty sisältö, joka koostuu ainoastaan alikentistä. Rakenteellisen kentän alikenttien järjestyksellä EI ole merkitystä.

4.2.12. Luettelokentät alkavat avainsanalla BEGIN ja päättyvät avainsanaan END. Näiden välissä voi olla sama alikenttä useita kertoja tai alikenttien yhdistelmä. Niiden esiintymisjärjestys luettelokentän sisällä on merkityksellinen.

4.2.13. Seuraavassa termiä "kenttä" käytetään yleisesti tarkoittamaan ensisijaisia ja/tai alikenttiä, ellei toisin erikseen mainita.

4.2.14. Sanoman kentät voivat olla valinnaisia tai pakollisia niiden muodostussäännöistä riippuen.

4.3. Tunnistamattomat kentät

4.3.1. Jos sanomassa on tunnistamaton kenttä, se ohitetaan.

4.3.2. Toisin sanoen jos sanomaa analysoiva järjestelmä ei tunnista avainsanaa, kaikki teksti ohitetaan seuraavaan sellaiseen tunnettuun ensisijaiseen kenttään asti, joka ei ole luettelokentän sisällä.

4.3.3. Sanoman otsikosta riippuen ohitettu kenttä saattaa aiheuttaa tai olla aiheuttamatta jäsennettävän sanoman hylkäämisen.HUOM.

On huomattava, että vaikka ADEXP on suunniteltu tältä osin joustavaksi, on rajapintavaatimuksien määrityksestä vastaavien henkilöiden harkinnan varassa osoittaa kunkin sanoman osalta se, miten järjestelmän tulisi reagoida tunnistamattomaan kenttään.

4.3.4. Jos tunnistamaton kenttä on luettelokenttä (mikä on havaittu avainsanan -BEGIN takia), koko sen sisältö (aina vastaavaan avainsanaan -END asti) ohitetaan.

4.3.5. Jotta vältettäisiin tunnistamattoman kentän ohittamisen jälkeiset tulkintavaikeudet, avainsanan tulee aloittaa joko ensisijainen tai alikenttä.

4.3.6. Tämä sallii kahdentyyppisten avainsanojen määrittämisen:

- ensisijaiset avainsanat

- aliavainsanat.

4.3.7. Kun avainsana on määritelty yhdentyyppiseksi, sitä ei saa enää käyttää uudelleen toisessa sanomaryhmässä toisentyyppisenä lukuun ottamatta yhtä poikkeusta, jolloin se on luettelokentässä. Ensisijainen avainsana voi esiintyä luettelokentän sisällä ilman moniselitteisyyden vaaraa, koska avainsanan BEGIN esiintyminen osoittaa, että sisäistä esiintymää voidaan pitää alikenttänä.Esimerkkejä (avainsanatyyppien käytöstä)

1) Ensisijainen kenttä

-RFL F330

2) Alikenttä: aina "Yhdistelmäkentän" sisällä

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

jossa -GEO on ensisijainen yhdistelmäkenttä ja -GEOID, -LATTD ja -LONGTD ovat kaikki alikenttiä.

3) Luettelokenttä

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

...

-END RTEPTS

jossa "-BEGIN" on luettelokentän osoitin ja "RTEPTS" on ensisijainen kenttä.

HUOM.

"RFL" on määritetty ensisijaiseksi kentäksi. Sisällyttäminen luettelokenttään on ainoa tapaus, jolloin ensisijaista kenttää voidaan käyttää alikenttänä. (Katso esimerkki 3 yllä.)

5. ADEXP-MUODOSTUSSÄÄNNÖT

5.1. Leksikaaliset osat

5.1.1. Merkistö

5.1.1.1. Sanomien vaihtoon ADEXP-formaatissa käytetyn merkistön tulee olla International Alphabet Number 5 (IA-5), kuten viitteessä 1 on määritetty.

5.1.1.2. ADEXP-formaatti on suunniteltu tietokoneiden väliseksi sanomanvaihtoformaatiksi, jota voidaan käyttää eri tietokoneverkoissa tai tähän käyttöön varatuissa tietokoneyhteyksissä. Lisäksi vaatimuksena on, että eräitä, yleensä lentosuunnitelmaan ja ATFM:ään liittyviä ADEXP-sanomia voidaan vaihtaa Aeronautical Fixed Telecommunication Network -verkossa (AFTN).

5.1.1.3. Jos sanomia voidaan joutua lähettämään AFTN:n kautta, niiden merkistö tulee rajoittaa niihin merkkeihin, joilla on suora vastaavuus International Telegraph Alphabet Number 2 (ITA-2) -merkistön ja IA-5-merkistön välillä, kuten viitteessä 1 on määritetty.HUOM.

Alla määriteltyjen graafisten merkkien ja toiminnemerkkien lisäksi ITA-2-merkistö määrittelee "signaalit" (kuten esimerkiksi reikänauha). Ne eivät ole osa ADEXP-sanomien sallittua merkistöä.

5.1.1.4. ADEXP-sanomissa, joita voidaan lähettää AFTN:n kautta, voidaan käyttää seuraavia graafisia merkkejä ja toiminnemerkkejä:

Graafiset merkit

a) isot kirjaimet (A-Z)

b) numerot (0-9)

c) seuraavat graafiset erikoismerkit:

1) välilyönti " "

2) sulku auki "("

3) sulku kiinni ")"

4) yhdysviiva "-"

5) kysymysmerkki "?"

6) kaksoispiste ":"

7) piste "."

8) pilkku ","

9) heittomerkki "'"

10) yhtäläisyysmerkki "="

11) plusmerkki "+"

12) kauttaviiva "/"

Toiminnemerkit

a) Carriage-Return (Vaununpalautus)

b) Line-Feed (Rivinvaihto)

5.1.2. Leksikaaliset peruselementit

Seuraavia leksikaalisia peruselementtejä käytetään tässä spesifikaatiossa:

- 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

HUOMAA

LIM_CHAR tarkoittaa mitä tahansa sallittua merkkiä paitsi yhdysviivaa (HYPHEN), joka on varattu osoittamaan kentän alkua. Sen sijaan CHARACTER tarkoittaa mitä tahansa merkistön sallittua elementtiä.

5.1.3. Rivit, erottimet ja lopettimet

5.1.3.1. Sanoman tekstin jakamisella riveiksi ei ole syntaktista merkitystä.

5.1.3.2. Erotin voi olla välilyönti tai toiminnemerkki.

5.1.3.3. Kenttiä rajataan vain kentän alkumerkillä, jota seuraa avainsana.

5.1.3.4. Tällöin koko sanoma voi olla laillisesti yhdellä rivillä.

5.1.4. Etumerkillä varustetut arvot

5.1.4.1. Numeroarvo voidaan joutua osoittamaan negatiiviseksi.

5.1.4.2. Kenttien, joiden on osoitettava negatiivista arvoa, tulee muodostussääntömääritelmässään yksiselitteisesti osoittaa arvo "etumerkillä varustetuksi", ts. joko positiiviseksi tai negatiiviseksi. Jos kenttää ei ole määritelty näin, se ei voi edustaa negatiivista arvoa.

5.1.4.3. "Etumerkillä varustettua arvoa" edeltää aina joko kirjain "N" (negatiivinen) tai "P" (positiivinen). Nolla-arvoa voi edeltää joko "N" tai "P".

5.1.4.4. "Etumerkillä varustetun arvon" sallivan kentän muodostussääntö on seuraava:

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

Esimerkkejä:

Kenttä nimeltä "NUMBER", jossa voi olla 1-8-merkkinen negatiivinen arvo, määritellään seuraavasti:

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

Tällöin:

-NUMBER P5 - "numeron" arvo on +5

-NUMBER N5 - "numeron" arvo on -5

-NUMBER 5 - epäkelpo muoto, kentässä on oltava joko "P" tai "N"

5.1.5. Avainsanat

5.1.5.1. Avainsana on mikä tahansa isojen kirjaimien tai numeroiden jono. Se aloittaa kentän vain silloin, kun sitä edeltää kentän aloitusmerkki ("-")

keyword ::= 1{ ALPHANUM }

5.1.5.2. Avainsanojen tulee noudattaa seuraavaa muodostussääntöä:

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

Toisin sanoen avainsanan ja kentän aloitusmerkin välissä tulee olla nolla erotinta tai useampi erotin. Sitä seuraa välittömästi yksi tai useampi erotin, joita seuraavat merkitykselliset alikentät tai sisältyvä arvo.

HUOM.

On tärkeää huomata, että avainsanan ja sitä edeltävän kentänaloitusmerkin välissä voi olla kuinka monta erotinta hyvänsä tai ei yhtään.

Esimmerkkejä (Kaikki seuraavat jonot aloittavat kentän oikein)

1) - TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Suositus:

Suosituksena on välttää erottimen käyttöä kentän alkumerkin "-" ja sitä seuraavan avainsanan välissä.

HUOM.

1) Yllä olevissa esimerkeissä ensimmäinen vaihtoehto on suositeltavin.

2) Lisäksi on tärkeää huomata, että välittömästi avainsanan jäljessä tulee olla vähintään yksi erotin.

5.1.5.4. Koko standardissa vähintään yhdellä erottimella erotettujen elementtien ketjutus esitetään implisiittisesti "Löyhän ketjutuksen" merkitsemistavalla (katso 3.5). HUOM.

Kuten myöhemmin selitetään, avainsanat aloittavat myös luettelokenttiä, kun niitä edeltää avainsana BEGIN.

5.1.5.5. Avainsanojen tulee olla mahdollisimman lyhyitä, mutta kuitenkin semanttisesti mielekkäitä.

5.1.5.6.

>TAULUKON PAIKKA>

5.1.5.7. Jotta vältettäisiin moniselitteisyyttä (saman avainsanan käyttöä eri merkityksissä) tai redundanssia (samaa merkitystä eri avainsanoilla), tämän standardin liitteessä A (A3) on ensisijaisten kenttien keskeinen määrittelytaulukko (eli ensisijaiset avainsanat) ja liitteessä A (A4) alikenttien keskeinen määrittelytaulukko (eli aliavainsanat).

5.2. Kentät

5.2.1. Kentän muodostussääntö

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

HUOM.

Kuten jäljempänä käy ilmi, luettelokenttien kohdalla avainsanaa ei edellä suoraan "-" vaan rakenne "-" "BEGIN".

5.2.2. Sanoman rakenne kenttien suhteen

5.2.2.1. ADEXP-sanoman ensimmäinen kenttä on aina TITLE-kenttä (otsikko, eli kenttä, jonka TITLE-avainsana aloittaa).

5.2.2.2. Sanoman muun sisällön ensisijaisten kenttien suhteen määrittää sen TITLE.

5.2.2.3. Tietyn TITLE:n mukaisten sanomien muodostussäännöt määräytyvät sen sisältämien kenttien pohjalta (jotka määräytyvät avainsanojensa mukaan):

- sen ensisijaisten kenttien nimi ja sallittu sisältö

- sen alikenttien nimi ja sallittu sisältö,

5.2.3. Peruskentät

5.2.3.1. Peruskentän muodostussääntö on seuraava:

basic_field ::= '-' keyword contained_values

5.2.3.2. "Sisältyvät_arvot" määrittää tekstin, joka antaa kentän arvon ja joka ei voi aloittaa alikenttää.Esimerkkisääntö

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

1) Vastaava eksplisiittinen sääntö on:

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

2) Esimerkki sanoman osasta: "-ARCTYP ZZZZ".

5.2.3.3. Suositus:

Kun peruskentässä on enemmän kuin kaksi sisältyvää arvoa ja lisäksi halutaan ilmaista näiden arvojen "valintaa" tai "vaihtoehtoisuutta", suositellaan, että kentästä tehdään strukturoitu kenttä ja sisältyvät arvot sijoitetaan alikenttiin.

5.2.4. Luettelokentät

5.2.4.1. Luettelokenttien muodostussääntö on seuraava:

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

5.2.4.2. "Alikentät" voivat olla millainen alikenttien yhdistelmä hyvänsä, ja ne voivat esiintyä nolla kertaa tai useammin luettelokentän sisällä.

5.2.4.3. Tietyssä luettelokentässä olevien alikenttien luettelo muodostaa järjestetyn joukon (alikenttien järjestys on merkitsevä).Esimerkkisääntö

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

1) Tämä esimerkki näyttää, että addr-kenttä on luettelokenttä, jossa alikenttä "fac" (ATS-palvelu) esiintyy nolla kertaa tai useammin.

2) Esimerkkiosuus sanomasta, jossa ADDR on luettelokenttä, joka sisältää FAC-alikenttiä: -BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) Esimerkkiosuus sanomasta, jossa on useita alikenttiä:

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

5.2.5. Strukturoidut kentät

5.2.5.1. Strukturoitujen kenttien muodostussääntö on seuraava:

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

5.2.5.2. Tietyssä strukturoidussa kentässä sallittavien sisältyvien alikenttien tulee riippua vain strukturoidusta kentästä itsestään.

5.2.5.3. Alikenttien esiintymisjärjestys strukturoidussa kentässä ei ole merkitsevä, joten tulevaisuudessa laajentaminen on helppoa (uusia sisältyviä alikenttiä lisäämällä).Esimerkkisääntö

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

1) Tämä määrittelee "pt"-kentän strukturoiduksi kentäksi, joka sisältää pisteen ("ptid"-alikenttä), jota voi seurata laskettu lentopinta ("fl"-alikenttä), jota voi seurata arvioitu pisteen yllä oltava aika ("eto"-alikenttä).

2) Kentän esiintymä voi olla esim. seuraava:

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

5.2.5.4. Suositus:

Aina kun vaikuttaa siltä, että kentän sisältö saattaa kehittyä tulevaisuudessa, siitä kannattaa tehdä strukturoitu kenttä. Tällöin sen alikenttiä voidaan asteittain laajentaa. Toisaalta peruskenttä voi olla yksinkertaisempi tai helppokäyttöisempi, mutta se vaatii määrätyn elementtien (arvojen) järjestyksen, ja sen laajennusmahdollisuudet ovat hyvin rajoitetut.

5.2.6. COMMENT-kenttä

5.2.6.1. Kommenttikenttä aloittaa vapaan tekstin alueen, jossa voidaan käyttää kaikkia merkkejä kentän alkumerkkiä ("-") lukuun ottamatta ja joka ulottuu seuraavaan kenttään asti

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

Esimerkki

-COMMENT TAMA ON VAPAAN REITTITEKSTIALUEEN ALKU

5.2.7. TITLE-kenttä

5.2.7.1. ADEXP-sanoman ensimmäinen kenttä on aina otsikkokenttä. Otsikkokentän muodostussääntö on seuraava:

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

5.2.7.2. Otsikkokentän mahdolliset arvot koostuvat standardin liitteessä B luetellusta ADEXP-sanomaotsikoiden joukosta.Esimerkki

-TITLE IFPL

6. ADEXP-SANOMIEN NORMALISOITU KUVAUS

6.1. Johdanto

6.1.1. Seuraavissa kappaleissa määritetään, miten eri sanomaluokkien ADEXP-formaatti kuvataan normalisoidulla tavalla tässä standardissa.

6.1.2. Normalisoidussa kuvauksessa määritellään:

- aputermit,

- jokaisen yksittäisen ensisijaisen kentän muodostussäännöt ja semantiikka,

- jokaisen yksittäisen alikentän muodostussäännöt ja semantiikka,

- jokainen sanomaryhmä viittaamalla niiden määrittelydokumentaatioon.

6.1.3. Tässä standardissa ei esitetä sanomaotsikkojen kenttien kokoonpanoa eikä tietojen lisäyssääntöjä koskevia yksityiskohtia.

6.1.4. On kuitenkin syytä ottaa huomioon kutakin sanomaryhmää koskeva määrittelydokumentaatio (Liittymän erittely) (katso kohta 6.5.7).

6.1.5. Määrittelydokumentaation tulee antaa normalisoidulla tavalla seuraavat tiedot jokaisesta sanomaotsikosta:

- luettelo pakollisista ensisijaisista kentistä,

- luettelo valinnaisista ensisijaisista kentistä,

- jokaisen kentän tietojen lisäyssäännöt ja erityisesti säännöt, jotka koskevat tässä standardissa valinnaisiksi määritettyjen alikenttien käyttöä,

- säännöt, jotka koskevat tunnistamattoman kentän havaitsemisen jälkeistä normaalitilaan palautumista.

6.1.6. Tällä hetkellä määritellyt kentät, jotka Eurocontrol-jäsenvaltiot ovat hyväksyneet käyttöön ADEXP:n eri sanomaluokissa, luetellaan tämän standardin liitteessä A.

6.1.7. Kenttää ei saa käyttää muuhun kuin sen semanttisessa kuvauksessa määriteltyyn tarkoitukseen.

6.1.8. Varattujen kenttien keskushakemisto on liitteessä D. "Varattuja kenttiä" ei ole hyväksytty käytettäviksi nykyisin määritellyissä ADEXP-sanomissa. Yleensä ne ovat kenttiä, jotka mahdollisesti otetaan käyttöön tulevaisuudessa tai joita käytetään paikallisesti kansallisissa järjestelmissä. Ne on otettu mukaan tähän standardiin, jotta kenttien otsikoiden ainutkertaisuuden varmistaminen ja tarpeettomien päällekkäisyyksien välttäminen olisi helpompaa.

6.2. Aputermit

6.2.1. Jotta kenttien määritelmästä saataisiin luettava, kieliopin kuvauksessa kannattaa usein käyttää aputermejä.

6.2.2. Aputermit eivät aloita kenttää tai apukenttää, eivätkä ne siis liity mihinkään tiettyyn avainsanaan. Ne saattavat kuitenkin esiintyä useamman kuin yhden kentän, apukentän tai aputermin määrityksessä. Esimerkiksi aputermiä "date" voidaan käyttää useiden kenttien määritelmässä.

6.2.3. Kaikki tarvittavat aputermit luetellaan aakkosjärjestyksessä, ja ne on määritelty tämän standardin liitteessä A (A2).

6.2.4.

>TAULUKON PAIKKA>

6.3. Ensisijaisten kenttien määritelmä

6.3.1. ADEXP-sanomien kaikkien ensisijaisten kenttien tulee noudattaa tämän standardin liitteessä A (A3) mainittuja muodostussääntöjä ja semantiikkaa.

6.3.2. Ensin ilmoitetaan jokaisen kentän muotosääntö ja sitten kuvataan sen semantiikka yksinkertaisesti, selkeästi ja yksiselitteisesti.

6.3.3. Kenttien muotosääntö ilmaistaan käyttäen tämän standardin osassa 3 esitettyä BNF-merkintätapaa.

6.3.4.

>TAULUKON PAIKKA>

6.4. Alikenttien määritelmä

6.4.1. ADEXP-sanomien kaikkien alikenttien tulee noudattaa tämän standardin liitteessä A (A4) mainittuja muodostussääntöjä ja semantiikkaa.

6.4.2. Lisäksi ristiviittaustarkoituksia varten mainitaan ne ensisijaiset kentät, joiden sisällä tietty alikenttä esiintyy.

6.4.3. Alikenttä voi olla myös muiden alikenttien alikenttä, joten lisäksi annetaan ristiviittaus näihin alikenttiin.

6.4.4.

>TAULUKON PAIKKA>

6.5. Sanomaryhmä

6.5.1. Sanomien operatiiviset luokat (ryhmät), jotka on määritelty käytettäviksi ADEXP-formaatin kanssa, on esitetty tämän standardin liitteessä E.

6.5.2. Ryhmät on määritelty suhteessa vaihdettavien sanomien operatiiviseen luonteeseen, ja niitä luonnehditaan usein asiaan liittyvien järjestelmien avulla.

6.5.3. Viittaus määrittelevään dokumentaation on tehtävä jokaisessa sanomaryhmässä.

6.5.4. Mitään otsikon arvoa, jota on jo käytetty sanomaryhmälle, ei saa käyttää toiselle ryhmälle eri merkityksessä.

6.5.5. Tämän standardin liitteessä B pidetään yllä sanomaotsikoiden keskushakemistoa.

6.5.6. Viittaus asiaankuuluvaan ryhmään annetaan jokaiselle sanomaotsikoiden keskushakemistossa luetellulle sanomaotsikolle. Täten viittaus jokaisen sanomaotsikon määrittävään dokumentaatioon annetaan sanomaryhmän kautta.

6.5.7. Lisäksi liitteessä C on varattujen sanomaotsikoiden keskushakemisto. "Varattu"-sanomaotsikoita ei ole hyväksytty käytettäviksi nykyisin määritellyissä ADEXP:tä käyttävissä sanomaryhmissä. Yleensä ne ovat sanomia, jotka mahdollisesti otetaan käyttöön tulevaisuudessa jossain määritellyssä ryhmässä tai joita käytetään paikallisesti kansallisissa järjestelmissä. Ne on otettu mukaan tähän standardiin, jotta sanomaotsikoiden ainutlaatuisuuden varmistaminen ja tarpeettomien päällekkäisyyksien välttäminen olisi helpompaa.

LIITE A(Normatiivinen)

ADEXP-KENTTIEN MÄÄRITYKSET

A.1. Johdanto

Tässä liitteessä on luettelo kaikista kentistä, aputermeistä, ensisijaisista kentistä ja alikentistä, jotka on määritelty käytettäväksi ADEXP:ssä.

A.2. ADEXP-aputermit

>TAULUKON PAIKKA>

A.3. ADEXP ensisijaiset kentät

>TAULUKON PAIKKA>

A.4. ADEXP-alikentät

>TAULUKON PAIKKA>

LIITE B(Normatiivinen)

ADEXP-SANOMAOTSIKOIDEN KESKUSHAKEMISTO

>TAULUKON PAIKKA>

LIITE C(Normatiivinen)

VARATTUJEN SANOMAOTSIKOIDEN KESKUSHAKEMISTO

C.1. Johdanto

Tämä liite sisältää keskushakemiston varatuista otsikkosanomista, joita ei vielä ole määritetty käytettäväksi ADEXP:ssä. Niiden sisältyminen tähän hakemistoon osoittaa, että joko niiden tuleva käyttö on odotettavissa tai ne ovat jo käytössä, mutta niiden käyttö on rajoitettu paikallisiin järjestelmiin.

C.2. Tarkoitus

Tämä luettelo otsikoista, joita ei vielä ole muodollisesti hyväksytty käytettäväksi tässä ADEXP-standardissa, on laadittu mahdollisuuksien mukaan ehkäisemään redundanssia, kun tiettyyn tarkoitukseen haetaan uutta otsikkoa, sekä estämään luomasta sellaista otsikkoa, joka jo on käytössä jossain paikallisessa järjestelmässä.

C.3. Varatut sanomaotsikot

>TAULUKON PAIKKA>

LIITE D(Normatiivinen)

VARATTUJEN KENTTIEN KESKUSHAKEMISTO

D.1. Johdanto

Tässä liitteessä on keskushakemisto varatuista kentistä, aputermeistä, ensisijaisista kentistä ja alikentistä, joita ei vielä ole määritelty käytettäväksi ADEXP:ssä. Niiden ottaminen mukaan tähän liitteeseen osoittaa, että niiden uskotaan tulevan käyttöön tai että ne ovat jo käytössä, mutta niiden käyttö on rajoittunut paikallisiin järjestelmiin.

D.2. Tarkoitus

Tämä luettelo kentistä, joita ei vielä ole muodollisesti hyväksytty käytettäväksi tässä ADEXP-standardissa, on laadittu mahdollisuuksien mukaan ehkäisemään redundanssia, kun tiettyyn tarkoitukseen tarvitaan uusi kenttä, sekä estämään luomasta sellaista avainsanaa, joka on jo käytössä jossain paikallisessa järjestelmässä.

D.3. Varatut aputermit

>TAULUKON PAIKKA>

D.4. Varatut ensisijaiset kentät

>TAULUKON PAIKKA>

D.5. Varatut alikentät

>TAULUKON PAIKKA>

LIITE E (Informatiivinen)

SANOMARYHMIEN ESITTELY

JOHDANTO

Tässä liitteessä esitellään eri sanomaryhmät tai -luokat, joita voidaan vaihtaa ADEXP:ssä. Täydellinen luettelo kaikista ADEXP-sanomaotsikoista on liitteessä B.

HUOM.

Tarkkojen ehtojen, käyttösääntöjen, kenttäkäytön ja etenkin valinnaisten kenttien käytön osalta viitataan kyseisten järjestelmien dokumentaatioon (esim. Käyttöliittymän määrittelyasiakirja).

E.1. Lentosuunnitelmasanomat

E.1.1. Johdanto

Tämän kategorian sanomia vaihdetaan ensisijaisesti lentoliikenteen harjoittajan, IFPS:n ja asiaankuuluvien ATS-yksiköiden välillä.

E.1.2. Sanomaotsikoiden määritelmä

Tähän luokkaan kuuluvat sanomaotsikot ovat:

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

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 3.

E.1.3. Ensisijaisten kenttien rakenne

Sanoman sisällön, tietojen lisäyssääntöjen sekä pakollisten ja valinnaisten kenttien käytön yksityiskohtainen määrittely on viiteasiakirjassa 3.

Esimerkki:

Lentosuunnitelmasanoma

-TITLE IFPL

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

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

-FAC LPAMYWYA -FAC LPAMYCYX -FAC LPPTIFPS

-END ADDR

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

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

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

-FLTTYP S

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

-BEGIN RTEPTS

-PT -PTID EGKK -FL F000 -ETO 980305113000

-PT -PTID SAM -FL F196 -ETO 980305114012

-PT -PTID ASPEN -FL F288 -ETO 980305114658

-PT -PTID ORTAC -FL F311 -ETO 980305114959

-PT -PTID GUR -FL F330 -ETO 980305115617

-PT -PTID AKEMI -FL F330 -ETO 980305120118

-PT -PTID LARSI -FL F330 -ETO 980305120626

-PT -PTID QPR -FL F330 -ETO 980305121236

-PT -PTID ERWAN -FL F330 -ETO 980305123152

-PT -PTID LOTEE -FL F330 -ETO 980305124401

-PT -PTID AVS -FL F330 -ETO 980305125357

-PT -PTID KORET -FL F330 -ETO 980305130137

-PT -PTID BARKO -FL F330 -ETO 980305130734

-PT -PTID CANAR -FL F330 -ETO 980305131544

-PT -PTID VIS -FL F330 -ETO 980305132220

-PT -PTID FTM -FL F234 -ETO 980305133230

-PT -PTID LPPT -FL F000 -ETO 980305134529

-END RTEPTS

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

-ATSRT UG41 AVS FTM

E.2. Ilmaliikennevirran hallintasanomat

E.2.1. Johdanto

Tämän kategorian sanomia vaihdetaan ensisijaisesti Eurocontrolin CFMU:n TACT-järjestelmän, lentotoiminnan harjoittajien ja ATS-yksiköiden välillä.

E.2.2. Tietokoneavusteiset tulo- ja lähtöajan osoitussanomat (Computer Assisted Slot Allocation (CASA)

Tähän luokkaan kuuluvat sanomaotsikot ovat:

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

E.2.2.1. Sanomaotsikoiden määritelmä

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 5.

E.2.2.2. Ensisijaisten kenttien rakenne

Sanoman sisällön, tietojen lisäyssääntöjen sekä pakollisten ja valinnaisten kenttien käytön yksityiskohtainen määrittely on viiteasiakirjassa 5.

Esimerkki:

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

-CTOT 010 -REGUL UZZU11 -TAXITIME 0020

E.2.3. Tiedotussanomat

Tähän luokkaan kuuluvat sanomaotsikot ovat:

FSA

E.2.3.1. Sanomaotsikoiden määritelmä

Tämän sanoman määrittelymateriaali tulee viiteasiakirjaan 5.

E.2.3.2. Ensisijaisten kenttien rakenne

Sanoman sisällön, tietojen lisäyssääntöjen sekä pakollisten ja valinnaisten kenttien käytön määrittely on viiteasiakirjassa 5.

Esimerkki:

Ensimmäinen järjestelmän aktivointisanoma

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

E.3. ATC-koordinaatiosanomat

E.3.1. Johdanto

Koordinaatiosanomia käytetään automatisoimaan käytännön koordinaatiota ja tietojen vaihtoa ATC-yksiköiden välillä. Sanomat varmistavat koordinaatioon liittyvien tietojen oikea-aikaisen jakelun standardoitujen tiedon erottelu- ja lähetysominaisuuksien kautta.

E.3.2. Sanomaotsikoiden määritelmä

Tähän luokkaan kuuluvat sanomaotsikot ovat:

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

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 6.

E.3.3. Ensisijaisten kenttien rakenne

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 6.

Esimerkkejä:

Luovutusehdotussanoma

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

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

Aktivointisanoma

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

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

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

E.4. Ilmatilan hallintasanomat

E.4.1. Johdanto

Ilmatilan hallinnan koordinaatiossa käytettävät sanomat. Nämä sanomat kattavat liikenteen tapahtumaympäristön hallinnan: pysyvät ja ehdolliset reitit, tilapäisesti eristetyt alueet, vaaralliset ja kielletyt alueet jne.

E.4.2. Sanomaotsikoiden määritelmä

Tähän luokkaan kuuluvat sanomaotsikot ovat:

AUP, CRAM, UUP.

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 7.

E.4.3. Ensisijaisten kenttien rakenne

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 7.

Esimerkki:

Ehdollinen reitin käytettävyyssanoma

-TITLE CRAM -PART -NUM 001 -LASTNUM 010

-FILTIME 281353 -MESVALPERIOD 199803290600 1998703300600

-BEGIN LACDR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-END LACDR

E.5. Siviili/sotilaskoordinaatiosanomat

E.5.1. Johdanto

Sanomat, joita käytetään lentotietojen koordinoinnissa ja ilmatilan ylityspyynnöissä siviili- ja sotilaslennonjohtoyksiköiden välillä.

E.5.2. Sanomaotsikoiden määritelmä

Tähän luokkaan kuuluvat sanomaotsikot ovat:

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

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 7.

E.5.3. Ensisijaisten kenttien rakenne

Kaikki näiden sanomien määrittelymateriaali on viiteasiakirjassa 7.

Esimerkki:

Ylitysluvan pyyntösanoma

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

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

-BEGIN RTEPTS

-PT -PTID GEO01 -TO 1630 -FL F250

-PT -PTID GEO02 -TO 1631 -FL250

-END RTEPTS

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

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

Hyväksymissanoma

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

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

-SEQNUM 012

LIITE F (Informatiivinen)

ESIMERKKEJÄ ADEXP-SANOMAFORMAATISTA

Seuraavat esimerkit ovat näytteitä ADEXP-formaatista, eivät esimerkkejä sanoman sisällöstä. Käytetty sanoma on IFPL, ja vaikka se on julkaisuhetkellä oikea, kenttien rakenteen yms. oikeellisuutta ei taata.

ESIMERKKI 1 on annettu helposti luettavassa muodossa. Tämä on saatu aikaan käyttämällä rivinvaihtoja, sisennyksiä yms. Tällainen muotoilu ei kuitenkaan ole osa ADEXP-muodostussääntöjä.

Siksi sanoman esitystapa on vastaanottavan järjestelmän harkittavissa. ESIMERKKI 2 ja ESIMERKKI 3 ovat molemmat käypiä esityksiä samasta sanomasta kuin ESIMERKKI 1.

ESIMERKKI 1

-TITLE IFPL

-BEGIN ADDR

-FAC CFMUTACT

-FAC LFFFSTIP

-FAC EDFFZRZL

-FAC EDZZZQZA

-FAC EDUUZQZA

-FAC LOVVZQZX

-FAC LHBPZEZX

-FAC LYBAZQZX

-FAC LWSSZQZX

-FAC LGTSZAZX

-END ADDR

-ADEP EDDF

-ADES LGTS

-ARCID DLH3728

-ARCTYP B73A

-CEQPT SDMRY

-EOBD 980517

-EOBT 0715

-FILTIM 170421

-IFPLID AA05966101

-ORGNID DLHAOCC

-ORIGIN -NETWORKTYPE SITA -FAC FRAOXLH

-REG DABHM

-SEL KMGJ

-SRC FPL

-FLTTYP S

-WKTRC M

-TTLEET 0210

-RFL F330

-SPEED N0417

-FLTRUL I

-SEQPT C

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

SAVIN UG18 BUI UB1 TALAS

-ALTRNT1 LBSF

-EETFIR EDUU 0014

-EETFIR LOVV 0035

-EETFIR LJLA 0054

-EETFIR LHCC 0057

-EETFIR LYBA 0113

-EETFIR LWSS 0148

-EETFIR LGGG 0159

-BEGIN RTEPTS

-PT -PTID EDDF -FL F000 -ETO 980317071500

-PT -PTID NDG -FL F311 -ETO 9803173414

-PT -PTID RIDER -FL F327 -ETO 980317073726

-PT -PTID MAH -FL F330 -ETO 980317074130

-PT -PTID MUN -FL F330 -ETO 980317074449

-PT -PTID CHIEM -FL F330 -ETO 980317074754

-PT -PTID UNKEN -FL F330 -ETO 980317075109

-PT -PTID GRZ -FL F330 -ETO 9803170080830

-PT -PTID DIMLO -FL F330 -ETO 980317081443

-PT -PTID BABIT -FL F330 -ETO 980317083107

-PT -PTID SAVIN -FL F330 -ETO 980317083613

-PT -PTID UPIVO -FL F330 -ETO 980317084054

-PT -PTID KLENA -FL F330 -ETO 980317084204

-PT -PTID VAL -FL F330 -ETO 980317084629

-PT -PTID KAVOR -FL F330 -ETO 980317085329

-PT -PTID BUI -FL F330 -ETO 980317090135

-PT -PTID SARAX -FL F330 -ETO 980317090650

-PT -PTID PEP -FL F312 -ETO 980317091414

-PT -PTID TALAS -FL F241 -ETO 980317091746

-PT -PTID LGTS -FL F000 -ETO 980317093138

-END RTEPTS

-SID NDG3D

-ATSRT UW70 NDG MUN

-ATSRT UB103 MUN UNKEN

-ATSRT UT23 UNKEN BABIT

-ATSRT UR26 BABIT SAVIN

-ATSRT UG18 SAVIN BUI

-ATSRT UB1 BUI TALAS

ESIMERKKI 2

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

ESIMERKKI 3

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

LIITE G (Informatiivinen)

KEHITYSNÄKYMÄT

G.1. Johdanto

Tämän liitteen tarkoituksena on antaa viitteitä ADEXP:n ehdotetusta tulevasta kehityksestä ja kehityksen syistä ja tavoitteista.

G.2. Tavoitteet

Yksi tärkeimmistä ADEXP:n kehitysvaiheen aikaisista tavoitteista oli pyrkimys kehittää formaatti, joka sallisi vastaanottavan järjestelmän onnistuneesti "jättää huomiotta" tai "ohittaa" tuntematon tai tunnistamaton kenttä ilman, että käsiteltävää sanomaa tarvitsee välttämättä mitätöidä. Tämä toteutus sallii uuden kentän lisäämisen sanomaan ilman vaatimusta, että kaikki vastaanottavat järjestelmät muutetaan etukäteen ja että sitten suoritetaan huolellisesti koordinoitu "siirtyminen" uuteen järjestelmään. Näin saavutettu huomattava joustavuus on yksi ADEXP-formaatin eduista.

Tämä tavoite saavutetaan nykyisessä standardissa käyttämällä ennalta määriteltyjä ensisijaisia kenttiä ja alikenttiä, jotka aloitetaan yksikäsitteisillä avainsanoilla. Jos sanomaa analysoiva järjestelmä ei tunnista avainsanaa, sen on ohitettava kaikki teksti seuraavaan tunnettuun ensisijaiseen kenttään asti, joka ei ole luettelokentän sisällä. Näin saavutetaan palautuminen normaalitilaan ensisijaisten kenttien tasolla.

Uusien sanomien määrityksen nykyinen ja tuleva kehitys osoittaa, että tietyillä alueilla tarpeet muodostuvat niin monimutkaisiksi, että ne edellyttävät kenttien sisäkkäisyyttä kolmannella ja jopa neljännellä tasolla. (Ehdollisen reitin osoitussanoma (CRAM) on tuore esimerkki tästä vaatimuksesta.) Tällä hetkellä ADEXP tarjoaa mahdollisuuden rakentaa sanoma, jossa on minkä tahansa tasoista sisäkkäisyyttä. Tilanteesta, jossa alikenttä jää tunnistamatta vaikkapa kolmannella tai neljännellä tasolla, järjestelmä ei kuitenkaan pysty palautumaan normaalitilaan ilman vaaraa, että tiedot voivat tulla tulkituiksi väärin tai ilman pakkoa mitätöidä sanoma. Ehdotetut muutokset, joita ADEXP-formaatilta vaaditaan, on suunniteltu varmistamaan, että leksikaalinen analysaattori tai jäsennin pysyy koko ajan selvillä sijainnistaan suhteessa sanoman tai yksittäisen kentän rakenteeseen ja kykenee sen ansiosta jatkamaan toimintaansa virheen jälkeen millä tahansa sisäkkäisyyden tasolla ilman tietojen väärintulkinnan vaaraa.

G.3. Ehdotus

Jotta vikasietoisuustavoite saavutettaisiin millä tahansa tasolla sanoman rakenteessa, leksikaalisen analysaattorin on pystyttävä tunnistamaan kentän alun lisäksi myös sen loppu. Nykyinen muoto sallii vain kentän alun tunnistamisen merkin "-" perusteella.

ADEXP:n myöhemmässä julkaisussa tullaan ehdottamaan sulkeiden käyttöä kentän alun ja lopun osoittamisessa. Nyt käytössä oleva merkki "-" osoittamassa kentän alkua korvattaisiin merkillä "(". Kentän loppu, jota ei nykyään erikseen osoiteta, osoitettaisiin tulevaisuudessa merkillä ")". Seuraavat esimerkit selittävät periaatetta.

Esimerkkejä

>TAULUKON PAIKKA>

LIITE III

LENTOTIETOJEN SIIRRON RAJAPINNAN KONTROLLI (FLIGHT DATA EXCHANGE - INTERFACE CONTROL DOCUMENT, FDE-ICD), VERSIO 1.0

(Eurocontrolin asiakirjaviite COM.ET1.ST12-STD)

SISÄLLYSLUETTELO

>TAULUKON PAIKKA>

TEKIJÄNOIKEUSTIEDOT

Tämän asiakirjan on laatinut Euroopan lennonvarmistusjärjestö (Eurocontrol).

Eurocontrol omistaa asiakirjan tekijänoikeudet.

Asiakirjan sisältö kokonaisuudessaan tai osin on siten vapaasti jäsenvaltioiden edustajien käytettävissä, mutta asiakirjan kopiointi tai toimittaminen ulkopuolisille edellyttää Eurocontrolin antamaa kirjallista lupaa.

ESIPUHE

1. Vastuunalainen elin

Tämän standardin on laatinut ja sitä ylläpitää Eurocontrolin alainen lentosuunnitelmiin liittyvää tiedonvaihtoa (FPDE) käsittelevä työryhmä.

2. EATCHIP-työohjelma-asiakirja

Standardi koskee EATCHIP-työohjelma-asiakirjaa (EWPD), viestintäalaa, toimeenpanoa 01 sekä asiantuntijatehtävää 12.

3. Standardin hyväksyntä

3.1. Standardi on otettu käyttöön Eurocontrolin standardoinnista (viite 000-2-93) annetuissa ohjeissa määriteltyjen menettelyjen mukaisesti.

3.2. Standardi tulee voimaan, kun Eurocontrolin pysyvä komissio ottaa sen käyttöön. Standardi korvaa on-line-tiedonsiirtoa (OLDI) koskevan Eurocontrolin standardin 1. painoksen osan 3: TEKNISET VAATIMUKSET (lyhyen aikavälin rajapintahallinta-asiakirja), viite 001-3-92.

4. Tekniset oikaisut ja korjaukset

Standardia tarkistetaan jatkuvasti, jotta tarvittavat muutokset ja tekniset korjaukset voidaan ottaa huomioon. Standardin muuttamismenettelyt on kuvattu Eurocontrol-standardiasiakirjojen yhdenmukaisten laatimis- ja esitysohjeiden (viite 000-1-92) liitteessä H (Directives for the Uniform Drafting and Presentation of Eurocontrol).

5. Toimituskäytännöt

5.1. Tämän standardi on Eurocontrol-standardien yhtenäisestä laadinnasta ja esitystavasta annetun ohjeen mukainen.

5.2. Seuraavaa käytäntöä on noudatettu kohdan statuksen ilmaisemiseksi:

- Normatiivisten tietojen kohdalla käytetään verbiä "tulee" tai (yleisimmin) indikatiivin preesensmuotoa (tekee, tehdään, lähettää, lähetetään jne.), ja ne on ladottu normaalitekstinä;

- Suositeltujen tietojen kohdalla käytetään verbiä "tulisi" ja ne on ladottu kursivoituna tekstinä. Lisäksi ne on merkitty otsakkeella "Suositus".

5.3. Muu tietyn kohdan ymmärtämiselle olennainen tieto sisällytetään tekstiin HUOMAUTUKSENA. Huomautus on ainoastaan informatiivinen eli se ei sisällä määritelmiä, ja se sijoitetaan välittömästi sen kohdan jälkeen, johon se viittaa.

5.4. Jotta liitteen E profiilivaatimusten luettelot (PRL) on voitu esittää sopivassa muodossa, eräät taulukot on poikkeuksellisesti jätetty sisentämättä, eivätkä na jatku usealla sivulla.

6. Yhteys muihin standardiasiakirjoihin

6.1. Tämä Eurocontrol-standardiasiakirja korvaa Eurocontrolin OLDI-standardin [viite 13] sisältämän asiakirjan OLDI Short Term Interface Control Document (ST-ICD), 1. painos, osa 3.

6.2. Tämä Eurocontrol-standardi on ensimmäinen osa tulevaisuudessa laadittavaa lentotietojen siirtoa koskevaa Eurocontrolin (ICD-) standardisarjaa.

7. Tämän standardin liitteiden status

Tämän standardin liitteillä on seuraava status:

- Liite A - Normatiivinen

- Liite B - Normatiivinen

- Liite C - Normatiivinen

- Liite D - Normatiivinen

- Liite E - Normatiivinen

- Liite F - Informatiivinen

- Liite G - Informatiivinen

- Liite H - Informatiivinen

8. Kieli

Asiakirjan alkukieli on englanti.

1. JOHDANTO

Tämä Eurocontrol-standardi perustuu rajapinnan hallintaa koskevaan lyhyen aikavälin asiakirjaan, jonka laati aiempi OLDIn tekninen työryhmä, jonka tehtävänä oli määrittää uusia rajapintanormeja OLDI-järjestelmän toimintaan jatkossa aluelennonjohtokeskusten välillä.

Aikaisemmat OLDI-yhteydet perustuivat ainoastaan tähän tarkoitukseen määriteltyihin protokolliin, kuten INTERCAUTRA tai Datenübertragungs- und Verteilungssystem (DÜV), jotka toimivat tarkoitukseen varattujen kaksipisteyhteyksien tai rajattujen verkkojen kautta, ja vaativat erikoislaitteistoja ja -ohjelmistoja.

Useimpien suunniteltujen uusien yhteyksien kohdalla haluttiin siirtyä verkkopohjaisen rakenteen suuntaan ja ottaa käyttöön kansainväliset televiestintästandardit, joiden avulla yhteyksiä voidaan perustaa kustannustehokkaammin vähentämällä kunkin aluelennonjohtokeskuksen yhteyksien lukumäärää ja hyödyntämällä mahdollisuutta käyttää tavallisia helposti saatavia laitteistoja ja ohjelmia.

Tämä Eurocontrol-standardi virallistaa ja laajentaa rajapinnan hallintaa koskevaa lyhyen aikavälin asiakirjaa (ST-ICD). Se on kirjoitettu uudelleen perusteellisemmaksi määritykseksi, joka parantaa yhteentoimivuutta ja on lisäksi sopiva perusta tuleville rajapinnan hallintaa käsitteleville asiakirjoille, jotta nämä täyttäisivät jatkuvasti kehittyvät, lentotietojen siirtoon (FDE) kohdistuvat vaatimukset. Vaatimuksiin kuuluu muun muassa yhteiskäyttöisten verkkojen lisääntyvä käyttö sekä uusien alemman kerroksen standardien käyttöönotto. Tämä Eurocontrol-standardi määrittelee vähimmäistoiminnot, joita voidaan tukea olemassa olevilla OLDI-järjestelmillä mahdollisimman pienin muutoksin käyttäen joko kaksipisteyhteyksiä tai CCITT:n (Comité Consultatif des Téléphones et Télégraphes; 1980 tai uudempi) suositusta pakettivälitteisestä X.25-verkosta. Hankintatarkoituksiin voidaan määritellä myös muita vaihtoehtoja. Tämä rajapintahallinta-asiakirja ei estä osapuolia sopimasta keskenään pidemmälle menevistä ratkaisuista.

Kohteet, joissa on tarkoitus käyttää myös muita sovellusprotokollia tässä asiakirjassa kuvatun lisäksi tai sen sijaan, voivat joko hakea muutosta nykyiseen protokollaan tai eriyttää eri protokollia käyttävät järjestelmänsä omiksi virtuaaliyksiköikseen.

2. LAAJUUS

2.1. Eurocontrol-standardissa täsmennetään aluelennonjohtokeskusten (ACC) välisessä lentotietoihin liittyvien sanomien välityksessä käytettävä dataliikennerajapinta. Se esitetään avointen järjestelmien liitäntämallin (OSI) mukaisen profiilin muodossa kuten Kansainvälisen standardisoimisjärjestön / Kansainvälisen sähköteknisen komission (ISO/IEC) teknisessä raportissa (TR) 10000-2 [viite 3] on kuvattu. Profiili kattaa sekä alakerrokset (T-profiili) että yläkerrokset (A-profiili).

2.2. Tämä Eurocontrol-standardi soveltuu seuraaviin tilanteisiin:

- OLDIn tukeminen Eurocontrol-standardin N° 001-92 painoksen 1 mukaisesti;

- OLDI-sovellussanomien välityksen tukeminen aluelennonjohtokeskuksista (ACC) lentovirtojen hallinnan keskusjärjestelmiin (CFMU).

2.3. Standardia sovelletaan yhteyksiin, jotka käyttävät joko

- vuokrattuja kahden pisteen välisiä yhteyksiä, tai

- yleisen puhelinverkon (PSTN) kahden pisteen välisiä yhteyksiä, tai

- pakettivälitteisiä dataverkkoja tai yhteenliitettyjä pakettivälitteisiä dataverkkoja, joiden rajapinta vastaa CCITT:n X.25-suositusta (1980 tai uudempi).

HUOM.

1. Lentosuunnitelmien prosessointijärjestelmien välinen järjestely on esitetty kuvassa 1.

2. Kuvassa 1 ei esitetä mahdollisia varayhteyksiä, kuten yleisen puhelinverkon yhteyksiä, joista on annettu ohjeita liitteessä H.

Kuva 1

Rajapinnan järjestely

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

2.4. Tässä standardissa ei määrätä määritellyn tiedonsiirtorajapinnan yksityiskohtaisista turvanäkökohdista. Liitekohdasa on kuitenkin kuvattu perustoteutus ja lisäohjeita on tämän Eurocontrol-standardin liitteessä H.

3. VIITTAUKSET

3.1. Johdanto

Seuraavien asiakirjojen ja standardien ne kohdat, joihin viitataan tässä asiakirjassa, ovat osa tätä Eurocontrol-standardia.

Viiteasiakirjoista ja -standardeista on ilmoitettu tämän Eurocontrol-standardin julkaisuhetkellä voimassa olleet painokset.

Viitteenä oleviin kansainvälisen siviili-ilmailujärjestön (ICAO) asiakirjoihin tehdyt muutokset tulee välittömästi ottaa huomioon tässä Eurocontrol-standardissa.

Muiden viitteenä olevien asiakirjojen muutokset tulevat osaksi tätä Eurocontrol-standardia vasta kun ne on virallisesti arvioitu ja sisällytetty tähän Eurocontrol-standardiin.

Mikäli kyseiset muut viitteenä olevat asiakirjat ovat ristiriidassa tämän Eurocontrol-standardin kanssa, noudatetaan tätä Eurocontrol-standardia.

3.2. Viittaukset

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Part 1 Integration Test Plan Version 1.0, päivätty 10. 5.1996.

16. Eurocontrol FDE ICD Part 1- Reliability, Availability and Security - Technical Report version 1.0, päivätty 20. 4.1997.

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

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

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

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

4. MÄÄRITELMÄT, TUNNUKSET JA LYHENTEET

4.1. Määritelmät

4.1.1. Tässä Eurocontrol-standardissa noudatetaan seuraavia määritelmiä:

4.1.2. Profiili: Yhdestä tai useammasta perusstandardista ja tarvittaessa näistä perustandardeista valittujen luokkien, osajoukkojen, vaihtoehtojen tai parametrien määritelmästä koostuva kokonaisuus, joka on välttämätön tietyn toiminnon toteuttamiseksi [viite 2].

4.1.3. Profiilivaatimusluettelo (PRL): Profiilivaatimukset esitetään vastaavuusvaatimusten muodossa, ja ne on järjestetty luetteloksi taulukkomuotoon [viite 2].

4.1.4. T-profiili: Siirtoprofiili, joka tarjoaa yhteydellisen siirtopalvelun [viite 3].

4.1.5. A-profiili: Sovellusprofiili, joka vaatii yhteydellisen siirtopalvelun [viite 3].

4.1.6. Protokollatoteutuksen vastaavuuslausunto (PICS): Lausunto, jonka on antanut OSI-järjestelmän toimittaja ja josta käy ilmi, mitkä ominaisuudet kyseisestä OSI-protokollasta on toteutettu [viite 14].

4.2. Tunnukset ja lyhenteet

>TAULUKON PAIKKA>

4.3. Merkkijärjestelmä

4.3.1. Tässä Eurocontrol-standardissa binääriarvot tai bittijonot merkitään heksadesimaaleina käyttäen merkintää 'd'H, jossa kirjain d tarkoittaa merkkiä tai heksadesimaalisten merkkien jonoa.

4.3.2. Tässä Eurocontrol-standardissa bittijonon heksadesimaalinen esitys muodostetaan ottamalla neljä bittiä kerrallaan aloittamalla eniten merkitsevästä bitistä (MSB) ja etenemällä vähiten merkitsevään bittiin (LSB).HUOM.

Ellei viitteenä olevissa kansainvälisissä standardeissa mainita toisin, bittijono lähetetään MSB:stä LSB:hen.

4.3.3. Tässä Eurocontrol-standardissa perusstandardin tai tämän Eurocontrol-standardin ominaisuuksien tukemisen tila merkitään isoilla kirjaimilla (esim. M, O, O.< n >, X). Jokaisen tilaa ilmaisevan merkinnän tarkka merkitys on kuvattu tämän Eurocontrol-standardin liitteissä ennen kuin niitä käytetään tekstissä.

4.3.4. Lentotietojen vaihdon rajapinnan hallintaa koskevan asiakirjan osan 1 profiilin määrittelemiseksi tässä Eurocontrol-standardissa merkitään perusstandardin tai tämän Eurocontrol-standardin ominaisuuksien tukemisen tila pienillä kirjaimilla (esim. m, o, o.< n >, x).HUOM.

Tämän johdosta ehdolliset, valinnaiset tai arvosta riippuvat perusstandardien ominaisuudet tulevat määritellyksi entistä tarkemmin (katso E.3.1).

5. TEKNINEN YLEISKATSAUS

5.1. Protokollapino

HUOM.

Tämän Eurocontrol-standardin profiilin protokollapino on esitetty kuvassa 2. Kuvassa suhteutetaan protokollat OSI:n perusviitemalliin [viite 9] osoittamalla niiden vastaavuudet pinon OSI-kerrosten kanssa. Protokollapino on kuitenkin määritelty ennen OSI:a vallinneille järjestelmille, eikä se tue niitä monia toimintoja, jotka ovat mahdollisia vastaavien OSI-kerrosten OSI-protokollissa.

Kuva 2

Profiilin protokollapino

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

5.2. Profiilirakenne

HUOM.

1. Kuten kuvassa 2 esitetään, profiilipino yhdistää useita alemman kerroksen protokollia, joista ainoastaan pakettitason protokolla (PLP) X.25 [viite 1] ja sitä tukevat protokollat, X.21 [viite 4] ja X.21bis [viite 5], on määritetty olemassa olevissa ISO/IEC:n ja ITU-T:n standardeissa. Muut korkeampien kerrosten protokollat on määritetty tämän Eurocontrol-standardin liitteissä (liitteet A, B ja C).

2. Profiilin vastaavuusvaatimuksissa voidaan viitata näihin eritelmiin yhtä hyvin kuin ulkoisiin normeihinkin. Vaatimukset on esitelty kohdassa 6. Yksityiskohtaiset vaatimukset on esitetty käyttämällä PRL-taulukkomuotoa (liite E) ja PICS-lomakkeita (liitteissä määriteltyjen protokollien lomakkeet esitetään liitteessä D). Näiden PRL-muotojen ja PICS-lomakkeiden käyttö kehitystyössä ja ja/tai hankintamenettelyissä on selvitetty liitteessä E.

5.3. Yhteys aikaisempiin määritelmäversioihin

HUOM.

1. Tämä profiili perustuu ST-ICD-asiakirjaan, jonka laati entinen tekninen OLDI-alaryhmä. Tässä Eurocontrol-standardissa kuvatut protokollat ja pakettimuodot ovat yhteensopiva osajoukko ST-ICD:n vastaavista protokollista ja pakettimuodoista, sillä poikkeuksella, että tämä Eurocontrol-standardi esittää yksityiskohtaisempia vaatimuksia X.25 PLP:n käytölle, sisältää M-bitin pakollisen tuen sekä korjaa AFI-kentän arvon epäjohdonmukaisen määrittelyn NSAP-osoitteessa.

2. Suurin tyylimuutos tässä Eurocontrol-standardissa koskee ICD-määrittelyn rakennetta. Sanomanvälitysprotokolla (liite A) on erotettu sitä tukevasta T-profiilista. Tämä helpottaa muiden T-profiilien käyttöä sitä mukaa kun se tulee välttämättömäksi FDE-vaatimusten kehittymisen myötä.

3. Ne osat ST-ICD-määrityksissä, jotka koskevat X.25:n virtuaalipiirien ohjausta ja sovellussanomien rajoittamista, löytyvät nyt sanoman otsikkoprotokollasta (liite B), joka muodostaa FDE:n vähimmäissiirtokerroksen.

6. PROFIILIVAATIMUKSET

6.1. Vaatimustenmukaisuus

6.1.1. Toteutuksen, jonka ilmoitetaan vastaavan tätä standardia, tulee täyttää jäljempänä olevissa kappaleissa 6.2 ja 6.3 esitetyt vaatimukset.

6.1.2. Vastaavuusväittämän tueksi tulee antaa profiilin toteutuksen vastaavuusvakuutus kuten liitteissä D ja E on kuvattu.

6.2. Ylemmän kerroksen vaatimukset

6.2.1. Vaatimustenmukaisen toteutuksen tulee täyttää perusstandardissa asetetut vaatimukset, jotka on esitetty liitteessä A.

6.2.2. Vaatimustenmukaisen toteutuksen tulee täyttää ehdot, jotka on esitetty profiilivaatimusluettelossa liitteessä E.7.

6.3. Alemman kerroksen vaatimukset

6.3.1. Siirtokerroksen vaatimukset

6.3.1.1. Vaatimustenmukaisen toteutuksen tulee täyttää liitteessä B esitetyt perusstandardin vaatimukset.

6.3.1.2. Vaatimustenmukaisen toteutuksen tulee täyttää ehdot, jotka on esitetty profiilivaatimusluettelossa liitteessä E.8.1.

6.3.1.3. Vaatimustenmukaisen toteutuksen tulee tukea TSDU-yksiköiden kokoja 4097 oktettiin asti.HUOM.

TSDU:n ensimmäinen oktetti vastaa yhtä sanomaotsikon kenttää (katso A.4.10 ja B.4.4), ja jättää näin enintään 4096 oktettia käyttäjän tiedoille.

6.3.2. Verkkokerroksen vaatimukset

6.3.2.1. Vaatimustenmukaisen toteutuksen tulee täyttää ISO/IEC 8208:n vaatimukset [viite 7] liitteessä C esitetyn protokollakuvauksen mukaisesti.

6.3.2.2. Vaatimustenmukaisen toteutuksen tulee täyttää ehdot, jotka on esitetty profiilivaatimusluettelossa liitteessä E.8.2.

6.3.2.3. Vaatimustenmukaisen toteutuksen tulee, mikäli DTE-DTE-toimintaa tuetaan, pystyä järjestelmänhallintamekanismien avulla konfiguroimaan valinta DTE- ja DCE-roolien välillä DTE-DTE-toimintaa varten.

6.3.2.4. Vaatimustenmukaisen toteutuksen tulee kummassakin 6.3.2.3:n mukaisessa roolissa pystyä luomaan yhteys liitteen C määrittelyn mukaisesti, toisin sanoen protokolla on täysin symmetrinen.HUOM.

Jotkin olemassa olevat ST-ICD:hen perustuvat toteutukset eivät ehkä pysty luomaan verkkoyhteyksiä liitteen C protokollan mukaisesti.

6.3.2.5. Vaatimustenmukaisen toteutuksen tulee mukautua tietyn ajanjakson ajan ei-standardoituihin oletuspakettikokoihin arvolla 256 kumpaankin siirtosuuntaan.

6.3.2.6. Vaatimustenmukaisen toteutuksen tulee käyttää NSAP-osoitteita liitteen C mukaisesti.

6.3.2.7. Vaatimustenmukaisen toteutuksen tulee asettaa D-bitti arvoon 0 paketeissa CALL REQUEST, CALL ACCEPTED ja DATA.HUOM.

Kun arvoksi asetetaan D=0 paketeissa CALL REQUEST ja CALL ACCEPTED, vahvistus lähetyksen onnistumisesta kytkeytyy pois.

6.3.3. Siirtoyhteyskerroksen vaatimukset

6.3.3.1. Vaatimustenmukaisen toteutuksen tulee täyttää ISO/IEC 7776:n vastaavuusvaatimukset [viite 6] protokollan Link Access Protocol Balanced (LAPB) Single Link Protocol osalta.

6.3.3.2. Vaatimustenmukaisen toteutuksen tulee täyttää myös ehdot, jotka on esitetty profiilivaatimusluettelossa liitteessä.

6.3.4. Fyysisen kerroksen vaatimukset

Vaatimustenmukaisen toteutuksen tulee täyttää ISO/IEC ISP 10609-9 lausekkeen 7 [viite 8] vastaavuusvaatimukset.

7. TESTAUSMENETELMÄT

HUOM.

1. Liitteessä F on kuvattu testausmalli, jonka avulla voidaan selvittää, ovatko järjestelmät tämän standardin mukaisia.

2. Tähän standardiin liittyvien PRL-luetteloiden ja PICS-lomakkeiden käyttöä vaatimustenmukaisuuden dokumentointiin on kuvattu liitteessä E.

LIITE A (Normatiivinen)

SANOMANVÄLITYSPROTOKOLLA

A.1. Johdanto

Tämä määritelmä kuvaa protokollaa, jonka avulla toteutetaan yksinkertainen sanomanvälityspalvelu sovelluksille, jotka edellyttävät lentotietojen siirtoa.

A.2. Toteutettavat palvelut

Sanomanvälitys (MT)-protokolla toteuttaa seuraavat vahvistamattomat palvelut:

MT-Associate: luo sovellussanoman siirtoyhteyden;

MT-Data: välittää ASCII-merkeistä koostuvan sovellussanoman;

MT-Abort: katkaisee sovellussanoman siirtoyhteyden.

A.3. Edellytetyt palvelut

Tämä sanomanvälitysprotokolla edellyttää osajoukkoa yhteydellisestä siirtopalvelusta, joka on kuvattu ISO/IEC 8072:ssa [viite 11] ja jollaisen tämän Eurocontrol-standardin liitteessä B kuvattu protokolla mahdollistaa.

A.4. Protokollan määrittely

A.4.1. Johdanto

Seuraavassa tekstissä kuvataan ainoastaan yhden sovelluksen luoman sanomanvälitysyhteyden toiminta. Samalla verkkorajapinnalla voidaan tukea muitakin yhteyksiä toistamalla näitä toimenpiteitä jokaiselle siirtoyhteydelle.

A.4.2. Tietotyypit

Tässä liitteessä yksilöidään neljä eri sovellussanomaa, jotka vastaavat Eurocontrol-standardin N:o 001-3-92 versiossa 1 kuvattuja sovellussanomia:

Järjestelmäsanomat: Näitä sanomia käytetään yhteyden tarkkailuun (HEARTBEAT-sanoma) ja sovelluksen ohjaukseen (STARTUP- ja SHUTDOWN-sanomat).

Toiminnalliset sanomat: Nämä sanomat liittyvät tiettyyn toiminnalliseen kontekstiin, ja ne on kuvattu Eurocontrol-standardeissa ja -asiakirjoissa, jotka hyödyntävät tätä standardia tiedonsiirrossa. Eurocontrol-standardi on-line-tiedonsiirrosta kuvaa toiminnallisia sanomia, jollaisia ovat esim. aktivointisanoma (ACT), rajatiedon ennakkoilmoitussanoma (ABI) ja looginen kuittaussanoma (LAM).

Operaattorisanomat: Nämä sanomat sisältävät vapaata tekstiä. Niiden käytöstä sovitaan kahdenvälisesti. Niitä voidaan esimerkiksi käyttää testitietojen vaihtamiseen tai toisen osapuolen informoimiseen operaattorin toimista.

Tilasanomat: Näiden sanomien käytöstä ja sisällöstä sovitaan kahdenvälisesti. Niitä voidaan esimerkiksi käyttää järjestelmänhallintatietojen vaihtamiseen.

HUOM.

1. Järjestelmäsanomien käyttö on osa tämän protokollan toimintaa, ja niiden muoto on määritelty tämän liitteen kohdassa A.4.10.3.

2. Tilasanomien käyttö ja muoto perustuvat kahdenvälisiin sopimuksiin eikä niitä ole tarkemmin määritelty tässä Eurocontrol-standardissa.

3. Protokollan tila määrää, minkätyyppisiä sanomia voidaan välittää. Seuraavissa kappaleissa on kuvattu näitä tyyppejä.

A.4.3. Yhteyden luominen

A.4.3.1. Protokolla on aluksi IDLE-tilassa.

A.4.3.2. Sanoman välityksen yhteyspyyntöprimitiivi (MT-Associate-Request) suoritetaan sovellusyhteyden luomiseksi ja protokollan saattamiseksi tilaan DATA_READY. Sekä paikallisten että etäsovellusten tulee kutsua primitiiviä.

A.4.3.3. Ensin on luotava siirtoyhteys noudattaen liitteen B kappaleessa B.4.1 kuvattuja primitiivin T-Connect-menettelyjä, minkä jälkeen protokolla siirtyy tilaan READY. Tässä vaiheessa voidaan välittää ainoastaan järjestelmäsanomia (ja mahdollisesti kahdenvälisen sopimuksen perusteella myös operaattorisanomia). Järjestelmä- tai operaattorisanoman välittämiseksi lähettäjä käyttää primitiiviä T-Data (katso B.4.4) ja sanoma toimii parametrinä.

A.4.3.4. Tämän jälkeen lähetetään STARTUP-sanoma (järjestelmäsanoma), käynnistetään ajastin Tr (katso A.4.7) ja protokolla siirtyy tilaan ASSOCIATION_PENDING. Jos ajastin Tr käy loppuun protokollan ollessa tässä tilassa, STARTUP-sanoma lähetetään uudestaan ja ajastin käynnistetään uudestaan.HUOM.

Protokolla pysyy ASSOCIATION_PENDING-tilassa, kunnes STARTUP-sanoma on vastaanotettu. Jatkuvat Tr-ajastimen ajan ylitykset voidaan ilmaista paikallisesti.

A.4.3.5. STARTUP-sanomien vastaanoton tulee aiheuttaa seuraavat toimenpiteet:

- Tilassa ASSOCIATION_PENDING lähetetään uusi STARTUP-sanoma, protokolla siirtyy tilaan DATA_READY ja primitiivi MT-Associate-Indication ilmaistaan;

- muissa tiloissa sanomaa ei huomioida.

A.4.3.6. STARTUP-sanoman vastaanotto tilassa ASSOCIATION_PENDING merkitsee jompaa kumpaa seuraavista:

- etäsovellus on antanut primitiivin MT-Associate-Request ja sen sanomanvälitysprotokolla on siirtynyt tilaan ASSOCIATION_PENDING, tai

- etäsovelluksen sanomanvälitysprotokolla vastaa aikaisemmin vastaanotettuun STARTUP-sanomaan ja on siirtynyt tilaan DATA_READY.

HUOM.

Moniselitteisyys johtuu siitä, että samaa sanomaa käytetään STARTUP:iin ja STARTUP:iin vastaamiseen. Tämän seurauksena sanomanvälitys-protokolla, joka ensin siirtyi DATA_READY-tilaan, vastaanottaa toisenkin STARTUP-sanoman. Kuten kohdassa A.4.3.5 on määritelty, tätä STARTUP-sanomaa ei huomioida.

A.4.3.7. Kun STARTUP-sanomia on vaihdettu, yhteys on luotu ja kaikki yksilöidyt sanomatyypit voidaan välittää (DATA_READY-tila).

A.4.4. Tiedonsiirto

Muuntyyppisiä sanomia välitetään järjestelmäsanomien tapaan käyttäen T-Data-palvelua sanoman toimiessa parametrina. Tämä vastaa palveluprimitiivejä MT-Data-Request ja MT-Data-Indication. HUOM.

Jokainen sanoma lähetetään yhtenä TSDU:na: tällä tasolla ei tapahdu sanomien ketjuttamista tai pilkkomista.

A.4.5. Järjestyksenmukainen yhteyden purku

A.4.5.1. Sanomanvälitysyhteys kahden sovelluksen väliltä voidaan purkaa kumman tahansa toimesta. Tämä vastaa palveluprimitiiviä MT-Abort-Request.

A.4.5.2. Tässä tilanteessa tulee suorittaa seuraavat toimenpiteet:

- Tilassa DATA_READY lähetetään SHUTDOWN-sanoma (järjestelmäsanoma), ajastimet Tr ja Ts pysäytetään ja siirtoyhteys puretaan;

- Tilassa ASSOCIATION_PENDING lähetetään SHUTDOWN-sanoma (järjestelmäsanoma), ajastin Tr pysäytetään ja siirtoyhteys puretaan;

- READY-tilassa siirtoyhteys puretaan;

- muussa tapauksessa ei toimenpiteitä.

HUOM.

SHUTDOWN-sanoma ei ole ennakkovaroitus - yhteys katkeaa välittömästi. Tätä sanomaa ei vahvisteta toisesta päästä.

A.4.5.3. SHUTDOWN-sanoman vastaanotto aiheuttaa seuraavat toimenpiteet:

- Tilassa DATA_READY, ajastin Ts (katso A.4.7) pysäytetään, MT-Abort-Indication ilmaistaan ja rajapinta siirtyy tilaan ASSOCIATION_PENDING lähettämättä STARTUP-sanomaa;

- muissa tiloissa ei aiheudu minkäänlaisia toimenpiteitä.

A.4.6. Yhteyden uudelleenluonti

Sovelluksella, joka käynnisti yhteyden purkamisen, on valmiina ollessaan vastuu luoda uudelleen sovellusyhteys ja mahdolliset alemmat kerrokset (tarvittaessa).HUOM.

Jos yhteyden purkaminen on johtanut kanavana käytetyn verkkoyhteyden katkeamiseen, tulee seurata kappaleen A.4.3 yhteydenluontitoimenpiteitä.

A.4.7. Yhteyden eheys

A.4.7.1. Kahden sovelluksen välisen yhteyden eheydestä huolehtii lepotilan sykäysominaisuus (heartbeat).

A.4.7.2. Siirryttäessä tilaan DATA_READY ja lähetettäessä siirtoyhteyden kautta minkätyyppistä sanomaa tahansa käynnistetään säädettävä ajastin Ts. Jos ajastin Ts laukeaa tilassa DATA_READY, lähetetään HEARTBEAT-sanoma (järjestelmäsanoma) (ja ajastin käynnistetään uudelleen).

A.4.7.3. Samoin siirryttäessä tilaan DATA_READY ja vastaanotettaessa yhteyden kautta muu kuin STARTUP-sanoma käynnistetään säädettävä ajastin Tr. Jos ajastin Tr laukeaa tilassa DATA_READY, ilmaistaan MT-Abort-Indication, kaikkien sanomien lähetys pysäytetään, ajastin Ts pysäytetään ja ajastin Tr käynnistetään uudelleen. Rajapinta on tilassa ASSOCIATION_PENDING.HUOM.

Sovellukset palautuvat toimintatilaan ja synkronoituvat uudelleen STARTUP-sanomien vaihdon avulla (katso A.4.3).

A.4.8. Yhteyden purkaminen epäjärjestyksessä

A.4.8.1. Yhteys purkautuu epänormaalisti, jos

- siirtoyhteys katkeaa (esim. linjavika, protokollavirhe),

- toinen kahdesta sovelluksesta tai järjestelmästä menee epäkuntoon (tämä voi olla seurausta laitteisto- tai ohjelmistovioista; joissakin tapauksissa siirtoyhteys toimii edelleen).

HUOM.

Liitteen B siirtoprotokollan määritelmän mukaisesti ei ole olemassa päästä-päähän-siirtoyhteyttä. Tämän seurauksena siirtoyhteyden katkeaminen on suoraa seurausta verkkoyhteyden katkeamisesta.

A.4.8.2. Sovellus- tai järjestelmävirhe voidaan havaita siitä, että kyseiseltä sovellukselta ei saavu odotettua HEARTBEAT-sanomaa ennen ajastimen laukeamista (katso A.4.7).

A.4.9. Vikatilanteesta toimintakuntoon palautuminen

A.4.9.1. Tarkasteltavana on kaksi tilannetta:

- tilanne siirtoyhteysvian jälkeen

- tilanne sovellusvian jälkeen

A.4.9.2. Kummassakin tapauksessa yhteyden uudelleenluonti edellyttää normaaleja yhteydenluontitoimenpiteitä (katso A.4.3), mukaan luettuna STARTUP-sanomien vaihto.HUOM.

Jos sovellustasolla tapahtuu virheitä, jotka eivät kuitenkaan pura varsinaista yhteyttä, vikatilassa oleva järjestelmä saattaa lähettää SHUTDOWN-sanoman (ts. L_shutdown-sanoman, joka on tuotettu joko manuaalisesti tai osana sovelluslogiikkaa) ennen kuin se yrittää luoda yhteyttä uudelleen. Tämä nopeuttaa etäsovelluksen Tr-ajastimen laukeamista ja saattaa johtaa nopeampaan palautumiseen normaalitilaan, jolloin häviävän tiedon määrä voi vähentyä.

A.4.10. Sanomamuodot

A.4.10.1. Yleinen sanomarakenne

>TAULUKON PAIKKA>

A.4.10.2. Sanoman rungon pituus

Enintään 4096 oktetin mittaiset sanomarungot ovat mahdollisia.

A.4.10.3. Järjestelmäsanomien muodot

>TAULUKON PAIKKA>

A.4.10.4. Muut sanomamuodot

>TAULUKON PAIKKA>

HUOMAUTUKSET

1. Tilasanomien sanomarungon muoto ei kuulu tämän Eurocontrol-standardin piiriin.

2. Toiminnallisten sanomien muoto on määritetty Eurocontrol-standardeissa ja -asiakirjoissa, jotka kuvaavat sanomanvälityssovelluksia, kuten on-line-tiedonsiirtoa [viite 13].

3. Operaattorisanomat koostuvat tulostettavasta ASCII-tekstistä. Jos näitä sanomia käytetään, tarvitaan käyttöliittymä, joka näyttää vastaanotetut sanomat ja sallii lähetettävien sanomien kirjoittamisen.

A.5. Protokollan tilasiirtymätaulukot

A.5.1. Johdanto

Alla olevat tilataulukot ovat protokollan määräävä kuvaus. Jos ilmenee ristiriitoja edellä olevan tekstin kanssa, jäljempänä esitetyt määritykset pätevät.HUOM.

Tilojen, tapahtumien, ajastimien ja toimintojen kuvaustapa perustuu ST-ICD-asiakirjaan. Seuraavassa annettavat määritelmät ja niihin perustuvat toimenpiteet on kuitenkin uudelleen tarkistettu, ja ne saattavat poiketa ST-ICD:stä.

A.5.2. Tilan määritelmiä

Taulukko 1

Tilan määritelmiä

>TAULUKON PAIKKA>

A.5.3. Mahdolliset tapahtumat

Taulukko 2

Mahdolliset tapahtumat

>TAULUKON PAIKKA>

A.5.4. Ajastimet

Taulukko 3

Ajastimet

>TAULUKON PAIKKA>

Näiden ajastimien arvon tulee olla sellainen, että Tr = 2Ts + siirtoaika.HUOM.

Ajastimien tyypilliset arvot ovat: Ts = 30s, Tr = 70s.

A.5.5. Tilanvaihtotaulukko

Taulukko 4

Tilasiirtymät

>TAULUKON PAIKKA>

A.5.6. Tilasiirtymäkaavio

HUOM.

Protokolla kuvataan kuvassa A.1 tilasiirtymäkaavion muodossa. Kaavio on ainoastaan informatiivinen: jos kaavion ja edellä esitettyjen tilataulukoiden välillä ilmenee ristiriitaa, noudatetaan taulukoita.

Kuva A.1

Sanomanvälitysprotokolla: Tilasiirtymäkaavio

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

LIITE B (Normatiivinen)

SANOMAN OTSIKKOPROTOKOLLA

B.1. Johdanto

Tässä liitteessä määritetään sanoman otsikkoprotokolla, joka on vähimmäissiirtoprotokolla OLDIn kaltaisille sovelluksille.

B.2. Toteutettavat palvelut

B.2.1. Sanoman otsikkoprotokolla vastaa osajoukkoa yhteydellisestä siirtopalvelusta, kuten ISO/IEC 8072:ssa on määritetty [viite 11], ja koostuu seuraavista palveluprimitiiveistä.

T-Connect: luo sovellukselle siirtoyhteyden

T-Data: siirtää ASCII-muotoista tietoa

T-Disconnect: katkaisee sovelluksen siirtoyhteyden

B.2.2. Palvelu ei tue kanavointia, virheistä palautumista eikä segmentointia ja uudelleen kokoamista.

B.3. Edellytetyt palvelut

Protokolla edellyttää luotettavaa perusverkkopalvelua, jollaisen tarjoaa X.25:n pakettitason protokolla (PLP).HUOM.

Jokaisessa verkkoyhteydessä tuetaan ainoastaan yhtä siirtoyhteyttä.

B.4. Protokollan määrittely

B.4.1. Yhteyden luominen

Primitiivi T-Connect toteutetaan käyttämällä pohjana olevan verkon palvelua N-Connect. Näiden kahden (request- ja indication-) primitiivijoukon välillä on suora vastaavuus. Vaihtoehtoisesti voidaan käyttää olemassa olevaa verkkoyhteyttä (esim. järjestelmänhallintamekanismien luomaa).Suosituksia

1. Jälkimmäisessä yllämainituista tapauksista verkkoyhteys tulisi nollata ennen käyttöä. Primitiivi N-Connect voidaan uusia automaattisesti, jos vastausta ei saada määrätyn ajan kuluessa.

2. Jos tämä automaattinen uudelleenyritys toteutetaan, yritykset tulisi tehdä noin 15 sekunnin välein.

B.4.2. Ylimääräisten verkkoyhteyksien välttäminen

Jos primitiivi N-Connect-Request esiintyy yksin (eli vastaavaa primitiiviä N-Connect-Confirm tai N-Disconnect ei ole ilmaistu) ja N-Connect-Indication on ilmaistu, niin kyseinen sisääntuleva yritys verkkoyhteyden luomiseksi torjutaan tai puretaan vastaamalla siihen primitiivillä N-Disconnect-Request, mutta vain molempien seuraavien ehtojen täyttyessä:

- primitiivin N-Connect-Indication kutsuva NSAP-osoite on sama kuin yksin esiintyneen primitiivin N-Connect-Request kutsuma NSAP-osoite,

- yksin esiintyneen primitiivin N-Connect-Request kutsuva NSAP-osoite on suurempi kuin ko. primitiivin kutsuma NSAP-osoite: vertailu perustuu kunkin NSAP-osoitteen binääriesitykseen sellaisina kuin ne on määritetty dokumentin ISO/IEC 8348 Liitteessä A [Viite 10] (jono katsotaan suuremmaksi kuin mikään sen aloittava alajono, esim. '8800'H >'88'H).

B.4.3. Yhteyden purku

B.4.3.1. Yhteyttä purettaessa käytetään perustana olevan verkkopalvelun primitiivejä N-Disconnect and N-Reset.

B.4.3.2. Primitiivin T-Disconnect-Request toteuttamiseksi ilmaistaan N-Disconnect-Request. Vaihtoehtoisesti, jos verkkoyhteyksien käsittelyä primitiivien N-Disconnect-Request avulla ei tueta, verkkoyhteyttä ei pureta eksplisiittisesti.Suositus:

Jälkimmäisessä edellä mainituista tapauksista verkkoyhteys tulisi nollata.

B.4.3.3. T-Disconnect-Indication ilmaistaan vastaanotettaessa jompikumpi seuraavista verkkopalveluprimitiiveistä verkkoyhteydessä, joka vastaa kokonaan tai osittain luotua siirtoyhteyttä:

- N-Disconnect-Indication

- N-Reset-Indication

B.4.4. Tiedonsiirto

B.4.4.1. Primitiivi T-Data toteutetaan käyttämällä perustana olevan verkkopalvelun primitiiviä N-Data. Näiden kahden (request- ja indication-) primitiivijoukon välillä on suora vastaavuus. Se perustuu TPDU-yksikköön, joka välitetään verkkopalvelun kautta.

B.4.4.2.

>TAULUKON PAIKKA>

HUOM.

1. Tämä otsikko on määritetty identtiseksi INTERCAUTRA-proseduurissa käytetyn kanssa, kun sillä siirretään liitteessä määritettyjä sanomamuotoja; tässä tapauksessa kenttä "data(1)" vastaa TYP-kenttää. INTERCAUTRA määrittelee ACT-sanomien vaihdon seuraavien kohteiden välillä: CAUTRA Paris, London Air Traffic Control Centre: 9020D-järjestelmä, ja Digital Communications Terminal System (DCTS) Maastricht/Karlsruhe.

2. Kenttien ADEST, DEST, AEMM, EMM ja ADR käyttö muilla arvoilla kuin '40'H ei kuulu tämän Eurocontrol-standardin piiriin, mutta siitä voidaan sopia kahdenvälisesti.

B.4.4.3. Palvelun T-Data tulee rajoittua tulostettavan ASCII-merkkitiedon siirtoon. Erityisen tärkeää on, että millään tieto-oktetilla ei ole arvoa '03'H (merkki ETX).

B.4.4.4. Vaatimustenmukaisen toteutuksen tulee tukea 4105 oktetin kokoisia ja sitä pienempiä NSDU-yksiköitä.

B.4.4.5. Vaatimustenmukaisen toteutuksen tulee estää usean TSDU-yksikön ketjuttaminen yhdeksi NSDU:ksi.

B.4.4.6. Vaatimustenmukaisen toteutuksen tulee estää yhden TSDU:n pilkkominen useaksi NSDU-yksiköksi.

LIITE C (Normatiivinen)

VERKKOPROTOKOLLA

C.1. Johdanto

Tässä liitteessä määritetään X.25:n pakettitason protokollan avulla perusverkkoprotokolla käytettäväksi lentotietojen siirron tukemiseen sekä pisteestä-pisteeseen-yhteyksissä että pakettivälitteisessä verkkoympäristössä. Tämä protokollan osajoukko on vastaa viitteessä 1 kuvattua osaprotokollaa (versiot vuoden 1980 painoksesta lähtien).

C.2. Toteutettavat palvelut

C.2.1. Protokolla toteuttaa yhteydellisen OSI-verkkopalvelun, kuten ISO/IEC 8348:ssa on määritetty [viite 10], seuraavin poikkeuksin:

- NSAP-osoitteet on rajoitettu C.4.2:ssa määritettyyn muotoon,

- ei ole keinoa, jolla verkkopalvelun käyttäjät ja sen tarjoaja voivat sopia verkkoyhteyteen liittyvän palvelun laadusta,

- verkkopalvelun käyttäjän tietojen siirtoa verkkoyhteyden luomisen tai purkamisen aikana ei tueta lukuun ottamatta C.5.3:ssa kuvattuja ehtoja.

C.2.2. Seuraavia verkkopalvelun tarjoajan toimintoja ei ole käytettävissä:

- vastaanoton vahvistaminen

- tiedonsiirron nopeuttaminen

C.3. Edellytetyt palvelut

Protokolla edellyttää OSI:n siirtokerroksen palvelua, jollaisen tarjoaa esim. ISO/IEC 7776 (LAPB) [viite 6].

C.4. NSAP-osoitteiden luominen

C.4.1. Johdanto

C.4.1.1. NSAP-osoitteiden rakenne noudattaa dokumentin ISO/IEC 8348 liitteessä A [viite 10] kuvattua rakennetta, kuten alla on esitetty.

>PIC FILE= "L_2000254FI.019702.EPS">

C.4.1.2. Alla on määritelty NSAP-osoitteen osat:

IDP: Initial Domain Part, koostuu kentistä AFI ja IDI:

AFI: Authority and Format Identifier, ja

IDI: Initial Domain Identifier

DSP: Domain Specific Part

C.4.2. NSAP-osoitteen rakenne

C.4.2.1. Tässä Eurocontrol-standardissa osoitteen osat on rajoitettu seuraavaan muotoon.

C.4.2.2. AFI-kentän arvo tulee olla 48, joka ilmaisee, että IDI on paikallista muotoa ja noudattaa desimaalista abstraktia syntaksia.

C.4.2.3. IDI on nolla, paikallisen muodon mukaisesti.

C.4.2.4. DSP koostuu kahdesta desimaalinumeroparista, seuraavasti:

- ensimmäinen pari on lennonjohdon (ATC) yksikön tunniste, joka ilmaisee ATC-järjestelmän ja siten epäsuorasti sijainnin,

- toinen pari on ATC-yksikön valitsin, jota voidaan käyttää tietyn päätepisteen yksilöintiin ATC-yksikön sisällä.

C.4.2.5.

>TAULUKON PAIKKA>

C.4.3. ATC-yksikön tunnisteiden ja valitsimien määrittäminen

C.4.3.1. Erilaisten ATC-yksikkötunnisteiden määrittäminen jokaiselle ATC-järjestelmälle on Eurocontrolin tehtävä, kun taas ATC-yksikön valitsimet määrittää asiaankuuluva viranomainen ATC:n hallinnossa tai organisaatiossa.

C.4.3.2. Tämän standardin valmisteluajankohtana käytössä olleet ATC-yksikkötunnisteet on esitetty liitteessä G.

C.5. Protokollan määrittely

C.5.1. Yleiskatsaus

Protokolla perustuu dokumentin ISO/IEC 8878 [viite 12] liitteessä A määriteltyyn X.25:n (1980) protokollaan Subnetwork-Dependent Convergence Protocol, seuraavilla eroilla:

- käyttäjän Fast Select -toiminto ei ole käytössä; ISO/IEC 8878:n [viite 12] liitteessä A on kuitenkin määritelty koodaus käytettäväksi laajennetussa käyttäjän tietokentässä, joka on saatavana Fast Select -toiminnon yhteydessä. Tätä koodausta käytetään tässä yhteydessä perusmuotoisessa käyttäjän tietokentässä paketeissa CALL REQUEST ja INCOMING CALL, koska sallittujen verkkopalveluparametrien rajoitukset varmistavat, että koodattu tieto mahtuu 16 oktettiin,

- verkkopalveluparametreistä, joille on määritetty koodaukset ISO/IEC 8878:ssa [viite 12], ainoastaan kutsutut ja kutsuvat NSAP-osoitteet (ja ainoastaan kohdassa määritellyssä muodossa) lähetetään CALL REQUEST-paketissa,

- käyttäjän tietokenttää ei käytetä paketeissa CALL ACCEPTED, CALL CONNECTED, CLEAR REQUEST tai CLEAR INDICATION,

- vaihtoehtoisia toimenpiteitä verkkoyhteyden luomiseksi tai purkamiseksi ei käytetä,

- vastaanoton vahvistamista D-bitin avulla ei tueta.

HUOM.

Ensimmäiset kolme näistä rajoituksista varmistavat, että kaikki kahden DTE:n välillä välitettävä informaatio mukautuu käyttäjän tietokentän rajoituksiin X.25:n (1980) PLP-protokollassa.

C.5.2. Osoitteen koodaus

Kutsuvat ja kutsutut NSAP-osoitteet koodataan halutulla binäärikoodilla, joka on määritelty ISO/IEC 8348:n liitteessä A [viite 10].

C.5.3. Käyttäjän tietokentän koodaus

C.5.3.1. Yllämainittujen vaatimusten seurauksena pakettien CALL REQUEST ja INCOMING CALL käyttäjän tietokenttä tulee koodata alla kuvatun mukaisesti. Kaikki 16 oktettia lähetetään.

Taulukko 1

Käyttäjän tietokentän koodaus

>TAULUKON PAIKKA>

C.5.3.2. Muita ISO/IEC 8878:ssa [Viite 12] kuvattuja parametrejä ei tule käyttää.

C.5.4. Osoitteiden käsittely INCOMING CALL -paketeissa

C.5.4.1. DTE-osoitteet

INCOMING CALL -paketin kutsuva DTE-osoite validoidaan suhteessa järjestelmän voimassaolevaan DTE-etäosoitteiden paikalliseen luetteloon. Jos havaitaan kelvoton osoite, kutsu puretaan.

HUOM.

1. Jos kutsuttu DTE-osoite on mukana INCOMING CALL -paketissa, se voidaan vaihtoehtoisesti validoida suhteessa järjestelmän voimassaolevien paikallisten DTE-osoitteiden luetteloon (joka tyypillisesti koostuu vain yhdestä alkiosta).

2. Joissakin tapauksissa yksikön DTE-osoite saattaa poiketa arvoltaan ja/tai pituudeltaan yksikön ollessa kutsuvana tai kutsuttuna järjestelmänä. Siksi tähän asiaan täytyy kiinnittää huomiota määriteltäessä tai toteutettaessa DTE-osoitteen validointitoimintoa.

C.5.4.2. NSAP-osoitteet

INCOMING CALL -paketissa edellä kuvatulla tavalla koodattu kutsuva NSAP-osoite validoidaan suhteessa järjestelmän voimassaolevaan NSAP-etäosoitteiden paikalliseen luetteloon. Jos havaitaan kelvoton osoite, kutsu puretaan.

HUOM.

Kutsuttu NSAP-osoite voidaan vaihtoehtoisesti validoida myös suhteessa järjestelmän voimassaolevien paikallisten NSAP-osoitteiden luetteloon (koostuu tyypillisesti yhdestä alkiosta).

C.5.5. Tiedonsiirto

C.5.5.1. Kuten ISO/IEC 8878:n liitteessä A.5.3 [viite 12] on kuvattu, NSDU:t siirretään DATA-paketin käyttäjän tietokentässä.

HUOM.

Tämän seurauksena on kiellettyä lähettää enempää kuin yksi käyttäjän sanoma, kuten OLDI-sanoma, yhtä X.25-pakettia tai M-bittijonoa kohden.

C.5.5.2. NSDU:t, jotka ovat pidempiä kuin virtuaalipiirin suurin sallittu käyttäjän tieto, pilkotaan ja lähetetään DATA-pakettijonon käyttäjän tietokentissä, missä kaikilla muilla paitsi viimeisellä on maksimaalinen pituus ja M-bitti asetettuna (eli More-bittijono).

C.5.5.3. Vastaanotossa More-bittijonon käyttäjätietokentät kootaan uudelleen, jotta voidaan muodostaa vastaanotettu NSDU.

LIITE D (Normatiivinen)

PROFIILIKOHTAISET PICS-LOMAKKEET

D.1. Johdanto

D.1.1. Jotta protokollatoteutusta voidaan kutsua liitteiden A-C määritysten mukaiseksi, sen toimittajan tulee täyttää seuraavat PICS-lomakkeet.HUOM.

PICS-lomakkeiden tekijänoikeudet: tämän Eurocontrol-standardin käyttäjät saavat vapaasti kopioida tämän liitteen PICS-lomakkeita käytettäväksi aiottuun tarkoitukseen sekä julkaistavaksi valmiina.

D.1.2. Valmis PICS-lomake on kyseessä olevan toteutuksen PICS. PICS on selvitys siitä, mitkä protokollan ominaisuudet ja vaihtoehdot on toteutettu.

D.1.3. PICS:llä voi olla esimerkiksi seuraavanlaisia käyttötarkoituksia:

- yleisesityksenä ja tarkistuslistana se auttaa protokollan toteuttajaa välttämään epäjohdonmukaisuuksia toteutuksessa,

- toteutuksen toimittaja ja hankkija, tai mahdollinen hankkija voivat käyttää sitä yksityiskohtaisena esityksenä toteutuksen ominaisuuksista, joiden sisältö tulkitaan standardinmukaisen PICS-lomakkeen käytön ansiosta yhteisellä tavalla,

- toteutuksen käyttäjä tai mahdollien käyttäjä voi pitää sitä perustana tarkastaessaan alustavasti toteutuksen yhteentoimivuutta muiden toteutusten kanssa (on huomioitava, että vaikka yhteentoimivuutta ei voida koskaan taata, yhteensopimattomuus voidaan usein ennustaa yhteensopimattomista PICS:istä),

- protokollan testaaja voi käyttää sitä perustana valitessaan sopivia testejä toteutuksen väitetyn yhteensopivuuden arvioimiseksi.

D.2. Ohjeita PICS-lomakkeiden täyttämiseen

D.2.1. PICS-lomakkeiden yleinen rakenne

D.2.1.1. Toteutuksen yksilöinti ja protokollan yhteenveto ovat ensimmäinen osa jokaista PICS-lomaketta. Lomake tulee täyttää ohjeen mukaisesti vaadittavilla tiedoilla, joiden avulla voidaan selvästi yksilöidä sekä toimittaja että toteutus.

D.2.1.2. PICS-lomakkeen pääosan muodostaa kiinteämuotoinen kysely. Kyselyn kohtiin vastataan oikeanpuoleisimpaan sarakkeeseen, joko niin, että vastaukseksi merkitään valinta annettujen vaihtoehtojen joukosta (yleensä kyllä tai ei), tai niin, että annetaan arvo, joukko arvoja tai arvoväli.HUOM.

1. Jokaisen kohdan yksilöi osioviite ensimmäisessä sarakkeessa; toinen sarake sisältää vastausta vaativan kysymyksen; kolmas sarake sisältää viitteen tai viitteet materiaaliin, joka määrittelee kohdan tässä Eurocontrol-standardissa. Jäljellä olevat sarakkeet ilmaisevat kohdan statuksen (onko tuki pakollista, valinnaista, kiellettyä tai ehdollista) ja tarjoavat tilan vastauksille: katso myös jäljempänä kohta D.2.4.

2. Toimittaja voi myös tarjota, tai hänen voidaan vaatia tarjoavan, ylimääräistä informaatiota, joka luokitellaan joko lisätiedoiksi tai poikkeustiedoiksi. Tällaiset tiedot tulee ristiviittauksia varten ilmaista merkinnällä A< i > tai X< i > varustettuina alakohtina (A lisätiedoille ja X poikkeustiedoille). Tässä < i > on jokin yksiselitteinen kohdan tunniste (esimerkiksi vain numero): sen muodon tai esitystavan suhteen ei ole muita rajoituksia.

D.2.1.3. Valmista PICS-lomaketta, johon luetaan kuuluviksi myös mahdolliset lisätiedot ja poikkeustiedot, pidetään vakuutuksena kyseisen protokollatoteutuksen vaatimustenmukaisuudesta. HUOM.

Jos toteutus voidaan konfiguroida useammalla kuin yhdellä tavalla, yksi PICS saattaa pystyä kuvaamaan kaikkia tällaisia konfiguraatioita. Toimittajalla on kuitenkin mahdollisuus toimittaa useampi kuin yksi PICS, joista jokainen kattaa jonkin konfiguraatiovaihtoehdon ominaisuudet, jos se selkeyttää ja helpottaa informaation esittämistä.

D.2.2. Lisätiedot

Lisätietokohdat antavat toimittajalle mahdollisuuden tarjota lisätietoa auttamaan PICS:n tulkinnassa.HUOM.

1. Perusajatuksena on, että lisätietoja ei yleensä tarvitse paljoakaan esittää ja että PICS on kattava ilmankin tällaisia tietoja. Lisätietona voidaan esimerkiksi esittää kuvaus kokonaisuuden toteuttamisesta eri ympäristöissä ja konfiguraatioissa, tai lyhyt perustelu (joka pohjautuu esimerkiksi erityisiin sovellustarpeisiin) joidenkin sellaisten ominaisuuksien poisjättämiselle, jotka valinnaisuudestaan huolimatta ovat yleisiä tämän protokollan toteutuksissa.

2. Viittauksia lisätietokohtiin voidaan merkitä minkä tahansa vastauksen yhteyteen, ja niitä voidaan sisällyttää myös poikkeustietoihin.

D.2.3. Poikkeustiedot

D.2.3.1. Joskus saattaa käydä niin, että toimittaja haluaa vastata pakollisella tai kielletyllä statuksella varustettuun kohtaan (mahdollisten ehtojen soveltamisen jälkeen) tavalla, joka on ristiriidassa ilmoitetun vaatimuksen kanssa. Tuki-sarakkeesta ei löydy valmista vastausta, joten toimittaja kirjoittaa puuttuvan vastauksen Tuki-sarakkeeseen yhdessä poikkeustietokohdan viitteen X< i > kanssa.

D.2.3.2. Toimittaja laatii poikkeustietokohdassa esiintyvät perustelut itse.

D.2.3.3. Toteutus, joka vaatii tällaisen poikkeustietokohdan ei ole tämän standardin mukainen.HUOM.

Mahdollinen syy yllä kuvattuun tilanteeseen on, että standardissa on raportoitu virhe, jonka korjauksen odotetaan tuovan muutoksen siihen vaatimukseen, jota toteutus ei täytä.

D.2.4. Ehdolliset osiot

D.2.4.1. Yksittäiset ehdolliset osiot on ilmaistu Status-sarakkeessa muotoa "< osio >: < s >" olevalla ehdollisella symbolilla, jossa "< osio >" on osioviite, joka esiintyy taulukon jonkin toisen osion ensimmäisessä sarakkeessa ja "< s >" on statuksen symboli, M, O, O.< n > tai X.HUOM.

PICS-lomake saattaa sisältää useita ehdollisia osioita. Nämä ovat osioita, joille sekä osion sovellettavuus sinänsä että tarpeen vaatiessa sen status (pakollinen, valinnainen tai kielletty) riippuvat siitä, tuetaanko tiettyjä muita osioita vai ei.

D.2.4.2. Jos osio, johon viitataan ehdollisella symbolilla, on merkitty tuetuksi, niin ehdollinen osio on voimassa ja sen statuksen ilmaisee "< s >"-merkintä: tukisarake tulee täyttää tavalliseen tapaan. Muussa tapauksessa ehdollinen osio ei ole relevantti ja vastauskohtaan merkitään Ei sovelleta (NA, Not Applicable).

D.2.4.3. Jokaisen sellaisen osion, jonka viitettä käytetään ehdollisessa symbolissa, Osio-sarakkeessa on asteriski-merkki.

D.3. Sanomanvälitysprotokollan PICS-lomake

D.3.1. Lyhenteet ja erikoissymbolit

D.3.1.1. Statuksen ilmaisevat tunnukset

M Pakollinen

O Valinnainen

D.3.1.2. Osion viitteet

PICS-lomakkeen osiot merkitään muistiteknisin osioviittein. PICS-osiot, jotka koskevat toisiinsa liittyviä toimintoja merkitään osioviitteillä, joissa on sama alkukirjain tai kirjainpari (suurin kirjaimin). Alla on luettelo näistä alkukirjaimista siinä järjestyksessä kuin osioryhmät esiintyvät PICS-lomakkeessa.

>TAULUKON PAIKKA>

D.3.2. Tunnistus

>PIC FILE= "L_2000254FI.020301.EPS">

D.3.3. Protokollan toteutus

>PIC FILE= "L_2000254FI.020401.EPS">

D.4. Sanoman otsikkoprotokollan PICS-lomake

D.4.1. Lyhenteet ja erikoissymbolit

D.4.1.1. Statuksen tunnukset

M pakollinen

O valinnainen

O.< n > valinnainen, mutta vaaditaan tuki ainakin yhdelle vaihtoehdoista, joilla on sama numero < n >

X kielletty

< osio >: ehdollisen osion symboli, riippuvainen osiolle < osio > merkitystä tuesta (katso D.2.4)

D.4.1.2. Lyhenteet

NA ei sovelleta (not applicable)

D.4.1.3. Osioviitteet

>TAULUKON PAIKKA>

D.4.2. Yksilöinti

>PIC FILE= "L_2000254FI.020501.EPS">

D.4.3. Protokollan toteutus

>PIC FILE= "L_2000254FI.020601.EPS">

D.5. Verkkoprotokollan PICS-lomake

D.5.1. Lyhenteet ja erikoistunnukset

D.5.1.1. Statuksen ilmaisevat tunnukset

M pakollinen

O valinnainen

D.5.1.2. Osioviitteet

>TAULUKON PAIKKA>

D.5.2. Yksilöinti

>PIC FILE= "L_2000254FI.020701.EPS">

D.5.3. Protokollan toteutu

>PIC FILE= "L_2000254FI.020702.EPS">

LIITE E (Normatiivinen)

PROFIILIVAATIMUSLUETTELO

E.1. Johdanto

E.1.1. Tämä liite sisältää tässä Eurocontrol-standardissa määritellyn lentotietojen siirron rajapinnanhallintaprofiilin (FDE ICD -profiilin) profiilivaatimusluettelon (PRL:n). Tätä profiilia vastaavaksi väitetyn toteutuksen vastaavuusvakuutuksen tulee olla laadittu alla mainittujen ohjeiden mukaisesti.HUOM.

Tämän liitteen lomakkeet perustuvat standardin viitteenä olevien perusstandardien liitteissä oleviin lomakkeisiin.

E.1.2. Vaatimustenmukaisen toteutuksen tulee täyttää niiden perusstandardien pakolliset standardinmukaisuusvaatimukset, joihin tässä profiilissa viitataan.

E.2. PRL- ja PICS-lomakkeiden tehtävä

Tämän kohdan (E.2) status on informatiivinen: se ei siis ole tämän Eurocontrol-standardin osan varsinainen lauseke.

- Vastaavuusvaatimusten esittämisellä PRL- ja PICS- lomakkeiden taulukkomuodossa pyritään luomaan tarkistuslista niistä ominaisuuksista, jotka täytyy tai voidaan toteuttaa. Tämän perusteena olevat käsitteet on määritetty ja kuvattu dokumenteissa ISO/IEC 9646-1 [viite 14] (vastaa ITU-T:n suositusta X.290) ja ISO/IEC TR 10000-1 [viite 2].

- Profiiliin kootaan ja valitaan kohtia useista perusstandardeista tiettyä tietojenkäsittelytehtävää varten. Jokaisella perusstandardilla on oma PICS-lomake, johon on luetteloitu standardin vaatimukset. PRL sisältää profiilien ja tiettyjen profiilivaatimusten määrittämän joukon perusstandardien PICS-lomakeosioita. PRL:ssä määritellään sellaiset perusstandardien PICS-lomakkeiden vastaukset, joita profiili edellyttää. Lisäksi PRL sisältää PICS-tyyppisiä osioita, jotka ovat profiilikohtaisia (mukana on ainakin osio, jossa testataan onko kaikki vaaditut PICS-lomakkeet asianmukaisesti täytetty). Nämä osiot tulee täyttää yhdessä perusstandardien PICS-lomakkeiden kanssa. Valmiit lomakkeet yhdessä muodostavat profiilille toteutuksen vastaavuusvakuutuksen (Implementation Conformance Statement, ICS).

- ISO/IEC TR 10000-1:n [Viite 2] metodologian mukaisesti profiilin vaatimusten täyttymistä koskevan väittämän tueksi on esitettävä PRL:n mukaiset PICS-lomakkeet. Tämän materiaalin myöhempi käyttö riippuu FDE ICD -toteutuksen teettämisessä sovellettavasta lähestymistavasta.

- Lentotietojen siirjärjestelmän toteuttamisessa voidaan soveltaa useaa eri lähestymistapaa:

- Kansallisen hallintoelimen tai organisaation sisäinen toteutus: PRL:ää tulisi käyttää toteutuksen perusvaatimusten ja hyväksymistestin määrittelyn pohjana; toteutuksen valmis vastaavuusvakuutus tulisi antaa osana hyväksymismenettelyä.

- Profiilin toteutuksen teettäminen alihankkijalla: materiaalia käytetään ja tuotetaan kuten sisäiseen toteutukseenkin, mutta sopimuksessa on erikseen edellytettävä, että toteuttaja laatii vastaavuusvakuutuksen.

- Profiilin toteutuksen teettääminen alihankkijalla osana valmisjärjestelmää tai järjestelmän integrointiurakkaa: materiaalia käytetään ja tuotetaan kuten sisäiseen toteutukseenkin, mutta alihankkijan täytyy tehdä tämä sisäisesti sekä laatia toteutuksen vastaavuusvakuutus. Yhdenmukaisuus profiilin kanssa varmistaa muun muassa sen, että kahden hallinnon alaisena työskentelevä alihankkija ei voi toteuttaa lentotietojen siirron vaatimuksia omilla protokollillaan. Näin sopimuksen tehneet hallinnot pystyvät paremmin hallitsemaan kokonaisuutta.

- Valmiina hankittavien tuotteiden integroiminen profiilin toteutukseen jossain aikaisemmin mainituista tapauksista: tuotteen toimittajaa tulisi vaatia tuottamaan tuotteen kannalta oleelliset PICS-lomakkeet tässä kuvatun PRL:n mukaisesti, sekä takaamaan, että tuote vastaa käytettyjä profiilivaatimuksia; nämä PICS:t voidaan tämän jälkeen esittää osana profiilin vastaavuusvakuutusta.

- Toteutuksen käyttöönoton jälkeen ICS tulisi säilyttää osana toteutuksen dokumentaatiota; sen avulla voidaan ennakoida yhteentoimivuutta muiden hallinnollisten yksiköiden kanssa ja tunnistaa muutoksia, joita vaaditaan siirryttäessä eri protokolliin.

E.3. Merkinnät

E.3.1. Seuraavia ISO/IEC TR 10000-1:n merkintöjä [Viite 2] käytetään PRL:ssä ilmaisemaan ominaisuuksien statusta:

m: pakollinen

o: valinnainen

-: ei sovelleta (eli loogisesti mahdoton profiilin puitteissa)

x: ei käytetä

HUOM.

1. Kaksimerkkisiä yhdistelmiä voidaan käyttää, jolloin ensimmäinen merkki viittaa staattiseen (toteutuksen) statukseen ja toinen dynaamiseen statukseen (käyttöön); jolloin "mo" tarkoittaa "toteuttaminen pakollista, käyttö valinnaista".

2. Merkintää "o.< n >" käytetään ilmaisemaan joukkoa valittavia vaihtoehtoja (vähintään yksi joukosta tulee toteuttaa), joilla on sama tunniste n.

3. Ominaisuus, joka on merkitty merkinnällä "x" saattaa olla osa toteutusta, kunhan sitä ei käytetä silloin, kun toteutus toimii profiilin mukaisesti.

4. Merkinnällä "x" varustettujen ominaisuuksien käyttö edellyttäisi kahdenkeskistä sopimusta osapuolten välillä. Tässä tapauksessa ominaisuuksien status tulisi määrittää uudelleen, koska niillä saattaa olla merkitystä muiden toteutusten kannalta.

E.3.2. Seuraavaa riippuvaisuusmerkintää (predicate) käytetään:

< predicate >:: esittelee ryhmän osioita, jotka kaikki ovat sidoksissa mainittuun riippuvuusehtoon (< predicate >) (layout ilmaisee ryhmän laajuuden).

< predicate >: esittelee yhden osion, joka on sidoksissa mainittuun riippuvuusehtoon (< predicate >).

HUOM.

Kummassakin tapauksessa riippuvuusehto saattaa olla profiilin ominaisuuden tunniste tai riippuvuusehtojen looginen (Boolen) lauseke ("¬" on loogisen negaation symboli).

E.3.3. Perusstandardin vaatimukset esitetään vastaavilla merkinnöillä, mutta isoilla kirjaimilla (esim. M, O, O.< n >, X).

E.4. PICS-lomakkeiden täyttöohjeet

E.4.1. Profiilin ICS:ää varten tulee täyttää viitteenä olevien perusstandardien PICS-lomakkeet sekä tässä liitteessä esitetyt profiilikohtaiset PICS-lisäosiot.

E.4.2. Niiltä osin kuin tämä profiili tarkentaa perusstandardien vaatimuksia, tulee tämän PRL:n vaatimuksia käyttää (kuten PRL-osioiden sarakkeessa "Profiilin ominaisuudet" todetaan) rajoittamaan perusstandardien PICS-lomakkeissa sallittuja vastauksia.

E.4.3. Jos tässä profiilissa esitetään lisävaatimuksia, tulee myös niitä koskevien osioiden vastaussarake täyttää. Tämän sarakkeen kukin vastaus joko valitaan annettujen vastausten joukosta tai se muodostuu parametrin arvosta, arvoista tai arvovälistä, sen mukaan mitä kulloinkin edellytetään.

E.4.4. Jos tietty pakollinen vaatimus ei täyty, tulee tästä esittää poikkeustieto lisäämällä viite X< i >, jossa < i > on yksikäsitteinen tunniste, joka viittaa oheistettaviin perusteluihin vastaavuuden puuttumiselle.HUOM.

Mahdollinen syy tällaiseen poikkeukseen on vastaavuus profiilia koskevan, vielä käsittelyssä olevan virheraportin kanssa; jos virheraportti hyväksytään, on toteutus tämän jälkeen vaatimustenmukainen.

E.5. Viitteet

E.5.1. Tässä profiilissa viitataan seuraaviin protokollamääritelmiin:

- Sanomanvälitysprotokolla (tämän Eurocontrol-standardin liite A);

- Sanoman otsikkoprotokolla (tämän Eurocontrol-standardin liite B);

- Yhteydellinen verkkoprotokolla, joka käyttää ISO/IEC 8208:aa (tämän Eurocontrol-standardin liite C);

- ISO/IEC 7776 [viite 6];

- ITU-T:n suosituksen X.25 (1993) lausekkeessa 1 [viite 1] tarkoitetut fyysisen kerroksen standardit.

E.5.2. Koska asiaanliittyvillä fyysisen kerroksen normeilla ei ole erityisiä PICS-lomakkeita, tulee käyttää ISO/IEC ISP 10609-9 lausekkeen A.4 [viite 8] fyysisen kerroksen väliaikaisia PICS-lomakkeita.

E.6. Vastaavuusvakuutus

E.6.1. Vaatimustenmukaisuuden yleiskuvaus

>PIC FILE= "L_2000254FI.021101.EPS">

E.6.2. Dynaamiset vastaavuusvaatimukset

>PIC FILE= "L_2000254FI.021201.EPS">

E.7. Ylemmän kerroksen vaatimukset

Taulukko 3

Sanomanvälitysprotokolla

>TAULUKON PAIKKA>

E.8. Alemman kerroksen vaatimukset

E.8.1. Siirtokerroksen vaatimukset

Taulukko 4

Sanoman otsikkoprotokolla

>TAULUKON PAIKKA>

E.8.2. Verkkokerroksen vaatimukset

Tässä jaksossa annetut PRL:t perustuvat ISO/IEC 8208:1993:n [Viite 7] PICS-lomakkeeseen. Seuraavissa taulukoissa otsikon "Perusstandardin ominaisuudet" alla olevan "Viitteet"-sarakkeen tiedot ovat viitteitä mainitun standardin kohtiin.

E.8.2.1. Yleiset DTE-ominaisuudet

Taulukko 5

Yleiset DTE-ominaisuudet

>TAULUKON PAIKKA>

E.8.2.2. Proseduurit, pakettityypit ja pakettimuodot

Taulukko 6

Loogisista kanavista riippumattomat pakettikerroksen toiminnot

>TAULUKON PAIKKA>

Taulukko 7

Kutsun asetukset

>TAULUKON PAIKKA>

Taulukko 8

Kutsun purku

>TAULUKON PAIKKA>

Taulukko 9

Loogisten kanavien uudelleenasettaminen

>TAULUKON PAIKKA>

Taulukko 10

Virheproseduurit

>TAULUKON PAIKKA>

Taulukko 11

Siirron keskeytys

>TAULUKON PAIKKA>

Taulukko 12

Tiedon lähettäminen

>TAULUKON PAIKKA>

Taulukko 13

Tiedon vastaanottaminen

>TAULUKON PAIKKA>

Taulukko 14

Toimituksen vahvistaminen

>TAULUKON PAIKKA>

E.8.2.3. Sekalaiset ominaisuudet ja vaihtoehdot

Taulukko 15

Syykoodien ja diagnostisten koodien arvot

>TAULUKON PAIKKA>

E.8.2.4. Toiminnot

Taulukko 16

CALL REQUEST -paketeissa lähetetyt toiminnot

>TAULUKON PAIKKA>

Taulukko 17

CALL ACCEPT -paketeissa lähetetyt toiminnot

>TAULUKON PAIKKA>

Taulukko 18

CLEAR REQUEST -paketeissa lähetetyt toiminnot

>TAULUKON PAIKKA>

Taulukko 19

INCOMING CALL -paketeissa vastaanotetut toiminnot

>TAULUKON PAIKKA>

Taulukko 20

CALL CONNECTED -paketeissa vastaanotetut toiminnot

>TAULUKON PAIKKA>

Taulukko 21

CLEAR INDICATION -paketeissa vastaanotetut toiminnot

>TAULUKON PAIKKA>

Taulukko 22

CLEAR CONFIRMATION -paketeissa vastaanotetut toiminnot

>TAULUKON PAIKKA>

E.8.2.5. Parametriarvot ja -alueet

Taulukko 23

Parametriarvot ja -alueet

>TAULUKON PAIKKA>

E.8.3. Siirtoyhteysvaatimukset

Tässä jaksossa annetut PRL:t perustuvat ISO/IEC 7776:1994:n [Viite 6] PICS-lomakkeeseen. Seuraavassa taulukossa otsikon "Perusstandardin ominaisuudet" alla olevan "Viitteet"-sarakkeen tiedot ovat viittauksia mainitun standardin lausekkeisiin.

Taulukko 24

Siirtoyhteysprotokolla

>TAULUKON PAIKKA>

E.8.4. Fyysisen kerroksen vaatimukset

Katso ISO/IEC TR 10609-9:n lauseke A.4 [Viite 8].

LIITE F (Informatiivinen)

VASTAAVUUDEN TESTAUSMENETELMÄT

F.1. Johdanto

F.1.1. On tärkeää, että tämän standardin mukaisesten toteutusten yhteistoiminta lennonjohtokeskusten (ATCC) välillä rajapinnan välityksellä on erittäin luotettavaa.

F.1.2. Rajapintojen toteuttamisesta tulevat jäsenvaltioissa todennäköisesti vastaamaan useat eri tahot. Jotta tällaisten toteutusten yhteentoimivuuteen voitaisiin luottaa, tarvitaan yhteiset yhdenmukaisuuteen liittyvät testivaatimukset testiin valmistautumisen, itse testin sekä tulosten esittämisen standardoimiseksi.

F.2. Päämäärä ja laajuus

F.2.1. Tämä liite on osa tätä Eurocontrol-standardia, ja siinä määritellään vaatimustenmukaisuuden testausvaatimukset standardin mukaisille toteutuksille.

F.2.2. Liitteessä määritellään mekanismeja, joilla voidaan testauksen kautta vahvistaa rajapintaa koskevan vastaavuusväittämän uskottavuutta. I

F.3. Kirjallisuutta

Seuraava asiakirja on merkityksellinen tämän Eurocontrol-standardin mukaisten toteutusten testaamisen kannalta:

Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) FDE ICD Osa 1 Integration Test Plan Versio 1.0, päivätty 10.5.199 [Reference 15].

F.4. Kehitysmenetelmät ja -käytännöt

F.4.1. ICD-asiakirjan mukaiset toteutukset voidaan aikaansaada käyttäen ICD-asiakirjassa annettuja eri vaihtoehtoja ja versioita. Rajapinnan toteuttavan jäsenvaltion täytyy yhteentoimivuuden kartoittamiseksi yksilöidä toimintakykyä kuvaavalla lausunnolla, mitä ICD-asiakirjan osia tuetaan ja mitä mahdollisia muuttuvien parametrien rajoituksia tuetaan.

F.4.2. Jokaisen toteutuksen tulisi läpikäydä jäljempänä kuvatun kaltainen vastaavuustesti.

F.5. Testit

F.5.1. Johdanto

F.5.1.1. Jotta lennonjohtokeskuksen (ATCC:n) lentotietojen siirron rajapintaan voidaan luottaa ja sitä voidaan tukea yhteistoiminnassa mukana olevien lentotietojen siirtosovellusten välillä, on hyvä, että jokaisen rajapinnan yhteensopivuus testataan niiden standardien mukaan, joihin tämäkin liite kuuluu. Tällainen testaaminen kohdistuu testattavana olevan järjestelmän ulkoiseen käyttäytymiseen, ja sen on tarkoituksena on varmistua pikemminkin yhteentoimivuudesta kuin tietyn loppujärjestelmän käyttökelpoisuudesta.

F.5.1.2. Tällaisten testien tuloksia voidaan käyttää tämän Eurocontrol-standardin osan luvun 5.1 mukaisten vastaavuusväittämien tukena. Tämän profiilimäärityksen edellyttämiä PICS-lomakkeita ja PRL:iä voidaan käyttää pohjana vastaavuustesteille. Lisäksi kansainvälisissä normeissa (esim. ISO/IEC 8208 viitteessä 7) saattaa jo olla määriteltynä ohjeellisia testiohjelmia, joita voidaan käyttää vaatimustenmukaisuuden testaamisessa.

F.5.1.3. Tämän asiakirjan tarkoituksena on luoda standardoituun testikokoelmaan perustuva standardoitu testausohjelma, jonka käytön tulisi johtaa testituloksien vertailukelpoisuuteen ja tällaisten testitulosten laajaan hyväksyntään minimoida edellytettyjen vastaavuustestien määrä. Tämä standardisoitu testiohjelma on osittain Eurocontrolin kehittämä.

F.5.1.4. Kuva 2 mukaisesti täydellisen loppujärjestelmän testaaminen koostuu kolmen alimman kerroksen testeistä. Suosituksena on, että testaaminen käsittää myös lentotietojen siirtoon liittyvien sovellus-, tila-, järjestelmä- ja operaattorisanomien testejä.

F.5.1.5. Jäjempänä kuvatut testit tulisi suorittaa annetussa järjestyksessä. Järjestyksessä myöhemmin tuleva testi onnistuu vain jos alemmat kerrokset toimivat oikein, mikä tulee todennäköisesti varmistettua aikaisemmissa testeissä.

F.5.1.6. Edellä esitetystä huolimatta tässä jaksossa kuvattu testaaminen on vapaaehtoista.

F.5.2. Alempien kerrosten testaus (Kerrokset 1-3)

Minkä tahansa ATCC:n ja sen vastapuolien välisen yhteistoimintavaatimuksen tukemiseksi on suositeltavaa, että kaikki testit perustuvat testisuunnitelmaan, joka on esitetty asiakirjassa Eurocontrol (Maastricht UAC Systems Division) FDE ICD Integration Test Plan. Testitoimenpiteistä tulisi sopia kahdenkeskisesti yhteistyötä tekevien ATCC-yksikköjen välillä.

F.5.3. Sovelluskerroksen testaus

Yhteistyötä tekevien ATCC-yksikköjen välillä tulisi suorittaa näiden keskenään sopima testisarja.

F.5.4. Sertifiointi

Yhteistyöosapuolten tulisi keskenään hyväksyä ja tallentaa testitulokset.

F.5.5. Ilmoittaminen

Jäsenvaltioidet tulisi toimittaa yksityiskohtaiset testitulokset Eurocontrolille.

LIITE G (Informatiivinen)

ATC-YKSIKKÖTUNNISTEIDEN MÄÄRITTÄMINEN

Seuraavassa taulukossa esitetään 22.4.1997 käytössä olleet ATC-yksikkötunnisteet. Tietoja tämänhetkisistä tunnisteista saa Eurocontrolista. Taulukossa nähdään myös tunnisteiden binäärikoodit heksadesimaalisina eli osana NSAP-osoitteen koodausta siten kuin liitteessä C on määritelty.

Taulukko 1

ATC-yksikkötunnisteet

>TAULUKON PAIKKA>

LIITE H (Informatiivinen)

OHJEITA LUOTETTAVUUDESTA, SAATAVUUDESTA JA TURVALLISUUDESTA

H.1. Johdanto

On oletettavissa, että ATC-sovelluksissa, kuten OLDIssa, hyödynnetäät yhteenliitettyjä X.25-verkkoja ja/tai yleisiä tai yksityisiä televerkkoja. Tästä syystä katsotaan olevan tarpeen antaa ohjeita FDE ICD Osan 1 toteutuksiin.

H.2. Päämäärä ja laajuus

H.2.1. Tämän liitteen tavoitteena on antaa luotettavuuteen, saatavuuteen ja turvallisuuteen liittyviä ohjeita.

H.2.2. Tämä liite kattaa kaksi tilannetta. Ensimmäisessä on kyse pisteestä-pisteeseen yhteydestä vuokratun (kiinteän) yhteyden välityksellä. Toinen perustuu yhteenliitettyihin X.25-verkkoihin.HUOM.

Jälkimmäisessä tilanteessa ei oteta huomioon X25-verkkojen yhteenliittämiseen liittyviä seikkoja.

H.2.3. Tilanteissa oletetaan, että toteutukset on fyysisesti suojattu väärinkäyttöä, virtakatkoja ja muita normaaliin toimintaan mahdollisesti vaikuttavia uhkia vastaan.

H.3. Kirjallisuutta

Tässä liitteessä luodaan yleiskatsaus seuraavaan yksityiskohtaisen teknisen analyysin sisältävään asiakirjaan:

Eurocontrol FDE ICD Part 1: Reliability, Availability and Security - Technical Report [Viite 16].

H.4. Vuokrayhteyttä käyttävät toteutukset

H.4.1. Luotettavuus

Palvelun luotettavuuden parantamiseksi vuokrajohdon, yleisen puhelinverkon johtojen ja ISDN-verkon kaapelien tulee fyysisesti seurata eri reittejä ja olla kytkettyinä teleoperaattorin eri kytkimiin (tätä on erikseen edellytettävä teleoperaattorilta).

H.4.2. Saatavuus

H.4.2.1. Koska yleisen puhelinverkon yhteydenmuodostusajat ovat pitkiä eikä se näin ollen sovi sovelluksille, joissa aika on kriittinen tekijä, varmistusvälineenä tulisi käyttää ISDN-yhteyttä.

H.4.2.2. DTE:n vaihtuessa valmiustilassa olevan DTE:n tulisi luoda DISC-kehys yhteyden uudelleenluonnin nopeuttamiseksi.

H.4.3. Turvallisuus

H.4.3.1. Kun käytetään ISDN:ää varmistusvälineenä, kutsutun ISDN-päätesovittimen (TA:n) tulisi validoida kutsujan E.164-osoite [viite 18].

H.4.3.2. Kutsuvan DTE:n tulisi olla ITU-T:n suosituksen X.32 [viite 17] mukainen ja sisällyttää kutsujan tunniste- ja autentisointitiedot.

H.4.4. Esimerkki laitteistokokonaisuudesta

Kuva H.1

Vuokrayhteyttä käyttävä konfigurointiesimerkki

>PIC FILE= "L_2000254FI.023301.EPS">

H.5. Verkkototeutus

H.5.1. Luotettavuus

Palvelun luotettavuuden lisäämiseksi tietyn kohteen isäntäkoneet tulisi olla kytketty kahteen DCE:hen, jotka liittyvät eri verkkokytkimiin (tämä vaatimus tulisi välittää verkko-operaattorille).

H.5.2. Saatavuus

H.5.2.1. Hakuryhmätoimintoa (hunt group facility) tulisi käyttää, jotta tietyssä kohteessa sijaitseville DCE:lle voitaisiin määrittää yksi tietty X.121-osoite [viite 20], ja näin optimoida verkkoreititys ja vähentää epäonnistuneita kutsuja.

H.5.2.2. Jos käyttöön otetaan muita kutsumekanismeja, joiden seurauksena paketeissa CALL REQUEST ja CALL ACCEPT on erilainen kutsuttu DTE-osoitearvo, tulisi kutsuva DTE konfiguroida niin, ettei tällä ole vaikutusta yhteydenmuodostukseen.

H.5.2.3. Jos DCE:n yhteys katkeaa verkkovian vuoksi ja käytettävissä on toinen yhteys verkkoon, kutsuyhteyden uudelleenluonti tulisi suoritttaa tämän toisen yhteyden kautta.

H.5.3. Turvallisuus

Suljetun käyttäjäryhmän (CUG) toiminto on ainoa tämän liitteen puitteissa käytettävissä oleva verkkotoiminto.

H.6. Yleisiä ohjeita vuokrayhteyksien ja verkkojen toteuttamisesta

H.6.1. Luotettavuus

H.6.1.1. Koska täydellinen isäntäkoneen vaihto voi kestää kauan, kannattaa harkita edustasuorittimen (FEP) käyttöä isäntäkoneen vikatilanteiden varalta.

H.6.1.2. FEP:iin perustuva rakenne voi lisätä palvelun luotettavuutta.HUOM.

Tulevaisuudessa laadittavassa FDE ICD -standardin osassa 2 saatetaan profiilimääritykseen sisällyttää myös siirtopino.

H.6.2. Saatavuus

Jos kutsu epäonnistuu, kutsuvan kohteen tulisi uusia kutsu käyttäen toista X.121-osoitetta (jos käytettävissä).

H.6.3. Järjestelmän hallinta

H.6.3.1. Mahdollisuuksien mukaan tulisi käyttää kytkimiä, jotka ohjautuvat automaattisesti rajapintasignaalien avulla.

H.6.3.2. Tiedonsiirron aikaista paikallista virheilmoitusta voidaan käyttää isäntäkoneen vaihdon laukaisijana.

H.6.3.3. FEP:n vaihtumisen tulisi generoida TC-Disconnect, jotta varmistutaan, että paikallinen isäntäkone on IDLE-tilassa.

H.6.3.4. X.25-verkkokerroksen tai tiedonsiirtokerroksen ajastimien lauetessa tulisi ylempien kerrosten purkautua.

H.6.3.5. FEP:n täydellisen toimintakatkoksen tulisi generoida TC-Disconnect.

H.6.3.6. Hallintajärjestelmän tulisi suorittaa kyselyjä sanomanvälityksen protokollakerroksessa (liite A) ja tarkistaa tilakone erottaakseen sanomanvälitysprotokollan virheen ja sovellusvirheen toisistaan.

H.6.4. Esimerkki laitteistokokonaisuudesta

Kuva H.2

Esimerkki verkon laitteistokokonaisuudesta

>PIC FILE= "L_2000254FI.023401.EPS">