32000R2082

Regulamento (CE) n.o 2082/2000 da Comissão

de 6 de Setembro de 2000

que adopta normas Eurocontrol e altera a Directiva 97/15/CE que adopta as normas Eurocontrol e altera a Directiva 93/65/CEE do Conselho

A COMISSÃO DAS COMUNIDADES EUROPEIAS,

Tendo em conta o Tratado que institui a Comunidade Europeia,

Tendo em conta a Directiva 93/65/CEE do Conselho, de 19 de Julho de 1993, relativa à definição e à utilização de especificações técnicas compatíveis com a aquisição de equipamentos e de sistemas para a gestão de tráfego aéreo(1) e, nomeadamente, o seu artigo 3.o,

Tendo em conta a Directiva 97/15/CE da Comissão, de 25 de Março de 1997, que adopta as normas Eurocontrol e altera a Directiva 93/65/CEE do Conselho relativa à definição e à utilização de especificações técnicas compatíveis para a aquisição de equipamentos e de sistemas para a gestão do tráfego aéreo(2),

Considerando o seguinte:

(1) A Directiva 97/15/CE adoptou a norma Eurocontrol para o intercâmbio de informação em tempo real (OLDI), edição 1.0, e a norma Eurocontrol para a apresentação do intercâmbio de informação dos serviços de tráfego aéreo (ADEXP), edição 1.0.

(2) Eurocontrol adoptou versões mais recentes das duas normas acima mencionadas, ou seja, OLDI edição 2.2 e ADEXP edição 2.0 e também uma nova norma Eurocontrol intitulada intercâmbio de informação de voo - documento de controlo do interface (FDE-ICD).

(3) Essas normas Eurocontrol integram o âmbito de aplicação da Directiva 93/65/CEE e contribuem para a harmonização dos sistemas nacionais de gestão do tráfego aéreo pelos Estados-Membros, especialmente no que diz respeito à transferência de voos entre os centros de controlo de tráfego aéreo (OLDI), a gestão do fluxo de tráfego aéreo (ADEXP) e as comunicações entre sistemas nacionais (FDE-ICD).

(4) As edições 2.2 da OLDI e 2.0 da ADEXP substituem edições anteriores actualmente em vigor de acordo com as disposições do artigo 1.o da Directiva 97/15/CE e; portanto; esse artigo foi revogado.

(5) As disposições do presente regulamento estão de acordo com o parecer do comité instituído pela Directiva 93/65/CEE,

ADOPTOU O PRESENTE REGULAMENTO:

Artigo 1.o

Na medida em que sejam necessárias para a implementação de um sistema integrado europeu de gestão do tráfego aéreo, os elementos obrigatórios das especificações Eurocontrol incluídas nas normas Eurocontrol a seguir indicadas são adoptados no âmbito da Directiva 93/65/CEE:

- a norma Eurocontrol para o intercâmbio de informação em tempo real (OLDI), edição 2.2 (referência do documento do Eurocontrol DPS.ET1.ST06-STD), cujo texto está incluído no anexo I do presente regulamento,

- a norma Eurocontrol para a apresentação do intercâmbio de informação dos serviços de tráfego aéreo (ADEXP), edição 2.0 (referência do documento do Eurocontrol DPS.ET1.ST09-STD), cujo texto está incluído no anexo II do presente regulamento,

- a norma Eurocontrol intercâmbio de informação de voo - documento de controlo do interface (FDE-ICD), edição 1.0 (referência do documento do Eurocontrol COM.ET1.ST12-STD), cujo texto está incluído no anexo III do presente regulamento.

Artigo 2.o

O artigo 1.o da Directiva 97/15/CE é revogado.

Artigo 3.o

O presente regulamento entra em vigor no terceiro dia seguinte ao da sua publicação no Jornal Oficial das Comunidades Europeias.

O presente regulamento é obrigatório em todos os seus elementos e directamente aplicável em todos os Estados-Membros.

Feito em Bruxelas, em 6 de Setembro de 2000.

Pela Comissão

Loyola De Palacio

Membro da Comissão

(1) JO L 187 de 29.7.1993, p. 52.

(2) JO L 95 de 10.4.1997, p. 16.

ANEXO I

INTERCAMBIO DE INFORMAÇÃO EM TEMPO REAL (OLDI), EDIÇÃO 2.2

(referência do documento do Eurocontrol DPS.ET1.ST06-STD)

ÍNDICE

>POSIÇÃO NUMA TABELA>

INFORMAÇÃO RELATIVA AOS DIREITOS DE AUTOR

O presente documento foi produzido pela Agência Eurocontrol.

Os direitos de autor pertencem à Agência Eurocontrol.

O conteúdo, ou parte dele, está assim à livre disposição dos representantes dos Estados-membros, mas a cópia ou a divulgação a outras partes está sujeita ao consentimento prévio, por escrito, da Agência Eurocontrol.

PREFÁCIO

1. Organismo Responsável

A Norma do Eurocontrol para o Intercâmbio de Informação em Tempo Real (OLDI), Edição 2.2, foi preparada pela Direcção-Geral para o Desenvolvimento (DED) do Programa de Harmonização e Integração dos Sistemas ATC Europeus (EATCHIP) do Eurocontrol, que é também responsável pela actualização do documento. Todas as questões ou comentários devem ser dirigidos ao Director-Geral, Eurocontrol, Rue de la Fusée, 96, B-1130 Bruxelles, à atenção da Divisão DED-2.

2. Relação com o Documento do Programa de Trabalho do EATCHIP

A presente norma é o produto resultante da Tarefa Especializada DPS.ET1.ST06 do domínio dos Sistemas de Processamento de Dados (DPS) da ATM do EATCHIP, tal como especificado na Edição 2.0 do Documento do Programa de Trabalho do EATCHIP (EWPD), de 30/09/94.

3. Aprovação e Alterações

A presente Norma foi submetida ao seguinte procedimento de aprovação, conforme detalhado nas Directivas de Normalização do Eurocontrol:

- Aprovação pela Equipa de Requisitos Operacionais e de Processamento de Dados de ATM (ODT) do EATCHIP, através do procedimento de correspondência;

- Consulta a todos os Estados CEAC através dos seus representantes na Comissão de Gestão ou no Conselho de Projectos do EATCHIP;

- Aprovação pelo Conselho de Projectos do EATCHIP e pela Comissão de Gestão;

- Adopção pela Comissão Permanente.

As disposições da presente Norma tornam-se efectivas após a sua adopção pela Comissão Permanente.

Por forma a cumprir os requisitos da evolução dos procedimentos de Controlo de Tráfego Aéreo (ATC), podem ser propostas alterações e aditamentos através da ODT, para discussão e possível aprovação. Os requisitos serão incorporados ou como alterações ou como uma nova edição do documento para aval e aprovação, de acordo com procedimentos especificados.

4. Práticas Editoriais

Foi aceite a prática seguinte para indicar o estado de cada declaração: Os Elementos Normativos foram impressos em texto normal; os Elementos Recomendados foram impressos em itálico, sendo o estado indicado pelo prefixo Recomendação.

Foi seguida a prática editorial seguinte na redacção das especificações: para os Elementos Normativos é utilizado o verbo-chave "deve" e para os Elementos Recomendados é utilizado o verbo-chave "deveria".

As notas são impressas em itálico, precedidas do prefixo "NOTA".

5. Relação com a Edição 1 da Norma do Eurocontrol para o Intercâmbio de Informação em Tempo Real

O presente documento substitui as Partes 1 e 2 da Edição 1 da Norma do Eurocontrol para o Intercâmbio de Informação em Tempo Real. A Parte 3, que descreve os protocolos técnicos a utilizar, é substituída pela Norma do Eurocontrol para o Intercâmbio de Informação de Voo - Parte 1 do Documento de Controlo do Interface.

6. Alterações Significativas à Edição 1

Seguidamente referem-se as alterações e os aditamentos mais significativos em relação à Edição 1:

1. Incorporação das seguintes mensagens complementares (não obrigatórias) em relação ao procedimento básico:

- Mensagem para a Revogação da Coordenação (MAC);

- Mensagem de Atribuição de Código (COD) do Radar de Vigilância Secundário (SSR);

- Mensagem de Informação (INF).

2. Definição do conteúdo e do formato da mensagem para apoiar o atravessamento de uma fronteira por um voo numa trajectória que não é uma rota definida dos Serviços de Tráfego Aéreo (ATS), mas que é definida pelos pontos iniciais e finais do segmento da rota.

3. Integração de um procedimento de diálogo que permita:

- a identificação e a negociação de condições de transferência não normalizadas pelos controladores que efectuam a função de planeamento;

- à unidade aceitante ter a capacidade de efectuar uma contraproposta às condições de transferência;

- a disponibilização de funcionalidades para transferência de comunicação como parte do procedimento de transferência de controlo.

4. Introduz-se a utilização do formato descrito na Edição 2 do Documento Normativo do Eurocontrol para a Apresentação do Intercâmbio de Informação (ADEXP). Descrevem-se todas as mensagens especificadas no procedimento básico, bem como as utilizadas durante a fase de coordenação do procedimento de diálogo, utilizando tanto os formatos da Organização da Aviação Civil Internacional (ICAO) como os da ADEXP. As mensagens de Transferência de Comunicação especificadas no procedimento de diálogo são descritas utilizando apenas o formato ADEXP.

5. Eliminação dos seguintes Anexos da Edição 1:

A: Identificação da Unidade ATC.

B: Estrutura das Mensagens OLDI

(todas as mensagens na Edição 3 incluem exemplos).

D: Resenha Histórica.

E: Plano de Execução.

F: Cumprimento pelos Estados.

G: Directrizes para a Execução.

H: Directrizes para a Avaliação da OLDI.

6. Separação da Parte 3 - Requisitos Técnicos - da especificação das aplicações.

7. Relação com Outros Documentos

O presente documento faz referência à utilização de dois tipos de formato dos campos na compilação de mensagens: ICAO e ADEXP.

Os formatos dos campos ICAO são descritos na Referência 1. No caso de a Referência 1 ser substituída por outro documento, a definição dos tipos de campos ICAO será tal como descrita nesse documento.

Os formatos dos campos ADEXP são descritos na Referência 2.

NOTA

Os documentos em referência são listados na Secção 2.

8. Idioma

Na preparação da versão original do presente documento utilizou-se a língua Inglesa.

1. INTRODUÇÃO

1.1. Objectivo

1.1.1. Os voos que se encontram sob um serviço ATC são transferidos de uma unidade ATC para outra de uma forma destinada a garantir total segurança. Para atingir este objectivo, é procedimento normal que a passagem de cada voo pela linha de separação das áreas de responsabilidade das duas unidades seja previamente coordenada entre elas e que o controlo do voo seja transferido quando este se encontra na dita linha de separação, ou nas suas proximidades.

1.1.2. Quando realizada pelo telefone, a transferência da informação sobre os voos individuais, como parte do processo de coordenação, é uma importante tarefa de apoio das unidades ATC, particularmente nos Centros de Controlo de Área (ACC). A utilização operacional de ligações entre os Sistemas de Processamento de Informação de Voo (FDPS) nos ACC com o objectivo de substituir essas "comunicações" verbais, designadas por Intercâmbio de Informação em Tempo Real (OLDI), começou na Europa no princípio dos anos oitenta.

1.1.3. Para facilitar a execução foram elaboradas e aceites pelas agências envolvidas, regras comuns e formatos de mensagens que foram incorporadas na Edição 1 da Norma do Eurocontrol sobre Intercâmbio de Informação em Tempo Real. O presente documento, Edição 2.2, foi produzido para apoiar o desenvolvimento permanente dessas facilidades, em conformidade com os requisitos do EATCHIP.

1.2. Âmbito

1.2.1. O presente documento especifica as funcionalidades e as mensagens a estabelecer entre FDPS em operação nas unidades ATC, com o objectivo de conseguir:

- a necessária coordenação antes da transferência dos voos de uma unidade para a seguinte;

- a transferência de comunicação de tais voos.

1.2.2. O presente documento:

- define os formatos das mensagens e as regras para o seu conteúdo;

- descreve as funcionalidades necessárias em tais unidades que constituem um requisito essencial para a utilização do intercâmbio de informação com este objectivo.

1.2.3. A presente Norma é aplicável entre os Estados-membros do Eurocontrol nas funcionalidades OLDI internacionais entre as unidades que executam um serviço ATC de área.

1.2.4. Recomendação

Recomenda-se que os Estados-membros da Conferência Europeia da Aviação Civil (CEAC) apliquem esta Norma às:

- funcionalidades OLDI internacionais entre unidades que executem um serviço ATC de área dentro da área ECAC;

- funcionalidades OLDI entre unidades que executem um serviço ATC de área, internas ao Estado em causa.

2. REFERÊNCIAS

2.1. Os seguintes Documentos contêm disposições que, através de referência no presente texto, constituem disposições do presente Documento Normativo do Eurocontrol.

À data da publicação do presente Documento Normativo do Eurocontrol, vigoravam as edições indicadas dos documentos em referência.

Qualquer revisão dos Documentos ICAO referidos será tida imediatamente em conta para a revisão do presente Documento Normativo do Eurocontrol.

As revisões dos outros documentos em referência não farão parte das disposições do presente Documento Normativo do Eurocontrol até serem formalmente revistas e incorporadas no presente Documento Normativo do Eurocontrol.

Em caso de conflito entre os requisitos do presente Documento Normativo do Eurocontrol e o conteúdo destes outros documentos em referência, terá precedência o presente Documento Normativo do Eurocontrol.

2.2. No presente Documento Normativo é feita referência aos seguintes documentos:

1. Procedures for Air Navigation Services - Rules of the Air & Air Traffic Services (Procedimentos dos Serviços de Navegação Aérea - Regras do Ar e dos Serviços de Tráfego Aéreo), Documento n.o 4444 da ICAO, Décima terceira Edição, de 7 de Novembro de 1996, com as alterações introduzidas.

2. Edição 2.0 do Documento Normativo do Eurocontrol relativo à Apresentação do Intercâmbio de Informação ATS (ADEXP), referência DPS-ET1-ST09-STD-01-00, de Junho de 1998.

3. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS

3.1. Definições

Para os efeitos da presente Norma do Eurocontrol, aplicar-se-ão as seguintes definições

3.1.1. Unidade Aceitante: A unidade executante de um serviço ATC que assume ou já assumiu o controlo sobre um voo quando a transferência de uma unidade para a seguinte vai ocorrer ou já ocorreu.

3.1.2. Confirmação: Notificação de que uma mensagem foi recebida e que pode ser correctamente processada.

3.1.3. Activação: O processo numa unidade ATC receptora por intermédio do qual é actualizado o plano de voo, por forma a incluir a informação fornecida pela unidade transferidora, como parte do processo de coordenação entre as duas unidades e que resulta no fornecimento dos dados aos controladores.

3.1.4. Altitude: A distância medida na vertical desde um nível, um ponto ou um objecto considerado como um ponto, até ao nível médio das águas do mar.

3.1.5. Aplicação: A parte de um subsistema ATS que está em conformidade com a presente norma e que faz o interface com entidades semelhantes em outros sistemas ATS.

3.1.6. Área de Responsabilidade: Um espaço aéreo de dimensões definidas dentro do qual uma unidade ATC executa serviços de tráfego aéreo.

3.1.7. Associação: Um procedimento através do qual um sistema liga uma mensagem OLDI recebida a uma entrada de um plano de voo na base de dados.

3.1.8. Unidade ATC: Uma unidade que executa um serviço de controlo de tráfego aéreo.

3.1.9. Disponibilidade: A probabilidade de uma função estar acessível a um utilizador num dado instante.

3.1.10. Fronteira: Os planos (laterais e verticais) que delimitam a área de responsabilidade de uma unidade ATC.

3.1.11. Nível de Voo Autorizado: O nível de voo para o qual um voo foi autorizado pelo ATC.

3.1.12. Coordenação, ATC: O processo, executado entre unidades ATC com áreas de responsabilidade adjacentes, para se alertarem mútua e formalmente, da passagem planeada de voos através da fronteira, por forma a garantir a segurança de voo através da consistência das acções planeadas.

3.1.13. Mensagem de Coordenação: Um termo genérico para designar uma mensagem utilizada no cumprimento da coordenação ATC. Inclui a CDN que é uma mensagem específica descrita no parágrafo 8.8.

3.1.14. Fase de Coordenação: Relativamente a um dado voo, é a fase durante a qual as unidades ATC transferidoras e receptoras acordam as condições (por ex. o nível de voo, o ponto de fronteira) sob as quais um voo passará do controlo de uma para a outra.

3.1.15. Ponto de Coordenação: Um ponto na fronteira ou adjacente a ela, conhecido pelas unidades ATC numa sequência de coordenação e referido nas mensagens de coordenação.

3.1.16. Correlação: O processo baseado em critérios definidos de ligação da informação do plano de voo com a trajectória radar do mesmo voo, normalmente para apresentação no ecrã do controlador.

3.1.17. Norma do Eurocontrol: Quaisquer especificações para as características técnicas, configuração, material, desempenho, pessoal ou procedimento, cujas aplicações uniformes foram aprovadas como essenciais para a implementação de sistemas ATS nos Estados-membros do Eurocontrol. Uma Norma do Eurocontrol não poderá estar em conflito com as Normas ICAO, mas deve-as complementar nos casos em que isso se justifique.

3.1.18. Controlador Executivo: Um controlador que dá instruções directamente aos voos sob o seu controlo. Estes controladores incluem os que efectuam o serviço de controlo de área por radar.

3.1.19. Nível de Saída: Um nível para o qual um voo foi coordenado para atravessar um ponto de transferência do controlo. Um nível de saída pode incluir condições de atravessamento suplementares que definem a banda de níveis dentro da qual se encontrará um voo que sobe/desce.

3.1.20. Plano de Voo: Informação detalhada fornecida às unidades do serviço de tráfego aéreo, relativas ao planeamento de um voo ou parte de um voo de uma aeronave. Adicionalmente, informação derivada do plano de voo de um voo específico existente num FDPS.

3.1.21. Geração: Um processo num sistema ATC em que a informação relevante é extraída da(s) base(s) de dados, sendo criada uma mensagem a ser transmitida para uma unidade ATC receptora.

3.1.22. Formato ICAO: O formato utilizado para a transmissão solo - solo de mensagens ATS e que utiliza os tipos e separadores de campos descritos na Referência 1.

3.1.23. Nível: Termo genérico relacionado com a posição vertical de uma aeronave em voo; na presente Norma, o termo nível ou nível de voo inclui a altitude nos casos em que é usada.

3.1.24. Notificação: O processo pelo qual a unidade transferidora transmite informação para actualizar o sistema da unidade receptora em preparação para a fase de coordenação.

3.1.25. Unidade Receptora: A unidade ATC à qual é enviada uma mensagem.

3.1.26. Fiabilidade: A percentagem da disponibilidade planeada durante a qual o serviço deve encontrar-se em operação.

3.1.27. Nível de Voo Solicitado: Um nível de voo solicitado no plano de voo.

3.1.28. Revisão: Uma alteração à informação enviada previamente pela unidade ATC transferidora à unidade ATC receptora.

3.1.29. Nível Suplementar de Cruzamento: Um nível, acima ou abaixo do qual um voo foi coordenado para cruzar o ponto de transferência do controlo. O nível suplementar, se indicado, é um elemento do nível de saída.

3.1.30. Plano de Voo do Sistema: Informação derivada de um plano de voo específico existente num FDPS.

3.1.31. Tempo de Transacção: Um intervalo de tempo no seguimento da inicialização de uma mensagem durante o qual é executada a transmissão, o processamento inicial no sistema receptor, a geração e transmissão de uma mensagem de confirmação e a sua identificação no sistema transferidor.

3.1.32. Ponto de Transferência do Controlo: Um ponto definido, localizado no trajecto de voo de uma aeronave, no qual a responsabilidade de prestação de ATS à aeronave é transferida de uma unidade ATC ou de uma posição de controlo para a seguinte. Não coincide necessariamente com o ponto de coordenação.

3.1.33. Fase de Transferência: Uma fase do voo que se segue à fase de coordenação, durante a qual é executada a transferência de comunicação.

3.1.34. Unidade Transferidora: Numa sequência de coordenação, a unidade ATC responsável pela prestação de um serviço a um voo antes da fronteira e que inicia a fase de coordenação com a unidade seguinte.

3.1.35. Transmitir: Comunicar uma mensagem de um sistema para outro.

3.1.36. Unidade: Unidade de serviços de tráfego aéreo.

3.1.37. Alerta: Uma mensagem mostrada numa posição de trabalho na sequência de falha do processo de coordenação automático.

3.2. Símbolos e Abreviaturas

Para os efeitos da presente Norma do Eurocontrol, aplicar-se-ão os seguintes símbolos e abreviaturas:

ABI Mensagem Avançada de Informação de Fronteira

ACC Centro de Controlo de Área

ACP Mensagem de Aceitação

ACT Mensagem de Activação

ADEXP Apresentação do Intercâmbio de Informação ATS

ATC Controlo de Tráfego Aéreo

ATM Gestão de Tráfego Aéreo

ATS Serviço de Tráfego Aéreo

CDN Mensagem de Coordenação

CNL Cancelamento de Plano de Voo

COD Mensagem de Atribuição de Código SSR

COF Mensagem de Mudança de Frequência

COP Ponto de Coordenação

DED Direcção-Geral de Desenvolvimento do EATCHIP, Eurocontrol

EATCHIP Programa de Harmonização e de Integração dos Sistemas ATC Europeus

CEAC Conferência Europeia da Aviação Civil

ETO Hora Estimada Sobre

ETOT Hora Estimada de Descolagem

EWPD Documento do Programa de Trabalho do EATCHIP

FDPS Sistema de Processamento de Informação de Voo

FRF Rota Subsequente do Voo

HMI Interface Homem-Máquina

HOP Mensagem de Proposta de Entrega

ICAO Organização da Aviação Civil Internacional

INF Mensagem de Informação

LAM Mensagem de Confirmação Lógica

LoA Carta de Acordo

MAC Mensagem de Revogação de Coordenação

MAS Afectação Manual das Comunicações

NM Milha Náutica

OLDI Intercâmbio de Informação em Tempo Real

ORCAM Método de Atribuição de Códigos por Região de Origem

PAC Mensagem de Activação Preliminar

RAP Mensagem de Proposta de Activação Remetida

REV Mensagem de Revisão

RJC Mensagem de Rejeição de Coordenação

ROF Mensagem de Pedido na Frequência

RRV Mensagem de Revisão Remetida

SBY Mensagem de Espera

SDM Mensagem de Informação Suplementar

SSR Radar de Vigilância Secundário

SYSCO Coordenação Suportada pelo Sistema

TI Início da Transferência

TIM Mensagem de Início de Transferência

TWR/APP Torre (controlo de aeródromo) e Controlo de Aproximação

4. REQUISITOS GERAIS

4.1. Introdução

A presente secção descreve os requisitos operacionais gerais necessários para a execução de uma funcionalidade OLDI entre unidades ATC bem como a classificação e os requisitos de desempenho dos diferentes tipos de mensagens utilizadas.

4.2. Requisitos do Sistema de Processamento de Informação de Voo

4.2.1. Base de Dados de Voo

As unidades que utilizam funcionalidades descritas no presente documento deverão dispor dos dados provenientes de um FDPS que contenha toda a informação necessária para a visualização, processamento e compilação das mensagens da forma especificada. A fonte primária de informação para cada voo é o plano de voo preenchido pelo piloto comandante ou por alguém em seu nome. Os restantes itens de informação são obtidos através do processamento dos planos de voo com referência ao ambiente da unidade envolvida.

4.2.2. Operação em Tempo Real

O procedimento OLDI inclui os acontecimentos na unidade ATC transferidora que iniciam as funções necessárias à apresentação atempada da informação ao controlador que efectua a transferência, bem como a transmissão dos dados de coordenação para a unidade aceitante. Para este fim, o FDPS será capaz de iniciar funções através da comparação do Tempo Universal Coordenado e de parâmetros temporais aplicáveis com as horas nas posições especificadas da rota de voo, tais como determinados a partir da base de dados de voo.

4.2.3. Capacidade de Comunicação de Dados

4.2.3.1. O FDPS deverá ser capaz de receber e de transmitir informação de voo no formato aplicável à mensagem, tal como especificado no presente documento, através de um meio de comunicação de dados que suporte a função OLDI.

4.2.3.2. Recomendação

O FDPS deveria possuir o potencial de desenvolvimento que permitisse a adição de novas mensagens que possam ser incluídas em edições futuras da presente norma.

4.2.3.3. Juntamente com os requisitos de desempenho especificados no presente documento, o meio de comunicação de dados deverá proporcionar um intercâmbio de informação rápida e fiável entre aplicações:

- assegurando a integridade da transmissão da mensagem OLDI;

e

- monitorizando tanto as ligações ponto-a-ponto como o estado da rede de comunicações, conforme aplicável.

4.2.3.4. O FDPS deverá alertar as posições de trabalho sempre que forem detectadas anomalias pelo sistema de comunicação de dados.

4.2.4. Funções Aplicacionais

4.2.4.1. Os sistemas utilizados para a disponibilização das funcionalidades OLDI deverão ser capazes de automaticamente receber, armazenar, processar, extrair e passar para o ecrã, e transmitir em tempo real, informação relativa à OLDI.

4.2.4.2. O FDPS deverá:

- reflectir a informação operacional actual relevante à função OLDI, conforme exigido pela presente Norma, actualizada automaticamente ou através de entradas manuais ou por uma combinação das duas;

- ser capaz de extrair esses elementos da base de dados de planos de voo;

- identificar a próxima unidade ATC na rota do voo.

4.2.4.3. O seguinte será objecto de acordo bilateral:

- Pontos de Coordenação (COP);

- Pontos de referência utilizados na indicação do azimute e da distância na identificação do COP em segmentos de rota não-ATS directos, quando utilizados.

NOTA

Os COP podem não ser sempre idênticos aos pontos de transferência do controlo.

4.2.5. Interface Homem-Máquina (HMI)

4.2.5.1. O HMI deverá ser capaz de:

- apresentar o conteúdo operacional das mensagens OLDI e os alertas pertinentes relacionados com as mensagens recebidas, para atenção imediata;

- enviar alertas de mensagens de coordenação e de transferência para as posições operacionais responsáveis pela coordenação dos voos relacionados.

4.2.5.2. O pessoal do ATC disporá dos meios necessários para a modificação dos dados, a partir dos quais são derivados os conteúdos das mensagens operacionais, tal como exigido pelo presente documento.

4.2.5.3. O HMI deverá indicar que a transmissão da mensagem está em curso ou que foi transmitida com sucesso, conforme adequado.

4.2.5.4. Se no parâmetro tempo seguinte à transmissão de uma mensagem de coordenação ou de transferência não for recebida nenhuma mensagem de confirmação, deverá ser gerado automaticamente um alerta ou notificação para o ATC ou posição(ões) técnica(s) adequadas.

4.2.5.5. Esse alerta ou notificação deverá ser de forma a chamar imediatamente a atenção da posição de trabalho adequada.

4.2.5.6. Recomendação

O HMI em posições ATC que utilizem OLDI deveria lançar um alerta se a funcionalidade OLDI não estiver disponível.

4.2.6. Inicialização de Mensagens

4.2.6.1. Cada sistema deverá conter um conjunto de parâmetros de sistema para garantir a atempada inicialização automática de mensagens OLDI.

4.2.6.2. Recomendação

Deveria existir a capacidade de iniciar manualmente a transmissão de uma mensagem de coordenação antes da hora calculada de transmissão.

4.2.6.3. A ocorrência automática deverá estar sempre assegurada, caso a inicialização manual não seja executada.

4.2.6.4. O sistema deverá utilizar parâmetros temporais para definir o seguinte:

- o tempo de espera, antes da transmissão, enquanto é visualizado o conteúdo operacional das mensagens na unidade transferidora;

- o tempo necessário, global ou por COP, para transmitir a mensagem, quando aplicável;

- o tempo após a transmissão de uma mensagem durante o qual deve ser recebida uma confirmação de nível aplicacional (expiração do tempo).

4.2.6.5. Uma mensagem será transmitida sem demora quando a informação necessária só ficar disponível mais tarde do que, de outra maneira, deveria ter sido transmitida.

Exemplo:

Um voo começa num segmento GAT IFR num ponto próximo da fronteira que deverá atravessar; o ETO no ponto é comunicado oito minutos antes do COP, altura em que a transmissão da mensagem ACT se encontra já atrasada baseado no(s) parâmetro(s) temporal(is) aplicável(eis); a mensagem é enviada sem demora.

4.2.7. Recepção de Mensagens

4.2.7.1. O sistema ATC será capaz de:

- receber mensagens OLDI;

- processá-las automaticamente, em conformidade com a presente Norma;

- produzir informação de voo em conformidade com a mensagem recebida e apresentar os alertas necessários em caso de inconsistência da informação recebida;

- gerar e transmitir automaticamente mensagens de confirmação ao nível aplicativo.

4.2.7.2. Uma mensagem de confirmação (Mensagem de Confirmação Lógica (LAM), de Aceitação (ACP) ou de Espera (SBY)) será gerada e transmitida quando a mensagem correspondente tiver sido processada e quando estiver garantida a apresentação dos resultados do processamento na(s) posição(ões) apropriada(s), caso seja necessário.NOTA

As condições detalhadas para a geração de uma confirmação são especificadas individualmente para cada mensagem.

4.3. Actualização da Informação sobre Vigilância

Recomendação

Por forma a garantir a precisão da informação horária estimada, deveria utilizar-se a informação derivada do rastreio dos voos pelo radar ou por outros meios de vigilância, para actualizar a base de dados de planos de voo.

4.4. Gravação da Informação OLDI

4.4.1. Conteúdo

Deverão ser gravados os conteúdos de todas as mensagens OLDI, bem como a hora de recepção.

4.4.2. Funcionalidades

Deverão estar disponíveis funcionalidades para a recuperação e apresentação da informação gravada.

4.5. Disponibilidade, Fiabilidade, Segurança da Informação e Integridade dos Dados

4.5.1. Disponibilidade

4.5.1.1. A funcionalidade OLDI deverá estar disponível durante as horas normais e de pico do fluxo de tráfego entre as duas unidades envolvidas.

4.5.1.2. Recomendação

A funcionalidade OLDI deveria estar permanentemente disponível.

4.5.1.3. Quaisquer períodos programados de indisponibilidade (e, assim, o período de disponibilidade previsto) deverá ser acordado bilateralmente entre as duas unidades envolvidas.

4.5.2. Fiabilidade

4.5.2.1. A fiabilidade de qualquer ligação OLDI deverá ser de, pelo menos, 99,86 % (equivalente a um período de indisponibilidade não superior a 12 horas por ano, baseado numa disponibilidade de 24 horas).

4.5.2.2. Recomendação

Quando for operacionalmente justificável, a fiabilidade deveria ser de, pelo menos, 99,99 % (equivalente a um período de indisponibilidade não superior a 52 minutos por ano, baseado numa disponibilidade de 24 horas).

4.5.3. Segurança da Informação

Recomendação

Deveriam ser aplicados às funcionalidades OLDI métodos de segurança da informação (por ex. direitos de acesso, confirmação da origem, etc.) e, onde aplicável, de gestão de redes.

4.5.4. Integridade dos Dados

A taxa de falhas ao nível aplicativo não deve exceder um erro de transmissão por cada 2000 mensagens.

4.6. Avaliação Operacional

4.6.1. Período de Avaliação

Cada nova funcionalidade OLDI, incluindo uma nova funcionalidade numa ligação existente, será submetida a um período de avaliação para verificar a integridade dos dados, a precisão, o desempenho, a compatibilidade com os procedimentos ATC e com a segurança geral, antes da sua entrada em serviço.

NOTA

Está disponível no Secretariado da OLDI no Eurocontrol, um procedimento para auxiliar na avaliação de uma nova funcionalidade OLDI.

4.6.2. Data de Introdução Operacional

A data da introdução operacional, implicando o término do período de avaliação, será formalmente acordada entre as duas unidades.

5. CATEGORIAS DAS MENSAGENS

5.1. Generalidades

5.1.1. Objectivo

A presente Secção do documento:

- define as categorias das mensagens;

- estabelece os requisitos temporais de transacção em cada categoria;

- estabelece quais as mensagens obrigatórias e complementares;

- atribui tipos de mensagens às categorias.

5.1.2. Categorias das Mensagens

As mensagens OLDI foram atribuídas às seguintes categorias:

- Categoria 1: Transferência de Comunicação;

- Categoria 2: Coordenação;

- Categoria 3: Notificação.

5.2. Tempos de Transacção

5.2.1. Condições para os Tempos de Transacção

5.2.1.1. Os tempos de transacção especificados incluem a transmissão, processamento inicial na unidade receptora, criação da mensagem de confirmação, sua transmissão e recepção na unidade transferidora. As mensagens de confirmação automática LAM e SBY não foram, assim, atribuídas a uma categoria de mensagens.

5.2.1.2. Os tempos máximos de transacção para as diferentes categorias de mensagens serão os especificados na Tabela 5-1.

Tabela 5-1

Tempos Máximos de Transacção

>POSIÇÃO NUMA TABELA>

5.2.1.3. Por cada categoria ou tipo de mensagem será definido um tempo findo o qual expirará o tempo de transacção.

5.2.1.4. Se, durante o período de tempo especificado após a transmissão, não tiver sido recebida nenhuma confirmação, considerar-se-á que a mensagem não foi transmitida ou processada com sucesso e será activado um alerta, tal como especificado na secção relevante do presente documento.

5.2.1.5. Recomendação

Os valores findos os quais expirarão os tempos de transacção para as três categorias de mensagens não deveriam exceder 12 segundos, 30 segundos e 60 segundos, respectivamente.

5.3. Classificação e Categorização das Mensagens

5.3.1. Classificação das Mensagens - Obrigatórias e Complementares

5.3.1.1. As mensagens descritas no presente documento são classificadas de obrigatórias ou de complementares.

5.3.1.2. Quando uma mensagem for descrita como sendo de transmissão (TX) obrigatória (M), será incluído o processamento necessário para o seu envio.

5.3.1.3. Quando uma mensagem for descrita como sendo de recepção (REC) obrigatória, será incluído o processamento necessário para o tratamento das mensagens recebidas.NOTA

Em casos excepcionais, quando o fluxo de tráfego entre duas unidades seja unidireccional, as mensagens obrigatórias poderão ser aplicáveis em apenas uma das direcções.

