2000R2082 — PT — 15.06.2002 — 001.001 — 1
Este documento constitui um instrumento de documentação e não vincula as instituições
►BREGULAMENTO (CE) N.o2082/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
(JO L 254 de 9.10.2000, p. 1)
Alterado por:
Jornal Oficial
n.opágina data
►M1Regulamento (CE) n.o980/2002 da Comissão de 4 de Junho de 2002 L 150 38 8.6.2002
▼B
REGULAMENTO (CE) N.o2082/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écnicascompatíveis com a aquisição de equipamentos e de sistemas para agestã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/CEEdo Conselho relativa à definição e à utilização de especificaçõesté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, ea norma Eurocontrol para a apresentação do intercâmbio deinformação dos serviços de tráfego aéreo (ADEXP), edição 1.0.
(2)Eurocontrol adoptou versões mais recentes das duas normasacima mencionadas, ou seja, OLDI edição 2.2 e ADEXPediçã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 daDirectiva 93/65/CEE e contribuem para a harmonização dossistemas nacionais de gestão do tráfego aéreo pelos Estados--Membros, especialmente no que diz respeito à transferência devoos entre os centros de controlo de tráfego aéreo (OLDI), agestã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çõesanteriores actualmente em vigor de acordo com as disposições
do artigo 1.
oda Directiva 97/15/CE e; portanto; esse artigo foi
revogado.
(5)As disposições do presente regulamento estão de acordo com oparecer 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 umsistema integrado europeu de gestão do tráfego aéreo, os elementosobrigatórios das especificações Eurocontrol incluídas nas normas Euro-control 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 EurocontrolDPS.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 infor-
mação dos serviços de tráfego aéreo (ADEXP), edição 2.02000R2082 — PT — 15.06.2002 — 001.001 — 2
(1) JO L 187 de 29.7.1993, p. 52.
(2) JO L 95 de 10.4.1997, p. 16.
▼B
(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 — docu-
mento de controlo do interface (FDE-ICD), edição 1.0 (referênciado documento do Eurocontrol COM.ET1.ST12-STD), cujo texto
está incluído no anexo III do presente regulamento.
Artigo 2.
o
O artigo 1.oda 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.2000R2082 — PT — 15.06.2002 — 001.001 — 3
▼B
ANEXO I
INTERCAMBIO DE INFORMAÇÃO EM TEMPO REAL (OLDI),
EDIÇÃO 2.2
(referência do documento do Eurocontrol DPS.ET1.ST06-STD)2000R2082 — PT — 15.06.2002 — 001.001 — 4
▼B
ÍNDICE
DIREITOS DE AUTOR
PREFÁCIO1. INTRODUÇÃO
1.1. Objectivo1.2. Âmbito
2. REFERÊNCIAS3. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS
3.1. Definições3.2. Símbolos e Abreviaturas
4. REQUISITOS GERAIS
4.1. Introdução4.2. Requisitos do Sistema de Processamento de Informação de Voo4.2.1. Base de Dados de Voo4.2.2. Operação em Tempo Real4.2.3. Capacidade de Comunicação de Dados4.2.4. Funções Aplicacionais4.2.5. Interface Homem-Máquina (HMI)4.2.6. Inicialização de Mensagens4.2.7. Recepção de Mensagens4.3. Actualização da Informação sobre Vigilância4.4. Gravação da Informação OLDI4.4.1. Conteúdo4.4.2. Funcionalidades4.5. Disponibilidade, Fiabilidade, Segurança da Informação e Integridade dos Dados4.5.1. Disponibilidade4.5.2. Fiabilidade4.5.3. Segurança da Informação4.5.4. Integridade dos Dados4.6. Avaliação Operacional4.6.1. Período de Avaliação4.6.2. Data de Introdução Operacional
5. CATEGORIAS DAS MENSAGENS
5.1. Generalidades5.1.1. Objectivo5.1.2. Categorias das Mensagens5.2. Tempos de Transacção5.2.1. Condições para os Tempos de Transacção5.3. Classificação e Categorização das Mensagens2000R2082 — PT — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Classificação das Mensagens — Obrigatórias e Complementares
5.3.2. Categorização das Mensagens
6. PROCEDIMENTO BÁSICO — MENSAGENS OBRIGATÓRIAS
6.1. Generalidades6.1.1. Descrição do Requisito6.1.2. Implementação6.2. Mensagem Avançada de Informação de Fronteira (ABI)
6.2.1. Finalidade da Mensagem ABI
6.2.2. Conteúdo da Mensagem6.2.3. Regras de Aplicação6.2.4. Confirmação da ABI6.2.5. Exemplos6.3. Mensagem de Activação (ACT)
6.3.1. Finalidade da Mensagem de Activação
6.3.2. Conteúdo das Mensagens6.3.3. Regras de Aplicação6.3.4. Confirmação da ACT6.3.5. Exemplos
6.4. Mensagem de Confirmação Lógica (LAM)
6.4.1. Finalidade da Mensagem LAM6.4.2. Conteúdo da Mensagem6.4.3. Regras de Aplicação6.4.4. Confirmação da LAM6.4.5. Exemplos
7. PROCEDIMENTO BÁSICO — MENSAGENS COMPLEMENTARES
7.1. Generalidades
7.1.1. Descrição do Requisito7.1.2. Implementação7.2. Mensagem de Activação Preliminar (PAC)7.2.1. Finalidade da Mensagem PAC7.2.2. Conteúdo da Mensagem
7.2.3. Regras de Aplicação
7.2.4. Confirmação da PAC7.2.5. Exemplos7.3. Mensagem de revisão (REV)7.3.1. Finalidade da Mensagem REV
7.3.2. Conteúdo da mensagem
7.3.3. Regras de Aplicação7.3.4. Confirmação da REV7.3.5. Exemplos2000R2082 — PT — 15.06.2002 — 001.001 — 6
▼B
7.4. Mensagem de Revogação da Coordenação (MAC)
7.4.1. Finalidade da Mensagem MAC7.4.2. Conteúdo da Mensagem
7.4.3. Regras de Aplicação
7.4.4. Confirmação de uma MAC7.4.5. Exemplos7.5. Mensagem de Atribuição de Código SSR (COD)
7.5.1. Finalidade da Mensagem COD
7.5.2. Conteúdo da Mensagem7.5.3. Regras de Aplicação
7.5.4. Confirmação da COD
7.5.5. Exemplos7.6. Mensagem de Informação (INF)7.6.1. Finalidade da mensagem INF
7.6.2. Conteúdo da Mensagem
7.6.3. Regras de Aplicação7.6.4. Confirmação da INF
7.6.5. Exemplo
8. PROCEDIMENTO DE DIÁLOGO — COORDENAÇÃO
8.1. Generalidades8.1.1. Introdução
8.1.2. O Filtro
8.1.3. Sequência das Mensagens8.1.4. Tratamento de Mensagens Simultâneas8.1.5. Rejeição de Tratamento
8.1.6. Expiração do Tempo de Resposta Operacional
8.1.7. Implementação8.2. Mensagem de Activação (ACT)
8.2.1. Finalidade da Mensagem ACT
8.2.2. Conteúdo da Mensagem8.2.3. Regras de Aplicação
8.2.4. Confirmação da ACT
8.3. Mensagem de Proposta de Activação Remetida (RAP)8.3.1. Finalidade da Mensagem RAP8.3.2. Conteúdo da Mensagem
8.3.3. Regras de Aplicação
8.3.4. Confirmação da RAP8.3.5. Resposta Operacional à RAP
8.3.6. Exemplos
8.4. Mensagem de Revisão (REV)2000R2082 — PT — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Finalidade da Mensagem REV
8.4.2. Conteúdo da Mensagem8.4.3. Regras de Aplicação
8.4.4. Confirmação da REV
8.4.5. Resposta Operacional à REV8.5. Mensagem de Proposta de Revisão Remetida (RRV)8.5.1. Finalidade da Mensagem RRV
8.5.2. Conteúdo da Mensagem
8.5.3. Regras de Aplicação8.5.4. Confirmação da RRV
8.5.5. Resposta Operacional à RRV
8.5.6. Exemplos8.6. Mensagem de Espera (SBY)8.6.1. Finalidade da Mensagem SBY
8.6.2. Conteúdo da Mensagem
8.6.3. Regras de Aplicação8.6.4. Confirmação da SBY
8.6.5. Exemplos
8.7. Mensagem de Aceitação (ACP)8.7.1. Finalidade da Mensagem de Aceitação
8.7.2. Conteúdo da Mensagem
8.7.3. Regras de Aplicação8.7.4. Confirmação da ACP8.7.5. Exemplos
8.8. Mensagem de Coordenação (CDN)
8.8.1. Finalidade da Mensagem CDN8.8.2. Conteúdo da Mensagem
8.8.3. Regras de Aplicação
8.8.4. Confirmação da CDN8.8.5. Resposta Operacional à CDN8.8.6. Exemplos
8.9. Mensagem de Rejeição de Coordenação (RJC)
8.9.1. Finalidade da Mensagem RJC8.9.2. Conteúdo da Mensagem
8.9.3. Regras de Aplicação
8.9.4. Confirmação da RJC8.9.5. Exemplos
9. PROCEDIMENTO DE DIÁLOGO — TRANSFERÊNCIA DE COMUNICAÇÃO
9.1. Generalidades
9.1.1. Introdução2000R2082 — PT — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Sequência das Mensagens
9.1.3. Transferência de Comunicações9.2. Mensagem de Início de Transferência (TIM)
9.2.1. Finalidade da Mensagem TIM
9.2.2. Conteúdo da Mensagem9.2.3. Regras de Aplicação9.2.4. Confirmação da TIM
9.2.5. Exemplo
9.3. Mensagem de Informação Suplementar (SDM)9.3.1. Finalidade da Mensagem SDM
9.3.2. Conteúdo da Mensagem
9.3.3. Regras de Aplicação9.3.4. Confirmação da SDM9.3.5. Exemplo
9.4. Proposta de Entrega (HOP)
9.4.1. Finalidade da Mensagem HOP9.4.2. Conteúdo da Mensagem
9.4.3. Regras de Aplicação
9.4.4. Confirmação da HOP9.4.5. Exemplo
9.5. Mensagem de Pedido na Frequência (ROF)
9.5.1. Finalidade da Mensagem ROF9.5.2. Conteúdo da Mensagem9.5.3. Regras de Aplicação
9.5.4. Confirmação da ROF
9.5.5. Exemplo9.6. Mensagem de Mudança de Frequência (COF)
9.6.1. Finalidade da Mensagem COF
9.6.2. Conteúdo da Mensagem9.6.3. Regras de Aplicação9.6.4. Confirmação da COF
9.6.5. Exemplos
9.7. Mensagem de Afectação Manual das Comunicações (MAS)9.7.1. Finalidade da Mensagem MAS
9.7.2. Conteúdo da Mensagem
9.7.3. Regras de Aplicação9.7.4. Confirmação da MAS
9.7.5. Exemplo
ANEXO A (NORMATIVO) REGRAS PARA A INSERÇÃO DE DADOS
ANEXO B (NORMATIVO) REQUISITOS DE PROCESSAMENTO DE ROTAS ESPECIAIS2000R2082 — PT — 15.06.2002 — 001.001 — 9
▼B
ANEXO C (INFORMATIVO) FASES DO PROCEDIMENTO DE DIÁLOGO (NÍVEL 1 DO
SYSCO) — SEQUÊNCIA DAS MENSAGENS2000R2082 — PT — 15.06.2002 — 001.001 — 10
▼B
INFORMAÇÃO RELATIVAAOS 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.2000R2082 — PT — 15.06.2002 — 001.001 — 11
▼B
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 represen-
tantes 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 alte-
raçõ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 decla-
raçã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 especifi-
caçõ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.2000R2082 — PT — 15.06.2002 — 001.001 — 12
▼B
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 trajec-
tó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 trans-
ferê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 procedi-
mento 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 especifi-
caçã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.2000R2082 — PT — 15.06.2002 — 001.001 — 13
▼B
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, é procedi-
mento 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 coorde-
nação, é uma importante tarefa de apoio das unidades ATC,
particularmente nos Centros de Controlo de Área (ACC). A utili-
zaçã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 desenvolvi-
mento permanente dessas facilidades, em conformidade com os
requisitos do EATCHIP.
1.2. Âmbito
1.2.1. O presente documento especifica as funcionalidades e as mensa-
gens 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 Euro-
control 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 OLDIinternacionais entre unidades que
executem um serviço ATC de área dentro da área ECAC;
—funcionalidades OLDIentre 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 Eurocon-
trol até serem formalmente revistas e incorporadas no presente
Documento Normativo do Eurocontrol.2000R2082 — PT — 15.06.2002 — 001.001 — 14
▼B
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 Nave-
gação Aérea — Regras do Ar e dos Serviços de Tráfego
Aéreo), Documento n.o4444 da ICAO, Décima terceira
Edição, de 7 de Novembro de 1996, com as alterações intro-
duzidas.
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 trans-
ferê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 inter-
mé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 conformi-
dade 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 defi-
nidas 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 fron-2000R2082 — PT — 15.06.2002 — 001.001 — 15
▼B
teira) 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 carac-
terí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 directa-
mente 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 trans-
mite 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, locali-
zado 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 coorde-
nação.2000R2082 — PT — 15.06.2002 — 001.001 — 16
▼B
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 comu-
nicaçã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 ÁreaACP Mensagem de AceitaçãoACT Mensagem de Activação
ADEXP Apresentação do Intercâmbio de Informação ATS
ATC Controlo de Tráfego AéreoATM Gestão de Tráfego AéreoATS Serviço de Tráfego AéreoCDN Mensagem de CoordenaçãoCNL Cancelamento de Plano de VooCOD Mensagem de Atribuição de Código SSR
COF Mensagem de Mudança de Frequência
COP Ponto de CoordenaçãoDED 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 CivilETO Hora Estimada SobreETOT Hora Estimada de DescolagemEWPD Documento do Programa de Trabalho do EATCHIP
FDPS Sistema de Processamento de Informação de Voo
FRF Rota Subsequente do VooHMI Interface Homem-MáquinaHOP Mensagem de Proposta de EntregaICAO Organização da Aviação Civil InternacionalINF Mensagem de InformaçãoLAM Mensagem de Confirmação Lógica
LoA Carta de Acordo
MAC Mensagem de Revogação de CoordenaçãoMAS Afectação Manual das ComunicaçõesNM Milha NáuticaOLDI Intercâmbio de Informação em Tempo RealORCAM Método de Atribuição de Códigos por Região de
Origem
PAC Mensagem de Activação PreliminarRAP Mensagem de Proposta de Activação RemetidaREV Mensagem de RevisãoRJC Mensagem de Rejeição de CoordenaçãoROF Mensagem de Pedido na Frequência
RRV Mensagem de Revisão Remetida2000R2082 — PT — 15.06.2002 — 001.001 — 17
▼B
SBY Mensagem de Espera
SDM Mensagem de Informação SuplementarSSR Radar de Vigilância SecundárioSYSCO Coordenação Suportada pelo SistemaTI Início da TransferênciaTIM Mensagem de Início de TransferênciaTWR/APP Torre (controlo de aeródromo) e Controlo de Apro-
ximação
4. REQUISITOSGERAIS
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 especifi-
cada. 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 trans-
ferê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 Coor-
denado 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 desenvol-
vimento 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, arma-
zenar, processar, extrair e passar para o ecrã, e transmitir em
tempo real, informação relativa à OLDI.2000R2082 — PT — 15.06.2002 — 001.001 — 18
▼B
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 modifi-
caçã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 imedia-
tamente a atenção da posição de trabalho adequada.
4.2.5.6. Recomendação O HMIem posições ATC que utilizem OLDI
deveria lançar um alerta se a funcionalidade OLDInã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 manual-
mente 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 é visuali-
zado 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 infor-
maçã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 trans-2000R2082 — PT — 15.06.2002 — 001.001 — 19
▼B
missã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 confir-
maçã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çadaInformaçãoeInte-
gridade 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 OLDIdeveria estar permanen-
temente disponível.
4.5.1.3. Quaisquer períodos programados de indisponibilidade (e, assim, o
período de disponibilidade previsto) deverá ser acordado bilate-
ralmente 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 disponibilidadede 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.2000R2082 — PT — 15.06.2002 — 001.001 — 20
▼B
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 2 000 mensagens.
4.6. Avaliação Operacional
4.6.1. Período de Avaliação
Cada nova funcionalidade OLDI, incluindo uma nova funcionali-
dade 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 OLDIno 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. CATEGORIASDAS 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 cate-
goria;
— 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 transferi-
dora. 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
Categoria da Mensagem 90 % 99,8 %
1 4 seg. 10 seg.
2 10 seg. 25 seg.
3 15 seg. 45 seg.
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 rele-
vante do presente documento.2000R2082 — PT — 15.06.2002 — 001.001 — 21
▼B
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 deve-
riam 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 obriga-
tó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 Coorde-
naçã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
Tipo de Mensagem Abreviatura Categoria Transmissão Recepção
Informação de Fronteira
AvançadaABI 3 M M
Activação ACT 2 M M
Revisão REV 2 C (1)C (1)
Activação Preliminar PAC 2 C CRevogação de Coorde-
naçãoMAC 2 C C
Atribuição de Código SSR COD 2 C C
Informação INF 3 C C
Mensagem de Confir-
mação LógicaLAM M M
NOTA
(1) Obrigatória na TX e REC quando utilizada num procedimento de diálogo.2000R2082 — PT — 15.06.2002 — 001.001 — 22
▼B
Tabela 5-3
Procedimento de Diálogo — Mensagens da Fase de Coordenação
(Adicional à Tabela 5-2)
Tipo de Mensagem Abreviatura Categoria Transmissão Recepção
Proposta de Activação
RemetidaRAP 2 C M
Revisão Remetida RRV 2 C M
Coordenação CDN 2 M M
Espera (1) SBY M M
Aceitação ACP 2 M M
Rejeição de Coorde-
nação (2)RJC 2 C C
NOTAS
(1) Ver parágrafo 5.2.1.1, Condições para os Tempos de Transacção.
(2) Não utilizada em todas as configurações de espaço aéreo.
Tabela 5-4
Procedimento de Diálogo — Mensagens da Fase de Transferência
Tipo de Mensagem Abreviatura Categoria Transmissão Recepção
Inicialização da Trans-
ferênciaTIM 1 M M
Informação Suplementar SDM 1 (1)(1)
Proposta de Entrega HOP 1 M M
Mudança de Frequência (2) COF 1 C M
Pedido na Frequência ROF 1 C M
Afectação Manual (2) MAS 1 C M
NOTAS
(1) M quando enviada pela unidade transferidora; C quando enviada pela unidade aceitante.
(2) Os procedimentos de acordo bilateral deverão especificar que ao efectuar-se a transferência
relativamente a uma dada direcção do fluxo de tráfego, no mínimo, a unidade transferidora
deverá enviar uma mensagem COF ou a unidade aceitante deverá enviar uma mensagem MAS.
6. PROCEDIMENTO BÁSICO — MENSAGENS OBRIGA-
TÓRIAS
6.1. Generalidades
6.1.1. Descrição do Requisito
A presente secção descreve os requisitos mínimos para a imple-
mentaçã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;2000R2082 — PT — 15.06.2002 — 001.001 — 23
▼B
— 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,— dados estimados,— aeródromo de destino,— número e tipo da aeronave,— tipo de voo,— capacidade e situação do equipamento,
— 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 ABIdeveria ser inibida se as
mensagens ACT ou RAP estiverem para ser enviadas imediata-
mente 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 mensa-
gens ABIe 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 ABIantecedente em mais do que o tempo espe-
cificado na Carta de Acordo (LoA);
—Qualquer outra informação que tenha sido objecto de acordo
bilateral .
6.2.3.2. Processamento na Unidade Receptora6.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 correspon-
dente.2000R2082 — PT — 15.06.2002 — 001.001 — 24
▼M1
▼B
▼B
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 identifi-
cada 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ão6.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. I C A O
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/
/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
-81/W/EQ Y/NO)
6.2.5.2. A D E X P
TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -
-SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 - ADEP
LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES
EGBB -ARCTYP B757 -FLTTYP N -BEGIN EQCST -EQPT W/
/EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON)
6.3. 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;2000R2082 — PT — 15.06.2002 — 001.001 — 25
▼M1
▼B
▼B
— Fornece as condições de transferência à unidade ATC recep-
tora.
6.3.2. Conteúdo da mensagem
A mensagem ACT 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,— dados estimados,
— aeródromo de destino,
— número e tipo da aeronave,
— tipo de voo,
— capacidade e situação do equipamento,— 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.3.3. Regras de Aplicação
6.3.3.1. Generalidades6.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 calcu-
lada para a transmissão.
6.3.3.1.4. O conteúdo operacional das mensagens ACT que vão ser transmi-
tidas 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 visuali-
zado 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 trans-
missã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.2000R2082 — PT — 15.06.2002 — 001.001 — 26
▼M1
▼B
▼B
6.3.3.2.2. Se for encontrado um plano de voo correspondente e não exis-
tirem 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 opera-
cional 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 processa-
mento 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ão6.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 trans-
ferê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 apresen-
tados no parágrafo 6.2 relativamente à mensagem ABI; todos os
detalhes são idênticos, com excepção da ETO no COP que é
1 226 na mensagem ACT apresentada:
6.3.5.1. I C A O
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON-80/N-
-81/W/EQ Y/NO)
6.3.5.2. A D E X P
-TITLE ACT -REFDATA -SENDER –FAC E -RECVR -FAC L -
-SEQNUM 005 –ARCID AMM253 -SSRCODE A7012 -ADEP2000R2082 — PT — 15.06.2002 — 001.001 — 27
▼M1
▼M1
LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 –ADES
EGBB -ARCTYP B757 -FLTTYP N-BEGIN EQCST-EQPT W/
/EQ -EQPT Y/NO -END EQCST-ROUTE N0480F390 UB4 BNE
UB4 BPK UB3 HON
6.4. 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 confir-
maçã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. Generalidades6.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 trans-
missõ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 0012000R2082 — PT — 15.06.2002 — 001.001 — 28
▼B
▼B
7. PROCEDIMENTO BÁSICO — MENSAGENS COMPLE-
MENTARES
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, Proce-
dimento 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. Generalidades7.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;2000R2082 — PT — 15.06.2002 — 001.001 — 29
▼B
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 indi-
cado 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 Receptora7.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 exis-
tirem 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.2000R2082 — PT — 15.06.2002 — 001.001 — 30
▼B
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 coorde-
nação verbal.
7.2.4.4. Inexistência de Mensagem COD7.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 apre-
sentado 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 bila-
teral.
7.2.5. Exemplos
7.2.5.1. Hora Estimada de Descolagem e Pedido de Código7.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 COP7.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,
— identificação da aeronave,
— aeródromo de partida,— dados estimados e/ou ponto de coordenação,
— aeródromo de destino,
— referência da mensagem (opcional),
— modo e código SSR (opcional),2000R2082 — PT — 15.06.2002 — 001.001 — 31
▼M1
▼M1
— rota (opcional),
— capacidade e situação do equipamento (opcional).
NOTA: As regras de inserção dos dados, os formatos e o
conteúdo dos campos encontram-se especificados no
anexo A.
7.3.3. Regras de Aplicação
7.3.3.1. Generalidades7.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,— capacidade e situação do equipamento.
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
ao inteiro mais próximo,
— existir alguma alteração do(s) nível(eis) de transferência, do
código SSR ou da capacidade e situação do equipamento.
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.
NOTA: As regras operacionais podem exigir que as modifi-
cações em vigor após a ACT sejam sujeitas a
coordenação prévia entre as unidades em causa.
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 alte-
ração.
7.3.3.2. Formato das Mensagens de Revisão
7.3.3.2.1. Formato I C A O
Todas as mensagens de revisão incluem os tipos de campos 3, 7,
13, 14 e 16. São aplicáveis as seguintes regras:
— será introduzida 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,
— será incluída uma alteração ao código SSR, enquanto
elementos b) e c) do campo 7.
Todas as outras alterações serão incluídas no formato do campo
22, após os cinco campos iniciais. Aplicam-se as seguintes regras:
— os campos incluídos no formato do campo 22 podem ser
dispostos em qualquer ordem,
— as alterações ao COP serão incorporadas como dados do
campo 14 no formato do campo 22 (ver anexo B — requisitos
de processamento de rotas especiais),
— as alterações de rota serão incorporadas como dados do
campo 15 no formato do campo 22. As regras de coordenação
destas alterações, incluindo as rotas directas, são especificadas
no anexo B — requisitos de processamento de rotas especiais,
— capacidade e situação do equipamento; só será(ão) incluída(s)
a(s) capacidade(s) que seja(m) alterada(s). Uma mensagem
que altere uma capacidade de modo a tornar necessária a2000R2082 — PT — 15.06.2002 — 001.001 — 32
▼B
▼M1
▼B
▼M1
▼M1
inclusão de dados respeitantes a uma capacidade adicional,
como especificado na secção A.30 do anexo A, incluirá a
capacidade adicional.
7.3.3.2.2. Formato A D E X P
Todas as mensagens de revisão no formato ADEXP devem
incluir os seguintes campos primários: TITLE REF DATA
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,
— o campo primário COP será incluído, a menos que uma alte-
ração na ETA ou no(s) nível(eis) de transferência exija o uso
do campo primário COORDATA. Deve conter o COP através
do qual o voo está a ser coordenado nesse momento ou, caso
o COP esteja a ser alterado, o COP através do qual o voo foi
anteriormente coordenado,
— as alterações no COP serão incorporadas recorrendo ao campo
primário COORDATA (ver anexo B — requisitos de proces-
samento de rotas especiais). Estas mensagens incluirão
também o campo primário COP, como indicado acima,
— as alterações de rota serão incorporadas recorrendo ao campo
primário ROUTE. As regras de coordenação destas alterações,
incluindo as rotas directas, são especificadas no anexo B —
requisitos de processamento de rotas especiais,
— uma alteração ao código SSR será indicada através da
inclusão do campo primário SSRCODE,
— as alterações na capacidade e situação do equipamento recor-
rerão ao campo primário EQCST; só será(ão) incluída(s) a(s)
capacidade(s) que seja(m) alterada(s). Uma mensagem que
altere uma capacidade de modo a tornar necessária a inclusão
de dados respeitantes a uma capacidade adicional, como espe-
cificado na secção A.30 do anexo A, incluirá a capacidade
adicional.
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 correspon-
dente.
7.3.3.3.2. Se for encontrado um plano de voo correspondente e não exis-
tirem 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á transmi-
tida 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 sepa-
radamente 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).2000R2082 — PT — 15.06.2002 — 001.001 — 33
▼B
▼B
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 confir-
maçã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ção7.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. I C A O
a) (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b) (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-
-EGBB)
c) (REVE/L019-AMM253-LMML-BNE/1237F350-EGBB-81/W/
/NO)
d) (REVBC/P873-BAF4486-EBMB-NEBUL/2201F250-LERT-
-81/W/NO U/EQ)
7.3.5.2. A D E X P
a) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COOR-
DATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB
b) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -SSRCODE A2317
c) -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC
L -SEQNUM 019 -ARCID AMM253 -ADEP LMML -COP
BNE -ADES EGBB -BEGIN EQCST -EQPT W/NO -END
EQCST
d) -TITLE REV -REFDATA -SENDER -FAC BC -RECVR -
-FAC P -SEQNUM 873 -ARCID BAF4486 -ADEP EBMB -
-COP NEBUL -ADES LERT -BEGIN EQCST -EQPT Y/NO -
-EQPT U/EQ -END EQCST
7.4. 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.2000R2082 — PT — 15.06.2002 — 001.001 — 34
▼M1
▼B
▼B
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 coor-
denaçã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 automatica-
mente 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 combi-
naçõ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 trans-
ferê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 modifi-
cada 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;2000R2082 — PT — 15.06.2002 — 001.001 — 35
▼B
— 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 correcta-
mente 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 coorde-
naçã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ção7.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á trans-
mitida nenhuma mensagem LAM.
7.4.4.2. Não Confirmação7.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 é auto-
rizado, 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 aero-
nave 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 CAN2000R2082 — PT — 15.06.2002 — 001.001 — 36
▼B
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 neces-
sitar 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 espe-
cificado 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.2000R2082 — PT — 15.06.2002 — 001.001 — 37
▼B
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 controla-
dores. 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 revi-
sõ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 bila-
teral.
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 .2000R2082 — PT — 15.06.2002 — 001.001 — 38
▼B
7.6.4. Confirmação da INF
Recomendações1.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 proveni-
ente de EGLL com destino a OMDB a FL290, solicitando FL410,
estima o VOR de Koksy (KOK) às 1905, com código de trans-
ponderA5437, prosseguindo via UG1 e UB6.
É enviada uma mensagem ACT de Londres para Maastricht rela-
tiva 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 coorde-
nação e de comunicação na fase de transferência.
8.1.1.2. A presente secção descreve as mensagens utilizadas no procedi-
mento 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 — Trans-
ferê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 identifi-
caçã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 interpre-
taçã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.2000R2082 — PT — 15.06.2002 — 001.001 — 39
▼B
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 norma-
lizadas» 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 normali-
zadas.
8.1.2.2. Acção na Unidade Transferidora8.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 trans-
ferê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 Aceitante8.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 rece-
bidas 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 Filtros8.1.2.4.1. A utilização de mensagens diferentes para condições de trans-
ferê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 trans-
ferê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. Generalidades8.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); ou2000R2082 — PT — 15.06.2002 — 001.001 — 40
▼B
— 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 trans-
ferê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 coorde-
nação telefónica nos casos em que seja aplicável.
8.1.6. Expiração do Tempo de Resposta Operacional
8.1.6.1. Generalidades8.1.6.1.1. Nos centros receptores e emissores deve ser aplicado um meca-
nismo 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 expi-
raçã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, nomeada-
mente 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 trans-
ferê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 quais-
quer 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);2000R2082 — PT — 15.06.2002 — 001.001 — 41
▼B
— procedimento de diálogo na fase de transferência e de coorde-
naçã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 contro-
lador 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 rece-
bida uma mensagem de Rejeição de Coordenação (RJC).
8.2.3.2. Processamento na Unidade Receptora8.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 confor-
midade com o parágrafo 6.3.3.2.
8.2.3.2.4. Recomendação Se se determinar que as condições de trans-
ferê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ção8.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 normali-
zadas;
— 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 ACT2000R2082 — PT — 15.06.2002 — 001.001 — 42
▼B
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 coor-
denaçã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 trans-
ferê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. Generalidades8.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 trans-
ferência não são normalizadas;
— o controlador transferidor indicou que as condições de trans-
ferê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 coorde-
naçã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 Receptora8.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 exis-
tirem discrepâncias na mensagem que inibam o seu
processamento correcto:
— o conteúdo operacional deve ser remetido ao controlador acei-
tante;
— 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.2000R2082 — PT — 15.06.2002 — 001.001 — 43
▼B
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 contro-
lador 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 coorde-
nadas, 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 contrapro-
posta 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 que2000R2082 — PT — 15.06.2002 — 001.001 — 44
▼B
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. Generalidades8.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 Receptora8.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 normali-
zadas, 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ção8.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 trans-
ferê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 coor-
denaçã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 unidade2000R2082 — PT — 15.06.2002 — 001.001 — 45
▼B
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 trans-
ferê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 acei-
tante.
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 trans-
ferência não são normalizadas;
ou
— o controlador transferidor indicou que as condições de trans-
ferê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.2000R2082 — PT — 15.06.2002 — 001.001 — 46
▼B
8.5.5.2. Contraproposta
Quando o controlador aceitante decide efectuar uma contrapro-
posta à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 imedia-
tamente 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;2000R2082 — PT — 15.06.2002 — 001.001 — 47
▼B
— 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 trans-
ferê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 Receptora8.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.2000R2082 — PT — 15.06.2002 — 001.001 — 48
▼B
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 trans-
ferê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 acei-
tante.
8.8.3.1.2. Serão utilizadas para transmitir uma contraproposta do contro-
lador 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.2000R2082 — PT — 15.06.2002 — 001.001 — 49
▼B
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 utili-
zaçã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 confir-
maçã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 envol-
vido.
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 trans-
ferê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)2000R2082 — PT — 15.06.2002 — 001.001 — 50
▼B
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 contro-
lador 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. Generalidades8.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 acor-
dadas.
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 Receptora8.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 processa-
mento, 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)2000R2082 — PT — 15.06.2002 — 001.001 — 51
▼B
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 procedi-
mento 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 encon-
tram-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 envol-
vidas.
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 dife-
rentes. Por exemplo, uma unidade pode gerar mensagens
COF para voos que saem do seu espaço aéreo e mensa-
gens 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 coor-
denaçã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;2000R2082 — PT — 15.06.2002 — 001.001 — 52
▼B
— 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. Generalidades9.2.3.1.1. A mensagem TIM será gerada e transmitida pela unidade transfe-
ridora 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 encon-
trar 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 Receptora9.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 apro-
priada.
9.2.5. Exemplo
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
-SEQNUM 029 -ARCID AMM2532000R2082 — PT — 15.06.2002 — 001.001 — 53
▼B
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 contro-
lador aceitante.
9.3.1.1.2. A mensagem SDM também pode ser utilizada pela unidade acei-
tante 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 bila-
teral.
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.2000R2082 — PT — 15.06.2002 — 001.001 — 54
▼B
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 Receptora9.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 contro-
lador 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 acor-
dado 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.2000R2082 — PT — 15.06.2002 — 001.001 — 55
▼B
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. Generalidades9.4.3.1.1. A mensagem HOP, quando utilizada, deverá ser iniciada manual-
mente 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 relativa-
mente 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 Trans-
ferê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 separa-
damente para cada COP.
9.4.3.2. Processamento na Unidade Receptora9.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 visuali-
zada 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 monito-
rizaçã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 contro-
lador 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 apro-
priada.
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 a2000R2082 — PT — 15.06.2002 — 001.001 — 56
▼B
frequência do controlador aceitante. A mensagem pode ser utili-
zada:
— 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. Generalidades9.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 Receptora9.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ção9.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. Generalidades9.6.1.1.1. A COF é enviada pela unidade transferidora para a unidade acei-
tante, 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 transfe-
ridor libertar o voo das condições de transferência acordadas
quando estabelecer comunicação rádio com o controlador acei-
tante.2000R2082 — PT — 15.06.2002 — 001.001 — 57
▼B
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 bila-
teral, 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 Trans-
ferê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 transfe-
ridora 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;2000R2082 — PT — 15.06.2002 — 001.001 — 58
▼B
— 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. Generalidades9.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 bila-
teral, 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 AMM2532000R2082 — PT — 15.06.2002 — 001.001 — 59
▼B
ANEXO A (Normativo)
REGRASDE INSERÇÃODOS DADOS
ÍNDICE
A.1. Finalidade
A.2. Formatos de Mensagem GenéricosA.3. Tipo de Mensagem
A.4. Número da Mensagem
A.5. Referência da MensagemA.6. Identificação da Aeronave
A.7. Modo e Código SSR
A.8. Aeródromo de PartidaA.9. Informação Estimada
A.10. Ponto de Coordenação
A.11. Aeródromo de DestinoA.12. Número e Tipo da Aeronave
A.13. Rota
A.14. Outras Informações do Plano de VooA.15. Estado e Razão da Coordenação
A.16. Rumo Atribuído (apenas ADEXP)
A.17. Velocidade Atribuída (apenas ADEXP)A.18. Razão de Subida/Descida Atribuída (apenas ADEXP)
A.19. Autorização Directa (apenas ADEXP)
A.20. Pedido de Rota DirectaA.21. Posição (apenas ADEXP)
A.22. Indicação de Autorização (apenas ADEXP)
A.23. FrequênciaA.24. Razão (apenas ADEXP)
A.25. Nível de Voo Autorizado (apenas ADEXP)
A.26. Nível de Voo de Transferência (apenas ADEXP)A.27. Hora de Descolagem Estimada
A.28. Tipo de Mensagem de Referência
A.29. Tipo de voo
A.30. Capacidade e situação do equipamento
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.2000R2082 — PT — 15.06.2002 — 001.001 — 60
▼M1
▼B
▼B
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 TrafficControl (Proc edimentos dos Serviços de Navegação
Aérea — Regras do Ar e do Controlo de Tráfego Aéreo) (Docu-
mento 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.2.a. Por vezes é usado um pseudo-número de tipo de campo ICAO, caso
não exista um campo ICAO adequado. Estes números, formados por
dois dígitos, têm valor igual ou superior a 80.
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 asso-
ciados 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».2000R2082 — PT — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
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, indepen-
dentemente 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».2000R2082 — PT — 15.06.2002 — 001.001 — 62
▼B
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 esti-
mada 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 trans-
ferê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 conhe-
cido, 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; ou2000R2082 — PT — 15.06.2002 — 001.001 — 63
▼B
— um azimute e uma distância a um ponto de referência conhe-
cido, 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 aero-
nave 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 alti-
tude. 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 significa-
tivo).
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. Este campo oferece a possibilidade de incluir em determinadas
mensagens informações do plano de voo normalmente não incluídas
no processo de coordenação e não descritas em qualquer outra parte
do presente anexo. É permitida a inclusão dos seguintes elementos,
como descrito na referência 1, apêndice 2, tipos de campos 8 e 18:
— regras de voo,2000R2082 — PT — 15.06.2002 — 001.001 — 64
▼M1
▼M1
— marcas de registo,
— nome do operador,
— razões para tratamento especial pelo ATS,
— tipo,
— desempenho,
— nome dos aeródromos de partida e de destino e de aeródromos
alternativos,
— observações em texto livre.
A.14.1. ICAO
Tipo de campo 8, elemento a), regras de voo, no formato do tipo de
campo 22.
Um ou vários dos seguintes elementos do tipo de campo 18 no
formato do tipo de campo 22:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Campos primários: «fltru»l, «depz», «destz», «opr», «per», «reg»,
«rmk», «altrnt1»,«altrnt 2», «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 notifi-
caçã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 desconhe-
cida.
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/coorde-
naçã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.2000R2082 — PT — 15.06.2002 — 001.001 — 65
▼B
▼B
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 umarazã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 acor-
dados 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 conhe-
cido, conforme definido na mesma mensagem pelo campo
Primário «REF»;
ou
— o valor «ZZZ» se a unidade emissora não exigir a desig-
naçã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 conhe-
cido, 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 bila-
teralmente, 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.2000R2082 — PT — 15.06.2002 — 001.001 — 66
▼B
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 conhe-
cido;
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 conhe-
cido.
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 conhe-
cido, 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 conhe-
cido, 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.2000R2082 — PT — 15.06.2002 — 001.001 — 67
▼B
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».
A.29.Tipo de voo
Este elemento deve corresponder ao registado no plano de voo ou
em dados equivalentes provenientes de uma fonte alternativa. Deve
escrever-se a letra «X» caso o tipo de voo não conste do plano de
voo ou não seja conhecido por qualquer outra razão.
A.29.1. ICAO
O registo do tipo de voo é feito com uma única letra no formato do
tipo de campo 22 utilizando o pseudo-número de tipo de campo 80.
A.29.2. ADEXP
Campo primário «flttyp».
A.30.Capacidade e situação do equipamento
Este elemento indica a capacidade e situação de equipamento que é
condição para o voo em determinados espaços aéreos ou determi-
nadas rotas ou que tem influência significativa na oferta do serviço
ATC. A presença de uma capacidade está identificada no plano de
voo, mas pode revelar-se incorrecta ou ter mudado durante o voo. A2000R2082 — PT — 15.06.2002 — 001.001 — 68
▼M1
▼M1
capacidade e situação do equipamento indica a situação no
momento.
Será incluída a situação dos seguintes elementos:
— capacidade RVSM,
— equipamento RTF 8.33kHz.
Será incluída a situação dos elementos seguintes para os voos de
Estado, como especificado no tipo de voo do plano de voo, em
relação aos quais se desconheça a presença e possibilidade de utili-
zação de equipamento RTF 8,33 kHz:
— equipamento UHF.
A.30.1. ICAO
Os dados serão inscritos no formato do tipo de campo 22 utilizando
o pseudo-número de campo 81.
Serão inscritos dois elementos para cada capacidade:
— a capacidade do equipamento, expressa com uma única letra,
como especificado no tipo de campo 10 «Equipamento» do
plano de voo ICAO (ver apêndice 3 da referência 1), imediata-
mente seguida de,
— um separador — barra oblíqua (/), imediatamente seguido de,— a situação, expressa com duas letras.
A situação será expressa através dos seguintes indicadores, a utilizar
consoante o voo.
a) EQ indica que o voo está equipado e que o equipamento pode
ser utilizado no voo;
b) NO indica que o voo não está equipado ou que, por qualquer
razão, o equipamento não pode ser utilizado no voo.
c) UN situação de conformidade desconhecida.
O primeiro grupo de capacidade será inscrito imediatamente após a
barra oblíqua que se segue ao número de campo. Os grupos subse-
quentes serão separados por um carácter de espaço. A ordem das
capacidades do equipamento é irrelevante.
A.30.2. ADEXP
Campo primário «EQCST».2000R2082 — PT — 15.06.2002 — 001.001 — 69
▼B
ANEXO B (Normativo)
REQUISITOSDE PROCESSAMENTODE 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 rotadirecta descrito no plano de voo;
— após a transmissão da mensagem ABI ou ACT, o voo é redirec-
cionado 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 ABIe antes da Transmissão da ACT
Será enviada uma nova mensagem ABI com a informação corres-
pondente à 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 acei-
tante 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 coor-
denaçã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;2000R2082 — PT — 15.06.2002 — 001.001 — 70
▼B
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údodos 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 mensa-
gens 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 bila-
teralmente. 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).2000R2082 — PT — 15.06.2002 — 001.001 — 71
▼B
É 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
2000R2082 — PT — 15.06.2002 — 001.001 — 72
▼B
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 atraves-
samento 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)
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.2000R2082 — PT — 15.06.2002 — 001.001 — 73
▼B
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 coorde-
nação EMT. É transmitida a seguinte ACT:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
/FK28/M)
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)
2000R2082 — PT — 15.06.2002 — 001.001 — 74
▼B
O voo é então autorizado para o FL290, originando a seguinte
mensagem (contendo o novo COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
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 DTTA2000R2082 — PT — 15.06.2002 — 001.001 — 75
▼B
ANEXO C (Informativo)
FASES DO PROCEDIMENTO DE DIÁLOGO (NÍVEL 1 DO SYSCO) — SEQUÊNCIA DAS
MENSAGENS
Sequência das Mensagens
2000R2082 — PT — 15.06.2002 — 001.001 — 76
▼B
ANEXO II
APRESENTAÇÃO DO INTERCÂMBIO DE INFORMAÇÃO DOS
SERVIÇOSDE TRÁFEGO AÉREO (ADEXP), EDIÇÃO 2.0
(referência do documento do Eurocontrol DPS.ET1.ST09-STD)2000R2082 — PT — 15.06.2002 — 001.001 — 77
▼B
ÍNDICE
DIREITOS DE AUTOR
PREFÁCIO1. ÂMBITO2. REFERÊNCIAS3. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS
3.1. Notação3.2. Definições3.3. Construção3.4. Convenções3.5. Operadores3.6. Abreviaturas
4. PRÍNCIPIOS DO ADEXP
4.1. Formato Textual, Legível por Pessoas4.2. Campos Identificados e Recuperáveis4.3. Campos Não Reconhecidos
5. REGRAS SINTÁCTICAS DA ADEXP
5.1. Elementos Lexicais5.2. Campos
6. DESCRIÇÃO NORMALIZADA DAS MENSAGENS ADEXP
6.1. Introdução6.2. Termos Auxiliares6.3. Definição dos Campos Primários6.4. Definição dos Subcampos6.5. Grupo de Mensagens
ANEXO A (NORMATIVO) DEFINIÇÕES DOS CAMPOS
ANEXO B (NORMATIVO) ÍNDICE CENTRAL DOS TÍTULOS DAS MENSAGENS ADEXPANEXO C (NORMATIVO) ÍNDICE CENTRAL DOS TÍTULOS DE MENSAGENS RESERVADASANEXO D (NORMATIVO) ÍNDICE CENTRAL DOS CAMPOS RESERVADOSANEXO E (INFORMATIVO) INTRODUÇÃO AOS GRUPOS DE MENSAGENSANEXO F (INFORMATIVO) EXEMPLOS DE FORMATOS DE MENSAGENS ADEXPANEXO G (INFORMATIVO) DESENVOLVIMENTOS FUTUROS2000R2082 — PT — 15.06.2002 — 001.001 — 78
▼B
INFORMAÇÃO RELATIVAAOS 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.2000R2082 — PT — 15.06.2002 — 001.001 — 79
▼B
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 procedi-
mentos 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 alte-
raçõ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 Apresen-
taçã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 Direc-
tivas. As dispensas menores de formatação em relação às
Directivas destinam-se a evitar confusão com a notação da Apre-
sentaçã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;
—O s Elementos Recomendados utilizam o verbo-chave
«deveria» e foram impressos em itálico, sendo a situação indi-
cada 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
Existem 6 Anexos à presente Directiva, cuja situação é definida
seguidamente:
Anexo A Normativo;
Anexo B Normativo;Anexo C Normativo;Anexo D Normativo;Anexo E Informativo;2000R2082 — PT — 15.06.2002 — 001.001 — 80
▼B
Anexo F Informativo;
Anexo G Informativo.
8. Idioma utilizado
No texto original da presente Norma foi utilizada a língua
Inglesa.2000R2082 — PT — 15.06.2002 — 001.001 — 81
▼B
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, essencial-
mente, 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 Inte-
grado de Processamento Inicial de Planos de Voo (IFPS), os
Serviços de Tráfego Aéreo (ATS) e os Operadores de Aero-
naves (AO). (Documento Ref.a3)
— 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.a5)
— 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.a6)
— 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.a7)
— Coordenação Civil / Militar: mensagens relativas a infor-
mação de voo civil/militar e mensagens de cruzamento do
espaço aéreo. (Documento Ref.a7)
1.5. Nos documentos de referência poderão ser encontradas especifi-
caçõ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 Norma-
tivo do Eurocontrol.
As revisões dos outros documentos referenciados não farão parte
das disposições do presente Documento Normativo do Eurocon-
trol 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 utiliza-
dores 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 TrafficServic es» («Regras do Ar e
dos Serviços de Tráfego Aéreo»), Doc. 4444 do PANS-RAC,2000R2082 — PT — 15.06.2002 — 001.001 — 82
▼B
edição de Novembro de 1985 (incluindo a Alteração n.o6, 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çode 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» (Especifi-
caçõ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 sepa-
radores.
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 substi-
tuído por».
2)O «símbolo» é classificado como não-terminal.
3)A parte «expressão» contém símbolos terminais e não-termi-
nais.
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:2000R2082 — PT — 15.06.2002 — 001.001 — 83
▼B
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.
—O s Caracteres e as Sequências de Literais que aparecem nas
regras encontram-se respectivamente entre vírgulas dobradas
(') e aspas ('').
Exemplos1) 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 legal-
mente 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 sequen-
cialmente, mesmo que no meio possam aparecer um ou mais
separadores. Não existe representação explícita desta represen-
taçã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.
Exemplos1) Implícita:
dct::= '-' "DCT" point point
2) Explícita
dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
ex. "-DCT NTM RMS".
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 a::= B C | D é equivalente
a:a::= (B C) | D2000R2082 — PT — 15.06.2002 — 001.001 — 84
▼B
e NÃO a: a::= B (C | D) .
2)Em todas as regras, será deixada implícita a presença autori-
zada 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, reco-
menda-se a utilização de parênteses, para clarificar a ordem de
avaliação desejada.
3.6. Abreviaturas
Para os efeitos do presente Documento Normativo do Eurocon-
trol, aplicar-se-ão as seguintes abreviaturas:
ACH Mensagem de Alteração do Plano de Voo
ATC
ADEG Grupo de Intercâmbio de Informação ATSADEXP Apresentação do Intercâmbio de Infor-
mação ATS
AFIL Plano de Voo Efectuado em VooAFP Proposta de Plano de Voo ATCAFTN Rede de Telecomunicações Fixas Aeronáu-
ticas
ANM Mensagem de Notificação ATFMAO Operador(es) de AeronavesAPL Plano de Voo ATCATC Controlo do Tráfego AéreoATCU Unidade(s) de Controlo do Tráfego AéreoATFM Gestão do Fluxo de Tráfego AéreoATS Serviços de Tráfego Aéreo
BNF Notação Backus Naur
CASA Atribuição de Janelas Assistida por
Computador
CIDIN Rede Comum ICAO de Intercâmbio de
Informação
CFL Nível de Voo AutorizadoCFMU Unidade Central de Gestão de Tráfego
CMTP Plano Comum de Médio Prazo
CNL Mensagem de CancelamentoCTOT Hora Calculada para a Descolagem
DPS Domínio dos Sistemas de Tratamento de
Dados
ECAC Conferência Europeia da Aviação Civil
EFL Nível de Voo EstimadoEOBT Hora Estimada de Saída dos CalçosETO Hora Estimada SobreEUROCONTROL Organização Europeia para a Segurança da
Navegação Aérea
EWPD Documento do Programa de Trabalho do
EATCHIP
FIR Região de Informação de Voo
FIW Estação de Trabalho para Introdução de
Planos de Voo
FMP Posição de Gestão do Tráfego
FNM Mensagem de Notificação de Voo
FPL Mensagem de Plano de Voo (formato
ICAO)
GAT Tráfego Aéreo Geral
IA Alfabeto Internacional
IAFP Proposta de Plano de Voo ATC IndividualICAO Organização da Aviação Civil InternacionalIFPD Informação do Plano de Voo Individual2000R2082 — PT — 15.06.2002 — 001.001 — 85
▼B
IFPS Sistema Integrado de Processamento Inicial
de Planos de Voo
IFPU Unidade de IFPSIFR Regras de Voo por Instrumentos
ISO Organização Internacional de Normalização
ITA Alfabeto Telegráfico Internacional
LAM Mensagem de Confirmação Lógica
LRM Mensagem de Rejeição Lógica
MAC Mensagem de Revogação de Coordenação
MFS Mensagem Proveniente de Shanwick
OAT Tráfego Aéreo Operacional
OLDI Intercâmbio de Informação em Tempo Real
RFL Nível de Voo Solicitado
RFP Plano de Voo Substituto
RFPD Dados sobre Plano de Voo Repetitivo
RPL Plano de Voo RepetitivoRVR Extensão de Pista Visível
SFL Nível de Voo Suplementar
SRD Documento de Requisitos de SoftwareSSR Radar de Vigilância Secundário
TACT Sistema Táctico do CFMU
TOS Plano de Orientação do Tráfego
UIR Região Superior de Informações de VooVFR Regras de Voo Visual
4. PRÍNCIPIOSDO 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, deli-
mitadas 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.2000R2082 — PT — 15.06.2002 — 001.001 — 86
▼B
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 defi-
nido 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 flexibili-
dade, 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 0150000Wem 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
…2000R2082 — PT — 15.06.2002 — 001.001 — 87
▼B
-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, tipi-
camente 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 permi-
tido 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 ::= ' '2000R2082 — PT — 15.06.2002 — 001.001 — 88
▼B
— 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 repre-
senta 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 posi-
tivo. 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á defi-
nido 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ús-
culas 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 valida-
mente um campo)
1) -TITLE IFPL2000R2082 — PT — 15.06.2002 — 001.001 — 89
▼B
2) - TITLE IFPL
3) - TITLE IFPL4) -
TITLE IFPL
5.1.5.3. Recomendação Constitui prática recomendável evitar a utili-
zação de um separador entre o caracter de início de campo «-»
e a palavra-chave subsequente.
NOTA1) Nos exemplos acima, a primeira ocorrência é a escolha reco-
mendada.
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. As palavras-chave do formato ADEXP previamente definidas e
listadas abaixo, não deverão ser redefinidas ou utilizadas com
um significado diferente, em utilizações específicas do formato:
TITLE: identifica uma categoria de mensagens e define
o correspondente conjunto de campos primários
permitidos;
BEGIN: identifica o início de um campo de lista;
END: identifica o fim de um campo de lista;
COMMENT: identifica um campo COMENTÁRIO.
5.1.5.7. Por forma a evitar ambiguidades (utilização dupla de uma mesma
palavra-chave com significados diferentes) ou redundâncias (pala-
vras-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 Defi-
niçã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 valoresvalores::= {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.2000R2082 — PT — 15.06.2002 — 001.001 — 90
▼B
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.
Regraexemplificativa 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:2000R2082 — PT — 15.06.2002 — 001.001 — 91
▼B
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 opcio-
nalmente 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ÇÃONORMALIZADADAS MENSAGENSADEXP
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 catego-
rias 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 indi-
vidual;
— 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 (Espe-
cificaçã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 defi-
nidos 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 categorias2000R2082 — PT — 15.06.2002 — 001.001 — 92
▼B
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 especifi-
cados na descrição da sua semântica.
6.1.8. No Anexo D estabelece-se uma lista central de campos reser-
vados. 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 nacio-
nais. O objectivo da sua inclusão na presente Norma é ajudar a
garantir a singularidade dos títulos dos campos e evitar redundân-
cias 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 auxi-
liar «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. A descrição pode ser apresentada numa tabela como a seguinte, ordenada por ordem
alfabética:
Termo
AuxiliarSintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
SubcampoUtili-
zado
no
Auxi-
liar
adexpmsg { CHARACTER } Texto livre em
conformidade
com a sintaxe
descrita para
uma mensagem
ADEXPifpdlong
rfpdlongpreproctxt
postproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipamento
de radiocomu-
nicações, de
navegação e de
ajuda à aproxi-
mação.ceqpt
aircraftid 1{ ALPHANUM
}7Identificação
da Aeronave.arcid
arcidkarcidold
prevarcid
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.2000R2082 — PT — 15.06.2002 — 001.001 — 93
▼B
6.3.4. A descrição pode ser apresentada como na tabela seguinte, ordenada alfabeticamente,
em que:
— a primeira coluna representa o membro esquerdo de uma regra BNF (ou seja, o
membro da regra no lado esquerdo do símbolo «::=») e a terceira coluna representa
o seu membro direito.
— A segunda coluna (Tipo) indica se um campo é básico («b») ou composto («c»).
Campo Primário Tipo Sintaxe Semântica
eobt b '-' "EOBT" timehhmm Hora Estimada de Saída dos
Calços
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. A descrição pode ser apresentada como na tabela seguinte, ordenada alfabeticamente:
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado
no
Subca-
mpo
brng b '-' "BRNG"
refbearingRumo de um
ponto relativa-
mente a uma
ajuda à nave-
gação (em graus
magnéticos)ref
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 à docu-
mentaçã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 mensa-
gens 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 mensa-
gens e evitar redundâncias desnecessárias.2000R2082 — PT — 15.06.2002 — 001.001 — 94
▼B
ANEXO A (Normativo)
DEFINIÇÕES DOS CAMPOS ADEXP
A.1.Introdução
O presente Anexo fornece uma lista de todos os campos; Termos Auxi-
liares; Campos Primários e Subcampos que foram definidos para
utilização na ADEXP.
A.2.Termos Auxiliares ADEXP
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
adexpmsg { CARACTER } Texto livre em
conformidade com a
sintaxe descrita para
uma mensagem
ADEXPifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipamento de
radiocomunicações,
de navegação e de
ajuda à aproxi-
mação.ceqpt
aircraftid 2{ ALFANUM }7 Identificação da
Aeronavearcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALFANUM | '+'
| '?' }7Forma universal de
aircraftid a utilizar
em mensagens de
Consulta:
«?» substitui um
caracter
«+» substitui qual-
quer número de
caracteres.arcidk
atsroute 2 {ALFANUM} 7 O designador de
uma rota ATS.atsrt refatsrte
century 2{ALGARISMO}2 Os dois primeiros
algarismos de um
século.fulldate
coorstatusident 3 {ALFA} 3 Um indicador da
situação de coorde-
nação de um voo.statid
coorstatus-
reason3 {ALFA} 7 A razão para a noti-
ficação de uma
alteração na
situação de coorde-
nação.statreas-
on
country 2{ALFA}2 O designador de
duas letras ICAO,
para um país.refatsrte
datalink 1 {'S' | 'H' | 'V' | 'M'
}4O designador ICAO
da capacidade de
transmissão de
dados. Pode conter
qualquer um dos
valores: S, H, V ou
M em qualquer
ordem mas sem se
repetirem.dat2000R2082 — PT — 15.06.2002 — 001.001 — 95
▼B
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
date Ano ! mês ! dia Uma indicação da
data no formato
AAMMDD.
Exemplo:
930424 = 24 de
Abril de 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstday
neweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime Data ! horahhmm Um termo «data»
como acima
descrito e imediata-
mente seguido da
hora no formato
HHMM. Exemplo:
9304240930=0930Z
em 24 de Abril de
1993.origindt
datewldcrd 1{ ALGARISMO |
'+' | '?' )6Um termo «data»
que pode ser
universal.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
ALGARISMOUm número de dois
algarismos que pode
conter os algarismos
de 00 a 31.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicador do tipo de
equipamento de
rádio de emergência
a bordo da aero-
nave. Pode ser um
ou mais dos carac-
teres definidos por
qualquer ordem,
mas sem repetições.splr
equipmentcode 1 {('A' | 'B' | 'C' | 'D'
| 'E' | 'F' | 'G' | 'H' |
'I' | 'J' | 'K' | 'L' | 'M'
| 'O' | 'P' | 'Q' | 'R' |
'T' | 'U' | 'V' | 'W' |
'X' | 'Y' | 'Z' )} 24Uma letra válida do
código ICAO para
indicar o equipa-
mento transportado.
Pode ser um ou
mais dos caracteres
definidos por qual-
quer ordem, mas
sem repetições.aidequip-
ment
eqptcode 1 {ALPHANUM} 2 Código que identi-
fica uma capacidade
do equipamento.
Pode ser idêntico ao
equipmentcodeeqpt
eqptstatus 2 {ALPHA} 2 Valor constituído
por duas letras que
indica a situação no
que se refere à
capacidade da aero-
naveeqpt2000R2082 — PT — 15.06.2002 — 001.001 — 96
▼M1
▼B
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
errorcode 1{ALGARISMO}4 Número do código
da mensagem de
erro.error
fieldid 1{ ALFANUM } Nome de campo
ADEXP válido (ou
seja, palavra-chave)errfield
ifpsmod
firindicator 4{ ALFA }4 Um designador
ICAO de uma FIR.eetfir
flightlevel ('F' | 'A') ! 3{
ALGARISMO }3 |
('S' | 'M') ! 4{
ALGARISMO } 4Um nível de voo
expresso como:
«F» ou «A» seguido
de três algarismos
ou,
«S» ou «M»
seguido de quatro
algarismos.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'A razão para trata-
mento especial, tal
como indicado no
elemento «STS/» do
Campo 18,
EMER =
Emergência
HUM = Voo
Humanitário
HOSP = Voo
Hospitalar
SAR = Busca e
Salvamento
HEAD = Chefe de
Estado
STATE = Voo de
Estadosts
flightrule 'I' | 'V' | 'Y' | 'Z' O indicador da
regra de voo de um
voo.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'O tipo de voo tal
como indicado pelo
designador ICAO
utilizado.flttyp
flighttypechg 'OAT' | 'GAT' A indicação dada na
rota de voo de uma
alteração no tipo de
voo para «OAT» ou
«GAT»chgrul ptrulchg
fulldate século ! ano ! mês !
diaUma indicação da
data no formato
SSAAMMDD
ex. 19970801 = 1
de Agosto de 1997.fulldate-
time
fulldatetime data por extenso !
horahhmmUma data, tal como
descrita em «full-
date», imediata-
mente seguida da
hora no formato
HHMM
ex.
199708010930 = 09-
30 horas em 1 de
Agosto de 1997.mesval-
period
geoname "GEO" ! 2{ALGA-
RISMO}2A identificação
dada a uma posição
geográfica expressa
em latitude e longi-
tude.geoid2000R2082 — PT — 15.06.2002 — 001.001 — 97
▼B
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
heading 3{ALGARISMO}3 Um número de três
algarismos no inter-
valo de 001 a 360.ahead
icaoaerodrome 4{ ALFA }4 Designador ICAO,
de quatro letras,
identificador de um
aeródromo.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
icaoaerodro-
mewldcrd1{ ALFA | '+' | '?'
}4Forma universal de
icaoaerodrome, para
utilização em
mensagens de
Consulta:
«?» substitui um
caracter
«+» substitui qual-
quer número de
caracteresadepk
adesk
icaoaircrafttype ALFA ! 1{
ALFANUM }3Designador ICAO
de um tipo de aero-
nave.arctyp
icaomsg { CARACTER } Uma mensagem
ICAO (em confor-
midade com a
sintaxe descrita na
Ref. {4}).msgtxt
ifpuid 1{ ALFANUM } O identificador de
uma Unidade IFPS.ifpuresp
latitudelong 6{ ALGARISMO
}6Uma latitude
expressa com seis
algarismos.lattd
latitudeside 'N' | 'S' Um indicador para
latitude «Norte» ou
«Sul»lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4O indicador ICAO
do tipo de coletes
salva-vidas trans-portados. Pode ser
um ou mais dos
caracteres definidos
por qualquer ordem,
mas sem repetições.splj
longitudelong 7{ ALGARISMO
}7Uma longitude
expressa com sete
algarismos.longtd
longitudeside 'E' | 'W' Um indicador para
longitude «Este» ou
«Oeste».longtd
machnumber 'M' ! 3{ ALGA-
RISMO }3O número de Mach. mach
aspeedcrmach
ptmach
modifind 1{ALFANUM} Indicação do tipo de
modificação efec-
tuada a um campo.Ifpsmod
month ('0' | '1' ) ! ALGA-
RISMOMês, expresso como
um número de dois
algarismos.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Indicação dos dias
da semana em que
um RPL está activo.Days
daysk
daysold2000R2082 — PT — 15.06.2002 — 001.001 — 98
▼B
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
numdayswldcrd 1{ ALGARISMO |
'+' | '?' }7Indicação dos dias
da semana em que
um RPL está activo.
Podem também ser
utilizados caracteres
universais.Daysk
originatorid 1{ ALFANUM }10 Identificador do
remetente de uma
mensagem.Orgnid
qrorgn
point 2{ ALFANUM }5 Designador de um
ponto significativo.
Pode ser um ponto
publicado, um ponto
geográfico, um
ponto de referência
ou um ponto dado
artificialmente,
como um ponto
«redesignado»
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ ALGARISMO
}3Valor do Rumo de
Referênciabrng
refname "REF" ! 2{ALGA-
RISMO}2O identificador atri-
buído a um ponto
identificado através
do rumo e da
distância relativa-
mente a um ponto
publicadorefid
regulid 1{ ALFANUM }20 A identificação de
um regulamento
ATFM relativo a
um voo.regul regid
renameid "REN" ! 2{ALGA-
RISMO}2Identificador de um
ponto redesignado.renid
rrteid 1{ALFANUM} 20 O identificador de
uma nova rota.rrteref
rtf 6{ALGARISMO}6 Uma frequência de
rádio expressa em
MHz com três casas
decimais.freq
rulechg 'VFR' | 'IFR' Os indicadores utili-
zados numa rota de
um voo para indicar
uma alteração das
regras de voo.chgrul ptrulchg
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! ALGA-
RISMOSegundos.
Dois algarismos de
«00» a «59».eto
sto
spd ('K' | 'N') ! 4{
ALGARISMO }4Velocidade.
Expressa em «k» ou
em «N», seguidos
de quatro alga-
rismos.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALFA} 2 Designador ICAO
de um equipamento
SSR transportado e,
em opção, indicação
de uma capacidade
de transmissão de
dados.seqpt2000R2082 — PT — 15.06.2002 — 001.001 — 99
▼B
Termo Auxiliar Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcam-
poUsado no
Auxiliar
stayidentifier 'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Designador de um
período de
«permanência»,
período de «activi-
dade especial» na
rota de um voo.ptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4Designador ICAO
do equipamento de
sobrevivência trans-
portado. Pode ser
um ou mais dos
caracteres definidos
por qualquer ordem,
mas sem repetições.spls
text20 1{ LIM_CHAR }20 Texto constituído de
1 a 20 caracteres,
excluindo o hífen.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
ALGARISMO ! ( '0'
| '1' | '2' | '3' | '4' | '5'
) ! ALGARISMOTempo, expresso
em horas (2 alga-
rismos 00-23) e
minutos (2 alga-
rismos 00-59). Pode
ser a hora do dia ou
um período de
tempo.aobt
ata
atd
atot
cobt
ctot
delay
endtime
eobt
eobtk
eobtold
etot
filtim
iobt
minli-
neup
newctot
neweobt
newptot
ptot
rejctot
respby
starttime
taxitimecto
endreg
eto
from
ptstay
startreg
sto
time
to
untildatetime
fulldate-
time
timehhmm_e-
lapsedALGARISMO !
ALGARISMO ! ('0'
| '1' | '2' | '3' | '4' | '5'
) ! ALGARISMOUm número ilimi-
tado de horas e
minutos, utilizado
para períodos de
tempo.ttleet
eetfir
eetpt
sple
timewldcrd 1{ ALGARISMO |
'+' | '?' }4Forma universal de
timehhmm.eobtk
titleid 1{ ALFA }10 Um título válido de
uma mensagem
ADEXP. (ver
Anexo B)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' O designador ICAO
da categoria da
turbulência da
esteira.wktrc
year 2{ ALGARISMO
}2Os dois últimos
algarismos de um
ano.date
fulldate2000R2082 — PT — 15.06.2002 — 001.001 — 100
▼B
A.3.Campos primários ADEXP
Campo
Primário
AdexpTipo Sintaxe Semântica
ad c'-' "AD" adid [(fl | flbloc k)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Designador de um aeródromo. Nos
casos em que o aeródromo faça
parte da descrição da rota, pode ser
fornecida informação adicional
sobre a rota.
ada b '-' "ADA" date Data efectiva de chegada.
adarr b '-' "ADARR" (icaoaerodrome |
'ZZZZ')Aeródromo efectivo de chegada.
adarrz b '-' "ADARRZ" text20 Nome do aeródromo efectivo de
chegada se não existir indicador de
localização ICAO.
add b '-' "ADD" data Data efectiva de partida.
addr c'-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Lista de destinatários
adep b '-' "ADEP" (icaoaerodrome |
'AFIL' | 'ZZZZ')Indicador de localização ICAO do
aeródromo de partida ou a indi-
cação «AFIL» significando um
plano de voo efectuado em voo ou
«ZZZZ» quando não estiver atri-
buído qualquer indicador de locali-
zação ICAO ao aeródromo de
partida.
adepk b '-' "ADEPK" (icaoaerodrome |
'AFIL' | 'ZZZZ' | icaoaerodro-
mewldcrd)Aeródromo de partida utilizado
como chave de uma base de dados
numa consulta, podendo ser utili-
zados caracteres universais.
Pode conter um indicador de loca-
lização ICAO ou a indicação
«AFIL» significando um plano de
voo efectuado em voo ou «ZZZZ»
quando não estiver atribuído qual-
quer indicador de localização
ICAO ao aeródromo de partida ou
uma combinação de caracteres
alfabéticos e universais.
adepold b '-' "ADEPOLD" (icaoaerodrome |
'AFIL' | 'ZZZZ')O «anterior» aeródromo de partida.
Pode conter o indicador de locali-
zação ICAO ou a indicação
«AFIL» significando um plano de
voo efectuado em voo ou «ZZZZ»
quando não estiver atribuído qual-
quer indicador de localização
ICAO ao aeródromo de partida.
ades b '-' "ADES" (icaoaerodrome |
'ZZZZ')O indicador de localização ICAO
do aeródromo de destino ou
«ZZZZ» quando não estiver atri-
buído qualquer indicador de locali-
zação ICAO ao aeródromo de
destino.
adesk b '-' "ADESK" (icaoaerodrome |
'ZZZZ' | icaoaerodromewldcrd)O aeródromo de destino utilizado
como chave da base de dados numa
consulta, podendo ser utilizados
caracteres universais.
Pode conter um indicador de loca-
lização ICAO ou «ZZZZ» quando
não estiver atribuído qualquer indi-
cador de localização ICAO ao
aeródromo de destino ou uma
combinação de caracteres alfabé-
ticos e caracteres universais.2000R2082 — PT — 15.06.2002 — 001.001 — 101
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
adesold b '-' "ADESOLD" (icaoaerodrome |
'ZZZZ')O «anterior» aeródromo de destino.
Pode conter o indicador de locali-
zação ICAO ou «ZZZZ» quando
não estiver atribuído qualquer indi-
cador de localização ICAO ao
aeródromo de destino.
adexptxt c'-' "ADEXPTXT" (preproc txt |
postproctxt)Contém uma mensagem ADEXP.
afildata c'-' "AFILDATA" ptid fl eto Dados estimados para um plano de
voo efectuado em voo. A identifi-
cação de um ponto, o nível de voo
da junção e a data-hora estimada
no ponto.
NOTA: O nível de voo indicado é
o nível para o qual o voo foi auto-
rizado a entrar em espaço aéreo
controlado sobre o ponto indicado.
Não necessita de ser o mesmo que
o RFL.
ahead b '-' "AHEAD" (rumo | "ZZZ") O rumo atribuído a um voo,
expresso em graus. Tem de ser um
número de três algarismos ou
«ZZZ» indicando que não foi atri-
buído qualquer rumo.
altnz b '-' "ALTNZ" texto20 Nome do aeródromo alternante se
não existir localização ICAO.
altrnt1 b '-' "ALTRNT1" (icaoaerodrome |
'ZZZZ')O indicador de localização ICAO
do primeiro aeródromo alternante
de destino ou o indicador «ZZZ»
quando não estiver atribuído qual-
quer indicador de localização
ICAO ao aeródromo.
altrnt2 b '-' "ALTRNT2" (icaoaerodrome |
'ZZZZ')O indicador de localização ICAO
do segundo aeródromo alternante
de destino ou o indicador «ZZZ»
quando não estiver atribuído qual-
quer indicador de localização
ICAO ao aeródromo.
aobd b '-' "AOBD" data Data Efectiva de Saída dos Calços.aobt b '-' "AOBT" horahhmm Hora Efectiva de Saída dos Calços.arcid b '-' "ARCID" aircraftid Identificação da Aeronave.
Pode ser o número de registo da
aeronave, ou o designador ICAO
do operador da aeronave seguido
pelo identificador do voo.
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Identificação da Aeronave utilizada
como chave da base de dados numa
consulta; podem ser utilizados
caracteres universais. Deve ser uma
combinação de caracteres alfanu-
méricos e de caracteres universais
até um máximo de sete caracteres
no total.
arcidold b '-' ARCIDOLD aircraftid A identificação «anterior» da aero-
nave. Sempre que a identificação
da aeronave seja alterada, o novo
valor será indicado em «ARCID»
arctyp b '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")Tipo de aeronave (identificação
ICAO do tipo) ou ZZZZ.2000R2082 — PT — 15.06.2002 — 001.001 — 102
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
aspeed b '-' "ASPEED" (spd | machnumber |
"ZZZ")A velocidade do voo actualmente
atribuída, em quilómetros por hora,
nós ou número de Mach.
Terá de ser um «M» seguido de
três algarismos, «K» ou «N»
seguidos de quatro algarismos ou
«ZZZ» indicando não estar atri-
buída qualquer restrição de veloci-
dade.
ata b '-' "ATA" timehhmm Hora efectiva de chegada.
atd b '-' "ATD" timehhmm Hora efectiva de partida.atot b '-' "ATOT" timehhmm Hora efectiva de descolagem.atsrt b '-' "ATSRT" atsroute point point Designador ATS da rota e identifi-
cadores do primeiro e do último
ponto.
cassaddr c '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Destinatários aos quais as mensa-
gens ATFM devem ser ende-
reçadas.
ceqpt b '-' "CEQPT" aidequipment Equipamento de radiocomuni-
cações, de navegação e de ajuda à
aproximação (tal como no campo
10 da ICAO).
cfl c '-' "CFL" fl [ptid] Nível de Voo Autorizado. O nível
de voo actualmente atribuído pelo
ATC ao piloto (número do nível de
voo).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointIndicação de uma alteração nas
«regras de voo» (VFR/IFR) ou no
«tipo de voo» (OAT/GAT), ou em
ambas, juntamente com o ponto no
qual ocorre a alteração.
cobd b '-' "COBD" date Data Calculada de Saída dos
Calços.
cobt b '-' "COBT" timehhmm Hora Calculada de Saída dos
Calços.
com b '-' "COM" text20 Equipamento de comunicações (tal
como em COM/ do campo 18 da
ICAO).
comment b '-' "COMMENT" 1 { LIM_CHAR
}Um comentário genérico em texto
livre sem hífen.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Identificação de uma «condição
especial» em relevo no contexto da
ATFM.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]As condições de transferência de
um voo. A identificação de um
ponto, o nível de voo e a hora esti-
mada nesse ponto, bem como
informação suplementar opcional
sobre o nível de voo.
cop b '-' "COP" point O identificador de um ponto de
coordenação, seja o designador
codificado de um ponto ou um
nome dado artificialmente (GEOxx,
RENxx ou REFxx).
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Indicação de uma subida de
cruzeiro. Dando o ponto em que a
subida terá início, a velocidade ou
on .
ode Mach e os dois níveis
indicadores da faixa de níveis de
voo ocupada durante a subida. O
segundo nível pode ser «PLUS»
quando o nível superior for desco-
nhecido.2000R2082 — PT — 15.06.2002 — 001.001 — 103
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
cstat c '-' "CSTAT" statid [statreason] Um indicador confirmando a nova
situação de coordenação de um voo
e, opcionalmente, a razão para a
alteração.
ctod b '-' "CTOD" date Data Calculada de Descolagem.ctot b '-' "CTOT" timehhmm Hora Calculada de Descolagem
(CTOT): hora de referência de uma
janela ATFM.
dat b '-' "DAT" datalink Indicação da capacidade de trans-
missão de dados da aeronave.
days b '-' "DAYS" numdays Dias de operação para um plano de
voo repetitivo (1234567 em que 1 é
Segunda-feira, 2 Terça, …, com 0
nas colunas de não operação).
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Dias de operação para um plano de
voo repetitivo, usado como chave
da base de dados numa mensagem
de consulta, podendo ser utilizados
caracteres universais.
daysold b '-' "DAYSOLD" numdays Os dias de operação «anteriores».
Usado como uma chave da base de
dados. Quando os dias de operação
de um RPL tiverem de ser alte-
rados, os novos valores serão dados
em «DAYS».
dct b '-' "DCT" point point Indica uma rota directa entre dois
pontos. Os pontos podem ser
designadores ICAO válidos de um
ponto ou um ponto que apareça no
campo GEO, REN ou REF dos
formatos GEOxx, RENxx ou
REFxx.
delay b '-' "DELAY" timehhmm Um período de tempo representa-
tivo de um atraso. A natureza do
atraso, ou seja, atraso de um voo,
atraso de processamento, etc.
depende do seu contexto.
depz b '-' "DEPZ" text20 Nome do aeródromo de partida, se
não existir nenhum indicador de
localização ICAO.
desc b '-' "DESC" 1 {LIM_CHAR} Descrição de uma condição ou
entidade que seja relevante para o
conteúdo da mensagem.
destz b '-' "DESTZ" text20 Nome do aeródromo de destino, se
não existir nenhum indicador de
localização ICAO.
eetfir b '-' "EETFIR" firindicator
timehhmm_elapsedIdentificação da FIR e o tempo
decorrido acumulado (em horas e
minutos) até à fronteira da FIR.
eetlat c '-' "EETLAT" lattd time Indicação de um tempo decorrido
até uma posição dada apenas pela
latitude.
eetlong c '-' "EETLONG" longtd time Indicação de um tempo decorrido
até uma posição dada apenas pela
longitude.
eetpt b '-' "EETPT" point timehhmm_e-
lapsedIdentificador do ponto e o tempo
decorrido acumulado até ao ponto.
endtime b '-' "ENDTIME" day ! timehhmm O instante em que termina um
período de tempo.2000R2082 — PT — 15.06.2002 — 001.001 — 104
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
entrydata c'-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]Informação do plano de voo
aplicável a um voo no ponto atri-
buído ou na entrada do voo no
espaço aéreo aplicável. Os campos
«ptid» e «airspdes», ou um deles,
têm de estar presentes.
eobd b '-' "EOBD" date Data Estimada de Saída dos
Calços.
eobdk b '-' "EOBDK" date Data Estimada de Saída dos Calços
utilizada como chave da base de
dados numa consulta, podendo ser
utilizados caracteres universais.
Tem de ser uma combinação de
algarismos e de caracteres univer-
sais, até um máximo de 6 carac-
teres no total.
eobdold b '-' "EOBDOLD" date A «anterior» data estimada de saída
dos calços. Usado como uma chave
da base de dados. Quando a data
estimada de saída dos calços tiver
de ser alterada, o novo valor será
dado em «EOBD».
eobt b '-' "EOBT" timehhmm Hora Estimada de Saída dos Calços
(EOBT)
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Hora Estimada de Saída dos
Calços, utilizada como chave da
base de dados numa consulta,
podendo ser utilizados caracteres
universais.
eobtold b '-' "EOBTOLD" timehhmm A «anterior» hora estimada de
saída dos calços. Utilizada como
uma chave da base de dados.
Quando a hora estimada de saída
dos calços tiver de ser alterada, o
novo valor será dado em «EOBT».
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Lista dos códigos de capacidade do
equipamento, sendo cada um deles
seguido de um valor que indica a
situação da capacidade nesse
momento
errfield b '-' "ERRFIELD" fieldid Nomenclatura ADEXP para
campo(s) erróneo(s).
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Texto da mensagem de erro. Pode
conter, opcionalmente, um código
de identificação de erro.
estdata c'-' "ESTDATA" ptid eto fl [sfl] Informação estimada. Uma identi-
ficação de um ponto, o nível de
voo estimado (número do nível de
voo) e a data-hora estimada neste
ponto seguida opcionalmente pelo
nível de voo suplementar (número
do nível de voo seguido do indi-
cador A ou B).
etod b '-' "ETOD" date Data Estimada de Descolagem.
etot b '-' "ETOT timehhmm Hora Estimada de Descolagem.
extaddr c'-'"EXTADDR" num | { fac } |
(num {fac})Endereços fornecidos em adição
aos determinados automaticamente,
ou seja, «endereços extra». Pode
conter apenas o número de ende-
reços ou os próprios endereços ou
ambos.
filrte b '-' "FILRTE" {LIM_CHAR} A rota tal como preenchida, ou
seja, sem qualquer processamento.2000R2082 — PT — 15.06.2002 — 001.001 — 105
▼M1
▼B
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
filtim b '-' "FILTIM" day ! timehhmm Grupo data-hora especificando
quando a mensagem foi preenchida
para transmissão.
flband c'-' "FLBAND" fl fl Uma faixa de níveis de voo defi-
nindo verticalmente o espaço aéreo,
incluindo os níveis de voo dados.
fltrul b '-' "FLTRUL" flightrule Regra de voo, tal como no campo 8
da ICAO.
flttyp b '-' "FLTTYP" flighttype Tipo de voo, tal como no campo 8
da ICAO.
fmp b '-' "FMP" 4{ ALFA }4 Identificador de uma «Posição de
Gestão de Tráfego».
fmplist c'-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Lista de FMPs e dos seus regula-
mentos ATFM associados.
freq b '-' "FREQ" rtf Radiofrequência.
fstday b '-' "FSTDAY" date Primeiro dia de operação para um
plano de voo repetitivo. É utilizado
para fornecer o primeiro dia efec-
tivo em que os planos de voo serão
gerados a partir de um RPL (ver
campo valfrom) ou o primeiro dia
em que uma alteração a um RPL se
torna efectiva.
furthrte b '-' "FURTHRTE" {LIM_CHAR} A rota subsequente de um voo.
Para utilização em mensagens
contendo informação estimada para
indicar a rota subsequente do voo a
seguir ao ponto estimado. Pode
conter apenas o próximo ponto ou
a rota completa subsequente até ao
destino.
geo c'-' "GEO" geoid lattd longtd Ponto pertenc ente à rota definido
pela latitude e longitude e forne-
cido no plano de voo, tal como
GEOxx (em que xx é um número
sequencial).
ifp b '-' "IFP" 1{ALFA} Indicação dos erros conhecidos
num FPL.
ifpdlist c'-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Lista de todos os IFPD que
condizem com a chave da base de
dados dada na mensagem de
consulta. Contém uma lista de
informações completas para cada
voo individual que corresponde às
chaves de consulta dadas.
ifpdslist c'-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Lista de ifpdsum correspondentes à
chave da base de dados dada numa
mensagem de consulta. Contém
uma lista de informações sumárias
para cada voo individual que
corresponde às chaves de consulta
dadas.
ifplid b '-' "IFPLID" ALFA ALFA {
ALGARISMO }8Um identificador único do plano de
voo, atribuído pelo IFPS.
ifpsmod b '-' "IFPSMOD" fieldid modifind Uma indicação dada pelo IFPS dos
campos que foram modificados,
bem como a natureza da modifi-
cação.
ifpuresp b '-' "IFPURESP" ifpuid Identificador do IFPU responsável
por uma consulta. Tem de
processar a consulta e dar a
resposta.2000R2082 — PT — 15.06.2002 — 001.001 — 106
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
ignore c'-' "BEGIN" "IGNORE" {
(condição | condição ptid ptid) }'-'
"END" "IGNORE"Indicação das condições que foram
«ignoradas» ou omitidas no
processamento da mensagem em
causa. Uma condição «ignorada»
pode ser limitada a uma porção
específica da rota delimitada pelos
pontos da rota dados. Uma
condição poderá, por exemplo, ser
uma restrição temporal (condição
de acesso à rota), uma restrição do
nível de voo ou uma violação do
TOS.
iobd b '-' "IOBD" date A Data «Inicial» de Saída dos
Calços: «a data de saída dos
calços», tal como indicada no FPL
e actualizada pelas mensagens
associadas ao plano de voo (DLA,
CHG, etc.). Esta é a data de
referência utilizada para aceder ao
plano de voo na base de dados
sendo a única «data de saída dos
calços» conhecida pelas unidades
ATS envolvidas.
Nota: O IOBD não é afectado pelas
alterações solicitadas ou notificadas
através da permuta de mensagens
de ATFM.
iobt b '-' "IOBT" timehhmm A Hora «Inicial» De Saída dos
Calços:- «a hora de saída dos
calços», tal como indicada no FPL
e actualizada pelas mensagens
associadas ao plano de voo (DLA,
CHG, etc.). Esta é a hora de
referência utilizada para aceder ao
plano de voo na base de dados,
sendo a única «hora de saída dos
calços» conhecida pelas unidades
ATS envolvidas.
Nota: O IOBT não é afectado pelas
alterações solicitadas ou notificadas
através da permuta de mensagens
de ATFM.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Lista de Rotas Condicionais
Activas.
latsa c'-' "BEGIN" "LATSA" { airspac e
} '-' "END" "LATSA"Lista de Áreas Activas Tempora-
riamente Isoladas.
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Lista de Rotas ATS Fechadas
lfir c'-' "BEGIN" "LFIR" 1{ fir ( lac dr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
-' "END" "LFIR"Lista de FIR, incluindo o nome da
região seguido pela lista das Rotas
Condicionais Disponíveis ou pelas
listas de Rotas Condicionais
Disponíveis, Rotas ATS Fechadas,
Áreas Activas Temporariamente
Isoladas, Restrições de Espaço
Aéreo Reduzido e Espaços Aéreos
de Coordenação Reduzidos.
lrar c'-' "BEGIN" "LRAR" { airspac e }
'-' "END" "LRAR"Lista de Restrições de Espaço
Aéreo Reduzido.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Lista de Espaços Aéreos de Coor-
denação Reduzidos.2000R2082 — PT — 15.06.2002 — 001.001 — 107
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
lstday b '-' "LSTDAY" date Último dia de operação para um
plano de voo repetitivo. Usado para
indicar o ultimo dia efectivo a
partir do qual os planos de voo
serão gerados por uma RPL (ver o
campo valuntil) ou o último dia no
qual uma alteração a uma RPL se
torna efectiva.
=> Tem de ser uma data entre
VALFROM e VALUNTIL.
mach b '-' "MACH" machnumber [ point ] Número de Mach, em centésimos
da unidade e opcionalmente, o
ponto no qual é pedida a alteração.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimePeríodo de validade de uma
mensagem, incluindo os tempos
dados.
minlineup b '-' "MINLINEUP" timehhmm O tempo mínimo necessário que
um voo, declarado pronto para a
partida, demora desde a sua
posição de espera actual até se
encontrar no ar.
modifnb b '-' "MODIFNB" 1{ ALGARISMO
}3Número de modificações que foram
necessárias para corrigir uma
mensagem original.
msgref c'-' "MSGREF" sender rec vr
seqnumInformação de referência para
mensagens associadas previamente
transmitidas.
msgsum c'-' "BEGIN" "MSGSUM" { [arc id]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Contém um sumário de uma
mensagem.
Nota: Tem de conter um ou mais*
dos campos arcid, adep, ades, eobt
e orgn, mas sem repetições.
* um ou mais campos podem faltar
ou estarem truncados na mensagem
recebida.
msgtxt b '-' "MSGTXT" icaomsg Contém uma mensagem ICAO
completa.
msgtyp b '-' "MSGTYP" titleid Contém o título da mensagem refe-
rida ou copiada. Pode ser qualquer
título válido de uma mensagem
ADEXP (ver Anexo B).
nav b '-' "NAV" text20 Equipamento de navegação signifi-
cativo, tal como em NAV/ do
campo 18 da ICAO.
nbarcb '-' "NBARC" 1{ ALGARISMO }2 Número de aeronaves, se existir
mais de uma.
nbrfpd b '-' "NBRFPD" 1{ ALGARISMO
}3Número de informações de um
plano de voo que satisfazem uma
consulta. Tem de situar-se entre 0 e
999.
newctot b '-' "NEWCTOT" timehhmm Uma nova Hora Calculada para a
Descolagem, conforme actualizada
pelo TACT.
newend-
timeb '-' "NEWENDTIME" day !
timehhmmUm novo instante em que termina
um período de tempo.
neweobd b '-' "NEWEOBD" date Uma nova Data Estimada de Saída
dos Calços.
neweobt b '-' "NEWEOBT" timehhmm Uma nova Hora Estimada de Saída
dos Calços.
Newptot b '-' "NEWPTOT" timehhmm Uma nova Hora Provisória de
Descolagem.2000R2082 — PT — 15.06.2002 — 001.001 — 108
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
newrte b '-' "NEWRTE" { LIM_CHAR } Uma nova rota entre os mesmos
aeródromos de partida e de
chegada, conforme especificado na
mensagem original.
newstart-
timeb -' "NEWSTARTTIME" day !
timehhmmUm novo instante em que começa
um período de tempo.
oldmsg b '-' "OLDMSG" { CARACTER } Uma mensagem original completa,
exactamente (e com o mesmo
formato) como foi recebida.
opr b '-' "OPR" 1 { LIM_CHAR } Nome da companhia ou da agência
que opera o voo, tal como no
elemento OPR/ do Campo 18 da
ICAO.
orgmsg b '-' "ORGMSG" titleid O Título ADEXP de uma
mensagem errónea, tal como foi
recebida pelo TACT.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Endereço do remetente da
mensagem.
orgnid b '-' "ORGNID" originatorid O designador de um destinatário
que originou uma mensagem.
orgrte b '-' "ORGRTE" { LIM_CHAR } Rota original entre os aeródromos
de partida e de chegada.
origin c'-' "ORIGIN" networktype | fac |
(networktype fac)Informação relativa ao remetente
de uma mensagem. Pode incluir o
tipo de rede utilizada ou o endereço
aplicável ou ambos.
origindt b '-' "ORIGINDT" datetime Data e hora de recepção da
mensagem original pelo IFPS.
Nota: Esta não é a hora de depósito
da mensagem. O formato é
AAMMDDHHMM.
part c'-' "PART" num lastnum Identific ação da parte da
mensagem identificada pelo título,
hora de depósito e período de vali-
dade.
per b '-' "PER" text20 Informação de desempenho da
aeronave, tal como em PER/ do
campo 18 da ICAO.
position c'-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]A posição de uma aeronave dada
ou por um ponto ou por um aeró-
dromo, com hora opcional e infor-
mação do nível de voo.
prevarcid b '-' "PREVARCID" aircraftid O indicador de chamada utilizado
previamente.
prevssrcode b '-' "PREVSSRCODE" ALFA ! 4{
'0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' }4Modo e Código SSR utilizado pelo
voo imediatamente antes do Modo
e do Código SSR dado no campo
«-SSRCODE».
propfl c'-' "PROPFL" tfl [sfl] Um nível de voo proposto por uma
unidade receptora para a trans-
ferência de um voo.
ptot b '-' "PTOT" timehhmm Hora Provisória de Descolagem.
Hora de referência provisória para
uma janela ATFM.
qrorgn b '-' "QRORGN" originatorid Identificador do originador de uma
Consulta.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Nome do(s) aeródromo(s) alterna-
tivos em rota.2000R2082 — PT — 15.06.2002 — 001.001 — 109
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
rate b '-' "RATE" ((("C" | "D")!
2{ALGARISMO}2 ) | "ZZZ" )Razão de variação: a razão de
subida ou de descida atribuída a
uma aeronave, expressa em
centenas de pés por minuto. =>
Tem de ser um «C» para indicar
uma razão de subida, ou um «D»
para indicar uma razão de descida,
seguidos de um número de dois
algarismos indicando a razão atri-
buída em centenas de pés por
minuto. Em alternativa pode
utilizar-se o designador «ZZZ»
para indicar a não existência de
razão de subida ou de descida atri-
buída.
ratepdlst c'-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Lista de períodos de tempo e
respectivas velocidades de escoa-
mento do tráfego para uma
condição ATFM.
reason b '-' "REASON" 4{ALFA}12 Razão para a rejeição de uma
mensagem ou para o cancelamento
de uma janela pelo TACT.
A informação de apoio à
mensagem, dependendo do seu
contexto.
ref c'-' "REF" refid ptid brng distnc Ponto na rota definido em termos
do rumo magnético e da distância a
outro ponto e dado no designador
REFxx.
refdata c'-' "REFDATA" [sender] [rec vr]
seqnumInformação de referência da
mensagem a ser transmitida.
reg b '-' "REG" 1{ LIM_CHAR }7 Número de registo, tal como em
REG/ do campo 18 da ICAO.
reglocb '-' "REGLOC" 1 {LIM_CHAR}
15Localização de referência para um
Regulamento ATFM.
regul b '-' "REGUL" regulid Identificador de um Regulamento
relativo a um voo.
rejctot b '-' "REJCTOT" timehhmm Rejeição da Hora de Descolagem
Calculada: resposta negativa a uma
Proposta de Melhoria de Janela.
release b '-' "RELEASE" 1{ALFA}1 Uma indicação de que o voo é
autorizado pelo controlador que
transfere para o controlador que
recebe.
C = autorizado a subir
D = autorizado a descer
T = autorizado a dar voltas
F = autorizado para todas as acções
rename c'-' "RENAME" renid ptid Indic ação de um novo nome
temporário, dado a um «ponto
significativo» que aparece mais de
uma vez na descrição da rota para
evitar confusão. Este nome
temporário aplica-se apenas com o
objectivo de clarificar a represen-
tação da rota e não implica uma
modificação efectiva da identifi-
cação real do ponto.
respby b '-' "RESPBY" timehhmm Responder Em: hora a que terá de
ser dada uma resposta a uma
Proposta de Melhoria de Janela.2000R2082 — PT — 15.06.2002 — 001.001 — 110
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
rfl b '-' "RFL" flightlevel [point] Nível de voo solicitado (em
número de nível de voo, em
dezenas de metros ou em centenas
de pés) e, opcionalmente, o ponto
para o qual se requer a alteração do
RFL
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Indicador do Plano de Voo Substi-
tuto (RFP).
Tem de ser um «Q» seguido de um
algarismo (1 – 9).
rfpdlist c'-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Lista de todos os RFPD que
correspondem à chave da base de
dados dada numa Consulta.
rfpdslist c'-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Lista dos rfpdsum (informação
sumária da RFPD) que corres-
pondem às chaves da base de dados
dada numa Interrogação.
rif b '-' "RIF 4{LIM_CHAR} Rota revista sujeita a autorização
em voo e que termina com o
designador ICAO do aeródromo de
destino revisto.
rmk b '-' "RMK" 1{ LIM_CHAR } Observações em linguagem
simples, tal como em RMK/ do
campo 18 da ICAO.
route b '-' "ROUTE" {LIM_CHAR} Informação completa do Campo 15
da ICAO contendo a velocidade,
RFL e rota (de acordo com a
sintaxe dada na Ref. 4)
rrtefrom c'-' "RRTEFROM" tfvid refloc
flowlst flblockDescrição de um fluxo de tráfego
que deve ser reencaminhado.
rrteref b '-' "RRTEREF" rrteid Referência do Reencaminhamento.
rrteto c'-' "RRTETO" tfvid refloc flowlst
flblockDescrição de um fluxo de tráfego
para onde o tráfego vai ser reenca-
minhado.
rtepts c'-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Lista de pontos da rota. Pode
também conter um identificador de
aeródromo.
rvr b '-' "RVR" 1{ ALGARISMO }3 Extensão de Pista Visível (RVR).
Mínimos de operação quando exis-
tirem condições meteorológicas
especiais. Expressa em metros.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Lista de períodos de tempo e seus
limites RVR aplicáveis.
rvrperiod c'-' "RVRPERIOD" from until
rvrlimitO período de tempo dentro do qual
o limite RVR indicado é aplicável.
sector b '-' "SECTOR" 1{ ALFANUM }8 Identificação de um sector de ATC.
sel b '-' "SEL" 4{ ALFA }5 Código SELCAL, tal como no
elemento «SEL/» do Campo 18 da
ICAO.
sendto c'-' "BEGIN""SENDTO" {unit} '-'
"END""SENDTO"Lista de unidades de navegação
aérea que vão receber umamensagem.
seqpt b '-' "SEQPT" ssrequipment Equipamento de vigilância, tal
como no Campo 10 da ICAO.
sid b '-' "SID" point ! 1{ALGA-
RISMO}1 ! 0{ALFA}1Identificador de um procedimento
de Partida Normalizada por Instru-
mentos.2000R2082 — PT — 15.06.2002 — 001.001 — 111
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
speed b '-' "SPEED" spd [ point ] Velocidade verdadeira do ar (em
quilómetros por hora ou em nós) e,
em opção, o ponto para o qual é
solicitada a alteração de veloci-
dade.
spla b '-' "SPLA" 1{ LIM_CHAR }50 Cor das marcas da aeronave, tal
como no elemento «A/» do Campo
19 da ICAO.
spladdr c'-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Informação sobre contactos, onde
pode ser obtida Informação Suple-
mentar do plano de voo.
splcb '-' "SPLC" 1{ LIM_CHAR }50 Nome do piloto c omandante, tal
como no elemento «C/» do Campo
19 da ICAO.
spldcap b '-' "SPLDCAP" 1{ ALGARISMO
}3Capacidade total de botes de
borracha, tal como no elemento
«D/» do Campo 19 da ICAO.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Cor dos botes de borracha, tal
como no elemento «D/» do Campo
19 da ICAO.
spldcov b '-' "SPLDCOV" ('T' | 'F') Botes de borracha: indicação da
sua cobertura ou não, tal como no
elemento «D/» do Campo 19 da
ICAO.
T = Verdadeiro (=> «C» na ICAO)
F = Falso, não cobertos.
spldnb b '-' "SPLDNB" 1{ ALGARISMO
}2Botes de borracha: número, tal
como no elemento «D/» do Campo
19 da ICAO.
sple b '-' "SPLE" timehhmm_elapsed Autonomia de combustível, tal
como no elemento «E/» do Campo
19 da ICAO.
splj b '-' "SPLJ" lifejackets Coletes salva-vidas, tal como no
elemento «J/» do Campo 19 da
ICAO.
spln b '-' "SPLN" 1{ LIM_CHAR } Qualquer outro equipamento de
sobrevivência e observações úteis,
tal como no elemento «N/» do
Campo 19 da ICAO.
splp b '-' "SPLP" 1{ALGARISMO}3 Pessoas a bordo, tal como no
elemento «P/» do Campo 19 da
ICAO.
splr b '-' "SPLR" emergradio Equipamento rádio de emergência,
tal como no elemento «R/» do
Campo 19 da ICAO.
spls b '-' "SPLS" survivaleqpt Equipamento de sobrevivência, tal
como no elemento «S/»' do Campo
19 da ICAO.
srcb '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Identificação da origem da infor-
mação. O conteúdo depende do
campo TITLE.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Ou;
- modo e código SSR, tal como nos
elementos b e cdo c ampo 7 da
ICAO, ou
- as letras «REQ» indicando o
pedido do código.
star b '-' "STAR" point ! 1{ALGA-
RISMO}1 ! 0{ALFA}1Identificação de um procedimento
de Chegada Normalizada.
starttime b '-' "STARTTIME" day !
timehhmmInstante em que se inicia um
período de tempo.2000R2082 — PT — 15.06.2002 — 001.001 — 112
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
stay c'-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Indicação na rota de um voo de um
período de «actividade especial»
quando a aeronave irá «estar» na
área definida pelos pontos e/ou
aeródromos dados durante o
período de tempo indicado, ou seja,
treino, reabastecimento em voo,
missão fotográfica, etc.
NOTA: A ordem pela qual são
dados os pontos e/ou aeródromos é
significativa.
stayinfo c'-' "STAYINFO" stayident remark Informação relativa ao tipo de ac ti-
vidade (treino, missão fotográfica,
etc.) a realizar durante um período
de «estar» na rota de um voo.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Razão para tratamento especial, tal
como em STS/ do campo 18 da
ICAO. Poderá ser «PROTECTED»
para indicar tratamento sensível ou
um dos rótulos reconhecidos,EMER, HOSP, etc. ou texto livre.
taxitime b '-' "TAXITIME" timehhmm A diferença de tempo entre a «hora
de saída dos calços» e a «hora de
descolagem». As horas referidas
podem ser reais ou estimadas,
dependendo do contexto.
tfcvol b '-' "TFCVOL" 1 {ALFANUM} 15 Identificação de um «volume de
tráfego».
tfv c'-' "TFCVOL" tfvid refloc flowlst
flblockDescrição de um volume de
tráfego.
title b '-' "TITLE" titleid Título da mensagem.
ttleet b '-' "TTLEET" timehhmm_elapsed Tempo estimado total decorrido em
horas e minutos.
typz b '-' "TYPZ" text20 Tipo de aeronave quando não
existir código ICAO.
unit c'-' "UNIT" unitid [addrinfo] Informação relativa a uma
«unidade de navegação aérea», ou
seja, uma unidade de ATC, um
operador de aeronaves ou um
originador de um plano de voo.
Contém a identificação da unidade
e, opcionalmente, informação do
endereço.
valfrom b '-' "VALFROM" date Primeira data a partir da qual está
prevista a operação do voo (ano,
mês e dia).
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Primeira data a partir da qual está
prevista a operação do voo, usada
como chave da base de dados numa
consulta, podendo ser utilizados
caracteres universais. Tem de ser
uma data válida ou a combinação
de uma data válida e de caracteres
universais.
valfromold b '-' "VALFROMOLD" date A data «valfrom»«anterior». Usada
como uma chave da base de dados.
Quando o início da data de vali-
dade tiver de ser alterado, o novo
valor será dado em «VALFROM».
validitydate b '-' "VALIDITYDATE" date Data de validade.
valuntil b '-' "VALUNTIL" date Última data a partir da qual está
prevista a operação do voo (ano,
mês e dia).2000R2082 — PT — 15.06.2002 — 001.001 — 113
▼B
Campo
Primário
AdexpTipo Sintaxe Semântica
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Última data a partir da qual está
prevista a operação do voo, usada
como chave da base de dados numa
Consulta, podendo ser utilizados
caracteres universais. Tem de ser
uma data válida ou a combinação
de uma data válida e de caracteres
universais.
valuntilold b '-' "VALUNTILOLD" date A data «valuntil»«anterior». Usada
como uma chave da base de dados.
Quando o fim da data de validade
tiver de ser alterado, o novo valor
será dado em «VALUNTIL».
wktrc b '-' "WKTRC" waketurbcat Categoria da turbulência da esteira.
A.4.Subcampos ADEXP
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
addrinfo c'-' "ADDRINFO"
networktype facInformação de Ende-
reçamentounit
adid b '-' "ADID" icaoaero-
drome | 'ZZZZ'Designador de um
aeródromo. Pode
conter o indicador de
localização ICAO ou
os caracteres
«ZZZZ» quando não
estiver atribuído
nenhum designador.ad
position
stay
airroute c'-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Descrição de toda ou
de parte de uma rota
ATS durante um
período específico.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Descrição de todo ou
de parte de um
espaço aéreo durante
um período especí-
fico.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALFANUM }12Designa um espaço
aéreo que não uma
rota de ATS.entrydata airspace
brng b '-' "BRNG" refbea-
ringAzimute de um ponto
relativamente a uma
ajuda à navegação,
em graus magnéticos.ref
condition b '-' "CONDITION" 2
{ALFA} 20Tipo de condição ou
de restrição, por
exemplo, TOS,
restrição de FL.ignore
crfl1 b '-' "CRFL1" flight-
levelO limite inferior de
uma faixa de níveis
de voo dentro da qual
é solicitada uma
subida de cruzeiro.crsclimb ptcrsclimb
crfl2 b '-' "CRFL2" (flight-
level | "PLUS")O limite superior da
faixa de níveis de
voo dentro da qual é
solicitada uma subida
de cruzeiro. Escrever
o sinal «PLUS»
quando o limite
superior é desconhe-
cido.crsclimb ptcrsclimb2000R2082 — PT — 15.06.2002 — 001.001 — 114
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
crmach b '-' "CRMACH"
machnumberOn .ode Mach
mantido durante a
subida de cruzeiro.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd A velocidade a
manter durante uma
subida de cruzeiro.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Hora Calculada Sobre
um ponto.ad
positionpt
distncb '-' "DISTNC" 1{
ALGARISMO }3Distância de um
ponto a uma ajuda à
navegação em milhas
náuticas. Terá de ter
1 a 3 algarismos,
possivelmente com
zeros à esquerda.ref
efl b '-' "EFL" flightlevel Nível de voo esti-
mado.Reservado
para utili-
zação
futura.
endreg b '-' "ENDREG" day!ti-
mehhmmA hora a que termina
um Regulamento de
ATFM.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusCódigo de capaci-
dade do equipamento
seguido de um valor
que indica a situação
da capacidade no
momentoeqcst
eto b '-' "ETO" date !
timehhmm ! secondsHora Estimada Sobre
um ponto, indicando
o ano, mês, dia,
horas, minutos e
segundos.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]Uma «condição espe-
cial» levantada no
contexto da ATFM,
por exemplo,
nevoeiro num aeró-dromo.reglist
facb '-' "FAC" 1{
LIM_CHAR }30Informação de ende-
reçamento.addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
fir b '-' "FIR" 7{ ALFA }7 Designa uma FIR ou
uma UIR.lfir
fl b '-' " FL" flightlevel Um campo genérico
para o nível de voo.
Poderá ser «SFL»,
«EFL», «CFL»,
«RFL», etc. depen-
dendo do contexto.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt2000R2082 — PT — 15.06.2002 — 001.001 — 115
▼M1
▼B
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
flblock c '-' "FLBLOCK" fl fl Um bloco de níveis
de voo definindo
verticalmente um
espaço aéreo,
incluindo os níveis de
voo indicados. Um
bloco definido como
abaixo ou acima de
um nível de voo, será
expresso, respectiva-
mente, do nível de
voo 000 até ao nível
especificado ou do
nível especificado até
ao nível de voo 999.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c'-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleDescrição de um
«fluxo» dando a área
de origem, opcional-
mente as rotas ou os
pontos a serem
sobrevoados desde a
área de origem, a
área de destino e,
opcionalmente, as
rotas ou os pontos a
serem sobrevoados
até à área de destino.flowlst
flowlst c'-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Lista dos fluxos de
tráfego.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7A «razão» imposta
por um Regulamento
ATFM.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Uma indicação do
«papel» de um fluxo
de tráfego.
EX = excluído
IE = incluído isento
EM = isento
IN = incluídoflow
from b '-' "FROM" day!ti-
mehhmmO instante em que se
inicia um período de
tempo.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALFANUM} 15Uma posição em que
se inicia uma rota,
uma porção de uma
rota, um «percurso»
ou um fluxo de
tráfego.
Pode ser uma região,
um aeródromo ou um
ponto significativo.flow
geoid b '-' "GEOID" geoname Identificador de um
ponto geográfico,
constituído por GEOseguido de um
número sequencial
(exemplo: «GEO12»)geo
ifpdlong c'-' "BEGIN"
"IFPDLONG"
adexpmsg '-' "END"
"IFPDLONG"Informação completa
relativa a um plano
de voo individual.ifpdlist2000R2082 — PT — 15.06.2002 — 001.001 — 116
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
ifpdsum c'-' "IFPDSUM" arc id
adep ades eobt orgnInformação sumária
relativa a um plano
de voo individual.
Contém os campos
arcid, adep, ades,
eobt e orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{ALGARISMO}3Um número de três
algarismos indicando
o fim de uma
sequência.
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitude em graus,
minutos, segundos e
direcção (Norte ou
Sul).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitude em graus,
minutos, segundos e
direcção (Este ou
Oeste)eetlong
geo
network-
typeb '-' "NETWORK-
TYPE"
2{ALFANUM}10Indicador do tipo de
rede utilizada para
uma permuta de
mensagens.origin addrinfo
num b '-' "NUM" 3{ALGA-
RISMO}3Um número com três
algarismos.extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7A «razão pendente»,
utilizada para efeitos
de ATFM.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgContém uma
mensagem ADEXP
completa após ter
sido processada.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgContém uma
mensagem ADEXP
completa antes de ter
sido processada, ou
seja, tal como foi
recebida.adexptxt
pt c'-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Ponto de uma rota.
=> Contém a identi-
ficação de um ponto
e opcionalmente:
- um nível de voo ou
bloco de níveis de
voo,
- um nível de voo
suplementar,
- referência(s) de
tempo,
- uma subida de
cruzeiro,
- uma indicação de
rota,
- uma indicação de
um período de «acti-
vidade especial», ou
seja, que aquele voo
irá «estar» na área
durante um período
de tempo
Alteração de:
- RFL, regras de voo,
velocidade/n.ode
Mach.rtepts2000R2082 — PT — 15.06.2002 — 001.001 — 117
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Indicação de uma
subida de cruzeiro na
rota de um voo. É
dada a velocidade ou
on .ode Mach
seguido pelos dois
níveis indicando a
faixa de níveis de
voo a ocupar durante
a subida. O segundo
nível pode ser
«PLUS» quando o
nível superior for
desconhecido.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Uma indicação das
regras de voo aplicá-
veis ao ponto respec-
tivo.entrydata
ptid b '-' "PTID" point Identificação de um
ponto, seja um desig-
nador codificado ou
um nome dado artifi-
cialmente (GEOxx,
REFxx ou RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberNúmero de Mach, em
centésimos de
unidade, associado a
um ponto da rota.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Uma indicação das
regras de voo «mili-
tares» aplicáveis ao
ponto respectivo.entrydata
ptrfl b '-' "PTRFL" flight-
levelNível de voo solici-
tado, associado a um
ponto da rota.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}A rota do voo após o
ponto indicado. Pode
ser uma rota
completa até ao aeró-
dromo de destino ou
simplesmente o
elemento de rota até
ao próximo ponto.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgIndicação de uma
alteração, ou nas
«regras de voo»
(VFR/IFR) ou o «tipo
de voo» (OAT/GAT),
ou ambos, e asso-
ciados a um ponto da
rota.ad pt
ptspeed b '-' "PTSPEED" spd Velocidade verda-
deira do ar (em
quilómetros por hora
ou nós) associada a
um ponto da rota.ad
entrydatapt2000R2082 — PT — 15.06.2002 — 001.001 — 118
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
ptstay b '-' "PTSTAY" stayi-
dentifier timehhmmIndicação dentro da
rota de voo preen-
chida de um período
de «actividade espe-
cial» em que a aero-
nave irá «estar» na
área definida, duranteo período de tempo
dado, ou seja, treino,
reabastecimento em
voo, etc.ad pt
rateperiod c'-' "RATEPERIOD"
from until flowrate
penrateUm período de tempo
durante o qual as
velocidades de escoa-
mento de tráfego
dadas são aplicáveis
para um Regula-
mento ATFM.ratepdlst regcond
recvr b '-' "RECVR" fac O receptor da
mensagem em
referência.msgref
refdata
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]Designador da rota
ATS e identificadores
do primeiro e do
último ponto. Os
pontos listados
podem ser identifica-
dores ICAO ou
pontos GEOxx,
RENxx ou REFxx
atribuídos artificial-mente. Pode, em
opção, ser incluído o
identificador do país
em que o ponto se
localiza. Os pontos
terminais têm de ser
consistentes com a
informação da rota.airroute
refid b '-' "REFID" refname Identificador de um
ponto de referência
constituído por
«REF» seguido de
um número sequen-
cial (exemplo.
«REF02»)ref
reflocb '-' "REFLOC"
1{LIM_CHAR}15Localização de
referência de um
Regulamento ATFM.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Lista de períodos de
tempo e respectivas
velocidades de escoa-
mento de tráfego para
um regulamento
particular.regulation
regdescb '-' "REGDESC"
1{LIM_CHAR}Descrição de um
Regulamento ATFM.regulation
regid b '-' "REGID" regulid Identificação de um
«Regulamento» de
gestão do fluxo de
tráfego.regulation
reglist c'-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Lista de «Regula-
mentos» para efeitos
de gestão de fluxos
de tráfego.fmplist2000R2082 — PT — 15.06.2002 — 001.001 — 119
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
regnum b '-' "REGNUM"
3{ALGARISMO}3 !
"/" ! 2{ALGA-
RISMO}2Número de referência
para um «Regula-
mento» ATFM.
Fornece uma
referência única
seguida de uma indi-
cação de validade.exccond
regulation
regreason b '-' "REGREASON" 4
{ALFA} 12A razão para um
Regulamento ATFM.exccond
regulation
regulation c'-' "REGULATION"
regnum regid regdesc
reflocstartreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]Um «Regulamento»
imposto por razões
de gestão do fluxo de
tráfego.reglist
remark b '-' "REMARK"
1{LIM_CHAR}Observação acerca do
item, de cuja
descrição este campo
é uma parte.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identificador atri-
buído a um ponto que
se repete na descrição
da rota.rename
respunit b '-' "RESPUNIT"
12{ALFA}12A Unidade ATC
responsável.airspace
rfpdlong c'-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Informação completa
relativa a um plano
de voo repetitivo.rfpdlist
rfpdsum c'-' "RFPDSUM" arc id
adep ades eobt orgn
days valfrom valuntilSumário da infor-
mação relativa a um
plano de voo repeti-
tivo. Contém os
campos arcid, adep,
ades, eobt, orgn,
days, valfrom e
valuntil.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{ALGARISMO}3Extensão de Pista
Visível: mínimos de
operação quando
existirem condições
meteorológicas espe-
ciais. Expressa em
metros.rvrperiod exccond
sender b '-' "SENDER" facO emissor da
mensagem em
referência.msgref
refdata
seqnum b '-' "SEQNUM"
3{ALGARISMO}3O número de série da
mensagem a enviar
(um número de três
algarismos, único da
combinação emissor/
/receptor).msgref
refdata2000R2082 — PT — 15.06.2002 — 001.001 — 120
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
sfl b '-' SFL flightlevel !
('A'|'B')Nível de voo suple-
mentar. O nível de
voo a que, a esse
nível ou acima, ou, a
esse nível ou abaixo,
um voo foi ou será
coordenado para
cruzar um ponto.
Consiste de um
número do nível de
voo e de uma
condição de cruza-
mento («A» se a
aeronave irá cruzar o
ponto a esse nível ou
acima dele, ou «B»
se a aeronave irá
cruzar o ponto a esse
nível ou abaixo dele).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmA altura em que um
Regulamento ATFM
se torna efectivo.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentO indicador do
estado de coorde-
nação de um voo.cstat
statreason b '-' "STATREASON"
coorstatusreasonA razão para uma
alteração do estado
de coordenação de
um voo.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentificação de um
período de «activi-
dade especial» ou de
uma «estadia» na rota
de um voo.stay
stayinfo
sto b '-' "STO" timehhmm
! secondsUm campo de hora
genérico que pode
conter a hora para um
ponto ou para um
aeródromo. A hora
pode ser estimada,
calculada ou ser real,
dependendo do
contexto.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Nível de Voo de
Transferência. O
nível de voo para o
qual um voo foi ou
será coordenado para
cruzar um ponto
(número do nível de
voo), se em voonivelado, ou o nível
autorizado para o
qual o voo se dirige
se estiver a descer ou
a subir no ponto de
fronteira.coordata
propfl
tfvid b '-' "TFVID"
1{ALFANUM}15Identificação de um
«volume de tráfego».rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Uma indicação
horária. Pode ser uma
hora efectiva ou um
período de tempo,
dependendo do
contexto da
mensagem.stay2000R2082 — PT — 15.06.2002 — 001.001 — 121
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
to b '-' "TO" timehhmm «Hora Sobre/Fora».
Um campo horário
genérico que pode
conter a hora para um
ponto ou para um
aeródromo. A hora
pode ser estimada,
calculada ou ser real,
dependendo do
contexto.position
coordatapt
topos b '-' "TOPOS" 1
{ALFANUM} 15Uma posição até
onde se estende uma
rota, um segmento de
rota, um «percurso»
ou um fluxo de
tráfego. Pode ser uma
região, um aeró-
dromo ou um ponto
significativo.flow
unitid b '-' "UNITID" 2{
ALFANUM}10Identificação de uma
unidade de nave-
gação aérea, ou seja,
uma unidade ATC,
um operador de aero-
nave ou um origi-
nador de planos de
voo.unit
until b '-' "UNTIL" day!ti-
mehhmmO instante em que
um período de tempo
termina.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timeUm período de vali-
dade, incluindo as
horas dadas.airroute
airspace
via1 b '-' "VIA1" 1
{ALFANUM} 15Um ponto, uma rota
ATS ou um espaço
aéreo que se encontre
na rota ou que seja
necessário estar na
rota do voo. Quando
seja necessário
indicar mais de um,
este campo conterá o
primeiro na
sequência.flow
via2 b '-' "VIA2" 1 {
ALFANUM } 15Um ponto, uma rota
ATS ou um espaço
aéreo que se encontre
na rota ou que seja
necessário estar na
rota do voo. Quando
seja necessário
indicar mais de um,
este campo conterá o
segundo na
sequência.flow
via3 b '-' "VIA3" 1 {
ALFANUM } 15Um ponto, uma rota
ATS ou um espaço
aéreo que se encontre
na rota ou que seja
necessário estar na
rota do voo. Quando
seja necessário
indicar mais de um,
este campo conterá o
terceiro na sequência.flow2000R2082 — PT — 15.06.2002 — 001.001 — 122
▼B
Subcampo Tipo Sintaxe SemânticaUsado no
Campo
PrimárioUsado no
Subcampo
via4 b '-' "VIA4" 1 {
ALFANUM } 15Um ponto, uma rota
ATS ou um espaço
aéreo que se encontre
na rota ou que seja
necessário estar na
rota do voo. Quando
seja necessário
indicar mais de um,
este campo conterá o
quarto na sequência.flow2000R2082 — PT — 15.06.2002 — 001.001 — 123
▼B
ANEXO B (Normativo)
ÍNDICECENTRAL DE TÍTULOS DE MENSAGENSADEXP
Título DefiniçãoApresentada na
Secção
ABI Mensagem Avançada de Informação de Fronteira E.3
ACK Mensagem de Confirmação E.1
ACP Mensagem de Aceitação E.5
ACT Mensagem de Activação E.3
AUP Mensagem de Plano de Utilização de Espaço Aéreo E.4
BFD Mensagem de Informação de Voo Básica E.5CDN Mensagem de Coordenação E.3
CFD Alteração a uma Mensagem de Informação de Voo E.5
CNLCOND Mensagem de Cancelamento de Condição Excepcional de
ATFME.2.3
CNLREG Mensagem de Cancelamento de Regulamento ATFM E.2.3
COD Mensagem de Atribuição de Código SSR E.3
COF Mensagem de Alteração de Frequência E.3
CRAM Mensagem de Disponibilidade de Rota Condicional E.4
DES Mensagem de Cancelamento de Suspensão E.2.2
ERR Mensagem de Erro E.2.2
EXCOND Mensagem de Notificação de Condição Excepcional de
ATFME.2.3
FCM Mensagem de Confirmação de Voo E.2.2
FLS Mensagem de Suspensão de Voo E.2.2
FSA Primeira Mensagem de Activação do Sistema E.2.3
HOP Mensagem de Proposta de Transferência E.3
IACH Mensagem de Modificação de ATC Individual E.1
IAFP Mensagem de Proposta de Plano de Voo de ATC Individual E.1
IAPL Mensagem de Plano de Voo de ATC Individual E.1
IARR Mensagem de Chegada Individual E.1
ICHG Mensagem de Modificação Individual E.1ICNL Mensagem de Cancelamento Individual E.1
IDEP Mensagem de Partida Individual E.1
IDLA Mensagem de Atraso Individual E.1
IFPL Mensagem de Plano de Voo Individual E.1
INF Mensagem de Informação E.3
IRPL Plano de Voo Repetitivo Individual E.1
IRQS Pedido Individual de Plano de Voo Suplementar E.1
ISPL Plano de Voo Suplementar Individual E.1
LAM Mensagem de Confirmação Lógica E.3, E.5
LRM Mensagem de Rejeição Lógica E.3
MAC Mensagem para Revogação de Coordenação E.3
MAN Mensagem Aguardando Processamento Manual E.1
MAS Afectação Manual de Mensagens de Comunicações E.3
MODCOND Mensagem de Modificação de Condições Excepcionais de
ATFME.2.3
MODREG Mensagem de Modificação de Regulamento de ATFM E.2.3
MRA Mensagem de Activação de Rota Obrigatória E.2.3
MRCNL Mensagem de Cancelamento de Rota Obrigatória E.2.3
MRMOD Mensagem de Modificação de Rota Obrigatória E.2.32000R2082 — PT — 15.06.2002 — 001.001 — 124
▼B
Título DefiniçãoApresentada na
Secção
NEWREG Nova Mensagem de Notificação de Regulamento de ATFM E.2.3
NTA Mensagem de Não Aceitação de Tráfego E.2.3
NTACNL Mensagem de Cancelamento de Não Aceitação de Tráfego E.2.3
NTAMOD Mensagem de Modificação de Não Aceitação de Tráfego E.2.3
OLRA Mensagem de Activação de Rota Sem Tráfego E.2.3OLRCNL Mensagem de Cancelamento de Rota Sem Tráfego E.2.3
OLRMOD Mensagem de Modificação de Rota Sem Tráfego E.2.3
PAC Mensagem de Activação Preliminar E.3
RAP Mensagem de Referência de Proposta de Activação E.3
RCHG Mensagem de Modificação de Informação de Plano de Voo
RepetitivoE.1
RCNL Mensagem de Cancelamento de Informação de Plano de
Voo RepetitivoE.1
RDY Mensagem de Aprontamento E.2.2
REJ Mensagem de Rejeição E.1
REV Mensagem de Revisão E.3
RJC Mensagem de Rejeição de Coordenação E.5
RJT Mensagem de Rejeição de Reencaminhamento E.2.2
ROF Mensagem de Pedido Na Frequência E.3
RRP Mensagem de Proposta de Reencaminhamento E.2.2
RRV Mensagem de Referência de Proposta de Revisão E.3
SAM Mensagem de Atribuição de Janela E.2.2
SBY Mensagem de Espera E.3
SDM Mensagem de Informação Suplementar E.3
SIP Mensagem de Proposta de Melhoria de Janela E.2.2
SLC Mensagem de Cancelamento de Pedido de Janela E.2.2
SMM Mensagem de Perda de Janela E.2.2
SPA Mensagem de Aceitação de Proposta de Janela E.2.2SRJ Mensagem de Rejeição de Proposta de Janela E.2.2
SRM Mensagem de Revisão de Janela E.2.2
SRR Mensagem de Pedido de Revisão de Janela E.2.2
TIM Mensagem de Início de Transferência E.3
UUP Mensagem Actualizada de Plano de Utilização de Espaço
AéreoE.4
XAP Mensagem de Proposta Alternativa de Cruzamento E.5
XCM Mensagem de Cancelamento de Cruzamento E.5
XIN Mensagem de Notificação de Intenção de Cruzamento E.5
XRQ Mensagem de Pedido de Cruzamento E.52000R2082 — PT — 15.06.2002 — 001.001 — 125
▼B
ANEXO C (Normativo)
ÍNDICECENTRAL DE TÍTULOS RESERVADOSDE 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
Título Reservado Tipo de Mensagem Reservado por
ACTARR Mensagem de Activação para uma Chegada FRANÇA
ACTDEP Mensagem de Activação para uma Partida FRANÇA
ADMFPL Mensagem de Plano de Voo ADMAR2000 ALEMANHA
ADMFPT Mensagem de Término de Plano de Voo ADMAR2000 ALEMANHAADMFPU Mensagem de Actualização de Plano de Voo
ADMAR2000ALEMANHA
ANM Mensagem de Notificação de ATFM CFMU
ANSWERCT Mensagem de Resposta (Sistema de Controlo Terminal) FRANÇA
ANSWM Mensagem de Resposta (ODS) FRANÇA
ANSXFPLCT Mensagem de Resposta FRANÇA
ATT Mensagem de Aterragem FRANÇA
BEGINPROC Mensagem de Início de Processamento FRANÇA
BEGPROC Mensagem do Procedimento de Inicialização de
Posição de Trabalho de Controlador (ODS)FRANÇA
BEGPROCCT Mensagem de Inicialização de Posição de Trabalho de
Controlador (Sistema de Controlo Terminal)FRANÇA
CDA Mensagem de Autorização de Partida (ARINC 623) FRANÇA
CDAFTX Autorização de Partida (ARINC 620) FRANÇA
CHGDEP Mensagem de Modificação para a partida de um Voo FRANÇA
CLD Autorização de Partida (ARINC 623) FRANÇA
CLDFTX Autorização de Partida (ARINC 620) FRANÇA
CNLARR Cancelamento de uma Chegada FRANÇA
CNLCOND Cancelamento de uma Condição Especial CFMU
CNLDEP Cancelamento de uma Partida FRANÇA
CNLREG Cancelamento de um Regulamento ATFM CFMU
CONFEND Mensagem Final de uma alteração da Configuração
OperacionalFRANÇA
CONFIDM Mensagem de Configuração Operacional (ODS) FRANÇA
CONFIDMCT Mensagem de Configuração Operacional (Sistema de
Controlo Terminal)FRANÇA
DEC Mensagem de Descolagem FRANÇA
DOUBM Mensagem de Plano de Voo Duplicado FRANÇA
DRT Mensagem de Modificação de Destino FRANÇA
EATARR Actualização da Mensagem de Hora Estimada de
ChegadaFRANÇA2000R2082 — PT — 15.06.2002 — 001.001 — 126
▼B
Título Reservado Tipo de Mensagem Reservado por
ENDPROC Última Mensagem do Procedimento de Inicialização de
Posição de Trabalho de Controlador (ODS)FRANÇA
ENDPROCCT Última Mensagem do Procedimento de Inicialização de
Posição de Trabalho de Controlador (Sistema de
Controlo Terminal)FRANÇA
EVLARR Mensagem de Pré-Activação de uma Chegada FRANÇA
EVLDEP Mensagem de Pré-Activação de uma Partida FRANÇA
EXCOND Activação de uma Condição Especial CFMU
FICM Mensagem de Criação de Informação de Voo FRANÇA
FLXVIVO Mensagem de Visualização da Descrição de um
«Trajecto Flexível»FRANÇA
FPCLOSE Mensagem de Fecho de Informação de Plano de Voo
(ODS)FRANÇA
FPCLOSECT Mensagem de Fecho de Informação de Plano de Voo
(Sistema de Controlo Terminal)FRANÇA
FPCLOSED Duplicação da Mensagem de Fecho de Informação de
Plano de Voo (ODS)FRANÇA
FPCRD Activação da Mensagem de Plano de Voo (ODS) FRANÇA
FPCRDCT Activação da Mensagem de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
FPCRDD Duplicação da Mensagem de Activação da Informação
de Plano de Voo (ODS)FRANÇA
FPCRE Criação de Mensagem de Plano de Voo (ODS) FRANÇA
FPCRECT Criação de Mensagem de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
FPINI Pré-Activação de Mensagem de Plano de Voo (ODS) FRANÇA
FPINICT Pré-Activação de Mensagem de Plano de Voo (Sistema
de Controlo Terminal)FRANÇA
FPINID Duplicação da Pré-Activação de Mensagem de Plano
de VooFRANÇA
FPNTF Pré-Activação de Mensagem de Plano de Voo (ODS) FRANÇA
FPNTFD Duplicação da Pré-Activação de Mensagem de Plano
de Voo (ODS)FRANÇA
FPRDU Mensagem de Informação de Parâmetros de Voo para
um Sector Não Envolvido (ODS)FRANÇA
FPRDUCT Mensagem de Informação de Parâmetros de Voo para
um Sector Não Envolvido (Sistema de Controlo
Terminal)FRANÇA
FSM Mensagem de Sistema para Autorização de Partida
(ARINC 623)FRANÇA
FSMFTX Mensagem de Sistema para Autorização de Partida
(ARINC 620)FRANÇA
FSR Mensagem de Pedido de Suspensão de Voo CFMU
IACHD Mensagem de Modificação de ATC Individual ALEMANHA
ICHGD Mensagem de Modificação Individual ALEMANHA
IDEPD Mensagem de Partida Individual ALEMANHA
IDLAD Mensagem de Atraso Individual ALEMANHA
IFPDQ Mensagem de Consulta de Informação de Plano de Voo
IndividualCFMU
IFPDQR Mensagem de Resposta a uma Consulta de Informação
de Plano de Voo IndividualCFMU
IFPDSQ Mensagem de Consulta Sumária de Informação de
Plano de Voo IndividualCFMU
IFPDSQR Mensagem de Resposta a uma Consulta Sumária de
Informação de Plano de Voo IndividualCFMU
IFPLD Plano de Voo Individual ALEMANHA2000R2082 — PT — 15.06.2002 — 001.001 — 127
▼B
Título Reservado Tipo de Mensagem Reservado por
INFOM Mensagem de Informação FRANÇA
IRQS Pedido Individual para Mensagem de Informação
SuplementarCFMU
ISPL Mensagem de Plano de Voo Suplementar Individual CFMU
LGR Lista de Mensagens de Plano de Voo FRANÇA
LISTFP Lista de Mensagens de Plano de Voo (ODS) FRANÇALISTFPCT Lista de Mensagens de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
LOGON Identificação de Mensagem de Plano de Voo FRANÇA
MAJVIVO Mensagem de Movimentos Diários FRANÇA
MCOM Mensagem de Coordenação FRANÇAMODCOND Modificação de uma Condição Excepcional CFMUMODREG Modificação de um Regulamento ATFM CFMUMRA Activação de uma Rota Obrigatória CFMUMRCNL Cancelamento de uma Rota Obrigatória CFMUMRMOD Modificação de uma Rota Obrigatória CFMUMRR Mensagem de Reencaminhamento Obrigatório CFMU
MVTVIVO Mensagem de Informação de Movimentos FRANÇA
NEWREG Activação de um Regulamento ATFM CFMUNTA Activação de um Fluxo de Tráfego «Não Autorizado» CFMUNTACNL Cancelamento de um Fluxo de Tráfego «Não Autori-
zado»CFMU
NTAMOD Modificação de um Fluxo de Tráfego «Não Autori-
zado»CFMU
OCLM Mensagem de Autorização Oceânica FRANÇA
OCLMD Duplicação de Mensagem de Autorização Oceânica FRANÇA
OLRA Activação de uma Rota Sem Tráfego CFMU
OLRCNL Cancelamento de uma Rota Sem Tráfego CFMUOLRMOD Modificação de uma Rota Sem Tráfego CFMUPAMAER Mensagem de Solicitação de Pista de Aterragem FRANÇAPAMARB Mensagem de Confirmação de «Em Posição» FRANÇAPAMARRANN Cancelamento de Atribuição de Estacionamento para
uma ChegadaFRANÇA
PAMARRCRE Atribuição de Posição de Estacionamento para uma
ChegadaFRANÇA
PAMARRPST Modificação de Atribuição de Estacionamento para
uma ChegadaFRANÇA
PAMDAPARB Mensagem de Estacionamento para uma Aeronave que
ChegaFRANÇA
PAMDAPCRE Atribuição de uma Posição de Estacionamento FRANÇA
PAMDEPANN Cancelamento de Atribuição de Estacionamento para
uma PartidaFRANÇA
PAMDEPCRE Atribuição de Estacionamento para uma Partida FRANÇA
PAMDEPPST Modificação da Atribuição de Estacionamento para
uma PartidaFRANÇA
PAMDRB Mensagem de Confirmação de «Em Posição» FRANÇA
QTAARR Regresso à Situação Original «Criada» para uma
ChegadaFRANÇA
QTADEP Regresso à Situação Original «Criada» para uma
PartidaFRANÇA
RCD Mensagem de Pedido de Autorização de Partida
(ARINC 623)FRANÇA2000R2082 — PT — 15.06.2002 — 001.001 — 128
▼B
Título Reservado Tipo de Mensagem Reservado por
RCDFTX Mensagem de Pedido de Autorização de Partida
(ARINC 620)FRANÇA
REVARR Mensagem de Revisão para uma Chegada FRANÇA
RFPDQ Mensagem de Consulta de Informação de Plano de Voo
RepetitivoCFMU
RFPDQR Mensagem de Resposta a uma Consulta de Informação
de Plano de Voo RepetitivoCFMU
RFPDSQ Mensagem de Consulta Sumária de Informação de
Plano de Voo RepetitivoCFMU
RFPDSQR Mensagem de Resposta a uma Consulta Sumária de
Informação de Plano de Voo RepetitivoCFMU
RIEM Mensagem Informativa de Parâmetros de Voo FRANÇA
RMG Mensagem de Aproximação Falhada FRANÇARRA Mensagem de Aceitação de Reencaminhamento CFMU
RREC Mensagem de Recuperação de Plano de Voo Repetitivo CFMU
RRN Mensagem de Notificação de Reencaminhamento CFMURSUS Mensagem de Suspensão de Plano de Voo Repetitivo CFMU
RWYCHGCT Mensagem de Configuração da Pista de Aterragem FRANÇA
TRACT Pedido de Activação de Plano de Voo (ODS) FRANÇA
TRACTCT Pedido de Activação de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
TRCNL Pedido de Cancelamento de Plano de Voo (ODS) FRANÇA
TRCNLCT Pedido de Cancelamento de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
TRCOR Pedido de Correlação Manual FRANÇA
TRDECOR Pedido de Descorrelação Manual FRANÇATRFIC Pedido para Criação de Informação de Plano de Voo
(ODS)FRANÇA
TRFICCT Pedido para Criação de Informação de Plano de Voo
(Sistema de Controlo Terminal)FRANÇA
TRFLRQT Mensagem de Pedido de Nível de Voo FRANÇA
TRMOD Pedido de Modificação de Plano de Voo (ODS) FRANÇA
TRMODCT Pedido de Modificação de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA
TRMODH Pedido de Modificação de Hora FRANÇA
TRMODHD Pedido de Modificação de Hora para Voo Atrasado FRANÇA
TRMVT Pedido de Coordenação para Voo que Sai (ODS) FRANÇA
TRMVTCT Pedido de Coordenação para Voo que Sai (Sistema de
Controlo Terminal)FRANÇA
TRPOINT Mensagem de Pedido de Informação de Voo Específica FRANÇA
TRRET Pedido de Alteração de Plano de Voo para a Situação
«Criado» (ODS)FRANÇA
TRRETCT Pedido de Alteração de Plano de Voo para a Situação
«Criado» (Sistema de Controlo Terminal)FRANÇA
TRRIP Pedido de Visualização de Informação de Parâmetros
de Voo (ODS)FRANÇA
TRRIPCT Pedido de Visualização de Informação de Parâmetros
de Voo (Sistema de Controlo Terminal)FRANÇA
TRRQT Pedido de Plano de Voo (ODS) FRANÇA
TRRQTCT Pedido de Plano de Voo (Sistema de Controlo
Terminal)FRANÇA
TRSHRQT Pedido de Acção SHOOT FRANÇA
TRSTAR Pedido de Inicialização de Posição de Trabalho de
Controlador (ODS)FRANÇA2000R2082 — PT — 15.06.2002 — 001.001 — 129
▼B
Título Reservado Tipo de Mensagem Reservado por
TRSTARCT Pedido de Inicialização de Posição de Trabalho de
Controlador (Sistema de Controlo Terminal)FRANÇA
TRTRP Mensagem de Posição de Transferência FRANÇA
UNKFP Supressão de Mensagem de Plano de Voo (ODS) FRANÇA
UNKFPCT Supressão de Mensagem de Plano de Voo (Sistema de
Controlo Terminal)FRANÇA2000R2082 — PT — 15.06.2002 — 001.001 — 130
▼B
ANEXO D (Normativo)
ÍNDICE CENTRALDE 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 defi-
nidos 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
Termo Auxi-
liar Reser-
vadoSintaxe SemânticaUtilizado no
Campo
PrimárioUtilizado no
SubcampoUtili-
zado no
auxiliar
centreidentifi-
cation1{ALFA}4 Identificação do
Centroctsrc
ripsrc
ctripectdest
contextfdpsid 'OPEPAL' |
'OPESOS' |
'EVALPAL' |
'TSTOPEPAL'
|'TSTOPESOS'Modo de
operação de uma
aplicação FDPS.
(Operacional,
Ensaio, etc.)ctxtfdps
contextphi-
diasid'OPE'|'EVA-
L1'|'EVAL2'
|('TST'!1{ALGA-
RISMO}1)Específico do
Sistema Francêsctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Ponto de entrada
para a posição de
controlo («E»).
Ponto de saída
para a posição
(«S»).
Ponto XFL (X).
Ponto OCL (O).coorpt
eoidentifica-
tion1{ALFANUM}6 Identificação de
uma «entidade
operacional»eosrceoid
fl3 'F' ! 3{ALGA-
RISMO}3Nível de voo
expresso em
centenas de pés.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Tendência projec-
tada do perfil de
voo.
U para CimaD para BaixoS para Estáveletrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Situação de um
plano de voo num
ACC.fpctst2000R2082 — PT — 15.06.2002 — 001.001 — 131
▼B
Termo Auxi-
liar Reser-
vadoSintaxe SemânticaUtilizado no
Campo
PrimárioUtilizado no
SubcampoUtili-
zado no
auxiliar
latitude 4{ ALGARISMO
}4Uma latitude
expressa com
quatro alga-
rismos.Reservado
para utili-
zação futura
latitudeshort 2{ ALGARISMO
}2Uma latitude
expressa com
dois algarismos.Reservado
para utili-
zação futura
longitude 5{ ALGARISMO
}5Uma longitude
expressa com
cinco algarismos.Reservado
para utili-
zação futura
longitudes-
hort3{ ALGARISMO
}3Uma longitude
expressa com três
algarismos.Reservado
para utili-
zação futura
pointcautra 1{ALFANUM}5 Específico do
sistema francêsfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALFANUM}6 Posição de
trabalho real ou
lógicaposid
qfuid ('0'|'1'|'2'|'3')!1{
ALGARISMO
}1!('L'|'C'
|'R'|NIL)QFU para uma
pista.
L = EsquerdaC= Central
R = Direitaqfu qful
secidentifica-
tion1{ALFANUM}2 Identificação de
Sector.secdest
secsrcsecid
sendin-
greason'INI'|'NTF'|'ACT'|
'MOD'|'MVT'|
'MVTSEC'|'COO-
RAUTO'|'-
MODHD'|
'CNL'|'RADAR'|'I-
NIT'|'RQT'|'TR-
F'|'RIP'|
'CONF'|'END'|'Q-
TA'|
'ESLSA'|'OCM'|
'DMER'|'TRFSE-
C'|
'COLLAT'|'SHR-
QT'|
'POINT'|'FLRQT'|'PKG'Razão para o
envio de infor-
mação de plano
de voo.event
starreason 'TOTAL' O tipo de iniciali-
zação de uma
posição com
informação de
plano de voostreason
temperature ("N" | "P") !
2{ALGA-
RISMO}2Temperatura
expressa em
graus centígrados
(00-99) com indi-
cação do sinal
(Negativo ou
Positivo)temp2000R2082 — PT — 15.06.2002 — 001.001 — 132
▼B
Termo Auxi-
liar Reser-
vadoSintaxe SemânticaUtilizado no
Campo
PrimárioUtilizado no
SubcampoUtili-
zado no
auxiliar
updatereason ('T'!('R'|NIL)|'R') Tipo da última
actualização feita
a uma informação
de voo.
Transacção do
Operador («T»)
Actualização
Radar («R»).udpt
D.4.Campos Primários Reservados
Campo
Primário
ReservadoTipo Sintaxe Semântica
aabd b '-' "AABD" date Data efectiva de chegada aos
calços
aabt b '-' "AABT" timehhmm Hora efectiva de chegada aos
calços
acnf c '-' "ACNF" ad rcnf [qfulist] Configuração da pista de aterragem
aobd b '-' "AOBD" date Data efectiva de saída dos calços
aobt b '-' "AOBT" timehhmm Hora efectiva de saída dos calços
apptyp b '-' "APPTYP" 1{ALFANUM}1 Tipo de aproximação do voo (1
algarismo, valores: 1, 2, 3)
arcidao b '-' "ARCIDAO" 1{ALFANUM}11 Identificação da aeronave utilizada
pelos operadores da aeronave
arcidatc b '-' "ARCIDATC" 8{ALGA-
RISMO}8Número de identificação da aero-
nave inequívoco no local, utilizado
pelo ATC
atis b '-' "ATIS" 1{ALFA}1 Indicador do Serviço de Infor-
mação Terminal Automática
autfl1 b '-' "AUTFL1" fl3 Nível de voo 1 autorizado
autfl2 b '-' "AUTFL2" fl3 Nível de voo 2 autorizado
automsg c'-' "AUTOMSG" (sendt ptc id flb
pflt)|'NO'Fornece a informação a transmitir
numa mensagem de coordenação:
Hora de envio, ponto de saída,
nível de voo por cima do ponto de
saída, nível de voo planeado e
informação relativa à concordância
do nível com o estabelecido.
avail b '-' "AVAIL" 'YES'|'NO' Indicação sobre se um sector está
ou não autorizado a modificar a
informação de um plano de voo
bkrow b '-' "BKROW" 1{ALGARISMO}2 A posição de um ponto de
referência numa lista de pontos da
rota
bkt b '-' "BKT" datetime A hora sobre o ponto de referência
para uma transacção
codetr b '-' "CODETR" 'YES'|'NO' Indicação sobre se o ssrcode deve
ser transmitido (ou não) para o
piloto pela posição de controlo
confid b '-' "CONFID" 1{ALGARISMO}5 Identificação da configuração
operacional (sectores|posições)
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-'"END" "CONFL"Lista de associações de sectores/
/posições para um centro na rota
crspd b '-' "CRSPD" 1{ALGARISMO}4 Velocidade de cruzeiro em nós
ctripe b '-' "CTRIPE" centreidentification Nome do centro receptor de uma
transacção2000R2082 — PT — 15.06.2002 — 001.001 — 133
▼B
Campo
Primário
ReservadoTipo Sintaxe Semântica
ctrow b '-' "CTROW" 1{ALGARISMO}1 A posição de um centro numa lista
de centros
ctsrc b '-' "CTSRC" centreidentification Identificação do centro emissor
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Modo de operação do Sistema de
Controlo Terminal
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Modo de operação de um FPDS
ctxtpos b '-' "CTXTPOS" contextphidiasid Modo de operação do ODScurfl b '-' "CURFL" fl3 Nível de voo actual
curpos c '-' "CURPOS" ptid | (lattd longtd) Posição actual
curpost b '-' "CURPOST" datetime Data e hora na posição actualcurptt b '-' "CURPTT" datetime Data e hora do sobrevoo do ponto
actual
curptx b '-' "CURPTX" 1{ALGARISMO}2 Posição numerada do ponto actual
numa lista de pontos da rota.
dcatcid b '-' "DCATCID" icaoaerodrome Aeródromo responsável pela auto-
rização de partida, quando dada à
aeronave pelo FPDS através de
uma ligação de dados.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Texto básico das mensagens
ARINC 623 de autorização de
partida. «ACK» para mensagens de
confirmação.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Texto básico das mensagens
ARINC 620 de autorização de
partida. «ACK» para mensagens de
confirmação.
dccar b '-' "DCCAR" 'DMER'|'COL-
LAT'|'NO'Situação da autorização de partida
para um voo.
dcid b '-' "DCID" 1{ALGARISMO}3 Número de sistema da autorização
de partida.
dcmtyp b '-' "DCMTYP" 1{ALFA}3 Tipo da mensagem de autorização
de partida.
dcref b '-' "DCREF" 1{ALFANUM}5 Referência de contexto para uma
autorização de partida.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Observações de uma autorização de
partida.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Texto suplementar para uma
Mensagem de Sistema de Autori-
zação de Partida (ARINC 623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Segundo texto suplementar para a
mensagem de Autorização de
Partida (ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Dia, hora, minutos e segundos da
autorização de partida.
delcode b '-' "DELCODE” 1{ALFANUM}20 Razão de um atraso.
dfdpsid b '-' "DFDPSID datetime ! seconds Informação da Identificação do
Sistema de Processamento de
Informação de Voo.
doubid b '-' "DOUBID" 1{ALFANUM}2 Identificação de uma «entidade»
duplicada.
ecurptt b '-' "ECURPTT" datetime Hora estimada de sobrevoo do
ponto actual.
eda b '-' "EDA" date Data estimada de chegada.
elastptt b '-' "ELASTPTT" datetime Hora estimada de sobrevoo do
último ponto da rota.2000R2082 — PT — 15.06.2002 — 001.001 — 134
▼B
Campo
Primário
ReservadoTipo Sintaxe Semântica
endhldt b '-' "ENDHLDT" datetime Hora de finalização do circuito de
espera.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Número de ocorrências de um
plano de voo num centro.
entryt b '-' "ENTRYT" datetime Hora de entrada na posição.
enxtptt b '-' "ENXTPTT" datetime Hora estimada de sobrevoo do
próximo ponto (não indicado se o
ponto actual for o último).
eobdt b '-' "EOBDT" datetime Data e hora estimada de saída dos
calços.
eosrc b '-' "EOSRC" eoidentification Identificação da «entidade» opera-
cional
espfl b '-' "ESPFL" flightlevel Nível de voo de transferência
suplementar para a posição de
controlo anterior.
eta b '-' "ETA" timehhmm Hora estimada de chegada.
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyNível de Voo de Entrada ou
tendência do perfil de voo.
event b '-' "EVENT" sendingreason Razão que despoleta um FDPS
firstpid b '-' "FIRSTPID" pointcautra Específico do Sistema Francês
flbk b '-' "FLBK" flightlevel Nível de voo do ponto de
referência da última transacção
para um voo activado, ou nível
modificado para um ponto de
referência de uma transacção.
fpbaseid b '-'FPBASEID" datetime!seconds Identificação na Base de Dados de
um Plano de Voo
fpctst b '-' "FPCTST" fpcentrestate Situação de um Plano de Voo num
Centro.
fpkwl c'-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Lista dos planos de voo conhecidos
mas ainda não transferidos para
uma posição.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Categoria do voo:
T = sobrevoo
E = a entrar
S = a sair
I = interno.
fplist c'-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Lista da informação de plano de
voo para um indicativo de
chamada.
fpllist c'-' BEGIN "FPLLIST" fpllgr
'-' "END"Lista dos campos de um plano de
voo.
fplnb b '-' "FPLNB" 1{ALGARISMO}1 Número de planos de voo de 0 a 5.
fplstat b '-' "FPLSTAT" "T" | "C" Situação do voo:
T = terminado
C = activo.
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Observações sobre o plano de voo
inicial.
fpsrcb '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-
CACT""|FIC-
PAC"|'FPL"|"RPL"|"NKW")Origem do Plano de Voo.
fpunkl c'-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Lista de planos de voo «desconhe-
cidos».
freetxt c'-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Mensagem em texto livre.
ftxid b '-' "FLXID" 1{ALFANUM}14 Identidade de um trajecto flexível.2000R2082 — PT — 15.06.2002 — 001.001 — 135
▼B
Campo
Primário
ReservadoTipo Sintaxe Semântica
ftxname b '-' "FLXNAME" 1{ALFANUM}4 Nome do trajecto flexível.
ftxnum b '-' "FLXNUM" 1{ALGARISMO}2 Número de geração do trajecto
flexível.
grspd b '-' "GRSPD" 1{ALGARISMO}4 Velocidade relativamente ao solo,
em nós.
hldbkrw b '-' "HLDBKRW" 1{ALGA-
RISMO}2Posição do número de um ponto de
referência pertencente a um
circuito de espera numa lista de
pontos da rota.
icing b '-' "ICING" 1{ALFA}8 Formação de gelo.
«VESTÍGIOS» ou «LIGEIRA» ou
«MODERADA» ou «SEVERA».
indstip b '-' "INDSTIP" 'STIP' Específico do sistema Francês
initid b '-' "INITID" 1{ALGARISMO}1 Número de inicialização
interid b '-' "INTERID" 'V'!2{ALGARIS-
MO}2!'R'!2{ALGARISMO}2Identificador do interface FDPS/
/ODS ou FDPS/Sistema terminal.
lalglist c'-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Lista da latitude e da longitude dos
pontos da rota.
lang b '-' "LANG" '?' Indicador de linguagem de conver-
sação.
«?» = a linguagem não é habitual
na companhia
lastradt b '-' "LASTRADT" datetime Última actualização horária forne-
cida pela informação radar.
lights b '-' "LIGHTS" 1{ALFANUM}1 Código de luzes.
maint b '-' "MAINT" 'YES'|'NO' Indicador sobre se a informação
dos dados de uma posição de
controlo é ou não mantida de forma
contínua.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Informação de Modo A do SSR
modecb '-' "MODEC" flightlevel Informação de Modo C do SSR
msgbody b '-' "MSGBODY" 1{CARACTER} Contém uma sequência de carac-
teres idêntica ao corpo da
mensagem não-ADEXP existente e
equivalente.
msgct b '-' "MSGCT" datetime ! seconds Hora impressa na mensagem no
formato: Dia, horas, minutos,
segundos.
nat b '-' "NAT" 1{ALFA}1 Identificação de um trajecto no
Atlântico Norte
nfcb '-' "NFC" 3{ALGARISMO}3 ! '.' !
3{ALGARISMO}3Frequência do próximo contacto.
nxtfir b '-' "NXTFIR" icaoaerodrome Próxima FIR a ser contactada.
nxtpos c'-' "NXTPOS" ptid | (lattd longtd) Próxima posição.
nxtpost b '-' "NXTPOST" datetime Hora sobre a próxima posição.oclfl b '-' "OCLFL" flightlevel Nível de voo do Limite de Sepa-
ração Oceânica (OCL).
oprfl b '-' "OPRFL" flightlevel Nível de Voo Solicitado modifi-
cado por um operador.
oprmk c'-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Lista de observações de um
Operador.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Observações de um Operador.
oriented b '-' "ORIENTED" 'YES'|'NO' Voo orientado ou não.
pfl b '-' "PFL" flightlevel Nível de Voo Planeado (PFL).2000R2082 — PT — 15.06.2002 — 001.001 — 136
▼B
Campo
Primário
ReservadoTipo Sintaxe Semântica
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistCoordenadas da trajectória radar e
coordenadas do vector velocidade.
pistid b '-' "PISTID" 1{ALGARISMO}4 Identificação da trajectória radar.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Posição de estacionamento para um
voo que chega.
pkdep b '-' "PKDEP" 1{ALFANUM}3 Posição de estacionamento para um
voo que parte.
plnid b '-' "PLNID" 4{ALGARISMO}4 Identificação do Plano de Voo.plnold b '-' "PLNOLD" 4{ALGARISMO}4 Identificação de um Plano de Voo
antigo.
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Estado do movimento de coorde-
nação para a posição:
Movimento Aceite para a Entrada
(MAE) ou para a saída (MAS) ou
Movimento Proposto para a Saída
(MPS) ou Alarme do Movimento
Proposto para a Saída (MPSA) ou
posição cujo movimento ainda não
foi coordenado (NO).
ptnb b '-' "PTNB" 1{ALGARISMO}2 Número de pontos na rota.qfu b '-' "QFU" qfuid Identificação da pista em uso
(QFU)
quebecb '-' "QUEBEC" 'YES'|'NO' Voo do Quebec ou não.radioid b '-' "RADIOID" 1{ALFANUM}20 Identificação rádio.reqid b '-' "REQID" 1{ALGARISMO}5 Número de um pedido.reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Tipo do pedido de plano de voo.ripel c'-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Lista das entidades que devem
receber a informação do plano de
voo.
ripsrc b '-' "RIPSRC" centreidentification Identificação do centro responsável
pelo início da transmissão da infor-
mação do plano de voo.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' Número da transacção IFPS num
pedido de plano de voo.
rte c'-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Lista dos pontos CAUTRA de uma
rota não dirigida.
rtetr c'-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Lista dos pontos de rota para
determinadas transacções.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Lista das configurações dos aeró-
dromos.
secdest b '-' "SECDEST" secidentification Identificador do sector receptor.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Lista Global de sectores.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Lista Global dos Sectores.
secsrc b '-' "SECSRC" secidentification Identificador do sector originador.
spfl b '-' "SPFL" flightlevel Nível de Voo Suplementar.ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Código SSR transmitido.
stamp b '-' "STAMP" 3{ALGARISMO}3 !
timehhmmIdentificação da impressão.
streason b '-' "STREASON" starreason Razão de um pedido de iniciali-
zação emitido a partir de uma
posição de trabalho.
strid b '-' "STRID" 1{ALGARISMO} Identificador RDPS.2000R2082 — PT — 15.06.2002 — 001.001 — 137
▼B
Campo
Primário
ReservadoTipo Sintaxe Semântica
temp b '-' "TEMP" temperature Temperatura.
terminal b '-' "TERMINAL" 1{ALFANUM}2 Nome do terminal.
translist c'-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Lista de transacções possíveis para
a posição de controlo e para o
plano de voo especificado.
trfl b '-' "TRFL" flightlevel | flightten-
dancyNível de Transferência do Voo ou
informação de tendência de um
perfil de voo.
turb b '-' "TURB" 1{ALFA}8 Turbulência = LIGEIRA ou
MODERADA ou SEVERA
validend b '-' "VALIDEND" datetime Hora final de visualização.
validst b '-' "VALIDST" datetime Hora inicial de visualização.
visi b '-' "VISI" 1{ALFANUM}20 Visibilidade.
wddir b '-' "WDDIR" 1{ALGARISMO}3 Direcção do vento expressa em
graus de 0 a 359.
wdspd b '-' "WDSPD" 1{ALGARISMO}3 Velocidade do vento expressa em
nós.
xfl b '-' "XFL" flightlevel Nível de Saída do Voo (XFL).
xfpltxt b '-' "XFPLTXT" 1{CARACTER |
ASCII_SUP}768Mensagem de resposta a um pedido
de plano de voo.
D.5.Subcampos Reservados
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Campos do plano de
voo que são modi-
ficáveis na altura da
activação de um voo.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxFL implícito, FL
mínimo e FL máximo
para o ponto de
referência numa tran-
sacção. O FL é gené-
rico, pode ser RFL,
PFL, etc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2O valor (+/-) pelo
qual é permitida uma
modificação horária
para um ponto.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxNível de Voo Autori-
zado Implícito (CFL),
CFL mínimo e CFL
máximo para o ponto
de referência numa
transacção.fieldid
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e código
atribuído.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e código
disponível para utili-
zação.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e código
previamente atri-
buído.ssrcodes2000R2082 — PT — 15.06.2002 — 001.001 — 138
▼B
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR e código
que foi reservado
para utilização, não
estando assim
disponível.ssrcodes
coorpt b '-' "COORPT" coor-
dpointsCaracterística de um
ponto de coorde-
nação: Inicial, Saída,
OCL, XFLptc
ctdest b '-' "CTDEST"
centreidentificationCentro receptor
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!AL-
GARISMOIntervalo de tempo
para o cálculo de um
tempo mínimo.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!AL-
GARISMOIntervalo de tempo
para o cálculo de um
tempo máximo.bktchg
deltsp1 b '-' "DELTSP1"
1{ALGARISMO}4Intervalo de veloci-
dade para o cálculo
de uma velocidade
mínima.spdchg
deltsp2 b '-' "DELTSP2"
1{ALGARISMO}4Intervalo de veloci-
dade para o cálculo
de uma velocidade
máxima.spdchg
destid c'-' "DESTID" c tdest
secripCentro ATC e lista
de sectores aos quais
o plano de voo deve
ser enviadoripel
edto b '-' "EDTO" dateti-
me|"WT"Hora estimada sobre
um ponto em ano,
mês, dia, horas,
minutos ou indicador
de «ponto sem
horas»«WT»ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationNome da «entidade»
operacional.eolist
eolist c'-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Lista de entidades
operacionais asso-
ciadas a uma posição
de controlo.eopos
eopos c'-' "EOPOS" posid
[eolist]Nome da posição de
controlo e lista das
entidades operacio-
nais associadas a essa
posição.confl
fieldid c'-' "FIELDID"
'TYPA'|'ADES'|'R-
TE'|'ADEP'|'CODE'|'-
LANG'|'BK'|spdchg|r-
flchg|cflchg|pflchg|tf-
lchg|sflchg|xflchg|bk-
chg|bktchg|'QFU'|'PK-
DEP'|'SID'|'NFC'|'A-
TIS'|'DCRM-
K'|'OPRMK'Identificação dos
campos modificáveis
numa transacção.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Nível de voo calcu-
lado no ponto de
saída de coordenação
que pode ser transmi-
tido para o próximo
centro na mensagem
de coordenação
automática.automsg2000R2082 — PT — 15.06.2002 — 001.001 — 139
▼B
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
flimp b '-' "FLIMP" flight-
levelNível de voo implí-
cito.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" flight-
levelNível de voo
máximo.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" flight-
levelNível de voo mínimo. bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c'-' "FPIDENT" plnid
stamp ctrow entrnbIdentificação do
plano de voo numa
mensagem.fpunkl
fpkwl
fpllgr c'-' "FPLLGR" arc i-
datcarc id adep ades
eobd eobtInformação
«sumária» do plano
de voo.fpllist
fpsum c'-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidIdentificação do
plano de voo.fplist
lalg c'-' "LALG" lattd
longtdLatitude e longitude
de cada ponto na
rota.laglist
mod c'-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Lista de campos
modificáveis após
activação.transid
modh c'-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Lista de campos que
são modificáveis
numa transacção de
actualização temporal
após activação.transid
mvt c'-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Lista de campos que
são modificáveis
numa coordenação
entre sectores despo-
letada manualmentetransid
pflchg c '-' "PFLCHG" flimp
flmin flmaxNível implícito,
mínimo e máximo
para uma modifi-
cação de PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Nível de voo
planeado que será
transmitido na
mensagem de coor-
denação automática
para o próximo
centro. Mais uma
indicação sobre se o
nível está em confor-
midade com os
acordos operacionais
aplicáveis.
NA = Não está em
conformidade com os
acordosautomsg2000R2082 — PT — 15.06.2002 — 001.001 — 140
▼B
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
pka b '-' "PKA"
1{ALFANUM}3Posição de estaciona-
mento reservada,
ainda não atribuída.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indicador de que a
aeronave está à
espera de uma
posição de estaciona-
mento.pkarr
pkcb '-' "PKC"
1{ALFANUM}3Posição de estaciona-
mento atribuída.pkarr
pointid b '-' "POINTID" point-
cautraEspecífico do Sistema
Francêsptpro
posid b '-' "POSID" positioni-
dentificationNome da posição de
controlo.eopos
ptcc '-' "PTC" ptc id edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Características de um
ponto na rota.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameEspecífico do Sistema
Francêsautomsg ptc
ptpro c'-' "PTPRO" pointid
[edto] [fl] [traj]Descrição dos pontos
de rota propostos.rtetr
qful c'-' "QFUL" qfuid QFU válido para uma
dada pista num aeró-
dromo.qfulist
qfulist c'-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Lista de QFU válidos
para um aeródromo.acnf
rcnf b '-' "RCNF"
1{ALFA}5Direcção geral de
descolagem e ater-
ragem num aeró-
dromo. (Este, Oeste,
etc.)acnf
ref c'-' "REF" (refi-
d|ref1id)Características de um
ponto de referência
para uma transacção.ptc
refid b '-' "REFID"
'REF'!2{ALGA-
RISMO}2Identificação de um
possível ponto de
referência para uma
transacção.ref
ref1id b '-' "REF1ID"
'REF'!2{ALGA-
RISMO}2Identificação do
ponto de referência
mais provável para
uma transacção.ref
regulid1 b '-' "REGULID1"
1{ALFANUM}5Informação regula-
mentar específica dos
sistemas Franceses.regul
regulid2 b '-' "REGULID2"
1{ALFANUM}5Informação regula-
mentar específica dos
sistemas Franceses.regul
regult b '-' "REGULT" date-
timeInformação regula-
mentar específica dos
sistemas Franceses.regul
ret c'-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Lista de campos que
são modificáveis
numa transacção para
retornar a informação
do plano de voo à
sua situação anterior.transid2000R2082 — PT — 15.06.2002 — 001.001 — 141
▼B
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
rflchg c '-' "RFLCHG" flimp
flmin flmaxNível implícito,
mínimo e máximo
para a modificação
do RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Texto de uma obser-
vação do controlador.oprmk
secc '-' "SEC" sec id
[seccar]Identificação e carac-
terísticas dos sectores
ACC aos quais a
informação do plano
de voo deve ser
enviada.seclist secrip
seccar b '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Característica de um
sector ACC:
— Primeiro sector
(«F»)
— Último sector
(«L»)
— Aceite para
Entrada («M»)
— Sector origem da
«duplicação» («D»)sec
seccarct b '-' "SECCARCT"
('F'!('L'!('M'!('V'/
/NIL)/NIL)/NIL)/NIL)
/('L'! ('M'!('V'/NIL)/
/NIL)/NIL)
/('M'!('V'/NIL)/NIL)
/'V'Característica de um
sector de Área
Terminal:
— Primeiro sector
(«F»)
— Último sector
(«L»)
— Aceite para
Entrada («M»)secct
secct c '-' "SECCT" secid
[seccarct]Identificação e carac-
terísticas de sectores
de Área Terminal.seclistct
secid b '-' "SECID" seciden-
tificationIdentificação do
sector.secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Lista de entidades
receptoras (sectores
ou entidades de
controlo de partida/
/chegada) às quais a
informação de plano
de voo deve ser
enviada.destid
sendt b '-' "SENDT" datetime Hora para o envio de
uma mensagem de
coordenação.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxNível implícito,
mínimo e máximo
para modificação de
um Nível de Voo
Suplementar (SFL).fieldid
spdchg c '-' "SPDCHG" deltsp1
deltsp2Intervalos inferior e
superior de veloci-
dade para a modifi-
cação da velocidade
do plano de voo
durante uma tran-
sacção.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxNível implícito,
mínimo e máximo
para a modificação
de um Nível de
Transferência de Voo
(TFL).fieldid2000R2082 — PT — 15.06.2002 — 001.001 — 142
▼B
Subcampos
ReservadosTipo Sintaxe SemânticaUtilizado
no Campo
PrimárioUtilizado
no
Subcampo
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Características de um
ponto em relação à
trajectória de um
voo.
S = Ponto de sepa-
ração
M = Ponto de união
T = Ponto de través
A = Ponto STARptc
ptpro
transid b '-' " TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Identificação de
possível transacção
da posição de
controlo para este
plano de voo ou indi-
cação «NO» para
impossibilidade de
transacção.translist
txt b '-' "TXT"
1{LIM_CHAR}80Texto livre. freetxt
udpt b '-' "UDPT" update-
reasonÚltima actualização
originada pelo
operador e/ou pela
informação radar.ptc
view b '-' "VIEW"
('V'|'VNX')Indicação da natureza
«visível» de um
ponto.
V = visível
VNX = não visível
(ponto artificial)ptc
vxpist b '-' "VXPIST" ALFA
1{ALGARISMO}5
ALFA:= P|N
P:= Positivo
N:= NegativoCoordenada X do
vector velocidade de
uma posição radar.pistcoord
vypist b '-' "VYPIST" ALFA
1{ALGARISMO}5
ALFA:= P|N
P:= Positivo
N:= NegativoCoordenada Y do
vector velocidade de
uma posição radar.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxNível máximo e
mínimo para modifi-
cação de um Nível de
Saída de um Voo
(XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{ALGARISMO}6
P:= Positivo
N:= NegativoCoordenada X de
uma posição radar.pistcoord
ypist b '-' "YPIST" 'P'|'N'
1{ALGARISMO}6
ALFA:= P/N
P:= Positivo
N:= NegativoCoordenada Y de
uma posição radar.pistcoord2000R2082 — PT — 15.06.2002 — 001.001 — 143
▼B
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.
a3.
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 opcio-
nais, pode ser encontrada no Documento Ref.a3.
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 9803051231522000R2082 — PT — 15.06.2002 — 001.001 — 144
▼B
-PT -PTID LOTEE -FL F330 -ETO 980305124401
-PT -PTID AVS -FL F330 -ETO 980305125357
-PT -PTID KORET -FL F330 -ETO 980305130137
-PT -PTID BARKO -FL F330 -ETO 980305130734-PT -PTID CANAR -FL F330 -ETO 980305131544-PT -PTID VIS -FL F330 -ETO 980305132220-PT -PTID FTM -FL F234 -ETO 980305133230-PT -PTID LPPT -FL F000 -ETO 980305134529-END RTEPTS-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT
UR107 QPR AVS
-ATSRT UG41 AVS FTM
E.2.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 Aero-
naves 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.
a5.
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 opcio-
nais, pode ser encontrada no Documento Ref.a5.
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.a5.
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á encon-
trada no Documento Ref.a5
Exemplo:
Primeira Mensagem de Activação do Sistema
-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — PT — 15.06.2002 — 001.001 — 145
▼B
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.a6.
E.3.3. Composição dos Campos Primários
Todo o material de definição para estas mensagens encontra-se no
Documento Ref.a6.
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 temporaria-
mente 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.a7.
E.4.3. Composição dos Campos Primários
Todo o material de definição para estas mensagens encontra-se no
Documento Ref.a7.
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 LP2000R2082 — PT — 15.06.2002 — 001.001 — 146
▼B
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600
199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830
199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030
199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL
-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700
199803291330
-END LACDR
E.5.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.a7.
E.5.3. Composição dos Campos Primários
Todo o material de definição para estas mensagens encontra-se no
Documento em Ref.a7.
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 0122000R2082 — PT — 15.06.2002 — 001.001 — 147
▼B
ANEXO F (Informativo)
EXEMPLOS DO FORMATO DE MENSAGENSADEXP
Os exemplos seguintes são apresentados como demonstração do formato
ADEXP e não como exemplo do conteúdo das mensagens. A mensagem utili-
zada é 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 represen-
taçõ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 TALAS2000R2082 — PT — 15.06.2002 — 001.001 — 148
▼B
-ALTRNT1 LBSF
-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500-PT -PTID NDG -FL F311 -ETO 9803173414
-PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130-PT -PTID MUN -FL F330 -ETO 980317074449-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830-PT -PTID DIMLO -FL F330 -ETO 980317081443-PT -PTID BABIT -FL F330 -ETO 980317083107
-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054-PT -PTID KLENA -FL F330 -ETO 980317084204-PT -PTID VAL -FL F330 -ETO 980317084629-PT -PTID KAVOR -FL F330 -ETO 980317085329
-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650-PT -PTID PEP -FL F312 -ETO 980317091414-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS
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 -PTID2000R2082 — PT — 15.06.2002 — 001.001 — 149
▼B
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 TALAS2000R2082 — PT — 15.06.2002 — 001.001 — 150
▼B
ANEXO G (Informativo)
DESENVOLVIMENTOSFUTUROS
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 desco-
nhecido 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 comple-
xidade, sempre que seja necessário encaixar um terceiro ou mesmo um
quarto nível de campos. (A Mensagem de Atribuição de Rota Condi-
cional (CRAM) é um exemplo actual deste requisito). Hoje em dia, a
ADEXP oferece a possibilidade de construir uma mensagem com qual-
quer 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 conce-
bidas por forma a garantir que um analisador lexical ou sintáctico seja
permanentemente capaz de determinar onde se encontra dentro da estru-
tura 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 fimde 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
Formato Actual Formato Proposto
Exemplo de um Campo Básico: -RFL F330 (RFL F330)Exemplo de um Campo Composto: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430)2000R2082 — PT — 15.06.2002 — 001.001 — 151
▼B
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)2000R2082 — PT — 15.06.2002 — 001.001 — 152
▼B
ÍNDICE
DIREITOS DE AUTOR
PREFÁCIO1. INTRODUÇÃO2. ÂMBITO3. REFERÊNCIAS
3.1. Introdução3.2. Referências
4. DEFINIÇÕES, SÍMBOLOS E ABREVIATURAS
4.1. Definições4.2. Símbolos e Abreviaturas4.3. Notações
5. GENERALIDADES TÉCNICAS
5.1. Pilha de Protocolos5.2. Estrutura do Perfil5.3. Relação com as Versões Anteriores da Especificação
6. REQUISITOS DOS PERFIS
6.1. Requisitos de Conformidade6.2. Requisitos da Camada superior6.3. Requisitos da Camada inferior6.3.1. Requisitos da Camada de Transporte6.3.2. Requisitos da Camada de Rede6.3.3. Requisitos da Camada de Ligação de Dados6.3.4. Requisitos da Camada Física
7. MÉTODOS DE ENSAIOANEXO A (NORMATIVO) PROTOCOLO DE TRANSFERÊNCIA DE MENSAGENS
A.1. IntroduçãoA.2. Serviço ImplementadoA.3. Serviço AssumidoA.4. Especificação do ProtocoloA.4.1. IntroduçãoA.4.2. Tipos de DadosA.4.3. Estabelecimento da AssociaçãoA.4.4. Transferência de dadosA.4.5. Libertação Ordenada da AssociaçãoA.4.6. Restabelecimento da AssociaçãoA.4.7. Integridade da AssociaçãoA.4.8. Libertação Desordenada da AssociaçãoA.4.9. Recuperação de uma Falha2000R2082 — PT — 15.06.2002 — 001.001 — 153
▼B
A.4.10. Formatos das Mensagens
A.5. Tabelas de Transição dos Estados do ProtocoloA.5.1. Introdução
A.5.2. Definições dos estados
A.5.3. Eventos PossíveisA.5.4. TemporizadoresA.5.5. Tabela de Transição de EstadosA.5.6. Diagrama de Transição dos Estados
ANEXO B (NORMATIVO) PROTOCOLO DO CABEÇALHO DAS MENSAGENS
B.1. IntroduçãoB.2. Serviço ImplementadoB.3. Serviço AssumidoB.4. Especificação do ProtocoloB.4.1. Estabelecimento da LigaçãoB.4.2. Evitação de Ligações de Rede RedundantesB.4.3. Libertação da LigaçãoB.4.4. Transferência de Dados
ANEXO C (NORMATIVO) PROTOCOLO DE REDE
C.1. IntroduçãoC.2. Serviço PrestadoC.3. Serviço AssumidoC.4. Endereçamento NSAPC.4.1. IntroduçãoC.4.2. Estrutura dos Endereços NSAPC.4.3. Atribuição de Selectores e Identificadores das Unidades ATCC.5. Especificação do ProtocoloC.5.1. GeneralidadesC.5.2. Codificação dos EndereçosC.5.3. Codificação do Campo Dados de Utilizador
C.5.4. Tratamento dos Endereços nos Pacotes INCOMING CALL
C.5.5. Transferência de Dados
ANEXO D (NORMATIVO) PRÓ-FORMAS PICS ESPECÍFICOS DO PERFIL
D.1. Introdução
D.2. Instruções para o Preenchimento dos Pró-formas PICS
D.2.1. Estrutura Geral dos Pró-formas PICSD.2.2. Informação AdicionalD.2.3. Informação de ExcepçãoD.2.4. Itens CondicionaisD.3. Pró-forma PICS para o Protocolo de Transferência de MensagensD.3.1. Abreviaturas e Símbolos Especiais2000R2082 — PT — 15.06.2002 — 001.001 — 154
▼B
D.3.2. Identificação
D.3.3. Implementação do Protocolo
D.4. Pró-forma PICS para o Protocolo do Cabeçalho das MensagensD.4.1. Abreviaturas e Símbolos EspeciaisD.4.2. IdentificaçãoD.4.3. Implementação do ProtocoloD.5. Pró-forma PICS para o Protocolo de RedeD.5.1. Abreviaturas e Símbolos EspeciaisD.5.2. Identificação
D.5.3. Implementação do Protocolo
ANEXO E (NORMATIVO) LISTA DE REQUISITOS DO PERFIL
E.1. Introdução
E.2. A função dos Pró-formas PRL e PICSE.3. NotaçãoE.4. Instruções para o Preenchimento dos Pró-formas PICSE.5. ReferênciasE.6. Declaração de ConformidadeE.6.1. Generalidades sobre a ConformidadeE.6.2. Requisitos Dinâmicos de ConformidadeE.7. Requisitos da Camada Superior
E.8. Requisitos da Camada Inferior
E.8.1. Requisitos da Camada de TransporteE.8.2. Requisitos da Camada de RedeE.8.3. Requisitos da Camada de Ligação de DadosE.8.4. Requisitos da Camada Física
ANEXO F (INFORMATIVO) METODOLOGIA DO ENSAIO DE CONFORMIDADE
F.1. IntroduçãoF.2. Âmbito e FinalidadeF.3. BibliografiaF.4. Métodos e Práticas de Desenvolvimento
F.5. Ensaios
F.5.1. IntroduçãoF.5.2. Ensaio das Camadas Inferiores (Camadas 1-3)F.5.3. Ensaio da Camada de AplicaçãoF.5.4. CertificaçãoF.5.5. Notificação
ANEXO G (INFORMATIVO) ATRIBUIÇÃO DE CÓDIGOS IDENTIFICADORES DAS
UNIDADES ATC
ANEXO H (INFORMATIVO) ORIENTAÇÕES SOBRE FIABILIDADE, DISPONIBILIDADE E
SEGURANÇA2000R2082 — PT — 15.06.2002 — 001.001 — 155
▼B
H.1. Introdução
H.2. Finalidade e ÂmbitoH.3. Bibliografia
H.4. Implementações sobre Linhas Alugadas
H.4.1. FiabilidadeH.4.2. DisponibilidadeH.4.3. SegurançaH.4.4. Exemplo de ConfiguraçãoH.5. Implementação de RedeH.5.1. FiabilidadeH.5.2. DisponibilidadeH.5.3. SegurançaH.6. Orientações Gerais sobre Linhas Alugadas e Implementações de RedeH.6.1. FiabilidadeH.6.2. DisponibilidadeH.6.3. Gestão de SistemasH.6.4. Exemplo de Configuração2000R2082 — PT — 15.06.2002 — 001.001 — 156
▼B
INFORMAÇÃO RELATIVAAOS 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.2000R2082 — PT — 15.06.2002 — 001.001 — 157
▼B
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 procedi-
mentos 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 Infor-
maçã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 alte-
raçõ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 Docu-
mentos 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 Normativosdo 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;
—A s declarações recomendadas utilizam o verbo chave
«deveria» e foram impressas em itálico, sendo o estado indi-
cado pelo prefixo Recomendação .
5.3. Qualquer outra informação considerada essencial para a interpre-
taçã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 imediata-
mente 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 — Normativo2000R2082 — PT — 15.06.2002 — 001.001 — 158
▼B
— 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.2000R2082 — PT — 15.06.2002 — 001.001 — 159
▼B
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 proprie-
tá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 hard-
ware 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 dehardware 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 intero-
perabilidade, 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 poste-
rior, 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 aplica-
cionais, 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 mensa-
gens de informação relacionadas com voos entre Centros deControlo 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 infe-
riores (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.
o001-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.2000R2082 — PT — 15.06.2002 — 001.001 — 160
▼B
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
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 Eurocon-
trol.
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 Norma-
tivo 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 dedi-
cated 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 Inter-
nacionais: — Parte 1: Organização) (2.aedição).2000R2082 — PT — 15.06.2002 — 001.001 — 161
▼B
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 taxo-
nomia dos Perfis Normalizados Internacionais: — Parte 2:
Princípios e Taxonomia dos Perfis OSI) (3.aediçã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
publicdata networks» (Interfac e entre equipamentos termi-
nais 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 isdesigned 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 — Telecom-
munications 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.
aedição).
7. ISO/IEC 8208:1993, «Information Technology — Data
communications — X.25 Packet Layer Protocol for Data
Terminal Equipment» (Tecnologia da informação — Comu-
nicações de dados — Protocolo da Camada de Pacotes X.25
para Equipamento Terminal de Dados) (3.aediçã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
BasicModel» (Tec nologia da informação — Interligação de
Sistemas Abertos — Modelo de Referência Básico: O
Modelo Básico) (2.aediçã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.aediçã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.aedição).
12. ISO/IEC 8878:1992, «Information Technology — Telecom-
munications 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.aedição).
13. «Eurocontrol Standard for On-Line Data Interchange»
(Norma do Eurocontrol para o Intercâmbio de Informação
em Tempo Real (OLDI)), N.o001-92, 1.aEdição, 1992.
14. ISO/IEC 9646-1:1994, «Information technology — Open
Systems Interconnection — Conformance testing methodo-
logy and framework — Part 1: General concepts»2000R2082 — PT — 15.06.2002 — 001.001 — 162
▼B
(Tecnologia da informação — Interligação de Sistemas
Abertos — Organização e metodologia dos ensaios de
conformidade — Parte 1: Conceitos gerais) (2.aedição).
15. ICD FDE do Eurocontrol (Divisão de Sistemas de Controlo
da Área Superior (UAC) de Maastricht), 1.aParte, 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, Availabi-
lity 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-swit-
ched signalling system between public network providing
data transmission service» (Sistema de sinalização de comu-
taçã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 publicdata networks» (Plano de nume-
raçã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 Eurocon-
trol, 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 reali-
zaçã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 implemen-
tadas para um determinado protocolo OSI [Referência 14].
4.2. Símbolos e Abreviaturas
Para os efeitos do presente Documento Normativo do Eurocon-
trol, utilizam-se os seguintes símbolos e abreviaturas:
ACC Centro de Controlo de Área
AFI Identificador do Formato e da AutoridadeASCII Código Normalizado Americano para o
Intercâmbio de Informação
ATC Controlo do Tráfego Aéreo
ATCC Centro de Controlo do Tráfego Aéreo
CAUTRA Coordinateur Automatique du TraficAérien
(Coordenador Automático do Tráfego
Aéreo)2000R2082 — PT — 15.06.2002 — 001.001 — 163
▼B
CCITT Comité consultatif international télégra-
phique et téléphonique (actualmente ITU-T)
(Comité Consultivo Internacional Tele-
gráfico e Telefónico)
CFMU Unidade Central de Gestão de TráfegoCUG Grupo Fechado de Utilizadores
DCE Equipamento de Terminação do Circuito de
Dados
DCTS Sistema Terminal de Comunicações DigitaisDSP Parte Específica do Domínio
DTE Equipamento Terminal de Dados
DÜV Datenübertragungs- und Verteilungssystem
FDE Intercâmbio de Informação de Voo
FEP Processador FrontalFPDE Intercâmbio de Informação relativa a Planos
de Voo
FPPS Sistema de Processamento de Planos de Voo
ICAO Organização da Aviação Civil Internacional
ICD Documento de Controlo do InterfaceIDI Identificador do Domínio Inicial
IDP Parte do Domínio Inicial
IEC Comissão Electrotécnica InternacionalINTERCAUTRA Protocolo Inter-CAUTRAISO Organização Internacional de NormalizaçãoITU-T União Internacional das Telecomunicações
— Sector de Normalização das Telecomuni-
cações
RDIS Rede Digital com Integração de Serviços
LAPB Equilíbrio dos Procedimentos de Acesso ao
Circuito
LSB Bit Menos Significativo
M, m Obrigatório
MSB Bit Mais Significativo
MT Transferência de Mensagens
NA Não Aplicável
NS Serviço de RedeNSAP Ponto de Acesso ao Serviço de RedeNSDU Unidade de Dados do Serviço de Rede
O, O.<n> Opcional, onde <n> é um número de
referência
o, o.<n> Opcional, onde <n> é um número de
referência
OLDI Intercâmbio de Informação em Tempo RealOSI Interligação de Sistemas Abertos
PICS Declaração de Conformidade com a Imple-
mentação do Protocolo
PLP Protocolo da Camada de PacotesPRL Lista de Requisitos do PerfilPSTN Rede Telefónica Pública Comutada
ST-ICD Documento de Controlo do Interface a Curto
Prazo
SUT Sistema Sob Ensaio
T<x> Temporizador (onde <x> é uma letra
simples ou dupla para efeitos de referência)
TA Adaptador de Terminal
TSDU Unidade de Dados do Serviço de TransporteTPDU Unidade de Dados do Protocolo de Trans-
porte
TR Relatório Técnico da ISO
X Proibido
x Excluído2000R2082 — PT — 15.06.2002 — 001.001 — 164
▼B
<item>: Item Condicional (dependente do valor do
item)
4.3. Notações
4.3.1. Para os efeitos do presente Documento Normativo do Eurocon-
trol, 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 Eurocon-
trol, a representação hexadecimal de uma sequência de bits é
formada tomando 4 bits de cada vez desde o bit mais significa-
tivo (MSB) até ao bit menos significativo (LSB).
NOTA Salvo se especificado em contrário nas Normas interna-
cionais 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 Eurocon-
trol, 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ís-
ticas das normas base que são condicionais, opcionais,
ou dependentes de valores (ver E.3.1).
5. GENERALIDADESTÉ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 OSIcorrespondentes. 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 OSIdas camadas OSIcorrespondentes.2000R2082 — PT — 15.06.2002 — 001.001 — 165
▼B
Figura 2
Pilha de Protocolos do Perfil
5.2. Estrutura do Perfil
NOTAS1. 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 Norma-
tivo 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 requi-
sitos 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 Euro-
control 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 Auto-
ridade (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.2000R2082 — PT — 15.06.2002 — 001.001 — 166
▼B
Isto facilita a utilização de outros perfis-T quando tal se
tornar necessário para apoiar os requisitos FDE em desenvol-
vimento.
3. As partes da especificação ICD-ST que tratam do controlo dos
circuitos virtuais X.25 e da delimitação das mensagens aplica-
tivas, encontram-se agora no Protocolo de Cabeçalho das
Mensagens (Anexo B), que constitui uma camada de trans-
porte mínima para o FDE.
6. REQUISITOSDOS 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 estabele-
cidos 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 Trans-
porte (TSDU) até 4 097 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 4 096 octetos para os dados dos utiliza-
dores.
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 proto-
colo 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 é total-
mente 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.2000R2082 — PT — 15.06.2002 — 001.001 — 167
▼B
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 conformi-
dade 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.2000R2082 — PT — 15.06.2002 — 001.001 — 168
▼B
ANEXO A (Normativo)
PROTOCOLO DE TRANSFERÊNCIADE 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 mensa-
gens 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 Eurocon-
trol.
A.4.Especificação do Protocolo
A.4.1. Introdução
No texto que se segue, apenas se descreve a operação de uma asso-
ciaçã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.o001-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 Eurocon-
trol 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 Confir-
maçã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.
NOTAS1. 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.2000R2082 — PT — 15.06.2002 — 001.001 — 169
▼B
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 apli-
cações locais como remotas.
A.4.3.3. Em primeiro lugar, é necessário estabelecer uma ligação de trans-
porte 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_PEN-
DING 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-Asso-
ciaçã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 especifi-
cado em A.4.3.5, esta mensagem STARTUP é ignorada.
A.4.3.7. Uma vez trocadas as mensagens STARTUP, estabelece-se a asso-
ciaçã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;2000R2082 — PT — 15.06.2002 — 001.001 — 170
▼B
— no estado ASSOCIATION_PENDING, será transmitida uma
mensagem SHUTDOWN (mensagem de sistema), o tempori-
zador 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 inter-
face 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 respon-
sabilidade, 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 procedi-
mento 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 inac-
tividade 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 tempo-
rizador configurável Ts. Se o temporizador Ts expirar o tempo no
estado DATA_READY, será transmitida uma mensagem HEART-
BEAT (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 trans-
missã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.2000R2082 — PT — 15.06.2002 — 001.001 — 171
▼B
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_shut-
down 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
Todas as mensagens consistem de um campo de tipo inteiro
(«TYP») de 1 a 63, seguido do corpo da mensagem. O campo
«TYP» é codificado num octeto na forma de um caracter ASCII
adicionando '40'H à representação binária do campo (por exemplo,
o valor 3 é codificado como '43'H, caracter «C»). O corpo da
mensagem consiste de caracteres ASCII codificados um por octeto.
Isto conduz ao seguinte formato:
TYP Corpo da Mensagem
Octeto 1 octeto 2 …octeto n
A.4.10.2. Comprimento do Corpo da Mensagem
Serão suportados comprimentos até 4 096 octetos (inclusive) para o
corpo das mensagens.
A.4.10.3. Formatos das Mensagens de Sistema
As mensagens de sistema são codificadas com TYP = 4, codificado
como '44'H. O corpo da mensagem consiste de dois octetos, codifi-
cados da seguinte forma:
— Mensagem STARTUP: '3031'H (ASCII digits "01");
— Mensagem SHUTDOWN: '3030'H (ASCII digits "00");
— Mensagem HEARTBEAT: '3033'H (ASCII digits "03").
A.4.10.4. Outros Formatos de Mensagens
O campo TYP define o tipo de mensagem, codificado como descrito
abaixo:
— valor 1 (codificado como
'41'H)Mensagens operacionais;
— valor 2 (codificado como
'42'H)Mensagens de operador;
— valor 5 (codificado como
'45'H)Mensagens de estado.
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 mensa-
gens para transmissão.2000R2082 — PT — 15.06.2002 — 001.001 — 172
▼B
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
Estado Descrição do Estado Informação Adicional sobre o Estado
estado 0 IDLE Sem ligação de transporte
estado 1 READY Ligação de transporte estabelecida,
utilizador local inactivo, utilizador
remoto inactivo
estado 2 ASSOCIATION_PEN-
DINGLigação de transporte estabelecida,
utilizador local pronto, utilizador
remoto inactivo
estado 3 DATA_READY Utilizador local pronto, utilizador
remoto pronto
A.5.3. Eventos Possíveis
Tabela 2
Eventos Possíveis
Descrição do Aconte-
cimentoInformação Adicional sobre o Estado
L_data Indicação de que estão para ser enviados dados (mensagem Opera-
cional, de Operador ou de Situação) do utilizador local para o
utilizador remoto (primitiva MT-Pedido de Dados)
L_shutdown É dado um comando para parar o utilizador local (MT-Pedido de
Cancelamento)
L_startup É dado um comando para iniciar o utilizador local (MT-Pedido de
Associação)
R_data Indica terem sido recebidos dados do utilizador remoto (T-Indi-
cação de Dados, TYP ≠«Sistema»)
R_heartbeat É recebida uma mensagem HEARTBEAT do utilizador remoto
(T-Indicação de Dados, TYP = «Sistema», Código de Mensagem
= HEARTBEAT)
R_shutdown É recebida uma mensagem SHUTDOWN do utilizador remoto (T-
-Indicação de Dados, TYP = «Sistema», Código de Mensagem =
SHUTDOWN)
R_startup É recebida uma mensagem STARTUP do utilizador remoto (T-
-Indicação de Dados, TYP = «Sistema», Código de Mensagem =
STARTUP)
Ts_timeout Expiração do temporizador Ts
Tr_timeout Expiração do temporizador Tr2000R2082 — PT — 15.06.2002 — 001.001 — 173
▼B
Descrição do Aconte-
cimentoInformação Adicional sobre o Estado
TC_disconnect Foi recebida uma indicação de libertação da ligação de Transporte
(T-Indicação de Desligação)
TC_setup Evento (por exemplo, comando explícito, pedido da aplicação)
que causa uma primitiva T-Pedido de Ligação
A.5.4. Temporizadores
Tabela 3
Temporizadores
Temporizador Informação do Temporizador
Tr Expiração de tempo quando é esperada uma HEARTBEAT ou
uma mensagem de dados
Ts Expiração de tempo para o envio de uma HEARTBEAT para o
utilizador remoto
O valor destes temporizadores será de forma a que Tr = 2Ts +
tempo de trânsito
NOTA 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
Estado Evento Acções a Tomar Novo Estado
Estado 0 TC_setup A camada de transporte tenta esta-
belecer a(s) ligação(ões) da
camada inferior entre os utiliza-
dores locais e remotos; quando a
ligação tiver sido estabelecida com
sucesso, o utilizador é notifi-
cado (1)estado 1
TC_disconnect O sistema toma as acções
adequadas mas mantém-se no
estado 0estado 0
L_data Ignorado estado 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Ignorado (evento que não deve
ocorrer)estado 0
R_heartbeat
R_shutdown
R_startup2000R2082 — PT — 15.06.2002 — 001.001 — 174
▼B
Estado Evento Acções a Tomar Novo Estado
estado 1 L_startup O utilizador local envia uma
mensagem STARTUP ao utili-
zador remoto, iniciando-se o
temporizador Tr (2)estado 2
R_startup O utilizador local recebe uma
mensagem STARTUP do utili-
zador remoto, esta mensagem
STARTUP é ignorada uma vez
que ainda não ocorreu um eventoestado 1
L_data Ignorado estado 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Ignorado estado 1
Ts_timeout
L_shutdown A ligação de transporte é cance-
ladaestado 0
TC_disconnect O utilizador local é notificado de
que a ligação de transporte foi
desligada (por exemplo, devido a
um erro ou a uma desligação
remota)estado 0
estado 2 R_startup O utilizador local recebe uma
mensagem STARTUP do utili-
zador remoto; os temporizadores
Tr e Ts são iniciados; o utilizador
local é notificado de que os dados
podem ser enviados na associação
e a recepção da mensagem
STARTUP é explicitamente notifi-
cada através da resposta com outra
mensagem STARTUP (3)estado 3
Tr_timeout O utilizador local retransmite uma
mensagem STARTUP se não
receber uma mensagem STARTUP
do utilizador remoto dentro de um
intervalo de tempo especificado
Tr; o temporizador Tr é reiniciadoestado 2
L_startup Ignorado estado 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown O utilizador local é instruído para
parar a associação: é transmitida
uma mensagem SHUTDOWN, é
parado o temporizador Tr e a
ligação de transporte é libertadaestado 0
TC_disconnect O utilizador local é notificado de
que a ligação de transporte foi
desligada (por exemplo, devido a
um erro), o temporizador Tr é
parado e a associação é canceladaestado 02000R2082 — PT — 15.06.2002 — 001.001 — 175
▼B
Estado Evento Acções a Tomar Novo Estado
estado 3 L_data O temporizador Ts é reiniciado estado 3
R_data O temporizador Tr é reiniciado estado 3
R_heartbeat
R_startup Se for recebida uma mensagem
STARTUP do utilizador remoto,
isso é considerado como uma
confirmação de uma mensagem
STARTUP previamente enviada; o
temporizador Tr não é reiniciadoestado 3
Ts_timeout É enviada uma mensagem
HEARTBEAT e reinicia-se o
temporizador Tsestado 3
L_startup Ignorado estado 3 (4)
TC_setup
R_shutdown Para-se o temporizador Ts; é sina-
lizada uma MT-Indicação-de-
-Cancelamento ao utilizador localestado 2
Tr_timeout Para-se o temporizador Ts; é sina-
lizada uma MT-Indicação-de-
-Cancelamento ao utilizador local;
o temporizador Tr é reiniciadoestado 2
L_shutdown É transmitida uma mensagem
SHUTDOWN; os temporizadores
Tr e Ts são parados e é libertada a
ligação de transporteestado 0
TC_disconnect O utilizador local é notificado de
que a ligação de transporte foi
desligada (por exemplo, devido a
um erro); os temporizadores Tr e
Ts são parados e a associação é
canceladaestado 0
NOTAS
(1) Ao entrar no estado 0, pode considerar-se que se gera automaticamente o evento TC_setup.
(2) Apenas quando entra no estado 1 através de um evento TC_setup gerado automaticamente, tal
como descrito no estado 0, então o evento L_setup pode ser gerado automaticamente.
(3) Este método garante que uma mensagem STARTUP recebida de um utilizador remoto é sempre
confirmada por uma mensagem STARTUP.
(4) Algumas implementações existentes, anteriores ao presente Documento Normativo do Eurocontrol,
podem tratar este evento como TC_disconnect, ou seja, retornando ao estado 0.2000R2082 — PT — 15.06.2002 — 001.001 — 176
▼B
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 Estados2000R2082 — PT — 15.06.2002 — 001.001 — 177
▼B
ANEXO B (Normativo)
PROTOCOLO DO CABEÇALHO DASMENSAGENS
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 subcon-
junto 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ções1. 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 subca-
deias iniciais características, por exemplo '8800'H>'88'H).2000R2082 — PT — 15.06.2002 — 001.001 — 178
▼B
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 oestabelecimento 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 trans-
porte 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 Trans-
porte (TPDU) que é transferida pelo serviço de rede.
B.4.4.2. A TPDU deverá ter o seguinte formato, transmitido da esquerda para
a direita, pelo que a estrutura da mensagem definida em A.4.10.1
deve ser inserida nos campos de dados(1), dados(2)…dados(n).
STX LENG ADEST DEST AEMM EMM dados(1) ADRdados(2) …
dados(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
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/Karls-
ruhe, 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 carac-
teres 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 tama-
nhos até 4 105 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.2000R2082 — PT — 15.06.2002 — 001.001 — 179
▼B
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, excep-
tuando-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.
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;2000R2082 — PT — 15.06.2002 — 001.001 — 180
▼B
— o segundo par é um selector da unidade ATC, que pode ser utili-
zado para identificar um ponto terminal particular numa unidade
ATC.
C.4.2.5. A estrutura do endereço NSAP resultante encontra-se ilustrada
abaixo.
AFI DSP
48 Identificador da unidade
ATCSelector da unidade ATC
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 perti-
nente pertencente à Organização ou Administração ATC.
C.4.3.2. À data da preparação da presente Norma, a atribuição de identifica-
dores 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 é utili-
zada; 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 codi-
ficaçõ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 utili-
zando 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 transmi-
tidos todos os 16 octetos.
Tabela 1
Codificação do Campo Dados de Utilizador
Descrição do CampoSemi-Octeto de Mais
Alta OrdemSemi-Octeto de Mais
Baixa Ordem
Octeto 0: Identificação do protocolo bin (1000) bin (0100)2000R2082 — PT — 15.06.2002 — 001.001 — 181
▼B
Descrição do CampoSemi-Octeto de Mais
Alta OrdemSemi-Octeto de Mais
Baixa Ordem
Octeto 1: Tipo do código da mensagem bin (0010) bin (0000)
Octeto 2: Valor do código da mensagem (N
CR)bin (0000) bin (0001)
Octeto 3: Tipo de parâmetro = NSAP
chamadobin (1100) bin (1001)
Octeto 4: Comprimento do parâmetro bin (0000) bin (0110)
Octeto 5: Valor do parâmetro (1.oocteto) =
valor AFIbin (0100) bin (1000)
Octeto 6: Valor do parâmetro (2.oocteto) =
identificador da unidade ATCDígito de mais alta
ordemDígito de mais baixa
ordem
Octeto 7: Valor do parâmetro (3.oocteto) =
selector da unidade ATCDígito de mais alta
ordemDígito de mais baixa
ordem
Octeto 8: Tipo de parâmetro = NSAP
chamadorbin (1100) bin (1011)
Octeto 9: Comprimento do parâmetro bin (0000) bin (0110)
Octeto 10: Valor do parâmetro (1.oocteto)
= valor AFIbin (0100) bin (1000)
Octeto 11: Valor do parâmetro (2.oocteto)
= identificador da unidade ATCDígito de mais alta
ordemDígito de mais baixa
ordem
Octeto 12: Valor do parâmetro (3.oocteto)
= selector da unidade ATCDígito de mais alta
ordemDígito de mais baixa
ordem
Octeto 13: Reservado para utilização futura bin (0000) bin (0000)
Octeto 14: Reservado para utilização futura bin (0000) bin (0000)
Octeto 15: Reservado para utilização futura bin (0000) bin (0000)
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á vali-
dado 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.
NOTAS1. O endereço DTE chamado, se existir, num pacote INCOMING
CALL, se existir, pode ser opcionalmente validado por compa-
raçã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 implemen-
taçã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.2000R2082 — PT — 15.06.2002 — 001.001 — 182
▼B
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 compri-
mento 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.2000R2082 — PT — 15.06.2002 — 001.001 — 183
▼B
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á preen-
cher 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 proto-
colo 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 imple-
mentaçã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 interope-
ração com outra implementação (note-se que, enquanto a
interoperação não pode nunca ser garantida, a falha da interope-
raçã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 mate-
rial 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 apre-
sentar, 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áu-
sula 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 Decla-2000R2082 — PT — 15.06.2002 — 001.001 — 184
▼B
ração de Conformidade da Implementação do Protocolo para o proto-
colo 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 abran-
gendo 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 apre-
sentadas 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 quais-
quer 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 fornecedorescreverá 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>»: «
» na coluna Situação, em que
«<item>» é uma referência ao item que surge na primeira coluna da
tabela para um outro item, e «
» é 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 «
»: a coluna suporte deve ser preenchida da forma habi-
tual. 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.2000R2082 — PT — 15.06.2002 — 001.001 — 185
▼B
D.3.Pró-formaPICSparaoProtocolodeTransferênciadeMensagens
D.3.1. Abreviaturas e Símbolos Especiais
D.3.1.1. Símbolos de Situação
M: ObrigatórioO: 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.
— MTsy, MTop, MTst, MTor tipos de mensagens
— MAE, MAR, MCI, MDT,
MAVprocedimentos
— MEsu, MEsd, MEhb, MEty codificações
— MNmsg tamanho da mensagem
— Ts, Tr temporizadores
D.3.2. Identificação
2000R2082 — PT — 15.06.2002 — 001.001 — 186
▼B
D.3.3. Implementação do Protocolo
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 opcionalO.<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 assi-
nalado no <item> (ver D.2.4)
D.4.1.2. Abreviaturas
NA não aplicável2000R2082 — PT — 15.06.2002 — 001.001 — 187
▼B
D.4.1.3. 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.
— IHC1, IHC2, IHC3, IHC4,
IHCCestabelecimento da ligação
— IHR1, IHR2 libertação da ligação
— IHT1, IHTx transferência de dados— Tcr temporizador
D.4.2. Identificação
2000R2082 — PT — 15.06.2002 — 001.001 — 188
▼B
D.4.3. Implementação do Protocolo
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
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 de2000R2082 — PT — 15.06.2002 — 001.001 — 189
▼B
letras iniciais (em maiúsculas). Segue-se uma lista dessas iniciais,
pela ordem em que os grupos de itens aparecem no pró-forma PICS.
— SNDCP1 protocolo do campo ID
— NCRdae, NCRgae, NCCx,
NDRxparâmetros nas mensagens de
protocolo
— NCD1, NCD2, NCN1, NCN2 validação dos endereços— NDT transferência de dados
D.5.2. Identificação
2000R2082 — PT — 15.06.2002 — 001.001 — 190
▼B
D.5.3. Implementação do Protocolo
2000R2082 — PT — 15.06.2002 — 001.001 — 191
▼B
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 é equi-
valente) 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 paraa 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 Organi-
zaçã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 neces-
sidade 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 imple-
mentaçã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 satis-
fazer o requisito FDE e, assim, ajudar a ceder controlo às
administrações contratantes.
— Integração de produtos disponíveis no mercado na implemen-
taçã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 com2000R2082 — PT — 15.06.2002 — 001.001 — 192
▼B
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 aoutros 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
NOTAS1. 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» signi-
fica «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 <atri-
buto> (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 indi-
cado, 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 conformi-
dade 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.2000R2082 — PT — 15.06.2002 — 001.001 — 193
▼B
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 Recomen-
daçã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
2000R2082 — PT — 15.06.2002 — 001.001 — 194
▼B
E.6.2. Requisitos Dinâmicos de Conformidade
E.7.Requisitos da Camada Superior
Tabela 3
Protocolo de Transferência de Mensagens
Características da Norma BaseCaracterísticas do
Perfil
ItemProtocolo de Transferência
de MensagensReferências Situação ReferênciasSituaç-
ão
MTst — mensagens de
situaçãoA.4.2 O ox
MTor — mensagens de
operadorA.4.2 O ox
E.8.Requisitos da Camada Inferior
E.8.1. Requisitos da Camada de Transporte
Tabela 4
Protocolo do Cabeçalho das Mensagens
Características da Norma BaseCaracterísticas do
Perfil
ItemProtocolo do Cabeçalho das
MensagensReferências Situação ReferênciasSituaç-
ão
IHTx Utilização dos campos
ADEST, DEST,
AEMM, EMM e ADR
com valores diferentesde '40'HB.4.4 O ox
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»2000R2082 — PT — 15.06.2002 — 001.001 — 195
▼B
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
Características da Norma BaseCaracterísticas do
Perfil
ItemCaracterísticas Gerais dos
DTEReferências Situação ReferênciasSituaç-
ão
Serviço suportado:
Vs — chamada virtual O.1 m
Vp — circuito virtual
permanenteO.1 x
Ambientes suportados: 3, 3.2
Ec/3 — DTE/DCE(1993) O.2 6.3.2 o.2
Ec/8 — DTE/DCE(1988) O.2 6.3.2 o.2
Ec/4 — DTE/DCE(1984) O.2 6.3.2 o.2
Ec/0 — DTE/DCE(1980) O.2 6.3.2 o.2
Et/t — DTE/DTE numa
função fixa como DTEO.2 6.3.2 o.2
Et/c— DTE/DTE numa
função fixa como DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE com
selecção dinâmica de
função4.5 Vs: O.2 x
Numeração de
sequência de pacotes
suportada:
M8 — Módulo 8 13.2, 12.1.1,
Tabela 3O.3 m
M128 — Módulo 128 13.2, 12.1.1,
Tabela 3O.3 x
Funcionalidade de
utilizador opcional de
Número de Referência
suportada, para a atri-
buição alternativa de
Identificador de Canal
Lógico13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig. 31
RNa — sem reversão para a
utilização de gamas
de canais lógicos13.29.2.1 Et:O
¬Et:Xx
RNb — com possível
reversão para a
utilização de gamas
de canais lógicos13.29.2.1 Et:O
¬Et:Xx2000R2082 — PT — 15.06.2002 — 001.001 — 196
▼B
E.8.2.2. Procedimentos, Tipos e Formatos dos Pacotes
Tabela 6
Funções da Camada de Pacotes Independentes dos Canais Lógicos
Características da Norma BaseCaracterísticas do
Perfil
ItemFunções da Camada de
Pacotes Independentes dos
Canais LógicosReferências Situação ReferênciasSituaç-
ão
São suportadas as
seguintes funções da
camada de pacotes:
Z2s Envio de um pacote de
diagnóstico12.7, Tabela 24 Et:O
¬Et:Xx
Z4i Início da Funcionali-
dade de Registo em
Tempo Real:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— envio de REGIS-
TRATION REQUEST12.9.1
— recepção de
REGISTRATION
CONFIRMATION12.9.2, Tabela
10
Z4r Resposta a uma
Funcionalidade de
Registo em Tempo
Real:13.1, 13.1.1.1,
13.1.1.4Et:O –
— recepção de
REGISTRATION
REQUEST12.9.1
— envio de REGIS-
TRATION CONFIR-
MATION12.9.2, Tabela
10
Tabela 7
Estabelecimento da Chamada
Características da Norma BaseCaracterísticas do
Perfil
ItemEstabelecimento da
ChamadaReferências Situação ReferênciasSituaç-
ão
São suportadas
Chamadas Virtuais de
saída:5.2.1, 5.2.5,
Tabela 33
S1a — Selecção Rápida,
sem restrições na
resposta?5.2.4, 13.16 O x
S1b — Selecção Rápida,
com resposta limitada?13.16 O x
S1c— Sem Selec ção
Rápida?5.2.4 O m
SP1b CALL REQUEST,
formato básico12.2.3.1 S1c:M
S1ab: O.4m
SP1e envio de CALL
REQUEST, formato
alargado12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b recepção de CALL
CONECTED, formato
básico12.2.4.1 S1ac:M m
SP2e recepção de CALL
CONECTED, formato
alargado12.2.4.1,
12.2.4.2S1a:M –2000R2082 — PT — 15.06.2002 — 001.001 — 197
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemEstabelecimento da
ChamadaReferências Situação ReferênciasSituaç-
ão
É suportado o endereç-
amento alternativo nas
Chamadas Virtuais de
saída:13.28
— Utilizando A = 1 e
o formato expandido
do Bloco de Ende-
reços?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— Utilizando a
Funcionalidade de
Extensão do Endereço
Chamado?13.28.2.2. Ec/3:O
¬Ec/3:Xx
É suportada a entrada
de Chamadas Virtuais:5.2.2, 5.2.5,
Tabela 33
S2a — Selecção Rápida,
com aceitação
possível?5.2.3, 13.17 O –
S2b — Selecção Rápida,
sempre cancelada?13.17 O m
S2c— sem Selec ção
Rápida, com aceitação
possível?5.2.3 O m
S2d — sem Selecção
Rápida, sempre cance-
lada?5.2.3 O x
SP3b recepção de INCO-
MING CALL, formato
básico12.2.3.1 S2:M m
SP3e recepção de INCO-
MING CALL, formato
alargado12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b envio de CALL
ACCEPTED, formato
básico12.2.4.1 S2c:M
S2axc:
O.5m
SP4e envio de CALL
ACCEPTED, formato
alargado12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
É suportada a nego-
ciação do bit-D:
DN1 — para Chamadas
Virtuais de saída6.3 S1ac:O m
DN2 — para Chamadas
Virtuais de entrada6.3 S1ac:O m
NOTA O bit-D será sempre negociado a 0.
Tabela 8
Cancelamento da Chamada
Características da Norma BaseCaracterísticas do
Perfil
Item Cancelamento da Chamada Referências Situação ReferênciasSituaç-
ão
É suportado o cancela-
mento da chamada,
para:5.5.4, Tabela 332000R2082 — PT — 15.06.2002 — 001.001 — 198
▼B
Características da Norma BaseCaracterísticas do
Perfil
Item Cancelamento da Chamada Referências Situação ReferênciasSituaç-
ão
C1 — resposta à indicação
de cancelamento5.5.2 O m
C2a — cancelar uma tenta-
tiva de Chamada
Virtual de Saída?5.4, 5.5.1, 5.5.3 S1:O o
C2b — rejeitar uma
Chamada Virtual de
entrada?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd :
Om
C2c— dar origem ao
cancelamento de uma
Chamada Virtual esta-
belecida?5.5.1, 5.5.3 O o
CP1b recepção de CLEAR
INDICATION,
formato básico12.2.5.1 Cany:M m
CP1e recepção de CLEAR
INDICATION,
formato alargado12.2.5.1,
12.2.5.2Cany:M –
CP2b envio de CLEAR
CONFIRMATION,
formato básico12.2.6.1 C1:M m
CP2e envio de CLEAR
CONFIRMATION,
formato alargado12.2.6.1,
12.2.6.2C1rn:M x
CP3b envio de CLEAR
REQUEST, formato
básico12.2.5.1 C2a:M
C2bcxa:
O.6m
CP3e envio de CLEAR
REQUEST, formato
alargado12.2.5.1,12.2.5.2 C2bcxa:
O.6
C2axbc:
Xx
CP4b recepção de CLEAR
CONFIRMATION,
formato básico12.2.6.1 C2:M m
CP4e recepção de CLEAR
CONFIRMATION,
formato alargado12.2.6.1,
12.2.6.2C2rnci:M –
Tabela 9
Restabelecimento de Canais Lógicos
Características da Norma BaseCaracterísticas do
Perfil
ItemRestabelecimento de Canais
LógicosReferências Situação ReferênciasSituaç-
ão
É suportado o restabe-
lecimento:8, 8.4, Tabela 34
RSi — como originador? 8.1, 8.3 O mm
envio de RESET
REQUEST12.5.1
recepção de RESET
CONFIRMATION/
/INDICATION12.5.2, 12.5.12000R2082 — PT — 15.06.2002 — 001.001 — 199
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemRestabelecimento de Canais
LógicosReferências Situação ReferênciasSituaç-
ão
RSr — como receptor? 8.2 O mm
recepção de RESET
INDICATION12.5.1
envio de RESET
CONFIRMATION12.5.2
Tabela 10
Procedimentos de Erro
Características da Norma BaseCaracterísticas do
Perfil
ItemProcedimentos de Erro
(Serviço de Chamada
Virtual)Referências Situação ReferênciasSituaç-
ão
O procedimento
ERROR-C é:5.2.1, 5.4, 8.1,
Tabela 33
W1a — cancelar a Chamada
Virtual?O.7 m
W1b — restabelecer a
camada de pacotes?O.7 x
O procedimento
ERROR-R para
chamadas virtuais, é:6.3, 6.4, 6.6,
6.8.1, 6.8.2,
7.1.3, 7.1.4, 8.2,
11.2.1, 13.4.1,
Tabelas 34-36
W2sc— restabelec er a
camada de pacotes?O.8 x
Tabela 11
Interrupção da Transferência
Características da Norma BaseCaracterísticas do
Perfil
ItemInterrupção da Trans-
ferênciaReferências Situação ReferênciasSituaç-
ão
Is É suportado o envio de
interrupções?envio de
INTERRUPT
REQUESTOo x
recepção de INTER-
RUPT CONFIRMA-
TION12.3.2
6.8, 6.8.1, 6.8.3,
Tabela 3512.3.3
Ir É suportada a recepção
de interrupções?recepção de
INTERRUPT
REQUESTO–
— envio de INTER-
RUPT CONFIRMA-
TION12.3.2
6.8, 6.8.2, 6.8.3,
Tabela 3512.3.32000R2082 — PT — 15.06.2002 — 001.001 — 200
▼B
Tabela 12
Envio de Dados
Características da Norma BaseCaracterísticas do
Perfil
Item Envio de Dados Referências Situação ReferênciasSituaç-
ão
DS1 É suportado o envio de
pacotes DATA?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
É suportado o
seguinte:
DS2 — envio de rotação de
janela na recepção de
valores P(R) actuali-
zados?7.1, 7.1.2, 7.1.3 O mm
DS4a — envio de M = 0 nos
pacotes DATA?6.4, 6.5, 6.7 M mo.9
DS4b — envio de M = 1 nos
pacotes DATA?6.4, 6.5, 6.7 O mo.9
DS5a — envio de Q = 0 nos
pacotes DATA?6.6 O.10 mm
DS5b — envio de Q = 1 nos
pacotes DATA?6.6 O.10 ox
DS6 — resposta a pedidos
de retransmissão de
pacotes (pacotes
REJECT recebidos)?13.4.2 12.8 Et:O –
— Procedimento do
Temporizador de
Rotação da Janela:
DS7a — Acção ERROR-R
ao expirar11.2.1(a) O ox
DS7b — retransmissão do
pacote ao expirar11.2.1(b) Et:O
¬Et:Xox
DS8 — abandono dos
pacotes de controlo de
fluxo de comprimento
excessivo (em vez de
ERROR-R)?Tabela 36 Nota
2Oo x
Tabela 13
Recepção de Dados
Características da Norma BaseCaracterísticas do
Perfil
Item Recepção de Dados Referências Situação ReferênciasSituaç-
ão
DR1 É suportada a recepção
de pacotes DATA?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
É suportado o
seguinte:
DR2 — Recepção de
rotação de janela no
envio de valores P(R)
actualizados?7.1.2, 7.1.3 O mm
DR3 — Controlo de fluxo
através do envio de
RECEIVE NOT
READY e RECEIVE
READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m2000R2082 — PT — 15.06.2002 — 001.001 — 201
▼B
Características da Norma BaseCaracterísticas do
Perfil
Item Recepção de Dados Referências Situação ReferênciasSituaç-
ão
DR4b — Recepção de M = 1
nos pacotes DATA?6.4, 6.5, 6.7 O mm
DR5a — Recepção de Q = 0
nos pacotes DATA?6.6 O.11 mm
DR5b — Recepção de Q = 1
nos pacotes DATA?6.6 O.11 –
DR6 — Pedido de retrans-
missão de pacotes
através do envio de
pacotes REJECT?13.4.1, 12.8 O ox
— Recuperação da
recepção de pacotes
DATA contendo P(S)
inválidos, através de:
DR7a — acção ERROR-R? 11.3(a) O.12 mm
DR7b — pedido de retrans-
missão dos pacotes ?11.3(b) O.12 ox
DR7c— ignorar o pac ote e
esperar por um pacote
correctamente retrans-
mitido ?11.3(c) O.12 ox
— recuperação da
recepção de pacotes
DATA contendo
campos inválidos de
Dados de Utilizador,
através de:
DR8a — acção ERROR-R? 11.3(a) O.13 mm
DR8b — pedido de retrans-
missão dos pacotes ?11.3(b) O.13 ox
DR8c— ignorar o pac ote e
esperar por um pacote
correctamente retrans-
mitido ?11.3(c) O.13 ox
DR9 — Procedimento do
Temporizador de
Transmissão de
Situação da Janela?11.2.2 O ox
Tabela 14
Confirmação da Entrega
Características da Norma BaseCaracterísticas do
Perfil
Item Confirmação da Entrega Referências Situação ReferênciasSituaç-
ão
DC É suportada a Confir-
mação de Entrega?6.3, 6.5, 6.7,
7.1.4Ox2000R2082 — PT — 15.06.2002 — 001.001 — 202
▼B
E.8.2.3. Características e Opções Diversas
Tabela 15
Valores dos Códigos de Causa e Diagnóstico
Características da Norma BaseCaracterísticas do
Perfil
ItemValores dos Códigos de
Causa e DiagnósticoReferências Situação ReferênciasSituaç-
ão
Nos pacotes
RESTART REQUEST
enviados:12.6.1.1,
12.6.1.2,
Tabelas 24-25
Y1d — Causa = 128,
códigos de diagnóstico
privadosO.14 ox
Nos pacotes
RESTART INDICA-
TION recebidos:12.6.1.1, Tabela
9, 12.6.1.2
Y2b — Causa diferente de
0 ou 128, qualquer
código de diagnósticoEC:M
¬EC:Om
Nos pacotes CLEAR
REQUEST enviados:12.2.3.1.1,
12.2.3.1.2,
Tabela 24-25
Y3d — Causa = 128,
códigos de diagnóstico
privadosO.15 ox
Nos pacotes CLEAR
INDICATION rece-
bidos:12.2.3.1.1,
Tabela 7
12.2.3.1.2,
Y4b — Causa diferente de
0 ou 128, qualquer
código de diagnósticoEC:M
¬EC:Om
Nos pacotes RESET
REQUEST enviados:12.5.1.1,
12.5.1.2,
Tabelas 24-25
Y5d — Causa = 128,
códigos de diagnóstico
privadosO.16 ox
Nos pacotes RESET
INDICATION rece-
bidos:12.5.1.1, Tabela
8, 12.5.1.2
Y6b — Causa diferente de
0 ou 128, qualquer
código de diagnósticoEC:M
¬EC:Om
E.8.2.4. Funcionalidades
Tabela 16
Funcionalidades Enviadas nos Pacotes CALL REQUEST
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes PEDIDO DE
CHAMADAReferências Situação ReferênciasSituaç-
ão
FS1pi Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho do
pacote13.12, 15.2.2.1.1 O x
FS1wi Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho da
janela13.12, 15.2.2.1.2 O x2000R2082 — PT — 15.06.2002 — 001.001 — 203
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes PEDIDO DE
CHAMADAReferências Situação ReferênciasSituaç-
ão
FS2ib Negociação da Classe
de Débito Básica13.13,
15.2.2.2.1,
Tabela 20aOx
FS2ie Negociação da Classe
de Débito Alargada13.13,
15.2.2.2.2,
Tabela 20bOx
FS3b Selecção do Grupo
Fechado de Utiliza-
dores, formato básico13.14.6,
15.2.2.3.1Oo
FS3e Selecção do Grupo
Fechado de Utiliza-
dores, formato alar-
gado13.14.6,
15.2.2.3.2Ox
FS4b Grupo Fechado de
Utilizadores com
Selecção de Acesso de
Saída, formato básico13.14.7,
15.2.2.4.1Ox
FS4e Grupo Fechado de
Utilizadores comSelecção de Acesso de
Saída, formato alar-
gado13.14.7,
15.2.2.4.2Ox
FS5 Selecção Bilateral do
Grupo Fechado de
Utilizadores13.15, 15.2.2.5 O x
FS6a Selecção Rápida 13.16, 15.2.2.6 O x
FS6b Facturação Inversa 13.18, 15.2.2.6 O xFS6cSelec ção da Situação
ICRD13.25.4.2,
15.2.2.6Ox
FS7i Identificação do Utili-
zador da Rede13.21, 13.21.3,
15.2.2.7Ox
FS8i Informação de Factu-
ração, pedido de
serviço13.22, 15.2.2.8.1 O x
FS9b Selecção RPOA,
formato básico13.23, 13.23.2,
15.2.2.9.1Ox
FS9e Selecção RPOA,
formato alargado13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Selecção e Indicação
do Atraso do Trânsito13.27, 15.2.2.13 O x
FS99i Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1, Tabela 18 O x
FS98i Funcionalidades não-
-X.25 remotas, no
seguimento da Funcio-nalidade de Sinali-
zação15.1, Tabela 18 O x
FS20i Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pelo CCITT15.1 O x
FS21i Extensão do Endereço
Chamador14.1, 15.3.2.1 x
FS22i Extensão do Endereço
Chamado14.2, 15.3.2.2 x2000R2082 — PT — 15.06.2002 — 001.001 — 204
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes PEDIDO DE
CHAMADAReferências Situação ReferênciasSituaç-
ão
FS23ib Negociação da Classe
de Débito Mínima,
formato básico14.3, 15.3.2.3.1,
Tabela 20aOx
FS23ie Negociação da Classe
de Débito Mínima,
formato alargado14.3, 15.3.2.3.2,
Tabela 20bO
FS24i Negociação do Atraso
de Trânsito de Ponta-a-
-Ponta14.4, 15.3.2.4 O x
FS25i Negociação Expedita
dos Dados14.7, 15.3.2.7 O x
FS26i Prioridade 14.5, 15.3.2.5 O x
FS27i Protecção 14.6, 15.3.2.6 O x
Tabela 17
Funcionalidades Enviadas nos Pacotes CALL ACCEPTED
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes CALL
ACCEPTEDReferências Situação ReferênciasSituaç-
ão
FS1pr Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho do
pacote13.12,
15.2.2.1.1,
Tabela 13Ox
FS1wr Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho da
janela13.12,
15.2.2.1.2,
Tabela 13Ox
FS2rb Negociação da Classe
de Débito Básica13.13,
15.2.2.2.1,
Tabela 20aOx
FS2re Negociação da Classe
de Débito Alargada13.13,
15.2.2.2.2,
Tabela 20bOx
FS7r Identificação do Utili-
zador da Rede13.21, 13.21.3
15.2.2.7Ox
FS8r Informação de Factu-
ração, pedido de
serviço13.22, 15.2.2.8.1 O x
FS10r Notificação de Modifi-
cação do Endereço da
Linha Chamada13.26, 15.2.2.12 O x
FS99r Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1 Tabela 18 O x
FS98r Funcionalidades não-
-X.25 remotas, no
seguimento da Funcio-
nalidade de Sinali-
zação15.1, Tabela 18 O x
FS20r Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pelo CCITT15.1 O x2000R2082 — PT — 15.06.2002 — 001.001 — 205
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes CALL
ACCEPTEDReferências Situação ReferênciasSituaç-
ão
FS22r Extensão do Endereço
Chamado14.2, 15.3.2.2 O x
FS24r Negociação do Atraso
de Trânsito de Ponta-a-
-Ponta14.4, 15.3.2.4 O x
FS25r Negociação Expedita
dos Dados14.7, 15.3.2.7 O x
FS26r Prioridade 14.5, 15.3.2.5 O x
FS27r Protecção 14.6, 15.3.2.6 O x
Tabela 18
Funcionalidades Enviadas nos Pacotes CLEAR REQUEST
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Enviadas
nos Pacotes CLEAR
REQUESTReferências Situação ReferênciasSituaç-
ão
FS10d Notificação da Modifi-
cação do Endereço da
Linha Chamada13.26, 15.2.2.12 O x
FS13 Selecção do Desvio de
Chamada13.25.2.2,
15.2.2.10Ox
FS99d Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1, Tabela 18 O x
FS98d Funcionalidades não-
-X.25 remotas, no
seguimento da Funcio-
nalidade de Sinali-
zação15.1, Tabela 18 O x
FS20d Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pelo CCITT15.1 O x
FS22d Extensão do Endereço
Chamado14.2, 15.3.2.2 O x
Tabela 19
Funcionalidades Recebidas nos Pacotes INCOMING CALL
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes INCOMING
CALLReferências Situação ReferênciasSituaç-
ão
FR1pi Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho do
pacote13.12, 15.2.2.1.1 O x
FR1wi Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho da
janela13.12, 15.2.2.1.2 O x2000R2082 — PT — 15.06.2002 — 001.001 — 206
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes INCOMING
CALLReferências Situação ReferênciasSituaç-
ão
FR2ib Negociação da Classe
de Débito Básica13.13,
15.2.2.2.1,
Tabela 20aOx
FR2ie Negociação da Classe
de Débito Alargada13.13,
15.2.2.2.2,
Tabela 20bOx
FR3b Selecção do Grupo
Fechado de Utiliza-
dores, formato básico13.14.6,
15.2.2.3.1Oo
FR3e Selecção do Grupo
Fechado de Utiliza-
dores, formato alar-
gado13.14.6,
15.2.2.3.2Ox
FR4b Grupo Fechado de
Utilizadores comSelecção de Acesso de
Saída, formato básico13.4.7,
15.2.2.4.1Ox
FR4e Grupo Fechado de
Utilizadores com
Selecção de Acesso de
Saída, formato alar-gado13.4.7,
15.2.2.4.2Ox
FR5 Selecção Bilateral do
Grupo Fechado de
Utilizadores13.15, 15.2.2.5 O x
FR6a Selecção Rápida 13.16, 13.17,
15.2.2.6Ox
FR6b Facturação Inversa 13.18, 13.19,
15.2.2.6Ox
FR11 Notificação de Reen-
caminhamento de
Chamada ou de Desvio
de Chamada13.25.3,
15.2.2.11Ox
FR12i Selecção e Indicação
do Atraso do Trânsito13.27, 15.2.2.13 O x
FR99i Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1, Tabela 18 O x
FR20i Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pelo CCITT15.1 O x
FR21 Extensão do Endereço
Chamador14.1, 15.3.2.1 x
FR22i Extensão do Endereço
Chamado14.2, 15.3.2.2 x
FR23b Negociação da Classe
de Débito Mínima,
formato básico14.3, 15.3.2.3.1,
Tabela 20aOx
FR23e Negociação da Classe
de Débito Mínima,
formato alargado14.3, 15.3.2.3.2,
Tabela 20bOx
FR24i Negociação do Atraso
de Trânsito de Ponta-a-
-Ponta14.4, 15.3.2.4 O x
FR25i Negociação Expedita
dos Dados14.7, 15.3.2.7 O x
FR26i Prioridade 14.5, 15.3.2.5 O x2000R2082 — PT — 15.06.2002 — 001.001 — 207
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes INCOMING
CALLReferências Situação ReferênciasSituaç-
ão
FR27i Protecção 14.6, 15.3.2.6 O x
Tabela 20
Funcionalidades Recebidas nos Pacotes CALL CONECTED
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes CALL
CONECTEDReferências Situação ReferênciasSituaç-
ão
FR1pr Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho do
pacote13.12,
15.2.2.1.1,
Tabela 14Ox
FR1wr Negociação do Parâ-
metro de Controlo de
Fluxo, tamanho da
janela13.12,
15.2.2.1.2,
Tabela 14Ox
FR2rb Negociação da Classe
de Débito Básica13.13,
15.2.2.2.1,
Tabela 20aOx
FR2re Negociação da Classe
de Débito Alargada13.13,
15.2.2.2.2,
Tabela 20bOx
FR10r Notificação da Modifi-
cação do Endereço da
Linha Chamada13.26, 15.2.2.12 O x
FR12r Selecção e Indicação
do Atraso do Trânsito13.27, 15.2.2.13 O x
FR99r Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1, Tabela 18 O x
FR20r Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pelo CCITT15.1 O x
FR22r Extensão do Endereço
Chamado14.2, 15.3.2.2 O x
FR24r Negociação do Atraso
de Trânsito de Ponta-a-
-Ponta14.4, 15.3.2.4 O x
FR25r Negociação Expedita
dos Dados14.7, 15.3.2.7 O x
FR26r Prioridade 14.5, 15.3.2.5 O x
FR27r Protecção 14.6, 15.3.2.6 O x2000R2082 — PT — 15.06.2002 — 001.001 — 208
▼B
Tabela 21
Funcionalidades Recebidas nos Pacotes CLEAR INDICATION
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes CLEAR INDI-
CATIONReferências Situação ReferênciasSituaç-
ão
FR8ad Informação de Factu-
ração, unidade mone-
tária13.22, 15.2.2.8.2 O x
FR8bd Informação de Factu-
ração, contagem de
segmentos13.22, 15.2.2.8.3 O x
FR8cd Informação de Factu-
ração, duração da
chamada13.22, 15.2.2.8.4 O x
FR10d Notificação da Modifi-
cação do Endereço da
Linha Chamada13.26, 15.2.2.12 O x
FR99d Funcionalidades não-
-X.25 locais, no segui-
mento da
Funcionalidade de
Sinalização15.1, Tabela 18 O x
FR20d Funcionalidade de
Sinalização, funciona-
lidades DTE especifi-
cadas pela ITU-T15.1 O x
FR22d Extensão do Endereço
Chamado14.2, 15.3.2.2 O x
Tabela 22
Funcionalidades Recebidas nos Pacotes de CLEAR CONFIRMATION
Características da Norma BaseCaracterísticas do
Perfil
ItemFuncionalidades Recebidas
nos Pacotes CLEAR
CONFIRMATIONReferências Situação ReferênciasSituaç-
ão
FR8af Informação de Factu-
ração, unidade mone-
tária13.22, 15.2.2.8.2 O x
FR8bf Informação de Factu-
ração, contagem de
segmentos13.22, 15.2.2.8.3 O x
FR8cf Informação de Factu-
ração, duração da
chamada13.22, 15.2.2.8.4 O x
E.8.2.5. Valores e Gamas dos Parâmetros
Tabela 23
Valores e Gamas dos Parâmetros
Características da Norma BaseCaracterísticas do
Perfil
ItemValores e Gamas dos Parâ-
metrosReferências Situação ReferênciasSituaç-
ão
Que valores são supor-
tados:2000R2082 — PT — 15.06.2002 — 001.001 — 209
▼B
Características da Norma BaseCaracterísticas do
Perfil
ItemValores e Gamas dos Parâ-
metrosReferências Situação ReferênciasSituaç-
ão
V1s — Tamanhos assu-
midos dos pacotes
(envio)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octetos6.3.2 Pelo
menos
128 e
256
V1r — Tamanhos assu-
midos dos pacotes
(recepção)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096
octetos6.3.2 Pelo
menos
128 e
256
V2s — Tamanhos assu-
midos das janelas,
envio?16.2.2.6 (M8: na
gama de
1-7)2
V2r — Tamanhos assu-
midos das janelas,
recepção?16.2.2.6 (M8: na
gama de
1-7)2
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
Características da Norma BaseCaracterísticas do
Perfil
ItemProtocolo da Ligação de
DadosReferências Situação ReferênciasSituaç-
ão
Lm Procedimento Multili-
gação6O o x
LcOperação DTE/DCE 1, 5.1 M mo.1
Lt Operação DTE/DTE 1, 5.1 O mo.1
M8 Operação básica
(Módulo 8)1, 3, 4.1.1 O.1 mm
M128 Operação alargada
(Módulo 128)1, 3, 4.1.1 O.1 ox
T4 Procedimento do
Temporizador T45.3.2, 5.6.1 O mm
SPN1 Número máximo (N1)
de bits numa trama-I5.7.3 N1 ≥
1 080N1≥
2 104
SPk Número máximo de
tramas pendentes (k)5.7.4 1 ≤k≤
7k=7
E.8.4. Requisitos da Camada Física
Consultar a cláusula A.4 da ISO/IEC TR 10609-9 [Referência 8].2000R2082 — PT — 15.06.2002 — 001.001 — 210
▼B
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 conformi-
dade 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 inter-
face 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 determi-
nadas 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 apli-
caçõ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 funciona-
mento 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 Euro-
control. Os pró-formas PICS e as PRL evocados por esta
especificação do perfil podem servir de base aos ensaios de conformi-
dade; 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 utili-
zaçã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, desenvol-
vida pelo Eurocontrol.2000R2082 — PT — 15.06.2002 — 001.001 — 211
▼B
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 encon-
trarem 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 Inte-
graçã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.2000R2082 — PT — 15.06.2002 — 001.001 — 212
▼B
ANEXO G (Informativo)
ATRIBUIÇÃO DE CÓDIGOS IDENTIFICADORES DAS UNIDADES
ATC
A tabela seguinte mostra os códigos identificadores das unidades ATC atri-
buí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 codi-
ficação de endereços NSAP definida no Anexo C.
Tabela 1
Códigos Identificadores das Unidades ATC
Código Identificador da
Unidade ATCCódigo Descrição
00 Reservado
01 '01'H CATCAS, Copenhaga
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Frankfurt/Main
04 '04'H CANAC Bruxelas
05 '05'H CAUTRA genérico, França
06 '06'H Dublin
07 '07'H Shannon
08 '08'H LATCC, Londres
09 '09'H ATCC de Oslo
10 '10'H ATCC de Karlsruhe
11 '11'H Langen (futuro sistema alemão)
12 '12'H Sistema FATMI, Tampere13 '13'H Sistema ROVA, Rovaniemi
14 '14'H VAS, Viena
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H Genebra ACC/FMP
18 '18'H Zurique ACC/FMP
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milão
23 '23'H Roma
24 '24'H Jersey
25 '25'H Shanwick
26 '26'H Athis-Mons
27 '27'H Reims
28 '28'H Brest
29 '29'H Bordéus
30 '30'H Aix-en-Provence
31 '31'H Bratislava
32 '32'H Estocolmo-Arlanda
33 '33'H Malmö-Sturup34 '34'H Sundsvall
35 '35'H Lisboa
36 '36'H Sevilha
37 '37'H Gran Canaria2000R2082 — PT — 15.06.2002 — 001.001 — 213
▼B
Código Identificador da
Unidade ATCCódigo Descrição
38 '38'H Praga
39 '39'H Amesterdão
40 '40'H LIZ Offenbach
41 '41'H Sistema Militar Alemão
42 '42'H Sistema Militar Alemão43 '43'H Sistema Militar Alemão
44 '44'H Sistema Militar Alemão
45 '45'H Sistema Militar Alemão
46 '46'H Sistema Militar Alemão
47 '47'H Sistema Militar Alemão
48 '48'H Sistema Militar Alemão
49 '49'H Sistema Militar Alemão
50 '50'H Munique (Futuro Sistema Alemão)
51 '51'H Zagreb
52 '52'H Aeroporto de Hahn, Alemanha
53 '53'H FIR de Santa Maria
54 '54'H Ljubljana
55 '55'H Sistema Militar Belga
56 '56'H Budapeste
57 '57'H Varsóvia2000R2082 — PT — 15.06.2002 — 001.001 — 214
▼B
ANEXO H (Informativo)
ORIENTAÇÕES SOBRE FIABILIDADE, DISPONIBILIDADE E SEGU-
RANÇ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, disponibi-
lidade 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 rela-
tivas à interligação das redes X.25.
H.2.3. Pressupõe-se que as implementações se encontram fisicamente prote-
gidas 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 Segu-
ranç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.2000R2082 — PT — 15.06.2002 — 001.001 — 215
▼B
H.4.4. Exemplo de Configuração
Figura H.1
Exemplo de Configuração de Linha Alugada
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 dife-
rentes 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 estabeleci-
mento 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 hospe-
deiro.
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.2000R2082 — PT — 15.06.2002 — 001.001 — 216
▼B
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 auto-
maticamente 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 Trans-
ferê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 Rede2000R2082 — PT — 15.06.2002 — 001.001 — 217