5.3.1.4. Quando uma mensagem for descrita como sendo de transmissão complementar (C), será incluído o processamento necessário para o seu envio, se tal for exigido pela unidade emissora e objecto de acordo bilateral com a unidade receptora.NOTA

As mensagens complementares podem ser usadas apenas numa direcção, em função do que for determinado pelos requisitos operacionais.

5.3.1.5. Quando uma mensagem for descrita como sendo de recepção complementar, será incluído o processamento necessário para o tratamento das mensagens recebidas, se tal utilização tiver sido objecto de acordo bilateral.

5.3.1.6. Os requisitos descritos nas Tabelas 5-3 e 5-4 só se aplicam quando a utilização do procedimento de Diálogo para a Coordenação e/ou Transferência de Comunicação, respectivamente, tiver sido objecto de acordo bilateral entre as unidades ATC.

5.3.2. Categorização das Mensagens

5.3.2.1. A categorização das mensagens para o procedimento básico encontra-se especificada na Tabela 5-2.

5.3.2.2. A categorização das mensagens de coordenação adicionais para o procedimento de diálogo encontra-se especificada na Tabela 5-3.

5.3.2.3. A categorização das mensagens de transferência de comunicação para o procedimento de diálogo encontra-se especificada na Tabela 5-4.

Tabela 5-2

Mensagens de Procedimento Básico

>POSIÇÃO NUMA TABELA>

Tabela 5-3

Procedimento de Diálogo - Mensagens da Fase de Coordenação

(Adicional à Tabela 5-2)

>POSIÇÃO NUMA TABELA>

Tabela 5-4

Procedimento de Diálogo - Mensagens da Fase de Transferência

>POSIÇÃO NUMA TABELA>

6. PROCEDIMENTO BÁSICO - MENSAGENS OBRIGATÓRIAS

6.1. Generalidades

6.1.1. Descrição do Requisito

A presente secção descreve os requisitos mínimos para a implementação das funcionalidades OLDI ao nível aplicativo.

6.1.2. Implementação

As unidades que utilizam a OLDI para a coordenação dos voos deverão implementar as mensagens ABI, ACT e LAM da forma descrita nesta secção, excepto se a utilização do procedimento de diálogo para a coordenação, descrito na Secção 8 do presente documento, tiver sido objecto de acordo bilateral. Neste caso, as condições para a utilização das mensagens ACT e LAM são as definidas naquela secção.

6.2. Mensagem Avançada de Informação de Fronteira (ABI)

6.2.1. Finalidade da Mensagem ABI

A ABI satisfaz os seguintes requisitos operacionais:

- permite a aquisição dos dados de plano de voo em falta;

- fornece informação avançada de fronteira e suas revisões à unidade ATC seguinte;

- actualiza a informação básica do plano de voo;

- facilita a correlação antecipada das trajectórias radar;

- facilita a avaliação precisa a curto prazo da carga do sector.

A ABI é uma mensagem de notificação.

6.2.2. Conteúdo da Mensagem

A mensagem ABI deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Modo e Código SSR (se existente);

- Aeródromo de Partida;

- Informação Estimada;

- Aeródromo de Destino;

- Número e Tipo da Aeronave;

- Rota (opcional);

- Outras Informações do Plano de Voo (opcional).

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos, encontram-se especificados no Anexo A.

6.2.3. Regras de Aplicação

6.2.3.1. Generalidades

6.2.3.1.1. À excepção do estabelecido em 6.2.3.1.3 e 6.2.3.1.4 abaixo, deverão ser enviadas uma ou mais mensagens ABI por cada voo cujo atravessamento da fronteira das áreas de responsabilidade esteja planeado, subordinadas aos procedimentos OLDI.

6.2.3.1.2. Quando enviada, a mensagem ABI deverá preceder a mensagem de Activação (ACT) ou de Proposta de Activação Remetida (RAP).

6.2.3.1.3. A mensagem ABI não deverá ser gerada se estiver para ser enviada uma mensagem de Activação Preliminar (PAC).

6.2.3.1.4. Recomendação

A transmissão da ABI deveria ser inibida se as mensagens ACT ou RAP estiverem para ser enviadas imediatamente ou num intervalo de tempo acordado bilateralmente.NOTA

O objectivo desta recomendação é evitar a tentativa de resolução simultânea de anomalias em diferentes posições da unidade receptora, relativamente às mensagens ABI e ACT de um mesmo voo.

6.2.3.1.5. Será enviada uma mensagem ABI revista se a mensagem ACT subsequente não tiver sido gerada e se:

- a rota do voo tiver sido modificada de tal modo, conduzindo à imprecisão do COP enviado na mensagem ABI antecedente;

- o aeródromo de destino tiver sido alterado;

ou

- tiver mudado o tipo de aeronave.

6.2.3.1.6. Recomendação

Deveria ser enviada uma mensagem ABI revista se a mensagem ACT subsequente não tiver sido gerada e se um dos seguintes dados estiver sujeito a alteração:

- O nível esperado de atravessamento da fronteira;

- O código SSR esperado no ponto de transferência do controlo;

- Quando a hora estimada sobre (ETO) o COP diferir da hora da mensagem ABI antecedente em mais do que o tempo especificado na Carta de Acordo (LoA);

- Qualquer outra informação que tenha sido objecto de acordo bilateral.

6.2.3.2. Processamento na Unidade Receptora

6.2.3.2.1. O sistema ATC que receba uma mensagem ABI deverá tentar a sua associação com a informação do plano de voo correspondente.

6.2.3.2.2. Se a associação com o plano de voo não tiver êxito, deverá ser criado, automática ou manualmente, um plano de voo no sistema receptor.

6.2.3.2.3. Se a associação com o plano de voo tiver êxito mas for identificada uma discrepância entre a informação da mensagem e os correspondentes dados no sistema receptor que possa resultar na necessidade de uma acção correctiva aquando da recepção da mensagem ACT seguinte, a referida discrepância deverá ser remetida a uma posição apropriada para a sua resolução.

6.2.3.3. Parâmetros de Tempo para Transmissão

6.2.3.3.1. A mensagem será transmitida durante um determinado número de minutos antes da hora estimada no COP.

6.2.3.3.2. O(s) parâmetro(s) de geração ABI serão incluídos na LoA entre as unidades ATC envolvidas.

6.2.3.3.3. Recomendação

O(s) parâmetro(s) de geração ABI deveriam ser:

- variáveis, baseados nas disposições da LoA;

- definidos separadamente para cada um dos COP.

6.2.4. Confirmação da ABI

6.2.4.1. Confirmação

A mensagem ABI será confirmada pela geração e transmissão de uma mensagem LAM.

NOTA

É gerada uma mensagem LAM independentemente do resultado da tentativa de associação com o plano de voo.

6.2.4.2. Não Confirmação

Recomendação

Se, em confirmação de uma mensagem ABI, não for recebida uma mensagem LAM, deve ser apresentado um alerta numa posição de supervisão.

6.2.5. Exemplos

"Air 2000" 253, Boeing 757 proveniente de Malta com destino a Birmingham estimando um BNE VOR às 1221 UTC, voando a FL350 a uma velocidade verdadeira do ar de 480 nós, planeando uma rota via UB4 BNE UB4 BPK UB3 HON, com código de transponder A7012 e solicitando FL390. O que se segue são exemplos equivalentes da mensagem ABI enviada do ACC de Reims para o ACC de Londres.

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. Mensagem de Activação (ACT)

6.3.1. Finalidade da Mensagem de Activação

A mensagem ACT satisfaz os seguintes requisitos operacionais:

- Substitui a estimativa verbal de fronteira pela transmissão automática de detalhes de um voo de uma unidade ATC para a seguinte antes da transferência do controlo;

- Actualiza a informação básica do plano de voo na unidade ATC receptora, com a informação mais recente;

- Facilita a distribuição e visualização da informação do plano de voo pelas posições de trabalho envolvidas na unidade ATC receptora;

- Acelera a visualização da correlação identificador de chamada/código na unidade ATC receptora;

- Fornece as condições de transferência à unidade ATC receptora.

6.3.2. Conteúdo das Mensagens

A mensagem ACT deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Modo e Código SSR;

- Aeródromo de Partida;

- Informação Estimada;

- Aeródromo de Destino;

- Número e Tipo de Aeronave;

- Rota (opcional);

- Outras informações do plano de voo (opcional).

NOTA

As regras de inserção de dados, os formatos e os conteúdos dos campos são especificados no Anexo A.

6.3.3. Regras de Aplicação

6.3.3.1. Generalidades

6.3.3.1.1. Será enviada uma mensagem ACT para os voos elegíveis que atravessem a fronteira, exceptuando-se o estabelecido no parágrafo 6.3.3.1.10.

6.3.3.1.2. A mensagem ACT será gerada e transmitida automaticamente à hora calculada, tal como especificado na LoA, excepto se for previamente iniciada manualmente.

6.3.3.1.3. Recomendação

O pessoal do ATC deveria dispor de meios para activar a transmissão das mensagens ATC antes da hora calculada para a transmissão.

6.3.3.1.4. O conteúdo operacional das mensagens ACT que vão ser transmitidas deve ser visualizado na posição de trabalho responsável pela coordenação do voo antes da transmissão.

6.3.3.1.5. Recomendação

Relativamente a 6.3.3.1.4, deveria ser visualizado juntamente com o seu conteúdo, a hora calculada para a transmissão automática da ACT.

6.3.3.1.6. A mensagem ACT deve conter a informação mais recente sobre o voo, reflectindo as condições de saída previstas.

6.3.3.1.7. A posição de trabalho respectiva deve ser notificada da transmissão da mensagem ACT.

6.3.3.1.8. A informação da mensagem ACT torna-se operacionalmente vinculativa para ambas as unidades ATC, logo que a LAM seja recebida. As condições de transferência coordenada e o facto de a LAM ter sido recebida serão apresentadas ao pessoal do ATC na unidade transferidora.

6.3.3.1.9. Assumir-se-á a aceitação pela unidade receptora das condições de transferência implícitas na mensagem ATC, excepto se a unidade receptora iniciar a coordenação para a sua alteração.

6.3.3.1.10. Só poderá ser enviada uma outra mensagem ACT para o mesmo parceiro de coordenação se a anterior tiver sido revogada pela utilização de uma MAC.

6.3.3.1.11. A Rota e Outras informações do plano de voo, deverão ser incluídas se tal tiver sido objecto de coordenação bilateral.

6.3.3.2. Processamento na Unidade Receptora

6.3.3.2.1. O sistema ATC que recebe uma mensagem ACT deve tentar a sua associação com o plano de voo correspondente.

6.3.3.2.2. Se for encontrado um plano de voo correspondente e não existirem discrepâncias na mensagem que possam inibir o correcto processamento:

- o conteúdo operacional deverá ser incluído no plano de voo;

- a informação necessária será apresentada num ATC operacional e noutras posições, conforme apropriado;

- deverá ser enviada uma LAM em resposta.

6.3.3.2.3. Se não puder ser encontrado um plano de voo correspondente, ou for encontrada uma discrepância que iniba o correcto processamento da mensagem:

- se puder ser identificado o sector responsável pela aceitação do controlo do voo:

- o conteúdo operacional da mensagem será apresentado no sector;

- será enviada uma LAM em resposta;

- será criado um plano de voo;

- nos restantes casos, não será enviada uma LAM em resposta.

6.3.3.3. Parâmetros de Transmissão

6.3.3.3.1. A mensagem será transmitida assim que ocorrer o primeiro dos instantes de tempo a seguir determinados, ou o mais rápido possível após a sua ocorrência:

- um determinado número de minutos antes da hora estimada no COP;

- a hora a que o voo se encontra a uma distância bilateralmente acordada do COP.

6.3.3.3.2. O(s) parâmetro(s) de geração do ACT será(ão) incluído(s) na LoA estabelecida entre as unidades ATC envolvidas.

6.3.3.3.3. O(s) parâmetro(s) de geração do ACT será(ão) variável(eis) em função das disposições da LoA.

6.3.3.3.4. Recomendação

Os parâmetros de geração da ACT deveriam ser definidos separadamente para cada um dos COP.

6.3.3.3.5. Os parâmetros especificados deverão permitir tempo suficiente para:

- que a unidade transmissora actualize o nível de voo da transferência para reflectir as condições esperadas no COP;

e

- que a unidade receptora processe a ACT e gere e transmita uma LAM, mas que, ainda assim, permita a coordenação verbal pela unidade transferidora e a resultante acção pela unidade aceitante, caso o intercâmbio de informação falhe.

6.3.4. Confirmação da ACT

6.3.4.1. Confirmação

A mensagem ACT será confirmada pela geração e transmissão de uma mensagem LAM.

6.3.4.2. Casos de Não Confirmação

Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem ACT, deve ser apresentado um alerta na posição ATC responsável pela coordenação do voo.

6.3.5. Exemplos

Os exemplos seguintes são uma extensão dos exemplos apresentados no parágrafo 6.2 relativamente à mensagem ABI; todos os detalhes são idênticos, com excepção da ETO no COP que é 1226 na mensagem ACT apresentada:

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. Mensagem de Confirmação Lógica (LAM)

6.4.1. Finalidade da Mensagem LAM

A LAM é o meio através do qual a unidade receptora indica à unidade transmissora, a recepção e a protecção de uma mensagem transmitida.

O processamento da LAM fornece ao pessoal do ATC na unidade transferidora:

- um alerta, no caso de não ter sido recebida qualquer confirmação;

- uma indicação de que a mensagem transmitida foi recebida, processada com êxito, sem erros, armazenada e, onde aplicável, estar disponível para apresentação na(s) posição(ões) apropriada(s).

6.4.2. Conteúdo da Mensagem

A mensagem LAM deve conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem.

NOTA

As regras de inserção dos dados, os formatos e os conteúdos das mensagens são especificados no Anexo A.

6.4.3. Regras de Aplicação

6.4.3.1. Generalidades

6.4.3.1.1. As regras para o envio de uma mensagem LAM em resposta, estão especificadas nas secções do presente documento que definem o processamento de cada mensagem.

6.4.3.1.2. A mensagem LAM será gerada e transmitida sem intervenção humana.

6.4.3.1.3. A mensagem LAM não será utilizada para evitar a necessidade de mensagens técnicas destinadas a garantir a integridade das transmissões de dados.

6.4.3.1.4. A mensagem LAM será gerada e transmitida imediatamente, por forma a poder ser alcançado o requisito do tempo de transacção da mensagem que está a ser confirmada.

6.4.3.1.5. Com excepção das mensagens ABI, o sistema ATC transmissor deverá informar o controlador responsável pela coordenação, da não recepção de uma mensagem LAM dentro dos parâmetros de tempo estabelecidos para tais alertas.

6.4.4. Confirmação da LAM

A mensagem LAM não exigirá qualquer confirmação.

6.4.5. Exemplos

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. PROCEDIMENTO BÁSICO - MENSAGENS COMPLEMENTARES

7.1. Generalidades

7.1.1. Descrição do Requisito

A presente secção descreve as funcionalidades aplicáveis ao procedimento básico, adicionais às descritas na Secção 6, Procedimento Básico - Mensagens Obrigatórias.

7.1.2. Implementação

7.1.2.1. A utilização de qualquer uma das funcionalidades descritas nesta secção será objecto de acordo bilateral antes da sua introdução.

7.1.2.2. Quando essa utilização for acordada, serão aplicadas as regras descritas nesta secção.

7.2. Mensagem de Activação Preliminar (PAC)

7.2.1. Finalidade da Mensagem PAC

A mensagem PAC satisfaz os seguintes requisitos operacionais:

- notificação e coordenação antes da partida de um voo em que o tempo de voo, desde a partida até ao COP, é inferior ao requerido para cumprir os parâmetros de tempo acordados para a transmissão da mensagem ACT;

- notificação e coordenação antes da partida de um voo, por uma unidade local (controlo de aeródromo/aproximação) para a próxima unidade que tomará controlo do voo;

- permitir a aquisição dos dados do plano de voo em falta, no caso de discrepâncias na distribuição inicial da informação do plano de voo;

- solicitar a atribuição de um código SSR à unidade a que é enviada a coordenação/notificação acima referida, se necessário.

7.2.2. Conteúdo da Mensagem

A mensagem PAC deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem (opcional);

- Identificação da Aeronave;

- Modo e Código SSR;

- Aeródromo de Partida;

- Hora Estimada de Descolagem ou Informação Estimada;

- Aeródromo de Destino;

- Tipo de Aeronave;

- Rota (opcional);

- Outras informações do plano de voo (opcional).

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

7.2.3. Regras de Aplicação

7.2.3.1. Generalidades

7.2.3.1.1. Serão enviadas uma ou mais mensagens PAC por cada voo que planeie atravessar a fronteira das áreas de responsabilidade, e em que o tempo decorrido desde a partida até ao COP não permita o envio da mensagem ACT na altura requerida.

7.2.3.1.2. Serão enviadas uma ou mais mensagens PAC pela unidade de Aeródromo/Aproximação para a unidade seguinte, por cada voo que parta e que necessite de notificação ou de coordenação.

7.2.3.1.3. Recomendação

Para a implementação da PAC/LAM entre unidades, os sistemas TWR/APP aplicáveis deveriam possuir os meios para introduzir e enviar o "arranque", "recuo", "táxi" ou informação similar a partir da qual o ETOT possa ser derivado de forma a calcular o ETO no COP e iniciar a transmissão da PAC.

7.2.3.1.4. Tal como acordado bilateralmente, a mensagem deverá conter:

- a Hora Estimada de Descolagem;

ou

- a Informação Estimada.

7.2.3.1.5. Quando a referência da mensagem for incluída deverá, por acordo bilateral:

- conter o número da primeira mensagem PAC enviada para o voo;

- ser incluída na segunda mensagem PAC e subsequentes.

7.2.3.1.6. A utilização da funcionalidade de solicitação do código, se necessária, deverá ser objecto de acordo bilateral.

7.2.3.1.7. No caso de antes da partida se aplicar alguma das condições seguintes, deverá ser enviada uma mensagem PAC revista:

- a rota do voo foi modificada de tal modo, que o COP indicado na mensagem anterior deixa de ser válido;

- mudança do tipo de aeronave;

- o aeródromo de destino indicado na PAC anterior não é o correcto.

7.2.3.1.8. Recomendação

Deveria ser enviada uma mensagem PAC se, antes da partida, os seguintes dados diferirem dos indicados na mensagem PAC anterior:

- o nível (na informação estimada, se existente);

- o código SSR esperado no ponto de transferência do controlo;

- a Hora Estimada de Descolagem ou se a ETO no COP exceder um valor acordado bilateralmente

- existir uma alteração em quaisquer outros dados, tal como acordado bilateralmente.

7.2.3.2. Processamento na Unidade Receptora

7.2.3.2.1. O sistema ATC que receba uma mensagem PAC deverá tentar a sua associação com o plano de voo correspondente.

7.2.3.2.2. Se for encontrado um plano de voo correspondente e não existirem discrepâncias na mensagem que possam inibir o correcto processamento:

- o conteúdo operacional será incluído no plano de voo;

- os dados necessários serão enviados para o ATC operacional e para outras posições, conforme apropriado;

- será enviada uma LAM em resposta.

7.2.3.2.3. Se não for encontrado um plano de voo correspondente, ou forem detectadas discrepâncias que inibam o correcto processamento da mensagem:

- se puder ser identificado o sector responsável pela aceitação do controlo do voo:

- o conteúdo operacional da mensagem será apresentado no sector;

- será enviada uma LAM em resposta;

- será criado um plano de voo;

- nos restantes casos, não será enviada uma LAM em resposta.

7.2.3.2.4. A informação na segunda mensagem PAC ou nas subsequentes substitui a informação na mensagem antecedente.

7.2.3.2.5. Se a mensagem PAC incluir um pedido de atribuição de um código SSR e puder ser correctamente processada, conforme descrito no parágrafo 7.2.3.2.2 supra, em adição à LAM será enviada em resposta uma mensagem COD.NOTA

Uma vez que o processo de atribuição de código exige informação detalhada da rota do plano de voo, não se estabelece neste documento nenhum requisito para o envio de uma mensagem COD pela unidade receptora, quando tal informação possa não estar disponível para o voo. Isto não impede o envio de uma mensagem em circunstâncias em que exista uma capacidade local específica e onde o procedimento tiver sido objecto de acordo bilateral.

7.2.3.3. Parâmetros de Tempo para a Transmissão

O parâmetro tempo de transmissão não se aplica uma vez que a mensagem é enviada em resultado de uma acção manual que identifica a partida iminente de um voo.

7.2.4. Confirmação da PAC

7.2.4.1. Confirmação

As mensagens a enviar em resposta a uma mensagem PAC são descritas no parágrafo 7.2.3.2 supra.

7.2.4.2. Não Confirmação

Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem PAC, deverá ser apresentado um alerta na posição da unidade ATC responsável pela coordenação com a unidade seguinte.

7.2.4.3. Casos de Inexistência de LAM

Nos casos em que não exista LAM, deverá ser iniciada a coordenação verbal.

7.2.4.4. Inexistência de Mensagem COD

7.2.4.4.1. Se não for recebida uma mensagem COD em resposta a um pedido de código incluído na mensagem PAC, deverá ser apresentado um alerta na posição apropriada.

7.2.4.4.2. Sempre que a função de pedido de código seja utilizada, o valor de expiração do prazo a aplicar deverá ser objecto de acordo bilateral.

7.2.5. Exemplos

7.2.5.1. Hora Estimada de Descolagem e Pedido de Código

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. Hora no 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. Mensagem de revisão (REV)

7.3.1. Finalidade da Mensagem REV

A mensagem REV é utilizada para transmitir revisões a dados de coordenação enviados previamente numa mensagem ACT, desde que a unidade aceitante não varie em resultado da modificação.

7.3.2. Conteúdo da mensagem

A mensagem REV deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem (opcional);

- Identificação da Aeronave;

- Modo e Código SSR (opcional);

- Aeródromo de Partida;

- Informação Estimada;

- Ponto de Coordenação (opcional);

- Aeródromo de Destino;

- Rota (opcional);

- Outras informações do plano de voo (opcional).

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

7.3.3. Regras de Aplicação

7.3.3.1. Generalidades

7.3.3.1.1. Poderão ser enviadas uma ou mais mensagens REV para a unidade à qual o voo foi actualmente coordenado pela utilização de uma mensagem de Activação.

7.3.3.1.2. Os seguintes elementos serão sujeitos a revisões:

- ETO no COP;

- Nível(eis) de transferência;

- Código SSR.

7.3.3.1.3. Deverá ser enviada uma mensagem REV quando:

- a ETO no COP diferir da indicada na mensagem anterior por mais do que um valor acordado bilateralmente, arredondado para o inteiro mais próximo;

- existir alguma alteração do(s) nível(eis) de transferência ou do código SSR.

7.3.3.1.4. Sempre que houver acordo bilateral, deverá ser enviada uma mensagem REV quando existir alguma alteração no seguinte:

- COP;

- rota;

- outras informações do plano de voo (dados dos campos 8, 10 e 18 da ICAO).

NOTA

As regras operacionais podem exigir que as modificações em vigor após a ACT, sejam sujeitas a coordenação prévia entre as unidades envolvidas.

7.3.3.1.5. Sempre que houver acordo bilateral, a referência da mensagem será incluída na mensagem REV.

7.3.3.1.6. A referência da mensagem, quando incluída, deverá conter o número de mensagem da mensagem ACT precedente.

7.3.3.1.7. Assumir-se-á a aceitação pela unidade ATC receptora das condições de transferência indicadas na mensagem REV, excepto se a unidade ATC receptora iniciar a coordenação para a sua alteração.

7.3.3.2. Formato das Mensagens de Revisão

7.3.3.2.1. Formato ICAO

Todas as mensagens de revisão incluem os tipos de campos 3, 7, 13, 14 e 16. Nesses campos incluem-se os seguintes tipos de revisão:

- incorporação de uma alteração à ETO no COP ou ao(s) nível(eis) de transferência através da inclusão dos dados revistos no campo 14;

- uma alteração ao Código SSR será incluída no campo 7;

- as alterações de rota, incluindo as alterações ao COP, serão incorporadas nos dados dos campos 14 e 15 incluídos no formato do campo 22 após os cinco campos iniciais. Estas mensagens incluirão dois campos 14, o primeiro contendo apenas o elemento a), o COP através do qual o voo foi previamente coordenado. As regras para a coordenação destas alterações, incluindo as rotas directas, são especificadas no Anexo B, Requisitos de Processamento de Rotas Especiais;

- as modificações aos campos 8, 10 e 18 serão incorporadas como dados do campo 22 após os cinco campos iniciais.

7.3.3.2.2. Formato ADEXP

Todas as mensagens de revisão no formato ADEXP deverão incluir os seguintes campos primários: Title Refdata Arcid ADEP ADES. Aplicam-se as seguintes regras:

- será incorporada uma alteração à ETO no COP ou ao(s) nível(eis) de transferência através da inclusão dos dados revistos no campo primário Coordata;

- as alterações de rota, incluindo as alterações ao COP, serão incorporadas nos campos primários Coordata e Route. Estas mensagens incluirão o campo primário COP contendo o Ponto de Coordenação através do qual o voo foi previamente coordenado. As regras para a coordenação destas alterações, incluindo as rotas directas, são especificadas no Anexo B;

- uma alteração ao código SSR será indicada através da inclusão do campo primário SSRCODE;

- as modificações a outros dados do plano de voo serão incorporadas pela inclusão do(s) campo(s) primário(s) requerido(s), tal como definido no Anexo A no que diz respeito a outras Informações do Plano de Voo.

Se uma mensagem de revisão for enviada para coordenar apenas o Código SSR e/ou Outras Informações do Plano de Voo, o campo primário COP será incluído no lugar de Coordata.

7.3.3.2.3. Código SSR

O Modo e o Código SSR serão incluídos numa mensagem REV apenas quando for necessário coordenar uma alteração do código SSR.

7.3.3.3. Processamento na Unidade Receptora

7.3.3.3.1. Se for recebida uma ACT para o voo em questão, proveniente da mesma unidade ATC, o sistema ATC que recebe uma mensagem REV deverá tentar a associação com o plano de voo correspondente.

7.3.3.3.2. Se for encontrado um plano de voo correspondente e não existirem discrepâncias na mensagem que possam inibir o processamento correcto;

- o conteúdo operacional será incluído no plano de voo;

- a informação necessária será enviada para o ATC operacional e para outras posições, conforme seja necessário.

7.3.3.4. Início da Transmissão

7.3.3.4.1. A mensagem REV é actuada pelos acontecimentos e será transmitida imediatamente a seguir à entrada ou actualização pertinente.

7.3.3.4.2. Logo que o voo se encontrar a uma distância/tempo especificado do ponto de transferência, nenhumas alterações poderão tornar-se efectivas pela utilização da mensagem REV. Os parâmetros de tempo e distância serão objecto de acordo bilateral.

7.3.3.4.3. Recomendação

Os parâmetros REV deveriam ser definidos separadamente para cada um dos COP.

7.3.3.5. Alteração da Unidade ATC Receptora

A mensagem REV não deverá ser utilizada, caso uma revisão da informação do plano de voo provoque uma alteração da unidade ATC receptora (ver Mensagem de Revogação da Coordenação).

7.3.4. Confirmação da REV

7.3.4.1. Confirmação

Se a mensagem REV:

- puder ser associada a um plano de voo no âmbito do sistema receptor, será transmitida uma mensagem LAM em confirmação;

- não puder ser associada a um plano de voo no âmbito do sistema receptor, não será transmitida nenhuma mensagem LAM.

7.3.4.2. Não Confirmação

7.3.4.2.1. Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem REV, será apresentado um alerta na posição ATC responsável pela coordenação dos voos.

7.3.4.2.2. Nos casos de inexistência de mensagem LAM, será iniciada uma revisão verbal pela unidade ATC transferidora.

7.3.5. Exemplos

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. Mensagem de Revogação da Coordenação (MAC)

7.4.1. Finalidade da Mensagem MAC

A mensagem MAC é utilizada para indicar à unidade receptora a revogação da coordenação ou notificação previamente efectuada.

A MAC não substitui a mensagem de Cancelamento (CNL), tal como definida pela ICAO, não sendo assim utilizada para apagar a informação básica do plano de voo.

7.4.2. Conteúdo da Mensagem

A mensagem MAC deverá conter os seguintes dados:

- Tipo de Mensagem,

- Número da Mensagem;

- Referência da Mensagem (opcional);

- Identificação da Aeronave;

- Aeródromo de Partida;

- Ponto de Coordenação;

- Aeródromo de Destino;

- Estado e Razão da Coordenação (opcional).

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos, são especificados no Anexo A.

7.4.3. Regras de Aplicação

7.4.3.1. Generalidades

7.4.3.1.1. Será enviada uma mensagem MAC a uma unidade com a qual tenha sido previamente efectuada a coordenação de um voo, através da utilização de uma mensagem ACT ou RAP, quando ocorrer uma das seguintes situações:

- o nível esperado no ponto de transferência é diferente do nível indicado na mensagem antecedente, resultando numa alteração da unidade seguinte na sequência da coordenação;

- a rota do voo foi modificada, resultando numa alteração da unidade seguinte na sequência de coordenação;

- o plano de voo do sistema é cancelado na unidade expedidora, deixando de ser aplicável a coordenação;

- é recebida uma MAC da unidade antecedente relativa ao voo.

7.4.3.1.2. Quando a mensagem MAC é enviada em resultado de alteração do nível de voo ou da rota, será efectuada a notificação e/ou coordenação, conforme adequado, com a nova unidade na sequência de coordenação.

7.4.3.1.3. Será enviada uma mensagem MAC quando for revogada a coordenação de um voo que parte, em resultado da utilização de uma mensagem PAC.

7.4.3.1.4. Recomendação

Deveria ser enviada uma mensagem MAC quando a notificação (mensagem ABI) previamente efectuada para um voo for cancelada devido a qualquer uma das razões especificadas no parágrafo 7.4.3.1.1 supra, ou quando o voo sofre um atraso em rota e não puder ser determinada automaticamente uma estimativa revista.

7.4.3.1.5. Será incluída a referência da mensagem, se tal for objecto de acordo bilateral.

7.4.3.1.6. Se incluída, a referência da mensagem deverá conter o número da última mensagem ABI, PAC ou ACT transmitida para o voo e confirmada.

7.4.3.1.7. O ponto de coordenação será o COP através do qual o voo foi previamente notificado ou coordenado.

7.4.3.1.8. Recomendação

A mensagem MAC deveria identificar o estado para que reverte a coordenação ou notificação e a razão da revogação.

7.4.3.1.9. Se incluída, o estado e a razão serão uma das seguintes combinações:

- quando a unidade receptora deixa de ser o próximo parceiro de coordenação:

- o estado é INI (inicial);

- a razão é uma das seguintes:

- TFL se a razão for uma alteração do nível de transferência;

- RTE se a razão for uma alteração de rota;

- CSN se a razão for uma alteração do identificador de chamada;

- CAN se a razão for um cancelamento;

- OTH para qualquer outra razão ou se a razão for desconhecida;

- quando se aplica uma das seguintes condições:

- a coordenação efectuada através da utilização da mensagem PAC ou ACT antecedente (conforme modificada por qualquer mensagem REV subsequente) é revogada mas prevê-se que o voo seja objecto de uma nova sequência de coordenação com a mesma unidade;

ou

- no seguimento da transmissão de uma mensagem ABI, o voo está em situação de espera por um período indefinido e prevê-se que seja sujeito a uma ABI ou ACT revista, conforme adequado:

- o estado é NTF (notificação);

- a razão é uma das seguintes:

- DLY se a razão for um atraso;

- HLD se a razão for uma espera;

- OTH para qualquer outra razão, ou se a razão for desconhecida.

7.4.3.1.10. Se o voo vai ser novamente notificado ou novamente coordenado:

- será enviada uma nova mensagem de notificação e/ou de coordenação, conforme aplicável;

- a informação básica do plano de voo armazenada na unidade ATC receptora não será afectada por uma mensagem MAC;

- o sistema deverá manter a capacidade de processar correctamente uma nova mensagem de notificação e/ou de coordenação proveniente da unidade transferidora precedente ou de uma unidade diferente numa nova sequência de coordenação.

7.4.3.2. Processamento na Unidade Receptora

A posição ou posições de trabalho na unidade ATC receptora que disponham de detalhes do voo, serão notificadas da revogação.

7.4.4. Confirmação de uma MAC

7.4.4.1. Confirmação

7.4.4.1.1. Se a mensagem MAC puder ser associada a um plano de voo no sistema receptor e puder ser processada, será transmitida uma mensagem LAM em confirmação.

7.4.4.1.2. Se a mensagem MAC não puder ser associada a um plano de voo no sistema receptor, ou não puder ser processada, não será transmitida nenhuma mensagem LAM.

7.4.4.2. Não Confirmação

7.4.4.2.1. Se a coordenação ATC estiver em processo de revogação e não for recebida uma mensagem LAM, será apresentado um alerta na posição ATC responsável pela coordenação.

7.4.4.2.2. Neste casos será efectuada uma revogação verbal de coordenação pela unidade ATC transferidora.

7.4.5. Exemplos

O ACC de Amesterdão enviou uma mensagem ABI para o ACC de Bruxelas relativa ao voo HOZ3188, planeado para o FL190; subsequentemente, o voo solicita a subida para o FL270 e é autorizado, entrando assim no espaço aéreo de Maastricht em vez de no de Bruxelas. Os exemplos 7.4.5.1 a e 7.4.5.2 a, mostram como a MAC enviada de Amesterdão para Bruxelas apareceria nos formatos ICAO e ADEXP.

É enviada para Maastricht uma mensagem ABI e, mais tarde, uma ACT, mas poucos minutos antes de chegar ao COP, a aeronave regressa ao Aeroporto de Amesterdão e o plano de voo é cancelado no sistema da unidade emissora; é enviada uma MAC para Maastricht, tal como indicado nos exemplos (7.4.5.1 b e 7.4.5.2 b)

7.4.5.1. ICAO

a. (MACAM/BC112-HOZ3188-EHAM-NIK-LFPG-18/STA/INITFL)

b. (MACAM/MC096-HOZ3188-EHAM-NIK-LFPG-18/STA/INICAN)

7.4.5.2. ADEXP

a. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC BC -SEQNUM 112 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON TFL

b. -TITLE MAC -REFDATA -SENDER -FAC AM -RECVR -FAC MC -SEQNUM 096 -ADEP EHAM -COP NIK -ADES LFPG -ARCID HOZ3188 -CSTAT -STATID INI -STATREASON CAN

7.5. Mensagem de Atribuição de Código SSR (COD)

7.5.1. Finalidade da Mensagem COD

7.5.1.1. O Método de Atribuição de Códigos por Região de Origem (ORCAM) existe para permitir a um voo responder o mesmo código às mesmas unidades inseridas numa área participante. Se a atribuição de códigos não for efectuada de forma centralizada como, por exemplo, por um ACC, os aeroportos poderão necessitar da atribuição de um conjunto de códigos SSR discretos. Estas atribuições resultam num gasto muito grande de códigos.

7.5.1.2. A mensagem COD satisfaz o requisito operacional da emissão de um código SSR Modo A por uma Unidade do Serviço de Tráfego Aéreo para outra para um voo específico, quando solicitado. Uma funcionalidade opcional permite à unidade emissora a inclusão da rota do voo, se tal for objecto de acordo bilateral.

7.5.2. Conteúdo da Mensagem

A mensagem COD deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem (opcional);

- Identificação da aeronave;

- Modo e código SSR;

- Aeródromo de partida;

- Aeródromo de destino;

- Rota (opcional).

NOTA

As regras de inserção de dados, os formatos e os conteúdos dos campos são especificados no Anexo A.

7.5.3. Regras de Aplicação

7.5.3.1. Generalidades

7.5.3.1.1. Será gerada e transmitida automaticamente uma mensagem COD em resposta a um pedido de atribuição de código recebido numa mensagem.

7.5.3.1.2. O código SSR será o código atribuído ao voo.

7.5.3.1.3. Se não estiver disponível um código discreto, será inserido o código de saturação aprovado, tal como especificado no Plano de Navegação Aérea para a Região Europeia.

7.5.3.1.4. Se for acordado bilateralmente, será incluída a referência da mensagem, contendo o número da mensagem à qual a mensagem COD responde.

7.5.3.1.5. Se for acordado bilateralmente, será incluída a rota.

7.5.3.1.6. Assumir-se-á a aceitação do código SSR pela unidade que recebe a mensagem COD.

7.5.3.2. Processamento na Unidade Receptora

7.5.3.2.1. Será enviada uma LAM, se não existir qualquer discrepância na mensagem que iniba o seu processamento correcto.

7.5.3.2.2. Se a mensagem não puder ser associada a um plano de voo ou for encontrada uma discrepância que iniba o processamento correcto da mensagem, não será enviada nenhuma LAM em resposta.

7.5.3.2.3. A informação de rota, se incluída, não será razão para inibir o envio de uma LAM em resposta, excepto se aquela informação não estiver em conformidade com o requisito de formatação especificado no Anexo A.

7.5.3.3. Parâmetros de Tempo para a Transmissão

Não será aplicável um parâmetro de tempo para a transmissão, uma vez que a mensagem COD é enviada em resultado da recepção de uma mensagem solicitando a atribuição de um código SSR.

7.5.4. Confirmação da COD

7.5.4.1. Confirmação

A mensagem COD será confirmada pela geração e transmissão de uma mensagem LAM.

7.5.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem LAM em confirmação de uma mensagem COD, será apresentado um alerta na posição apropriada.

7.5.5. Exemplos

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. Mensagem de Informação (INF)

7.6.1. Finalidade da mensagem INF

7.6.1.1. A mensagem INF é utilizada para fornecer informação sobre voos específicos a agências não envolvidas directamente no processo de coordenação entre duas unidades ATC sucessivas na rota do voo.

7.6.1.2. A mensagem INF pode ser utilizada para fornecer cópias de mensagens e para comunicar condições de coordenação acordadas a essas agências no seguimento de um diálogo entre controladores. Para este fim, as mensagens INF podem ser geradas pelos sistemas nas unidades que transferem e que aceitam.

7.6.1.3. A mensagem pode também ser utilizada para fornecer informação a uma agência relativamente a qualquer ponto na rota de um voo.

7.6.1.4. O formato permite a comunicação de informação inicial, de revisões e de cancelamentos.

7.6.2. Conteúdo da Mensagem

A mensagem INF deverá conter os seguintes dados no formato de uma mensagem descrita no presente documento.

- Tipo de mensagem;

- Número da mensagem;

- Todos os dados operacionais contidos na mensagem original ou resultantes da coordenação copiada;

- Tipo da Referência da Mensagem.

NOTA

As regras de inserção de dados, os formatos e os conteúdos dos campos são especificados no Anexo A.

7.6.3. Regras de Aplicação

7.6.3.1. Tipos de Mensagens

O(s) tipo(s) de mensagem(ns) a duplicar por uma mensagem INF, serão baseados nos requisitos dos utilizadores e nas capacidades da unidade emissora. O(s) tipo(s) de mensagem(ns), bem como as regras de aplicação serão, geralmente, objecto de acordo bilateral.

7.6.3.2. Destinatários das Mensagens

Podem ser transmitidas uma ou mais mensagens INF relativas a um mesmo voo, a um ou mais destinatários.

7.6.3.3. Conteúdo Operacional

O conteúdo operacional da mensagem INF será no formato de uma das mensagens existentes.

7.6.3.4. Recomendações

1. As condições enviadas numa mensagem de diálogo inicial (p. ex. mensagens ACT, RAP, REV e RRV) podem ser alteradas ou rejeitadas antes de o diálogo se completar. As unidades emissoras deveriam ser capazes de enviar as condições de coordenação finais acordadas.

2. A mensagem INF deveria ser enviada imediatamente, ou num instante relacionado com a hora no COP, que seja objecto de acordo bilateral com a agência receptora.

7.6.4. Confirmação da INF

Recomendações

1. Dependendo do parceiro de coordenação, a mensagem INF pode ser confirmada pela geração e transmissão de uma mensagem LAM.

2. Sujeito a acordo bilateral entre as unidades envolvidas, se não for recebida uma mensagem LAM em confirmação de uma mensagem INF, deve ser apresentado um alerta na posição apropriada.

7.6.5. Exemplo

Um voo com o indicativo de chamada BAW011, B747 proveniente de EGLL com destino a OMDB a FL290, solicitando FL410, estima o VOR de Koksy (KOK) às 1905, com código de transponder A5437, prosseguindo via UG1 e UB6.

É enviada uma mensagem ACT de Londres para Maastricht relativa ao voo. É enviada uma cópia de Londres para uma unidade identificada como IT.

Abaixo, mostram-se exemplos da mensagem INF.

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. PROCEDIMENTO DE DIALOGO - COORDENAÇÃO

8.1. Generalidades

8.1.1. Introdução

8.1.1.1. O procedimento de diálogo fornece as funcionalidades para a comunicação e negociação entre controladores na fase de coordenação e de comunicação na fase de transferência.

8.1.1.2. A presente secção descreve as mensagens utilizadas no procedimento de diálogo durante a fase de coordenação onde são planeadas as condições de transferência. As mensagens para a fase de transferência em que a entrega do voo é concretizada, são descritas na Secção 9 - Procedimento de Diálogo - Transferência de Comunicação.

8.1.1.3. Os procedimentos para as duas fases não são dependentes entre si, podendo ser aplicados individual ou conjuntamente.

8.1.1.4. Apresentam-se diversas mensagens adicionais e é suportada a capacidade de cada um dos parceiros iniciar um diálogo.

8.1.1.5. O procedimento do diálogo de coordenação permite a identificação de:

- transferências que estão em conformidade com as LoA e podem ser aceites automaticamente, e

- daquelas que exigem o envio ao controlador na unidade receptora para uma decisão quanto à aceitação.

8.1.1.6. Este procedimento permite também a monitorização da interpretação das LoA nos dois sistemas e a identificação de qualquer discrepância entre elas.

8.1.2. O Filtro

8.1.2.1. Generalidades

8.1.2.1.1. O procedimento de diálogo de coordenação exige que o sistema identifique se as transferências estão ou não em conformidade com as LoA.

8.1.2.1.2. O processo que verifica esta conformidade é designado no presente documento como "o filtro". A base de dados usada para o filtro incluirá o seguinte, se necessário:

- pontos de coordenação acordados;

- níveis de voo elegíveis (ou não elegíveis) que podem também ser associados aos pontos de coordenação;

- aeródromos de partida;

- destinos;

- rotas directas acordadas;

- limites de tempo e/ou de distância antes do COP, após os quais qualquer mensagem de coordenação é considerada como não normalizada;

- quaisquer outras condições acordadas bilateralmente.

8.1.2.1.3. Todos os itens nesta lista podem ser combinados para definir condições mais complexas.

8.1.2.1.4. Na Secção 8 do presente documento, o termo "condições normalizadas" será interpretado como "em conformidade com a LoA" e o termo "condições não normalizadas" como "não conforme com a LoA". Excepto se acordado bilateralmente, as mensagens enviadas por unidades transferidoras relativas a coordenações que se sabe serem normalizadas, utilizarão tipos de mensagens diferentes dos tipos para os quais as condições não são normalizadas.

8.1.2.2. Acção na Unidade Transferidora

8.1.2.2.1. O filtro na unidade transferidora deverá analisar as condições de transferência que vão ser enviadas para a unidade aceitante.

8.1.2.2.2. Recomendação

Se se determinar que as condições de transferência não são normalizadas, esse facto deveria ser levado ao conhecimento do controlador de transferência, para confirmação ou modificação.

8.1.2.3. Acção na Unidade Aceitante

8.1.2.3.1. Todas as mensagens ACT e REV devem ser verificadas em relação ao filtro.

8.1.2.3.2. Se a verificação indicar que as condições de transferência recebidas não são normalizadas, então estas devem ser remetidas ao controlador para ser tomada uma decisão. Caso contrário, serão aceites automaticamente.

8.1.2.4. Sincronização dos Filtros

8.1.2.4.1. A utilização de mensagens diferentes para condições de transferência normalizadas e não normalizadas permite a identificação de quaisquer discrepâncias entre as condições normalizadas contidas nos sistemas nas unidades transferidoras e aceitantes.

8.1.2.4.2. A identificação na unidade aceitante, das condições de transferência não normalizadas numa mensagem utilizada apenas para a coordenação de transferências normalizadas, causará uma discrepância entre os dois filtros. Estas discrepâncias devem ser resolvidas para a operação efectiva do procedimento de diálogo.

8.1.3. Sequência das Mensagens

8.1.3.1. Generalidades

8.1.3.1.1. É necessário cumprir determinadas regras de modo a garantir que a coordenação está completa antes de ter lugar qualquer revisão ou troca de mensagens de comunicação de transferência, e também para garantir que os controladores em ambas as unidades não fazem propostas simultâneas para o mesmo voo.

8.1.3.1.2. Uma unidade ATC só deverá transmitir ou confirmar a recepção de uma mensagem de revisão (REV ou RRV) para um voo quando se encontra no estado coordenado, ou seja, quando um diálogo ACT ou RAP foi completado por uma LAM ou ACP.

8.1.3.1.3. As mensagens CDN serão apenas elegíveis para transmissão pela unidade aceitante.

8.1.3.1.4. As mensagens CDN serão apenas transmitidas e confirmadas:

- como parte de um diálogo iniciado pela recepção de uma mensagem de Activação (ACT, RAP) ou de Revisão (REV ou RRV); ou

- quando o plano de voo para o voo em questão se encontra no estado coordenado.

8.1.4. Tratamento de Mensagens Simultâneas

8.1.4.1. Generalidades

8.1.4.1.1. Uma unidade envolvida numa troca de mensagens de transferência ou de coordenação para um voo, não deverá iniciar uma outra troca de mensagens de transferência ou de coordenação para o mesmo voo com a mesma unidade até receber uma LAM, ACP ou RJC, ou até à expiração de um prazo.

8.1.4.1.2. É possível que uma mensagem CDN se cruze com uma mensagem REV, RRV ou MAC para o mesmo voo enviada pela unidade transferidora. Esta situação pode ser identificada na unidade transferidora quando a CDN chega antes da confirmação da mensagem de coordenação transmitida e, na unidade aceitante, quando a mensagem proveniente da unidade transferidora chega antes da confirmação da CDN. Neste caso a CDN não deverá ser confirmada, devendo ser processada a REV, RRV ou MAC.

8.1.5. Rejeição de Tratamento

A mensagem RJC conclui um diálogo de sistema. Terá de ser iniciada uma nova coordenação de sistema que reflicta a coordenação telefónica nos casos em que seja aplicável.

8.1.6. Expiração do Tempo de Resposta Operacional

8.1.6.1. Generalidades

8.1.6.1.1. Nos centros receptores e emissores deve ser aplicado um mecanismo de expiração de tempo para as respostas às mensagens remetidas ao controlador.

8.1.6.1.2. A duração destes períodos de expiração deverá ser objecto de acordo bilateral.

8.1.6.1.3. O expirar do tempo na unidade transferidora deverá resultar num alerta enviado ao controlador de transferência, para indicar a necessidade de iniciar uma coordenação telefónica.

8.1.6.1.4. Recomendações

1. Deveria ser visualizado um alerta na posição ATC na unidade aceitante responsável pelo voo, quando está iminente a expiração de tempo na unidade transferidora.

2. O alerta deveria ter em conta o tempo para a transmissão da resposta.

8.1.6.1.5. Os sistemas deverão ser capazes de processar respostas que sejam recebidas após a expiração do tempo.

8.1.7. Implementação

8.1.7.1. Os procedimentos de diálogo dirigem-se a duas fases, nomeadamente a fase de coordenação e a fase de transferência. O diálogo nas duas fases utiliza mensagens diferentes, sendo também diferentes os tempos de transacção requeridos. As mensagens de coordenação são especificadas nos formatos ICAO e ADEXP, e a transferência de mensagens de comunicação apenas no ADEXP.

8.1.7.2. Os requisitos HMI mínimos para o diálogo de coordenação são diferentes desses mesmos requisitos para o diálogo de transferência:

- o diálogo de transferência dirige-se principalmente à função de controlo executivo e exige um HMI rápido e "amigo do utilizador";

- o diálogo de coordenação não é crítico no tempo, pelo que os requisitos do seu HMI são de ordem inferior.

8.1.7.3. O procedimento de diálogo será implementado utilizando um dos seguintes cenários alternativos:

- procedimento de diálogo na fase de coordenação mais quaisquer mensagens complementares acordadas bilateralmente (Secções 7 e 8);

- procedimento de coordenação básico e procedimento de diálogo na fase de transferência (Secções 6, 7 e 9);

- procedimento de diálogo na fase de transferência e de coordenação mais quaisquer mensagens de coordenação complementares acordadas bilateralmente (Secções 7, 8 e 9).

A mensagem Avançada de Informação de Fronteira será enviada em todos os cenários.

8.1.7.4. O cenário usado para a implementação será objecto de acordo bilateral.

8.2. Mensagem de Activação (ACT)

8.2.1. Finalidade da Mensagem ACT

A finalidade da mensagem ACT encontra-se descrita no parágrafo 6.3.1. Num procedimento de diálogo, a mensagem ACT é utilizada para satisfazer esses requisitos, desde que as condições de transferência para o voo sejam normalizadas e que o controlador transferidor não queira remeter o voo ao controlador aceitante para a respectiva aceitação.

8.2.2. Conteúdo da Mensagem

O conteúdo da mensagem ACT utilizada no procedimento de diálogo será como descrito no parágrafo 6.3.2.

8.2.3. Regras de Aplicação

8.2.3.1. Generalidades

8.2.3.1.1. As regras de aplicação são as descritas no parágrafo 6.3 com excepção das regras especiais descritas neste parágrafo.

8.2.3.1.2. Será enviada uma mensagem ACT para um voo com condições de transferência normalizadas ao qual o controlador transferidor não exija o seu remetimento ao controlador aceitante.NOTA

Se estes requisitos não se aplicarem, é enviada uma mensagem RAP (ver parágrafo 8.3, Mensagem de Proposta de Activação Remetida).

8.2.3.1.3. Recomendação

Deveria ser iniciado um novo procedimento de coordenação se em resposta a uma mensagem ACT fosse recebida uma mensagem de Rejeição de Coordenação (RJC).

8.2.3.2. Processamento na Unidade Receptora

8.2.3.2.1. A mensagem é verificada em relação ao filtro para confirmar que as condições propostas são normalizadas.

8.2.3.2.2. A mensagem será processada como uma mensagem RAP se:

- se determinar que as condições de transferência não são normalizadas;

- não puder ser encontrado um plano de voo correspondente e não exista suficiente informação disponível para identificar se as condições de transferência são ou não normalizadas.

8.2.3.2.3. As mensagens ACT normalizadas serão processadas em conformidade com o parágrafo 6.3.3.2.

8.2.3.2.4. Recomendação

Se se determinar que as condições de transferência numa mensagem ACT não são normalizadas, existe uma discrepância entre os filtros nos dois sistemas. O facto de a ACT não ser normalizada deveria ser levado ao conhecimento do pessoal supervisor para a resolução da discrepância.

8.2.4. Confirmação da ACT

8.2.4.1. Confirmação

8.2.4.1.1. Num procedimento de diálogo, uma mensagem ACT deve ser confirmada por:

- uma LAM, se as condições de transferência forem normalizadas;

- uma mensagem SBY, nos restantes casos.

8.2.4.1.2. Quando tiver sido recebida uma LAM, o conteúdo operacional da mensagem ACT deve tornar-se operacionalmente vinculativo para ambas as unidades ATC.

8.2.4.1.3. Quando acordado bilateralmente, pode ser usada uma ACP em lugar de uma LAM para indicar a aceitação de uma ACT contendo condições de transferência normalizadas pela unidade aceitante.

8.2.4.2. Casos de Não Confirmação

Se não for recebida confirmação a uma mensagem ACT, deverá ser apresentado um alerta na posição ATC responsável pela coordenação do voo.

8.3. Mensagem de Proposta de Activação Remetida (RAP)

8.3.1. Finalidade da Mensagem RAP

A mensagem RAP satisfaz os seguintes requisitos operacionais, além dos especificados para a mensagem ACT no parágrafo 6.3.

- a proposta pelo controlador transferidor e remetimento para o controlador aceitante dos voos com condições de transferência não normalizadas;

- permitir ao controlador transferidor, se o desejar, forçar o remetimento ao controlador aceitante, de condições de transferência normalizadas para um voo específico.

8.3.2. Conteúdo da Mensagem

A mensagem RAP conterá a mesma informação da mensagem ACT (parágrafo 6.3) e pode, em opção, incluir os seguintes dados:

- razão, indicando o remetimento manual (só disponível na ADEXP).

8.3.3. Regras de Aplicação

8.3.3.1. Generalidades

8.3.3.1.1. Será enviada uma mensagem RAP em substituição de uma mensagem ACT para voos que atravessem a fronteira e que cumpram uma das seguintes condições:

- o sistema transferidor determinou que as condições de transferência não são normalizadas;

- o controlador transferidor indicou que as condições de transferência propostas devem ser remetidas ao controlador aceitante.

8.3.3.1.2. O conteúdo operacional da mensagem RAP a transmitir deverá ser apresentado na posição de trabalho responsável pela coordenação do voo, antes da sua transmissão.

8.3.3.1.3. Recomendação

A hora em que a mensagem RAP é transmitida automaticamente deveria ser apresentada juntamente com o seu conteúdo.

8.3.3.1.4. A posição de trabalho correspondente deve ser notificada da transmissão da mensagem RAP.

8.3.3.2. Processamento na Unidade Receptora

8.3.3.2.1. O sistema ATC que recebe uma mensagem RAP deverá tentar a sua associação com o correspondente plano de voo.

8.3.3.2.2. Se for encontrado um plano de voo correspondente e não existirem discrepâncias na mensagem que inibam o seu processamento correcto:

- o conteúdo operacional deve ser remetido ao controlador aceitante;

- deve ser enviada uma SBY.

8.3.3.2.3. Recomendação

Deveria ser incluída uma indicação da razão para o remetimento (condições não normalizadas ou remetimento manual).

8.3.3.2.4. Se a mensagem não puder ser associada a um plano de voo, ou for encontrada uma discrepância que iniba o processamento correcto da mensagem, então:

- o conteúdo operacional da mensagem deve ser visualizado no sector;

e

- deve ser enviada uma SBY;

e

- deve ser criado um plano de voo.

8.3.3.2.5. Nos restantes casos, a mensagem não deve ser confirmada.

8.3.3.3. Activação Manual

8.3.3.3.1. Quando a RAP for usada para forçar o remetimento ao controlador aceitante de uma proposta de coordenação com condições de transferência normalizadas, ela será iniciada manualmente pelo controlador transferidor e transmitida imediatamente.

8.3.3.3.2. Recomendação

A activação manual de uma mensagem RAP antes da hora calculada para a transmissão deveria ser permitida na posição responsável pela coordenação do voo.

8.3.3.4. Parâmetros de Tempo para a Transmissão Automática

O tempo/distância antes da fronteira onde as mensagens RAP são transmitidas automaticamente, deverá ser igual ao utilizado nas mensagens ACT.

8.3.4. Confirmação da RAP

8.3.4.1. Confirmação

A mensagem deve ser confirmada pela geração e transmissão de uma mensagem SBY.

8.3.4.2. Caso de Não Confirmação

Se não for recebida uma mensagem SBY em confirmação de uma mensagem RAP, deverá ser apresentado um alerta na posição ATC responsável pela coordenação do voo.

8.3.5. Resposta Operacional à RAP

O controlador aceitante pode aceitar, contrapropor ou rejeitar as condições de transferência.

8.3.5.1. Aceitação

8.3.5.1.1. Quando o controlador aceitante decide aceitar as condições de transferência propostas, deve ser enviada uma mensagem ACP em resposta.

8.3.5.1.2. Logo que a mensagem ACP for recebida, a informação da mensagem RAP torna-se operacionalmente vinculativa para ambas as unidades ATC. As condições de transferência coordenadas, bem como o facto de ter sido recebida a ACP, serão apresentados ao controlador transferidor.

8.3.5.2. Contraproposta

Quando o controlador aceitante decide efectuar uma contraproposta de condições de transferência, será enviada em resposta uma mensagem CDN.

8.3.5.3. Recomendação

Quando o controlador aceitante decide rejeitar as condições de transferência propostas, deve ser enviada em resposta uma mensagem RJC. Deve ser então iniciado um novo processo de coordenação.NOTA

Relativamente à recomendação em 8.3.5.3, na maioria dos casos a nova coordenação será feita com uma unidade diferente.

8.3.6. Exemplos

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. Mensagem de Revisão (REV)

8.4.1. Finalidade da Mensagem REV

A finalidade da mensagem REV encontra-se descrita no parágrafo 7.3.1. Num procedimento de diálogo, a mensagem REV é utilizada para cumprir esses requisitos desde que as condições de transferência para o voo sejam normalizadas e que o controlador transferido não exija que o voo seja remetido ao controlador aceitante para aceitação.

8.4.2. Conteúdo da Mensagem

O conteúdo da mensagem REV é o descrito no parágrafo 7.3.2.

8.4.3. Regras de Aplicação

8.4.3.1. Generalidades

8.4.3.1.1. Podem ser enviadas uma ou mais mensagens REV para a unidade com a qual um voo foi coordenado, através da utilização de uma mensagem de Activação ou RAP.

8.4.3.1.2. As mensagens REV serão enviadas nas condições especificadas no parágrafo 7.3.3.1 para os voos com condições de transferência normalizadas e para os quais o controlador transferidor não exige o seu remetimento ao controlador aceitante.

8.4.3.2. Início da Transmissão

A mensagem REV será transmitida imediatamente no seguimento da detecção de uma alteração na informação de coordenação que necessita de ser coordenada, tal como descrito no parágrafo 7.3.3.

8.4.3.3. Processamento na Unidade Receptora

8.4.3.3.1. Se for encontrado um plano de voo correspondente no estado coordenado e não for detectada nenhuma discrepância que iniba o processamento correcto da mensagem, então:

- a mensagem REV será confirmada;

- nos restantes casos, a mensagem não será confirmada.

8.4.3.3.2. As condições de transferência serão examinadas para confirmar que são normalizadas.

8.4.3.3.3. Se as condições de transferência não forem normalizadas, serão apresentadas ao controlador aceitante.

8.4.3.3.4. Se se determinar que as condições de transferência são normalizadas, elas serão incluídas no plano de voo e a informação necessária será apresentada no ATC operacional e em outras posições, conforme apropriado.

8.4.3.3.5. Recomendação

Se as condições de transferência numa mensagem REV forem consideradas não normalizadas, existe uma discrepância entre os filtros nos dois sistemas. O facto de a REV não ser normalizada deve ser levado ao conhecimento do pessoal supervisor para que a discrepância seja resolvida.

8.4.4. Confirmação da REV

8.4.4.1. Confirmação

8.4.4.1.1. Se a mensagem REV é para ser confirmada, essa confirmação será efectuada por:

- uma mensagem LAM, se as condições de transferência forem normalizadas;

- uma mensagem SBY, se as condições de transferência não forem normalizadas.

8.4.4.1.2. Quando tiver sido recebida uma LAM, o conteúdo operacional da mensagem REV deve tornar-se operacionalmente vinculativo para ambas as unidades ATC.

8.4.4.1.3. Quando acordado bilateralmente, pode ser usada uma ACP em substituição de uma LAM para indicar a aceitação, por uma unidade aceitante, de uma REV contendo condições de transferência normalizadas.

8.4.4.2. Casos de Não Confirmação

Se não for recebida confirmação a uma mensagem REV, deverá ser apresentado um alerta na posição ATC responsável pela coordenação dos voos.

8.4.5. Resposta Operacional à REV

Uma vez que a mensagem REV é utilizada para enviar condições de transferência normalizadas, ela será normalmente aceite pelo sistema na unidade aceitante. Se as condições de transferência forem detectadas como não normalizadas pelo filtro na unidade aceitante, a mensagem será processada como uma mensagem RRV.

8.5. Mensagem de Proposta de Revisão Remetida (RRV)

8.5.1. Finalidade da Mensagem RRV

A mensagem RRV servirá para a revisão de condições de transferência previamente enviadas e acordadas nos seguintes casos:

- quando as condições de transferência propostas na revisão não são normalizadas;

- quando a revisão proposta é normalizada, mas o controlador transferidor pretende remeter a revisão ao controlador aceitante.

8.5.2. Conteúdo da Mensagem

O conteúdo da mensagem RRV será o descrito na mensagem REV (parágrafo 7.3.2) e pode, em opção, conter o seguinte elemento de informação:

- razão, indicando remetimento manual (só disponível no formato ADEXP).

8.5.3. Regras de Aplicação

8.5.3.1. Generalidades

Para cada revisão, serão enviadas uma ou mais mensagens RRV, em vez de mensagens REV, se:

- o sistema transferidor determinou que as condições de transferência não são normalizadas;

ou

- o controlador transferidor indicou que as condições de transferência propostas devem ser remetidas ao controlador aceitante. A utilização da RRV é opcional.

8.5.3.2. Início da Transmissão

A mensagem RRV será transmitida imediatamente após a detecção de uma alteração nos dados de coordenação ou quando iniciada manualmente.

8.5.3.3. Processamento na Unidade Receptora

8.5.3.3.1. Se for encontrado um plano de voo correspondente no estado coordenado e não for detectada nenhuma discrepância que iniba o processamento correcto da mensagem, então:

- a mensagem RRV será confirmada;

- nos restantes casos, a mensagem não será confirmada.

8.5.3.3.2. As condições de transferência propostas serão apresentadas na posição ATC responsável pela coordenação do voo.

8.5.3.3.3. Recomendação

Deveria ser incluída a razão do remetimento (condições não normalizadas ou remetimento manual).

8.5.4. Confirmação da RRV

8.5.4.1. Confirmação

A mensagem será confirmada pela geração e transmissão de uma mensagem SBY.

8.5.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem SBY em confirmação de uma mensagem RRV, deverá ser apresentado um alerta na posição ATC responsável pela coordenação do voo.

8.5.5. Resposta Operacional à RRV

O controlador aceitante pode aceitar, efectuar uma contraproposta ou rejeitar uma mensagem RRV.

8.5.5.1. Aceitação

Quando o controlador aceitante decide aceitar a alteração proposta às condições de transferência acordadas, deverá ser enviada uma mensagem ACP em resposta.

8.5.5.2. Contraproposta

Quando o controlador aceitante decide efectuar uma contraproposta às condições de transferência, deverá ser enviada uma mensagem CDN em resposta.

8.5.5.3. Rejeição

Quando o controlador aceitante decide rejeitar a alteração proposta às condições de transferência acordadas:

- deverá ser enviada uma mensagem RJC em resposta;

e

- deverá ter início um novo processo de coordenação.

Está implícita a rejeição se não for recebida qualquer ACP ou CDN em resposta à mensagem RRV.

8.5.6. Exemplos

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. Mensagem de Espera (SBY)

8.6.1. Finalidade da Mensagem SBY

A mensagem SBY confirma a recepção de uma mensagem propondo condições de transferência e indica que a proposta foi remetida ao controlador para ser tomada uma decisão.

8.6.2. Conteúdo da Mensagem

A mensagem SBY deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da mensagem

NOTA

As regras de inserção de dados, os formatos e o conteúdo dos campos encontram-se especificados no Anexo A.

8.6.3. Regras de Aplicação

8.6.3.1. Generalidades

A mensagem SBY será gerada e transmitida automática e imediatamente em resposta a:

- uma mensagem RAP, RRV ou CDN;

- uma mensagem ACT ou REV que não passe no filtro.

8.6.4. Confirmação da SBY

A mensagem SBY não será confirmada.

8.6.5. Exemplos

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. Mensagem de Aceitação (ACP)

8.7.1. Finalidade da Mensagem de Aceitação

A mensagem ACP satisfaz os seguintes requisitos operacionais durante as fases de coordenação e transferência ATC:

- indica a aceitação manual, por um controlador numa unidade, das condições de transferência propostas pelo controlador na outra unidade, numa das seguintes mensagens:

- RAP;

- RRV;

- CDN;

- ACT e REV, se ambas forem determinadas como não normalizadas;

- quando acordado bilateralmente, proporciona a aceitação automática de uma mensagem ACT ou REV que passou no filtro na unidade aceitante (em substituição da LAM);

- quando acordado bilateralmente, indica a aceitação manual de uma mensagem HOP (em substituição de uma mensagem ROF).

8.7.2. Conteúdo da Mensagem

A mensagem ACP é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deve conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da mensagem;

- Dados opcionais - a mensagem pode também incluir:

- Frequência;

- Dados opcionais das mensagens no formato ICAO - a mensagem pode também conter os seguintes dados:

- Identificação da Aeronave;

- Aeródromo de Partida;

- Aeródromo de Destino;

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

8.7.3. Regras de Aplicação

8.7.3.1. Generalidades

8.7.3.1.1. A Referência da Mensagem ACP deve incluir o Número da Mensagem à qual responde.

8.7.3.1.2. O campo Frequência, quando incluído, deverá conter a frequência na qual o voo deve contactar a unidade aceitante quando a transferência se efectuar.

8.7.3.1.3. A mensagem ACP deverá ser enviada no seguimento da aceitação manual pelo controlador das condições de transferência propostas, enviadas por uma ACT, RAP, REV, RRV ou CDN.

8.7.3.1.4. A mensagem ACP pode ser enviada em alternativa a uma mensagem ROF em resposta a uma mensagem HOP.

8.7.3.1.5. Quando acordado bilateralmente, a mensagem ACP deverá ser gerada e transmitida automaticamente pelo sistema, em resposta a uma ACT/REV que tenha passado no filtro.

8.7.3.1.6. Quando for recebida uma ACP, as condições de transferência acordadas serão vinculativas para ambas as unidades.

8.7.3.2. Processamento na Unidade Receptora

8.7.3.2.1. O sistema ATC que recebe uma mensagem ACP deve tentar a sua associação com o plano de voo correspondente.

8.7.3.2.2. Se a ACP puder ser associada a um plano de voo, a aceitação deverá ser indicada ao controlador.

8.7.3.2.3. Se a ACP não puder ser associada a um plano de voo:

- deverá ser apresentado um alerta na posição adequada;

- não será enviada nenhuma LAM.

8.7.4. Confirmação da ACP

8.7.4.1. Confirmação

8.7.4.1.1. Não deverá ser enviada uma LAM em resposta quando a ACP é usada como uma resposta automática a uma mensagem ACT ou REV que passou no filtro.

8.7.4.1.2. Uma mensagem ACP enviada em resultado de uma aceitação manual será confirmada pela geração e transmissão de uma mensagem LAM.

8.7.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem LAM em confirmação de uma mensagem ACP enviada em resultado de uma aceitação manual, deverá ser apresentado um alerta na posição ATC responsável pela coordenação do voo.

8.7.5. Exemplos

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. Mensagem de Coordenação (CDN)

8.8.1. Finalidade da Mensagem CDN

A mensagem CDN satisfaz os seguintes requisitos operacionais:

- envio de uma contraproposta do controlador aceitante ao controlador transferidor, em resposta a uma mensagem ACT, RAP, REV ou RRV;

- iniciar uma proposta de modificação às condições de transferência acordadas, pelo controlador aceitante ao controlador transferidor.

8.8.2. Conteúdo da Mensagem

A mensagem CDN é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem (apenas no caso de responder a outra mensagem);

- Identificação da Aeronave;

- Aeródromo de Partida;

- Aeródromo de Destino;

NOTA

A mensagem deverá também conter um dos seguintes dados, ou ambos:

- Informação Estimada (se for uma mensagem ICAO) ou Nível de Voo de Transferência (se for uma mensagem ADEXP);

- Pedido de Rota Directa.

- Dados acordados bilateralmente - Quando houver acordo bilateral, podem também ser incluídos os seguintes dados:

- Frequência.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

8.8.3. Regras de Aplicação

8.8.3.1. Generalidades

8.8.3.1.1. As mensagens CDN serão apenas iniciadas pelo controlador aceitante.

8.8.3.1.2. Serão utilizadas para transmitir uma contraproposta do controlador aceitante ao controlador transferidor.NOTA

Isto pode ser feito num diálogo em resposta a uma proposta enviada por uma ACT, RAP, REV ou RRV, ou como início de um diálogo para alterar condições de transferência previamente acordadas.

8.8.3.1.3. A referência da mensagem será inserida apenas quando a mensagem CDN responder a outra mensagem.

8.8.3.1.4. Quando inserida, a referência da mensagem deverá conter o número da mensagem à que a CDN responde.

8.8.3.1.5. A funcionalidade de Pedido de Rota Directa (descrita no Anexo A), deverá:

- ser apenas usada se acordada bilateralmente; e

- se acordada, definir quaisquer limites operacionais à sua utilização.

8.8.3.1.6. A CDN não deverá ser enviada após um determinado tempo/distância antes da fronteira especificada na LoA entre as duas unidades envolvidas.

8.8.3.1.7. No caso de uma CDN ser transmitida efectivamente em simultâneo com uma mensagem da unidade transferidora relativa ao mesmo voo, por exemplo, uma revisão ou uma revogação da coordenação, não deve ser enviada em resposta qualquer confirmação ou resposta operacional.NOTA

O efeito disto é que quando duas mensagens se cruzam, a mensagem da unidade transferidora tem prioridade e a CDN é abandonada por ambas. Ambas as unidades podem detectar a situação através da recepção da mensagem proveniente da outra, antes da recepção da confirmação.

8.8.3.1.8. Logo que seja recebida uma aceitação, a mensagem CDN torna-se operacionalmente vinculativa para ambas as unidades ATC. As condições de transferência coordenadas e o facto de a ACP ter sido recebida, deverão ser apresentadas ao pessoal do ATC envolvido.

8.8.3.2. Processamento na Unidade Receptora

8.8.3.2.1. Se for encontrado um plano de voo correspondente e não existir nenhuma discrepância na mensagem que iniba o processamento correcto:

- o conteúdo operacional será apresentado na posição ATC responsável pela coordenação do voo;

e

- será enviada uma SBY em resposta.

8.8.3.2.2. Se a CDN não puder ser associada, ou for encontrada uma discrepância que iniba o processamento correcto da mensagem, não será enviada uma SBY em resposta.

8.8.4. Confirmação da CDN

8.8.4.1. Confirmação

Nas condições acima especificadas, a mensagem CDN será confirmada pela geração e transmissão de uma mensagem SBY.

8.8.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem SBY em confirmação de uma mensagem CDN, será apresentado um alerta na posição ATC responsável pela coordenação do voo.

8.8.5. Resposta Operacional à CDN

O controlador pode aceitar ou rejeitar as condições de transferência propostas numa mensagem CDN.

8.8.5.1. Aceitação

Quando o controlador transferidor decide aceitar as condições de transferência propostas, deverá ser enviada uma mensagem ACP em resposta.

8.8.5.2. Recomendação

Quando o controlador transferidor decide rejeitar as condições de transferência propostas, deveria ser enviada uma mensagem RJC (rejeição explícita).

NOTA

A coordenação proposta é implicitamente rejeitada, se não for recebida uma aceitação até ao expirar do tempo da mensagem CDN.

8.8.6. Exemplos

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. Mensagem de Rejeição de Coordenação (RJC)

8.9.1. Finalidade da Mensagem RJC

A mensagem RJC indica a rejeição por um controlador numa unidade, das condições de transferência propostas pelo controlador na outra unidade, numa das seguintes mensagens:

- RAP;

- RRV;

- CDN;

- ACT e REV, se alguma for detectada como não normalizada.

A mensagem RJC pode apenas ser utilizada em resposta directa a uma das mensagens acima.

8.9.2. Conteúdo da Mensagem

A mensagem RJC deve conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Referência da Mensagem.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

8.9.3. Regras de Aplicação

8.9.3.1. Generalidades

8.9.3.1.1. A RJC será enviada, conforme necessário, em resposta a uma mensagem RAP, RRV, CDN ou a uma mensagem ACT ou REV que seja detectada como não normalizada na unidade aceitante.

8.9.3.1.2. A mensagem RJC termina o diálogo do sistema, mantendo-se válidas quaisquer condições de coordenação previamente acordadas.

8.9.3.1.3. Recomendação

No seguimento da recepção de uma mensagem RJC deve ser iniciada uma nova sequência de coordenação, reflectindo a coordenação telefónica, quando aplicável.

8.9.3.2. Processamento na Unidade Receptora

8.9.3.2.1. Se for encontrada uma mensagem correspondente referida pela mensagem RJC;

- a rejeição será indicada na posição ATC responsável pela coordenação do voo correspondente; e

- em resposta será enviada uma LAM em confirmação.

8.9.3.2.2. Se não for encontrada uma tal mensagem a aguardar resposta, ou se existir uma discrepância na mensagem que iniba o processamento, não será enviada nenhuma confirmação em resposta.

8.9.4. Confirmação da RJC

8.9.4.1. Confirmação

A mensagem RJC será confirmada pela geração e transmissão de uma mensagem LAM.

8.9.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem LAM em confirmação de uma mensagem RJC, deverá ser apresentado um alerta na posição ATC responsável pela coordenação dos voos.

8.9.5. Exemplos

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. PROCEDIMENTO DE DIÁLOGO - TRANSFERÊNCIA DE COMUNICAÇÃO

9.1. Generalidades

9.1.1. Introdução

9.1.1.1. A presente secção da Norma descreve as funcionalidades e as mensagens que suportam o aspecto da entrega radar do procedimento de transferência de controlo. Estas serão aplicadas através de acordo bilateral.

9.1.1.2. As funcionalidades da Transferência de Comunicação não serão implementadas, excepto se a unidade utilizar as funcionalidades de coordenação descritas na Secção 6 (Procedimento Básico - Mensagens Obrigatórias) ou as da Secção 8 (Procedimento de Diálogo - Coordenação).

9.1.1.3. As mensagens descritas na presente secção do documento encontram-se disponíveis apenas no formato ADEXP, não se prevendo que venham a estar disponíveis no formato ICAO.

9.1.2. Sequência das Mensagens

9.1.2.1. A permuta de mensagens de Transferência de Comunicação, para além da Mensagem de Informação Suplementar (SDM), só terá lugar depois de a coordenação ser completada, ou seja, até que um procedimento de diálogo ACT ou RAP tenha sido completado por uma LAM ou ACP.

9.1.2.2. Enquanto a coordenação estiver pendente, não será enviada uma confirmação em resposta.

9.1.3. Transferência de Comunicações

9.1.3.1. O método de exprimir a troca efectiva de comunicação de voos será objecto de acordo bilateral entre as duas unidades envolvidas.

9.1.3.2. As condições serão uma das abaixo especificadas, ou ambas:

- a unidade transferidora envia uma mensagem de Mudança de Frequência (COF);

- a unidade aceitante envia uma mensagem de Afectação Manual das Comunicações (MAS);

9.1.3.3. O método será acordado entre as duas unidades para cada fluxo de tráfego.NOTA

Podem ser usados métodos alternativos para fluxos diferentes. Por exemplo, uma unidade pode gerar mensagens COF para voos que saem do seu espaço aéreo e mensagens MAS para voos que entram no seu espaço aéreo. Neste caso, não seria necessário que a outra unidade enviasse qualquer mensagem para indicar a transferência de comunicação.

9.2. Mensagem de Início de Transferência (TIM)

9.2.1. Finalidade da Mensagem TIM

A finalidade da TIM é:

- assinalar o Início da Transferência (TI) (final da fase de coordenação e início da fase de transferência)

- simultaneamente, enviar informação de controlo executivo da unidade transferidora para a unidade aceitante.

9.2.2. Conteúdo da Mensagem

A mensagem TIM será constituída pelos seguintes itens:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Dados disponíveis - a mensagem deverá também conter qualquer um dos seguintes dados, se disponíveis:

- Nível de Voo Autorizado;

- Rumo Atribuído ou Autorização Directa;

- Velocidade Atribuída;

- Razão de Subida/Descida Atribuída;

- Dados opcionais - a mensagem poderá também conter:

- Posição.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.2.3. Regras de Aplicação

9.2.3.1. Generalidades

9.2.3.1.1. A mensagem TIM será gerada e transmitida pela unidade transferidora para a unidade aceitante sem intervenção humana, a uma distância/tempo de voo da fronteira acordados bilateralmente.

9.2.3.1.2. Será também enviada automaticamente uma mensagem TIM quando a mensagem de Pedido na Frequência (ROF) for recebida pela unidade transferidora.

9.2.3.1.3. Não será enviada uma TIM antes do voo ter sido coordenado.

9.2.3.1.4. A mensagem TIM deverá conter a informação mais recente disponível no sistema.

9.2.3.2. Parâmetros de Tempo para a Transmissão

9.2.3.2.1. O parâmetro de geração da TIM será um Parâmetro de Sistema Variável que pode ser alterado com base nas disposições das LoA.

9.2.3.2.2. Recomendação

O parâmetro de sistema para a geração da TIM deveria ser definido separadamente para cada um dos COP.

9.2.3.2.3. Os parceiros de coordenação deverão incluir nas suas LoA os parâmetros de geração da TIM.

9.2.3.2.4. O parâmetro de sistema que activa a mensagem TIM pode ser relacionado com a velocidade em relação ao solo calculada da aeronave. No entanto, o início de uma mensagem TIM deverá ocorrer sempre antes da posição actual do plano de voo se encontrar mais perto do COP do que a uma distância mínima especificada bilateralmente.

9.2.3.2.5. O parâmetro de sistema especificado para a transmissão da TIM deverá deixar tempo suficiente para a coordenação verbal antes da entrega.

9.2.3.3. Processamento na Unidade Receptora

9.2.3.3.1. A informação recebida numa TIM deve ser disponibilizada ao controlador aceitante.

9.2.4. Confirmação da TIM

9.2.4.1. Confirmação

Se a mensagem TIM:

- puder ser associada inequivocamente a um plano de voo, ela será confirmada pela geração e transmissão de uma mensagem LAM;

- não puder ser associada inequivocamente a um plano de voo, não será enviada confirmação.

9.2.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem LAM em confirmação de uma mensagem TIM, será apresentado um alerta na posição apropriada.

9.2.5. Exemplo

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

9.3. Mensagem de Informação Suplementar (SDM)

9.3.1. Finalidade da Mensagem SDM

9.3.1.1. Generalidades

9.3.1.1.1. A finalidade primária da SDM é transmitir informação de controlo e alterações às mesmas, da unidade transferidora para a unidade aceitante, desde que tenha sido acordado bilateralmente que as alterações não necessitam de ser confirmadas pelo controlador aceitante.

9.3.1.1.2. A mensagem SDM também pode ser utilizada pela unidade aceitante para notificar a unidade transferidora da frequência de rádio para a qual o voo é transferido.

9.3.2. Conteúdo da Mensagem

9.3.2.1. Mensagens da Unidade Transferidora

A mensagem SDM é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Dados adicionais - a mensagem deverá também conter um ou mais dos seguintes dados:

- Rumo Atribuído ou Autorização Directa;

- Velocidade Atribuída

- Razão de Subida/Descida Atribuída;

- Nível de Voo Autorizado.

9.3.2.2. Mensagens da Unidade Aceitante

A SDM deverá conter os seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Frequência.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.3.3. Regras de Aplicação

9.3.3.1. Mensagens da Unidade Transferidora

9.3.3.1.1. As mensagens SDM serão transmitidas após o início da fase de transferência (ver TIM, parágrafo 9.2) no seguimento de qualquer alteração aos seguintes itens:

- nível de voo autorizado;

- velocidade atribuída;

- razão de subida/descida atribuída;

- rumo atribuído; ou

- emissão ou alteração de autorização para o voo se dirigir directamente para um ponto especificado.

NOTA

A utilização da mensagem HOP é necessária quando é requerida a autorização pelo controlador aceitante antes da transferência da comunicação.

9.3.3.1.2. A mensagem deverá conter apenas os campos alterados.

9.3.3.1.3. As mensagens SDM contendo a informação descrita em 9.3.3.1.1 serão transmitidas antes da TI, se tal for objecto de acordo bilateral.

9.3.3.1.4. Estas mensagens deverão começar num instante de tempo relativo à TI acordado bilateralmente, desde que existam dados com valores disponíveis no sistema.

9.3.3.2. Mensagens da Unidade Aceitante

9.3.3.2.1. As mensagens SDM podem ser transmitidas para indicar a frequência na qual o voo deve contactar a unidade aceitante.NOTA

As unidades podem acordar bilateralmente o envio de outra informação. Esta transferência não está definida, nem faz parte da presente Norma.

9.3.3.2.2. As mensagens SDM provenientes da unidade aceitante serão transmitidas durante a fase de coordenação, se tal for acordado bilateralmente.

9.3.3.3. Processamento na Unidade Receptora

9.3.3.3.1. O sistema ATC que recebe uma mensagem SDM deve tentar a associação com o plano de voo correspondente.

9.3.3.3.2. Se for encontrado um plano de voo correspondente no estado coordenado:

- será enviada uma LAM em resposta;

- conteúdo operacional da mensagem SDM será disponibilizado ao controlador apropriado.

9.3.3.3.3. Se não puder ser encontrado um plano de voo correspondente, ou for detectada uma discrepância que iniba o processamento correcto da mensagem:

- não será enviada uma LAM em resposta; e

- será apresentado um alerta na posição apropriada.

9.3.4. Confirmação da SDM

9.3.4.1. Confirmação

A mensagem SDM será confirmada pela geração e transmissão de uma mensagem LAM.

9.3.4.2. Casos de Não Confirmação

Se não for recebida uma mensagem LAM em confirmação de uma mensagem SDM, será apresentado um alerta numa posição apropriada.

9.3.5. Exemplo

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

9.4. Proposta de Entrega (HOP)

9.4.1. Finalidade da Mensagem HOP

A Mensagem HOP serve:

- para o controlador transferidor chamar a atenção do controlador aceitante para um voo específico para efeitos de entrega;

- para o controlador transferidor efectuar a proposta de entrega do voo ao controlador aceitante, quando for necessário;

- enviar modificações à informação de controlo executivo que exigem a aprovação do controlador aceitante, tal como acordado bilateralmente.

Não é necessária a utilização da HOP para todos os voos, pois ela é usada à discrição do controlador transferidor.NOTA

Relativamente à alínea c) supra, a SDM é utilizada para enviar modificações à informação de controlo executivo que não exigem a aprovação do controlador aceitante.

9.4.2. Conteúdo da Mensagem

A mensagem HOP é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Dados disponíveis - a mensagem deverá conter também, se disponíveis:

- Nível de Voo Autorizado;

- Rumo Atribuído/Autorização Directa;

- Velocidade Atribuída;

- Razão de Subida/Descida Atribuída;

- Dados opcionais - a mensagem poderá também conter:

- Posição.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.4.3. Regras de Aplicação

9.4.3.1. Generalidades

9.4.3.1.1. A mensagem HOP, quando utilizada, deverá ser iniciada manualmente pelo controlador transferidor.

9.4.3.1.2. A mensagem deverá incluir qualquer informação de voo descrita no parágrafo 9.4.2 supra, que tenha sofrido alteração relativamente ao anteriormente transmitido.

9.4.3.1.3. Se uma mensagem HOP for enviada antes da TI, terá início a fase de Transferência.NOTA

Não é necessária uma Mensagem de Início de Transferência (TIM) em adição à HOP.

9.4.3.1.4. Deverá ser objecto de acordo bilateral a menor distância ou tempo de voo até ao COP ou até à fronteira, a que uma HOP poderá ser enviada.

9.4.3.1.5. Recomendação

O tempo/distância deve ser especificado separadamente para cada COP.

9.4.3.2. Processamento na Unidade Receptora

9.4.3.2.1. O sistema ATC que recebe uma mensagem HOP deverá tentar a sua associação com o plano de voo correspondente.

9.4.3.2.2. A informação de voo recebida na mensagem deverá ser visualizada imediatamente pelo controlador aceitante.

9.4.3.2.3. Se o controlador aceitante aceita o voo nas condições propostas na HOP, poderá ser enviada em resposta uma ROF à unidade transferidora. Quando acordado bilateralmente, poderá ser enviada uma ACP em resposta a uma HOP.

9.4.3.2.4. Se o controlador aceitante não puder aceitar o voo, a transferência será acordada verbalmente.NOTA

Dada a urgência do procedimento de entrega, não é exigido por esta Norma o suporte do sistema na monitorização do retorno da ROF (ou uma ACP). Assume-se que o controlador transferidor terá plena consciência da ausência da resposta do controlador aceitante e tomará as medidas necessárias. No entanto, a presente Norma não impede que seja apresentado um alerta ao controlador transferidor, se tal for considerado operacionalmente necessário.

9.4.3.2.5. Logo que for recebida uma ROF (ou uma ACP), a mensagem HOP tornar-se-á operacionalmente vinculativa para ambas as unidades ATC.

9.4.4. Confirmação da HOP

9.4.4.1. Confirmação

Se puder ser associada a um plano de voo, a mensagem HOP será confirmada automaticamente por uma LAM.

9.4.4.2. Casos de Não Confirmação

Se em resposta a uma mensagem HOP não for recebida uma mensagem LAM, será apresentado um alerta na posição apropriada.

9.4.5. Exemplo

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

9.5. Mensagem de Pedido na Frequência (ROF)

9.5.1. Finalidade da Mensagem ROF

Quando necessário, a mensagem ROF é enviada pela unidade aceitante para a unidade transferidora, solicitando ao controlador transferidor que dê instruções à aeronave para mudar para a frequência do controlador aceitante. A mensagem pode ser utilizada:

- em resposta a uma HOP para indicar a aceitação do voo nas condições propostas;

- para solicitar a transferência antecipada do voo.

9.5.2. Conteúdo da Mensagem

A mensagem ROF é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Dados opcionais - a mensagem pode também conter:

- Frequência.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.5.3. Regras de Aplicação

9.5.3.1. Generalidades

9.5.3.1.1. A mensagem ROF será iniciada manualmente pelo controlador aceitante.

9.5.3.1.2. O controlador aceitante pode desencadear uma ROF:

- quando pretender ter mais cedo a aeronave na frequência;

- em resposta a uma mensagem HOP.

9.5.3.2. Processamento na Unidade Receptora

9.5.3.2.1. O sistema ATC que receba uma mensagem ROF deve tentar a sua associação com o plano de voo correspondente.

9.5.3.2.2. A recepção da ROF será indicada sem demora ao controlador transferidor.

9.5.3.2.3. Se o voo não se encontrar na fase de Transferência, dar-se-á início a esta e será enviada uma mensagem TIM.

9.5.4. Confirmação da ROF

9.5.4.1. Confirmação

9.5.4.1.1. Se a mensagem ROF puder ser associada inequivocamente a um plano de voo, será confirmada pela geração e transmissão de uma mensagem LAM.

9.5.4.1.2. Se a mensagem ROF não puder ser associada inequivocamente a um plano de voo, não será enviada qualquer confirmação.

9.5.4.2. Casos de Não Confirmação

Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem ROF, será apresentado um alerta na posição ATC apropriada.

9.5.5. Exemplo

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

9.6. Mensagem de Mudança de Frequência (COF)

9.6.1. Finalidade da Mensagem COF

9.6.1.1. Generalidades

9.6.1.1.1. A COF é enviada pela unidade transferidora para a unidade aceitante, para indicar que o voo recebeu instruções para contactar o controlador aceitante.

9.6.1.1.2. A mensagem pode incluir a facilidade de o controlador transferidor libertar o voo das condições de transferência acordadas quando estabelecer comunicação rádio com o controlador aceitante.

9.6.2. Conteúdo da Mensagem

A mensagem COF é constituída pelos seguintes dados:

- Dados obrigatórios - a mensagem deverá conter:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave;

- Dados disponíveis - a mensagem deverá também conter o seguinte, se disponíveis:

- Indicação de Libertação;

- Frequência;

- Nível de Voo Autorizado;

- Rumo Atribuído ou Autorização Directa;

- Velocidade Atribuída;

- Razão de Subida/Descida Atribuída;

- Dados opcionais - a mensagem pode também conter:

- Posição.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.6.3. Regras de Aplicação

9.6.3.1. Generalidades

9.6.3.1.1. A mensagem COF será iniciada manualmente pelo controlador transferidor.

9.6.3.1.2. A utilização da mensagem COF é obrigatória se, por acordo bilateral, não for utilizada a mensagem MAS.

9.6.3.1.3. Se for enviada uma mensagem COF antes da TI, iniciar-se-á a fase de Transferência.NOTA

Não é necessária uma Mensagem de Início de Transferência (TIM) em adição à COF.

9.6.3.2. Processamento na Unidade Receptora

9.6.3.2.1. O sistema ATC que recebe uma mensagem COF deverá tentar a sua associação com o plano de voo correspondente.

9.6.3.2.2. A recepção da COF será indicada sem demora ao controlador aceitante.

9.6.4. Confirmação da COF

9.6.4.1. Confirmação

9.6.4.1.1. Se a mensagem COF puder ser associada inequivocamente a um plano de voo, será confirmada pela geração e transmissão de uma mensagem LAM.

9.6.4.1.2. Se a mensagem COF não puder ser associada inequivocamente a um plano de voo, não será enviada qualquer confirmação.

9.6.4.2. Casos de Não Confirmação

Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem COF, será apresentado um alerta na posição ATC apropriada.

9.6.5. Exemplos

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

9.7. Mensagem de Afectação Manual das Comunicações (MAS)

9.7.1. Finalidade da Mensagem MAS

A MAS é enviada pela unidade aceitante para a unidade transferidora indicando ter sido estabelecido contacto rádio nos dois sentidos com o voo.

9.7.2. Conteúdo da Mensagem

A mensagem MAS é constituída pelos seguintes dados:

- Tipo de Mensagem;

- Número da Mensagem;

- Identificação da Aeronave.

NOTA

As regras de inserção dos dados, os formatos e o conteúdo dos campos são especificados no Anexo A.

9.7.3. Regras de Aplicação

9.7.3.1. Generalidades

9.7.3.1.1. A mensagem MAS será iniciada manualmente pelo controlador aceitante.

9.7.3.1.2. A utilização da mensagem MAS é obrigatória se, por acordo bilateral, não for utilizada a mensagem COF.

9.7.3.2. Processamento na Unidade Receptora

9.7.3.2.1. O sistema ATC que recebe uma mensagem MAS deverá tentar a sua associação com o plano de voo correspondente.

9.7.3.2.2. A recepção da MAS será indicada imediatamente ao controlador.

9.7.4. Confirmação da MAS

9.7.4.1. Confirmação

9.7.4.1.1. Se a mensagem MAS puder ser associada inequivocamente a um plano de voo, será confirmada pela geração e transmissão de uma mensagem LAM.

9.7.4.1.2. Se a mensagem MAS não puder ser associada inequivocamente a um plano de voo, não será enviada qualquer confirmação.

9.7.4.2. Casos de Não Confirmação

Se não for recebida nenhuma mensagem LAM em confirmação de uma mensagem MAS, será apresentado um alerta na posição ATC apropriada, se necessário.

9.7.5. Exemplo

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

ANEXO A (Normativo)

REGRAS DE INSERÇÃO DOS DADOS

ÍNDICE

>POSIÇÃO NUMA TABELA>

A.1. Finalidade

O presente Anexo descreve as regras gerais para a inserção de dados nas mensagens descritas na presente Norma. Estas regras aplicam-se a todas as mensagens excepto quando nas Regras de Aplicação de uma determinada mensagem forem especificamente estabelecidas outras alternativas ou excepções a estas regras.

A.2. Formatos de Mensagens Genéricos

A.2.1. Todas as mensagens descritas nas seguintes secções podem ser transmitidas utilizando o formato ICAO:

6 Procedimento Básico - Mensagens Obrigatórias;

7 Procedimento Básico - Mensagens Complementares;

8 Procedimento de Diálogo - Coordenação.

A.2.2. Os formatos dos campos das mensagens ICAO são especificados nos Procedures for Air Navigation Services - Rules of the Air and Air Traffic Control (Procedimentos dos Serviços de Navegação Aérea - Regras do Ar e do Controlo de Tráfego Aéreo) (Documento 4444). Nas mensagens em que ocorram, os seguintes tipos de Campos ICAO serão transmitidos antes de quaisquer outros tipos de Campos pela seguinte ordem: 3, 7, 13, 14 e 16. Uma vez que se encontram no formato do tipo de Campo 22, a ordem dos outros tipos de Campos ICAO não é importante, desde que não precedam os tipos de Campos listados acima.

A.2.3. Todas as mensagens descritas no presente documento podem ser transmitidas utilizando o formato ADEXP do Eurocontrol. O conteúdo, a estrutura e a utilização dos campos de dados ADEXP deverá estar em conformidade com a Referência 2.NOTAS

1. O presente Anexo apenas faz referência aos campos de dados Primários da ADEXP, excepto quando os Sub-campos associados necessitarem de comentários específicos. A Norma ADEXP lista todos os Sub-campos opcionais e obrigatórios exigidos em cada campo Primário.

2. As mensagens descritas na Secção 9, Procedimento de Diálogo - Transferência de Comunicação, são descritas apenas no formato ADEXP.

A.3. Tipo de Mensagem

O tipo de mensagem será a abreviatura da mensagem, tal como descrita na lista apresentada a seguir.

ABI: Informação de Fronteira Avançada.

ACP: Aceitação.

ACT: Activação.

CDN: Coordenação.

COD: Atribuição de Código SSR.

COF: Mudança de Frequência.

HOP: Proposta de Entrega.

INF: Informação.

LAM: Mensagem de Confirmação Lógica.

MAC: Mensagem para Revogação de Coordenação.

MAS: Afectação Manual das Comunicações.

PAC: Activação Preliminar.

RAP: Proposta de Activação Remetida.

REV: Revisão.

RJC: Rejeição de Coordenação.

ROF: Pedido na Frequência.

RRV: Proposta de Revisão Remetida.

SBY: Espera.

SDM: Mensagem de Informação Suplementar.

TIM: Mensagem de Início de Transferência.

A.3.1. ICAO

Tipo de Campo 3, elemento (a).

A.3.2. ADEXP

Campo Primário "title".

A.4. Número da Mensagem

A informação do número da mensagem inclui os identificadores atribuídos às unidades emissoras e receptoras e o número sequencial da mensagem. O número sequencial da mensagem progride de 001 a 000 (representando 1000), repetindo-se então a partir de 001 para todas as mensagens enviadas para o mesmo destinatário, independentemente do tipo de mensagem.

A.4.1. ICAO

Tipo de Campo 3, elemento (b).

A.4.2. ADEXP

Campo Primário "refdata".

O Sub-campo "fac", dentro dos sub-campos "sender" e "recvr", deverá conter os identificadores atribuídos às unidades ATC. Estes identificadores não terão mais de 8 caracteres de comprimento.

O Sub-campo "seqnum" deverá conter o número sequencial.

A.5. Referência da Mensagem

A.5.1. ICAO

Tipo de Campo 3, elemento (c) (designado "informação de referência" no documento 4444 da ICAO).

O conteúdo do elemento (c) será o mesmo do elemento (b), do tipo de Campo 3, da mensagem OLDI em referência.

A.5.2. ADEXP

Campo Primário "msgref".

Os valores dos Sub-campos "sender", "recvr" e "seqnum", dentro do campo Primário "msgref", serão iguais aos dos mesmos Sub-campos dentro do campo Primário "refdata" da mensagem OLDI em referência.

A.6. Identificação da Aeronave

A.6.1. ICAO

Tipo de Campo 7, elemento (a).

A.6.2. ADEXP

Campo Primário "arcid".

A.7. Modo e Código SSR

Ou:

1. se conhecido, o modo/código SSR no qual a unidade receptora pode esperar que a aeronave responda no ponto de transferência do controlo;

ou

2. um indicador de que o código SSR está a ser pedido pela unidade receptora.

A.7.1. ICAO

Tipo de Campo 7, elementos (b) e (c).

Se não estiver atribuído um código SSR ou se o modo/código for desconhecido, os elementos (b) e (c) serão omitidos.

Ao solicitar um código/modo SSR, os elementos b) e c) deverão conter o valor "A9999".

A.7.2. ADEXP

Campo Primário "ssrcode".

Se não estiver atribuído um código SSR válido ou se o modo/código for desconhecido, o campo será omitido.

Ao solicitar um código/modo SSR através de uma mensagem PAC, o campo primário "ssrcode" deverá conter o indicador "REQ".

A.8. Aeródromo de partida

A.8.1. ICAO

Tipo de Campo 13, elemento (a).

A.8.2. ADEXP

Campo Primário "adep".

A.9. Informação Estimada

A.9.1. Generalidades

A.9.1.1. A informação estimada deverá incluir o COP, a hora no COP e o nível de transferência.

A.9.1.2. O ponto de coordenação será definido por um ponto de referência conhecido, por um azimute e uma distância a um ponto de referência conhecido, ou por uma latitude e longitude.

A.9.1.3. O nível (de transferência) autorizado deverá corresponder às condições de transferência propostas.

A.9.1.4. Recomendação

Para voos que sobem ou descem, a informação estimada deveria conter também informação de atravessamento suplementar ou condições para o atravessamento.

A.9.1.5. Se utilizada, a informação de atravessamento suplementar deverá conter o nível de atravessamento suplementar no ponto de transferência do controlo. As condições de atravessamento serão as seguintes:

- Letra "A"; - se o voo irá encontrar-se no nível indicado na informação de atravessamento suplementar ou acima dele; ou

- Letra "B"; - se o voo irá encontrar-se no nível indicado na informação de atravessamento suplementar ou abaixo dele.

A.9.2. ICAO

Tipo de Campo 14.

A.9.3. ADEXP

Campo Primário "coordata".

O Sub-campo "ptid", dentro do campo Primário "coordata", deverá conter:

- um ponto de referência conhecido; ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF" ou "GEO".

A.10. Ponto de Coordenação

A.10.1. Generalidades

A.10.1.1. O ponto de coordenação referido pelas unidades ATC transferidoras e receptoras para os fins da transferência em causa.

A.10.1.2. O ponto de coordenação será definido por um ponto de referência conhecido, por um azimute e uma distância a um ponto de referência conhecido, ou por uma latitude e longitude.

A.10.2. ICAO

Campo 14, elemento (a).

A.10.3. ADEXP

Campo Primário "cop" contendo:

- um ponto de referência conhecido; ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF" ou "GEO".

A.11. Aeródromo de Destino

A.11.1. ICAO

Campo 16, elemento (a).

A.11.2. ADEXP

Campo Primário "ades".

A.12. Número e Tipo da Aeronave

O número e o tipo da aeronave deverão conter o tipo da aeronave. O número da aeronave será incluído no caso de voos de formação.

A.12.1. ICAO

Tipo de Campo 19 no formato do tipo de campo 22. O elemento c do tipo de campo 9 deverá conter a categoria da turbulência da esteira adequada ao tipo de aeronave ou a letra "Z".

A.12.2. ADEXP

Campo Primário "arctyp". Em adição, se existir mais de uma aeronave no voo, o campo Primário "nbarc".

A.13. Rota

Ambos os formatos suportam a descrição da rota, de acordo com o definido para as mensagens ICAO que requerem a velocidade como primeiro elemento e o nível de voo solicitado ou informação de altitude. Após o grupo do nível de velocidade, a informação de rota incluirá como mínimo os dados especificados no parágrafo seguinte. Poderá ser inserida informação de rota adicional após o item c), se disponível. Ver também o Anexo B, "Requisitos de Processamento de Rotas Especiais" para as regras de inserção de informação de rota.

A.13.1. Conteúdo

A.13.1.1. Voos que Seguem através de um COP Definido

- o elemento de rota antes do COP (rota ATS, identificador SID, DCT ou ponto significativo);

- o COP;

- o elemento de rota após o COP (rota ATS ou ponto significativo).

A.13.1.2. Voos que Seguem Fora de uma Rota ATS

- o ponto de onde provém o voo no segmento de rota directo;

- o elemento "DCT";

- o ponto para onde o voo prossegue no segmento de rota directo.

A.13.2. Formato

A.13.2.1. ICAO

Tipo de Campo 15, no formato do tipo de campo 22.

A.13.2.2. ADEXP

Campo Primário "route".

A.14. Outras Informações do Plano de Voo

A.14.1. ICAO

Tipos de campos 8, 10 e 18, no formato do tipo de campo 22.

A.14.2. ADEXP

Campos Primários: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts" e "typz".

A.15. Estado e Razão de Coordenação

O estado e a Razão de coordenação deverá incluir os seguintes elementos:

- um indicador de três letras que confirme a nova situação do plano de voo do sistema, devendo ser um dos seguintes:

- INI, quando o plano de voo do sistema deve estar num estado inicial, ou seja, não foi recebida mensagem de notificação;

- NTF, quando o plano de voo do sistema deve estar num estado notificado;

- CRD, quando o plano de voo do sistema deve estar num estado coordenado, ou seja, foi recebida uma ACT básica ou completou-se o diálogo de coordenação inicial com as condições acordadas.

- um indicador de três letras especificando a razão da situação, devendo ser um dos seguintes:

- TFL, se a razão for uma alteração do nível de transferência;

- RTE, se a razão for uma alteração de rota;

- HLD, para indicar que o voo aguarda durante um período de tempo indefinido e será sujeito a uma nova mensagem;

- DLY, para indicar que a partida está atrasada;

- CAN, se a razão for um cancelamento;

- CSN, para uma mudança do indicativo de chamada;

- OTH, para qualquer outra razão ou se a razão for desconhecida.

A.15.1. ICAO

A.15.1.1. O estado e a razão de coordenação deverá estar no formato do tipo de Campo 18.

A.15.1.2. O estado e a razão de coordenação deverá incluir os seguintes elementos na forma de um grupo de 10 caracteres:

- STA, seguido de uma barra oblíqua;

- o indicador para confirmar o novo estado da notificação/coordenação;

- o indicador especificando a razão.

A.15.2. ADEXP

Campo Primário "cstat".

Os itens auxiliares "coordstatusident" e "coordstatusreason" deverão conter respectivamente, o novo estado e razão, conforme especificado acima.

A.16. Rumo Atribuído (apenas ADEXP)

O campo Primário "ahead" deverá conter:

- o rumo atribuído a um voo, expresso em graus;

ou

- se não for atribuído um rumo, o indicador "ZZZ", por exemplo, quando uma mensagem SDM é usada para indicar o abandono de um rumo previamente atribuído.

A.17. Velocidade Atribuída (apenas ADEXP)

O campo Primário "aspeed" deverá conter:

- a velocidade atribuída a um voo, expressa em nós, número de mach ou em quilómetros/hora;

ou

- se não for atribuída uma velocidade, o indicador "ZZZ", por exemplo, quando uma mensagem SDM é usada para indicar o abandono de uma velocidade previamente atribuída.

A.18. Razão de Subida/Descida Atribuída (apenas ADEXP)

O campo Primário "rate" deverá conter:

- a razão de subida ou de descida atribuída a um voo, expressa em centenas de pés por minuto;

ou

- se não for atribuída uma razão de subida/descida, o indicador "ZZZ" na posição numérica do campo, por exemplo, quando uma mensagem SDM é usada para indicar o abandono de uma razão de subida/descida previamente atribuída.

A.19. Autorização Directa (apenas ADEXP)

Uma rota directa, não definida como uma rota ATS, entre dois pontos. Os pontos podem ser definidos por pontos de referência conhecidos ou pelo azimute e distância a um ponto de referência. Todos os pontos designadores finais utilizados deverão ser acordados bilateralmente, ou seja, devem ser conhecidos por ambos os sistemas.

Campo Primário "DCT" contendo:

- o ponto no qual se iniciou ou se iniciará o desvio, definido como um dos seguintes:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF";

ou

- o valor "ZZZ" se a unidade emissora não exigir a designação do ponto de desvio.

- o ponto situado na rota do plano de voo original para o qual a aeronave foi ou será autorizada, definido como:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF".

A.20. Pedido de Rota Directa

Pedido para uma rota directa, não definida como uma rota ATS, entre dois pontos. Os pontos podem ser definidos ou por pontos de referência conhecidos ou pelo azimute e distância a um ponto de referência.

Todos os pontos designadores finais utilizados serão acordados bilateralmente, ou seja, devem ser conhecidos por ambos os sistemas.

A.20.1. ICAO

Tipo de campo 15, excluindo o grupo nível/velocidade inicial, no formato do campo 22.

Deverá conter:

- o ponto onde se pretende que o desvio se inicie, definido como um dos seguintes:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido;

ou

- o valor "ZZZ", se a rota directa for pedida pela unidade ATC receptora.

- a abreviatura "DCT",

- seguida do ponto situado na rota do plano de voo original para o qual é pedida a autorização para a aeronave, definido como:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido.

A.20.2. ADEXP

Campo Primário "DCT" contendo:

- o ponto onde se pretende que o desvio se inicie, definido como um dos seguintes:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF";

ou

- o valor "ZZZ", se a rota directa for pedida pela unidade ATC receptora mas não for conhecida a localização precisa do ponto onde deveria começar.

- o ponto situado na rota do plano de voo original para o qual é pedida a autorização para a aeronave, definido como:

- um ponto de referência conhecido;

ou

- um azimute e uma distância a um ponto de referência conhecido, conforme definido na mesma mensagem pelo campo Primário "REF";

A.21. Posição (apenas ADEXP)

A.21.1. Generalidades

A.21.1.1. A posição actual do voo expressa em coordenadas geográficas ou em azimute e distância a um ponto designado.

A.21.1.2. O campo Primário "ref" ou "geo" definirá a localização horizontal actual da aeronave. Os pontos utilizados para efeitos da distância e azimute no campo primário "ref" serão acordados bilateralmente, ou seja, deverão ser conhecidos por ambos os sistemas. O campo Primário "position" deverá conter o sub-campo "ptid" que se refere à referência ou ao ponto geográfico definidos. Se tiver de ser incluída informação horária, deve utilizar-se o sub-campo "to" (hhmm) ou "sto" (hhmmss), conforme acordado bilateralmente.

A.22. Indicação de Autorização (apenas ADEXP)

O campo Primário "release" deverá conter um dos seguintes:

- C, se o voo recebeu autorização para subir;

- D, se o voo recebeu autorização para descer;

- T, se o voo recebeu autorização para fazer voltas;

- F, se o voo recebeu autorização para executar todas as acções.

A.23. Frequência

A.23.1. ICAO

O tipo de campo 18 deverá incluir os seguintes elementos no formato do campo 22:

- FRQ, seguido de uma barra oblíqua;

- 6 algarismos indicando a frequência, expressa em MHz com três casas decimais.

A.23.2. ADEXP

Campo Primário "freq".

A.24. Razão (apenas ADEXP)

Campo Primário "reason", contendo o valor "MANUAL" para mensagens remetidas manualmente.

A.25. Nível de Voo Autorizado (apenas ADEXP)

Campo Primário "cfl".

A.26. Nível de Voo de Transferência Proposto (apenas ADEXP)

Campo primário "propfl".

A.27. Hora Estimada de Descolagem

A.27.1. ICAO

Elemento (b) do tipo de campo 13.

A.27.2. ADEXP

Campo Primário "etot".

A.28. Tipo da Mensagem de Referência

O campo contém o tipo de mensagem especificado no parágrafo A.1 do presente Anexo.

A.28.1. ICAO

Tipo de campo 18 no formato do tipo 22. O elemento indicador será "MSG".

A.28.2. ADEXP

Campo Primário "msgtyp".

ANEXO B (Normativo)

REQUISITOS DE PROCESSAMENTO DE ROTAS ESPECIAIS

B.1. Introdução

B.1.1. Generalidades

B.1.1.1. O presente Anexo descreve as regras e os requisitos de inserção de dados nos seguintes casos, quando autorizado:

- um voo segue uma rota num trajecto directo, fora de rota, cruzando a fronteira em resultado de um segmento de rota directa descrito no plano de voo;

- após a transmissão da mensagem ABI ou ACT, o voo é redireccionado através de:

- uma rota ATS diferente;

- uma trajectória diferente para se juntar à rota original num ponto posterior.

B.1.1.2. Relativamente ao redireccionamento de voo (parágrafo B.1.1.1), o intercâmbio de informação descrito no presente Anexo suporta a modificação da rota do voo conforme especificada em ambos os sistemas, através da utilização das mensagens de notificação e de coordenação.

B.2. Aplicação de Mensagens

B.2.1. Regras Básicas para Rotas Directas

B.2.1.1. As condições para a utilização da OLDI na coordenação de voos em rotas directas serão objecto de acordo bilateral.

B.2.1.2. A informação requerida para a notificação e coordenação de voos em rotas directas encontra-se no ponto de coordenação (informação estimada (formato ICAO) e informação de coordenação (formato ADEXP)), bem como na rota nas mensagens aplicáveis.

B.2.2. Preenchimento da Rota Directa

Quando a rota indica que o voo irá atravessar a fronteira numa trajectória directa, o segmento de rota directa e o COP resultante serão incluídos na(s) mensagem(ns) ABI. Este COP será incluído na mensagem ACT ou RAP subsequente.

O COP e a informação de rota serão formatados de acordo com o descrito no parágrafo B.3.2.

B.2.3. Redireccionamento após a ABI e antes da Transmissão da ACT

Será enviada uma nova mensagem ABI com a informação correspondente à nova rota.

B.2.4. Redireccionamento após a transmissão da ACT

B.2.4.1. Os redireccionamentos serão indicados por uma mensagem REV, após a mensagem ACT ter sido enviada até a uma hora acordada bilateralmente antes da ETO no COP previamente coordenado.NOTA

Uma mensagem REV só é utilizada quando a unidade aceitante não se altera em resultado da modificação. Se se alterar, tem de se enviar uma mensagem MAC para a unidade aceitante original ou cancelar verbalmente a coordenação.

B.2.4.2. A mensagem deverá conter os seguintes dados:

- Ponto de coordenação (COP prévio, para fins de referência);

- Informação estimada;

- Rota.

B.2.4.3. As mensagens no formato ICAO devem conter os seguintes campos:

3 Tipo e número da mensagem; referência da mensagem, se acordado bilateralmente;

7 Identificação da aeronave. Os elementos b e c não serão incluídos, excepto se estiver a ser coordenada simultaneamente uma revisão ao código SSR;

13 Aeródromo de partida;

14 Apenas o elemento a, contendo o COP prévio para fins de referência;

16 Destino;

22 Campo 14 contendo a informação estimada para as condições do novo cruzamento de fronteira no formato do campo 22;

22 Campo 15 contendo a nova rota no formato do campo 22.

B.2.4.4. As mensagens no formato ADEXP deverão incluir, além do tipo e número da mensagem, identificação da aeronave, aeródromo de partida, destino e, se acordado bilateralmente, o número de referência da mensagem:

- COP prévio no campo COP;

- as novas condições de coordenação no campo COORDATA;

- a nova rota no campo ROUTE.

B.2.4.5. As revisões à rota, enviadas como parte do procedimento de diálogo serão enviadas como mensagens RRV, salvo se forem consideradas "normalizadas" por acordo bilateral.

B.3. Conteúdo dos Campos

B.3.1. Rotas ATS

Para os voos redireccionados através de uma Rota ATS alternativa, os campos estimados e de rota terão o mesmo formato das mensagens ABI e ACT.

B.3.2. Rotas Directas

B.3.2.1. Na informação estimada, o ponto de coordenação será o ponto de cruzamento da fronteira expresso como um azimute e uma distância a um ponto de notificação. Estes pontos devem ser acordados bilateralmente. Quando essa distância for nula ou quando um voo passe a uma distância acordada bilateralmente a esse ponto, apenas será incluído o identificador desse ponto.

B.3.2.2. Quando acordado bilateralmente, o ponto de coordenação para um voo numa rota directa pode ser expresso em referência à latitude/longitude.

B.3.2.3. A rota deverá conter:

- ponto situado na rota original a partir do qual a aeronave passará a ter rota directa; quando um voo passa a ter rota directa a partir da "posição actual", o ponto pode ser expresso como um rumo e uma distância a um ponto de notificação. Quando acordado bilateralmente, o ponto pode ser expresso em referência à latitude/longitude.

- a abreviatura "DCT";

- ponto para onde a aeronave se deve dirigir directamente;

- resto da rota seguinte do voo (FRF), se for conhecido do sistema emissor.

B.4. Exemplos

B.4.1. Rotas Directas

B.4.1.1. Mensagens ABI e ACT

B.4.1.1.1. O voo (identificação Jetset 253) vai cruzar a fronteira numa rota directa desde o Ponto A (PTA) até ao Ponto C (PTC) após o que seguirá a rota ATS UA134. O sistema determina um COP com o azimute 350, à distância de 22 NM do Ponto B (PTB).

>PIC FILE= "L_2000254PT.008401.EPS">

É enviada a seguinte mensagem ABI

- 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. A mensagem ACT possui formato idêntico ao da mensagem ABI, com a excepção de que a rota do voo é opcional.

B.4.1.2. Mensagem REV

O voo HZT2051 foi, previamente, o assunto da seguinte mensagem ACT (ou o seu equivalente ADEXP):

(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-9/B737/M

>PIC FILE= "L_2000254PT.008501.EPS">

O voo é redireccionado a partir do ponto a 40 NM oeste do ponto RQA directamente para o ponto MYY. O ponto mais próximo até ao atravessamento da fronteira é TDS, cuja distância até ao atravessamento efectivo é de 26 NM no azimute 240 graus. É enviada a seguinte mensagem de revisão:

(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/1842F310-15/N0458F310 RQA270040 DCT MYY)

>PIC FILE= "L_2000254PT.008502.EPS">

O equivalente ADEXP da mensagem é:

-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

Uma mensagem de revisão subsequente indicaria como COP TDS240026.

B.4.2. Redireccionamento através de Rotas ATS após a Transmissão da ACT

B.4.2.1. Mensagem ACT

O voo GKP217 planeia fazer uma rota através do ponto de coordenação EMT. É transmitida a seguinte ACT:

(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)

>PIC FILE= "L_2000254PT.008601.EPS">

Subsequentemente, o voo redirecciona através da rota ATS UM247, no interior do espaço aéreo do centro emissor, para um novo ponto de coordenação XAT após o qual seguirá a rota ATS UJ124. O centro aceitante continua a ser o mesmo. É enviada a seguinte mensagem de revisão:

(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)

>PIC FILE= "L_2000254PT.008602.EPS">

O voo é então autorizado para o FL290, originando a seguinte mensagem (contendo o novo COP):

(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)

>PIC FILE= "L_2000254PT.008701.EPS">

B.4.2.2. Equivalentes ADEXP

Os equivalentes ADEXP das duas mensagens de revisão são os seguintes:

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

ANEXO C (Informativo)

FASES DO PROCEDIMENTO DE DIÁLOGO (NÍVEL 1 DO SYSCO) - SEQUÊNCIA DAS MENSAGENS

Sequência das Mensagens

>PIC FILE= "L_2000254PT.008802.EPS">

ANEXO II

APRESENTAÇÃO DO INTERCÂMBIO DE INFORMAÇÃO DOS SERVIÇOS DE TRÁFEGO AÉREO (ADEXP), EDIÇÃO 2.0

(referência do documento do Eurocontrol DPS.ET1.ST09-STD)

ÍNDICE

>POSIÇÃO NUMA TABELA>

INFORMAÇÃO RELATIVA AOS DIREITOS DE AUTOR

O presente documento foi produzido pela Agência Eurocontrol.

Os direitos de autor pertencem à Agência Eurocontrol.

O conteúdo, ou parte dele, está assim à livre disposição dos representantes dos Estados-membros, mas a cópia ou a divulgação a outras partes está sujeita ao consentimento prévio, por escrito, da Agência Eurocontrol.

PREFÁCIO

1. Organismo Responsável

A presente Norma foi desenvolvida e é mantida pela Secção "Requisitos de Utilizador" da Unidade Central de Gestão de Tráfego (CFMU) da Organização Europeia para a Segurança da Navegação Aérea (Eurocontrol).

2. Documento do Programa de Trabalho do EATCHIP

A presente Norma é o produto resultante do Documento do Programa de Trabalho do EATCHIP (EWPD), Domínio dos Sistemas de Tratamento de Dados (DPS), Tarefa Executiva 09.

3. Aprovação da Norma

3.1. A presente Norma é adoptada em conformidade com os procedimentos especificados nas Directivas para a Normalização do Eurocontrol, Ref. 000-2-93, Edição 1.0.

3.2. As disposições da presente Norma entraram em vigor após a adopção da edição 1.0 pela Comissão Permanente do Eurocontrol em 1995. Esta norma estava prevista para ser aplicada a partir de 1 de Dezembro de 1997.

4. Corrigenda Técnica e Alterações

A presente Norma é mantida sob revisão para determinar as alterações necessárias ou a corrigenda técnica. O procedimento para a manutenção da presente Norma encontra-se estabelecido no Anexo H das Directivas para o Projecto Uniforme e Apresentação dos Documentos Normativos do Eurocontrol.

As alterações ou os aditamentos que afectem os princípios básicos ou a gramática do formato ADEXP serão efectuadas apenas no decurso do procedimento de revisão formal, conforme estabelecido nas Directivas para o Projecto Uniforme e Apresentação dos Documentos Normativos do Eurocontrol.

As alterações ou os aditamentos à presente Norma serão propostas por escrito à: CFMU User Requirements Section (ADEXP), Eurocontrol Agency.

5. Convenções Editoriais

5.1. O formato da presente Norma obedece às Directivas para o Projecto Uniforme e Apresentação dos Documentos Normativos do Eurocontrol, existindo, no entanto, alguns desvios às Directivas. As dispensas menores de formatação em relação às Directivas destinam-se a evitar confusão com a notação da Apresentação do Intercâmbio de Informação ATS (ADEXP).

5.2. A seguinte notação foi utilizada para indicar a situação de cada declaração:

- Os Elementos Normativos utilizam o verbo-chave "deve" e foram impressos em texto romano normal;

- Os Elementos Recomendados utilizam o verbo-chave "deveria" e foram impressos em itálico, sendo a situação indicada pelo prefixo; Recomendação.

6. Relação com outros Documentos Normativos

A presente Norma está relacionada com:

Documento Normativo do Eurocontrol para o Intercâmbio de Informação em Tempo Real (OLDI)

7. Situação dos Anexos da presente Norma

>POSIÇÃO NUMA TABELA>

8. Idioma utilizado

No texto original da presente Norma foi utilizada a língua Inglesa.

1. ÂMBITO

1.1. O ADEXP é um formato e não um protocolo. Não são impostas quaisquer restrições aos meios e aos protocolos de transmissão a utilizar, para além do conjunto de caracteres.

1.2. O ADEXP estabelece um formato para ser utilizado, essencialmente, em tempo real, na permuta de mensagens entre computadores.

1.3. O presente documento define os princípios e as regras de sintaxe do formato ADEXP, estabelecendo esta definição em termos de uma definição global dos campos ADEXP.

1.4. O formato ADEXP foi especificado para utilização nas seguintes áreas de permuta de mensagens (consultar a página 3 da Secção 2 para informação sobre documentos de referência):

- Planeamento de Voos: intercâmbio de informação sobre planos de voo e mensagens associadas entre o Sistema Integrado de Processamento Inicial de Planos de Voo (IFPS), os Serviços de Tráfego Aéreo (ATS) e os Operadores de Aeronaves (AO). (Documento Ref.a 3)

- Gestão do Fluxo de Tráfego Aéreo (ATFM): permuta de mensagens entre o Sistema Táctico (TACT) do CFMU, AO e ATS. (Documento Ref.a 5)

- Coordenação do Controlo do Tráfego Aéreo: permuta de mensagens de coordenação táctica entre as Unidades de Controlo do Tráfego Aéreo (ATCU). (Documento Ref.a 6)

- Gestão do Espaço Aéreo: intercâmbio de informação entre as Unidades ATS Nacionais, o CFMU e os AO, relativamente à disponibilidade do espaço aéreo. (Documento Ref.a 7)

- Coordenação Civil / Militar: mensagens relativas a informação de voo civil/militar e mensagens de cruzamento do espaço aéreo. (Documento Ref.a 7)

1.5. Nos documentos de referência poderão ser encontradas especificações detalhadas relativamente à utilização e ao conteúdo das mensagens em cada um dos grupos supramencionados.

2. REFERÊNCIAS

2.1. Os seguintes documentos e normas contêm disposições que, através de referência no presente texto, constituem disposições do presente Documento Normativo do Eurocontrol.

À data da publicação do presente Documento Normativo do Eurocontrol, as edições indicadas para os documentos e normas referenciados eram válidas.

Qualquer revisão dos Documentos mencionados da Organização da Aviação Civil Internacional (ICAO) será imediatamente tida em consideração para a revisão do presente Documento Normativo do Eurocontrol.

As revisões dos outros documentos referenciados não farão parte das disposições do presente Documento Normativo do Eurocontrol até serem formalmente revistas e incluídas no presente Documento Normativo do Eurocontrol.

Em caso de conflito entre os requisitos do presente Documento Normativo do Eurocontrol e o conteúdo dos outros documentos referenciados, terá precedência o presente Documento Normativo do Eurocontrol.

2.2. À data da publicação, os documentos abaixo listados são os que foram referenciados na presente Norma. No entanto, os utilizadores são convidados a verificar a utilização e as tabelas de composição dos campos das mensagens nas edições mais recentes desses documentos.

1. Volume I do Anexo 10 da Convenção de Chicago da ICAO, edição de Novembro de 1985;

2. Volume II do Anexo 10 da Convenção de Chicago da ICAO, edição de Julho de 1995;

3. Dicionário de Mensagens do IFPS e RPL, edição 1.0, de Março de 1998;

4. "Rules of the Air and Air Traffic Services" ("Regras do Ar e dos Serviços de Tráfego Aéreo"), Doc. 4444 do PANS-RAC, edição de Novembro de 1985 (incluindo a Alteração n.o 6, de Novembro de 1995);

5. "Guide To ATFM Message Exchange" (Guia da Permuta de Mensagens da ATFM), Documento do Eurocontrol Ref.a TACT/USD/MSGGUID, edição 6.0, em vigor desde Março de 1998,

6. "Eurocontrol Standard for On-Line Data Interchange" (Norma do Eurocontrol relativa ao Intercâmbio de Informação em Tempo Real), edição 2.0, de Outubro de 1996.

7. "Funcional Specifications for System Support to Airspace Data Distribuition and Civil Military Co-ordination" (Especificações Funcionais para o Suporte do Sistema na Distribuição da Informação sobre o Espaço Aéreo e na Coordenação Civil/Militar), edição 1.0, de Maio de 1996.

3. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS

3.1. Notação

A notação utilizada para definir a sintaxe é designada de Notação Backus Naur (BNF). A BNF define um conjunto de regras que determinam uma classe de sequências de caracteres. Neste caso, a classe de sequências de caracteres é o conjunto de mensagens que podem ser designadas de mensagens ADEXP sintacticamente válidas.

3.2. Definições

Para os efeitos do presente documento Normativo do Eurocontrol, aplicar-se-ão as seguintes definições:

Marca: Um caracter ou conjunto de caracteres que pode ser "extraído" por um analisador lexical devido à presença de separadores.

Símbolo: Qualquer "termo" que apareça numa regra BNF mas que não seja um caracter.

Símbolo Terminal: Um símbolo representado em termos de uma sequência de caracteres.

Símbolo Não-Terminal: Um símbolo representado por um ou mais símbolos terminais.

NOTA

Um símbolo não-terminal pode também ser representado por uma mistura de símbolos terminais e não-terminais.

3.3. Construção

3.3.1. O BNF consiste de uma série de regras ou construções da forma:

símbolo ::= expressão

NOTAS

1) A notação "::=" deve ser entendida como "pode ser substituído por".

2) O "símbolo" é classificado como não-terminal.

3) A parte "expressão" contém símbolos terminais e não-terminais.

3.3.2. Os símbolos terminais possuem uma representação directa como uma sequência de caracteres que podem ser identificados como uma marca por um analisador lexical, utilizando a presença de separadores.

3.4. Convenções

Para os efeitos do presente documento Normativo do Eurocontrol, aplicam-se as seguintes convenções:

- Os símbolos terminais estão em maiúsculas.NOTA

Por convenção, o símbolo terminal NIL significa "sem símbolo terminal".

É utilizado em escolhas tal como no seguinte exemplo:

a ::= b ( c | NIL ) em que a pode ser substituído por (b seguido de c) ou apenas por b.

- Os símbolos Não-Terminais (p.ex. o lado esquerdo de uma produção gramatical) estão em minúsculas.

- Os Caracteres e as Sequências de Literais que aparecem nas regras encontram-se respectivamente entre vírgulas dobradas (') e aspas ('').

Exemplos

1) HYPHEN ::= '-'

2) title ::= '-' "TITLE" titleid

Em algumas aplicações de modelização de dados, poderá ser necessário distinguir entre símbolos terminais e não-terminais por outros meios que não a utilização de letras maiúsculas e minúsculas.

Sempre que seja necessário distinguir explicitamente entre símbolos terminais e não-terminais, por outros meios que não a utilização de letras maiúsculas e minúsculas, recomenda-se a adição de um sufixo da seguinte forma: "_at" para um termo Auxiliar, "_pf" para um campo Primário e "_sf" para um Subcampo.

3.5. Operadores

Para os efeitos do presente documento Normativo do Eurocontrol, aplicar-se-ão os seguintes operadores:

Opcional: Quando determinados símbolos podem aparecer legalmente ou não em algum ponto na gramática. Os símbolos opcionais aparecem entre parênteses rectos "[" e "]".

Oclusão: Quando for possível um grupo de símbolos não aparecer ou aparecer mais de uma vez. Os símbolos aparecem entre chavetas "{" e "}". Se for especificado um número antes de "{" esse número indica o número mínimo de vezes que o grupo de símbolos pode aparecer. Se for especificado um número depois de "}" esse número indica o número máximo de vezes que o grupo de símbolos pode aparecer.

Escolha: Quando em algum ponto na gramática possa aparecer um determinado número de símbolos alternativos. A escolha é indicada por "|".

Concatenação: Representação de símbolos que ocorrem sequencialmente, mesmo que no meio possam aparecer um ou mais separadores. Não existe representação explícita desta representação. Existem dois tipos:

- Concatenação Rigorosa: ao nível lexical, as regras podem envolver a concatenação de terminais indicando que eles se seguem de forma rigorosa (sem separador no meio); neste caso utilizar-se-á o símbolo "!".Exemplo

datetime :: = date ! timehhmm

ex. "9912251200" indica 25 de Dezembro de 1999, às 12h00.

- Concatenação Livre: a presença autorizada de separadores entre terminais. A representação da Concatenação Livre numa regra pode ser Implícita ou Explícita.Exemplos

1) Implícita:

dct::= '-' "DCT" point point

2) Explícita

dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point

>POSIÇÃO NUMA TABELA>

NOTAS

1) A concatenação terá sempre precedência sobre a escolha. São utilizados parênteses "(" e ")" para alterar a ordem de avaliação da expressão.Exemplo

>POSIÇÃO NUMA TABELA>

2) Em todas as regras, será deixada implícita a presença autorizada de separadores entre símbolos, de forma a preservar a inteligibilidade.

Recomendação

Quando existir o risco de confusão em resultado da precedência entre os operadores acima mencionados, recomenda-se a utilização de parênteses, para clarificar a ordem de avaliação desejada.

3.6. Abreviaturas

>POSIÇÃO NUMA TABELA>

4. PRÍNCIPIOS DO ADEXP

4.1. Formato Textual, Legível por Pessoas

4.1.1. O formato ADEXP é textual, baseado em caracteres

4.1.2. As mensagens ADEXP continuam a ser legíveis por operadores humanos o que permite uma melhor aproximação à sua análise e aos factores operacionais envolvidos.

4.1.3. Um formato textual é também mais aberto e mais inteligível.

4.2. Campos Identificados e Recuperáveis

4.2.1. Uma mensagem em formato ADEXP será composta por campos.

4.2.2. Os campos serão delimitados por um caracter especial que indica o início do campo, o hífen ("-"), e identificados por palavras-chave específicas.NOTA

Note-se que determinados campos (aqueles cuja sintaxe os define como contendo o item léxico "CARACTER") podem legalmente conter o caracter "-" como parte do conteúdo do campo.

4.2.3. Esta aproximação melhora a extensibilidade e a robustez do formato. (Se um campo estiver ausente ou incorrecto, pode ser ignorado, continuando a poder ser interpretada a restante parte da mensagem. (Ver a secção 4.3).

4.2.4. Outra consequência é que a ordem dos campos numa mensagem não será relevante para determinar a sua legalidade, com a excepção do primeiro campo (campo de título obrigatório) que determina os campos permitidos.

4.2.5. Os campos podem ser simples ou compostos.

4.2.6. As partes constituintes de campos compostos são denominadas de subcampos e são definidas pela presença de palavras-chave, delimitadas pelo caracter de início de campo.

4.2.7. Os campos básicos são os campos que não contêm subcampos.

4.2.8. Os campos básicos ou compostos que compõem o primeiro nível de definição de uma mensagem são os seus campos primários.

4.2.9. Todos os constituintes de nível inferior são por definição subcampos, que por sua vez, podem ser básicos ou compostos.

4.2.10. Os campos compostos são de dois tipos, campos estruturados ou campos de lista.

4.2.11. Os campos estruturados possuem um conteúdo previamente definido composto exclusivamente de subcampos. A ordem dos subcampos num campo estruturado NÃO é significativa.

4.2.12. Os campos de lista são apresentados pela palavra-chave BEGIN e terminam com a palavra-chave END. Entre estas, podem ter lugar ocorrências repetitivas de um mesmo subcampo ou combinação de subcampos. A ordem das ocorrências no interior de um campo de listagem tem significado semântico.

4.2.13. Doravante, o termo "campo" será utilizado genericamente para designar campos primários e/ou subcampos, excepto quando for explicitamente estabelecido o contrário.

4.2.14. Os campos numa mensagem podem ser opcionais ou obrigatórios, conforme definido pelas suas sintaxes.

4.3. Campos Não Reconhecidos

4.3.1. Se numa mensagem aparecer um campo não reconhecido, este será ignorado.

4.3.2. Por outras palavras, se o sistema que analisa a mensagem não reconhecer uma palavra-chave, todo o texto até ao próximo Campo Primário conhecido, que não se encontre dentro de um campo de lista, será ignorado.

4.3.3. Dependendo do título da mensagem, o campo ignorado poderá, ou não, causar a rejeição da mensagem em análise.NOTA

Deve ter-se em linha de conta que apesar de a ADEXP ser concebida para proporcionar este tipo de flexibilidade, está à descrição dos responsáveis pela definição dos requisitos de interface, a indicação, para cada mensagem, de como o sistema deverá reagir perante um campo não reconhecido.

4.3.4. Se o campo desconhecido for um campo de lista, (encontrado devido à palavra-chave -BEGIN), então todo o seu conteúdo (até à correspondente palavra-chave -END) será ignorado.

4.3.5. De forma a evitar qualquer ambiguidade durante a recuperação que ocorre após a omissão de um campo não reconhecido, é necessária uma palavra-chave para apresentar tanto um campo primário como um subcampo.

4.3.6. Isto permite a definição de dois tipos de palavras-chave:

- Palavras-chave primárias;

- Palavras-chave secundárias.

4.3.7. Uma vez definida como sendo de um tipo, uma palavra-chave deve deixar de ser reutilizada noutro grupo de mensagens como sendo do outro tipo, excepto quando estiver dentro de um campo de lista. É possível a existência de ocorrências de uma palavra-chave primária em qualquer ponto no interior de um campo de lista sem criar ambiguidades, uma vez que a presença da palavra-chave BEGIN indica que podemos considerar a ocorrência interior como um subcampo. Exemplo (da utilização dos tipos de palavras-chave)

1) Campo Primário

-RFL F330

2) Subcampo: sempre dentro de um "Campo Composto"

-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W

em que -GEO é um campo primário composto e -GEOID, -LATTD e LONGTD são todos subcampos.

3) em que "-BEGIN" é o indicador do campo de lista e "RTEPTS" é um campo primário.

-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID

...

-END RTEPTS

NOTA

"RFL" é definido como sendo um campo primário. A inclusão no interior de um campo de lista é a única ocasião em que um campo primário pode ser utilizado como um subcampo. (Ver Exemplo 3 acima)

5. Regras sintácticas da ADEXP

5.1. Elementos Lexicais

5.1.1. Conjunto de Caracteres

5.1.1.1. O conjunto de caracteres a utilizar na permuta de mensagens no formato ADEXP será o Alfabeto Internacional Número 5 (IA-5), conforme definido na Referência 1.

5.1.1.2. O formato ADEXP foi concebido como um formato de permuta de computador para computador que pode ser transmitido em diferentes redes de computadores ou em ligações dedicadas computador-computador. Adicionalmente, existe um requisito para possibilitar a permuta de algumas mensagens ADEXP, tipicamente relacionadas com o Planeamento de Voo e a ATFM, na Rede de Telecomunicações Fixas Aeronáuticas (AFTN).

5.1.1.3. As mensagens que podem necessitar ser transmitidas via AFTN deverão ter o seu conjunto de caracteres restringido aos caracteres que têm uma correlação directa entre o Alfabeto Telegráfico Internacional Número 2 (ITA-2) e o IA-5, tal como definido na Referência 1.NOTA

Para além dos caracteres gráficos e dos formatadores conforme definidos abaixo, o conjunto de caracteres ITA-2 define "sinais" (como fita perfurada, por exemplo). Estes não fazem parte do conjunto de caracteres permitido nas mensagens ADEXP

5.1.1.4. Os caracteres cuja utilização é permitida nas mensagens ADEXP e que podem ser transmitidos via AFTN, são os caracteres gráficos e os formatadores definidos abaixo:

Caracteres Gráficos

a) letras maiúsculas (A a Z)

b) algarismos (0 to 9)

c) os seguintes caracteres gráficos especiais:

1) espaço " "

2) abrir parênteses "("

3) fechar parênteses ")"

4) hífen "-"

5) ponto de interrogação "?"

6) dois pontos ":"

7) ponto final "."

8) vírgula ","

9) apóstrofe "'"

10) sinal de igual "="

11) sinal mais "+"

12) barra "/"

Formatadores

a) Retorno do Carro ("Carriage-Return")

b) Avanço de Linha ("Line-Feed")

5.1.2. Itens Léxicos Básicos

Os seguintes itens lexicais básicos são definidos para utilização na presente especificação:

- 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

NOTA

LIM_CHAR representa qualquer caracter permitido com a excepção do HÍFEN que é reservado para indicar o início de um campo. Pelo contrário, CARACTER representa qualquer elemento permitido do conjunto de caracteres.

5.1.3. Linhas, Separadores e Delimitadores

5.1.3.1. A divisão do texto de uma mensagem em linhas não terá efeito sintáctico.

5.1.3.2. Um separador pode ser um espaço ou um formatador.

5.1.3.3. Os campos serão delineados apenas pela presença de um caracter de início de campo seguido de uma palavra-chave.

5.1.3.4. Deste modo, toda a mensagem pode legalmente consistir de uma única linha.

5.1.4. Valores com Sinal

5.1.4.1. Pode ser necessário indicar um número como sendo negativo.

5.1.4.2. Os campos que devem indicar um valor negativo deverão, no âmbito da sua definição sintáctica, indicar explicitamente o valor como sendo um "valor com sinal", ou seja, sendo positivos ou negativos. Um campo que não seja definido desta forma não poderá representar um valor negativo.

5.1.4.3. Um "valor com sinal" deverá ser sempre precedido ou pela letra "N" indicando ser negativo, ou pela letra "P" indicando ser positivo. O zero pode ser precedido de "N" ou de "P".

5.1.4.4. A sintaxe de um campo que admita um "valor com sinal" será a seguinte:

'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}

Exemplo:

Um campo designado "NUMERO" que possa conter um valor negativo de um a oito algarismos será definido da seguinte forma:

'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8

Assim

-NUMBER P5 o valor do "numero" é +5

-NUMBER N5 o valor do "número" é -5

-NUMBER 5 sintaxe inválida, terá de existir um "N" ou um "P"

5.1.5. Palavras-chave

5.1.5.1. Uma palavra-chave é uma qualquer sequência de letras maiúsculas ou de algarismos. Apresenta um campo apenas quando é precedida de um caracter início de campo ("-").

keyword ::= 1{ ALPHANUM }

5.1.5.2. As palavras-chave devem possuir a seguinte sintaxe:

'-'!{SEP}!"KEYWORD"!1{SEP}! < subfield/s or contained value >

ou seja, uma palavra-chave deverá ser separada do seu "caracter de início de campo" por nenhum ou mais separadores. Deverá ser imediatamente seguida de um ou mais separadores, seguidos dos subcampos ou valores aplicáveis.

NOTA

Importa notar que uma palavra-chave e o seu caracter de início de campo precedente podem ser separados por qualquer, ou nenhum, número de separadores.

Exemplos (Todas as sequências seguintes introduzem validamente um campo)

1) -TITLE IFPL

2) - TITLE IFPL

3) - TITLE IFPL

4) -

TITLE IFPL

5.1.5.3. Recomendação

Constitui prática recomendável evitar a utilização de um separador entre o caracter de início de campo "-" e a palavra-chave subsequente.

NOTA

1) Nos exemplos acima, a primeira ocorrência é a escolha recomendada.

2) Importa também notar que uma palavra-chave tem de ser imediatamente seguida de pelo menos um separador.

5.1.5.4. Em todo o documento, a concatenação de itens separados por, pelo menos, um separador está implicitamente representada pela notação "Concatenação Livre" (ver 3.5).NOTA

Como será posteriormente explicado, as palavras-chave também introduzem campos de lista quando forem precedidas da palavra-chave BEGIN.

5.1.5.5. As palavras-chave devem ser tão curtas quanto possível, devendo ao mesmo tempo possuir um significado semântico.

5.1.5.6.

>POSIÇÃO NUMA TABELA>

5.1.5.7. Por forma a evitar ambiguidades (utilização dupla de uma mesma palavra-chave com significados diferentes) ou redundâncias (palavras-chave diferentes com o mesmo significado), estabelece-se no Anexo A (A3) da presente Norma uma Tabela de Definição Central de Campos Primários (ou seja, palavras-chave primárias), sendo também definida no Anexo A (A4) uma Tabela de Definição Central de Subcampos (ou seja, palavras-chave secundárias).

5.2. Campos

5.2.1. Sintaxe dos Campos

campo::= campo_básico | campo_estruturado | campo_lista

campo_básico::= '-' palavra-chave valores

valores::= {CARACTER}

campo_lista::= '-' palavra-chave "BEGIN" {subcampos} '-' palavra-chave "END"

campo_estruturado::= '-' palavra-chave campo_1 campo_2 ...campo_n

NOTA

Como se verá, no caso de campos de lista, a palavra-chave não é directamente precedida de "-" mas da construção "-""BEGIN".

5.2.2. Composição da Mensagem em Termos de Campos

5.2.2.1. O primeiro campo de uma mensagem ADEXP deverá ser sempre um campo TITULO (ou seja, um campo introduzido pela palavra-chave TITLE).

5.2.2.2. O restante conteúdo de uma mensagem, em termos dos seus campos primários, será definido pelo seu TITULO.

5.2.2.3. A sintaxe das mensagens correspondentes a um dado TITULO será definida pelos campos que contém (definidos pelas suas palavras-chave):

- O nome e o conteúdo permitido dos seus campos primários;

- O nome e o conteúdo permitido dos seus subcampos.

5.2.3. Campos Básicos

5.2.3.1. A sintaxe de um campo básico será a seguinte:

campo_básico ::= '-' palavra-chave valores

5.2.3.2. "Valores" define o texto que fornece o valor do campo, podendo não introduzir um subcampo.Regra exemplificativa

arctyp::= '-' "ARCTYP" (icaoaircrafttype | "ZZZZ")

NOTA:

1) Uma regra equivalente explícita disto é:

arctyp ::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype | "ZZZZ").

2) Um exemplo de uma parte de uma mensagem é:: "-ARCTYP ZZZZ".

5.2.3.3. Recomendação

Quando existirem mais de dois valores contidos num campo básico e, em adição, exista a necessidade de expressar "escolha" ou "opção" entre estes valores, recomenda-se transformar o campo em campo estruturado e incluir os valores contidos nos subcampos.

5.2.4. Campos de Lista

5.2.4.1. A sintaxe dos campos lista será a seguinte:

campo_lista::='-' palavra-chave "BEGIN" { subcampos } '-' palavra-chave "END"

5.2.4.2. Os "subcampos" podem ser qualquer combinação de subcampos, cuja ocorrência pode aparecer zero ou mais vezes dentro do campo de lista.

5.2.4.3. A lista de subcampos num dado campo de lista deve formar um conjunto ordenado (a ordem dos subcampos é significativa).Regra exemplificativa

addr::= '-' "BEGIN" "ADDR" { fac } '-' "END" "ADDR"

NOTA:

1) Este exemplo demonstra que um campo "addr" é um campo de lista contendo 0 ou mais ocorrências de um subcampo "fac" (uma instalação de ATS).

2) Um exemplo de uma parte de uma mensagem mostrando ADDR como um campo de lista contendo subcampos FAC é:

-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END ADDR.

3) Um exemplo de uma parte de uma mensagem mostrando uma combinação de subcampos é:

xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".

5.2.5. Campos Estruturados

5.2.5.1. A sintaxe dos campos estruturados deve ser a seguinte:

campo_estruturado::= '-' palavra-chave campo_1 campo_2...campo_n

5.2.5.2. Os subcampos permitidos contidos num dado campo estruturado dependerão apenas do próprio campo estruturado.

5.2.5.3. A ordem de aparecimento dos subcampos num campo estruturado não será significativa, permitindo fáceis extensões futuras (através da adição de novos subcampos)Regra exemplificativa

pt::= '-' "PT" ptid [fl] [eto]

NOTAS:

1) Esta define o campo "pt" como um campo estruturado contendo um ponto (subcampo "ptid"), seguido opcionalmente de um nível de voo calculado (subcampo "fl"), seguido opcionalmente de uma hora estimada sobre o ponto (subcampo "eto").

2) Um exemplo de ocorrência desse campo pode ser:

"-PT -PTID RMS -FL F250 -ETO 921225120000".

5.2.5.4. Recomendação

Sempre que se julgue que o conteúdo de um campo possa evoluir no futuro, é desejável que este seja um campo estruturado. Isto permitirá o crescimento progressivo dos seus subcampos. Pelo contrário, um campo básico pode ser mais simples ou de utilização mais familiar, mas impõe uma sequência fixa de elementos (valores) com muito poucas possibilidades de crescimento.

5.2.6. O Campo COMENTÁRIOS

5.2.6.1. O campo comentários abre uma área de texto livre em que todos os caracteres disponíveis, com a excepção do caracter de início de campo ("-"), podem ser utilizados, e que se estende até ao próximo campo.

comment::= '-' "COMMENT" { LIM_CHAR }

Exemplo

-COMMENT ESTE É O INÍCIO DE UMA ÁREA DE TEXTO LIVRE

5.2.7. O Campo TÍTULO

5.2.7.1. O primeiro campo de uma mensagem ADEXP será sempre um campo de título. A sua sintaxe é definida da seguinte forma:

title::= '-' "TITLE" 1{ ALPHA }10

5.2.7.2. Os valores possíveis do campo título consistem do conjunto de títulos de mensagens ADEXP, conforme listadas no Anexo B da presente Norma.Exemplo

-TITLE IFPL

6. DESCRIÇÃO NORMALIZADA DAS MENSAGENS ADEXP

6.1. Introdução

6.1.1. Os seguintes parágrafos definem como serão descritos de uma maneira normalizada os formatos ADEXP das diferentes categorias de mensagens, no quadro da presente Norma.

6.1.2. A descrição Normalizada envolve:

- a definição de termos auxiliares;

- a definição da sintaxe e da semântica de cada campo primário individual;

- a definição da sintaxe e da semântica de cada subcampo individual;

- a definição de cada grupo de mensagens com referência à documentação que os define.

6.1.3. A presente Norma não fornece os detalhes relativos à composição dos campos nem as regras de introdução dos dados para cada título de mensagem.

6.1.4. Deve ser feita referência à documentação sobre definições (Especificação do Interface) aplicável ao grupo de mensagens em questão (Ver secção 6.5.7).

6.1.5. A documentação sobre definições deve fornecer, de uma forma normalizada, a seguinte informação para cada título de mensagem:

- uma lista dos campos primários obrigatórios;

- uma lista dos campos primários opcionais;

- as regras de introdução dos dados para cada campo, e em particular, as regras relativas à utilização dos subcampos definidos como opcionais na presente Norma;

- as regras relativas à recuperação após a detecção de um campo não reconhecido.

6.1.6. Os campos actualmente definidos e aceites por todos os Estados-Membros do Eurocontrol para utilização nas diferentes categorias de mensagens que foram definidas para utilização na ADEXP, são os indicados no Anexo A do presente documento.

6.1.7. Um campo não será utilizado para fins diferentes dos especificados na descrição da sua semântica.

6.1.8. No Anexo D estabelece-se uma lista central de campos reservados. Os "Campos reservados" não foram aceites para utilização nas mensagens ADEXP actualmente definidas. De uma maneira geral, são campos cuja possibilidade de utilização foi prevista, ou que são utilizados localmente em sistemas nacionais. O objectivo da sua inclusão na presente Norma é ajudar a garantir a singularidade dos títulos dos campos e evitar redundâncias desnecessárias.

6.2. Termos Auxiliares

6.2.1. Por forma a estabelecer uma definição inteligível dos campos, é frequentemente necessário apresentar termos auxiliares na descrição gramatical.

6.2.2. Os termos auxiliares não apresentam um campo ou um subcampo e assim, não estão associados a uma determinada palavra-chave. Podem, no entanto, aparecer na definição de mais de um campo, de um subcampo ou de um auxiliar. Por exemplo, o termo auxiliar "data" pode ser utilizado na definição de vários campos.

6.2.3. Todos os termos auxiliares necessários serão apresentados por ordem alfabética e são definidos no Anexo A (A2) da presente Norma.

6.2.4.

>POSIÇÃO NUMA TABELA>

6.3. Definição dos Campos Primários

6.3.1. Todos os campos primários usados nas mensagens ADEXP devem obedecer à sintaxe e à semântica expressas no Anexo A (A3) da presente Norma.

6.3.2. A sintaxe de cada campo será dada em primeiro lugar, seguida da sua semântica em termos claros e não ambíguos.

6.3.3. A sintaxe dos campos será expressa utilizando a notação BNF, conforme apresentada na secção 3 da presente Norma.

6.3.4.

>POSIÇÃO NUMA TABELA>

6.4. Definição dos Subcampos

6.4.1. Todos os subcampos usados nas mensagens ADEXP deverão obedecer à sintaxe e à semântica expressas no Anexo A (A4) da presente Norma.

6.4.2. Adicionalmente, para efeitos de referência cruzada, identificam-se os campos primários nos quais se incluem um determinado subcampo.

6.4.3. Um subcampo pode também ser um subcampo de outros subcampos, pelo que se apresenta também uma referência cruzada a estes subcampos.

6.4.4.

>POSIÇÃO NUMA TABELA>

6.5. Grupo de Mensagens

6.5.1. As categorias operacionais (grupos) de mensagens que foram definidas para utilização com o formato ADEXP são apresentadas no Anexo E da presente Norma.

6.5.2. Os grupos são definidos em termos da natureza operacional das mensagens trocadas e são frequentemente caracterizados pelos sistemas envolvidos.

6.5.3. Para cada grupo de mensagens deve ser feita referência à documentação sobre definições.

6.5.4. Nenhum valor de título utilizado num grupo de mensagens deve ser reutilizado com significado diferente noutro grupo.

6.5.5. No Anexo B da presente Norma, encontra-se um índice central de títulos de mensagens.

6.5.6. Para cada título de mensagem listado no índice central de títulos de mensagens é feita referência ao grupo relacionado. A referência à documentação sobre definições para cada título de mensagem é assim feita através do grupo de mensagens.

6.5.7. No Anexo C encontra-se também um índice central de títulos de mensagens reservadas. Os títulos de mensagens "Reservadas" não foram aceites para utilização nos grupos de mensagens que utilizam ADEXP actualmente definidos. Regra geral, são mensagens cuja possibilidade de utilização dentro de um dos grupos definidos foi prevista, ou que são utilizadas localmente em sistemas nacionais. O objectivo da sua inclusão na presente Norma é ajudar a garantir a singularidade dos títulos das mensagens e evitar redundâncias desnecessárias.

ANEXO A (Normativo)

DEFINIÇÕES DOS CAMPOS ADEXP

A.1. Introdução

O presente Anexo fornece uma lista de todos os campos; Termos Auxiliares; Campos Primários e Subcampos que foram definidos para utilização na ADEXP.

A.2. Termos Auxiliares ADEXP

>POSIÇÃO NUMA TABELA>

A.3. Campos primários ADEXP

>POSIÇÃO NUMA TABELA>

A.4. Subcampos ADEXP

>POSIÇÃO NUMA TABELA>

ANEXO B (Normativo)

ÍNDICE CENTRAL DE TÍTULOS DE MENSAGENS ADEXP

>POSIÇÃO NUMA TABELA>

ANEXO C (Normativo)

ÍNDICE CENTRAL DE TÍTULOS RESERVADOS DE MENSAGENS

C.1. Introdução

O presente anexo contém um índice central de títulos reservados de mensagens que ainda não foram definidas para utilização na ADEXP. A sua inclusão no presente anexo indica ter sido prevista a sua utilização futura ou que já se encontram em uso, embora a sua utilização esteja limitada a sistemas locais.

C.2. Objectivo

O objectivo do fornecimento de uma lista de títulos que ainda não foram formalmente adoptados para utilização na presente Norma ADEXP é evitar, tanto quanto possível, a criação de uma redundância sempre que um novo título seja necessário para um fim específico ou a criação de um título que já é utilizado num sistema local.

C.3. Títulos Reservados de Mensagens

>POSIÇÃO NUMA TABELA>

ANEXO D (Normativo)

ÍNDICE CENTRAL DE CAMPOS RESERVADOS

D.1. Introdução

O presente anexo contém um índice central de campos reservados (Primários, Subcampos e Termos Auxiliares), que ainda não foram definidos para utilização na ADEXP. A sua inclusão no presente anexo indica ter sido prevista a sua utilização futura ou que já se encontram em uso, embora a sua utilização esteja limitada a sistemas locais.

D.2. Objectivo

O objectivo do fornecimento de uma lista de campos que ainda não foram formalmente adoptados para utilização na presente Norma ADEXP é evitar, tanto quanto possível, a criação de uma redundância sempre que um novo campo seja necessário para um fim específico ou a criação de uma palavra-chave que já é utilizada num sistema local.

D.3. Termos Auxiliares Reservados

>POSIÇÃO NUMA TABELA>

D.4. Campos Primários Reservados

>POSIÇÃO NUMA TABELA>

D.5. Subcampos Reservados

>POSIÇÃO NUMA TABELA>

ANEXO E (Informativo)

INTRODUÇÃO AOS GRUPOS DE MENSAGENS

INTRODUÇÃO

O presente Anexo faz a introdução aos diferentes grupos ou categorias de mensagens cuja permuta é possível na ADEXP. No Anexo B é fornecida uma lista completa de todos os títulos de mensagens ADEXP.

NOTA

Para conhecer as condições exactas, as regras de aplicação e a utilização dos campos, em particular a utilização dos campos opcionais, deve ser feita referência à documentação aplicável (por exemplo, o documento sobre a Especificação do Interface) dos sistemas envolvidos.

E.1. Mensagens de Plano de Voo

E.1.1. Introdução

As mensagens nesta categoria são trocadas essencialmente entre os AO, o IFPS e as Unidades ATS aplicáveis.

E.1.2. Definição dos Títulos das Mensagens

Os títulos das mensagens nesta categoria são os seguintes:

ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL, IRPL, IRQP, MAN, RCHG, RCNL, REJ.

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 3.

E.1.3. Composição dos Campos Primários

A definição detalhada do conteúdo das mensagens, das regras de introdução de dados e da utilização dos campos obrigatórios e opcionais, pode ser encontrada no Documento Ref.a 3.

Exemplo:

Mensagem de Plano de Voo

-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. Mensagens de Gestão do Fluxo de Tráfego Aéreo

E.2.1. Introdução

As mensagens nesta categoria são trocadas essencialmente entre o sistema TACT da CFMU do Eurocontrol, os Operadores das Aeronaves e as Unidades ATS.

E.2.2. Mensagens de Atribuição de Janelas Assistida por Computador (CASA)

Os títulos das mensagens nesta categoria são os seguintes:

DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM, SPA, SRJ, SRM, SRR.

E.2.2.1. Definição dos Títulos das Mensagens

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 5.

E.2.2.2. Composição dos Campos Primários

A definição detalhada do conteúdo das mensagens, das regras de introdução de dados e da utilização dos campos obrigatórios e opcionais, pode ser encontrada no Documento Ref.a 5.

Exemplo:

-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -EOBD 980324 -EOBT 0945

-CTOT 010 -REGUL UZZU11 -TAXITIME 0020

E.2.3. Mensagens de Informação

Os títulos das mensagens nesta categoria são os seguintes:

FSA

E.2.3.1. Definição dos Títulos das Mensagens

O material de definição para esta mensagem estará disponível no Documento Ref.a 5.

E.2.3.2. Composição dos Campos Primários

A definição do conteúdo das mensagens, das regras de introdução de dados e da utilização dos campos obrigatórios e opcionais será encontrada no Documento Ref.a 5

Exemplo:

Primeira Mensagem de Activação do Sistema

-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSITION -PTID LIFFY -TO 1646

E.3. Mensagens de Coordenação ATC

E.3.1. Introdução

As Mensagens de Coordenação são utilizadas para automatizar a coordenação operacional e a troca de informação entre unidades ATC. As mensagens garantem a entrega atempada de informação operacional relacionada com a coordenação através das capacidade de extracção e de transmissão de informação normalizadas.

E.3.2. Definição dos Títulos das Mensagens

Os títulos das mensagens nesta categoria são os seguintes:

ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS, PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 6.

E.3.3. Composição dos Campos Primários

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 6.

Exemplos:

Mensagem de Proposta de Entrega

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

-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN

Mensagem de Activação

-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. Mensagens de Gestão do Espaço Aéreo

E.4.1. Introdução

Mensagens utilizadas na coordenação da gestão do espaço aéreo. Estas mensagens abrangem a gestão do meio no qual o tráfego se movimenta: as rotas permanentes e condicionais, as áreas temporariamente isoladas, áreas perigosas e proibidas, etc.

E.4.2. Definição dos Títulos das Mensagens

Os títulos das mensagens nesta categoria são os seguintes:

AUP, CRAM, UUP.

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 7.

E.4.3. Composição dos Campos Primários

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 7.

Exemplo:

Mensagem de Disponibilidade de Rota Condicional

-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. Mensagens de Coordenação Civil / Militar

E.5.1. Introdução

Mensagens usadas na coordenação de informação de voo e de pedidos de cruzamento do espaço aéreo entre unidades ATS civis e militares.

E.5.2. Definição dos Títulos das Mensagens

Os títulos das mensagens nesta categoria são os seguintes:

ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.

Todo o material de definição para estas mensagens encontra-se no Documento Ref.a 7.

E.5.3. Composição dos Campos Primários

Todo o material de definição para estas mensagens encontra-se no Documento em Ref.a 7.

Exemplo:

Mensagem de Pedido de Autorização de Cruzamento

-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

Mensagem de Aceitação

-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -FAC EBSZZXZQ

-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -FAC EBBUZXZQ

-SEQNUM 012

ANEXO F (Informativo)

EXEMPLOS DO FORMATO DE MENSAGENS ADEXP

Os exemplos seguintes são apresentados como demonstração do formato ADEXP e não como exemplo do conteúdo das mensagens. A mensagem utilizada é uma IFPL e apesar de correcta à data da publicação, não se garante a precisão da composição dos campos, etc.

O EXEMPLO 1 abaixo foi apresentado de forma a ser facilmente legível. Isto foi conseguido com a utilização de retornos de carro (carriage returns), mudanças de linha, espaços, etc. No entanto, esta disposição não faz parte das regras de formatação da ADEXP.

A apresentação de uma mensagem está pois à discrição do sistema receptor. Os exemplos apresentados nos EXEMPLO 2 e EXEMPLO 3 são ambos representações válidas da mesma mensagem que no EXEMPLO 1.

EXEMPLO 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

EXEMPLO 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

EXEMPLO 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

ANEXO G (Informativo)

DESENVOLVIMENTOS FUTUROS

G.1. Introdução

O presente anexo destina-se a fornecer uma indicação das propostas de desenvolvimento futuro da ADEXP, bem como as razões e objectivos por detrás do desenvolvimento

G.2. Objectivos

Um dos objectivos mais importantes durante o desenvolvimento da ADEXP foi a necessidade de desenvolver um formato que permitisse a um sistema receptor, "ignorar" ou "omitir" com êxito um campo desconhecido ou não reconhecido, sem ter de necessariamente invalidar a mensagem que está a ser processada. Esta aplicação pode permitir o aditamento de um novo campo numa mensagem sem ser necessário modificar previamente todos os sistemas receptores e de, seguidamente, proceder a uma "comutação" coordenada muito cuidadosa.

Este objectivo é conseguido na presente norma através da utilização de campos primários e de subcampos previamente definidos, apresentados por palavras-chave únicas. Um analisador lexical ou sintáctico que não "reconheça" uma palavra-chave deve ignorar todo o texto até ao próximo Campo Primário conhecido, que não se encontre num Campo de Lista. A recuperação é, assim, conseguida ao nível dos campos primários.

Os desenvolvimentos actuais e futuros na definição das novas mensagens indicam que em determinadas áreas é exigido um maior nível de complexidade, sempre que seja necessário encaixar um terceiro ou mesmo um quarto nível de campos. (A Mensagem de Atribuição de Rota Condicional (CRAM) é um exemplo actual deste requisito). Hoje em dia, a ADEXP oferece a possibilidade de construir uma mensagem com qualquer nível de encaixe. No entanto, é inexistente a capacidade de recuperação de um campo não reconhecido, que ocorra talvez no terceiro ou quarto nível de encaixe, sem a possibilidade de uma interpretação incorrecta da informação ou da necessidade de invalidar a mensagem. A necessidade das modificações propostas do formato ADEXP são concebidas por forma a garantir que um analisador lexical ou sintáctico seja permanentemente capaz de determinar onde se encontra dentro da estrutura de uma mensagem ou de um campo individual e, desta forma, permitir que a recuperação tenha lugar em qualquer nível de encaixe, sem o risco de má interpretação da informação.

G.3. Proposta

Por forma a atingir o objectivo de recuperação em qualquer nível dentro de uma mensagem, é necessário que o analisador lexical seja capaz de determinar o fim, e também o início, de um campo. O actual formato permite apenas determinar o início de um campo utilizando o caracter "-".

Ir-se-á propor que, numa futura edição da ADEXP, seja introduzida a utilização de parênteses para indicar, respectivamente, o início e o fim de um campo. A actual utilização do caracter "-" para indicar o início de um campo seria substituída pelo caracter "(". O fim do campo, que actualmente não é indicado de modo explícito, seria indicado, no futuro, pelo caracter ")". Os exemplos seguintes destinam-se a demonstrar o princípio.

Exemplos

>POSIÇÃO NUMA TABELA>

ANEXO III

INTERCAMBIO DE INFORMAÇÃO DE VOO - DOCUMENTO DE CONTROLO DO INTERFACE (FDE-ICD), EDIÇÃO 1.0

(referência do documento do Eurocontrol COM.ET1.ST12-STD)

ÍNDICE

>POSIÇÃO NUMA TABELA>

INFORMAÇÃO RELATIVA AOS DIREITOS DE AUTOR

O presente documento foi produzido pela Agência Eurocontrol.

Os direitos de autor pertencem à Agência Eurocontrol.

O conteúdo, ou parte dele, está assim à livre disposição dos representantes dos Estados-membros, mas a cópia ou a divulgação a outras partes está sujeita ao consentimento prévio, por escrito, da Agência Eurocontrol.

PREFÁCIO

1. Organismo Responsável

O presente Documento Normativo foi preparado e é mantido pelo Grupo de Trabalho de Intercâmbio de Informação relacionada com os Planos de Voo (FPDE), da Organização Europeia para a Segurança da Navegação Aérea (Eurocontrol).

2. Documento do Programa de Trabalho do EATCHIP

A presente Norma está relacionada com o Documento do Programa de Trabalho do EATCHIP (EWPD), Domínio das Comunicações, Tarefa Executiva 01, Tarefa Especialista 12.

3. Aprovação da Norma

3.1. A presente Norma é adoptada em conformidade com os procedimentos especificados nas Directivas para a Normalização do Eurocontrol, Ref. 000-2-93.

3.2. A presente Norma entra em vigor após a sua adopção pela Comissão Permanente do Eurocontrol e substitui a Edição 1, Parte 3, da Norma do Eurocontrol para o Intercâmbio de Informação em Tempo Real (OLDI): REQUISITOS TÉCNICOS (Documento de Controlo do Interface a Curto Prazo), Ref. 001-3-92.

4. Corrigenda Técnica e Alterações

A presente Norma é mantida sob revisão para determinar as alterações necessárias ou a corrigenda técnica. O procedimento para a manutenção da presente Norma é estabelecido no Anexo H das Directivas para o Projecto Uniforme e Apresentação dos Documentos Normativos do Eurocontrol, Ref. 000-1-92.

5. Convenções Editoriais

5.1. O formato da presente Norma obedece às Directivas para o Projecto Uniforme e Apresentação dos Documentos Normativos do Eurocontrol.

5.2. A seguinte notação foi utilizada para indicar a situação de cada declaração:

- As declarações normativas utilizam o verbo chave "deve" e foram impressas em texto romano normal;

- As declarações recomendadas utilizam o verbo chave "deveria" e foram impressas em itálico, sendo o estado indicado pelo prefixo Recomendação.

5.3. Qualquer outra informação considerada essencial para a interpretação de um determinado parágrafo, será integrada no texto como NOTA. Uma nota é considerada como meramente informativa, não contendo quaisquer especificações, sendo colocada imediatamente a seguir ao parágrafo a que se refere.

5.4. A título excepcional, para apresentar de forma adequada a Lista dos Requisitos dos Perfis (PRL) no Anexo E, algumas das tabelas não são separadas por parágrafos e não continuam durante várias páginas.

6. Relação com outros Documentos Normativos

6.1. O presente Documento Normativo do Eurocontrol substitui a Edição 1, Parte 3, do Documento de Controlo do Interface a Curto Prazo OLDI, da Norma do Eurocontrol relativa à OLDI [Referência 13].

6.2. O presente Documento Normativo do Eurocontrol é a primeira parte do que se espera ser uma série de Documentos de Controlo do Interface (ICD) de Normas do Eurocontrol para o Intercâmbio de Informação de Voo.

7. Situação dos Anexos da presente Norma

Os Anexos à presente Norma têm a seguinte situação:

- Anexo A - Normativo

- Anexo B - Normativo

- Anexo C - Normativo

- Anexo D - Normativo

- Anexo E - Normativo

- Anexo F - Informativo

- Anexo G - Informativo

- Anexo H - Informativo

8. Idioma Utilizado

No texto original da presente Norma foi utilizada a língua Inglesa.

1. INTRODUÇÃO

A presente Norma do Eurocontrol baseia-se no Documento de Controlo do Interface a Curto Prazo, desenvolvido pelo antigo Subgrupo Técnico da OLDI que foi incumbido da tarefa de definir novas normas de interface para a futura operação da OLDI entre Centros de Controlo de Área.

As anteriores ligações OLDI baseavam-se em protocolos proprietários tais como o INTERCAUTRA ou o Datenübertragungs- und Verteilungssystem (DÜV), que correm em circuitos ponto-a-ponto dedicados ou redes limitadas, e que exigiam a utilização de hardware e software especializados.

Para a maior parte das novas ligações planeadas, considerou-se ser desejável a migração para uma arquitectura baseada na rede e a adopção de normas de telecomunicações internacionais, permitindo a implementação das ligações de uma forma mais eficaz em termos de custo, através da redução do número de conexões em cada Centro e da possibilidade de utilização de hardware e software corrente no mercado.

A presente Norma do Eurocontrol formaliza e amplia o ICD a Curto Prazo. O ST-ICD sofreu nova redacção, com vista a fornecer uma especificação mais rigorosa que melhorará a interoperabilidade, sendo ainda adequado à constituição de uma base para os futuros ICD por forma a cumprirem os requisitos em desenvolvimento do Intercâmbio de Informação de Voo (FDE), incluindo uma utilização mais alargada de redes partilhadas e a introdução de novas normas relativas à camada inferior. A presente Norma do Eurocontrol estabelece um conjunto mínimo de funcionalidades que, com modificações menores, podem ser suportadas pelas implementações OLDI existentes, utilizando tanto ligações ponto-a-ponto como redes de comutação de pacotes em conformidade com a Recomendação X.25, de 1980 ou posterior, do Comité Consultivo Internacional Telegráfico e Telefónico (CCITT). No processo de aquisição podem ser especificadas mais possibilidades. O presente ICD não impede os acordos bilaterais de irem mais longe.

As instalações que para além do especificado no documento, ou que pretenda substitui-lo, desejem correr outros protocolos aplicacionais, podem requerer a alteração do presente protocolo, ou separar o seu protocolo utilizando circuitos virtuais diferentes.

2. ÂMBITO

2.1. O presente Documento Normativo do Eurocontrol especifica um interface de comunicação de dados para o intercâmbio de mensagens de informação relacionadas com voos entre Centros de Controlo de Área (ACC). É apresentado na forma de um perfil de Interligação de Sistemas Abertos (OSI) tal como definido no Relatório Técnico (TR) 10000-2 da Comissão Electrotécnica Internacional da Organização Internacional de Normalização (ISO/IEC) [Referência 3]. O perfil abrange tanto as camadas inferiores (perfil T) como as camadas superiores (perfil A).

2.2. O presente Documento Normativo do Eurocontrol aplica-se aos seguintes cenários:

- suporte da OLDI, tal como descrito na Norma do Eurocontrol N.o 001-92, Edição 1;

- suporte da transmissão de mensagens de aplicações OLDI dos sistemas dos ACC para os da Unidade Central de Gestão de Tráfego (CFMU).

2.3. A Norma é aplicável à ligação utilizando:

- circuitos ponto-a-ponto em linhas alugadas, ou

- circuitos ponto-a-ponto da Rede Telefónica Pública Comutada (PSTN), ou

- redes de dados de comutação de pacotes, ou redes de dados de comutação de pacotes interligadas, que constituam um interface em conformidade com a Recomendação X.25 do CCITT, de 1980 ou posterior

NOTAS

1. A combinação entre Sistemas de Processamento de Planos de Voo (FPPS) encontra-se representada na Figura 1.

2. A Figura 1 não ilustra as ligações de reserva potenciais, tais como as PSTN, para as quais se fornece orientação no Anexo H.

Figura 1

Disposição do Interface

>PIC FILE= "L_2000254PT.017801.EPS">

2.4. Não são estabelecidos pela presente Norma os detalhes dos aspectos de segurança do interface de comunicação de dados especificado. No entanto, é especificada no Anexo C.5.4 uma disposição básica e pode ser encontrada alguma orientação adicional no Anexo H à presente Norma do Eurocontrol.

3. REFERÊNCIAS

3.1. Introdução

Os seguintes documentos e normas contêm disposições que, através de referência no presente texto, constituem disposições da presente Norma do Eurocontrol.

À data da publicação da presente Norma do Eurocontrol, as edições indicadas para as normas e documentos referenciados eram válidas.

Qualquer revisão aos Documentos mencionados da Organização da Aviação Civil Internacional (ICAO), será imediatamente tida em consideração para a revisão da presente Norma do Eurocontrol.

As revisões dos outros documentos referenciados não farão parte das disposições da presente Norma do Eurocontrol, até serem formalmente revistas e incluídas no presente Documento Normativo do Eurocontrol.

Em caso de conflito entre os requisitos do presente Documento Normativo do Eurocontrol e o conteúdo destes outros documentos referenciados, terá precedência a presente Norma do Eurocontrol.

3.2. Referências

1. Recomendação X.25 da ITU-T (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" (Interface entre equipamentos terminais de dados (DTE) e equipamentos de terminação do circuito de dados (DCE) para terminais operando em modo de pacotes e ligados a uma rede pública de dados através de um circuito dedicado).

2. ISO/IEC TR 10000-1:1992, "Information technology - Framework and taxonomy of International Standardized Profiles: - Part 1: Framework" (Tecnologia da informação - Organização e taxonomia dos Perfis Normalizados Internacionais: - Parte 1: Organização) (2.a edição).

3. ISO/IEC TR 10000-12:1994, "Information technology - Framework and taxonomy of International Standardized Profiles - Part 2: Principles and Taxonomy for OSI Profiles" (Tecnologia da informação - Organização e taxonomia dos Perfis Normalizados Internacionais: - Parte 2: Princípios e Taxonomia dos Perfis OSI) (3.a edição).

4. Recomendação X.21 da ITU-T (1992) (Rev. 1), "Interface between data terminal equipment (DTE) and data circuit-terminating equipment (DCE) for synchronous operation on public data networks" (Interface entre equipamentos terminais de dados (DTE) e equipamentos de terminação do circuito de dados (DCE) para operação síncrona em redes públicas de dados).

5. Recomendação X.21bis do CCITT (1988), "Use on public data networks of data terminal equipment (DTE) which is designed for interfacing to synchronous V-Series modems" (Utilização, em redes públicas de dados, de equipamentos terminais de dados (DTE) concebidos para fazer interface com modems síncronos da Série V).

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" (Tecnologia da informação - Telecomunicações e intercâmbio de informação entre sistemas - Procedimentos de controlo da ligação de dados de alto nível - Descrição dos procedimentos da Ligação de Dados DTE compatíveis com o X.25 LAPB) (2.a edição).

7. ISO/IEC 8208:1993, "Information Technology - Data communications - X.25 Packet Layer Protocol for Data Terminal Equipment" (Tecnologia da informação - Comunicações de dados - Protocolo da Camada de Pacotes X.25 para Equipamento Terminal de Dados) (3.a edição).

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" (Tecnologia da informação - Perfis Normalizados Internacionais TB, TC, TD e TE - Serviço de Transporte em modo Ligação sobre Serviço de Rede em modo Ligação - Parte 9: Requisitos dependentes do tipo de sub-rede para a Camada de Rede, Camada da Ligação de Dados e Camada Física relativos ao acesso permanente a uma rede de dados de comutação de pacotes que utiliza chamadas virtuais).

9. ISO/IEC 7498-1:1994, "Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model" (Tecnologia da informação - Interligação de Sistemas Abertos - Modelo de Referência Básico: O Modelo Básico) (2.a edição).

10. ISO/IEC 8348:1993, "Information technology - Open Systems Interconnection - Network Service Definition" (Tecnologia da informação - Interligação de Sistemas Abertos - Definição do Serviço de Rede) (1.a edição).

11. ISO/IEC 8072:1994, "Information technology - Open Systems Interconnection - Transport service definition" (Tecnologia da informação - Interligação de Sistemas Abertos - Definição do serviço de transporte) (2.a edição).

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" (Tecnologia da informação - Telecomunicações e intercâmbio de informação entre sistemas - Utilização do X.25 para o Serviço de Rede em modo Ligação da OSI) (2.a edição).

13. "Eurocontrol Standard for On-Line Data Interchange" (Norma do Eurocontrol para o Intercâmbio de Informação em Tempo Real (OLDI)), N.o 001-92, 1.a Edição, 1992.

14. ISO/IEC 9646-1:1994, "Information technology - Open Systems Interconnection - Conformance testing methodology and framework - Part 1: General concepts" (Tecnologia da informação - Interligação de Sistemas Abertos - Organização e metodologia dos ensaios de conformidade - Parte 1: Conceitos gerais) (2.a edição).

15. ICD FDE do Eurocontrol (Divisão de Sistemas de Controlo da Área Superior (UAC) de Maastricht), 1.a Parte, Plano do Ensaio de Integração, Versão 1.0, datada de 10 de Maio de 1996.

16. ICD FDE do Eurocontrol, Parte 1 - "Reliability, Availability and Security - Technical Report" (Fiabilidade, Disponibilidade e Segurança - Relatório Técnico), versão 1.0, de 20 de Abril de 1997.

17. Recomendação X.32 do ITU-T (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" (Interface entre DTE e DCE para terminais operando em modo de pacotes e acedendo a uma rede pública de dados de comutação de pacotes através de uma rede telefónica pública comutada ou de uma rede digital com integração de serviços ou de uma rede pública de dados com comutação de circuitos).

18. Recomendação E.164 da ITU-T (1991) (Rev. 1), "Numbering plan for the ISDN era" (Plano de numeração para a era RDIS).

19. Recomendação X.75 da ITU-T (1993) (Rev. 1), "Packet-switched signalling system between public network providing data transmission service" (Sistema de sinalização de comutação de pacotes entre redes públicas que prestam serviço de transmissão de dados).

20. Recomendação X.121 da ITU-T (1993), "International numbering plan for public data networks" (Plano de numeração internacional para redes públicas de dados).

4. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS

4.1. Definições

4.1.1. Para os efeitos do presente Documento Normativo do Eurocontrol, aplicam-se as seguintes definições:

4.1.2. Perfil: Um conjunto de uma ou mais normas base, e, onde aplicável, a identificação das classes escolhidas, subconjuntos, opções e parâmetros dessas normas base, necessários para a realização de uma determinada função [Referência 2].

4.1.3. Lista de Requisitos dos Perfis (PRL): Os requisitos dos perfis são expressos na forma de requisitos de conformidade e são dispostos numa lista de formato tabular [Referência 2].

4.1.4. Perfil T: Perfil de Transporte que disponibiliza um Serviço de Transporte em modo Ligação [Referência 3].

4.1.5. Perfil A: Perfil Aplicativo que requer um Serviço de Transporte em modo Ligação [Referência 3].

4.1.6. Declaração de Conformidade da Implementação do Protocolo (PICS): Uma declaração efectuada pelo fornecedor de um sistema OSI, especificando as capacidades que foram implementadas para um determinado protocolo OSI [Referência 14].

4.2. Símbolos e Abreviaturas

>POSIÇÃO NUMA TABELA>

4.3. Notações

4.3.1. Para os efeitos do presente Documento Normativo do Eurocontrol, os valores binários ou a sequência de bits são apresentados em hexadecimal, utilizando a notação 'd'H, em que a letra d representa um dígito ou uma sequência de dígitos hexadecimais.

4.3.2. Para os efeitos do presente Documento Normativo do Eurocontrol, a representação hexadecimal de uma sequência de bits é formada tomando 4 bits de cada vez desde o bit mais significativo (MSB) até ao bit menos significativo (LSB).NOTA

Salvo se especificado em contrário nas Normas internacionais a que se faz referência, uma sequência de bits é transmitida desde o MSB até ao LSB.

4.3.3. Para os efeitos do presente Documento Normativo do Eurocontrol, a situação do suporte das características de uma norma base, ou da presente Norma do Eurocontrol, é indicada em letras maiúsculas (por exemplo, M, O, O.< n >, X). O significado exacto de cada símbolo de situação é descrito nos Anexos a esta Norma do Eurocontrol antes da sua utilização.

4.3.4. Com vista à definição do perfil da Parte 1 do ICD FDE no presente Documento Normativo do Eurocontrol, a situação do suporte das características de uma norma base, ou da presente Norma do Eurocontrol, é indicada em letras minúsculas (por exemplo, m, o, o.< n >, x).NOTA

O resultado é um novo aperfeiçoamento das características das normas base que são condicionais, opcionais, ou dependentes de valores (ver E.3.1).

5. GENERALIDADES TÉCNICAS

5.1. Pilha de Protocolos

NOTA

Ilustra-se na Figura 2 a pilha de protocolos dos perfis da presente Norma do Eurocontrol. A figura coloca os protocolos na organização do Modelo de Referência Básico da OSI [Referência 9], alinhando a pilha com as camadas OSI correspondentes. No entanto, a pilha de protocolos é uma especificação para os sistemas pré-OSI e não suporta as várias funções que são permitidas nos protocolos OSI das camadas OSI correspondentes.

Figura 2

Pilha de Protocolos do Perfil

>PIC FILE= "L_2000254PT.018201.EPS">

5.2. Estrutura do Perfil

NOTAS

1. Conforme ilustrado na Figura 2, a pilha do perfil combina vários protocolos da camada inferior dos quais apenas o Protocolo da Camada de Pacotes (PLP) X.25 [Referência 1] e respectivos protocolos de suporte, X.21 [Referência 4] e X.21bis [Referência 5], são definidos nas normas existentes da ISO/IEC e da União Internacional das Telecomunicações - Sector de Normalização das Telecomunicações (ITU-T). Os outros protocolos das camadas superiores são definidos nos Anexos (Anexos A, B e C) ao presente Documento Normativo do Eurocontrol.

2. Os requisitos de conformidade do perfil podem fazer referência a estas especificações em pé de igualdade com normas externas, sendo estabelecidos na Secção 6. Os requisitos detalhados são estabelecidos utilizando o formato tabular dos pró-formas PRL (Anexo E) e PICS (os pró-formas para os protocolos definidos nos Anexos são dados no Anexo D). A utilização destes pró-formas PRL e PICS no desenvolvimento e/ou nos processos de aquisição é explicada no Anexo E.

5.3. Relação com as Versões Anteriores da Especificação

NOTAS

1. Este perfil baseia-se no ICD-ST desenvolvido pelo antigo Subgrupo Técnico OLDI. Os formatos dos protocolos e dos pacotes definidos no presente Documento Normativo do Eurocontrol são um subconjunto compatível dos do ICD-ST com a excepção de que a presente Norma do Eurocontrol estabelece requisitos mais detalhados quanto à utilização do PLP X.25, inclui o suporte obrigatório do bit-M e corrige a especificação inconsistente do valor do Identificador do Formato e da Autoridade (AFI) no endereço do Ponto de Acesso ao Serviço de Rede (NSAP).

2. A principal alteração ao estilo do presente Documento Normativo do Eurocontrol está relacionada com a estrutura da especificação do ICD. O Protocolo de Transferência de Mensagens (Anexo A) está separado do perfil-T de suporte. Isto facilita a utilização de outros perfis-T quando tal se tornar necessário para apoiar os requisitos FDE em desenvolvimento.

3. As partes da especificação ICD-ST que tratam do controlo dos circuitos virtuais X.25 e da delimitação das mensagens aplicativas, encontram-se agora no Protocolo de Cabeçalho das Mensagens (Anexo B), que constitui uma camada de transporte mínima para o FDE.

6. REQUISITOS DOS PERFIS

6.1. Requisitos de Conformidade

6.1.1. Uma implementação que pretenda ser declarada em conformidade com a presente especificação deve cumprir os requisitos estabelecidos nas secções 6.2 e 6.3 abaixo.

6.1.2. Uma pretensão da declaração de conformidade será suportada por uma Declaração de Conformidade com a Implementação do Perfil, tal como descrita nos Anexos D e E.

6.2. Requisitos da Camada superior

6.2.1. Uma implementação conforme deverá satisfazer os requisitos da norma base, especificados no Anexo A.

6.2.2. Uma implementação conforme deverá satisfazer as restrições que constam da Lista de Requisitos do Perfil no Anexo E.7.

6.3. Requisitos da Camada inferior

6.3.1. Requisitos da Camada de Transporte

6.3.1.1. Uma implementação conforme deverá satisfazer os requisitos da norma base, especificados no Anexo B.

6.3.1.2. Uma implementação conforme deverá satisfazer as restrições que constam da Lista de Requisitos do Perfil no Anexo E.8.1.

6.3.1.3. Uma implementação conforme deverá satisfazer o requisito de suporte de tamanhos da Unidade de Dados do Serviço de Transporte (TSDU) até 4097 octetos, inclusive.NOTA

O primeiro octeto da TSDU corresponde a um campo do Cabeçalho da Mensagem (ver A.4.10 e B.4.4), deixando um máximo de 4096 octetos para os dados dos utilizadores.

6.3.2. Requisitos da Camada de Rede

6.3.2.1. Uma implementação conforme deverá satisfazer os requisitos da ISO/IEC 8208 [Referência 7] de acordo com a estrutura do protocolo dada no Anexo C.

6.3.2.2. Uma implementação conforme deverá satisfazer as restrições que constam da Lista de Requisitos do Perfil no Anexo E.8.2.

6.3.2.3. Uma implementação conforme deverá, se for suportada a operação de equipamento terminal de dados (DTE)-DTE, ser capaz de configurar, através dos mecanismos de gestão do sistema, a escolha da função do DTE ou do equipamento terminal do Circuito de Dados (DCE) na operação DTE-DTE.

6.3.2.4. Uma implementação conforme deverá, em qualquer das funções definidas em 6.3.2.3, ser capaz de iniciar uma ligação de acordo com a especificação do Anexo C, ou seja, o protocolo é totalmente simétrico.NOTA

Algumas implementações existentes baseadas no ICD-ST, podem não ser capazes de iniciar ligações de rede de acordo com o protocolo do Anexo C.

6.3.2.5. Uma implementação conforme deverá, durante um período de tempo, combinar com a funcionalidade de Tamanhos Assumidos de Pacotes Não Normalizados, com o valor de 256 em ambas as direcções de transmissão.

6.3.2.6. Uma implementação conforme deverá utilizar os endereços NSAP definidos no Anexo C.

6.3.2.7. Uma implementação conforme deverá colocar o bit-D a 0 nos pacotes CALL REQUEST, CALL ACEPTED e DATA.NOTA

Colocar D=0 nos pacotes CALL REQUEST e CALL ACEPTED tem o efeito de não utilizar a Confirmação de Entrega.

6.3.3. Requisitos da Camada de Ligação de Dados

6.3.3.1. Uma implementação conforme deverá satisfazer os requisitos de conformidade da ISO/IEC 7776 [Referência 6] para o Protocolo de Ligação Simples do Equilíbrio do Protocolo de Acesso ao Circuito (LAPB).

6.3.3.2. Uma implementação conforme deverá também satisfazer as restrições que constam da Lista de Requisitos do Perfil no Anexo E.8.3.

6.3.4. Requisitos da Camada Física

Uma implementação conforme deverá satisfazer os requisitos de conformidade da cláusula 7 da ISP 10606-9 da ISO/IEC [Referência 8].

7. MÉTODOS DE ENSAIO

NOTAS

1. No Anexo F é feita uma abordagem aos ensaios de conformidade das implementações da presente especificação.

2. A utilização dos pró-formas PRL e PICS, fornecidos pela presente especificação para a conformidade do documento, é especificada no Anexo E.

ANEXO A (Normativo)

PROTOCOLO DE TRANSFERÊNCIA DE MENSAGENS

A.1. Introdução

A presente especificação define um protocolo para a implementação de um serviço simples de transferência de mensagens destinado a aplicações que requeiram intercâmbio de informação de voo.

A.2. Serviço Implementado

O protocolo de Transferência de Mensagens (MT) implementa os seguintes serviços não confirmados:

MT-Associar: estabelecer uma associação de transferência de mensagens de aplicação;

MT-Dados: transferir uma mensagem de aplicação constituída por caracteres do Código Normalizado Americano para o Intercâmbio de Informação (ASCII);

MT-Cancelar: terminar uma associação de transferência de mensagens de aplicação.

A.3. Serviço Assumido

O presente protocolo de Transferência de Mensagens assume um subconjunto do Serviço de Transporte em modo Ligação, conforme definido na ISO/IEC 8072 [Referência 11], tal como o oferecido pelo protocolo definido no Anexo B à presente Norma do Eurocontrol.

A.4. Especificação do Protocolo

A.4.1. Introdução

No texto que se segue, apenas se descreve a operação de uma associação de Transferência de Mensagens iniciada pela aplicação. Poderão ser suportadas outras associações no mesmo interface de rede, repetindo estes procedimentos para cada ligação de transporte subjacente.

A.4.2. Tipos de Dados

O presente Anexo identifica quatro tipos de mensagens de aplicação que são equivalentes aos definidos na Norma do Eurocontrol N.o 001-3-92, Edição 1:

Mensagens de Sistema: Estas mensagens devem ser utilizadas na monitorização da ligação (mensagem HEARTBEAT) e no controlo da aplicação (mensagens STARTUP e SHUTDOWN).

Mensagens Operacionais: Estas mensagens serão ligadas a um contexto operacional específico e são definidas nos Documentos e Normas do Eurocontrol que fazem uso da presente Norma para o intercâmbio de informação. O Documento Normativo do Eurocontrol para o Intercâmbio de Informação em Tempo Real define mensagens operacionais tais como a mensagem de Activação (ACT), de Informação Avançada de Fronteira (ABI) e de Confirmação Lógica (LAM).

Mensagens de Operador: Estas mensagens devem conter texto livre. A sua utilização será objecto de acordo bilateral. Por exemplo, podem ser utilizadas para trocar informação de ensaio ou para informar a outra parte acerca de acções do operador.

Mensagens de Situação:A utilização e o conteúdo destas mensagens será objecto de acordo bilateral. Por exemplo, podem ser utilizadas para trocar informação de gestão do sistema.

NOTAS

1. A utilização de mensagens de Sistema faz parte da operação deste protocolo e o seu formato encontra-se especificado no parágrafo A.4.10.3 do presente Anexo.

2. A utilização e o formato das mensagens de Situação estão sujeitos a acordo bilateral, não sendo objecto de especificação adicional na presente Norma do Eurocontrol.

3. O estado do protocolo determina que tipos de mensagens podem ser transmitidas, tal como especificado nos parágrafos seguintes.

A.4.3. Estabelecimento da Associação

A.4.3.1. O protocolo encontra-se, inicialmente, no estado IDLE.

A.4.3.2. É executada a primitiva MT-Pedido-de-Associação para estabelecer uma associação de aplicação e colocar o protocolo no estado DATA_READY. A primitiva tem de ser invocada tanto pelas aplicações locais como remotas.

A.4.3.3. Em primeiro lugar, é necessário estabelecer uma ligação de transporte subjacente, no seguimento dos procedimentos da primitiva T-ligação descritos no parágrafo B.4.1 do Anexo B, após o que o protocolo entra no estado READY. Nesta fase apenas podem ser transferidas mensagens de Sistema (e possivelmente, por acordo bilateral, mensagens de Operador). Para transferir uma mensagem de Operador ou de Sistema, o emissor utiliza a primitiva T-Dados (ver B.4.4), com a mensagem a servir de parâmetro.

A.4.3.4. Será então transmitida uma mensagem STARTUP (mensagem de sistema), iniciar-se-á o temporizador Tr (ver A.4.7) e o protocolo entra no estado ASSOCIATION_PENDING. Se o temporizador Tr expirar enquanto o protocolo se encontra ainda neste estado, a mensagem STARTUP será retransmitida e o temporizador será reinicializado.NOTA

O protocolo manter-se-á no estado ASSOCIATION_PENDING até ser recebida uma mensagem STARTUP. A contínua expiração do tempo do temporizador Tr pode ser sinalizada localmente.

A.4.3.5. A recepção da mensagem STARTUP causará as seguintes acções:

- no estado ASSOCIATION_PENDING, é transmitida uma nova mensagem STARTUP, o protocolo entra no estado DATA_READY e é sinalizada a primitiva MT-Indicação-de-Associação;

- em qualquer outro estado, a mensagem é ignorada.

A.4.3.6. A recepção da mensagem STARTUP no estado ASSOCIATION_PENDING corresponde a uma das seguintes situações:

- a aplicação remota emitiu uma primitiva MT-Pedido-de-Associação e o seu protocolo de Transferência de Mensagens entrou no estado ASSOCIATION_PENDING, ou

- o protocolo de Transferência de Mensagens remoto está a responder a uma mensagem STARTUP previamente recebida e entrou no estado DATA_READY.

NOTA

Esta incerteza deve-se à utilização da mesma mensagem para o STARTUP e para a resposta ao STARTUP. Em resultado disso, o protocolo de Transferência de Mensagens que foi o primeiro a entrar no estado DATA_READY irá receber uma nova mensagem STARTUP. Conforme especificado em A.4.3.5, esta mensagem STARTUP é ignorada.

A.4.3.7. Uma vez trocadas as mensagens STARTUP, estabelece-se a associação e podem ser transferidos todos os tipos de mensagens identificados (estado DATA_READY).

A.4.4. Transferência de dados

Os outros tipos de mensagens são transferidas da mesma forma que as mensagens de Sistema, utilizando o serviço T-Dados, com a mensagem a servir de parâmetro. Isto corresponde às primitivas de serviço MT-Pedido-de-Dados e MT-Indicação-de-Dados. NOTA

Cada mensagem é enviada como uma TSDU única: não há concatenação ou segmentação de mensagens a este nível.

A.4.5. Libertação Ordenada da Associação

A.4.5.1. A associação de Transferência de Mensagens entre duas aplicações pode ser cancelada por qualquer uma delas. Isto corresponde à primitiva de serviço MT-Pedido-de-Cancelamento.

A.4.5.2. Serão tomadas as seguintes acções:

- no estado DATA_READY, será transmitida uma mensagem SHUTDOWN (mensagem de sistema), os temporizadores Tr e Ts serão parados e será libertada a ligação de transporte;

- no estado ASSOCIATION_PENDING, será transmitida uma mensagem SHUTDOWN (mensagem de sistema), o temporizador Tr será parado e a ligação de transporte será libertada;

- no estado READY, a ligação de transporte será libertada;

- em outras situações, não será tomada qualquer acção.

NOTA

A mensagem SHUTDOWN não é um alerta antecipado - a associação termina imediatamente. Não há confirmação desta mensagem pela outra parte.

A.4.5.3. A recepção de uma mensagem SHUTDOWN causará as seguintes acções:

- no estado DATA_READY, o temporizador Ts (ver A.4.7) será parado, é sinalizada a MT-Indicação-de-Cancelamento e o interface entra no estado ASSOCIATION_PENDING sem enviar uma mensagem STARTUP;

- em qualquer outro estado, não é tomada qualquer acção.

A.4.6. Restabelecimento da Associação

A aplicação que iniciou o cancelamento da associação tem a responsabilidade, quando estiver pronta, de restabelecer a associação das aplicações e de quaisquer níveis inferiores (se necessário).NOTA

Se o cancelamento da associação resultou na libertação da ligação de rede subjacente, tem de cumprir-se o procedimento de estabelecimento de associação especificado no parágrafo A.4.3.

A.4.7. Integridade da Associação

A.4.7.1. A integridade da associação entre duas aplicações é dada pela inactividade da funcionalidade de batida cardíaca.

A.4.7.2. Ao entrar no estado DATA_READY e ao transmitir qualquer tipo de mensagem na ligação de transporte, será (re)iniciado um temporizador configurável Ts. Se o temporizador Ts expirar o tempo no estado DATA_READY, será transmitida uma mensagem HEARTBEAT (Mensagem de sistema) (e será reiniciado o temporizador).

A.4.7.3. Da mesma forma, ao entrar no estado DATA_READY e ao receber qualquer mensagem na ligação, com excepção de uma mensagem STARTUP, será (re)iniciado um temporizador configurável Tr. Se o temporizador Tr expirar o tempo no estado DATA_READY, será sinalizada a MT-Indicação-de-Cancelamento, parar-se-á a transmissão de todas as mensagens, parar-se-á o temporizador Ts e iniciar-se-á o temporizador Tr. O interface encontra-se no estado ASSOCIATION_PENDING.NOTA

As aplicações irão recuperar e voltar a sincronizar através da troca de mensagens STARTUP (ver A.4.3).

A.4.8. Libertação Desordenada da Associação

A.4.8.1. Poderá existir uma libertação anormal da associação se:

- a ligação de transporte falha (por exemplo, falha da linha, erro do protocolo)

- uma das duas aplicações ou sistemas falhar (o que se pode ficar a dever a uma falha do hardware ou do software; em alguns casos, a ligação de transporte subjacente pode continuar a funcionar.

NOTA

No seguimento da definição do protocolo de transporte no Anexo B, não existe ligação de transporte de extremo-a-extremo. Em resultado disso, a falha da ligação de transporte é um resultado directo da falha da ligação de rede.

A.4.8.2. Uma falha da aplicação ou do sistema pode ser detectada pelo expirar do tempo para a recepção de uma mensagem HEARTBEAT esperada (ver A.4.7), proveniente desta aplicação.

A.4.9. Recuperação de uma Falha

A.4.9.1. Têm de ser considerados dois casos:

- após uma falha da ligação de transporte;

- após a falha de uma aplicação.

A.4.9.2. Em ambos os casos, o restabelecimento envolve o procedimento de estabelecimento de associação normal (ver A.4.3), incluindo a troca de mensagens STARTUP.NOTA

No caso de uma falha ao nível aplicacional que não cause a libertação da ligação subjacente, o sistema que falhou pode transmitir uma mensagem SHUTDOWN (ou seja, L_shutdown invocado manualmente ou como parte da lógica da aplicação) antes de tentar restabelecer a ligação. Isto irá cortar a expiração do tempo Tr da aplicação remota e pode resultar numa recuperação mais rápida com menos probabilidades de perda de dados.

A.4.10. Formatos das Mensagens

A.4.10.1. Estrutura Geral das Mensagens

>POSIÇÃO NUMA TABELA>

A.4.10.2. Comprimento do Corpo da Mensagem

Serão suportados comprimentos até 4096 octetos (inclusive) para o corpo das mensagens.

A.4.10.3. Formatos das Mensagens de Sistema

>POSIÇÃO NUMA TABELA>

A.4.10.4. Outros Formatos de Mensagens

>POSIÇÃO NUMA TABELA>

NOTAS

1. O formato do corpo das mensagens de estado ultrapassa o âmbito do presente Documento Normativo do Eurocontrol.

2. O formato das mensagens Operacionais está especificado nas Normas e Documentos do Eurocontrol que definem aplicações de mensagens tais como o Intercâmbio de Informação em Tempo Real [Referência 13].

3. As mensagens de Operador consistem de texto ASCII que pode ser impresso. Se estas mensagens forem suportadas, tem de ser fornecido um interface de utilizador para a visualização das mensagens recebidas e para permitir a composição de mensagens para transmissão.

A.5. Tabelas de Transição dos Estados do Protocolo

A.5.1. Introdução

A tabela de estados abaixo constitui a especificação definitiva do protocolo. Em caso de discrepância com o texto principal acima, prevalece a especificação abaixo.NOTA

A notação utilizada para descrever os estados, eventos, temporizadores e acções baseia-se no ICD-ST. No entanto, as seguintes definições, bem como as acções resultantes, foram objecto de revisão e podem diferir do ICD-ST.

A.5.2. Definições dos estados

Tabela 1

Definições dos Estados

>POSIÇÃO NUMA TABELA>

A.5.3. Eventos Possíveis

Tabela 2

Eventos Possíveis

>POSIÇÃO NUMA TABELA>

A.5.4. Temporizadores

Tabela 3

Temporizadores

>POSIÇÃO NUMA TABELA>

O valor destes temporizadores será de forma a que Tr = 2Ts + tempo de trânsitoNOTA

Os valores típicos destes temporizadores são: Ts = 30s, Tr = 70s.

A.5.5. Tabela de Transição de Estados

Tabela 4

Transições de estados

>POSIÇÃO NUMA TABELA>

A.5.6. Diagrama de Transição dos Estados

NOTA

O protocolo encontra-se descrito na Figura A.1 na forma de um diagrama de transição de estados. O diagrama é apenas informativo: em caso de conflito entre o diagrama e a tabela de estados acima, esta última terá precedência.

Figura A.1

Protocolo de Transferência de Mensagens: Diagrama de Transição de Estados

>PIC FILE= "L_2000254PT.019301.EPS">

ANEXO B (Normativo)

PROTOCOLO DO CABEÇALHO DAS MENSAGENS

B.1. Introdução

O presente Anexo define o protocolo do Cabeçalho das Mensagens, um protocolo de transporte mínimo a ser utilizado em aplicações tais como a OLDI.

B.2. Serviço Implementado

B.2.1. O protocolo do Cabeçalho das Mensagens corresponde a um subconjunto do Serviço de transporte em modo Ligação, tal como definido na ISO/IEC 8072 [Referência 11], abrangendo as seguintes primitivas de serviço.

T-Ligação: estabelece uma ligação de transporte para uma aplicação

T-Dados: transfere dados ASCII

T-Desligar: termina a ligação de transporte de uma aplicação

B.2.2. O serviço não suporta a multiplexagem, recuperação de erros ou a segmentação e o reagrupamento.

B.3. Serviço Assumido

O protocolo assume um serviço de rede básico fiável, tal como o proporcionado pelo Protocolo da Camada de Pacotes X.25. NOTA

Só é suportada uma única ligação de transporte em cada ligação de rede.

B.4. Especificação do Protocolo

B.4.1. Estabelecimento da Ligação

A primitiva T-ligação será implementada através da utilização do serviço N-Ligação do serviço de rede subjacente. Existe uma relação directa entre a estrutura dos dois conjuntos de primitivas (pedido, indicação). Em alternativa, pode ser utilizada uma ligação de rede existente (por exemplo, uma estabelecida pelos mecanismos de gestão do sistema).Recomendações

1. No último caso acima indicado, a ligação de rede deveria ser restabelecida antes da sua utilização. A primitiva N-Ligação pode ser novamente emitida, de forma automática, se não for obtida resposta dentro de um determinado intervalo de tempo.

2. Se for implementada esta nova tentativa automática, esta deveria ser efectuada de 15 em 15 segundos, aproximadamente.

B.4.2. Evitação de Ligações de Rede Redundantes

Se uma primitiva N-Pedido-de-Ligação estiver pendente (ou seja, não foi sinalizada nenhuma primitiva N-Confirmação-de-Ligação ou N-Desligar correspondente) e for sinalizada uma primitiva N-Indicação-de-Ligação, então a tentativa de estabelecimento de rede de entrada só deve ser rejeitada ou anulada através da resposta com uma primitiva N-Pedido-de-Desligar, quando se aplicarem ambas as condições seguintes:

- endereço NSAP chamador da N-Indicação-de-Ligação, é o mesmo que o endereço NSAP chamado do N-Pedido-de-Ligação pendente;

- endereço NSAP chamador do N-Pedido-de-Ligação, é superior ao endereço NSAP chamado do N-Pedido-de-Ligação pendente, sendo efectuada a comparação das cadeias de bits formadas pela codificação binária preferencial de cada endereço NSAP, tal como definida no Anexo A da ISO/IEC 8348 [Referência 10] (uma cadeia será considerada maior do que qualquer das suas subcadeias iniciais características, por exemplo '8800'H >'88'H).

B.4.3. Libertação da Ligação

B.4.3.1. A libertação da ligação utilizará as primitivas de serviço N-Desligar e N-Restabelecimento do serviço de rede subjacente.

B.4.3.2. Para a implementação de uma T-Pedido-de-Desligar, será sinalizada uma N-Pedido-de-Desligar. Em alternativa, se não for suportado o estabelecimento de ligações de rede que utilizam as primitivas N-Ligação, a ligação de rede não será libertada de forma explícita.Recomendação

Neste último caso, a ligação de rede deveria ser restabelecida.

B.4.3.3. Deverá ser sinalizada uma T-Indicação-de-Desligar aquando da recepção de qualquer uma das seguintes primitivas de serviço de rede numa ligação de rede correspondendo a uma ligação de transporte total ou parcialmente estabelecida:

- N-Indicação-de-Desligar;

- N-Indicação-de-Restabelecimento.

B.4.4. Transferência de Dados

B.4.4.1. A primitiva T-Dados será implementada pela utilização da primitiva N-Dados do serviço de rede subjacente. Existe uma relação directa entre a estrutura dos dois conjuntos de primitivas (pedido, indicação). Esta relação utiliza uma Unidade de Dados do Protocolo de Transporte (TPDU) que é transferida pelo serviço de rede.

B.4.4.2.

>POSIÇÃO NUMA TABELA>

NOTAS

1. Este cabeçalho é definido de forma a ser idêntico ao utilizado no procedimento INTERCAUTRA definido para o intercâmbio de mensagens ACT entre o CAUTRA de Paris, o sistema 9020D do Centro de Controlo de Tráfego Aéreo de Londres e o Sistema Terminal de Comunicações Digitais (DCTS) de Maastricht/Karlsruhe, quando transporta os formatos de mensagens definidos no Anexo A; neste caso, o campo "dados(1)" corresponde ao campo TYP.

2. A utilização dos campos ADEST, DEST, AEMM, EMM, e ADR com valores diferentes de '40'H está fora do âmbito do presente Documento Normativo do Eurocontrol, podendo, no entanto, ser objecto de acordo bilateral.

B.4.4.3. O serviço T-Dados restringir-se-á à transferência de dados em caracteres ASCII passíveis de serem impressos. Em particular, nenhum dos octetos de dados deverá ter o valor '03'H (o caracter ETX).

B.4.4.4. Uma implementação conforme deverá satisfazer o requisito de suportar Unidades de Dados do Serviço de Rede (NSDU) com tamanhos até 4105 octetos, inclusive.

B.4.4.5. Uma implementação conforme deverá proibir a concatenação de TSDU múltiplas numa NSDU simples.

B.4.4.6. Uma implementação conforme deverá proibir a segmentação de uma TSDU simples em NSDU múltiplas.

ANEXO C (Normativo)

PROTOCOLO DE REDE

C.1. Introdução

O presente Anexo especifica um Protocolo de Rede básico que utiliza o protocolo da camada de pacotes X.25, para utilização tanto em ambientes de redes ponto-a-ponto como de comutação de pacotes, para suportar a transferência de informação de voo. O subconjunto do protocolo é compatível com o definido nas versões da [Referência 1] a partir da edição de 1980.

C.2. Serviço Prestado

C.2.1. O protocolo implementa o modo Ligação do Serviço de Rede OSI tal como definido na ISO/IEC 8348 [Referência 10], com as seguintes excepções.

- os endereços NSAP são restringidos à forma definida em C.4.2;

- não existe a possibilidade para estabelecer um acordo entre os utilizadores do Serviço de Rede (NS) e o prestador de NS quanto à qualidade do serviço associado a uma ligação de rede;

- não é suportada a transferência de NS-Dados-de-Utilizador durante o estabelecimento e libertação da ligação de rede, exceptuando-se as disposições descritas em C.5.3.

C.2.2. Não são oferecidas as seguintes opções do prestador de NS:

- Confirmação da Recepção;

- Transferência Expedita de Dados

C.3. Serviço Assumido

O protocolo assume a existência de um Serviço de Ligação de Dados OSI, tal como o oferecido pela ISO/IEC 7776 (LAPB) [Referência 6].

C.4. Endereçamento NSAP

C.4.1. Introdução

C.4.1.1. A estrutura dos endereços NSAP segue a definida no Anexo A da ISO/IEC 8348 [Referência 10], como se ilustra abaixo.

>PIC FILE= "L_2000254PT.019702.EPS">

C.4.1.2. Os componentes dos endereços NSAP são definidos abaixo:

IDP: Parte Inicial do Domínio, compreendendo os campos AFI e IDI

AFI: Identificador da Autoridade e do Formato, e

IDI: Identificador Inicial do Domínio

DSP: Parte Específica do Domínio

C.4.2. Estrutura dos Endereços NSAP

C.4.2.1. Para os efeitos do presente Documento Normativo do Eurocontrol, os componentes dos endereços limitar-se-ão à seguinte forma.

C.4.2.2. Será utilizado o AFI com valor 48, indicando um IDI de formato Local com sintaxe decimal abstracta.

C.4.2.3. O IDI é nulo, seguindo o formato Local.

C.4.2.4. O DSP consistirá de 2 pares de dígitos decimais, da seguinte forma:

- o primeiro par é um identificador da unidade de Controlo de Tráfego Aéreo (ATC), que identifica o sistema ATC e assim, indirectamente, uma localização;

- o segundo par é um selector da unidade ATC, que pode ser utilizado para identificar um ponto terminal particular numa unidade ATC.

C.4.2.5.

>POSIÇÃO NUMA TABELA>

C.4.3. Atribuição de Selectores e Identificadores das Unidades ATC

C.4.3.1. A atribuição de identificadores únicos de unidade ATC a cada sistema ATC será da responsabilidade do Eurocontrol, enquanto que os selectores de unidade ATC serão atribuídos pela autoridade pertinente pertencente à Organização ou Administração ATC.

C.4.3.2. À data da preparação da presente Norma, a atribuição de identificadores de unidade ATC é a que se mostra no Anexo G.

C.5. Especificação do Protocolo

C.5.1. Generalidades

O protocolo baseia-se no Protocolo de Convergência Dependente da Sub-rede para o X.25 (1980) definido no Anexo A da ISO/IEC 8878 [Referência 12], com as seguintes diferenças:

- a funcionalidade de Selecção Rápida pelo utilizador não é utilizada; no entanto, a codificação definida no Anexo A da ISO/IEC 8878 [Referência 12] para utilização com o formato alargado do campo de Dados de Utilizador, disponível com a funcionalidade Selecção Rápida, é aqui utilizada com o formato básico do campo Dados de Utilizador nos pacotes CALL REQUEST e INCOMING CALL, uma vez que as restrições aos parâmetros permitidos no serviço de rede garantem que a informação codificada cabe em 16 octetos;

- dos parâmetros do serviço de rede para os quais se definem codificações na ISO/IEC 8878 [Referência 12], só os endereços NSAP chamados e chamadores (e apenas na forma definida em C.4.2) são enviados no pacote CALL REQUEST;

- o campo Dados de Utilizador não é utilizado nos pacotes CALL ACCEPTED, CALL CONECTED, CLEAR REQUEST ou CLEAR INDICATION;

- os procedimentos alternativos para o estabelecimento e libertação da ligação de rede não são utilizados;

- não é suportada a confirmação de recepção utilizando o bit-D.

NOTA

As primeiras três destas restrições garantem que toda a informação que será transmitida entre dois DTE, respeitará as limitações do campo Dados de Utilizador no PLP X.25 (1980).

C.5.2. Codificação dos Endereços

Os endereços NSAP chamados e chamadores serão codificados utilizando a codificação binária preferencial definida no Anexo A da ISO/IEC 8348 [Referência 10].

C.5.3. Codificação do Campo Dados de Utilizador

C.5.3.1. Em resultado dos requisitos acima mencionados, o campo Dados de Utilizador nos pacotes PEDIDO DE CHAMADA e CHAMADA DE ENTRADA será codificado tal como ilustrado abaixo. Serão transmitidos todos os 16 octetos.

Tabela 1

Codificação do Campo Dados de Utilizador

>POSIÇÃO NUMA TABELA>

C.5.3.2. Não serão utilizados os outros parâmetros descritos na ISO/IEC 8878 [Referência 12].

C.5.4. Tratamento dos Endereços nos Pacotes INCOMING CALL

C.5.4.1. Endereços DTE

O endereço DTE chamador num pacote INCOMING CALL será validado por comparação com uma lista local de endereços DTE remotos válidos para o sistema. Se for detectado um endereço inválido, a chamada será cancelada.

NOTAS

1. O endereço DTE chamado, se existir, num pacote INCOMING CALL, se existir, pode ser opcionalmente validado por comparação com uma lista (tipicamente de um item) de endereços DTE locais válidos para o sistema.

2. Em alguns casos, o endereço DTE de uma unidade pode diferir em valor e/ou comprimento, conforme a unidade actua como sistema chamado ou chamador. Desta forma, tem de ser dada particular atenção a este assunto na especificação ou implementação da funcionalidade de validação de endereços DTE.

C.5.4.2. Endereços NSAP

O endereço NSAP chamador, codificado da forma acima descrita, num pacote INCOMING CALL, será validado por comparação com uma lista local de endereços NSAP remotos válidos para o sistema. Se for detectado um endereço inválido, a chamada será cancelada.

NOTA

O endereço NSAP chamado pode opcionalmente ser validado por comparação com uma lista de (tipicamente de um item) endereços NSAP locais válidos para o sistema.

C.5.5. Transferência de Dados

C.5.5.1. Tal como descrito no Anexo A.5.3 da ISO/IEC 8878 [Referência 12], os NSDU são transferidos no campo Dados de Utilizador de um pacote DATA.

NOTA

Consequentemente, é proibido transmitir mais do que uma mensagem de utilizador, tal como uma mensagem OLDI, por cada pacote X.25 ou sequência de bits M.

C.5.5.2. As NSDU mais compridas do que o máximo permitido para Dados de Utilizador para o circuito virtual, serão segmentadas e transmitidas nos campos Dados de Utilizador de uma sequência de pacotes DATA, em que todos, à excepção do último, deverão ter o comprimento máximo e o conjunto de bits M (ou seja, uma Sequência de mais bits)

C.5.5.3. Na recepção, os campos Dados de Utilizador de uma Sequência de mais bits serão reagrupados de forma a constituir a NSDU recebida.

ANEXO D (Normativo)

PRÓ-FORMAS PICS ESPECÍFICOS DO PERFIL

D.1. Introdução

D.1.1. O fornecedor da implementação de um protocolo que afirma estar em conformidade com as especificações dos Anexos A-C deverá preencher os seguintes pró-formas PICS. NOTA

Libertação dos direitos de autor relativos aos pró-formas PICS: os utilizadores do presente Documento Normativo do Eurocontrol podem reproduzir livremente os pró-formas PICS do presente Anexo, para que possam ser utilizados para os fins previstos, podendo ainda publicar os PICS preenchidos.

D.1.2. Um pró-forma PICS preenchido é o PICS para a implementação em causa. O PICS é uma declaração das capacidades e opções do protocolo que foram implementadas.

D.1.3. Os PICS podem ter várias utilizações, incluindo a utilização:

- pelo implementador do protocolo, como uma lista de verificação para reduzir o risco de não conformidade com o protocolo devido a um lapso;

- pelo fornecedor ou comprador, ou comprador potencial, da implementação, como uma indicação detalhada das capacidades da implementação, estabelecidas relativamente à base comum de entendimento fornecida pelo pró-forma PICS normalizado;

- pelo utilizador ou utilizador potencial da implementação, como uma base para a verificação inicial da possibilidade de interoperação com outra implementação (note-se que, enquanto a interoperação não pode nunca ser garantida, a falha da interoperação pode frequentemente ser prevista a partir de PICS incompatíveis);

- por um ensaiador do protocolo, como a base para a selecção dos ensaios apropriados com os quais será avaliada a pretensão da declaração de conformidade da implementação.

D.2. Instruções para o Preenchimento dos Pró-formas PICS

D.2.1. Estrutura Geral dos Pró-formas PICS

D.2.1.1. A Identificação da Implementação e o Sumário do Protocolo constitui a primeira parte de cada pró-forma PICS e será preenchida como indicado, com a informação necessária para identificar plenamente tanto o fornecedor como a própria implementação.

D.2.1.2. A parte principal do pró-forma PICS é um questionário de formato fixo. As respostas aos itens do questionário serão dadas na coluna mais à direita, seja assinalando uma resposta para indicar uma escolha restrita (normalmente, Sim ou Não) ou indicando um valor ou um conjunto ou um intervalo de valores.NOTAS

1. Cada item é identificado por uma referência única de item na primeira coluna; a segunda coluna contém a questão a responder; a terceira coluna contém a referência ou as referências ao material que especifica o item na presente Norma do Eurocontrol. As restantes colunas registam a situação do item (se o seu suporte é obrigatório, opcional, proibido ou condicional) e fornece espaço para as respostas: ver também D.2.4 abaixo.

2. Um fornecedor pode também apresentar, ou ser solicitado a apresentar, informação adicional categorizada como Informação Adicional ou Informação de Excepção. Quando presente, cada tipo de informação adicional deve ser apresentado numa subcláusula adicional com itens identificados por A< i > ou X< i > respectivamente, para efeitos de referência cruzada, em que < i > é uma identificação inequívoca do item (por exemplo, um numeral): não existem outras restrições quanto ao seu formato e apresentação.

D.2.1.3. Um pró-forma PICS preenchido, incluindo qualquer Informação Adicional ou Informação de Excepção, será referido como a Declaração de Conformidade da Implementação do Protocolo para o protocolo em questão. NOTA

Quando uma implementação puder ser configurada em mais de uma maneira, um único PICS pode ser capaz de descrever todas essas configurações. No entanto, o fornecedor pode escolher apresentar mais do que um PICS, cada um abrangendo um dado subconjunto das capacidades de configuração da implementação, se assim tornar mais fácil e clara a apresentação da informação.

D.2.2. Informação Adicional

Os itens da Informação Adicional permitem ao fornecedor apresentar informação adicional para auxiliar na interpretação do PICS.NOTAS

1. Não se pretende nem se espera que seja fornecida uma grande quantidade (de informação adicional), podendo um PICS ser considerado completo sem nenhuma dessa informação. Como exemplo, pode-se indicar em linhas gerais as formas pelas quais pode ser estabelecida uma (única) implementação para operar numa variedade de ambientes e de configurações; ou uma breve fundamentação (baseada talvez nas necessidades específicas da aplicação) para excluir características que, apesar de opcionais, estão mesmo assim normalmente presentes nas implementações deste protocolo.

2. As referências aos itens da Informação Adicional podem ser apresentadas junto de qualquer resposta ao questionário, e podem ser incluídas nos itens da Informação de Excepção.

D.2.3. Informação de Excepção

D.2.3.1. Por vezes, pode suceder que um fornecedor deseje responder a um item com situação obrigatória ou proibida (após a aplicação de quaisquer condições), de forma a entrar em conflito com o requisito indicado. Na coluna Suporte não será encontrada qualquer resposta pré-impressa para esta situação: como alternativa, o fornecedor escreverá a resposta em falta na coluna Suporte, juntamente com uma referência X< i > a um item da Informação de Excepção.

D.2.3.2. O fornecedor deverá apresentar a fundamentação apropriada no próprio item de Excepção.

D.2.3.3. Uma implementação para a qual seja necessário um item de Excepção da forma referida, não está em conformidade com a presente especificação.NOTA

Uma possível razão para a situação acima descrita poderá ser uma falha na norma que já foi comunicada, esperando-se uma correcção para a alteração do requisito não cumprido pela implementação.

D.2.4. Itens Condicionais

D.2.4.1. Os itens condicionais individuais são indicados por um símbolo condicional na forma "< item >": "< s >" na coluna Situação, em que "< item >" é uma referência ao item que surge na primeira coluna da tabela para um outro item, e "< s >" é um símbolo de situação M, O, O. < n > ou X.NOTA

Um pró-forma PICS pode conter vários itens condicionais. Estes são itens para os quais tanto a aplicabilidade do item em si como a sua situação, se não se aplicar (obrigatório, opcional ou proibido), dependem do facto de certos outros itens serem suportados ou não.

D.2.4.2. Se o item referenciado pelo símbolo condicional for assinalado como sendo suportado, o item condicional é aplicável, e a sua situação é dada por "< s >": a coluna suporte deve ser preenchida da forma habitual. Caso contrário, o item condicional não é relevante e deverá ser assinalada a resposta Não Aplicável (NA).

D.2.4.3. Cada item, cuja referência é utilizada num símbolo condicional, é indicado por um asterisco na coluna Item.

D.3. Pró-forma PICS para o Protocolo de Transferência de Mensagens

D.3.1. Abreviaturas e Símbolos Especiais

D.3.1.1. Símbolos de Situação

M: Obrigatório

O: Opcional

D.3.1.2. Referências dos Itens

Os itens no pró-forma PICS são identificados por referências mnemónicas. Os itens PICS que tratam de funções relacionadas são identificados por referências que partilham a mesma letra ou par de letras iniciais (em maiúsculas). Segue-se uma lista dessas iniciais, pela ordem em que os grupos de itens aparecem no pró-forma PICS.

>POSIÇÃO NUMA TABELA>

D.3.2. Identificação

>PIC FILE= "L_2000254PT.020301.EPS">

D.3.3. Implementação do Protocolo

>PIC FILE= "L_2000254PT.020401.EPS">

D.4. Pró-forma PICS para o Protocolo do Cabeçalho das Mensagens

D.4.1. Abreviaturas e Símbolos Especiais

D.4.1.1. Símbolos de Situação

M obrigatório

O opcional

O.< n > opcional, mas é necessário o suporte de pelo menos um grupo de opções identificado pelo mesmo numeral < n >

X proibido

< item >: símbolo de item condicional, dependente do suporte assinalado no < item > (ver D.2.4)

D.4.1.2. Abreviaturas

NA não aplicável

D.4.1.3. Referências dos Itens

>POSIÇÃO NUMA TABELA>

D.4.2. Identificação

>PIC FILE= "L_2000254PT.020501.EPS">

D.4.3. Implementação do Protocolo

>PIC FILE= "L_2000254PT.020601.EPS">

D.5. Pró-forma PICS para o Protocolo de Rede

D.5.1. Abreviaturas e Símbolos Especiais

D.5.1.1. Símbolos de Situação

M obrigatório

O opcional

D.5.1.2. Referências dos Itens

>POSIÇÃO NUMA TABELA>

D.5.2. Identificação

>PIC FILE= "L_2000254PT.020701.EPS">

D.5.3. Implementação do Protocolo

>PIC FILE= "L_2000254PT.020702.EPS">

ANEXO E (Normativo)

LISTA DE REQUISITOS DO PERFIL

E.1. Introdução

E.1.1. O presente Anexo estabelece a PRL para o perfil ICD FDE definido no presente Documento Normativo do Eurocontrol. A Declaração de Conformidade da Implementação para uma implementação que pretenda ser declarada em conformidade com este perfil, será gerada de acordo com as instruções fornecidas abaixo.NOTA

Os pró-formas do presente Anexo baseiam-se nos pró-formas que acompanham as normas base de referência.

E.1.2. Uma implementação conforme deverá satisfazer os requisitos de conformidade obrigatórios das normas base referenciados neste perfil.

E.2. A função dos Pró-formas PRL e PICS

A presente secção (E.2) é informativa, não sendo uma disposição desta Parte da presente Norma do Eurocontrol.

- A apresentação dos requisitos de conformidade na forma tabular dos pró-formas PRL e PICS visa fornecer uma lista de verificação das características que têm de ser ou podem ser implementadas. Os conceitos subjacentes são definidos e descritos na ISO/IEC 9646-1 [Referência 14] (a Recomendação X.290 da ITU-T é equivalente) e na ISO/IEC TR10000-1 [Referência 2].

- Um perfil combina e selecciona as opções de diversas normas base de forma a executar uma função específica de processamento da informação. Cada norma base possui um pró-forma PICS que lista os requisitos da norma. A PRL é composta do subconjunto dos itens do pró-forma PICS da norma base que são restringidos pelo perfil, bem como dos requisitos específicos do perfil. Define as respostas requeridas pelos pró-formas PICS da norma base para a conformidade com o perfil. Além disso, a PRL irá conter os itens de tipo PICS que são específicos do perfil (pelo menos, haverá um item que verifica se todos os pró-formas PICS foram preenchidos correctamente); estes itens devem ser completados juntamente com os pró-formas PICS da norma base. Os pró-formas preenchidos constituem, em conjunto, a Declaração de Conformidade da Implementação do perfil (ICS).

- Seguindo a metodologia da ISO/IEC TR 10000-1 [Referência 2], a pretensão da declaração de conformidade com um perfil tem de ser suportada por pró-formas PICS preenchidos de acordo com a PRL. A utilização deste material dependerá da abordagem seguida pelo processo de aquisição da implementação de um ICD FDE.

- É possível imaginar várias abordagens para a implementação de um FDE:

- Implementação interna por uma Administração ou Organização Nacional: a PRL deve ser utilizada como base para a especificação dos requisitos e para a especificação dos ensaios de aceitação da implementação; a ICS preenchida deve ser produzida como parte do procedimento de aceitação.

- Implementação do perfil por um adjudicatário: o material será utilizado e produzido tal como para uma implementação interna, mas o adjudicatário deve fornecer a ICS e esta necessidade tem de ser um requisito contratual.

- Implementação do perfil por um adjudicatário como parte de um contrato chave-na-mão ou de integração de sistemas: o material será utilizado e produzido tal como para uma implementação interna, mas o adjudicatário terá de fazê-lo internamente, fornecendo também a ICS preenchida. A conformidade com o perfil garante, por exemplo, que um fornecedor que trabalhe para duas administrações não possa introduzir os seus protocolos proprietários com vista a satisfazer o requisito FDE e, assim, ajudar a ceder controlo às administrações contratantes.

- Integração de produtos disponíveis no mercado na implementação de um perfil, em qualquer dos casos precedentes: o fornecedor de um produto deve fornecer os pró-formas PICS relativos ao produto, preenchidos em conformidade com a PRL aqui descrita, e garantir a conformidade do produto com os requisitos aplicáveis ao perfil; este PICS pode ser depois enviado como parte do perfil ICS.

- No seguimento da implementação, a ICS deve ser mantida como parte da documentação da implementação, podendo ser utilizada para prever a interoperabilidade com outras administrações e identificar as alterações que possam ser necessárias para passar a outros protocolos.

E.3. Notação

E.3.1. Na PRL, são usadas as seguintes notações da ISO/IEC 10000-1 [Referência 2] para indicar a situação das características:

m: obrigatório

o: opcional

-: não aplicável (ou seja, logicamente impossível no âmbito do perfil)

x: excluído

NOTAS

1. Podem ser utilizadas combinações de dois caracteres, em que a primeira letra assinala a situação estática (implementação) e a segunda à dinâmica (utilização); assim, por exemplo, "mo" significa "implementação obrigatória, utilização opcional".

2. A notação "o.< n >" é utilizada para indicar um conjunto de opções seleccionáveis (ou seja, deve ser implementado pelo menos um elemento do conjunto) com o mesmo identificador n.

3. Uma característica assinalada com "x" pode, não obstante, ser parte de uma implementação, desde que não seja utilizada quando a implementação opera em conformidade com o perfil.

4. A utilização de características assinaladas com "x" requer acordo bilateral. Neste caso, a situação das características deve ser revista, dado que podem interessar a outras implementações.

E.3.2. É utilizada seguinte notação de atributos:

< atributo >:: introduz um grupo de itens, todos condicionais no < atributo > (a extensão do grupo é indicada pela configuração).

< atributo >: introduz um único item que é condicional no < atributo >.

NOTA

Em ambos os casos, o atributo pode ser o identificador de uma característica do perfil, ou uma combinação booleana de atributos ("¬" é o símbolo da negação lógica).

E.3.3. Os requisitos da norma base são indicados utilizando as notações equivalentes em maiúsculas (ou seja, M, O, O. < n >, X).

E.4. Instruções para o Preenchimento dos Pró-formas PICS

E.4.1. Para fornecer o perfil ICS, é necessário preencher os pró-formas PICS para as normas base de referência, juntamente com os itens PICS adicionais relativos ao perfil estabelecidos no presente Anexo.

E.4.2. Sempre que este perfil aperfeiçoar as características das normas base, aplicar-se-ão os requisitos expressos nesta PRL (conforme indicado nos itens PRL com uma coluna "Características do Perfil") para limitar as respostas permitidas nos pró-formas PICS da norma base.

E.4.3. Sempre que este perfil estabelecer requisitos adicionais, deverá ser preenchida a coluna de resposta para esses itens. Nesta coluna, cada resposta será, ou seleccionada de entre o conjunto de respostas indicado, ou incluirá um valor ou valores de parâmetro ou uma gama de valores, conforme for necessário.

E.4.4. Se um requisito obrigatório não for satisfeito, terá de ser fornecida informação de excepção, através da introdução de uma referência X< i >, sendo < i > um identificador único, a uma fundamentação apensa para a não-conformidade.NOTA

Uma razão possível para este tipo de excepção é a conformidade com um relatório de defeitos pendente relativo a uma disposição do perfil; se o relatório de defeitos for aceite, a implementação será então conforme.

E.5. Referências

E.5.1. Este perfil faz referência às seguintes especificações de protocolos:

- Protocolo de Transferência de Mensagens (Anexo A ao presente Documento Normativo do Eurocontrol);

- Protocolo do Cabeçalho das Mensagens (Anexo B ao presente Documento Normativo do Eurocontrol);

- Protocolo de Rede em Modo Ligação, utilizando a ISO/IEC 8208 (Anexo C ao presente Documento Normativo do Eurocontrol);

- ISO/IEC 7776 [Referência 6];

- Normas da Camada Física referidas pela cláusula 1 da Recomendação X.25 da ITU-T (1993) [Referência 1].

E.5.2. Em virtude de não existirem pró-formas PICS explícitos para as Normas da Camada Física pertinentes, serão utilizados os pró-formas PICS provisórios da camada física, estabelecidos na cláusula A.4 da ISO/IEC ISP 10609-9 [Referência 8].

E.6. Declaração de Conformidade

E.6.1. Generalidades sobre a Conformidade

>PIC FILE= "L_2000254PT.021101.EPS">

E.6.2. Requisitos Dinâmicos de Conformidade

>PIC FILE= "L_2000254PT.021201.EPS">

E.7. Requisitos da Camada Superior

Tabela 3

Protocolo de Transferência de Mensagens

>POSIÇÃO NUMA TABELA>

E.8. Requisitos da Camada Inferior

E.8.1. Requisitos da Camada de Transporte

Tabela 4

Protocolo do Cabeçalho das Mensagens

>POSIÇÃO NUMA TABELA>

E.8.2. Requisitos da Camada de Rede

As PRL dadas nesta secção baseiam-se no pró-forma PICS da ISO/IEC 8208:1993 [Referência 7]. As entradas na coluna "Referências" em "Características da norma base" das seguintes tabelas, são referências a cláusulas dessa norma.

E.8.2.1. Características Gerais dos DTE

Tabela 5

Características Gerais dos DTE

>POSIÇÃO NUMA TABELA>

E.8.2.2. Procedimentos, Tipos e Formatos dos Pacotes

Tabela 6

Funções da Camada de Pacotes Independentes dos Canais Lógicos

>POSIÇÃO NUMA TABELA>

Tabela 7

Estabelecimento da Chamada

>POSIÇÃO NUMA TABELA>

Tabela 8

Cancelamento da Chamada

>POSIÇÃO NUMA TABELA>

Tabela 9

Restabelecimento de Canais Lógicos

>POSIÇÃO NUMA TABELA>

Tabela 10

Procedimentos de Erro

>POSIÇÃO NUMA TABELA>

Tabela 11

Interrupção da Transferência

>POSIÇÃO NUMA TABELA>

Tabela 12

Envio de Dados

>POSIÇÃO NUMA TABELA>

Tabela 13

Recepção de Dados

>POSIÇÃO NUMA TABELA>

Tabela 14

Confirmação da Entrega

>POSIÇÃO NUMA TABELA>

E.8.2.3. Características e Opções Diversas

Tabela 15

Valores dos Códigos de Causa e Diagnóstico

>POSIÇÃO NUMA TABELA>

E.8.2.4. Funcionalidades

Tabela 16

Funcionalidades Enviadas nos Pacotes CALL REQUEST

>POSIÇÃO NUMA TABELA>

Tabela 17

Funcionalidades Enviadas nos Pacotes CALL ACCEPTED

>POSIÇÃO NUMA TABELA>

Tabela 18

Funcionalidades Enviadas nos Pacotes CLEAR REQUEST

>POSIÇÃO NUMA TABELA>

Tabela 19

Funcionalidades Recebidas nos Pacotes INCOMING CALL

>POSIÇÃO NUMA TABELA>

Tabela 20

Funcionalidades Recebidas nos Pacotes CALL CONECTED

>POSIÇÃO NUMA TABELA>

Tabela 21

Funcionalidades Recebidas nos Pacotes CLEAR INDICATION

>POSIÇÃO NUMA TABELA>

Tabela 22

Funcionalidades Recebidas nos Pacotes de CLEAR CONFIRMATION

>POSIÇÃO NUMA TABELA>

E.8.2.5. Valores e Gamas dos Parâmetros

Tabela 23

Valores e Gamas dos Parâmetros

>POSIÇÃO NUMA TABELA>

E.8.3. Requisitos da Camada de Ligação de Dados

As PRL estabelecidas nesta secção baseiam-se nos pró-formas PICS da ISO/IEC 7776:1994 [Referência 6]. As entradas na coluna "Referência" em "Características da Norma Base" das seguintes tabelas, são referências a cláusulas dessa norma.

Tabela 24

Protocolo da Ligação de Dados

>POSIÇÃO NUMA TABELA>

E.8.4. Requisitos da Camada Física

Consultar a cláusula A.4 da ISO/IEC TR 10609-9 [Referência 8].

ANEXO F (Informativo)

METODOLOGIA DO ENSAIO DE CONFORMIDADE

F.1. Introdução

F.1.1. É importante que as implementações do presente ICD sejam de forma a existir um elevado nível de confiança na interoperação entre Centros de Controlo de Tráfego Aéreo (ATCC) que operem através do interface.

F.1.2. As implementações dos interfaces realizadas pelos Estados-membros são efectuadas de modo a assentar no processo de aquisição de origem diversa. Para ter bastante confiança na interoperabilidade das implementações, é necessário um conjunto comum de requisitos para os ensaios de conformidade, com vista a normalizar a preparação do ensaio, o ensaio propriamente dito e a apresentação dos resultados.

F.2. Âmbito e Finalidade

F.2.1. O presente Anexo define os requisitos para os ensaios de conformidade das implementações da presente Norma do Eurocontrol que inclui este Anexo.

F.2.2. O presente Anexo identifica mecanismos onde a confiança no interface declarado é estabelecida através de um processo de ensaio para validar o pedido de declaração de conformidade.

F.3. Bibliografia

O seguinte documento é aplicável ao ensaio das implementações do presente Documento Normativo do Eurocontrol:

ICD FDE (Divisão de Sistemas do Controlo da Região Superior (UAC) de Maastricht) do Eurocontrol, Parte 1, Plano de Ensaio de Integração, Versão 1.0, de 10 de Maio de 1996 [Referência 15].

F.4. Métodos e Práticas de Desenvolvimento

F.4.1. As implementações do ICD podem ser efectuadas utilizando determinadas opções e versões do próprio ICD. Por forma a estabelecer o potencial de interoperação, um Estado-membro que implemente o interface deve identificar quais as partes do ICD que são suportadas, com uma declaração precisa quanto às capacidades dos parâmetros variáveis que são suportadas e quais as limitações, se existentes.

F.4.2. Qualquer implementação deve ser sujeita ao ensaio de conformidade abaixo descrito.

F.5. Ensaios

F.5.1. Introdução

F.5.1.1. De modo a confiar no Interface FDE e fornecer suporte para a sua implementação num ATCC, com vista à interoperação entre aplicações FDE cooperantes, é desejável que cada uma seja ensaiada quanto à conformidade com as normas, de que o presente Anexo faz parte. Este ensaio aplica-se ao comportamento externo do Sistema em Ensaio (SUT) e destina-se a testar a interoperação e não o funcionamento do sistema terminal.

F.5.1.2. Os resultados destes ensaios podem servir de prova para apoiar os pedidos de declaração de conformidade efectuados de acordo com a Secção 5.1 desta parte do presente Documento Normativo do Eurocontrol. Os pró-formas PICS e as PRL evocados por esta especificação do perfil podem servir de base aos ensaios de conformidade; além disso, as normas internacionais (por exemplo, ISO/IEC 8208 [Referência 7]) podem já possuir séries de ensaios resumidos definidos, que podem ser utilizados nos ensaios de conformidade.

F.5.1.3. O presente documento pretende fornecer um programa normalizado de ensaio baseado numa série de ensaios normalizados, cuja utilização deve conduzir à comparação dos resultados, à ampla aceitação de tais resultados e a uma minimização dos ensaios de conformidade necessários. A série de ensaios normalizados foi, em parte, desenvolvida pelo Eurocontrol.

F.5.1.4. Baseado na Figura 2, o ensaio do sistema terminal completo toma a forma de ensaios às 3 camadas inferiores. Recomenda-se que o ensaio inclua testes à aplicação FDE e às Mensagens de Situação, de Sistema e de Operador.

F.5.1.5. Cada um dos ensaios abaixo descritos deve ser efectuado por ordem. O último ensaio só terá sucesso se as camadas inferiores se encontrarem a funcionar correctamente, sendo provável que tal seja verificado com os primeiros ensaios.

F.5.1.6. Não obstante o acima mencionado, a realização do ensaio descrito na presente secção não é obrigatória.

F.5.2. Ensaio das Camadas Inferiores (Camadas 1-3)

Para apoiar o requisito da interoperação entre qualquer um dos ATCC e os seus congéneres, recomenda-se que qualquer ensaio se baseie na utilização do plano de ensaio definido no Plano de Ensaio de Integração do ICD FDE (Divisão de Sistemas UAC de Maastricht) do Eurocontrol. Os procedimentos de ensaio deverão ser objecto de acordo bilateral entre ATCC que operem em conjunto.

F.5.3. Ensaio da Camada de Aplicação

As ATCC que operem em conjunto devem acordar e realizar uma série de ensaios bilateralmente acordados.

F.5.4. Certificação

Os resultados dos ensaios devem ser registados e acordados entre as partes cooperantes.

F.5.5. Notificação

Os Estados-membros devem transmitir ao Eurocontrol os resultados pormenorizados de quaisquer ensaios.

ANEXO G (Informativo)

ATRIBUIÇÃO DE CÓDIGOS IDENTIFICADORES DAS UNIDADES ATC

A tabela seguinte mostra os códigos identificadores das unidades ATC atribuídos até 22 de Abril de 1997. O Eurocontrol pode fornecer informação sobre a actual atribuição de códigos identificadores. A tabela mostra igualmente em hexadecimal, a codificação binária do código identificador como parte da codificação de endereços NSAP definida no Anexo C.

Tabela 1

Códigos Identificadores das Unidades ATC

>POSIÇÃO NUMA TABELA>

ANEXO H (Informativo)

ORIENTAÇÕES SOBRE FIABILIDADE, DISPONIBILIDADE E SEGURANÇA

H.1. Introdução

Prevê-se que as aplicações ATC, tais como a OLDI, utilizem redes X.25 interligadas e/ou serviços de telecomunicações públicos ou privados. Consequentemente, torna-se necessário fornecer linhas de orientação para as implementações da Parte 1 do ICD FDE.

H.2. Finalidade e Âmbito

H.2.1. A finalidade do presente Anexo é fornecer linhas de orientação no que diz respeito a questões relacionadas com a fiabilidade, disponibilidade e segurança.

H.2.2. O âmbito do presente Anexo baseia-se em dois cenários. O primeiro cenário é uma ligação ponto-a-ponto através de uma linha alugada. O segundo cenário é baseado num ambiente de redes X.25 interligadas.NOTA

No segundo cenário, não são consideradas as questões relativas à interligação das redes X.25.

H.2.3. Pressupõe-se que as implementações se encontram fisicamente protegidas contra intrusão, falhas de energia eléctrica e outras ameaças externas que possam afectar o normal funcionamento.

H.3. Bibliografia

O documento seguinte é uma análise técnica mais pormenorizada em relação ao presente Anexo.

ICD FDE Eurocontrol, Parte 1: Fiabilidade, Disponibilidade e Segurança - Relatório Técnico [Referência 16].

H.4. Implementações sobre Linhas Alugadas

H.4.1. Fiabilidade

Para melhorar a fiabilidade do serviço, os cabos das linhas alugadas, PSTN, Redes Digitais com Integração de Serviços (RDIS) têm de seguir caminhos fisicamente diferentes e estar ligados a diferentes centrais de comutação do operador de telecomunicações (isto deve ser especificado ao operador de telecomunicações).

H.4.2. Disponibilidade

H.4.2.1. Devido aos longos tempos de estabelecimento nas PSTN, que são incompatíveis com as aplicações com restrições temporais, devem ser usadas RDIS como meios de reserva.

H.4.2.2. Em caso de mudança de um DTE para outro, o DTE de reserva deve gerar uma trama DISC para acelerar o restabelecimento da ligação.

H.4.3. Segurança

H.4.3.1. Ao utilizar a RDIS como meio de reserva, o adaptador de terminal (TA) RDIS chamado deve validar o endereço E.164 do chamador [Referência 18].

H.4.3.2. O DTE chamador deve estar em conformidade com a Recomendação X.32 da ITU-T [Referência 17], através da inclusão da identificação do chamador e da informação de autenticação.

H.4.4. Exemplo de Configuração

Figura H.1

Exemplo de Configuração de Linha Alugada

>PIC FILE= "L_2000254PT.023301.EPS">

H.5. Implementação de Rede

H.5.1. Fiabilidade

Para melhorar a fiabilidade do serviço, os computadores hospedeiros num dado local devem ser ligados a dois DCE pertencentes a diferentes centrais de comutação da rede (este requisito deve ser especificado ao operador da rede).

H.5.2. Disponibilidade

H.5.2.1. Deve ser utilizada a funcionalidade de grupo de busca para permitir a atribuição de um único endereço X.121 [Referência 20] aos DCE existentes num dado local, optimizando assim o encaminhamento da rede e limitando o número de chamadas mal sucedidas.

H.5.2.2. No caso de serem implementados outros mecanismos de chamada, resultando num diferente valor do endereço do DTE chamado nos pacotes CALL REQUEST e CALL ACCEPT, o DTE chamador deve ser configurado de forma a não produzir impacto no estabelecimento da chamada.

H.5.2.3. No caso de o DCE se desligar devido a uma falha da rede e se estiver disponível um segundo acesso à rede, o restabelecimento da chamada deve ser efectuado através desse segundo acesso.

H.5.3. Segurança

No âmbito do presente Anexo, a funcionalidade de Grupo Fechado de Utilizadores (CUG) é a única funcionalidade de rede aplicável que deve ser utilizada.

H.6. Orientações Gerais sobre Linhas Alugadas e Implementações de Rede

H.6.1. Fiabilidade

H.6.1.1. Dada a possível morosidade da mudança completa de um computador hospedeiro para outro, é aconselhável considerar a utilização de um processador frontal (FEP) para tratar falhas do computador hospedeiro.

H.6.1.2. Uma arquitectura baseada num FEP pode aumentar a fiabilidade do serviço.NOTA

A inclusão de uma pilha de transporte na especificação do perfil pode ser desenvolvida no contexto de uma futura norma ICD FDE, Parte 2.

H.6.2. Disponibilidade

Quando uma chamada falhar, o local chamador deve efectuar uma segunda chamada utilizando o segundo endereço X.121 (se disponível).

H.6.3. Gestão de Sistemas

H.6.3.1. Sempre que possível, devem ser utilizadas centrais que sejam automaticamente comutadas através da leitura dos sinais dos interfaces.

H.6.3.2. Pode ser utilizada uma indicação local de erro durante a transmissão dos dados para activar a mudança de um computador hospedeiro para outro.

H.6.3.3. A mudança de um FEP para outro deve gerar um TC-desligar para garantir que o computador hospedeiro local se encontra no estado inactivo.

H.6.3.4. A expiração do tempo na rede X.25 ou nas camadas de ligação de dados deve causar a libertação das camadas superiores.

H.6.3.5. Uma falha total do FEP deve gerar um TC-desligar.

H.6.3.6. O sistema de gestão deve interrogar a camada do Protocolo de Transferência de Mensagens (Anexo A) e verificar o estado da máquina para distinguir entre uma falha do Protocolo de Transferência de Mensagens e uma falha da aplicação.

H.6.4. Exemplo de Configuração

Figura H.2

Exemplo de Configuração da Rede

>PIC FILE= "L_2000254PT.023401.EPS">