2000R2082 — ES — 15.06.2002 — 001.001 — 1
Estedocumentoesuninstrumentodedocumentaciónynocomprometelaresponsabilidaddelasinstituciones
►B REGLAMENTO(CE)No2082/2000DELACOMISIÓN
de6deseptiembrede2000
porelqueseadoptannormasdeEurocontrolysemodificalaDirectiva97/15/CEporlaquese
adoptanalgunasnormasdeEurocontrolysemodificalaDirectiva93/65/CEEdelConsejo
(DO L 254 de 9.10.2000, p. 1)
Modificado por:
Diario Oficial
nopágina fecha
►M1Reglamento (CE) no980/2002 de la Comisión de 4 de junio de 2002 L 150 38 8.6.2002
▼B
REGLAMENTO(CE)No2082/2000DELACOMISIÓN
de6deseptiembrede2000
por el que se adoptan normas de Eurocontrol y se modifica la
Directiva97/15/CEporlaqueseadoptanalgunasnormasdeEuro-
controlysemodificalaDirectiva93/65/CEEdelConsejo
LA COMISIÓN DE LAS COMUNIDADES EUROPEAS,
Visto el Tratado constitutivo de la Comunidad Europea,
Vista la Directiva 93/65/CEE del Consejo, de 19 de julio de 1993, rela-
tiva a la definición y a la utilización de especificaciones técnicas
compatibles para la adquisición de equipos y de sistemas para lagestión del tráfico aéreo (
1) y, en particular, su artículo 3,
Vista la Directiva 97/15/CE de la Comisión de 25 de marzo de 1997
por la que se adoptan algunas normas de Eurocontrol y se modifica laDirectiva 93/65/CEE del Consejo relativa a la definición, a la utiliza-ción de especificaciones técnicas compatibles para la adquisición de
equipos, de sistemas para la gestión del trafico aéro (
2),
Considerando lo siguiente:
(1) Mediante la Directiva 97/15/CE se adoptó la norma de Eurocon-
trol para el intercambio de datos en línea (OLDI), edición 1.0, yla norma de Eurocontrol para la presentación del intercambio de
datos de servicios de tráfico aéreo (ADEXP), edición 1.0.
(2) Eurocontrol ha adoptado versiones más recientes de ambas
normas (OLDI, edición 2.2 y ADEXP, edición 2.0), así como
una nueva norma de Eurocontrol relativa al documento de
control de interfaz para el intercambio de datos de vuelo (FDE-ICD).
(3) Dichas normas de Eurocontrol entran en el ámbito de aplicación
de la Directiva 93/65/CEE y contribuyen a la armonización de
los regímenes de los Estados miembros de gestión del tráficoaéreo, principalmente por lo que respecta a la transferencia devuelos entre centros de control del tráfico aéreo (OLDI), lagestión del flujo del tráfico aéreo (ADEXP) y las comunica-ciones entre regímenes nacionales (FDE-ICD).
(4) Las ediciones 2.2 de OLDI y 2.0 de ADEXP sustituyen a lasversiones anteriores, que estaban vigentes en virtud del artículo1 de la Directiva 97/15/CE, por lo que es preciso derogar dicho
artículo.
(5) Las disposiciones del presente Reglamento son conformes al
dictamen del Comité creado con arreglo a la Directiva 93/65/CEE.
HA ADOPTADO EL PRESENTE REGLAMENTO:
Artículo 1
Dado que son necesarios para la implantación de un sistema integrado
europeo de gestión del tráfico aéreo, se adoptan los elementos obliga-
torios de las especificaciones de Eurocontrol incluidos en los siguientes
documentos de normas de Eurocontrol, en el marco de la Directiva 93/65/CEE:
— norma de Eurocontrol para el intercambio de datos en línea (OLDI),
edición 2.2 (Documento de referencia de Eurocontrol
DPS.ET1.ST06-STD), cuyo texto figura en el anexo I del presenteReglamento,
— norma de Eurocontrol para la presentación del intercambio de datos
de servicios de tráfico aéreo (ADEXP), edición 2.0 (Documento de2000R2082 — ES — 15.06.2002 — 001.001 — 2
(1) DO L 187 de 29.7.1993, p. 52.
(2) DO L 95 de 10.4.1997, p. 16.
▼B
referencia de Eurocontrol DPS.ET1.ST09-STD), cuyo texto figura
en el anexo II del presente Reglamento,
— norma de Eurocontrol relativa al documento de control de interfaz
para el intercambio de datos de vuelo (FDE-ICD), edición 1.0(Documento de referencia de Eurocontrol COM.ET1.ST12-STD),
cuyo texto figura en el anexo III del presente Reglamento.
Artículo 2
Queda derogado el artículo 1 de la Directiva 97/15/CE.
Artículo 3
El presente Reglamento entrará en vigor el tercer día siguiente al de su
publicación en el Diario Oficial de las Comunidades Europeas .
El presente Reglamento será obligatorio en todos sus elementos y
directamente aplicable en cada Estado miembro.2000R2082 — ES — 15.06.2002 — 001.001 — 3
▼B
ANEXO I
INTERCAMBIODEDATOSENLÍNEA(OLDI),EDICIÓN2.2
(DocumentodereferenciadeEurocontrolDPS.ET1.ST06-STD)2000R2082 — ES — 15.06.2002 — 001.001 — 4
▼B
ÍNDICE
DERECHOS DE AUTOR
PRÓLOGO1. INTRODUCCIÓN
1.1. Objetivo1.2. Campo de aplicación
2. REFERENCIAS3. DEFINICIONES, SÍMBOLOS Y ABREVIATURAS
3.1. Definiciones3.2. Símbolos y Abreviaturas
4. REQUISITOS GENERALES
4.1. Introducción4.2. Requisitos de los sistemas de procesamiento de datos de vuelo4.2.1. Base de datos de vuelo4.2.2. Funcionamiento en Tiempo Real4.2.3. Capacidad de comunicación de datos4.2.4. Funciones de aplicación4.2.5. Interfaz hombre-máquina (HMI)4.2.6. Inicio de mensajes4.2.7. Recepción de mensajes4.3. Actualización a partir de datos de vigilancia4.4. Registro de datos OLDI4.4.1. Contenido4.4.2. Dispositivos4.5. Disponibilidad, fiabilidad, seguridad e integridad de datos4.5.1. Disponibilidad4.5.2. Fiabilidad4.5.3. Seguridad de los datos4.5.4. Integridad de los datos4.6. Evaluación operativa4.6.1. Período de evaluación4.6.2. Fecha de introducción operativa
5. CATEGORÍAS DE MENSAJE
5.1. General5.1.1. Objeto5.1.2. Categorías de mensaje5.2. Tiempos de transacción5.2.1. Condiciones del tiempo de transacción5.3. Clasificación y categorización de mensajes2000R2082 — ES — 15.06.2002 — 001.001 — 5
▼B
5.3.1. Clasificación de mensajes: obligatorio y complementario.
5.3.2. Categorización de mensajes
6. PROCEDIMIENTO BÁSICO — MENSAJES OBLIGATORIOS
6.1. General6.1.1. Descripción de requisitos6.1.2. Implantación6.2. Mensaje de información de paso de límite (ABI)
6.2.1. Objeto del mensaje ABI
6.2.2. Contenidos de mensaje6.2.3. Normas de aplicación6.2.4. Acuse de recibo de mensaje ABI6.2.5. Ejemplos6.3. Mensaje de activación (ACT)
6.3.1. Objeto del mensaje ACT
6.3.2. Contenidos de mensaje6.3.3. Normas de aplicación6.3.4. Acuse de recibo de mensaje ACT6.3.5. Ejemplos
6.4. Mensaje de acuse de recibo lógico (LAM)
6.4.1. Objeto del mensaje LAM6.4.2. Contenidos de mensaje6.4.3. Normas de aplicación6.4.4. Acuse de recibo de mensaje LAM6.4.5. Ejemplos
7. PROCEDIMIENTO BÁSICO — MENSAJES COMPLEMENTARIOS
7.1. General
7.1.1. Descripción de requisitos7.1.2. Implantación7.2. Mensaje de activación preliminar (PAC)7.2.1. Objeto del mensaje PAC7.2.2. Contenidos del mensaje
7.2.3. Normas de aplicación
7.2.4. Acuse de recibo de mensaje PAC7.2.5. Ejemplos7.3. Mensaje de revisión (REV)7.3.1. Objeto del mensaje REV
7.3.2. Contenidos del mensaje
7.3.3. Normas de aplicación7.3.4. Acuse de recibo de mensaje REV7.3.5. Ejemplos2000R2082 — ES — 15.06.2002 — 001.001 — 6
▼B
7.4. Mensaje para anulación de coordinación (MAC)
7.4.1. Objeto del mensaje MAC7.4.2. Contenidos del mensaje
7.4.3. Normas de aplicación
7.4.4. Acuse de recibo de un mensaje MAC7.4.5. Ejemplos7.5. Mensaje de asignación de código SSR (COD)
7.5.1. Objeto del mensaje COD
7.5.2. Contenidos de mensaje7.5.3. Normas de aplicación
7.5.4. Acuse de recibo de COD
7.5.5. Ejemplos7.6. Mensaje de información (INF)7.6.1. Objeto del mensaje INF
7.6.2. Contenidos de mensaje
7.6.3. Normas de aplicación7.6.4. Acuse de recibo de mensaje INF
7.6.5. Ejemplos
8. PROCEDIMIENTO DE DIÁLOGO — COORDINACIÓN
8.1. General8.1.1. Introducción
8.1.2. El filtro
8.1.3. Secuencia de mensajes8.1.4. Gestión simultánea de mensajes8.1.5. Tratamiento de los mensajes de rechazo
8.1.6. Tiempo de respuesta operativo
8.1.7. Implantación8.2. Mensaje de activación (ACT)
8.2.1. Objeto del mensaje ACT
8.2.2. Contenidos del mensaje8.2.3. Normas de aplicación
8.2.4. Acuse de recibo de mensaje ACT
8.3. Mensaje de referencia a propuesta de activación (RAP)8.3.1. Objeto del mensaje RAP8.3.2. Contenidos del mensaje
8.3.3. Normas de aplicación
8.3.4. Acuse de recibo de mensaje RAP8.3.5. Respuesta operativa al mensaje RAP
8.3.6. Ejemplos
8.4. Mensaje de revisión (REV)2000R2082 — ES — 15.06.2002 — 001.001 — 7
▼B
8.4.1. Objeto del mensaje REV
8.4.2. Contenidos del mensaje8.4.3. Normas de aplicación
8.4.4. Acuse de recibo de mensaje REV
8.4.5. Respuesta operativa a mensaje REV8.5. Mensaje de referencia a propuesta de revisión (RRV)8.5.1. Objeto del mensaje RRV
8.5.2. Contenidos del mensaje
8.5.3. Normas de aplicación8.5.4. Acuse de recibo de mensaje RRV
8.5.5. Respuesta operativa a mensaje RRV
8.5.6. Ejemplos8.6. Mensaje de puesta en espera (SBY)8.6.1. Objeto del mensaje SBY
8.6.2. Contenidos del mensaje
8.6.3. Normas de aplicación8.6.4. Acuse de recibo de mensaje SBY
8.6.5. Ejemplos
8.7. Mensaje de aceptación (ACP)8.7.1. Objeto del mensaje ACP
8.7.2. Contenidos de mensaje
8.7.3. Normas de aplicación8.7.4. Acuse de recibo de mensaje ACP8.7.5. Ejemplos
8.8. Mensaje de coordinación (CDN)
8.8.1. Objeto del mensaje CDN8.8.2. Contenidos del mensaje
8.8.3. Normas de aplicación
8.8.4. Acuse de recibo de mensaje CDN8.8.5. Respuesta operativa a mensaje CDN8.8.6. Ejemplos
8.9. Mensaje de rechazo de coordinación (RJC)
8.9.1. Objeto del mensaje RJC8.9.2. Contenidos del mensaje
8.9.3. Normas de aplicación
8.9.4. Acuse de recibo de mensaje RJC8.9.5. Ejemplos
9. PROCEDIMIENTO DE DIÁLOGO — TRANSFERENCIA DE COMUNICACIÓN
9.1. General
9.1.1. Introducción2000R2082 — ES — 15.06.2002 — 001.001 — 8
▼B
9.1.2. Secuencia de mensaje
9.1.3. Transferencia de comunicaciones9.2. Mensaje de inicio de transferencia (TIM)
9.2.1. Objeto del mensaje TIM
9.2.2. Contenidos del mensaje9.2.3. Normas de aplicación9.2.4. Acuse de recibo de mensaje TIM
9.2.5. Ejemplo
9.3. Mensaje de datos complementarios (SDM)9.3.1. Objeto del mensaje SDM
9.3.2. Contenidos del mensaje
9.3.3. Normas de aplicación9.3.4. Acuse de recibo de mensaje SDM9.3.5. Ejemplo
9.4. Propuesta de transferencia (HOP)
9.4.1. Objeto del mensaje HOP9.4.2. Contenidos del mensaje
9.4.3. Normas de aplicación
9.4.4. Acuse de recibo de mensaje HOP9.4.5. Ejemplo
9.5. Mensaje de solicitud de frecuencia (ROF)
9.5.1. Objeto del mensaje ROF9.5.2. Contenidos del mensaje9.5.3. Normas de aplicación
9.5.4. Acuse de recibo de mensaje ROF
9.5.5. Ejemplo9.6. Mensaje de cambio de frecuencia (COF)
9.6.1. Objeto del mensaje COF
9.6.2. Contenidos del mensaje9.6.3. Normas de aplicación9.6.4. Acuse de recibo de mensaje COF
9.6.5. Ejemplos
9.7. Mensaje de asunción manual de comunicaciones (MAS)9.7.1. Objeto del mensaje MAS
9.7.2. Contenidos del Mensaje
9.7.3. Normas de aplicación9.7.4. Acuse de recibo de mensaje MAS
9.7.5. Ejemplo
ANEXO A (NORMATIVO) NORMAS DE INTRODUCCIÓN DE DATOS
ANEXO B (NORMATIVO) REQUISITOS DE PROCESAMIENTO DE RUTAS ESPECIALES2000R2082 — ES — 15.06.2002 — 001.001 — 9
▼B
ANEXO C (INFORMATIVO) FASES DEL PROCEDIMIENTO DE DIÁLOGO (SYSCO NIVEL 1)
— SECUENCIA DE MENSAJE2000R2082 — ES — 15.06.2002 — 001.001 — 10
▼B
DERECHOSDEAUTOR
Este documento ha sido elaborado por Eurocontrol.
Los derechos de autor pertenecen a Eurocontrol.Si bien el contenido o cualquier parte del mismo está libremente a disposi-
ción de los representantes de los Estados miembros, su copia o divulgación
a un tercero estará sujeta a la autorización previa por escrito de Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 11
▼B
PRÓLOGO
1.Organismoresponsable
La presente Norma Eurocontrol para el Intercambio de datos en
Línea (OLDI), Edición 2.2, ha sido preparada por la Dirección
para el Desarrollo (DED) del Programa europeo para la integra-
ción y armonización del control de la circulación aérea
(EATCHIP), que también es responsable del mantenimiento de
este documento. Todos los comentarios o solicitudes deberán diri-
girse al Director General, Eurocontrol, Rue de la Fusée 96, B-
1130 Bruselas, a la atención de la División DED-2.
2.RelaciónconelProgramadeTrabajoEATCHIP
La presente Norma es el resultado de la Tarea especializada
DPS.ET1.ST06 del dominio de Sistemas de procesamiento de
Datos ATM (DPS) de EATCHIP según se especifica en el Docu-
mento Programa de Trabajo (EWPD) Edición 2.0, de fecha 30/09/
94.
3.Aprobaciónycorrecciones
La presente Norma ha sido sometida al siguiente procedimiento
de aprobación según se detalla en las Directivas para la Normali-
zación de Eurocontrol:
— Aprobado, por correspondencia, por el equipo «Requisitos
Operativos y equipo de procesamiento de datos ATM
(ODT)»;
— Consulta de todos los Estados ECAC a través de sus represen-
tantes en el Comité de gestión o en el Consejo del proyecto
EATCHIP;
— Aprobación por el Consejo del proyecto EATCHIP y por el
Comité de gestión;
— Adopción porla Comisión per manente.
Las disposiciones de la presente Norma son efectivas a partir del
momento de su adopción porla Comisión per manente.
Con el fin de seguirla evolución de los pr ocedimientos de
Control de tráfico Aéreo (ATC), se pueden proponer correcciones
y adiciones a través del ODT para su debate y posible aproba-
ción. Los requisitos serán incorporados como corrección o como
edición posterior del documento para su aprobación y endoso
según los procedimientos especificados.
4.Prácticaseditoriales
Se han seguido los siguientes procedimientos para indicar el
estado de cada declaración: Los Elementos normativos están
impresos en texto normal; los Elementos recomendados están
impresos en cursiva, y van precedidos de la palabra Recomenda-
ción.
Al escribir las especificaciones se han seguido las siguientes
prácticas editoriales: para los Elementos normativos se utiliza el
verbo en tiempo futuro ( deberá ) y para los Elementos recomen-
dados se utiliza el verbo en tiempo condicional ( debería ).
Las Notas están escritas en cursiva normal precedida por la
palabra «NOTA».
5.RelaciónconlaEdición1delaNormaEurocontrolparael
Intercambiodedatosenlínea
El presente documento sustituye a las Partes 1 y 2 de la Edición 1
de la Norma Eurocontrol para el Intercambio de datos en línea.
La parte 3, que describe los protocolos técnicos utilizados, se
sustituye por la Norma Eurocontrol para Intercambio de datos de
vuelo — Documento de control de interfaz Parte 1.2000R2082 — ES — 15.06.2002 — 001.001 — 12
▼B
6.CambiossignificativosrespectoalaEdición1
A continuación se indican los cambios y las adiciones más signi-
ficativas respecto a la Edición 1:
1. Incorporación de los siguientes mensajes complementarios (no
obligatorios) respecto del procedimiento básico:
— Mensaje de anulación de coordinación (MAC);
— Mensaje de asignación de código (COD) para el Radar
secundario de vigilancia (SSR);
— Mensaje de información (INF).
2. Definición del formato y contenido del mensaje que apoya el
cruce de un límite en una ruta que no ha sido definida por los
Servicios de Tráfico Aéreo (ATS), pero que está definida por
los puntos inicial y final del segmento de ruta.
3. Incorporación de un procedimiento de diálogo que permite:
— La identificación y negociación de condiciones de transfe-
rencia no normalizadas por controladores que realizan la
función de planificación;
— La provisión, para los puestos receptores, de la capacidad
de proponer nuevamente condiciones de transferencia;
— La provisión de medios de transferencia de comunicación
como parte del procedimiento de control de transferencia.
4. Se introduce la utilización del formato descrito en la Edición 2
de la Norma Eurocontrol para la Presentación del Intercambio
de Datos ATS (ADEXP). Todos los mensajes especificados de
conformidad con el procedimiento básico y los utilizados
durante la fase de coordinación del procedimiento de diálogo
se describen utilizando los formatos de la Organización de
Aviación Civil Internacional (ICAO) y ADEXP. Los mensajes
de transferencia de comunicación descritos de conformidad
con el procedimiento de diálogo se describen utilizando única-
mente el formato ADEXP.
5. Eliminación de los siguientes Anexos a la Edición 1:
A Identificación de Unidad ATC
B Estructura de Mensaje OLDI
(todos los mensajes de la Edición 3 incluyen ejemplos).
D Visión General Histórica
E Plan de Implantación
F Cumplimiento porpar te de los EstadosG Directrices para la ImplantaciónH Directrices para la Evaluación de OLDI
6. Separación en la Parte 3 (Requisitos Técnicos) de las aplica-
ciones de la Norma.
7.Relaciónconotrosdocumentos
El presente documento hace referencia a la utilización de dos
tipos de formato de campo en la compilación de mensajes, que
son ICAO y ADEXP.
Los formatos de campo ICAO se describen en la Referencia 1. En
el caso de que la Referencia 1 fuera sustituida por otro docu-
mento, la definición de los tipos de campo ICAO deberá hacerse
tal y como se describe en ese documento.
Los formatos para los campos ADEXP se describen en la Refe-
rencia 2.
NOTA Los documentos de referencia se enumeran en la Sección
2.
8.Lenguaje
Se ha utilizado el idioma inglés en la preparación del original del
presente documento.2000R2082 — ES — 15.06.2002 — 001.001 — 13
▼B
1.INTRODUCCIÓN
1.1.Objetivo
1.1.1. Los vuelos que disponen de un servicio ATC se transfieren de un
puesto ATC al siguiente de tal forma que se garantiza una segu-
ridad completa. Para conseguir este objetivo, un procedimiento
normal es que el paso de cada vuelo por el límite de las áreas
de responsabilidad de las dos unidades esté coordinado por ellas
con antelación y que el control del vuelo se transfiera cuando éste
se encuentre en dicho límite o cerca de él.
1.1.2. Cuando se realiza por teléfono, el envío de datos de cada vuelo
como parte de un proceso de coordinación es una tarea de apoyo
importante en los puestos ATC, particularmente en los Centros de
control de área (ACC). La utilización operativa de conexiones
entre Sistemas de procesamiento de datos de vuelo (FDPS) en
ACC a efectos de reemplazar dichas «estimaciones» verbales, a
las que nos referimos como Intercambios de datos en línea
(OLDI), comenzó en Europa a principios de los años ochenta.
1.1.3. Para facilitar la implantación, se elaboraron formatos de mensaje
y normas sencillas que fueron aceptados por los organismos inte-
resados e incorporados en la Edición 1 de la Norma Eurocontrol
para el Intercambio de datos en línea. La presente Edición 2.2, ha
sido preparada como apoyo al continuo desarrollo de dichos
dispositivos en cumplimiento con los requisitos de EATCHIP.
1.2.Campodeaplicación
1.2.1. El presente documento especifica los dispositivos y mensajes
proporcionados entre los FDPS que atienden a puestos ATC con
el propósito de conseguir:
— La coordinación necesaria antes de la transferencia de vuelos
de un puesto al siguiente;
— La transferencia de comunicación de dichos vuelos.
1.2.2. El presente documento:
— define los formatos de mensaje y las normas para el conte-
nido;
— describe los dispositivos necesarios en dichos puestos, que
son un requisito previo para la utilización del intercambio de
datos para este propósito.
1.2.3. La presente Norma es aplicable entre los Estados Miembros de
Eurocontrol para los dispositivos OLDI internacionales entre
puestos que dan servicio a un área ATC.
1.2.4.Recomendación Se recomienda que los Estados de la Confe-
rencia de la Aviación Civil Europea (ECAC) apliquen estaNorma a:
—los dispositivos OLDIinternacionales entre puestos que dan
servicio a un área ATC dentro de un área ECAC;
—los dispositivos OLDIentre puestos que dan servicio a un
área ATC que pertenece al Estado interesado .
2.REFERENCIAS
2.1. Los siguientes Documentos contienen disposiciones que, a través
de referencias en este texto, constituyen disposiciones de la
presente Norma Eurocontrol.
En el momento de la publicación de esta Norma Eurocontrol,
tenían vigorlas ediciones indicadas de los documentos de r efe-
rencia.
Cualquier revisión de los Documentos ICAO mencionados deberá
tenerse en cuenta de forma inmediata para revisar la presente
Norma de Eurocontrol.
Las revisiones de los demás documentos de referencia no
formarán parte de las disposiciones de la presente Norma Euro-
control hasta que no sean revisados e incorporados formalmente
a la presente Norma Eurocontrol.
En caso de conflicto entre los requisitos de la presente Norma
Eurocontrol y los contenidos de los demás documentos mencio-
nados, prevalecerá la presente Norma Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 14
▼B
2.2. En la presente Norma se mencionan los siguientes documentos:
1. Procedimientos para los Servicios de navegación aérea —
Normas del Aire y Servicios de Tráfico Aéreo, Documento
ICAO 4444, 13aEdición, de fecha 7 de noviembre de 1996,
corregida.
2. Edición 2.0 de la Norma Eurocontrol para la Presentación del
intercambio de datos ATS (ADEXP), referencia DPS-ET1-
ST09-STD-01-00, de junio de 1998.
3.DEFINICIONES,SÍMBOLOSYABREVIATURAS
3.1.Definiciones
A los efectos de la presente Norma Eurocontrol deberán aplicarse
las definiciones siguientes:
3.1.1. Puesto Receptor : El puesto que presta un servicio ATC y que va
a tomar o ha tomado el control de un vuelo cuando va a reali-
zarse o se ha realizado la transferencia de un puesto al siguiente.
3.1.2. Acuse de Recibo : Notificación de que se ha recibido un mensaje
que puede procesarse correctamente.
3.1.3. Activación : El proceso, en un puesto receptor ATC, por el cual se
actualiza el plan de vuelo de la aeronave de referencia para
incluir los datos enviados por el puesto de transferencia como
parte de un proceso de coordinación entre los dos puestos, por el
cual se transmiten los datos a los controladores.
3.1.4. Altitud : La distancia vertical de un nivel, un punto o un objeto
considerado como un punto, medida sobre el nivel del mar.
3.1.5. Aplicación : Parte de un subsistema ATS que se ajusta a la
presente norma y establece una interfaz con entidades semejantes
en otros sistemas ATS.
3.1.6. Área de Responsabilidad : Espacio aéreo de dimensiones definidas
dentro del cual un puesto ATC presta servicios de tráfico aéreo.
3.1.7. Asociación : Procedimiento por el cual un sistema relaciona un
mensaje OLDI recibido con una entrada de plan de vuelo en la
base de datos.
3.1.8. Puesto ATC : Puesto que presta un servicio de control de tráfico
aéreo.
3.1.9. Disponibilidad : La probabilidad de que una instalación esté
disponible para un usuario en un determinado momento.
3.1.10. Límite : Los planos (lateral y vertical) que delimitan el área de
responsabilidad de un puesto ATC.
3.1.11. Nivel de Vuelo Autorizado : El nivel de vuelo al que o en el que
un vuelo ha sido autorizado por el ATC.
3.1.12. Coordinación, ATC : El proceso, realizado entre puestos ATC con
áreas de responsabilidad adyacentes, de comunicarse formalmente
del paso previsto de los vuelos por los límites de sus áreas de
responsabilidad, con el fin de garantizar la seguridad de vuelo
mediante la coherencia de las acciones previstas.
3.1.13. Mensaje de coordinación : Término genérico que hace referencia
a un mensaje utilizado para conseguir la coordinación ATC. Estos
mensajes incluyen un CDN que es un mensaje específico que se
describe en el párrafo 8.8.
3.1.14. Fase de coordinación : Para un vuelo dado, es la fase durante la
cual los puestos de transferencia y recepción ATC acuerdan las
condiciones (p. ej., nivel de vuelo, punto de paso porel límite)
según las cuales el vuelo va a pasardel contr ol del uno al del
otro.
3.1.15. Punto de Coordinación : Punto situado en el límite o adyacente al
límite y conocido porlos puestos ATC en una secuencia de coor -
dinación y mencionado en los mensajes de coordinación.
3.1.16. Correlación : Proceso, basado en criterios definidos, que consiste
en enlazardatos del plan de vuelo con los datos del seguimiento
por el radar del mismo vuelo, normalmente para la visualización
en la pantalla de un controlador.2000R2082 — ES — 15.06.2002 — 001.001 — 15
▼B
3.1.17. Norma Eurocontrol : Cualquier norma aplicable a las caracterís-
ticas físicas, a la configuración, al material, al funcionamiento,
al personal o al procedimiento, cuya aplicación uniforme haya
sido aprobada como esencial para la implantación de sistemas
ATS dentro de los Estados Miembros de Eurocontrol. Toda
Norma Eurocontrol debe estar en consonancia con las Normas
ICAO, es más, cuando sea apropiado, las complementará.
3.1.18. Controlador Ejecutivo : Controlador que proporciona instrucciones
directamente a los vuelos que están bajo su control. Dichos
controladores incluyen aquellos que prestan servicios de control
de área por radar.
3.1.19. Nivel de Salida : El nivel al que ha sido coordinado un vuelo para
pasar por un punto de transferencia de control. Un nivel de salida
puede incluircondiciones complementar ias de paso, las cuales
definen la banda de niveles dentro de la que se realizará un vuelo
de ascenso o descenso.
3.1.20. Plan de Vuelo : Información específica proporcionada a los
puestos de servicio de tráfico aéreo, relativa a un determinado
vuelo o porción de vuelo de una aeronave. También, información
obtenida del plan de vuelo de una determinada aeronave y conte-
nida en un FDPS.
3.1.21. Generación : Proceso, en un sistema ATC, en el cual se extraen
datos importantes de la base o bases de datos y se crea un
mensaje de transmisión a un puesto receptor ATC.
3.1.22. Formato ICAO : Formato utilizado para transmisiones tierra–tierra
de mensajes ATS y que utiliza los tipos de campo y separadores
descritos en la Referencia 1.
3.1.23. Nivel: Término genérico que hace referencia a la posición vertical
de una aeronave en vuelo; dentro de esta Norma el término nivel
o nivel de vuelo designa altitud en los casos en los que se utilice.
3.1.24. Notificación : El proceso por el cual el puesto de transferencia
transmite datos para actualizar el sistema del puesto receptor
como preparación para la fase de coordinación.
3.1.25. Puesto Receptor : El puesto ATC al que se envía un mensaje.
3.1.26. Fiabilidad : El porcentaje de la disponibilidad programada durante
la cual el servicio puede estar operativo.
3.1.27. Nivel de Vuelo Solicitado : Nivel de vuelo solicitado porla aer o-
nave en el plan de vuelo.
3.1.28. Revisión : Corrección de los datos enviados anteriormente por el
puesto de transferencia ATC al puesto receptor ATC.
3.1.29. Nivel de Cruce Complementario : Nivel, al cual, o porencima del
cual, o por debajo del cual ha sido coordinado un vuelo para
pasar por el punto de transferencia de control. El nivel comple-
mentario, si existe, es un elemento del nivel de salida.
3.1.30. Plan de Vuelo Sistema : Información obtenida del plan de vuelo
de una aeronave determinada contenida dentro de un FDPS.
3.1.31. Tiempo de Transacción : Intervalo de tiempo que sigue al inicio
de un mensaje y durante el cual se realiza la transmisión, proce-
samiento inicial en el sistema receptor, generación y transmisión
del mensaje de acuse de recibo y su identificación por el sistema
de transferencia.
3.1.32. Punto de Transferencia de Control : Punto definido, situado en un
itinerario de vuelo de una aeronave, en el que la responsabilidad
de proporcionar servicios ATS a la aeronave se transfiere de un
puesto ATC o puesto de control al puesto de control siguiente.
No coincide necesariamente con el punto de coordinación.
3.1.33. Fase de transferencia : Fase del vuelo que sigue a la fase de coor-
dinación, durante la cual se realiza la transferencia de
comunicación.
3.1.34. Puesto de Transferencia : En una secuencia de coordinación, el
puesto ATC responsable de prestar un servicio a una aeronave
antes de que cruce el límite y que inicie la fase de coordinación
con el puesto siguiente.
3.1.35. Transmitir : Comunicarun mensaje de un sistema a otr o.
3.1.36. Puesto : Puesto de servicio de tráfico aéreo.2000R2082 — ES — 15.06.2002 — 001.001 — 16
▼B
3.1.37. Aviso: Un mensaje visualizado en un puesto de trabajo cuando ha
fallado el proceso de coordinación automático.
3.2.SímbolosyAbreviaturas
A los efectos de la presente Norma Eurocontrol, se aplicarán los
símbolos y abreviaturas siguientes:
ABI Mensaje de información de paso de límite
ACC Centro de control de área
ACP Mensaje de aceptación
ACT Mensaje de activación
ADEXP Presentación de intercambio de datos ATS
ATC Control del tráfico aéreoATM Gestión del tráfico aéreo
ATS Servicios de tráfico aéreo
CDN Mensaje de coordinaciónCNL Cancelación del plan de vuelo
COD Mensaje de asignación de código SSR
COF Mensaje de cambio de frecuencia
COP Punto de coordinación
DED Dirección de desarrollo de EATCHIP, EurocontrolEATCHIP Programa europeo de integración y armonización del
control de tráfico aéreo
ECAC Conferencia europea de aviación civil
ETO Hora estimada de sobrevuelo
ETOT Hora estimada de despegueEWPD Documento programa de trabajo EATCHIP
FDPS Sistema de procesamiento de datos de vuelo
FRF Ruta de vuelo complementariaHMI Interfaz hombre máquina
HOP Mensaje de propuesta de transferencia
ICAO Organización de aviación civil internacional
INF Mensaje de información
LAM Mensaje de acuse de recibo lógicoLoA Carta de acuerdo
MAC Mensaje para anulación de coordinación
MAS Aceptación manual de comunicacionesNM Milla náutica
OLDI Intercambio de datos en línea
ORCAM Método de asignación código según región origen
PAC Mensaje de activación preliminar
RAP Mensaje de referencia a propuesta de activaciónREV Mensaje de revisión
RJC Mensaje de rechazo de coordinación
ROF Mensaje de solicitud de frecuenciaRRV Mensaje de referencia a propuesta de revisión
SBY Mensaje de puesta en espera
SDM Mensaje de datos complementarios
SSR Radarsecundar io de vigilancia
SYSCO Coordinación apoyada en sistemasTI Inicio de transferencia
TIM Mensaje de iniciación de transferencia
TWR/APP Control de torre (control de aeródromo) y aproxima-
ción2000R2082 — ES — 15.06.2002 — 001.001 — 17
▼B
4.REQUISITOSGENERALES
4.1.Introducción
Esta sección describe los requisitos operativos generales necesa-
rios para la implantación de un dispositivo OLDI entre puestos
ATC, así como su clasificación y los requisitos de funciona-
miento de los diferentes tipos de mensajes utilizados.
4.2.Requisitosdelossistemasdeprocesamientodedatosdevuelo
4.2.1. Base de datos de vuelo
Los puestos que utilizan un dispositivo como el descrito en el
presente documento deberán recibir los datos de un FDPS que
contenga toda la información necesaria para la visualización,
procesamiento y compilación de los mensajes como se especifica.
La principal fuente de datos para cada vuelo es el plan de vuelo
o, en su lugar, el piloto al mando de la aeronave. Otros datos
complementarios se obtienen mediante el procesamiento de los
planes de vuelo en función de las condiciones del puesto referido.
4.2.2. Funcionamiento en Tiempo Real
El procedimiento OLDI incluye hechos en el puesto ATC de
transferencia que provocan el inicio de las funciones necesarias
para la oportuna presentación de datos al controlador de transfe-
rencia y la transmisión de datos de coordinación al puesto
receptor. Para ello, el FDPS deberá estar en condiciones de
iniciar funciones mediante la comparación de parámetros de
Tiempo Universal Coordinado y parámetros de tiempo aplicable
con los tiempos en posiciones específicas de la ruta de vuelo
determinadas en la base de datos del vuelo.
4.2.3. Capacidad de comunicación de datos
4.2.3.1. El FDPS tendrá que poder recibir y transmitir datos de vuelo en
el formato aplicable al mensaje, según queda especificado en el
presente documento, utilizando un medio de comunicaciones de
datos que admita la función OLDI.
4.2.3.2.Recomendación El FDPS debería tener la suficiente capacidad
de desarrollo para permitir la adición de nuevos mensajes que
puedan incluirse en futuras ediciones de la presente Norma.
4.2.3.3. Dentro de los requisitos de funcionamiento especificados en el
presente documento, el sistema de comunicación de datos deberá
proporcionar un intercambio de datos rápido y fiable entre aplica-
ciones:
— asegurando la integridad de la transmisión de mensajes OLDI;
y
— comprobando las conexiones punto a punto o el estado de la
red de comunicaciones, según corresponda.
4.2.3.4. El FDPS deberá avisar a los puestos de trabajo cuando el sistema
de comunicación de datos detecte anomalías.
4.2.4. Funciones de aplicación
4.2.4.1. Los sistemas utilizados para atender a las necesidades de los
dispositivos OLDI deberán ser capaces de recibir, almacenar,
procesar, extraer y entregar para visualizar, y transmitir datos
OLDI en tiempo real y automáticamente.
4.2.4.2. El FDPS deberá:
— reflejar los datos operativos actuales correspondientes a la
función OLDI según se exige en la presente Norma, actuali-
zados automáticamente, manualmente o combinando ambos
métodos;
— sercapaz de extr aerdichos elementos de la base de datos del
plan de vuelo;
— identificarel siguiente puesto ATC en la r uta de vuelo.
4.2.4.3. Los siguientes puntos deberán ser aceptados bilateralmente:
— Puntos de Coordinación (CPO);
— Puntos de referencia utilizados para notaciones de rumbos y
distancias, identificando el COP sobre los segmentos de ruta
directos fuera del ATS, cuando se utilicen.2000R2082 — ES — 15.06.2002 — 001.001 — 18
▼B
NOTA Los COP no tiene que ser siempre idénticos a los puntos
de transferencia de control.
4.2.5. Interfaz hombre-máquina (HMI)
4.2.5.1. La HMI deberá ser capaz de:
— visualizarlos contenidos oper ativos de los mensajes OLDI y
los avisos importantes relacionados con los mensajes reci-
bidos, para que sean atendidos de forma inmediata;
— enviar avisos de mensaje de coordinación y de transferencia a
los puestos operativos responsables de la coordinación de los
vuelos en cuestión.
4.2.5.2. El personal ATC deberá disponer de un medio para modificar los
datos de los que se derivan los contenidos operativos de los
mensajes, según se exige en el presente documento.
4.2.5.3. La HMI deberá indicar que la transmisión del mensaje se está
realizando o que ha sido realizada con éxito, según el caso.
4.2.5.4. Se generará automáticamente un aviso o notificación al corres-
pondiente ATC o puesto técnico, si no se ha recibido un acuse
de recibo dentro del parámetro de tiempo que sigue a una trans-
misión de un mensaje de coordinación o de transferencia.
4.2.5.5. Dicho aviso o notificación deberá tener una forma que atraiga
inmediatamente la atención del puesto de trabajo correspondiente.
4.2.5.6.Recomendación La HMIen puestos ATC que utilizan OLDI
debería generar un aviso si no está disponible la instalación
OLDI.
4.2.6. Inicio de mensajes
4.2.6.1. Cada sistema deberá contener un conjunto de parámetros que
aseguren el inicio automático y en el momento adecuado de
mensajes OLDI.
4.2.6.2.Recomendación Debería disponerse de la capacidad de iniciar
manualmente la transmisión de un mensaje de coordinación antes
de la hora calculada para su transmisión.
4.2.6.3. Deberá garantizarse siempre el inicio automático, si no se ejecuta
el inicio manual.
4.2.6.4. El sistema deberá utilizar parámetros de tiempo para definir lo
siguiente:
— tiempo anterior a la transmisión, cuando se visualizan los
contenidos operativos de los mensajes en el puesto de transfe-
rencia.
— tiempo de adelanto, global o por COP, para trasmitir el
mensaje, cuando sea aplicable.
— tiempo posterior a la transmisión de un mensaje dentro del
cual debe recibirse un acuse de recibo de nivel de aplicación
(time-out ).
4.2.6.5. Un mensaje deberá ser transmitido sin demora cuando la informa-
ción requerida no se encuentre disponible hasta después del
momento en el que de otro modo debería haberse transmitido.
Ejemplo: Un vuelo comienza un segmento GAT IFR en un punto
cercano al límite que luego tiene que cruzar; el ETO en ese punto
se comunica ocho minutos antes del COP; produciéndose la trans-
misión del mensaje ACT ya con retraso según el parámetro o
parámetros de tiempo aplicables; el mensaje debe enviarse sin
demora.
4.2.7. Recepción de mensajes
4.2.7.1. El sistema ATC deberá estar en condiciones de:
— recibir mensajes OLDI;
— procesarlos automáticamente, de conformidad con la presente
Norma;
— extraer datos de vuelo de acuerdo con el mensaje recibido y
visualizar los avisos necesarios en caso de incoherencia en
los datos recibidos;
— generar y transmitir automáticamente mensajes de acuse de
recibo en el nivel de aplicación.2000R2082 — ES — 15.06.2002 — 001.001 — 19
▼B
4.2.7.2. Un mensaje de acuse de recibo (mensaje de acuse de recibo
lógico (LAM), de aceptación (ACP) o de puesta en espera
(SBY)) deberá ser generado y transmitido cuando el mensaje
correspondiente haya sido procesado y esté asegurada la presenta-
ción de los resultados de este proceso en el puesto o los puestos
adecuados, según sea necesario.
NOTA Las condiciones detalladas para la generación de un
acuse de recibo se especifican individualmente para
cada mensaje.
4.3.Actualizaciónapartirdedatosdevigilancia
Recomendación Para asegurar la exactitud de los datos de
tiempo estimado, debería utilizarse información procedente del
seguimiento de vuelos mediante radar u otros medios de vigi-
lancia para la actualización de la base de datos del plan de
vuelo.
4.4.RegistrodedatosOLDI
4.4.1. Contenido
Deberán registrarse tanto el contenido de todos los mensajes
OLDI como su hora de recepción.
4.4.2. Dispositivos
Los dispositivos estarán disponibles para la recuperación y visua-
lización de los datos registrados.
4.5.Disponibilidad,fiabilidad,seguridadeintegridaddedatos
4.5.1. Disponibilidad
4.5.1.1. El dispositivo OLDI estará disponible durante las horas de flujo
de tráfico normal o intenso entre los dos puestos interesados.
4.5.1.2.Recomendación La instalación OLDIdebería estar disponible
durante las 24 horas del día.
4.5.1.3. Cualquier período de desconexión programado (así como el
tiempo acordado de disponibilidad) deberá ser acordado bilateral-
mente entre los dos puestos interesados.
4.5.2. Fiabilidad
4.5.2.1. La fiabilidad de cada enlace OLDI deberá ser al menos del
99,86% (equivalente a un tiempo de desconexión de no más de
12 hora al año sobre una disponibilidad de 24 horas al día).
4.5.2.2.Recomendación Cuando esté justificado operativamente, debería
proporcionarse una fiabilidad de al menos un 99,99 % (equiva-
lente a un tiempo de desconexión de no más de 52 minutos al
año sobre una disponibilidad de 24 horas al día).
4.5.3. Seguridad de los datos
RecomendaciónDeberían aplicarse métodos para la seguridad
datos (p. ej., derechos de acceso, verificación de emisor) a los
dispositivos OLDIy, cuando sea aplicable, asegurar la gestión
de la red .
4.5.4. Integridad de los datos
La tasa de fallos a nivel de aplicación no deberá exceder de un
error de transmisión por cada 2 000 mensajes.
4.6.Evaluaciónoperativa
4.6.1. Período de evaluación
Cada nuevo dispositivo OLDI, incluyendo cualquiernuevo dispo-
sitivo en un enlace existente, deberá someterse a un período de
evaluación para verificar la integridad de los datos, la precisión,
el funcionamiento, la compatibilidad con los procedimientos ATC
y la seguridad general antes de su implantación operativa.
NOTA Un procedimiento para ayudar a la evaluación de una
nueva instalación OLDIse encuentra disponible en la
Secretaría OLDI, Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 20
▼B
4.6.2. Fecha de introducción operativa
La fecha de introducción operativa, que supone el final del
período de evaluación, deberá ser acordada formalmente entre
los dos puestos.
5.CATEGORÍASDEMENSAJE
5.1.General
5.1.1. Objeto
La presente Sección del documento:
— define las categorías de los mensajes;
— establece los requisitos de tiempo de transacción para las
categorías;
— establece qué mensajes son obligatorios y cuáles son comple-
mentarios;
— asigna los tipos de mensaje a categorías.
5.1.2. Categorías de mensaje
Se han asignado las siguientes categorías a los mensajes OLDI:
— Categoría 1: Transferencia de comunicación;
— Categoría 2: Coordinación;
— Categoría 3: Notificación.
5.2.Tiemposdetransacción
5.2.1. Condiciones del tiempo de transacción
5.2.1.1. Los tiempos de transacción especificados incluyen la transmisión,
el procesamiento inicial en el puesto de recepción, la creación del
mensaje de acuse de recibo, su transmisión y recepción al puesto
de transferencia, por lo que los mensajes de acuse de recibo LAM
y SBY no han sido asignados a ninguna categoría.
5.2.1.2. Los tiempos máximos de transacción para las distintas categorías
de mensajes serán los especificados en la Tabla 5-1.
Tabla 5-1
Tiempos máximos de transacción
Categoría del Mensaje 90 % 99,8 %
1 4 seg. 10 seg.
2 10 seg. 25 seg.
3 15 seg. 45 seg.
5.2.1.3. Se definirá un valor de tiempo para cada categoría o tipo de
mensaje.
5.2.1.4. Si no se ha recibido un acuse de recibo dentro del tiempo especi-
ficado a partir de la transmisión, se considerará que el mensaje no
ha sido transmitido o procesado satisfactoriamente y se enviaráun aviso según se especifica en la sección pertinente del presente
documento.
5.2.1.5.Recomendación Los valores de tiempo para las tres categorías
no deberían exceder de 12 segundos, 30 segundos y 60 segundos,
respectivamente.
5.3.Clasificaciónycategorizacióndemensajes
5.3.1. Clasificación de mensajes: obligatorio y complementario.
5.3.1.1. Los mensajes descritos en el presente documento se clasifican en
obligatorios y complementarios.2000R2082 — ES — 15.06.2002 — 001.001 — 21
▼B
5.3.1.2. Cuando un mensaje esté descrito como de transmisión (TX) obli-
gatoria (M), deberá incluirse el procesamiento para poder enviar
dichos mensajes.
5.3.1.3. Cuando un mensaje esté descrito como de recepción (REC) obli-
gatoria, deberá incluirse el procesamiento para poder procesar
dichos mensajes.
NOTA En casos excepcionales, cuando el flujo del tráfico entre
dos puestos sea unidireccional, los mensajes obligatorios
pueden ser aplicables solamente en una dirección.
5.3.1.4. Cuando un mensaje esté descrito como complementario (C) para
transmisión, deberá incluirse el procesamiento para poder enviar
dichos mensajes, si así lo requiere el puesto emisor y si así ha
sido acordado bilateralmente con el puesto receptor.
NOTA Los mensajes complementarios pueden ser utilizados
solamente en una dirección en función de los requisitos
operativos.
5.3.1.5. Cuando un mensaje esté descrito como de recepción complemen-
taria (C), deberá incluirse el procesamiento para poder enviar
dichos mensajes, siempre que haya sido acordado bilateralmente.
5.3.1.6. Los requisitos descritos en las Tablas 5-3 y 5-4 son aplicables
sólo cuando la utilización de los respectivos procedimientos de
Diálogo para coordinación y/o transferencia de comunicación
hayan sido acordados bilateralmente entre puestos ATC.
5.3.2. Categorización de mensajes
5.3.2.1. La categorización de mensajes para el procedimiento básico se
especifica en la Tabla 5-2.
5.3.2.2. La categorización de los mensajes complementarios de coordina-
ción para el procedimiento de diálogo se especifica en la Tabla 5-
3.
5.3.2.3. La categorización de los mensajes de transferencia de comunica-
ciones para el procedimiento de diálogo se especifica en la
Tabla 5-4.
Tabla 5-2
Mensajes del procedimiento básico
Tipo de mensaje Abreviatura Categoría Transmisión Recepción
Avance de Información de
LímiteABI 3 M M
Activación ACT 2 M M
Revisión REV 2 C (1)C (1)
Activación preliminar PAC 2 C C
Anulación de coordinación MAC 2 C C
Asignación de código SSR COD 2 C C
Información INF 3 C C
Mensaje de acuse de
recibo lógicoLAM M M
NOTA
(1) Obligatorio para TX y REC cuando se utilice en un procedimiento de diálogo.
Tabla 5-3
Procedimiento de Diálogo — Mensajes de fase de coordinación
(Complementaria a la Tabla 5-2)
Tipo de mensaje Abreviatura Categoría Transmisión Recepción
Propuesta de activación
acordadaRAP 2 C M
Revisión acordada RRV 2 C M
Coordinación CDN 2 M M2000R2082 — ES — 15.06.2002 — 001.001 — 22
▼B
Tipo de mensaje Abreviatura Categoría Transmisión Recepción
Puesta en espera (1) SBY M M
Aceptación ACP 2 M M
Rechazo de coordina-
ción (2)RJC 2 C C
NOTAS
(1) Véase párrafo 5.2.1.1 Condiciones de tiempo de transacción.
(2) No se utiliza en todas las configuraciones del espacio aéreo.
Tabla 5-4
Procedimiento de diálogo — Mensajes de fase de transferencia
Tipo de mensaje Abreviatura Categoría Transmisión Recepción
Inicio de transferencia TIM 1 M M
Datos complementarios SDM 1 (1)(1)
Propuesta de transferencia HOP 1 M M
Cambio de frecuencia (2) COF 1 C M
Solicitud de frecuencia ROF 1 C M
Aceptación manual (2) MAS 1 C M
NOTAS
(1) M cuando se envía desde el puesto emisor; C cuando se envía desde el puesto receptor.
(2) Los procedimientos acordados bilateralmente deberán especificar que, cuando se realiza la
transferencia respecto a una dirección de flujo de tráfico, como mínimo, el puesto emisordeberá enviar un mensaje COF o el puesto receptor deberá enviar un mensaje MAS.
6.PROCEDIMIENTO BÁSICO — MENSAJES OBLIGATO-
RIOS
6.1.General
6.1.1. Descripción de requisitos
Esta sección describe los requisitos mínimos a nivel de aplicación
para la implantación de dispositivos OLDI.
6.1.2. Implantación
Los puestos que utilizan OLDI para la coordinación de los vuelos
deberán implantar los mensajes ABI, ACT y LAM según se
describe en esta sección, excepto cuando se haya acordado bilate-
ralmente utilizar el procedimiento de diálogo de coordinación que
se describe en la Sección 8 del presente documento, en cuyo caso
las condiciones de utilización de los mensajes ACT y LAM será
como se define en dicha sección.
6.2.Mensajedeinformacióndepasodelímite(ABI)
6.2.1. Objeto del mensaje ABI
El ABI satisface los siguientes requisitos operativos:
— facilita la adquisición de datos del plan de vuelo perdidos;
— proporciona suministra avance de información de límite y
revisiones para el siguiente puesto ATC;
— actualiza los datos del plan de vuelo básico;
— facilita la pronta correlación de los datos de los seguimientos
por radar;
— facilita una exacta valoración a corto plazo de la carga de un
sector.
El ABI es un mensaje de notificación.
6.2.2. Contenidos de mensaje
El mensaje ABI deberá contener los siguientes datos:
— Tipo de mensaje2000R2082 — ES — 15.06.2002 — 001.001 — 23
▼M1
▼M1
— Número de mensaje
— Identificación de aeronave
— Modo y código SSR (si está disponible)— Aeródromo de salida— Datos estimados
— Aeródromo de destino
— Número y tipo de aeronave— Tipo de vuelo— Capacidad y estado de los equipos
— Ruta (opcional)
— Otros datos del plan de vuelo (opcional).
NOTA: Las normas de introducción de datos, los formatos y los
contenidos de los campos se especifican en el anexo A.
6.2.3. Normas de aplicación
6.2.3.1. General
6.2.3.1.1. A excepción de lo dispuesto en los apartados 6.2.3.1.3 y 6.2.3.1.4
siguientes, deberán enviarse uno o más mensajes ABI por cada
vuelo que vaya a cruzar el límite de áreas de responsabilidad
con sujeción a los procedimientos OLDI.
6.2.3.1.2. Cuando se envíe, el mensaje ABI deberá preceder al mensaje de
activación (ACT) o al mensaje de propuesta de activación acor-
dada (RAP).
6.2.3.1.3. No se generará un mensaje ABI si va a enviarse un mensaje de
activación preliminar (PAC).
6.2.3.1.4.Recomendación La transmisión ABIdebería inhibirse si va a
transmitirse un mensaje ACT o RAP inmediatamente o dentro de
un intervalo de tiempo acordado bilateralmente.
NOTA El propósito de esta recomendación es evitar que en
distintas posiciones del puesto receptor se intente
resolver de forma simultánea anomalías en relación con
mensajes ABIy ACT para el mismo vuelo.
6.2.3.1.5. Se enviará un mensaje ABI revisado si no se ha generado el
consiguiente mensaje ACT y:
— la ruta del vuelo ha sido modificada de modo que el COP del
mensaje ABI anterior ya no sea exacto;
— Se ha cambiado el aeródromo de destino;
o
— Se ha cambiado el tipo de aeronave.
6.2.3.1.6.Recomendación Debería enviarse un mensaje ABI revisado si no
se ha generado el consiguiente mensaje ACT y uno de los
siguientes elementos está sujeto a cambios:
—El nivel previsto de cruce de límite;
—El código SSR previsto en el punto de transferencia de
control;
—Cuando el tiempo estimado (ETO) en el COP difiere del
mensaje ABIprecedente en más del tiempo especificado en
la Carta de Acuerdo (LoA);
—Cualquier otro dato acordado bilateralmente .
6.2.3.2. Procesamiento en el puesto receptor
6.2.3.2.1. El sistema ATC que recibe un mensaje ABI deberá intentar su
asociación con los datos del plan de vuelo correspondiente.
6.2.3.2.2. Si la asociación con el plan de vuelo fracasa, deberá crearse un
plan de vuelo, automática o manualmente, en el sistema receptor.
6.2.3.2.3. Si la asociación con el plan de vuelo tiene éxito, pero se identi-
fica una discrepancia entre los datos del mensaje y los datos
correspondientes en el sistema receptor, que obliguen a realizar
una acción correctiva a la recepción del mensaje ACT siguiente,
deberá señalarse la discrepancia en el puesto de trabajo adecuado,
para su resolución.2000R2082 — ES — 15.06.2002 — 001.001 — 24
▼B
▼B
6.2.3.3. Parámetros de tiempo para transmisión
6.2.3.3.1. El mensaje deberá ser transmitido un número de minutos antes de
la hora estimada de paso por el COP.
6.2.3.3.2. El parámetro de generación ABI se incluirán en la LoA entre los
puestos ATC interesados.
6.2.3.3.3.Recomendación Los parámetros de generación ABI deberían:
—Ser variables en función de las disposiciones de la LoA;
—Estar definidos de forma individual para cada uno de los
COP.
6.2.4. Acuse de recibo de mensaje ABI
6.2.4.1. Acuse de recibo
El acuse de recibo del mensaje ABI deberá ser realizado
mediante la generación y transmisión de un mensaje LAM.
NOTA Se generará un mensaje LAM independientemente del
resultado del intento de asociación del plan de vuelo.
6.2.4.2. Ausencia de acuse de recibo
Recomendación Si no se recibe un mensaje LAM como acuse de
recibo de un mensaje ABI, debería visualizarse un aviso en un
puesto supervisor.
6.2.5. Ejemplos
«Air 2000» 253, un Boeing 757 de Malta a Birmingham, hora
estimada de llegada al VOR BNE a las 1221 UTC, volando a
FL350 a una velocidad real de 480 nudos, ruta prevista vía UB4
BNE UB4 BPK UB3 HON, transpondedor en A7012 y solici-
tando FL390. A continuación se proporcionan ejemplos
equivalentes del mensaje ABI enviado desde Reims a Londres
ACC.
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.Mensajedeactivación(ACT)
6.3.1. Objeto del mensaje ACT
El mensaje ACT satisface los siguientes requisitos operativos:
— Reemplaza el límite verbal estimado mediante la transmisión
automática de detalles de un vuelo de un puesto ATC al
siguiente antes de la trasferencia de control;
— Actualiza los datos del plan de vuelo básico en el puesto ATC
receptor, con información más reciente;
— Facilita la distribución y visualización de datos del plan de
vuelo dentro del puesto ATC receptor a los puestos de trabajo
afectados;
— Acelera la visualización de la relación indicativo de llamada/
código en el puesto receptor ATC;
— Proporciona condiciones de transferencia al puesto receptor
ATC.
6.3.2. Contenidos de mensaje
El mensaje ACT deberá contener los siguientes datos:
— Tipo de mensaje
— Número de mensaje2000R2082 — ES — 15.06.2002 — 001.001 — 25
▼M1
▼B
▼M1
▼M1
— Identificación de aeronave
— Modo y código SSR
— Aeródromo de salida— Datos estimados
— Aeródromo de destino
— Número y tipo de aeronave— Tipo de vuelo
— Capacidad y estado de los equipos
— Ruta (opcional)— Otros datos del plan de vuelo (opcional).
NOTA: Las normas de introducción de datos, los formatos y los
contenidos de los campos se especifican en el anexo A.
6.3.3. Normas de aplicación
6.3.3.1. General
6.3.3.1.1. Deberá enviarse un mensaje ACT para los vuelos autorizados que
crucen el límite, a excepción de lo dispuesto en el
apartado 6.3.3.1.10.
6.3.3.1.2. Deberá generarse y transmitirse automáticamente el mensaje ACT
en la hora calculada en la LoA, a menos que se haya iniciado
manualmente con anterioridad.
6.3.3.1.3.Recomendación El personal ATC debería disponer de medios
para iniciar la transmisión de mensajes ATC con anterioridad a
la hora calculada de transmisión.
6.3.3.1.4. Los contenidos operativos del mensaje ATC que va a ser transmi-
tido, deberán ser visualizados en el puesto de trabajo responsable
de la coordinación del vuelo antes de su transmisión.
6.3.3.1.5.Recomendación En relación con el apartado 6.3.3.1.4, la hora a
la que se calcula que el ACT va a ser transmitido automática-
mente debería visualizarse junto con su contenido.
6.3.3.1.6. El mensaje ACT deberá contener la información más reciente del
vuelo, reflejando las condiciones previstas para la salida.
6.3.3.1.7. El puesto de trabajo pertinente será notificado de la transmisión
del mensaje ACT.
6.3.3.1.8. Tan pronto como un LAM haya sido recibido, los datos del
mensaje ACT pasan a ser vinculantes operativamente para los
dos puestos ATC. El personal ATC del puesto de transferencia
deberá ser informado de las condiciones de transferencia coordi-
nada y del hecho de que el LAM ha sido recibido.
6.3.3.1.9. Se supondrá que el puesto receptor ha aceptado las condiciones
de transferencia incluidas en el mensaje ACT, a menos que el
puesto receptor inicie una coordinación para corregirlas.
6.3.3.1.10. Solamente podrá enviarse un mensaje ACT complementario al
mismo interlocutor de coordinación si el mensaje anterior ha
sido revocado utilizando el uso de un MAC.
6.3.3.1.11. La ruta y otros datos del plan de vuelo deberán incluirse si han
sido acordados bilateralmente.
6.3.3.2. Procesamiento en el puesto receptor
6.3.3.2.1. El sistema ATC que recibe un mensaje ATC deberá intentar su
asociación con el plan de vuelo correspondiente.
6.3.3.2.2. Si se encuentra un plan de vuelo correspondiente y no aparecen
discrepancias en el mensaje que impidan su correcto procesa-
miento:
— el contenido operativo deberá incluirse en el plan de vuelo;
— los datos requeridos deberán enviarse al ATC operativo y a
otros puestos que lo necesiten;
— deberá enviarse un LAM en respuesta.2000R2082 — ES — 15.06.2002 — 001.001 — 26
▼B
▼B
6.3.3.2.3. Si no puede encontrarse el plan de vuelo correspondiente o
aparece alguna discrepancia que impida el procesamiento correcto
del mensaje:
— si el sector responsable de aceptar el control del vuelo puede
seridentificado:
— el contenido operativo del mensaje será visualizado en el
sector;
— deberá enviarse un LAM en respuesta;
— deberá crearse un plan de vuelo;
— En todos los demás casos, no se enviará un LAM en
respuesta.
6.3.3.3. Parámetros para transmisión6.3.3.3.1. El mensaje deberá ser transmitido lo antes posible después del
primero de los dos tiempos calculados a partir de lo siguiente:
— un número de minutos antes del tiempo estimado en el COP;
— la hora a la que el vuelo se encuentra a una distancia acor-
dada bilateralmente del COP.
6.3.3.3.2. Los parámetros de generación del mensaje ACT deberán incluirse
en la LoA entre los puestos ATC interesados.
6.3.3.3.3. Los parámetros de generación del mensaje ACT serán variables
según las provisiones de la LoA.
6.3.3.3.4.Recomendación Los parámetros de generación del mensaje ACT
deberían definirse individualmente para cada uno de los COP.
6.3.3.3.5. Los parámetros especificados dejarán tiempo suficiente para:
— que el puesto transmisor actualice el nivel de vuelo de trans-
ferencia de forma que refleje las condiciones previstas en el
COP;
y
— que el puesto receptor procese el mensaje ACT, genere y
transmita un mensaje LAM, permita una coordinación verbal
por parte del puesto de transferencia y la iniciación, por el
puesto receptor, de la acción pertinente en caso de fallar el
intercambio de datos.
6.3.4. Acuse de recibo de mensaje ACT
6.3.4.1. Acuse de recibo
El acuse de recibo del mensaje ACT deberá realizarse mediante
la generación y transmisión de un mensaje LAM.
6.3.4.2. Casos de ausencia de acuse de recibo
Si no se recibe el mensaje LAM como acuse de recibo de un
mensaje ACT, deberá mostrarse un aviso en el puesto ATC
responsable de la coordinación del vuelo.
6.3.5. Ejemplos
Los ejemplos siguientes son una extensión de los expuestos para
el mensaje ABI en el párrafo 6.2; todos los detalles son los
mismos excepto el ETO en el COP, que es 1226 en el mensaje
ACT que se muestra.
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 -ADEP
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.2000R2082 — ES — 15.06.2002 — 001.001 — 27
▼M1
▼B
6.4.Mensajedeacusederecibológico(LAM)
6.4.1. Objeto del mensaje LAM
El mensaje LAM es el medio porel cual el puesto r eceptorindica
al puesto emisor que el mensaje transmitido ha sido recibido y
salvaguardado.
El procesamiento de un LAM proporciona al personal ATC del
puesto receptor lo siguiente:
— un aviso, cuando no se ha recibido un acuse de recibo;
— una indicación de que el mensaje del que se ha acusado
recibo ha sido recibido, procesado con éxito, carece de
errores, se ha almacenado y si es necesario, está disponible
para su presentación en los puestos de trabajo que se requiera.
6.4.2. Contenidos de mensaje
El mensaje LAM deberá contener los siguientes datos:
— tipo de mensaje;
— número de mensaje;— referencia de mensaje.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
6.4.3. Normas de aplicación
6.4.3.1. General
6.4.3.1.1. Las normas para el envío de un mensaje LAM se especifican en
las secciones del presente documento en las que se define el
procesamiento de cada mensaje.
6.4.3.1.2. El mensaje LAM deberá generarse y transmitirse sin intervención
humana.
6.4.3.1.3. El mensaje LAM no deberá utilizarse para evitar la necesidad de
mensajes técnicos destinados a asegurar la integridad de las trans-
misiones de datos.
6.4.3.1.4. El mensaje LAM deberá generarse y transmitirse inmediatamente
de modo que se cumpla el requisito de tiempo de transacción del
mensaje del que se está acusando recibo.
6.4.3.1.5. A excepción de los mensajes ABI, el sistema transmisor ATC
deberá informar al controlador responsable de la coordinación
cuando un mensaje LAM no haya sido recibido dentro del tiempo
establecido para dichos avisos.
6.4.4. Acuse de recibo de mensaje LAM
El mensaje LAM no requerirá ningún acuse de recibo.
6.4.5. Ejemplos
6.4.5.1. ICAO
(LAML/E012E/L001)
6.4.5.2. ADEXP
-TITLE LAM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 012 -MSGREF -SENDER -FAC E -RECVR -FAC L -
SEQNUM 001
7.PROCEDIMIENTO BÁSICO — MENSAJES COMPLE-
MENTARIOS
7.1.General
7.1.1. Descripción de requisitos
Esta sección describe dispositivos aplicables al procedimiento
básico y complementarios a los descritos en la Sección 6 Procedi-
miento básico — Mensajes obligatorios.2000R2082 — ES — 15.06.2002 — 001.001 — 28
▼B
7.1.2. Implantación
7.1.2.1. La utilización de cualquiera de los dispositivos descritos en esta
sección deberá ser objeto de un acuerdo bilateral, antes de su
puesta en marcha.
7.1.2.2. Cuando se acuerde dicha utilización, se aplicarán las normas
descritas en la presente sección.
7.2.Mensajedeactivaciónpreliminar(PAC)
7.2.1. Objeto del mensaje PAC
El mensaje PAC satisface los siguientes requisitos operativos:
— notificación y coordinación anterior a la salida de un vuelo
cuando el tiempo de vuelo desde la salida hasta el COP es
menor del que se necesitaría para cumplir con los parámetros
de tiempo acordados para la transmisión del mensaje ACT;
— notificación y coordinación anterior a la salida de un vuelo
antes de la salida por parte de un puesto local (aeródromo/
control de aproximación) al siguiente puesto que tomará
control del vuelo;
— facilita la recuperación de datos perdidos del plan de vuelo en
caso de discrepancias en la distribución inicial de datos del
plan de vuelo;
— solicita, del puesto al que es enviada la notificación/coordina-
ción, la asignación de un código SSR, en caso de que sea
necesario.
7.2.2. Contenidos del mensaje
El mensaje PAC deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;
— Referencia de mensaje (opcional);
— Identificación de la aeronave;— Modo y código SSR;
— Aeródromo de salida;
— Hora de despegue estimada o datos estimados;— Aeródromo de destino;— Tipo de aeronave;
— Ruta (opcional);
— Otros datos del plan de vuelo (opcional).
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
7.2.3. Normas de aplicación
7.2.3.1. General7.2.3.1.1. Deberán enviarse uno o más mensajes PAC para cada vuelo que
vaya a cruzar un límite de áreas de responsabilidad cuando el
tiempo desde la salida hasta el COP no permita el envío de un
mensaje ACT en el momento requerido.
7.2.3.1.2. El aeródromo/puesto de aproximación enviará uno o más
mensajes PAC al puesto siguiente porcada vuelo que salga y
deba serobjeto de una notificación o coor dinación.
7.2.3.1.3.Recomendación Para la implantación de mensajes PAC/LAM
entre puestos, los sistemas TWR/APP deberían disponer de
medios para introducir y enviar la información «start-up» ,
«push-back» , «taxi» o similarde la que pueda deducir se el ETO
en el COP e iniciarla tr ansmisión del PAC.
7.2.3.1.4. Según lo acordado bilateralmente, el mensaje contendrá:
— la hora estimada de despegue;
o
— los datos estimados.
7.2.3.1.5. Cuando se incluye la referencia del mensaje, por acuerdo bila-
teral, el mensaje deberá:
— contener el número de mensaje del primer mensaje PAC
enviado para el vuelo;2000R2082 — ES — 15.06.2002 — 001.001 — 29
▼B
— estarincluido en el segundo mensaje PAC y en los poste-
riores.
7.2.3.1.6. La utilización del dispositivo de solicitud de código, si es nece-
saria, será acordada bilateralmente.
7.2.3.1.7. Deberá enviarse un mensaje PAC revisado si, antes de la salida,
se cumple cualquiera de las condiciones siguientes:
— se ha modificado la ruta de vuelo de forma que el COP en el
mensaje anterior ya no es exacto;
— se ha cambiado el tipo de aeronave;— se considera incorrecto el aeródromo de destino indicado en el
PAC anterior.
7.2.3.1.8.Recomendación Debería enviarse un mensaje PAC revisado si,
antes de la salida, los siguientes datos difieren de los del mensaje
PAC precedente:
—el nivel (en los datos estimados, si se incluyen);
—el código SSR esperado en el punto de transferencia de
control;
—la hora estimada de despegue o el ETO en el COP si la
variación excede un valor acordado bilateralmente;
—hay un cambio en cualquier otro dato, según se haya acor-
dado bilateralmente .
7.2.3.2. Procesamiento en el Puesto Receptor
7.2.3.2.1. El sistema ATC que recibe un mensaje PAC deberá intentar su
asociación con el plan de vuelo correspondiente.
7.2.3.2.2. Si se encuentra un plan de vuelo correspondiente y no hay discre-
pancias en el mensaje que puedan obstaculizarsu pr ocesamiento
correcto:
— el contenido operativo deberá incluirse en el plan de vuelo;
— los datos requeridos deberán enviarse al ATC operativo y a
otros puestos, según sea necesario;
— Deberá enviarse un LAM en respuesta.
7.2.3.2.3. Si el mensaje no puede serasociado a ningún plan de vuelo o se
encuentra una discrepancia que obstaculiza el correcto procesa-
miento del mensaje:
— si el sector responsable de aceptar el control del vuelo puede
seridentificado:
— el contenido operativo del mensaje deberá visualizarse en
el sector;
— deberá enviarse un LAM en respuesta;— deberá crearse un plan de vuelo;
— En todos los demás casos no deberá enviarse un LAM en
respuesta.
7.2.3.2.4. Los datos de un segundo mensaje PAC o de cualquierPAC poste-
rior deberán sustituir a los datos de los mensajes previos.
7.2.3.2.5. Si el mensaje PAC incluye una solicitud de asignación de un
código SSR y puede procesarse correctamente según se describe
en el apartado 7.2.3.2.2, deberá enviarse un mensaje COD además
del LAM.
NOTA Dado que el proceso de asignación de código requiere
información detallada de la ruta del plan de vuelo, no
se incluye ningún requisito en el presente documento
para el envío de un mensaje COD por parte del puesto
receptor cuando dichos datos no estén disponibles. Esto
no excluye que se devuelva un mensaje en dichas circuns-
tancias si se dispone de los medios adecuados y el
procedimiento ha sido acordado bilateralmente.
7.2.3.3. Parámetros de tiempo de transmisión
Ningún parámetro de tiempo de transmisión es aplicable dado que
el mensaje se envía a consecuencia de un mensaje introducido
manualmente que identifica la inminente salida del vuelo.2000R2082 — ES — 15.06.2002 — 001.001 — 30
▼B
7.2.4. Acuse de recibo de mensaje PAC
7.2.4.1. Acuse de recibo
Los mensajes enviados en respuesta a un mensaje PAC se
describen en el párrafo 7.2.3.2.
7.2.4.2. Ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje PAC, se visualizará un aviso en el puesto ATC respon-
sable de la coordinación con el siguiente puesto.
7.2.4.3. Casos de ausencia de mensaje LAM
En los casos en los que no haya mensaje LAM, deberá iniciarse
una coordinación verbal.
7.2.4.4. Ausencia de mensaje COD
7.2.4.4.1. Si no se recibe un mensaje COD en respuesta a una solicitud de
código incluida en el mensaje PAC, se visualizará un aviso en el
puesto adecuado.
7.2.4.4.2. Cuando se utilice la función de solicitud de código, el valorde
tiempo que debe aplicarse deberá acordarse bilateralmente.
7.2.5. Ejemplos
7.2.5.1. Hora estimada de despegue y solicitud 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 en el COP
7.2.5.2.1. ICAO
(PACD/L025-EIN636/A5102-EIDW-LIFFY/1638F290F110A-
EBBR-9/B737/M)
7.2.5.2.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -SSRCODE A5102 -ADEP
EIDW -COORDATA -PTID LIFFY -TO 1638 -TFL F290 -SFL
F110A -ARCTYP B737 -ADES EBBR
7.3.Mensajederevisión(REV)
7.3.1. Objeto del mensaje REV
El mensaje REV se utiliza para transmitir revisiones de los datos
de coordinación enviados previamente en un mensaje ACT en el
supuesto de que el puesto receptor no cambie como resultado de
la modificación.
7.3.2. Contenidos del mensaje
El mensaje REV deberá contener los siguientes datos:
— Tipo de mensaje
— Número de mensaje— Identificación de la aeronave— Aeródromo de salida— Datos estimados y punto de coordinación— Aeródromo de destino— Referencia del mensaje (opcional)— Modo y código SSR (opcional)— Ruta (opcional)— Capacidad y estado de los equipos (opcional).
NOTA: Las normas de introducción de datos, los formatos y los
contenidos de los campos se especifican en el anexo A.2000R2082 — ES — 15.06.2002 — 001.001 — 31
▼M1
▼B
7.3.3. Normas de aplicación
7.3.3.1. General
7.3.3.1.1. Pueden enviarse uno o más mensajes REV al puesto al cual se ha
coordinado un vuelo mediante el uso de un mensaje de activación
7.3.3.1.2. Los siguientes elementos deberán ser objeto de revisiones:
— ETO en el COP
— Nivel(es) de transferencia
— Código SSR
— Capacidad y estado de los equipos.
7.3.3.1.3. Deberá enviarse un mensaje REV cuando:
— el ETO en el COP difiera del incluido en los mensajes previos
en más de un valor acordado bilateralmente, redondeado al
valor entero más próximo;
— haya cualquier cambio en los niveles de transferencia, en el
código SSR o en la capacidad y estado de los equipos.
7.3.3.1.4. Deberá enviarse un mensaje REV, si se ha acordado bilateral-
mente, cuando se produzca algún cambio que afecte a:
— el COP
— la ruta.
NOTA: Las normas operativas pueden exigir que las modifica-
ciones efectuadas después de un ACT estén sujetas a
una coordinación previa entre los puestos interesados.
7.3.3.1.5. Cuando se acuerde bilateralmente, la referencia de mensaje
deberá incluirse en el mensaje REV.
7.3.3.1.6. La referencia de mensaje, cuando se incluya, deberá contener el
número del mensaje ACT precedente.
7.3.3.1.7. Se supondrá que el puesto ATC receptor ha aceptado las condi-
ciones de transferencia incluidas en el mensaje REV, a menos
que el puesto receptor inicie una coordinación para corregirlas.
7.3.3.2. Formato de mensajes de revisión
7.3.3.2.1. Formato I C A O
Todos los mensajes de revisión incluyen los campos tipo 3, 7, 13,
14 y 16. Se aplicarán las siguientes normas:
— Cualquiercambio del ETO en el COP o del nivel o niveles de
transferencia deberá figurar en los datos revisados del campo
14.
— Cualquier cambio en el código SSR deberá incluirse como
elementos b) y c) del campo 7.
Las demás modificaciones deberán incluirse en el formato del
campo 22, después de los cinco primeros campos. Se aplicarán
las siguientes normas:
— Los campos incluidos en el formato del campo 22 pueden
seguircualquieror den.
— Los cambios en el COP deberán incluirse como datos del
campo 14 en el formato del campo 22 (véase el anexo B —
Requisitos especiales para el procesamiento de rutas).
— Los cambios de ruta deberán incluirse como datos del campo
15 en el formato del campo 22. Las normas para la coordina-
ción de dichos cambios, incluidas las rutas directas, se
especifican en el anexo B — Requisitos especiales para el
procesamiento de rutas.
— Capacidad y estado de los equipos. Sólo se incluirán las capa-
cidades modificadas. Un mensaje que modifique una
capacidad de modo que resulte necesario incluir datos sobre
una capacidad complementaria, como se especifica en el apar-
tado A.30 del anexo A, deberá incluir la capacidad
complementaria.2000R2082 — ES — 15.06.2002 — 001.001 — 32
▼M1
▼B
▼M1
▼M1
7.3.3.2.2. Formato A D E X P
Todos los mensajes de revisión en formato A D E X P deberán
incluir los siguientes campos primarios: TITLE REFDATA
ARCID ADEP ADES. Se aplicarán las siguientes normas:
— Cualquiercambio del ETO en el COP o del nivel o niveles de
transferencia deberá incorporarse mediante la inclusión de los
datos revisados en el campo primario COORDATA.
— Deberá incluirse el campo primario COP, salvo si un cambio
de ETO o del nivel o niveles de transferencia exige el uso del
campo primario COORDATA. Deberá incluir el COP a través
del cual se está coordinando el vuelo o, en caso de modifica-
ción del COP, el COP a través del cual se ha coordinado el
vuelo previamente.
— Los cambios de COP deberán incorporarse mediante el campo
primario COORDATA (véase el anexo B — Requisitos espe-
ciales para el procesamiento de rutas). Estos mensajes deberán
incluir asimismo el campo primario COP, como se indica más
arriba.
— Los cambios de ruta deberán incorporarse mediante el campo
primario ROUTE. Las normas para la coordinación de dichos
cambios, incluidas las rutas directas, se especifican en el
anexo B — Requisitos especiales para el procesamiento de
rutas.
— Cualquier cambio en el código SSR deberá indicarse mediante
la inclusión del campo primario SSRCODE.
— Cualquiercambio con r especto a la capacidad y estado de los
equipos deberá mencionarse en el campo primario EQCST.
Sólo se incluirán las capacidades modificadas. Un mensaje
que modifique una capacidad de modo que resulte necesario
incluir datos sobre una capacidad complementaria, como se
especifica en el apartado A.30 del anexo A, deberá incluir la
capacidad complementaria.
7.3.3.2.3. Código SSR
El Modo y Código SSR deberán incluirse en un mensaje REV
solamente cuando sea necesario para coordinar un cambio de
código SSR.
7.3.3.3. Procesamiento en el puesto receptor7.3.3.3.1. Un sistema ATC que recibe un mensaje REV después de recibir
un mensaje ACT del mismo puesto ATC en relación con el vuelo
en cuestión deberá intentar asociarlo con el plan de vuelo corres-
pondiente.
7.3.3.3.2. Si se encuentra el plan de vuelo correspondiente y no hay
ninguna discrepancia en el mensaje que pueda obstaculizar su
procesamiento correcto:
— El contenido operativo deberá incluirse en el plan de vuelo;
— Los datos requeridos deberán enviarse al ATC operativo y a
otros puestos, según sea necesario.
7.3.3.4. Inicio de transmisión7.3.3.4.1. El mensaje REV está desencadenado porun suceso y deber á
transmitirse inmediatamente después de la introducción o actuali-
zación de los datos correspondientes.
7.3.3.4.2. No podrá realizarse ningún cambio mediante la utilización de un
mensaje REV después de que el vuelo se encuentre a una deter-
minada distancia del punto de transferencia o después de un
determinado tiempo. Los parámetros de tiempo y distancia
deberán ser objeto de un acuerdo bilateral.
7.3.3.4.3.Recomendación Los parámetros REV deberían ser definidos
individualmente para cada uno de los COP.
7.3.3.5. Cambio del puesto ATC receptor
No deberá utilizarse el mensaje REV si una revisión de los datos
del plan de vuelo conduce a un cambio del puesto ATC receptor
(ver Mensaje para anular la coordinación).2000R2082 — ES — 15.06.2002 — 001.001 — 33
▼B
▼B
7.3.4. Acuse de recibo de mensaje REV
7.3.4.1. Acuse de recibo
Si el mensaje REV:
— puede asociarse con un plan de vuelo dentro del sistema
receptor, deberá transmitirse un mensaje LAM como acuse
de recibo;
— no puede asociarse con un plan de vuelo dentro del sistema
receptor, no deberá transmitirse un mensaje LAM.
7.3.4.2. Ausencia de acuse de recibo7.3.4.2.1. Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje REV, se visualizará un aviso en el puesto ATC respon-
sable de la coordinación de los vuelos.
7.3.4.2.2. En los casos en los que no haya mensaje LAM, el puesto ATC de
transferencia deberá iniciar una revisión verbal.
7.3.5. Ejemplos
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.Mensajeparaanulacióndecoordinación(MAC)
7.4.1. Objeto del mensaje MAC
Un mensaje MAC se utiliza para indicar al puesto receptor que se
ha revocado la coordinación o notificación efectuada previamente
para un vuelo.
El MAC no reemplaza a un mensaje de cancelación (CNL), según
define ICAO, y, por consiguiente, no deberá utilizarse para borrar
los datos del plan de vuelo básico.
7.4.2. Contenidos del mensaje
El mensaje MAC deberá contener los siguiente datos:
— Tipo de mensaje;
— Número de mensaje;— Referencia del mensaje (opcional);— Identificación de la aeronave;
— Aeródromo de salida;
— Punto de coordinación;— Aeródromo de destino;— Situación de la coordinación y motivo de la revocación
(opcional).2000R2082 — ES — 15.06.2002 — 001.001 — 34
▼M1
▼B
▼B
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
7.4.3. Normas de aplicación
7.4.3.1. General
7.4.3.1.1. Un mensaje MAC deberá enviarse a un puesto que ha efectuado
previamente la coordinación de un vuelo, mediante la utilización
de un mensaje ACT o RAP, en cualquiera de los siguientes supu-
estos:
— cuando el nivel esperado en el punto de transferencia sea
distinto del nivel indicado en el mensaje previo, dando lugar
a un cambio del siguiente puesto en la secuencia de coordina-
ción;
— cuando la ruta de vuelo haya sido modificada, provocando un
cambio del puesto siguiente de la secuencia de coordinación;
— cuando el plan de vuelo del sistema haya sido cancelado en el
puesto emisor y la coordinación ya no sea pertinente;
— cuando se ha recibido un MAC del puesto previo en relación
con el vuelo.
7.4.3.1.2. Cuando se envía un mensaje MAC debido a un cambio de nivel
de vuelo o de ruta, la notificación y/o coordinación, según el
caso, deberá realizarse con el nuevo puesto en la secuencia de
coordinación.
7.4.3.1.3. Deberá enviarse un mensaje MAC en caso de anulación de la
coordinación de un vuelo mediante la utilización de un mensaje
RAP.
7.4.3.1.4.Recomendación Debería enviarse un mensaje MAC cuando se
cancele la notificación (mensaje ABI) efectuada previamente
para un vuelo por cualquiera de los motivos especificados en el
párrafo 7.4.3.1.1 o cuando el vuelo se retrase en ruta y no pueda
determinarse automáticamente una estimación revisada.
7.4.3.1.5. Se incluirá una referencia de mensaje si ha sido acordado bilate-
ralmente.
7.4.3.1.6. La referencia de mensaje, en su caso, deberá contener el número
de mensaje del último ABI, PAC o ACT transmitido para el
vuelo y del que se ha recibido acuse de recibo.
7.4.3.1.7. El punto de coordinación deberá ser el COP a través del cual el
vuelo ha sido notificado o coordinado previamente.
7.4.3.1.8.Recomendación El mensaje MAC debería indicar el estado al
que deben retornar la notificación o la coordinación y el motivo
de la anulación.
7.4.3.1.9. Si se incluyen, el estado y el motivo deberán ser una de las
siguientes combinaciones:
— Cuando el puesto receptor ya no sea el siguiente interlocutor
de coordinación:
— el estado es INI (inicial);
— el motivo es uno de los siguientes:
— TFL si el motivo es un cambio del nivel de transfe-
rencia;
— RTE si el motivo es un cambio de ruta;
— CSN si el motivo es un cambio del indicativo de
llamada;
— CAN si el motivo es una cancelación;
— OTH porcualquierotr o motivo o si el motivo es
desconocido;
— cuando se presenta una de las siguientes condiciones:
— la coordinación efectuada por medio de un mensaje PAC
o ACT previo (modificado por cualquier mensaje REV
posterior) es revocada, pero el vuelo debe ser objeto de
una nueva secuencia de coordinación con el mismo
puesto;
o
— después de la transmisión de un mensaje ABI, el vuelo
está en espera durante un tiempo indefinido y deberá dar2000R2082 — ES — 15.06.2002 — 001.001 — 35
▼B
lugaral envío de un mensaje ABI o ACT r evisado, según
el caso:
— el estado es NTF (notificación);
— el motivo es uno de los siguientes:
— DLY si el motivo es un retraso;
— HLD si el motivo es una espera;— OTH porcualquierotr o motivo o si el motivo es
desconocido.
7.4.3.1.10. Si el vuelo es objeto de una nueva notificación o coordinación:
— se deberá enviar un nuevo mensaje de notificación y/o de
coordinación según el caso;
— los datos del plan de vuelo básico almacenados en el puesto
ATC receptor no deberán verse afectados por ningún mensaje
MAC;
— el sistema deberá retener la capacidad de procesar correcta-
mente un nuevo mensaje de notificación y/o de coordinación
procedente del puesto transmisor previo o de un puesto dife-
rente en una nueva secuencia de coordinación.
7.4.3.2. Procesamiento en el puesto receptor
Deberá notificarse la anulación a los puestos de trabajo del puesto
receptor ATC a los que se les suministren detalles del vuelo.
7.4.4. Acuse de recibo de un mensaje MAC
7.4.4.1. Acuse de recibo7.4.4.1.1. Si el mensaje MAC puede serasociado con un plan de vuelo
dentro del sistema receptor y puede ser procesado, deberá trans-
mitirse un mensaje LAM en señal de acuse de recibo.
7.4.4.1.2. Si el mensaje MAC no puede serasociado con un plan de vuelo
dentro del sistema receptor o no puede ser procesado, no deberá
transmitirse un mensaje LAM.
7.4.4.2. Ausencia de acuse de recibo7.4.4.2.1. Si se está revocando la coordinación ATC y no se recibe un
mensaje LAM, deberá visualizarse un aviso en el puesto ATC
responsable de la coordinación.
7.4.4.2.2. En dichos casos, el puesto ATC de transferencia deberá efectuar
una revocación verbal de la coordinación.
7.4.5. Ejemplos
El ACC de Amsterdam ha enviado un mensaje ABI al ACC de
Bruselas para el vuelo HOZ3188, altitud prevista FL190; el vuelo
solicita posteriormente ascender al FL270 y recibe autorización,
entrando en el espacio aéreo de Maastricht en lugar del de
Bruselas. Los ejemplos 7.4.5.1 a y 7.4.5.2 a muestran cómo
sería el MAC enviado a Bruselas por Amsterdam tanto en el
formato ICAO como ADEXP.
Un mensaje ABI y, posteriormente, un ACT se envían a Maas-
tricht, pero unos pocos minutos antes de alcanzar el COP, la
aeronave vuelve al Aeropuerto de Amsterdam y el plan de vuelo
es cancelado en el sistema del puesto emisor; se envía un mensaje
MAC a Maastricht según se muestra en los ejemplos (7.4.5.1 b y
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 — ES — 15.06.2002 — 001.001 — 36
▼B
7.5.MensajedeasignacióndecódigoSSR(COD)
7.5.1. Objeto del mensaje COD
7.5.1.1. El método de Asignación de código en función de la región de
origen (ORCAM) se ha concebido para permitir a un vuelo
responder en el mismo código a los puestos sucesivos dentro de
una región de participación. A menos que se realice una asigna-
ción de código de manera central, por ejemplo por un ACC,
puede sernecesar io asignarindividualmente un conjunto de
códigos SSR discretos a los aeropuertos. Estas asignaciones
suponen un gran desperdicio de códigos.
7.5.1.2. El mensaje COD satisface el requisito operativo de emitir un
código SSR en modo A porcada puesto ATS a otr o sucesivo
para un vuelo determinado cuando se solicita. Una instalación
opcional permite al puesto emisor incluir la ruta de vuelo, si ha
sido acordado bilateralmente.
7.5.2. Contenidos de mensaje
El mensaje COD deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;— Referencia de mensaje (opcional);— Identificación de la aeronave;— Modo y código SSR;
— Aeródromo de salida;
— Aeródromo de destino;— Ruta (opcional).
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
7.5.3. Normas de aplicación
7.5.3.1. General
7.5.3.1.1. Deberá generarse y transmitirse un mensaje COD automática-
mente en respuesta a una solicitud de asignación de código
recibida en un mensaje.
7.5.3.1.2. El código SSR deberá ser el código asignado al vuelo.
7.5.3.1.3. Deberá incluirse el código de saturación aprobado, según se espe-
cifica en Plan de navegación aérea para la región europea, en
caso de no poderdisponerde un código individual.
7.5.3.1.4. Si se ha acordado bilateralmente, deberá incluirse la referencia de
mensaje que contiene el número de mensaje al que responde el
mensaje COD.
7.5.3.1.5. La ruta deberá incluirse si se ha acordado bilateralmente.
7.5.3.1.6. Se deberá suponer la aceptación del código SSR por parte del
puesto receptor del mensaje COD.
7.5.3.2. Procesamiento en el puesto receptor
7.5.3.2.1. Deberá enviarse un LAM en respuesta siempre que no existan
discrepancias en el mensaje que pudieran impedir su correcto
procesamiento.
7.5.3.2.2. Si el mensaje no puede asociarse con un plan de vuelo o si se
encuentra una discrepancia que impida el procesamiento correcto
del mensaje, no deberá enviarse un LAM en respuesta.
7.5.3.2.3. Los datos de la ruta, si están incluidos, no serán motivo para
impedirel envío de un LAM, a menos que no cumplan con los
requisitos de formato indicados en el Anexo A.
7.5.3.3. Parámetros de tiempo de transmisión
No será aplicable la transmisión de un parámetro de tiempo,
puesto que el mensaje COD se envía como consecuencia de la
recepción de un mensaje en el que se solicita la asignación de
un código SSR.2000R2082 — ES — 15.06.2002 — 001.001 — 37
▼B
7.5.4. Acuse de recibo de COD
7.5.4.1. Acuse de recibo
El acuse de recibo de un mensaje COD se realizará mediante la
generación y transmisión de un mensaje LAM.
7.5.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje COD, deberá visualizarse un aviso en el puesto de
trabajo adecuado.
7.5.5. Ejemplos
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.Mensajedeinformación(INF)
7.6.1. Objeto del mensaje INF
7.6.1.1. El mensaje INF se utiliza para proporcionar información sobre
ciertos vuelos a agencias que no están directamente implicadas
en el proceso de coordinación entre dos puestos ATC sucesivos
de una ruta de vuelo.
7.6.1.2. El mensaje INF puede utilizarse para enviar a estas agencias
copias de los mensajes y para comunicar las condiciones acor-
dadas de coordinación después de un diálogo entre
controladores. Para este propósito, los mensajes INF pueden ser
generados por los sistemas del puesto que transfiere o del que
acepta el mensaje.
7.6.1.3. El mensaje INF puede servir también para enviar información
relativa a cualquier punto de la ruta de vuelo a una agencia.
7.6.1.4. El formato permite la comunicación de datos iniciales, revisiones
y cancelaciones.
7.6.2. Contenidos de mensaje
El mensaje INF deberá contener los siguientes datos en el
formato de mensaje descrito en el presente documento:
— Tipo de mensaje;
— Número de mensaje;— Todos los elementos de datos operativos contenidos en el
mensaje original o resultante de la coordinación que esta
siendo copiada;
— Tipo de mensaje de referencia.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se indican en el Anexo A.
7.6.3. Normas de aplicación
7.6.3.1. Tipos de mensaje
Los tipos de mensaje que deben serduplicados porun mensaje
INF se basarán en los requisitos de los usuarios y la capacidad
de los puestos emisores. Los tipos de mensaje y las normas de
aplicación estarán, por lo general, acordadas de forma bilateral.
7.6.3.2. Destinatarios de los mensajes
Pueden transmitirse uno o varios mensajes INF para el mismo
vuelo a uno o varios destinatarios.
7.6.3.3. Contenido operativo
El contenido operativo de un mensaje INF deberá estar en el
formato de uno de los mensajes existentes.
7.6.3.4.Recomendaciones
1.Las condiciones comunicadas en un mensaje de diálogo inicial
(p. ej. mensaje ACT, RAP, REV, RRV) pueden ser cambiadas o2000R2082 — ES — 15.06.2002 — 001.001 — 38
▼B
rechazadas antes del final del diálogo. Los puestos emisores
deberían poder comunicar las condiciones de coordinación
finalmente acordadas .
2.El mensaje INF debería ser enviado de forma inmediata o a
una hora relacionada con la hora en el COP, que ha sido
acordada bilateralmente con el puesto receptor .
7.6.4. Acuse de recibo de mensaje INF
Recomendaciones
1.El acuse de recibo de un mensaje INF puede hacerse, depen-
diendo del interlocutor de coordinación, mediante la
generación y transmisión de un mensaje LAM .
2.Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje INF, debería visualizarse un aviso en el puesto
adecuado, cuando se haya acordado bilateralmente .
7.6.5. Ejemplos
Un vuelo con un indicativo de llamada BAW011, B747 de EGLL
a OMDB, nivel de vuelo FL290, solicitando subira FL410,
estima llegaral VOR de Koksy (KOK) a las 1905, tr anspondedor
en A5437, avanzando vía UG1 y UB6.
Londres envía a Maastricht un mensaje ACT en relación con el
vuelo. Londres envía una copia a un puesto identificado como IT.
A continuación se proporcionan ejemplos del mensaje NIF.
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.PROCEDIMIENTODEDIÁLOGO—COORDINACIÓN
8.1.General
8.1.1. Introducción
8.1.1.1. El procedimiento de diálogo proporciona los medios de comuni-
cación y negociación entre controladores en la fase de
coordinación y los medios de comunicación en la fase de transfe-
rencia.
8.1.1.2. Esta sección describe los mensajes utilizados en el procedimiento
de diálogo en la fase de coordinación en la que se planifican las
condiciones de transferencia. Los mensaje para la fase de transfe-
rencia, en la que se realiza el traspaso del vuelo, se describen en
la Sección 9 — Procedimiento de diálogo — Transferencia de
comunicación.
8.1.1.3. Los procedimientos definidos para las dos fases no son interde-
pendientes, pueden seraplicados individualmente o en conjunto.
8.1.1.4. Se presenta una serie de mensajes adicionales y se respalda la
capacidad de cada interlocutor para iniciar un diálogo.
8.1.1.5. El procedimiento de diálogo en fase de coordinación permite la
identificación de:
— transferencias que están en conformidad con las LoA y
pueden seraceptadas automáticamente; y
— transferencias que deben remitirse al controlador del puesto
receptor, en espera de una aceptación sobre su aceptación.
8.1.1.6. Este procedimiento también permite comprobar la interpretación
de LoA en ambos sistemas e identificarcualquierdiscr epancia
entre ellas.2000R2082 — ES — 15.06.2002 — 001.001 — 39
▼B
8.1.2. El filtro
8.1.2.1. General
8.1.2.1.1. El procedimiento de diálogo en la fase de coordinación requiere
que el sistema determine si las transferencias están en confor-
midad con las LoA o no.
8.1.2.1.2. El proceso de verificación de esta conformidad se denomina en el
presente documento «el filtro». La base de datos utilizada para la
operación de filtrado incluirá, si es necesario, lo siguiente:
— puntos acordados de coordinación;
— niveles de vuelo admisibles (o inadmisibles) que puedan
asociarse con los puntos de coordinación;
— aeródromos de salida;
— destinos;
— rutas directas acordadas;— límites de hora y/o distancia anteriores al COP, a partir de la
que cualquier mensaje de coordinación se considera no
estándar;
— cualquier otra condición que haya sido acordada bilateral-
mente.
8.1.2.1.3. Todos los elementos de esta lista pueden combinarse para definir
condiciones más complejas.
8.1.2.1.4. En la Sección 8 del presente documento, el término «condiciones
estándar» deberá ser interpretado como «en conformidad con la
LoA» y el término «condiciones no estándar» como «en discon-
formidad con la LoA». Salvo acuerdos bilaterales en contrario,
los mensajes enviados por puestos de transferencia para coordina-
ciones que se sabe que son estándardeber án utilizartipos de
mensaje diferentes de aquellos utilizados para las coordinaciones
de condiciones no estándar.
8.1.2.2. Acciones en el puesto de transferencia
8.1.2.2.1. El filtro en el puesto de transferencia deberá revisar las condi-
ciones de transferencia que están a punto de ser comunicadas al
puesto destinatario.
8.1.2.2.2.Recomendación Si se considera que las condiciones de transfe-
rencia no son estándar, deberá comunicarse este hecho al
controlador de la transferencia para su confirmación o modifica-
ción.
8.1.2.3. Acciones en el puesto receptor8.1.2.3.1. Todos los mensajes ACT y REV deberán ser comprobados
mediante el filtro.
8.1.2.3.2. Si el resultado de la verificación indica que las condiciones de
transferencia recibidas no son estándar, deberán ser presentadas
al controlador para que éste tome una decisión; en caso contrario,
serán aceptadas automáticamente.
8.1.2.4. Sincronización de los filtros
8.1.2.4.1. La utilización de mensajes diferentes para las condiciones de
transferencia estándar y no estándar permite la identificación de
cualquier discrepancia entre las condiciones estándar contenidas
en los sistemas de los puestos transmisor y receptor.
8.1.2.4.2. La identificación en el puesto receptor de condiciones de transfe-
rencia no estándar en un mensaje utilizado para coordinar
solamente transferencias estándar indicará una discrepancia entre
los dos filtros. Dichas discrepancias deberían ser resueltas para
garantizar la eficacia del procedimiento de diálogo.
8.1.3. Secuencia de mensajes
8.1.3.1. General
8.1.3.1.1. Es necesario atenerse a ciertas normas, para asegurarse de que el
procedimiento de coordinación está finalizado antes de realizar
cualquier revisión o transferencia de mensaje de comunicación,
y para asegurarse también de que los controladores de ambos
puestos no realizan simultáneamente propuestas sobre los mismos
vuelos.
8.1.3.1.2. Un puesto ATC deberá transmitir o acusar recibo de un mensaje
de revisión (REV o RRV) solamente cuando el vuelo esté en2000R2082 — ES — 15.06.2002 — 001.001 — 40
▼B
estado de coordinación, p. ej. cuando se ha finalizado un diálogo
ACT o RAP con un LAM o ACP.
8.1.3.1.3. Sólo el puesto receptor podrá transmitir mensajes CDN
8.1.3.1.4. Los mensajes CDN solamente podrán ser transmitidos y ser
objeto de acuse de recibo:
— como parte de un diálogo iniciado por el receptor de un
mensaje de activación (ACT, RAP) o de revisión (REV o
RRV); o
— cuando el plan de vuelo para ese vuelo esté en estado de coor-
dinación.
8.1.4. Gestión simultánea de mensajes
8.1.4.1. General
8.1.4.1.1. Un puesto que participa en un intercambio de mensajes de coor-
dinación o de transferencia para un vuelo determinado no deberá
iniciar una coordinación posterior o un intercambio de mensaje de
transferencia para el mismo vuelo con el mismo puesto hasta que
no haya recibido un LAM, ACP o RJC, o haya alcanzado un
time-out (tiempo determinado).
8.1.4.1.2. Es posible que un mensaje CDN se cruce con mensajes REV,
RRV o MAC para el mismo vuelo enviados por el puesto de
transferencia. Esta situación puede identificarse en el puesto de
transferencia mediante la llegada del CDN antes del acuse de
recibo del mensaje de coordinación transmitido y en el puesto
receptor mediante la llegada del puesto de transferencia antes
del acuse de recibo del CDN. En este caso, no se dará acuse de
recibo del CDN y los mensajes REV, RRV o MAC no serán
procesados.
8.1.5. Tratamiento de los mensajes de rechazo
El mensaje RJC finaliza un dialogo del sistema. Habrá que iniciar
una nueva coordinación entre sistemas que refleje la coordinación
porteléfono, cuando sea aplicable.
8.1.6. Tiempo de respuesta operativo
8.1.6.1. General
8.1.6.1.1. Deberá aplicarse un mecanismo de tiempo de espera tanto en el
puesto emisor como en el receptor, para la contestación de los
mensajes que le son remitidos al controlador.
8.1.6.1.2. La duración de estos períodos de tiempo de espera deberá ser
acordada bilateralmente.
8.1.6.1.3. La finalización de este período de tiempo de espera en el puesto
de transferencia dará lugar a un aviso que se presentará al contro-
lador de la transferencia para indicar la necesidad de una
coordinación telefónica.
8.1.6.1.4.Recomendaciones
1.Un aviso debería visualizarse en el puesto receptor ATC, en la
unidad responsable del vuelo, cuando sea inminente la finali-
zación del tiempo de espera en el puesto de transferencia .
2.El aviso debería tener en cuenta el tiempo de transmisión de
la respuesta .
8.1.6.1.5. Los sistemas deberán ser capaces de procesar respuestas que se
reciban después de expirar el tiempo de espera.
8.1.7. Implantación
8.1.7.1. Los procedimientos de diálogo se realizan en dos fases, la fase de
coordinación y la fase de transferencia. El diálogo utiliza dife-
rentes mensajes en cada una de las fases y los tiempos de
transacción requeridos son diferentes. Los mensajes de coordina-
ción se especifican en formatos ICAO y ADEXP; la transferencia
de mensajes de comunicación sólo en ADEXP.
8.1.7.2. Los requisitos HMI mínimos necesarios para el diálogo de coor-
dinación son diferentes de los del diálogo de transferencia:
— el diálogo de transferencia se ocupa principalmente de la
función de control ejecutivo y necesita una HMI rápida y
fácil de usar;2000R2082 — ES — 15.06.2002 — 001.001 — 41
▼B
— en el diálogo de coordinación el tiempo no es tan primordial
y, por consiguiente, sus requisitos de HMI son menos rigu-
rosos.
8.1.7.3. El procedimiento de diálogo deberá ser implantado utilizando uno
de los siguientes marcos alternativos:
— procedimiento de diálogo para la fase de coordinación más
cualquier mensaje complementario, según se haya acordado
bilateralmente (Secciones 7 y 8);
— procedimiento de coordinación básica y procedimiento de
diálogo para la fase de transferencia (Secciones 6, 7 y 9);
— procedimiento de diálogo para las fases de coordinación y
transferencia más cualquier mensaje de coordinación comple-
mentario según se haya acordado bilateralmente (Secciones 7,
8 y 9).
El mensaje de información de límite de avance deberá ser
enviado en todos los casos.
8.1.7.4. El marco utilizado para la implantación deberá ser motivo de un
acuerdo bilateral.
8.2.Mensajedeactivación(ACT)
8.2.1. Objeto del mensaje ACT
El objeto del Mensaje ACT se describe en el párrafo 6.3.1. En un
procedimiento de diálogo, el mensaje ACT se utiliza para cumplir
estos requisitos en el supuesto de que las condiciones de transfe-
rencia del vuelo sean estándar y que el controlador de
transferencia no necesite enviar el vuelo al controlador receptor
para su aceptación.
8.2.2. Contenidos del mensaje
Los contenidos del mensaje ACT, utilizado en el procedimiento
de diálogo deberán ser los descritos en el párrafo 6.3.2 para el
mensaje ACT.
8.2.3. Normas de aplicación
8.2.3.1. General
8.2.3.1.1. Las normas de aplicación son las descritas en el párrafo 6.3 para
el mensaje ACT con la excepción de las normas especiales que se
describen en este párrafo.
8.2.3.1.2. Deberá enviarse un mensaje ACT para un vuelo con condiciones
de transferencia estándar cuando el controlador de transferencia
no necesite consultar al controlador receptor.
NOTA Si estos requisitos no se aplican, se enviará un RAP (ver
párrafo 8.3 Mensaje de referencia a Propuesta de Activa-
ción).
8.2.3.1.3.Recomendación Debería iniciarse un nuevo procedimiento de
coordinación si se envía un mensaje de rechazo de coordinación
(RJC) en respuesta a un mensaje ACT.
8.2.3.2. Procesamiento en el puesto receptor
8.2.3.2.1. El mensaje es comprobado mediante el filtro para confirmar que
las condiciones propuestas son estándar.
8.2.3.2.2. El mensaje deberá procesarse como un mensaje RAP si:
— las condiciones de transferencia no son estándar;
— no puede encontrarse un plan de vuelo en el sistema corres-
pondiente y no se dispone de suficiente información para
identificar si las condiciones de transferencia son estándar o
no.
8.2.3.2.3. Los mensajes ACT que se consideren estándar deberán ser proce-
sados de acuerdo con el párrafo 6.3.3.2.
8.2.3.2.4.Recomendación Si las condiciones de transferencia en un
mensaje ACT no son estándar, hay una discrepancia entre los
filtros en los dos sistemas. El hecho de que el ACT no sea
estándar debería llamar la atención del personal de supervisión
para que se resuelva la discrepancia.2000R2082 — ES — 15.06.2002 — 001.001 — 42
▼B
8.2.4. Acuse de recibo de mensaje ACT
8.2.4.1. Acuse de recibo
8.2.4.1.1. En un procedimiento de diálogo, el acuse de recibo de un
mensaje ACT se realizará mediante:
— un LAM, si las condiciones de transferencia son estándar;
— un mensaje SBY, en todos los demás casos.
8.2.4.1.2. Cuando se ha recibido un LAM, los contenidos operativos del
mensaje ACT pasarán a ser vinculantes para ambos puestos ATC.
8.2.4.1.3. Cuando se haya acordado bilateralmente, podrá utilizarse un
mensaje ACP en lugarde un LAM par a indicarla aceptación
por parte del puesto receptor de un ACT que contenga condi-
ciones de transferencia estándar.
8.2.4.2. Casos de ausencia de acuse de recibo
Si no se recibe el acuse de recibo para un mensaje ACT, deberá
visualizarse un aviso en el puesto ATC responsable de la coordi-
nación del vuelo.
8.3.Mensajedereferenciaapropuestadeactivación(RAP)
8.3.1. Objeto del mensaje RAP
El mensaje RAP cumple los siguientes requisitos operativos,
además de los especificados para el mensaje ACT en el párrafo
6.3:
— la propuesta por parte del controlador de transferencia y la
revisión al controlador receptor de vuelos con condiciones de
transferencia no estándar;
— permite al controlador de transferencia, si éste lo exige, forzar
la remisión al controlador receptor de condiciones de transfe-
rencia estándar para un vuelo determinado.
8.3.2. Contenidos del mensaje
Los contenidos del mensaje RAP deberán ser los mismos datos
que se indican en el párrafo 6.3 para el mensaje ACT y además
podrán incluir opcionalmente los siguientes datos:
— motivo, indicando remisión manual (solamente disponible en
ADEXP).
8.3.3. Normas de aplicación
8.3.3.1. General8.3.3.1.1. Deberá enviarse un mensaje RAP en lugar de un mensaje ACT
para los vuelos que crucen los límites y cumplan una de las
siguientes condiciones:
— el sistema de transferencia ha determinado que las condi-
ciones de transferencia no son estándar;
— el controlador de transferencia ha indicado que las condi-
ciones de transferencia propuestas deben ser remitidas con el
controlador receptor.
8.3.3.1.2. Los contenidos operativos del mensaje RAP que se va a trans-
mitir deberá ser visualizado en el puesto de trabajo responsable
de la coordinación del vuelo antes de la transmisión real.
8.3.3.1.3.Recomendación La hora a la que se transmite automáticamente
un mensaje RAP debería visualizarse junto con su contenido.
8.3.3.1.4. Deberá notificarse la transmisión de un mensaje RAP al puesto de
trabajo pertinente.
8.3.3.2. Procesamiento en el puesto receptor
8.3.3.2.1. El sistema ATC que recibe un mensaje RAP deberá intentar su
asociación con el plan de vuelo correspondiente.
8.3.3.2.2. Si se encuentra el plan de vuelo correspondiente y no existe
ninguna discrepancia con el mensaje que pudiera impedir su
correcto procesamiento:
— los contenidos operativos deberán remitirse al controlador
receptor;
— deberá enviarse un mensaje SBY en respuesta.2000R2082 — ES — 15.06.2002 — 001.001 — 43
▼B
8.3.3.2.3.Recomendación Debería incluirse una indicación del motivo de
la remisión (condiciones no estándar o remisión manual).
8.3.3.2.4. Si el mensaje no puede serasociado con un plan de vuelo, o se
encuentra una discrepancia que impida el procesamiento correcto
del mensaje, entonces:
— el contenido operativo del mensaje deberá visualizarse en el
sector;
y
— deberá enviarse un mensaje SBY en respuesta;
y
— deberá crearse un plan de vuelo.
8.3.3.2.5. En todos los demás casos, no se enviará acuse de recibo del
mensaje.
8.3.3.3. Inicio manual8.3.3.3.1. Cuando se utiliza para forzar la remisión, de una propuesta de
coordinación con condiciones de transferencia estándar al puesto
receptor, el RAP será iniciado manualmente por el controlador de
transferencia y transmitido inmediatamente.
8.3.3.3.2.Recomendación Debería permitirse, al puesto responsable de la
coordinación del vuelo, el inicio manual de un mensaje RAP
antes de la hora calculada de transmisión.
8.3.3.4. Parámetros de tiempo para transmisión automática
El tiempo o la distancia anterior al límite en el que los mensajes
RAP son transmitidos automáticamente deberá ser el mismo que
para los mensajes ACT.
8.3.4. Acuse de recibo de mensaje RAP
8.3.4.1. Acuse de recibo
El acuse de recibo del mensaje deberá realizarse mediante la
generación y transmisión de un mensaje SBY.
8.3.4.2. Caso de ausencia de acuse de recibo
Si no se recibe un mensaje SBY como acuse de recibo de un
mensaje RAP, deberá visualizarse un aviso en el puesto ATC
responsable de la coordinación del vuelo.
8.3.5. Respuesta operativa al mensaje RAP
El controlador receptor puede aceptar, proponer nuevamente o
rechazar las condiciones de transferencia.
8.3.5.1. Aceptación8.3.5.1.1. Cuando el controlador receptor elige aceptar las condiciones de
transferencia propuestas, deberá enviar un mensaje ACP.
8.3.5.1.2. Tan pronto como se reciba un mensaje ACP, los datos del
mensaje RAP pasan a ser operativamente vinculantes para los
dos puestos ATC. El controlador de transferencia deberá ser
informado de las condiciones de transferencia coordinada y del
hecho de que el ACP ha sido recibido.
8.3.5.2. Nueva propuesta
Cuando el controlador receptor elige realizar una nueva propuesta
en relación con las condiciones de transferencia, deberá enviar un
mensaje CDN.
8.3.5.3.Recomendación Cuando el controlador receptor elija rechazar
las condiciones de transferencia propuestas, debería enviar un
mensaje RJC. Debería iniciarse entonces un nuevo proceso de
coordinación.
NOTA Con respecto a la recomendación del apartado 8.3.5.3,
en la mayoría de los casos la nueva coordinación será
con un puesto diferente.
8.3.6. Ejemplos
8.3.6.1. ICAO
(RAPE/L022-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/
B757/M)2000R2082 — ES — 15.06.2002 — 001.001 — 44
▼B
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.Mensajederevisión(REV)
8.4.1. Objeto del mensaje REV
El objeto del mensaje REV se describe en el apartado 7.3.1. En
un procedimiento de diálogo, el mensaje REV se utiliza para
cumplir estos requisitos suponiendo que las condiciones de trans-
ferencia del vuelo son estándar y que el controlador de
transferencia no necesita remitir el vuelo al controlador receptor
para su aceptación.
8.4.2. Contenidos del mensaje
Los contenidos del mensaje REV deberán ser los descritos en el
apartado 7.3.2 para el mensaje REV.
8.4.3. Normas de aplicación
8.4.3.1. General
8.4.3.1.1. Pueden enviarse uno o varios mensajes REV al puesto al cual ha
sido actualmente coordinado el vuelo mediante la utilización de
un activación o RAP.
8.4.3.1.2. Los mensajes RAP deberán enviarse en las condiciones especifi-
cadas en el apartado 7.3.3.1 para vuelos con condiciones de
transferencia estándar y en los que el controlador de transferencia
no tenga que remitirse al controlador receptor.
8.4.3.2. Inicio de la transmisión
El mensaje REV deberá transmitirse inmediatamente a continua-
ción de la detección de un cambio en los datos de coordinación
que precisen ser coordinadas, según se describe en el apartado
7.3.3.
8.4.3.3. Procesamiento en el puesto receptor8.4.3.3.1. Si se encuentra un plan de vuelo correspondiente en estado de
coordinación y no se encuentra ninguna discrepancia que pudiera
impedir el correcto procesamiento del mensaje, entonces:
— deberá acusarse recibo del mensaje REV;
— en todos los demás casos, no deberá enviarse ningún acuse de
recibo.
8.4.3.3.2. Las condiciones de transferencia deberán ser examinadas para
asegurarse de que son estándar.
8.4.3.3.3. Si las condiciones de transferencia no son estándar deberán ser
presentadas al controlador receptor.
8.4.3.3.4. Si se considera que las condiciones de transferencia propuestas
son estándar, deberán incluirse en el plan de vuelo y deberán
enviarse los datos necesarios al ATC operativo y a otros puestos,
según sea necesario.
8.4.3.3.5.Recomendación Si se considera que las condiciones de transfe-
rencia en un mensaje REV no son estándar, hay una
discrepancia entre los filtros de los dos sistemas. El hecho de
que el mensaje REV no sea estándar debería atraer la atención
del personal de supervisión para que se resuelva la discrepancia.
8.4.4. Acuse de recibo de mensaje REV
8.4.4.1. Acuse de recibo8.4.4.1.1. El acuse de recibo del mensaje REV, en su caso, deberá reali-
zarse mediante:
— un mensaje LAM, si se estima que las condiciones de transfe-
rencia son estándar;
— un mensaje SBY, si se estima que las condiciones de transfe-
rencia no son estándar.
8.4.4.1.2. Cuando se ha recibido un LAM, los contenidos operativos del
mensaje REV pasan a ser operativamente vinculantes para ambos
puestos ATC.2000R2082 — ES — 15.06.2002 — 001.001 — 45
▼B
8.4.4.1.3. Si se ha acordado bilateralmente, puede utilizarse un mensaje
ACP en lugarde un mensaje LAM par a indicarla aceptación
por parte del puesto receptor de un REV conteniendo las condi-
ciones de transferencia estándar.
8.4.4.2. Casos de ausencia de acuse de recibo
Si no se recibe acuse de recibo del mensaje REV, deberá visuali-
zarse un aviso en el puesto ATC responsable de la coordinación
de los vuelos.
8.4.5. Respuesta operativa a mensaje REV
Dado que un mensaje REV se utiliza para enviar condiciones de
transferencia estándar, normalmente será aceptado por el sistemadel puesto receptor. Si el filtro del puesto receptor determina que
las condiciones de transferencia no son estándar, el mensaje
deberá procesarse como mensaje RRV.
8.5.Mensajedereferenciaapropuestaderevisión(RRV)
8.5.1. Objeto del mensaje RRV
El mensaje RRV deberá facilitar la revisión de las condiciones de
transferencia enviadas y acordadas previamente, en los siguientes
casos:
— cuando las condiciones de transferencia propuestas en la revi-
sión no sean estándar;
— cuando la revisión propuesta sea estándar, pero el controlador
de transferencia desee remitir la revisión al controlador
receptor.
8.5.2. Contenidos del mensaje
Los contenidos del mensaje RRV deberán ser los descritos en el
apartado 7.3.2 para el mensaje REV, y pueden incluir opcional-
mente los siguientes datos:
— motivo, indicando remisión manual (sólo disponible en
formato ADEXP).
8.5.3. Normas de aplicación
8.5.3.1. General
Deberán enviarse uno o varios mensajes RRV, en lugar de
mensajes REV, para cada revisión, si:
— el sistema de transferencia ha determinado que las condi-
ciones de transferencia no son estándar;
o
— el controlador de transferencia ha indicado que las condi-
ciones de transferencia propuestas van a ser remitidas al
controlador receptor. Esta utilización del RRV es opcional.
8.5.3.2. Inicio de transmisión
El mensaje RRV deberá ser transmitido inmediatamente después
de la detección de un cambio en los datos de coordinación o
cuando se inicie manualmente la coordinación.
8.5.3.3. Procesamiento en el puesto receptor8.5.3.3.1. Si se encuentra el plan de vuelo correspondiente en estado de
coordinación y no existe ninguna discrepancia que pudiera
impedir el correcto procesamiento del mensaje, entonces:
— deberá acusarse recibo del mensaje RRV;
— en todos los demás casos, no se enviará acuse de recibo.
8.5.3.3.2. Las condiciones de transferencia propuestas deberán visualizarse
en el puesto ATC responsable de la coordinación del vuelo.
8.5.3.3.3.Recomendación Debería incluirse una indicación del motivo de
la remisión (condiciones no estándar o presentación manual).
8.5.4. Acuse de recibo de mensaje RRV
8.5.4.1. Acuse de recibo
Se deberá enviar acuse de recibo del mensaje mediante la genera-
ción y transmisión de un mensaje SBY.2000R2082 — ES — 15.06.2002 — 001.001 — 46
▼B
8.5.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje SBY como acuse de recibo de un
mensaje RRV, deberá visualizarse un aviso en el puesto ATC
responsable de la coordinación del vuelo.
8.5.5. Respuesta operativa a mensaje RRV
El controlador receptor puede aceptar, proponer nuevamente o
rechazar un mensaje RRV.
8.5.5.1. Aceptación
Cuando el controlador receptor elige aceptar la propuesta de
corrección de las condiciones de transferencia acordadas, deberá
enviarun mensaje ACP.
8.5.5.2. Nueva propuesta
Cuando el controlador receptor elige realizar una nueva propuesta
de condiciones de transferencia, deberá enviar un mensaje CDN.
8.5.5.3. Rechazo
Cuando el controlador receptor elige rechazar la propuesta de
corrección de las condiciones de transferencia acordadas:
— deberá enviar un mensaje RJC en respuesta;
y
— deberá iniciar un nuevo proceso de coordinación.
Se supondrá el rechazo cuando no se reciba un mensaje ACP o
CDN en respuesta al mensaje RRV.
8.5.6. Ejemplos
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.Mensajedepuestaenespera(SBY)
8.6.1. Objeto del mensaje SBY
El mensaje SBY es el acuse de recibo de un mensaje con
propuesta de condiciones de transferencia e indica que la
propuesta está siendo remitida al controlador en espera de una
decisión.
8.6.2. Contenidos del mensaje
El mensaje SBY deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;— Referencia de mensaje.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
8.6.3. Normas de aplicación
8.6.3.1. General
El mensaje SBY deberá ser generado y transmitido automática e
inmediatamente en respuesta a:
— un mensaje RAP, RRV o CDN;
— un mensaje ACT o REV que no pase el filtro.
8.6.4. Acuse de recibo de mensaje SBY
No deberá acusarse recibo de un mensaje SBY.
8.6.5. Ejemplos
8.6.5.1. ICAO
(SBYL/E027E/L002)2000R2082 — ES — 15.06.2002 — 001.001 — 47
▼B
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.Mensajedeaceptación(ACP)
8.7.1. Objeto del mensaje ACP
El mensaje ACP satisface los siguientes requisitos operativos
durante las fases de coordinación y transferencia ATC:
— indica que un controlador de un puesto acepta manualmente
las condiciones de transferencia propuestas por el controlador
de otro puesto en uno de los siguientes mensajes:
— RAP;
— RRV;
— CDN;
— ACT y REV, si cualquiera de ellos no es estándar;
— si se acuerda bilateralmente, permite la aceptación automática
de un mensaje ACT o REV que ha superado con éxito el
filtro en el puesto receptor (en lugar de un mensaje LAM);
— si se acuerda bilateralmente, indica la aceptación manual de
un mensaje HOP (en lugarde un mensaje ROF).
8.7.2. Contenidos de mensaje
El mensaje ACP contiene los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;
— Referencia de mensaje;
— Datos opcionales — el mensaje también puede incluir:
— Frecuencia;
— Datos opcionales del formato ICAO — el mensaje también
puede contenerlos elementos siguientes:
— Identificación de aeronave;
— Aeródromo de salida;
— Aeródromo de destino.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
8.7.3. Normas de aplicación
8.7.3.1. General
8.7.3.1.1. La Referencia del mensaje ACP deberá incluir el número de
mensaje del mensaje al que responde.
8.7.3.1.2. El campo Frecuencia, cuando se incluya, deberá indicar la
frecuencia a la que debe contactar la aeronave con el puesto
receptor en el momento de la transferencia de control.
8.7.3.1.3. El mensaje ACP deberá enviarse a continuación de la aceptación
manual por parte del controlador de las condiciones de transfe-
rencia propuestas en un mensaje ACT, RAP, REV, RRV o CDN.
8.7.3.1.4. El mensaje ACP puede enviarse en respuesta a un mensaje HOP
como alternativa a un mensaje ROF.
8.7.3.1.5. Cuando se haya acordado bilateralmente, el mensaje ACP deberá
ser generado y transmitido automáticamente por el sistema en
respuesta a un mensaje ACT/REV que haya superado el filtro
con éxito.
8.7.3.1.6. Cuando se reciba un ACP, las condiciones de transferencia acor-
dadas pasarán a ser vinculantes para ambos puestos.
8.7.3.2. Procesamiento en el puesto receptor
8.7.3.2.1. El sistema ATC que recibe un mensaje ACP deberá intentar su
asociación con el plan de vuelo correspondiente.
8.7.3.2.2. Si el ACP puede serasociado con un plan de vuelo, la aceptación
deberá ser indicada al controlador.2000R2082 — ES — 15.06.2002 — 001.001 — 48
▼B
8.7.3.2.3. Si el ACP no puede serasociado con un plan de vuelo:
— deberá producirse un aviso en el puesto de trabajo adecuado;
y
— no deberá enviarse un LAM.
8.7.4. Acuse de recibo de mensaje ACP
8.7.4.1. Acuse de recibo8.7.4.1.1. No deberá enviarse un LAM no deberá ser enviado cuando el
ACP se utilice como respuesta automática a un mensaje ACT o
REV que haya superado con éxito el filtro.
8.7.4.1.2. Un mensaje ACP enviado a consecuencia de una aceptación
manual deberá ser objeto de un acuse de recibo mediante la gene-
ración y transmisión de un mensaje LAM.
8.7.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como indicación de acuse de
recibo de un mensaje ACP enviado a consecuencia de una acep-
tación manual, deberá visualizarse un aviso en el puesto de
trabajo ATC responsable de la coordinación del vuelo.
8.7.5. Ejemplos
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.Mensajedecoordinación(CDN)
8.8.1. Objeto del mensaje CDN
El mensaje CDN cumple los siguientes requisitos operativos:
— remitir una nueva propuesta del controlador receptor al
controlador de transferencia en respuesta a un mensaje ACT,
RAP, REV o RRV;
— Permite al controlador receptor remitir al controlador de trans-
ferencia una propuesta de modificación de las condiciones de
transferencia acordadas.
8.8.2. Contenidos del mensaje
El mensaje CDN contiene los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;
— Referencia de mensaje (sólo si es en respuesta a otro
mensaje);
— Identificación de la aeronave;— Aeródromo de salida;
— Aeródromo de destino;
NOTA El mensaje deberá contener también uno o los dos
elementos siguientes:
— Datos estimados (si es un mensaje ICAO) o Nivel de vuelo
de transferencia (si es un mensaje ADEXP);
— Solicitud de ruta directa.
— Datos acordados bilateralmente — También pueden incluirse
los siguientes datos:
— Frecuencia.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
8.8.3. Normas de aplicación
8.8.3.1. General8.8.3.1.1. Sólo el controlador receptor podrá iniciar mensajes CDN.2000R2082 — ES — 15.06.2002 — 001.001 — 49
▼B
8.8.3.1.2. Deberá utilizarse para transmitir una nueva propuesta del contro-
lador receptor al controlador de transferencia.
NOTA Puede ser tanto en un diálogo como en respuesta a una
propuesta enviada por un ACT, RAP, REV o RRV, o
como el inicio de un diálogo para corregir condiciones
de transferencia acordadas anteriormente.
8.8.3.1.3. La referencia de mensaje solamente deberá figurar cuando el
mensaje CDN se envíe como respuesta a otro mensaje.
8.8.3.1.4. La referencia de mensaje, cuando se incluya, deberá contener el
número de mensaje del mensaje al que responde el CDN.
8.8.3.1.5. El dispositivo de Solicitud de ruta directa (descrito con detalle en
el Anexo A) deberá:
— utilizarse solamente cuando se haya acordado de forma bila-
teral; y
— si se ha acordado, definir la utilización de cualquier límite
operativo.
8.8.3.1.6. El CDN no deberá enviarse después de un tiempo/distancia ante-
rior al límite especificado en la LoA entre lo puestos en cuestión.
8.8.3.1.7. En el caso de que se transmita un mensaje CDN simultáneamente
con un mensaje procedente del puesto de transferencia para el
mismo vuelo, p. ej. una revisión o una revocación de coordina-
ción, no se deberá enviar ni acuse de recibo ni respuesta
operativa.
NOTA Esto quiere decir que cuando dos mensaje se cruzan, el
procedente del puesto de transferencia tiene prioridad y
el CDN debe ser abandonado por ambas partes. Los dos
puestos pueden advertir esta situación por la recepcióndel mensaje del otro puesto previa a la recuperación del
acuse de recibo.
8.8.3.1.8. Tan pronto se haya recibido una aceptación, los datos del mensaje
CDN pasan a servinculantes par a ambos puestos ATC. El
personal ATC implicado deberá ser informado de las condiciones
de transferencia coordinada y del hecho de que el ACP ha sido
recibido.
8.8.3.2. Procesamiento en el puesto receptor
8.8.3.2.1. Si se encuentra el plan de vuelo correspondiente y no existe
ninguna discrepancia en el mensaje que pudiera impedir su
correcto procesamiento:
— el contenido operativo deberá ser presentado en el puesto de
trabajo ATC responsable de la coordinación del vuelo;
y
— deberá enviarse un mensaje SBY.
8.8.3.2.2. Si el CDN no puede serasociado o existe una discr epancia en el
mensaje que impida su correcto procesamiento, no deberá
enviarse ningún mensaje SBY.
8.8.4. Acuse de recibo de mensaje CDN
8.8.4.1. Acuse de recibo
En las condiciones especificadas anteriormente, el acuse de
recibo de un mensaje CDN deberá realizarse mediante la genera-
ción y transmisión de un mensaje SBY.
8.8.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje SBY como señal de acuse de recibo
para un mensaje CDN, deberá visualizarse un aviso en el puesto
de trabajo ATC responsable de la coordinación del vuelo.
8.8.5. Respuesta operativa a mensaje CDN
El controlador puede aceptar o rechazar las condiciones de trans-
ferencia propuestas en un mensaje CDN.
8.8.5.1. Aceptación
Cuando el controlador de transferencia elige aceptar las condi-
ciones de transferencia propuestas, deberá enviar en respuesta un
mensaje ACP.2000R2082 — ES — 15.06.2002 — 001.001 — 50
▼B
8.8.5.2.Recomendación Cuando el controlador de transferencia elige
rechazar las condiciones de transferencia propuestas, debería
enviar un mensaje RJC (rechazo explícito).
NOTA La coordinación propuesta es rechazada implícitamente
si no se ha recibido aceptación cuando finaliza el tiempo
de espera del CDN.
8.8.6. Ejemplos
8.8.6.1. ICAO
(CDNL/D041D/L025 -EIN636 -EIDW -LIFFY/1638F270F110A -
EBBR)
8.8.6.2. ADEXP
-TITLE CDN -REFDATA -SENDER -FAC L -RECVR -FAC D -
SEQNUM 041 -MSGREF -SENDER -FAC D -RECVR -FAC L -
SEQNUM 025 -ARCID EIN636 -ADEP EIDW -ADES EBBR -
PROPFL -TFL F270 -SFL F110A
8.9.Mensajederechazodecoordinación(RJC)
8.9.1. Objeto del mensaje RJC
El mensaje RJC indica el rechazo por parte de un controlador de
un puesto de transferencia de las condiciones de transferencia
propuestas por el controlador de otro puesto en uno de los
siguientes mensajes:
— RAP;
— RRV;— CDN;— ACT y REV, si se considera que cualquiera de los dos no es
estándar.
El mensaje puede utilizarse solamente como respuesta directa a
uno de los mensajes indicados anteriormente.
8.9.2. Contenidos del mensaje
El mensaje RJC deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;— Referencia de mensaje.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
8.9.3. Normas de aplicación
8.9.3.1. General8.9.3.1.1. El mensaje RJC deberá enviarse, según sea necesario, en
respuesta a un mensaje RAP, RRV o CDN o a un mensaje ACT
o REV que el puesto receptor considere no estándar.
8.9.3.1.2. El mensaje RJC pone fin al diálogo del sistema y cualquiercoor -
dinación acordada previamente permanece válida.
8.9.3.1.3.Recomendación Tras la recepción de un mensaje RJC debería
iniciarse una nueva secuencia de coordinación, teniendo en
cuenta la coordinación telefónica, cuando sea aplicable.
8.9.3.2. Procesamiento en el puesto receptor8.9.3.2.1. Si se encuentra un mensaje correspondiente al mensaje al que se
refiere el RJC:
— deberá indicarse el rechazo al puesto de trabajo ATC respon-
sable de la coordinación del vuelo; y
— deberá enviarse un LAM como acuse de recibo.
8.9.3.2.2. Si no se encuentra un mensaje de este tipo en espera de respuesta
o existe una discrepancia en el mensaje que impida su procesa-
miento, no deberá enviarse acuse de recibo.
8.9.4. Acuse de recibo de mensaje RJC
8.9.4.1. Acuse de recibo
El acuse de recibo de un mensaje RJC deberá realizarse mediante
la generación y transmisión de un mensaje LAM.2000R2082 — ES — 15.06.2002 — 001.001 — 51
▼B
8.9.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje RJC, deberá visualizarse un aviso en el puesto de trabajo
responsable de la coordinación de los vuelos.
8.9.5. Ejemplos
8.9.5.1. ICAO
(RJCMC/E746E/MC324)
8.9.5.2. ADEXP
-TITLE RJC -REFDATA -SENDER -FAC MC -RECVR -FAC E
-SEQNUM 746 -MSGREF -SENDER -FAC E -RECVR -FAC
MC -SEQNUM 324
9.PROCEDIMIENTO DE DIÁLOGO — TRANSFERENCIA
DECOMUNICACIÓN
9.1.General
9.1.1. Introducción
9.1.1.1. Esta sección de la Norma describe los dispositivos y mensajes
que apoyan el aspecto de transmisión por radar del procedimiento
de transferencia de control. Deberán ser aplicadas siempre que
hayan sido objeto de un acuerdo bilateral.
9.1.1.2. Los dispositivos de Transferencia de comunicaciones no deberán
serimplantados a menos que el puesto esté utilizando los dispo-
sitivos de coordinación descritos en la Sección 6 (Procedimiento
básico — Mensajes obligatorios) o los descritos en la Sección 8
(Procedimiento de diálogo — Coordinación).
9.1.1.3. Los mensajes descritos en esta sección del documento solamente
están disponibles en formato ADEXP y no está prevista su dispo-
nibilidad en formato ICAO.
9.1.2. Secuencia de mensaje
9.1.2.1. El intercambio de mensajes de Transferencia de comunicaciones,
aparte del Mensaje de datos complementarios (SDM), no se
llevará a cabo a menos que la coordinación se haya completado,
es decirque un mensaje LAM o ACP haya puesto fin a un
diálogo ACT o RAP.
9.1.2.2. No deberá enviarse ningún acuse de recibo mientras la coordina-
ción esté en curso.
9.1.3. Transferencia de comunicaciones
9.1.3.1. El método de denotarel cambio r eal de comunicaciones de
vuelos deberá ser acordado de forma bilateral entre los dos
puestos en cuestión.
9.1.3.2. Las condiciones deberán ser una o las dos siguientes:
— el puesto de transferencia envía un mensaje de cambio de
frecuencia (COF);
— El puesto receptor envía un mensaje de asunción manual de
comunicaciones (MAS);
9.1.3.3. El método deberá ser acordado entre los dos puestos de cada
corriente de tráfico.
NOTA Pueden utilizarse métodos alternativos para diferentes
corrientes de tráfico, p. ej. un puesto puede generar
mensajes COF para los vuelos que abandonan su espacio
aéreo y mensajes MAS para vuelos que entran en su
espacio aéreo. En este caso, no sería necesario para el
otro puesto entrar ningún mensaje para indicar la trans-
ferencia de comunicación.
9.2.Mensajedeiniciodetransferencia(TIM)
9.2.1. Objeto del mensaje TIM
El objeto del TIM es:
— indicar el inicio de la transferencia (TI) (el fin de la fase de
coordinación y el inicio de la fase de transferencia);2000R2082 — ES — 15.06.2002 — 001.001 — 52
▼B
— enviarsimultáneamente los datos de contr ol ejecutivo del
puesto de transferencia al puesto receptor.
9.2.2. Contenidos del mensaje
El mensaje TIM deberá contener los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;— Identificación de aeronave;
— Datos disponibles — el mensaje deberá contener también
cualquiera de los siguientes datos, si están disponibles:
— Nivel de vuelo autorizado;
— Rumbo asignado o autorización de ruta directa;— Velocidad asignada;— Velocidad de ascenso/descenso asignada;
— Datos opcionales — el mensaje también puede contener:
— Posición.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.2.3. Normas de aplicación
9.2.3.1. General9.2.3.1.1. El mensaje TIM deberá ser generado y transmitido por el puesto
de transferencia al puesto receptor sin intervención humana
cuando el vuelo esté a un tiempo/distancia del límite acordado
bilateralmente.
9.2.3.1.2. Un mensaje TIM también deberá enviarse automáticamente
cuando se reciba el mensaje de solicitud de frecuencia (ROF) en
el puesto de transferencia.
9.2.3.1.3. Un mensaje TIM no deberá enviarse antes de que el vuelo haya
sido coordinado.
9.2.3.1.4. El mensaje TIM deberá contener los datos más recientes disponi-
bles en el sistema.
9.2.3.2. Parámetros de tiempo para la transmisión
9.2.3.2.1. El parámetro de generación del TIM deberá ser un parámetro
variable del sistema y podrá cambiarse de acuerdo con las dispo-
siciones de las LoA.
9.2.3.2.2.Recomendación El parámetro de generación del mensaje TIM
del sistema debería definirse individualmente para cada COP.
9.2.3.2.3. Los interlocutores de la coordinación deberán incluir los paráme-
tros de generación del TIM en sus LoA.
9.2.3.2.4. El parámetro del sistema que inicia el mensaje TIM puede estar
relacionado con la velocidad calculada del avión respecto el
suelo. Sin embargo, el inicio del mensaje TIM deberá comenzar
siempre antes de que la posición de la aeronave, según el plan de
vuelo actual, esté más cerca del COP que una distancia mínima
acordada bilateralmente.
9.2.3.2.5. El parámetro del sistema especificado para la transmisión del
TIM permitirá un tiempo suficiente para realizar una coordina-ción verbal antes de la transferencia.
9.2.3.3. Procesamiento en el puesto receptor
9.2.3.3.1. Los datos recibidos en un mensaje TIM deberán ser comunicados
al controlador receptor.
9.2.4. Acuse de recibo de mensaje TIM
9.2.4.1. Acuse de recibo
Si el mensaje TIM:
— puede serasociado sin ambigüedad con un plan de vuelo,
deberá realizarse el acuse de recibo mediante la generación y
transmisión de un mensaje LAM;
— no puede serasociado sin ambigüedad con el plan de vuelo,
no deberá realizarse ningún acuse de recibo.2000R2082 — ES — 15.06.2002 — 001.001 — 53
▼B
9.2.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje TIM, deberá visualizarse un aviso en el puesto de trabajo
adecuado.
9.2.5. Ejemplo
-TITLE TIM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 029 -ARCID AMM253
9.3.Mensajededatoscomplementarios(SDM)
9.3.1. Objeto del mensaje SDM
9.3.1.1. General
9.3.1.1.1. El objeto principal de un mensaje SDM es transmitir datos de
control y cambios desde el puesto de transferencia hasta el puesto
receptor, en el supuesto de que se haya acordado bilateralmente
que el controlador receptor no necesite enviar acuse de recibo
para los cambios.
9.3.1.1.2. El mensaje SDM también puede serutilizado porel puesto
receptor para notificar al puesto de transferencia la frecuencia de
radio a la que va a transferirse el vuelo.
9.3.2. Contenidos del mensaje
9.3.2.1. Mensajes del puesto de transferencia
El mensaje SDM deberá contener los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;
— Identificación de aeronave;
— Datos complementarios — el mensaje deberá contener
también uno o varios de los siguientes elementos:
— Rumbo asignado o autorización de ruta directa;
— Velocidad asignada;
— Velocidad de ascenso/descenso asignada;
— Nivel de vuelo autorizado.
9.3.2.2. Mensajes del puesto receptor
El SDM deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;— Identificación de aeronave;
— Frecuencia.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.3.3. Normas de aplicación
9.3.3.1. Mensajes del puesto de transferencia9.3.3.1.1. Los mensajes SDM deberán ser transmitidos después del inicio de
la fase de transferencia (véase TIM, apartado 9.2) cuando se
produzca cualquier cambio en los siguientes elementos:
— Nivel de vuelo autorizado;
— Velocidad asignada;
— Velocidad de ascenso/descenso asignada;— Rumbo asignado; o
— Autorización o cambio de una autorización para que el vuelo
continúe directamente hacia el punto especificado.
NOTA Habrá que utilizar el mensaje HOP cuando se precise la
aprobación del controlador receptor antes de la transfe-
rencia de comunicación.
9.3.3.1.2. El mensaje deberá contener solamente los campos que hayan
cambiado.
9.3.3.1.3. Los mensajes SDM que contengan los datos descritos en el apar-
tado 9.3.3.1.1 deberán transmitirse antes del TI, si se ha acordado
bilateralmente.2000R2082 — ES — 15.06.2002 — 001.001 — 54
▼B
9.3.3.1.4. La transmisión de estos mensajes deberá comenzar a un tiempo
acordado bilateralmente con el TI, en el supuesto de que haya
datos para los que exista un valor disponible en el sistema.
9.3.3.2. Mensajes del puesto receptor
9.3.3.2.1. Los mensajes SDM podrán transmitirse para indicar la frecuencia
a la que el vuelo debe contactar al puesto receptor.
NOTA Los puestos podrán acordar bilateralmente el envío de
otra información. Dicha transferencia no está definida y,
por consiguiente, no forma parte de la presente Norma.
9.3.3.2.2. Los mensajes SDM del puesto receptor podrán transmitirse
durante la fase de coordinación, si se ha acordado bilateralmente.
9.3.3.3. Procesamiento en el puesto receptor9.3.3.3.1. El sistema ATC que recibe un mensaje SDM intentará asociarlo
con el plan de vuelo correspondiente.
9.3.3.3.2. Si se encuentra un plan de vuelo correspondiente en estado de
coordinación:
— deberá enviarse un LAM; y
— deberán comunicarse los contenidos operativos del mensaje
SDM al controlador adecuado.
9.3.3.3.3. Si no puede encontrarse un plan de vuelo correspondiente o existe
una discrepancia que impide el procesamiento correcto del
mensaje:
— no deberá enviarse un LAM; y
— deberá visualizarse un aviso en el puesto de trabajo adecuado.
9.3.4. Acuse de recibo de mensaje SDM
9.3.4.1. Acuse de recibo
El acuse de recibo del mensaje SDM deberá realizarse mediante
la generación y transmisión de un mensaje LAM.
9.3.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje SDM, deberá visualizarse un aviso en el puesto de
trabajo adecuado.
9.3.5. Ejemplo
-TITLE SDM -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 028 -ARCID AMM253 -AHEAD 290
9.4.Propuestadetransferencia(HOP)
9.4.1. Objeto del mensaje HOP
El objeto del mensaje HOP es:
— que el controlador de transferencia atraiga la atención del
controlador receptor sobre un vuelo determinado con fines de
transferir el control;
— que el controlador de transferencia proponga la transferencia
del vuelo al controlador receptor cuando se le requiera;
— transmitir las modificaciones a los datos de control ejecutivo
que precisen de la aprobación del controlador receptor, según
se haya acordado bilateralmente.
No es necesario utilizar el HOP para todos los vuelos; se utiliza a
discreción del controlador de transferencia.
NOTA Con respecto al párrafo c) anterior, el SDM se utiliza
para transmitir las modificaciones a los datos de control
ejecutivo que no precisan la aprobación del controlador
receptor.
9.4.2. Contenidos del mensaje
El mensaje HOP deberá contener los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;— Identificación de aeronave;2000R2082 — ES — 15.06.2002 — 001.001 — 55
▼B
— Datos disponibles — el mensaje también deberá contener
cualquiera de los siguientes datos, si están disponibles:
— Nivel de vuelo autorizado;
— Rumbo asignado/ruta directa autorizada;
— Velocidad asignada;
— Velocidad de ascenso/descenso asignada;
— Datos opcionales — El mensaje también puede contener:
— Posición.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.4.3. Normas de aplicación
9.4.3.1. General
9.4.3.1.1. El mensaje HOP, cuando se utilice, deberá iniciarse manualmente
por parte del controlador de transferencia.
9.4.3.1.2. El mensaje deberá incluir cualquier dato de vuelo descrito en el
apartado 9.4.2 que haya variado respecto del valor transmitido
previamente.
9.4.3.1.3. Si se envía un mensaje HOP antes de la TI, deberá iniciarse la
fase de Transferencia.
NOTA No es necesario añadir un mensaje de inicio de transfe-
rencia (TIM) a un mensaje HOP.
9.4.3.1.4. El momento calculado en tiempo o en distancia hasta el COP o el
límite a partir del cual puede enviarse un HOP deberá acordarse
bilateralmente.
9.4.3.1.5.Recomendación El tiempo/distancia debería especificarse de
forma individual para cada COP.
9.4.3.2. Procesamiento en el puesto receptor9.4.3.2.1. El sistema ATC que recibe un mensaje HOP deberá intentar su
asociación con el plan de vuelo correspondiente.
9.4.3.2.2. Los datos de vuelo recibidos en el mensaje deberán ser enviados
inmediatamente al controlador receptor.
9.4.3.2.3. Si el controlador receptor acepta el vuelo en las condiciones
propuestas en el HOP, podrá enviarse un ROF en respuesta al
puesto de transferencia. Si se ha acordado bilateralmente, podrá
enviarse un ACP en respuesta a un HOP.
9.4.3.2.4. Si el controlador receptor no puede aceptar el vuelo, la transfe-
rencia deberá ser acordada verbalmente.
NOTA Debido a la urgencia del procedimiento de transferencia,
la presente Norma no requiere un sistema de apoyo para
comprobar el envío de un ROF (o ACP); se supone que
el controlador de transferencia constatará la ausencia de
respuesta por parte del puesto receptor y tomará las
medidas necesarias. Sin embargo, la presente Norma no
impide que se envíe un aviso al controlador de transfe-
rencia si se considera necesario operativamente.
9.4.3.2.5. Tan pronto como se reciba un ROF (o un ACP), los datos del
mensaje HOP pasarán a ser vinculantes operativamente para
ambos puestos ATC.
9.4.4. Acuse de recibo de mensaje HOP
9.4.4.1. Acuse de recibo
Si puede serasociado con un plan de vuelo, se enviar á automáti-
camente un LAM como acuse de recibo del mensaje HOP.
9.4.4.2. Casos de ausencia de acuse de recibo
Si no se recibe mensaje LAM como acuse de recibo de un
mensaje HOP, deberá visualizarse un aviso en el puesto de
trabajo adecuado.
9.4.5. Ejemplo
-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253 -CFL F190 -ASPEED N0420 -
RATE D25 -DCT BEN STJ2000R2082 — ES — 15.06.2002 — 001.001 — 56
▼B
9.5.Mensajedesolicituddefrecuencia(ROF)
9.5.1. Objeto del mensaje ROF
El ROF es enviado por el puesto receptor al puesto de transfe-
rencia, cuando es necesario, y solicita al controlador de
transferencia que pida a la aeronave que cambie a la frecuencia
del controlador receptor. El mensaje puede ser utilizado:
— como respuesta a un HOP para manifestar la aceptación de un
vuelo en las condiciones propuestas;
— para solicitar la transferencia anticipada de un vuelo.
9.5.2. Contenidos del mensaje
El mensaje ROF deberá contener los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;— Identificación de aeronave;
— Datos opcionales — el mensaje también puede contener:
— Frecuencia.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.5.3. Normas de aplicación
9.5.3.1. General
9.5.3.1.1. El mensaje ROF deberá ser iniciado manualmente por el contro-
lador receptor.
9.5.3.1.2. El controlador receptor puede iniciar un ROF:
— cuando el controlador receptor solicite el paso anticipado de
la aeronave a su frecuencia;
— como respuesta a un mensaje HOP.
9.5.3.2. Procesamiento en el puesto receptor9.5.3.2.1. El sistema ATC que recibe un mensaje ROF deberá intentar su
asociación con el plan de vuelo correspondiente.
9.5.3.2.2. La recepción del ROF deberá ser comunicada al controlador de
transferencia sin demora.
9.5.3.2.3. Si el vuelo no está en la fase de Transferencia, se iniciará la fase
de Transferencia y se transmitirá un mensaje TIM.
9.5.4. Acuse de recibo de mensaje ROF
9.5.4.1. Acuse de recibo
9.5.4.1.1. Si el mensaje ROF puede asociarse sin ambigüedad con un plan
de vuelo, deberá realizarse el acuse de recibo mediante la genera-
ción y transmisión de un mensaje LAM.
9.5.4.1.2. Si el ROF no puede asociarse sin ambigüedad con un plan de
vuelo, no deberá realizarse acuse de recibo.
9.5.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
ROF, deberá visualizarse un aviso en el puesto de trabajo ATC
adecuado.
9.5.5. Ejemplo
-TITLE ROF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.6.Mensajedecambiodefrecuencia(COF)
9.6.1. Objeto del mensaje COF
9.6.1.1. General
9.6.1.1.1. El COF es enviado por el puesto de transferencia al puesto
receptor para indicar que el vuelo ha recibido instrucciones de
ponerse en contacto con el controlador receptor.
9.6.1.1.2. El mensaje puede incluir la posibilidad para el controlador de
transferencia de liberar al vuelo de las condiciones de transfe-2000R2082 — ES — 15.06.2002 — 001.001 — 57
▼B
rencia acordadas una vez se haya establecido comunicación con
el controlador receptor.
9.6.2. Contenidos del mensaje
El mensaje COF deberá contener los siguientes datos:
— Datos obligatorios — el mensaje deberá contener:
— Tipo de mensaje;
— Número de mensaje;— Identificación de aeronave;
— Datos disponibles — el mensaje también deberá contener
cualquiera de los siguientes elementos, si están disponibles:
— Indicación de transferencia;
— Frecuencia;— Nivel de vuelo autorizado;— Rumbo asignado o ruta directa autorizada;— Velocidad asignada;— Velocidad de ascenso/descenso asignada;
— Datos opcionales — el mensaje también puede contener:
— Posición.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.6.3. Normas de aplicación
9.6.3.1. General
9.6.3.1.1. El mensaje COF deberá ser iniciado manualmente por el contro-
lador de transferencia.
9.6.3.1.2. La utilización del mensaje COF es obligatoria, si por acuerdo
bilateral, no se utiliza el mensaje MAS.
9.6.3.1.3. Si se envía un mensaje COF antes de la TI, deberá iniciarse la
fase de transferencia.
NOTA No habrá que añadir un mensaje de inicio de transfe-
rencia (TIM) a un mensaje COF.
9.6.3.2. Procesamiento en el puesto receptor
9.6.3.2.1. El sistema ATC que recibe un mensaje COF deberá intentar su
asociación con el plan de vuelo correspondiente.
9.6.3.2.2. La recepción del COF deberá ser comunicada sin demora al
controlador receptor.
9.6.4. Acuse de recibo de mensaje COF
9.6.4.1. Acuse de recibo9.6.4.1.1. Si el mensaje COF puede serasociado sin ambigüedad con un
plan de vuelo, deberá realizarse un acuse de recibo mediante la
generación y transmisión de un mensaje LAM.
9.6.4.1.2. Si el mensaje COF no puede serasociado sin ambigüedad con un
plan de vuelo, no se enviará acuse de recibo.
9.6.4.2. Casos de ausencia de acuse de recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje COF, deberá visualizarse un aviso en el puesto de
trabajo ATC adecuado.
9.6.5. Ejemplos
-TITLE COF -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
9.7.Mensajedeasunciónmanualdecomunicaciones(MAS)
9.7.1. Objeto del mensaje MAS
El MAS es enviado por el puesto receptor al puesto de transfe-
rencia para indicar que ha sido establecido contacto de radio
bidireccional con el vuelo.2000R2082 — ES — 15.06.2002 — 001.001 — 58
▼B
9.7.2. Contenidos del Mensaje
El mensaje MAS deberá contener los siguientes datos:
— Tipo de mensaje;
— Número de mensaje;
— Identificación de aeronave.
NOTA Las normas de introducción de datos, los formatos y los
contenidos de campo se especifican en el Anexo A.
9.7.3. Normas de aplicación
9.7.3.1. General9.7.3.1.1. El mensaje MAS deberá ser iniciado manualmente por el contro-
lador receptor.
9.7.3.1.2. La utilización del mensaje MAS es obligatoria si, por acuerdo
bilateral, no se utiliza el mensaje COF.
9.7.3.2. Procesamiento en el puesto receptor9.7.3.2.1. El sistema ATC que recibe un mensaje MAS deberá intentar su
asociación con el plan de vuelo correspondiente.
9.7.3.2.2. El hecho de que se haya recibido el mensaje MAS será comuni-
cado inmediatamente al controlador.
9.7.4. Acuse de recibo de mensaje MAS
9.7.4.1. Acuse de recibo
9.7.4.1.1. Si el mensaje MAS puede serasociado sin ambigüedad con un
plan de vuelo, deberá realizarse un acuse de recibo mediante la
generación y transmisión de un mensaje LAM.
9.7.4.1.2. Si el mensaje MAS no puede serasociado sin ambigüedad con un
plan de vuelo, no se realizará acuse de recibo.
9.7.4.2. Casos de Ausencia de Acuse de Recibo
Si no se recibe un mensaje LAM como acuse de recibo de un
mensaje MAS, deberá visualizarse un aviso en el puesto de
trabajo ATC adecuado.
9.7.5. Ejemplo
-TITLE MAS -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM2532000R2082 — ES — 15.06.2002 — 001.001 — 59
▼B
ANEXO A (Normativo)
NORMASDEINTRODUCCIÓNDEDATOS
CONTENIDO
A.1. Objeto
A.2. Formatos genéricos de mensajeA.3. Tipo de mensaje
A.4. Número de mensaje
A.5. Referencia de mensajeA.6. Identificación de aeronave
A.7. Modo y código SSR
A.8. Aeródromo de salidaA.9. Datos estimados
A.10. Punto de coordinación
A.11. Aeródromo de destinoA.12. Número y tipo de aeronave
A.13. Ruta
A.14. Otros datos del plan de vueloA.15. Estado de la coordinación y motivo
A.16. Rumbo asignado (sólo ADEXP)
A.17. Velocidad asignada (sólo ADEXP)A.18. Velocidad de ascenso/descenso asignada (sólo ADEXP)
A.19. Autorización de ruta directa (sólo ADEXP)
A.20. Solicitud de ruta directaA.21. Posición (sólo ADEXP)
A.22. Indicación de transferencia (sólo ADEXP)
A.23. FrecuenciaA.24. Motivo (sólo ADEXP)
A.25. Nivel de vuelo autorizado (sólo ADEXP)
A.26. Nivel de vuelo de transferencia (sólo ADEXP)A.27. Hora estimada de despegue
A.28. Tipo de mensaje de referencia
A.29. Tipo de vuelo
A.30. Capacidad y estado de los equipos
A.1.Objeto
Este Anexo contiene las normas generales de introducción de datos
en los mensajes descritos en la presente Norma. Estas normas se
aplican a todos los mensajes excepto cuando en las Normas de apli-
cación para un mensaje determinado se indican específicamente
otras alternativas o excepciones a estas normas.
A.2.Formatosgenéricosdemensaje
A.2.1. Todos los mensajes descritos en las secciones siguientes pueden ser
transmitidos utilizando el formato ICAO:
6 Procedimiento básico — Mensajes obligatorios;
7 Procedimiento básico — Mensajes complementarios;
8 Procedimiento de diálogo — Coordinación.2000R2082 — ES — 15.06.2002 — 001.001 — 60
▼M1
▼B
▼B
A.2.2. Los formatos de campo de los mensajes ICAO están definidos en
los Procedimientos para los Servicios de navegación aérea —
Normas aéreas y de Control de tráfico aéreo (Documento 4444).
Los siguientes tipos de campo ICAO, cuando aparecen, deberán ser
transmitidos antes que cualquier otro tipo de campo y en el orden
siguiente: 3, 7, 13, 14 y 16. Como están en formato de campo tipo
22, el orden de los otros tipos de campo ICAO no es importante, a
excepción de que preceden a los tipos de campo mencionados ante-
riormente.
A.2.2.bis Cuando no exista un campo ICAO adecuado, se utilizará un seudo-
número de tipo de campo ICAO. Estos números incluyen valores de
dos cifras iguales o superiores a 80.
A.2.3. Todos los mensajes descritos en el presente documento pueden ser
transmitidos utilizando el formato Eurocontrol ADEXP. Los conte-
nidos, la estructura y la utilización de campos de datos ADEXP
deberán realizarse de acuerdo con la Referencia 2.
NOTAS
1.Solamente se enumeran en este Anexo los campos de datos
primarios ADEXP, excepto cuando los Campos secundarios
asociados necesitan algún comentario específico. La Norma
ADEXP enumera todos los Campos secundarios, tanto opcio-
nales como obligatorios, requeridos dentro de cada Campo
primario.
2.Los mensajes descritos en la Sección 9, Procedimiento de
diálogo — Transferencia de comunicación, se describen sola-
mente en formato ADEXP.
A.3.TipodeMensaje
El tipo de mensaje deberá ser la abreviatura del mensaje, según se
indica en la siguiente lista:
ABI: Información de paso de límite.
ACP: Aceptación.
ACT: Activación.
CDN: Coordinación.
COD: Asignación de código SSR.
COF: Cambio de frecuencia.
HOP: Propuesta de transferencia.
INF: Información.
LAM: Mensaje de acuse de recibo lógico.
MAC: Mensaje para anulación de coordinación.
MAS: Asunción manual de comunicaciones.
PAC: Activación preliminar.
RAP: Propuesta de activación consultada.
REV: Revisión.
RJC: Rechazo de coordinación.
ROF: Solicitud de frecuencia.
RRV: Propuesta de revisión consultada.
SBY: Preparación.
SDM: Mensaje de datos complementarios.
TIM: Mensaje de inicio de transferencia.
A.3.1. ICAO
Campo de Tipo 3, elemento (a).
A.3.2. ADEXP
Campo primario «title» .2000R2082 — ES — 15.06.2002 — 001.001 — 61
▼M1
▼B
▼B
A.4.Númerodemensaje
Los datos de número de mensaje incluyen los identificadores asig-
nados a los puestos de transferencia y receptor y el número de
orden del mensaje. El número de orden del mensaje varía secuen-
cialmente desde 001 hasta 000 (que representa a 1 000), después se
repite desde 001 para todos los mensajes enviados al mismo desti-
natario, con independencia del tipo de mensaje.
A.4.1. ICAO
Campo de Tipo 3, elemento (b).
A.4.2. ADEXP
Campo primario «refdata».El Campo secundario «fac», dentro de los campos secundarios
«sender» y «recvr», deberá contener los identificadores asignados a
los puestos ATC. La longitud de estos indicadores no será superiora
ocho caracteres.
El Campo secundario «seqnum» deberá contener el número de
orden.
A.5.Referenciademensaje
A.5.1. ICAO
Campo de tipo 3, elemento (c) (llamado «datos de referencia» en el
documento 4444 de la ICAO).
El contenido del elemento (c) deberá ser el del elemento (b) del
Campo tipo 3 del mensaje OLDI al que se refiere.
A.5.2. ADEXP
Campo primario «msgref».Los valores de los Campos secundarios «sender» , «recvr», y
«seqnum», dentro del Campo primario «msgref», deberán ser los
de los Campos secundarios dentro del Campo primario «refdata»
del mensaje OLDI al que se refieren.
A.6.Identificacióndeaeronave
A.6.1. ICAO
Campo de tipo 7, elemento (a).
A.6.2. ADEXP
Campo primario «arcid».
A.7.ModoyCódigoSSR
O bien:
1. si es conocido, el modo/código SSR en el que el puesto receptor
espera que responda la aeronave en el punto de control de trans-
ferencia;
o bien
2. una indicación de que el código SSR está siendo solicitado al
puesto receptor.
A.7.1. ICAO
Campo de tipo 7, elementos (b) y (c).Si no se ha asignado ningún código SSR o el modo/código es desco-
nocido, los elementos (b) y (c) deberán omitirse.
Cuando se solicite un código/modo SSR, los elementos b) y c)
deberán contener el valor «A9999».
A.7.2. ADEXP
Campo primario «ssrcode».2000R2082 — ES — 15.06.2002 — 001.001 — 62
▼B
Si no se ha asignado ningún código SSR válido o el modo/código es
desconocido, el campo deberá omitirse.
Cuando se solicite un código/modo SSR mediante un mensaje PAC,
el Campo primario «ssrcode» deberá contener el indicador «REQ».
A.8.Aeródromodesalida
A.8.1. ICAO
Campo de tipo 13, elemento (a).
A.8.2. ADEXP
Campo primario «adep».
A.9.Datosestimados
A.9.1. General
A.9.1.1. Los datos estimados deberán incluir el COP, la hora en el COP y el
nivel de transferencia.
A.9.1.2. El punto de coordinación deberá ser definido como un punto de
referencia conocido, mediante una distancia y un rumbo desde un
punto de referencia conocido o mediante su longitud y latitud.
A.9.1.3. El nivel autorizado (de transferencia) deberá corresponder a las
condiciones de transferencia propuestas.
A.9.1.4.Recomendación Para los vuelos en ascenso o descenso, los datos
estimados deberían contener también los datos de cruce comple-
mentarios y las condiciones de cruce.
A.9.1.5. Si se utilizan, los datos de cruce complementarios deberán contener
el nivel de vuelo complementario en el punto de transferencia de
control. Las condiciones de transferencia deberán ser:
— Letra «A»; — si el vuelo se situará en el nivel o por encima del
nivel en los datos de cruce complementarios; o
— Letra «B»; — si el vuelo se situará en el nivel o por debajo del
nivel en los datos de cruce complementarios.
A.9.2. ICAO
Campo del tipo 14.
A.9.3. ADEXP
Campo primario «coordata».El Campo secundario «ptid» dentro del Campo primario «coordata»
deberá contener:
— un punto de referencia conocido; o
— un rumbo y una distancia desde un punto de referencia cono-
cido, como queda definido en el Campo primario «REF» o
«GEO» del mismo mensaje.
A.10.Puntodecoordinación
A.10.1. General
A.10.1.1. El punto de coordinación mencionado por los puestos ATC de trans-
ferencia y receptor a los efectos de la transferencia de control en
cuestión.
A.10.1.2. El punto de coordinación deberá estar definido como un punto de
referencia conocido, mediante una distancia y un rumbo desde un
punto de referencia conocido, o mediante una latitud y una longitud.
A.10.2. ICAO
Campo 14, elemento (a).
A.10.3. ADEXP
Campo primario «cop» que contiene:
— un punto de referencia conocido; o2000R2082 — ES — 15.06.2002 — 001.001 — 63
▼B
— un rumbo y una distancia desde un punto de referencia cono-
cido, según queda definido en el Campo primario «REF» o
«GEO» del mismo mensaje.
A.11.AeródromodeDestino
A.11.1. ICAO
Campo 16, elemento (a).
A.11.2. ADEXP
Campo primario «ades».
A.12.Númeroytipodeaeronave
El número y tipo de aeronave deberá contener el tipo de aeronave.
El número de aeronave deberá incluirse cuando se trate de vuelos en
formación.
A.12.1. ICAO
Campo del tipo 9 en formato de campo tipo 22. El elemento c del
campo tipo 9 deberá contener la categoría de turbulencia de estela
correspondiente al tipo de aeronave o la letra «Z».
A.12.2. ADEXP
Campo primario «arctyp». Además, si hay más de una aeronave en
el vuelo, Campo primario «nbarc».
A.13.Ruta
Ambos formatos permiten la descripción de la ruta tal y como se
define para los mensajes ICAO, que imponen como primer elemento
la velocidad y el nivel de vuelo solicitado o la altitud. Después del
grupo de velocidad, los datos de la ruta incluirán como mínimo los
especificados en el párrafo siguiente. Pueden insertarse otros datos
adicionales relativos a la ruta después del elemento c), si está dispo-
nible. Véase también el Anexo B «Requisitos para el procesamiento
de rutas especiales» para obtener las normas de introducción de
datos de ruta.
A.13.1. Contenido
A.13.1.1. Vuelos procedentes vía un COP definido
— el elemento de la ruta anterior al COP (ruta ATS, identificador
SID, DCT o punto significativo);
— el COP;
— el elemento de la ruta posterior al COP (ruta ATS o punto signi-
ficativo).
A.13.1.2. Vuelos procedentes de una ruta ATS
— el punto a partir del cual continúa el vuelo en el segmento de
ruta directa;
— el elemento «DCT»;
— el punto hacia el cual el se dirige el vuelo en el segmento de
ruta directa.
A.13.2. Formato
A.13.2.1. ICAO
Campo del tipo 15, en formato de campo tipo 22.
A.13.2.2. ADEXP
Campo primario «route».
A.14. Este campo permite la posibilidad de incluir en determinados
mensajes datos del plan del vuelo que normalmente no figuran en
el proceso de coordinación ni se describen en ninguna otra parte2000R2082 — ES — 15.06.2002 — 001.001 — 64
▼M1
▼M1
del presente apéndice. Se permite la inclusión de los siguientes
elementos, como se indica en los tipos de campos 8 y 18 del anexo
2 del documento de referencia 1:
— Normas de vuelo
— Marcas de matriculación— Nombre del operador
— Motivo para un tratamiento especial por parte de los ATS
— Tipo— Características— Nombre de los aeródromos de salida, llegada y alternativos— Comentarios en lenguaje claro.
A.14.1. ICAO
Tipo de campo 8, elemento a) «Normas de vuelo» en formato de
tipo de campo 22.
Uno o varios de los siguientes elementos del tipo de campo 18 en el
formato del tipo de campo 22:
REG, OPR, STS, TYP, PER, DEP, DEST, ALTN, RALT, RMK.
A.14.2. ADEXP
Campos primarios: «fltrul», «depz», «destz», «opr», «per», «reg»,
«rmk», «altrnt1», «altrnt2», «sts» y «typz».
A.15.Estadodecoordinaciónymotivo
El estado de coordinación y motivo deberá incluir los siguientes
elementos:
— un indicador de tres letras confirmando el nuevo estado del plan
de vuelo en el sistema, que deberá ser uno de los siguientes:
— INI, cuando el plan de vuelo en el sistema esté en estado
inicial, es decir, que no se haya recibido ningún mensaje de
notificación;
— NTF, cuando el plan de vuelo en el sistema deba estaren un
estado de notificación;
— CRD, cuando el plan de vuelo en el sistema deba estaren
estado de coordinación, es decir, cuando se haya recibido el
ACT básico o completado el diálogo de coordinación inicial
con las condiciones acordadas.
— Un indicador de tres letras especificando el motivo del estado.
Deberá ser uno de los siguientes:
— TFL, si el motivo es un cambio en el nivel de transferencia;
— RTE, si el motivo es un cambio de ruta;
— HLD, para indicar que el vuelo está en espera durante un
período indeterminado y que será objeto de un mensaje
posterior;
— DLY, para indicar que se ha retrasado la salida;— CAN, si el motivo es una cancelación;— CSN, para un cambio en el indicativo de llamada;— OTH, porcualquierotr o motivo o si se desconoce el motivo.
A.15.1. ICAO
A.15.1.1. El estado de coordinación y motivo deberán estar en el formato del
campo tipo 18.
A.15.1.2. El estado de coordinación y motivo deberán incluir los siguientes
elementos como grupo de diez caracteres:
— STA seguido de una barra oblicua;
— el indicador para confirmar el nuevo estado de la notificación/
coordinación;
— el indicadorque especifica el motivo.
A.15.2. ADEXP
Campo primario «cstat».2000R2082 — ES — 15.06.2002 — 001.001 — 65
▼B
▼B
Los elementos auxiliares «coordstatusident» y «coordstatusreason»
deberán contener el nuevo estado y el motivo, respectivamente,
según se ha especificado anteriormente.
A.16.Rumboasignado (sólo ADEXP)
El Campo primario «ahead» deberá contener:
— el rumbo asignado a un vuelo, expresado en grados;
o
— si no se ha asignado rumbo, el indicador «ZZZ», por ejemplo,
cuando se utilice un mensaje SDM para indicar que el rumbo
asignado previamente ya no es aplicable.
A.17.Velocidadasignada (sólo ADEXP)
El Campo primario «aspeed» deberá contener:
— la velocidad asignada al vuelo, expresada en nudos, número de
mach o en kilómetros/hora;
o
— si no se ha asignado velocidad, el indicador«ZZZ», por
ejemplo, cuando se utilice un mensaje SDM para indicar que
una velocidad asignada previamente ya no es aplicable.
A.18.Velocidaddeascenso/descensoasignada (sólo ADEXP)
El Campo primario «rate» deberá contener:
— la velocidad de ascenso o descenso asignada al vuelo, expresada
en cientos de pies porminuto;
o
— si no se ha asignado la velocidad de ascenso/descenso, el indi-
cador «ZZZ» en la parte numérica del campo, por ejemplo,
cuando se utilice un mensaje SDM para indicar que una velo-
cidad de ascenso/descenso asignada previamente ya no es
aplicable.
A.19.Autorizaciónderutadirecta (sólo ADEXP)
Una ruta directa, no definida como ruta ATS, entre dos puntos. Los
puntos pueden ser definidos como puntos de referencia conocidos o
mediante una distancia y un rumbo desde un punto de referencia
conocido. Todos los designadores del punto final deberán ser acor-
dados bilateralmente, es decir, conocidos por ambos sistemas.
Campo primario «DCT», que contiene:
— el punto en el que la desviación ha comenzado o comenzará,
definido como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido, según se define en el Campo primario «REF» del
mismo mensaje;
o
— el valor«ZZZ», si el puesto tr ansmisorno necesita designar
el punto de desviación.
— el punto situado sobre la ruta inicial del plan de vuelo a la que
el vuelo ha sido o será autorizado, definido como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido, según se define en el Campo primario «REF» del
mismo mensaje.
A.20.Solicitudderutadirecta
Solicitud de una ruta directa, no definida como ruta ATS, entre dos
puntos. Los puntos pueden ser definidos como puntos de referencia
conocidos o mediante una distancia y un rumbo desde un punto de
referencia.
Todos los designadores del punto final utilizados deberán ser acor-
dados bilateralmente, es decir, conocidos por ambos sistemas.2000R2082 — ES — 15.06.2002 — 001.001 — 66
▼B
A.20.1. ICAO
Campo tipo 15, excluyendo el grupo velocidad/nivel inicial, en
formato de campo 22.
Deberá contener:
— el punto a partir del cual se solicita que comience el desvío,
definido como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido;
o
— el valor«ZZZ», si el puesto ATC r eceptoresta solicitando
una ruta directa.
— la abreviatura «DCT»,— seguido porel punto situado en la r uta inicial del plan de vuelo
al que la aeronave solicita autorización, definido como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido.
A.20.2. ADEXP
Campo primario «DCT», que contiene:
— el punto en el que se solicita que comience el desvío, definido
como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido, según se define en el Campo primario «REF» del
mismo mensaje;
o
— el valor «ZZZ», si el puesto ATC receptor recibe una soli-
citud de una ruta directa, pero no se conoce con exactitud
el punto en el que comenzará el desvío.
— el punto situado sobre la ruta del plan de vuelo inicial para el
que se solicita la autorización, definido como:
— un punto de referencia conocido;
o
— una distancia y un rumbo desde un punto de referencia cono-
cido, según se define en el Campo primario «REF» del
mismo mensaje.
A.21.Posición (sólo ADEXP)
A.21.1. General
A.21.1.1. La posición actual del vuelo expresada en coordenadas geográficas
o mediante un rumbo y una distancia desde un punto designado.
A.21.1.2. El Campo primario «ref» o «geo» deberá definir la posición hori-
zontal actual del avión. Los puntos utilizados para la indicación de
distancia o rumbo en el Campo primario «ref» deberán ser acor-
dados bilateralmente, es decir, conocidos por ambos sistemas. El
campo «position» deberá contener el Campo secundario «ptid» que
se refiere al punto de referencia o geográfico definido. Si deben
incluirse datos de tiempo, deberá utilizarse el Campo secundario
«to» (hhmm) o «sto» (hhmmss), según se acuerde de forma bila-
teral.
A.22.Indicacióndetransferencia (sólo ADEXP)
El Campo primario «release» deberá contener uno de los siguientes
elementos:
— C, si se trata de una transferencia para vuelo ascendente;
— D, si se trata de una transferencia para vuelo descendente;— T, si se trata de una transferencia para viraje;— F, si se trata de una transferencia para todas las situaciones.2000R2082 — ES — 15.06.2002 — 001.001 — 67
▼B
A.23.Frecuencia
A.23.1. ICAO
El campo tipo 18 deberá incluir los siguientes elementos en formato
del campo 22:
— FRQ, seguido de una barra oblicua;
— 6 dígitos que indican la frecuencia, expresada en MHz con tres
cifras decimales.
A.23.2. ADEXP
Campo primario «freq».
A.24.Motivo (sólo ADEXP)
El Campo primario «reason» , que contiene el valor«MANUAL»
para los mensajes enviados manualmente.
A.25.Niveldevueloautorizado (sólo ADEXP)
Campo primario «cfl».
A.26.Niveldevuelopropuestoparalatransferencia (sólo ADEXP)
Campo primario «propfl».
A.27.Horaestimadadedespegue
A.27.1. ICAO
Campo tipo 13, elemento (b).
A.27.2. ADEXP
Campo primario «etot».
A.28.Tipodemensajedereferencia
El campo contiene el tipo de mensaje que se especifica en el
punto A.1 de este Anexo.
A.28.1. ICAO
Campo tipo 18 en formato de campo tipo 22. El elemento indicador
deberá ser «MSG».
A.28.2. ADEXP
Campo primario «msgtyp».
A.29.Tipodevuelo
Este dato deberá corresponder al registrado en el plan de vuelo o en
datos equivalentes procedentes de otras fuentes. Si el tipo de vuelo
no figura en el plan de vuelo o se desconoce por cualquier otra
razón, deberá ponerse la letra «X».
A.29.1. ICAO
El tipo de vuelo se indicará con una única letra en el formato de
tipo de campo 22, utilizando el seudonúmero de tipo de campo 80.
A.29.2. ADEXP
Campo primario «flttyp».
A.30.Capacidadyestadodelosequipos
Este apartado indica la capacidad y estado de los equipos, lo que
constituye un requisito previo para volar en determinados espacios
aéreos o rutas, o tiene una incidencia significativa en la prestación
del servicio ATC. La presencia de una capacidad figura en el plan
de vuelo, pero puede resultar inexacta o haberse modificado durante2000R2082 — ES — 15.06.2002 — 001.001 — 68
▼M1
▼M1
dicho vuelo. El apartado «Capacidad y estado de los equipos» espe-
cifica la situación en ese momento.
Deberá incluirse el estado de los elementos siguientes:
— Capacidad RVSM
— Equipamiento RTF 8.33 kHz.
En los vuelos de Estado, deberá incluirse el estado de los elementos
siguientes, como se indica en el «Tipo de vuelo» del plan de vuelo,
con respecto a los cuales se desconoce si puede utilizarse el equipa-
miento RTF 8.33 kHz:
— Equipamiento UHF.
A.30.1. ICAO
Los datos deberán introducirse en el tipo de campo 22, utilizando el
seudonúmero de campo 81.
Para cada capacidad deberán introducirse dos elementos:
— La capacidad del equipo expresada con una única letra, como se
indica en el tipo de campo 10 «Equipos» del plan de vuelo
ICAO (véase el anexo 3 del documento de referencia 1), seguida
de
— un elemento separador — barra oblicua (/), seguida de— dos letras que indican el estado.
El estado se expresará mediante los siguientes indicadores, que se
aplican al vuelo:
a) EQ significa que el vuelo está equipado y que el equipo puede
utilizarse durante el vuelo.
b) NO significa que el vuelo no está equipado o que porcualquier
razón el equipo no puede utilizarse durante el vuelo.
c) UN significa que se desconoce si se reúnen las condiciones de
capacidad necesarias.
El primer grupo de capacidad deberá introducirse inmediatamente
después de la barra oblicua que sigue al número de campo. Los
grupos siguientes estarán separados mediante un espacio. El orden
de las capacidades de los equipos es irrelevante.
A.30.2. ADEXP
Campo primario «EQCST».2000R2082 — ES — 15.06.2002 — 001.001 — 69
▼B
ANEXO B (Normativo)
REQUISITOSDEPROCESAMIENTODERUTASESPECIALES
B.1.Introducción
B.1.1. General
B.1.1.1. El presente Anexo describe las normas y los requisitos para intro-
ducción de datos en los siguientes casos, siempre que estén
permitidos:
— rutas de vuelo con trayectoria directa, fuera de ruta, que cruzan
el límite a consecuencia de un segmento de ruta directa regis-
trado en el plan de vuelo;
— después de la transmisión de un mensaje ABI o ACT, redirec-
cionamiento de un vuelo vía:
— una ruta ATS diferente;
— una ruta directa para retornar a la ruta inicial en un punto
posterior.
B.1.1.2. Con respecto al redireccionamiento de vuelos (punto B.1.1.1), el
intercambio de datos descrito en este Anexo permite la modifica-
ción de la ruta de vuelo en los dos sistemas mediante la
utilización de mensajes de notificación y coordinación.
B.2.Aplicacióndemensajes
B.2.1. Normas básicas para rutas directas
B.2.1.1. Las condiciones para la utilización de OLDI para la coordinación
de vuelos en rutas directas deberá ser acordadas bilateralmente.
B.2.1.2. Los datos necesarios para la notificación y coordinación de vuelos
en rutas directas se encuentran en los puntos de coordinación (datos
estimados (formato ICAO) y datos de coordinación (formato
ADEXP)) y ruta en los mensajes aplicables.
B.2.2. Ruta directa registrada
Cuando la ruta indique que el vuelo cruzará el límite en una ruta
directa, el segmento de la ruta directa y el COP resultante estarán
incluidos en cualquiermensaje ABI. Este COP está incluido en el
mensaje ACT o RAP posterior.
Los datos del COP y de la ruta deberán estar en el formato descrito
en el punto B.3.2.
B.2.3. Redireccionamiento después de la transmisión de un ABIy antes de
la de un ACT
Deberá enviarse un nuevo mensaje ABI con los datos correspon-
dientes a la nueva ruta.
B.2.4. Redireccionamiento después de la transmisión de un ACT
B.2.4.1. Deberá utilizarse un mensaje REV para indicar redireccionamientos
después de la transmisión de un mensaje ACT hasta un tiempo
determinado antes del ETO en el COP previamente coordinado.
NOTA Un mensaje REV se utiliza únicamente cuando el puesto
receptor no cambia a consecuencia de la modificación. Si
cambiara, tendría que enviarse un mensaje MAC al puesto
receptor inicial o tendría que cancelarse verbalmente la
coordinación.
B.2.4.2. El mensaje deberá contener los siguientes datos:
— Punto de coordinación (COP previo, para referencia);
— Datos estimados;— Ruta.
B.2.4.3. Los mensajes en formato ICAO deberán contener los siguientes
campos:
3 Tipo y número de mensaje; referencia de mensaje si se ha
acordado bilateralmente;2000R2082 — ES — 15.06.2002 — 001.001 — 70
▼B
7 Identificación de aeronave. Los elementos b y c no deberán
incluirse a menos que se esté coordinando simultáneamente
una revisión del código SSR;
13 Aeródromo de salida;14 Solamente el elemento a, que contiene el COP previo, para
referencia;
16 Destino;22 El campo 14, que contiene los datos estimados para las nuevas
condiciones de cruce de límite, en formato del campo 22;
22 El campo 15, que contiene la nueva ruta, en formato del
campo 22.
B.2.4.4. Los mensajes en formato ADEXP deberán incluir, además del tipo
y número de mensaje, la identificación de aeronave, el aeródromo
de salida, el destino y, si se ha acordado bilateralmente, el número
de referencia del mensaje:
— el COP previo en el campo COP;
— las nuevas condiciones de coordinación en el campo Coordata;— la nueva ruta en el campo Route.
B.2.4.5. Las revisiones de ruta enviadas como parte del procedimiento de
diálogo deberán ser enviadas como mensajes RRV, a menos que
se haya acordado bilateralmente considerarlas revisiones estándar.
B.3.Contenidosdecampo
B.3.1. Rutas ATS
Para los vuelos que son redireccionados vía una ruta ATS alterna-
tiva, los campos relativos a los datos estimados y el de ruta estarán
en los formatos de los mensajes ABI y ACT.
B.3.2. Rutas directas
B.3.2.1. El punto de coordinación en los datos estimados deberá ser el punto
de cruce de límite expresado como un rumbo y distancia desde un
punto indicado. Dichos puntos serán acordados bilateralmente.
Cuando la distancia sea cero o un vuelo vaya a pasar a menos de
una distancia acordada bilateralmente del punto, sólo deberá
incluirse el identificador del punto.
B.3.2.2. Cuando se acuerde bilateralmente, el punto de coordinación para un
vuelo en una ruta directa podrá ser expresado en términos de latitud
y longitud.
B.3.2.3. La ruta deberá contener:
— el punto situado en la ruta inicial desde el cual la aeronave
seguirá una ruta directa; cuando un vuelo sigue una ruta directa
a partir de la «posición actual», el punto podrá expresarse en
términos de rumbo y distancia desde un punto indicado. Cuando
se haya acordado bilateralmente, el punto podrá ser expresado
en términos de latitud y longitud;
— la abreviatura «DCT»;— el punto hacia el que se dirige directamente la aeronave;
— el resto de la última ruta de vuelo (FRF), si es conocida por el
sistema emisor.
B.4.Ejemplos
B.4.1. Rutas directas
B.4.1.1. Mensajes ABI y ACT
B.4.1.1.1. El vuelo (identificación Jetset 253) va a cruzar el límite sobre una
ruta directa entre el punto A (PTA) y el punto C (PTC), tras lo cual
seguirá una ruta ATS UA134. El sistema determina un COP con
rumbo 350, distancia 22 NM del punto B (PTB).2000R2082 — ES — 15.06.2002 — 001.001 — 71
▼B
Se envía el siguiente mensaje 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. El mensaje ACT tiene el mismo formato que el mensaje ABI,
excepto en que la ruta de vuelo es opcional.
B.4.1.2. Mensaje REV
El vuelo HZT2051 fue previamente objeto del siguiente mensaje
ACT (o el equivalente ADEXP):
(ACTQW/FG455-HZT2051/A3347-HECA-WSS/1838F310-EHBK-
9/B737/M
2000R2082 — ES — 15.06.2002 — 001.001 — 72
▼B
El vuelo se dirige entonces en ruta directa al punto MYY desde 40
NM al oeste del punto RQA. El punto más próximo a la intersec-
ción del límite es el TDS a partir del cual la distancia al punto de
cruce real es de 26 NM con un rumbo de 240 grados. Se envía el
siguiente mensaje de revisión:
(REVQW/FG464-HZT2051-HECA-WSS-EHBK-14/TDS240026/
1842F310-15/N0458F310 RQA270040 DCT MYY)
El mensaje ADEXP equivalente es:
-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
Un mensaje de revisión posterior indicaría TDS240026 como el
COP.2000R2082 — ES — 15.06.2002 — 001.001 — 73
▼B
B.4.2. Redireccionamiento vía rutas ATS después de la transmisión del
ACT
B.4.2.1. Mensaje ACT
El vuelo GKP217 está diseñado para pasar por el punto de coordi-
nación EMT. Se transmite el siguiente mensaje ACT:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/
FK28/M)
El vuelo se redirecciona posteriormente vía la ruta ATS UM247 al
interior del espacio aéreo del puesto emisor hacia el nuevo punto de
coordinación XAT, después debe seguir la ruta ATS UJ124. El
puesto receptor no cambia. Se envía el siguiente mensaje de revi-
sión:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/
N0430F290 UM247 XAT UJ124)
2000R2082 — ES — 15.06.2002 — 001.001 — 74
▼B
A continuación, se autoriza al vuelo para dirigirse a FL290, lo que
da lugaral siguiente mensaje (que contiene el nuevo COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
B.4.2.2. Equivalentes ADEXP
Los ADEXP equivalentes a los dos mensajes de revisión son los
siguientes:
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 — ES — 15.06.2002 — 001.001 — 75
▼B
ANEXO C (Informativo)
FASES DEL PROCEDIMIENTO DE DIÁLOGO (SYSCO NIVEL 1) — SECUENCIA DE
MENSAJES
Secuenciademensajes
2000R2082 — ES — 15.06.2002 — 001.001 — 76
▼B
ANEXO II
PRESENTACIÓNDELINTERCAMBIODEDATOSDESERVICIOSDE
TRÁFICOAÉREO(ADEXP),EDICIÓN2.0
(DocumentodereferenciadeEurocontrolDPS.ET1.ST09-STD)2000R2082 — ES — 15.06.2002 — 001.001 — 77
▼B
ÍNDICE
DERECHO DE AUTOR
PRÓLOGO1. CAMPO DE APLICACIÓN2. REFERENCIAS3. DEFINICIONES, SIMBOLOS Y ABREVIATURAS
3.1. Notación3.2. Definiciones3.3. Construcción3.4. Convenciones3.5. Operadores3.6. Abreviaturas
4. PRINCIPIOS ADEXP
4.1. Formato de texto de lectura directa4.2. Campos identificados y recuperables4.3. Campos no reconocidos
5. REGLAS SINTÁCTICAS ADEXP
5.1. Elementos de léxico5.2. Campos
6. DESCRIPCIÓN NORMALIZADA DE LOS MENSAJES ADEXP
6.1. Introducción6.2. Términos auxiliares6.3. Definición de los campos primarios6.4. Definición de los subcampos6.5. Grupo de mensajes
ANEXO A (NORMATIVO) DEFINICIONES DE CAMPOS ADEXP
ANEXO B (NORMATIVO) ÍNDICE CENTRAL DE TÍTULOS DE MENSAJE ADEXPANEXO C (NORMATIVO) ÍNDICE CENTRAL DE TÍTULOS DE MENSAJE RESERVADOSANEXO D (NORMATIVO) ÍNDICE CENTRAL DE CAMPOS RESERVADOSANEXO E (INFORMATIVO) INTRODUCCIÓN DE GRUPOS DE MENSAJESANEXO F (INFORMATIVO) EJEMPLOS DE FORMATO DE MENSAJES ADEXPANEXO G (INFORMATIVO) FUTUROS DESARROLLOS2000R2082 — ES — 15.06.2002 — 001.001 — 78
▼B
DERECHOSDEAUTOR
El presente documento ha sido elaborado por Eurocontrol.
Los derechos de autor pertenecen a Eurocontrol.Si bien el contenido a cualquier parte del mismo está libremente a disposi-
ción de los representantes de los Estados miembros, su copia o divulgación
a un tercero estará sujeta a la autorización previa por escrito de Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 79
▼B
PRÓLOGO
1.Órganoresponsable
La presente Norma ha sido desarrollada y está mantenida por la
Sección de requisitos del usuario (URS) de la Unidad Central de
Gestión de Tráfico (CFMU) de la Organización Europea para la
Seguridad de la Navegación Aérea (Eurocontrol).
2.ProgramadetrabajoEATCHIP
La presente Norma es el resultado del Programa de trabajo
EATCHIP (EWPD), Dominio de sistemas de procesamiento de
datos, Tarea ejecutiva 09.
3.AprobacióndelaNorma
3.1. La presente Norma ha sido adoptada de conformidad con los
procedimientos descritos en las Directivas de Normalización de
Eurocontrol, Ref. 000-2-93, Edición 1.0.
3.2. Las disposiciones de la presente Norma son efectivas después de
la adopción de la edición 1.0 porla Comisión Per manente de
Eurocontrol en 1995 y su fecha de aplicación es a partir del 1o
de Diciembre de 1997.
4.Rectificacionestécnicasyenmiendas
La presente Norma está sujeta a revisión para determinar las posi-
bles modificaciones y rectificaciones técnicas necesarias. El
procedimiento de mantenimiento de la presente Norma se
describe en el Anexo H de las Directivas para la presentación y
redacción uniforme de las Normas Eurocontrol.
Las enmiendas o adiciones que afecten a los principios básicos o
la gramática del formato ADEXP se realizarán exclusivamente
según el procedimiento de revisión formal previsto en las Direc-
tivas para la presentación y redacción uniforme de las Normas
Eurocontrol.
Las modificaciones o adiciones a la presente Norma serán
propuestas por escrito a la CFMU, Sección de requisitos de usua-
rios (ADEXP), Eurocontrol.
5.Convencioneseditoriales
5.1. El formato de la presente Norma cumple con las Directivas para
la presentación y redacción uniforme de las Normas Eurocontrol,
si bien existen algunas excepciones a la misma. Estas pequeñas
desviaciones de formato de las Directivas se permiten para evitar
confusiones con la notación para la presentación de intercambio
de datos ATS (ADEXP).
5.2. Para indicar el estado de cada elemento se ha utilizado la
siguiente notación:
— Los Elementos normativos se caracterizan por la forma verbal
en futuro «deberá» y se encuentran impresos en caracteres
ordinarios.
— Los Elementos recomendados se caracterizan por la forma
verbal en condicional «debería», han sido impresos en cursiva
y van precedidas por la palabra Recomendación .
6.Relaciónconotrosdocumentosnormativos
La presente Norma está relacionada con:La Norma Eurocontrol para el Intercambio de datos en línea
(OLDI).
7.EstadodelosAnexosalapresenteNorma
Esta Directiva tiene 6 Anexos, cuyo estado se detalla a continua-
ción:
Anexo A Normativo;
Anexo B Normativo;Anexo C Normativo;Anexo D Normativo;2000R2082 — ES — 15.06.2002 — 001.001 — 80
▼B
Anexo E Informativo;
Anexo F Informativo;Anexo G Informativo.
8.Idiomautilizado
El texto original de la presente Norma ha sido redactado en
lengua inglesa.2000R2082 — ES — 15.06.2002 — 001.001 — 81
▼B
1.CAMPODEAPLICACIÓN
1.1. ADEXP es un formato, no un protocolo. No se impone ninguna
restricción en los soportes de transmisión ni en los protocolos
que se utilicen, a excepción de la restricción del conjunto de
caracteres.
1.2. El formato ADEXP se utiliza principalmente para intercambio de
mensajes en línea de ordenador a ordenador.
1.3. Este documento define los principios y las reglas sintácticas del
formato ADEXP en términos de una definición completa de los
campos ADEXP.
1.4. El formato ADEXP ha sido especificado para su empleo en las
siguientes áreas del intercambio de mensajes (si desea informa-
ción sobre los documentos de referencia, consulte la Sección 2,
página 3):
— Planificación de vuelos: intercambio de datos del plan de
vuelo y mensajes asociados entre el Sistema Integrado de
Tratamiento Inicial de Planes de Vuelo (IFPS), los Servicios
de Tráfico Aéreo (ATS) y Operadores de Aeronaves (AO).
(Documento Ref. 3)
— Gestión del Flujo de Tráfico Aéreo (ATFM): intercambio de
mensajes entre el Sistema Táctico (TACT) de la CFMU, los
AO y los ATS. (Documento Ref. 5)
— Coordinación del Control de Tráfico Aéreo: intercambio de
mensajes de coordinación táctica entre las Unidades de
Control de Tráfico Aéreo (ATCU). (Documento Ref. 6)
— Gestión del Espacio Aéreo: intercambio de datos entre las
unidades nacionales de ATS, la CFMU y los AO, en relación
con la disponibilidad de espacio aéreo. (Documento Ref. 7)
— Coordinación Civil / Militar: mensajes en relación con los
datos de vuelo civil/military mensajes que cr ucen el espacio
aéreo. (Documento Ref. 7)
1.5. Las especificaciones detalladas en relación con la utilización y al
contenido de los mensajes dentro de cada uno de los anteriores
grupos se encuentran en los documentos de referencia.
2.REFERENCIAS
2.1. Los siguientes documentos y normas contienen las disposiciones
que, mediante la referencia en este texto, constituyen las disposi-
ciones de la presente Norma Eurocontrol.
En la fecha de publicación de la presente Norma Eurocontrol las
ediciones indicadas para los documentos y normas de referencia
eran válidas.
Cualquier revisión de los documentos de la Organización de
Aviación Civil Internacional (ICAO) se considerarán de inme-
diato para revisar la presente Norma Eurocontrol.
Las revisiones de otros documentos citados en las referencias no
deberán formar parte de las disposiciones de la presente Norma
Eurocontrol hasta que no sean revisadas e incorporadas formal-
mente a la presente Norma Eurocontrol.
En caso de conflicto entre los requisitos de la presente Norma
Eurocontrol y el contenido del resto de documentos incluidos en
las referencias, prevalecerá la presente Norma Eurocontrol.
2.2. En la fecha de su publicación, los documentos enumerados a
continuación son los incluidos en las referencias de la presente
Norma, pero se invita a los usuarios comprobar la utilización y
las tablas de composición de los campos de mensaje en las
últimas ediciones de dichos documentos.
1. Anexo 10 a la Convención de Chicago de la ICAO Volumen I,
edición de noviembre de 1985;
2. Anexo 10 a la Convención de Chicago de la ICAO Volumen
II, edición de julio de 1995;
3. Diccionario de mensajes IFPS y RPL, edición 1.0, marzo de
1998;
4. «Reglas del aire y servicios del tráfico aéreo», PANS-RAC
Doc. 4444, edición de noviembre de 1985 (incluyendo la
Modificación no6 de noviembre de 1995);2000R2082 — ES — 15.06.2002 — 001.001 — 82
▼B
5. Guía para el intercambio de mensajes ATFM, Documento
Eurocontrol Ref. TACT/USD/MSGGUID, edición 6.0, en
vigor a partir de marzo de 1998,
6. Norma Eurocontrol para el Intercambio de datos en línea,
edición 2.0, octubre 1996.
7. Especificaciones de funcionamiento para el apoyo de sistemas
a la distribución de datos en el espacio aéreo y coordinación
civil, edición 1.0, mayo de 1996.
3.DEFINICIONES,SIMBOLOSYABREVIATURAS
3.1.Notación
La notación utilizada para definir la sintaxis se denomina Backus
Naur Form (BNF). BNF define un conjunto de reglas que deter-
minan una categoría de cadenas de caracteres. En este caso, la
categoría de la cadena de caracteres es el conjunto de mensajes
que puede serdenominado un mensaje ADEXP sintácticamente
correcto.
3.2.Definiciones
A los efectos de la presente Norma Eurocontrol, deberán apli-
carse las siguientes definiciones:
Entidad : Carácter o conjunto de caracteres que puede ser
«extraído» por un analizador de léxico debido a la presencia de
separadores.
Símbolo : Cualquier «término» que aparece en una regla BNF y no
es un carácter.
Símbolo terminal : Símbolo representado en forma de secuencia
de caracteres.
Símbolo no terminal : Símbolo representado con uno o más
símbolos terminales.
NOTA Un símbolo no terminal puede representarse también con
una combinación de símbolos terminales y no terminales.
3.3.Construcción
3.3.1. La BNF se compone de un conjunto de reglas o construcciones
de la forma:
símbolo::= expresión
NOTAS1)La notación «::=» se debe leer como «puede ser reemplazado
por».
2)El elemento «símbolo» está clasificado como no terminal.
3)El elemento «expresión» contiene símbolos terminales y no
terminales.
3.3.2. Los símbolos terminales tienen una representación directa como
secuencia de caracteres que puede ser identificada como una
entidad porun analizadorde léxico debido a la pr esencia de sepa-
radores.
3.4.Convenciones
A los efectos de la presente Norma Eurocontrol, deberán apli-
carse las siguientes convenciones:
— Los símbolos Terminal están en letras mayúsculas.
NOTA Por convención, el símbolo terminal NIL significa
«ningún símbolo terminal» .
Se utiliza en elecciones como las del siguiente
ejemplo:
a::= b ( c | NIL ) donde a puede ser reemplazada por
(b seguida de c) o solamente por b.
— Los símbolos No terminales (porejemplo el lado der echo de
una producción gramatical) figuran en letras minúsculas.2000R2082 — ES — 15.06.2002 — 001.001 — 83
▼B
— Los Caracteres y Cadenas literales que aparecen dentro de
las reglas aparecen entre apóstrofos (') o comillas ("), respec-
tivamente.
Ejemplos
1) HYPHEN::= '-'
2) title::= '-' "TITLE" titleid
Puede ser necesario, para ciertas aplicaciones de modelización de
datos, distinguir entre símbolos terminales y no terminales utili-
zando diferentes combinaciones de mayúsculas o minúsculas.
Siempre que sea necesario distinguir explícitamente entre
símbolos terminales y no terminales sin utilizar diferentes combi-
naciones de letras mayúsculas o minúsculas, se recomienda la
adición de un sufijo según se indica a continuación: «_at» para
un Término auxiliar, «_pf» para un Campo primario y «_sf»
para un Subcampo.
3.5.Operadores
A los efectos de la presente Norma Eurocontrol, deberán apli-
carse los siguientes operadores:
Opcional: Cuando algunos símbolos pueden aparecer o no en la
sintaxis en algún punto de la gramática. Los símbolos opcionales
aparecen entre los corchetes «[» y «]».
Cierre: Cuando un grupo de símbolos puede aparecer ninguna o
más veces. Los símbolos aparecen entre las llaves «{» y «}».
Cuando se especifique un número delante de «{», indicará el
número mínimo de veces que puede aparecer el grupo de
símbolos. Cuando se especifique un número después de «}»,
indicará el número máximo de veces que puede aparecer el grupo
de símbolos.
Elección: Cuando un número de símbolos alternativos puedan
aparecer en algún punto de la gramática. La elección se repre-
senta mediante un trazo vertical «|».
Concatenación: Representación de símbolos ordenados secuen-
cialmente, independientemente de la presencia o no de
separadores. No existe una representación explícita de este hecho.
Existen dos tipos de concatenación:
—Concatenación estricta : a nivel de léxico, ciertas reglas
pueden requerir la concatenación de símbolos terminales indi-
cando que se suceden de forma estricta (sin separadores
intermedios); en este caso se utilizará el signo de cierre de
admiración «!»
Ejemplo datetime:: = date ! timehhmm
es decir, "9912251200" que significa 25 de diciembre de
1999, a las 12:00.
—Concatenación suelta: se permite la presencia de separadores
entre símbolos terminales. La representación de una concate-
nación suelta dentro de una regla puede ser Implícita o
Explícita.
Ejemplos
1) Implícita:
dct::= '-' "DCT" point point
2) Explícita
dct::= '-'!{SEP}!"DCT"!1{SEP}!point!1{SEP}!point
es decir, "-DCT NTM RMS".
NOTAS
1)La concatenación tiene siempre prioridad sobre la elección.
Se utilizan los paréntesis «(» y «)» para modificar el orden
de evaluación de la expresión.
Ejemplo a::= B C | D es equiva-
lente a:a::= (B C) | D2000R2082 — ES — 15.06.2002 — 001.001 — 84
▼B
yN Oe s
equivalente a:a::= B (C | D).
2)En todas las reglas, la presencia permitida de separadores
entre los símbolos quedará implícita con el fin de mantener
su legibilidad .
Recomendación Cuando exista riesgo de confusión debido a la
prioridad entre los operadores mencionados anteriormente, se
recomienda la utilización de paréntesis para clarificar el orden
de evaluación deseado.
3.6.Abreviaturas
A los efectos de la presente Norma Eurocontrol, se deberán
aplicar las siguientes siglas y abreviaturas:
ACH Mensaje de modificación del plan de vuelo
ATC
ADEG Grupo de intercambio de datos ATSADEXP Presentación de intercambio de datos ATSAFIL Plan de vuelo registrado en el aireAFP Propuesta de plan de vuelo ATCAFTN Red fija de telecomunicaciones aeronáu-
ticas
ANM Mensaje de notificación ATFMAO Operador(es) de aeronavesAPL Plan de vuelo ATCATC Control del tráfico aéreoATCU Unidad(es) de control del tráfico aéreoATFM Gestión del flujo del tráfico aéreo
ATS Servicios de tráfico aéreo
BNF Backus NaurFor mCASA Asignación de ranura asistida por orde-
nador
CIDIN Red común de intercambio de datos de la
ICAO
CFL Nivel de vuelo autorizado
CFMU Unidad central de gestión de flujo de
tráfico aéreo
CMTP Plan común a medio plazoCNL Mensaje de cancelaciónCTOT Hora calculada de despegue
DPS Dominio del sistema de procesamiento de
datos
ECAC Conferencia europea de aviación civil
EFL Nivel estimado de vuelo
EOBT Hora estimada de salida del área de esta-
cionamiento
ESTO Hora estimada de paso por la verticalEUROCONTROL Organización europea para la seguridad de
la navegación aérea
EWPD Documento del programa de trabajo
EATCHIP
FIR Región de información de vuelo
FIW Estación de entrada del trabajo del plan de
vuelo
FMP Puesto de gestión del flujo del tráfico aéreo
FNM Mensaje de notificación de vueloFPL Mensaje del plan de vuelo (formato ICAO)
GAT Tráfico aéreo generalIA Alfabeto internacional
IAFP Propuesta de plan de vuelo individual ATC
ICAO Organización de aviación civil interna-
cional2000R2082 — ES — 15.06.2002 — 001.001 — 85
▼B
IFPD Datos del plan de vuelo individual
IFPS Sistema integrado de procesamiento inicial
de planes de vuelo
IFPU Unidad IFPS
IFR Reglas de vuelo instrumental
ISO Organización internacional de normaliza-
ción
ITA Alfabeto telegráfico internacional
LAM Mensaje de identificación lógico
LRM Mensaje de rechazo lógico
MAC Mensaje de anulación de coordinación
MFS Mensaje de Shanwick
OAT Tráfico aéreo operativo
OLDI Intercambio de datos en línea
RFL Nivel de vuelo solicitado
RFP Plan de vuelo de sustituciónRFPD Datos de plan de vuelo repetitivoRPL Plan de vuelo repetitivoRVR Alcance visual en pista
SFL Nivel de vuelo complementario
SRD Documento de requisitos de softwareSSR Radarsecundar io de vigilancia
TACT Sistema táctico de la CFMU
TOS Esquema de orientación del tráfico
UIR Región de información superior
VFR Reglas visuales de vuelo
4.PRINCIPIOSADEXP
4.1.Formatodetextodelecturadirecta
4.1.1. El formato ADEXP es un formato de texto, basado en caracteres.
4.1.2. Los mensajes ADEXP pueden serleídos porun oper ador
humano, lo que permite su mejor sincronización o la revisión de
cuestiones operativas.
4.1.3. Un formato de texto también es más abierto y comprensible.
4.2.Camposidentificadosyrecuperables
4.2.1. Un mensaje en formato ADEXP deberá estar formado por
campos.
4.2.2. Los campos deberán estar delimitados por un carácter especial de
inicio de campo, el guión («-»), e identificados porpalabr as clave
específicas.
NOTA Observe que determinados campos (aquellos que están
definidos sintácticamente de forma que contengan el
elemento del léxico «CHARACTER») pueden contener
un carácter «-» como parte del contenido del campo.
4.2.3. Este enfoque mejora la capacidad de extensión y la robustez del
formato. (Si falta un campo o es incorrecto, se puede saltar e
interpretar el resto del mensaje. (Véase Sección 4.3).
4.2.4. Otra consecuencia es que el orden de los campos dentro de un
mensaje no será relevante para determinar su legalidad, excepto
el primer campo (campo obligatorio de título) que determina loscampos permitidos.
4.2.5. Los campos pueden serbásicos o compuestos.4.2.6. Los elementos que constituyen los campos compuestos se deno-
minan subcampos se definen mediante la presencia de palabras
clave y están delimitados mediante un carácter de comienzo de
campo.
4.2.7. Los campos básicos son campos que no contienen subcampos.2000R2082 — ES — 15.06.2002 — 001.001 — 86
▼B
4.2.8. Los campos básicos o compuestos que constituyen el primer nivel
de definición de un mensaje se denominan campos primarios.
4.2.9. Todos los componentes de nivel inferior son, por definición,
subcampos que, a su vez, pueden serbásicos o compuestos.
4.2.10. Los campos compuestos son de dos clases: campos estructurados
o campos de lista.
4.2.11. Los campos estructurados tienen un contenido predefinido
formado exclusivamente por subcampos. El orden de los
subcampos dentro de un campo estructurado NO es significativo.
4.2.12. Los campos de lista comienzan con la palabra clave BEGIN y
terminan con la palabra clave END. Entre estas dos palabras
clave pueden aparecer repetidamente el mismo subcampo o la
misma combinación de subcampos. El orden de aparición dentro
del campo de lista no es semánticamente significativo.
4.2.13. En los párrafos siguientes, el término «campo» se utilizará gené-
ricamente para designar indistintamente campos primarios o
subcampos, excepto cuando se indique explícitamente lo
contrario.
4.2.14. Los campos de un mensaje pueden seropcionales u obligator ios,
según su sintaxis.
4.3.Camposnoreconocidos
4.3.1. Deberá hacerse caso omiso de todo campo no reconocido que
aparezca en un mensaje.
4.3.2. En otras palabras, si el sistema que analiza el mensaje no reco-
noce una palabra clave, ignorará todo el texto comprendido
hasta el siguiente campo primario, que no esté dentro de un
campo de lista.
4.3.3. Dependiendo del título del mensaje, el campo ignorado podrá
provocar o no el rechazo del conjunto del mensaje que está
siendo analizado.
NOTA Debería tenerse en cuenta que aunque ADEXP está dise-
ñado para ofrecer este tipo de flexibilidad, queda a la
discreción de los responsables de la definición de los
requisitos de interfaz el precisar, para cada mensaje,
cómo debe reaccionar el sistema ante un campo no reco-
nocido.
4.3.4. Si el campo no reconocido es un campo de lista (que se ha iden-
tificado gracias a la palabra clave -BEGIN), se ignorará todo su
contenido (hasta la correspondiente palabra clave -END).
4.3.5. Para evitar cualquier ambigüedad durante la recuperación que
viene a continuación del salto de un campo no reconocido, es
preciso que una palabra clave identifique un campo primario o
un subcampo.
4.3.6. Esto permite definir dos tipos de palabra clave:
— Palabras clave primarias;
— Palabras clave secundarias.
4.3.7. Una vez que ha sido definida según la clasificación anterior, una
palabra clave no puede ser utilizada en otro grupo de mensajes
definida de otro modo, con la única excepción de que esté dentro
de un campo de lista. Es posible que existan apariciones internas
de una palabra clave primaria en cualquier lugar de un campo de
lista sin crear ambigüedad, dado que la presencia de la palabra
clave BEGIN indica que podemos considerar la aparición interna
como un subcampo.
Ejemplos (de utilización de los dos tipos de palabra clave)
1)Campo primario
-RFL F330
2)Campo secundario: siempre dentro de un «Campo
Compuesto»
-GEO -GEOID 01 -LATTD 520000N -LONGTD 0150000W
donde -GEO es un campo compuesto primario y -GEOID, -
LATTD y LONGTD son subcampos.2000R2082 — ES — 15.06.2002 — 001.001 — 87
▼B
3)Campo de lista
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL
F370 -PT -PTID
…
-END RTEPTS
donde «-BEGIN» es el indicadorde campo de lista y
«RTEPTS» es un campo primario.
NOTA «RFL» está definido como un campo primario. La inclu-
sión en un campo de lista es el único caso en el que un
campo primario puede ser utilizado como un subcampo.
(Véase ejemplo 3 anterior.)
5.REGLASSINTÁCTICASADEXP
5.1.Elementosdeléxico
5.1.1. Conjunto de caracteres
5.1.1.1. El conjunto de caracteres que se utilizará para el intercambio de
mensajes en formato ADEXP deberá ser el Alfabeto internacional
no5 (IA-5), según se define en la Referencia 1.
5.1.1.2. El formato ADEXP está diseñado como formato para el inter-
cambio ordenador a ordenador que se puede transmitir por
diferentes redes informáticas o en enlaces dedicados ordenador a
ordenador. Además, hay un requisito para poder intercambiar
determinados mensajes ADEXP, normalmente mensajes relacio-
nados con Planes de vuelo y ATFM, en la Red fija de
comunicaciones aeronáuticas (AFTN).
5.1.1.3. Los mensajes que puedan transmitirse por medio de la AFTN
deberán limitar su conjunto de caracteres a los caracteres que
tienen correlación directa entre el Alfabeto internacional tele-
gráfico no2 (ITA-2) y IA-5, según se define en la Referencia 1.
NOTA Además de los caracteres gráficos y los comandos de
formato definidos a continuación, el conjunto de carac-
teres ITA-2 define «señales» (como por ejemplo, cinta
perforada). Estas señales no forman parte del conjunto
de caracteres permitido para mensajes ADEXP.
5.1.1.4. Los caracteres que se podrán utilizar dentro de mensajes ADEXP
y que pueden sertr ansmitidos pormedio de la AFTN, son los
caracteres gráficos y comandos de formato que se definen a
continuación:
Caracteres gráficos
a) mayúsculas (de la A a la Z)
b) dígitos (de 0 a 9)
c) caracteres gráficos especiales, como sigue:
1) espacio « »
2) paréntesis de apertura «(»
3) paréntesis de cierre «)»
4) guión «-»
5) signo de cierre de interrogación «?»
6) dos puntos «:»
7) punto «.»
8) coma «,»
9) apóstrofo «'»
10) signo igual «=»
11) signo más «+»
12) barra oblicua «/»
Comandos de formato
a) Retorno de carro
b) Cambio de línea2000R2082 — ES — 15.06.2002 — 001.001 — 88
▼B
5.1.2. Elementos básicos de léxico
Se definen los siguientes elementos básicos de léxico para su uso
en la presente Norma:
— ALPHA::='A'|'B'|'C'|'D'|'E'|'F'|'G'|'H'|'I'|'J'|'K'|'L'|'M'|'N'|'O'|'P'|'Q'|'-
R'|'S'|'T'|'U'|'V'|'W'|'X'|'Y'|'Z'
— DIGIT ::= '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7' | '8' | '9'— ALPHANUM ::= ALPHA | DIGIT
— SPACE ::= ' '
— HYPHEN ::= '-'— FEF ::= Carriage_return | Line_Feed— SEP ::= 1{ SPACE | FEF }— SPECIAL ::= SPACE | '(' | ')' | '?' | ':' | '.' | ',' | ''' | '=' | '+' | '/'— CHARACTER ::= ALPHA | DIGIT | SPECIAL | FEF |
HYPHEN
— LIM_CHAR ::= ALPHA | DIGIT | SPECIAL | FEF— START-OF-FIELD ::= HYPHEN
NOTA LIM_CHAR representa cualquier carácter permitido
excepto HYPHEN que se reserva para indicar el
comienzo de un campo. Por el contrario, CHARACTER
representa cualquier elemento permitido del conjunto de
caracteres.
5.1.3. Líneas, separadores y delimitadores
5.1.3.1. La división en líneas del texto de un mensaje no tendrá efectos
sobre la sintaxis.
5.1.3.2. Un separador puede ser un espacio o un comando de formato.5.1.3.3. Los campos deberán estar delineados solamente por la presencia
de un carácter de comienzo de campo seguido por una palabra
clave.
5.1.3.4. De ahí que el mensaje completo pudiera estar perfectamente en
una línea.
5.1.4. Valores con signo
5.1.4.1. Puede ser necesario indicar un valor numérico negativo.
5.1.4.2. Los campos que se requieren para indicar un valor negativo
deberán, dentro de su definición sintáctica, indicar explícitamente
que el valores un «valorcon signo», ya sea positivo o negativo.
Un campo que no haya sido definido de esta manera no podrá
representar un valor negativo.
5.1.4.3. Un «valor con signo» deberá ir siempre precedido de la letra «N»
cuando sea negativo y de la letra «P» cuando sea positivo. Un
valor cero puede ir precedido por las letras «N» o «P» indistinta-
mente.
5.1.4.4. La sintaxis de un campo que admite un valorcon signo ser á la
siguiente:
'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}Ejemplo: Un campo titulado «NUMBER» que puede contener
un valornegativo de uno a ocho dígitos se definir ía
de la siguiente forma:
'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8
Porlo tanto: -NUMBER P5 — el valorde «number » es +5
-NUMBER N5 — el valorde «number » es -5
-NUMBER 5 — sintaxis inválida, deberá
figurar obligatoriamente
una «P» o una «N»
5.1.5. Palabras clave
5.1.5.1. Una palabra clave está constituida por una secuencia de letras en
mayúscula o dígitos. Sólo introduce un campo cuando va prece-
dida del carácter de inicio de campo («-»).
keyword::= 1{ ALPHANUM }
5.1.5.2. Las palabras clave deberán respetar la siguiente sintaxis:
'-'!{SEP}!"KEYWORD"!1{SEP}! <subfield/s orcontained value>2000R2082 — ES — 15.06.2002 — 001.001 — 89
▼B
es decir, una palabra clave estará separada de su «carácter de
inicio de campo» por cero o más separadores. Deberá ir seguida
inmediatamente de uno o más separadores, seguidos por el
subcampo/s o valorcontenido per tinente.
NOTA Es importante observar que una palabra clave y su
carácter de inicio de campo pueden estar separados por
cualquier número de separadores, incluso ninguno.
Ejemplos(Lassiguientessecuenciasintroducenuncampode
formaválida.)
1) -TITLE IFPL
2) - TITLE IFPL3) - TITLE IFPL
4) -
TITLE IFPL
5.1.5.3.Recomendación Una práctica recomendada consiste en evitar la
utilización de un separador entre el carácter de inicio de campo
«-» y la palabra clave que le sigue.
NOTA
1) De los ejemplos anteriores, el primero es la elección recomen-
dada.
2) También es importante tener en cuenta que una palabra clave
tiene que irseguida inmediatamente poral menos un sepa-
rador.
5.1.5.4. A lo largo del documento, la concatenación de elementos sepa-
rados por al menos un separador se representa implícitamente
porla notación de «Concatenación suelta» (véase Sección 3.5).
NOTA Según se explicará más adelante, las palabras clave
también introducen campos de lista cuando van precedidas de la
palabra clave BEGIN.
5.1.5.5. Las palabras clave deberán ser lo más cortas posible siempre que
tengan sentido desde un punto de vista semántico.
5.1.5.6. Las palabras clave predefinidas de formato ADEXP que se
indican a continuación no podrán ser redefinidas ni utilizadas
con una función diferente en los usos específicos del formato:
TITLE: identifica una categoría de mensajes y define el
correspondiente conjunto de campos primarios
permitidos;
BEGIN: identifica el comienzo de un campo de lista;
END: identifica el final de un campo de lista;
COMMENT: identifica un campo COMMENT (observa-
ciones).
5.1.5.7. Para evitar ambigüedades (uso duplicado de una misma palabra
clave con significados diferentes) o redundancia (palabras clave
diferentes con el mismo significado), en el Anexo A (A3) a la
presente Norma se incluye una Tabla central de definiciones de
campos primarios (es decir, palabras clave primarias) y también
se incluye en el Anexo A (A4) una Tabla central de definiciones
de subcampos (palabras clave secundarias).
5.2.Campos
5.2.1. Sintaxis de los campos
field::= basic_field | structured_field | list_fieldbasic_field::= '-' keyword contained_values
contained_values::= {CHARACTER}
list_field::= '-' "BEGIN" keyword {subfields} '-' "END" keywordstructured_field::= '-' keyword field_1 field_2 ….field_n2000R2082 — ES — 15.06.2002 — 001.001 — 90
▼B
NOTA Como puede verse, en el caso de campos de lista, la
palabra clave no va precedida directamente de «-», sino
de la construcción «-»«BEGIN».
5.2.2. Composición de mensajes en términos de campos
5.2.2.1. El primer campo de un mensaje ADEXP deberá ser siempre un
campo TITLE (es decir, un campo introducido por la palabra
clave TITLE).
5.2.2.2. El resto de los contenidos de un mensaje en términos de sus
campos primarios deberá ser definido por su TITLE.
5.2.2.3. La sintaxis de los mensajes correspondientes a un TITLE dado
deberá estar definida por los campos que contiene (definido por
sus palabras clave):
— El nombre y el contenido permitido de sus campos primarios;
— El nombre y el contenido permitido de sus subcampos.
5.2.3. Campos básicos
5.2.3.1. La sintaxis de los campos básicos será la siguiente:
basic_field::= '-' keyword contained_values
5.2.3.2. La expresión «Contained_values» define el texto que proporciona
el valordel campo y puede no intr oducirningún subcampo.
Ejemplo de regla arctyp::= '-' "ARCTYP" (icaoaircrafttype |
"ZZZZ")
NOTAS
1) Una regla explícita equivalente será:
arctyp::= '-'!{SEP}!"ARCTYP"!1{SEP}!(icaoaircrafttype |
"ZZZZ").
2) Un ejemplo de porción de mensaje es:
"-ARCTYP ZZZZ".
5.2.3.3.Recomendación Cuando haya más de dos valores contenidos
dentro de un campo básico y exista, además, la necesidad de
expresar una «elección» u «opción» entre los valores, se reco-mienda construir el campo de forma estructurada e incluir los
valores contenidos dentro de subcampos.
5.2.4. Campos de lista
5.2.4.1. La sintaxis de los campos de lista será la siguiente:
list_field::='-' "BEGIN" keyword { subfields } '-' "END" keyword
5.2.4.2. Los «subcampos» pueden sercualquiercombinación de
subcampos que puede aparecer cero o más veces dentro del
campo de lista.
5.2.4.3. La lista de subcampos contenida en un campo de lista dado
deberá formar un conjunto ordenado (el orden de sucesión de los
subcampos es significativo).
Ejemploderegla addr::= '-' "BEGIN" "ADDR" { fac } '-' "END"
"ADDR"
NOTAS
1) Este ejemplo muestra que un campo «addr» es un campo de
lista que contiene cero o más apariciones de un subcampo
«fac» (una instalación ATS).
2) Un ejemplo de porción de mensaje en el que ADDR es un
campo de lista que contiene el subcampo FAC es:
-BEGIN ADDR -FAC LLEVZPZX -FAC LFFFZQZX -END
ADDR.
3) Un ejemplo de porción de mensaje en el que aparece una
combinación de subcampos es:
xxx::= '-' "BEGIN" "XXX" { yyy | zzz } '-' "END" "XXX".
5.2.5. Campos estructurados
5.2.5.1. La sintaxis de los campos estructurados deberá ser la siguiente:
structured_field::= '-' keyword field_1 field_2…field_n2000R2082 — ES — 15.06.2002 — 001.001 — 91
▼B
5.2.5.2. El número de subcampos permitido en una estructura dada deberá
depender exclusivamente del campo estructurado.
5.2.5.3. El orden de aparición de los subcampos en un campo estructurado
no deberá ser significativo, lo que permitirá realizar futuras
extensiones fácilmente (mediante la adición de nuevos
subcampos).
Ejemploderegla pt::= '-' "PT" ptid [fl] [eto]
NOTAS1) De esta forma, el campo «pt» se define como un campo
estructurado que contiene un punto (subcampo «ptid»),
seguido opcionalmente de un nivel calculado de vuelo
(subcampo «fl») y seguido opcionalmente de un tiempo esti-
mado de paso porla ver tical (subcampo «eto»).
2) Un ejemplo de aparición de ese campo puede ser:
"-PT -PTID RMS -FL F250 -ETO 921225120000".
5.2.5.4.Recomendación Siempre que se piense que los contenidos de un
campo pueden evolucionar en el futuro, es conveniente hacer un
campo estructurado. De esta forma, permitirá las extensiones
progresivas de sus subcampos. Por el contrario, un campo básico
puede ser más familiar o más sencillo de usar, pero impone una
secuencia fija de elementos (valores) con unas posibilidades de
extensión muy reducidas.
5.2.6. El campo COMMENT
5.2.6.1. El campo COMMENT introduce una zona de texto libre en la
que pueden utilizarse todos los caracteres disponibles, excepto el
carácter de comienzo de campo («-»). Esta zona se extiende hasta
el campo siguiente.
comment::= '-' "COMMENT" { LIM_CHAR }Ejemplo -COMMENT THIS IS THE BEGINNING OF A FREE
ROUTE TEXT AREA
5.2.7. El campo TITLE
5.2.7.1. El primer campo de un mensaje ADEXP deberá ser siempre un
campo TITLE. Su sintaxis será la siguiente:
title::= '-' "TITLE" 1{ ALPHA }10
5.2.7.2. Los posibles valores de un campo TITLE son el conjunto de
títulos de mensaje ADEXP que se enumeran el Anexo B de la
presente Norma.
Ejemplo -TITLE IFPL
6.DESCRIPCIÓN NORMALIZADA DE LOS MENSAJES
ADEXP
6.1.Introducción
6.1.1. Los siguientes párrafos definen la forma en que se deberá
describir el formato ADEXP de las diferentes categorías de
mensajes de forma normalizada, en el ámbito de la presente
Norma.
6.1.2. La descripción normalizada comprende:
— La definición de los términos auxiliares;
— La definición sintáctica y semántica de cada campo primario
individual;
— La definición sintáctica y semántica de cada subcampo indivi-
dual;
— La definición de cada grupo de mensajes con referencia a sus
documentos de definición.
6.1.3. La presente Norma no proporciona los detalles relacionados con
la composición de los campos ni con las reglas de inserción de
datos para el título de cada mensaje.
6.1.4. Debería hacerse referencia a los documentos de definición (espe-
cificación de interfaz) que es aplicable al grupo de mensajes
pertinente (Véase sección 6.5.7).2000R2082 — ES — 15.06.2002 — 001.001 — 92
▼B
6.1.5. La documentación de definición debería proporcionar, de forma
normalizada, la siguiente información para cada título de
mensaje:
— Una lista de los campos primarios obligatorios;
— Una lista de los campos primarios opcionales;— Las reglas de inserción de datos para cada campo y, en parti-
cular, las reglas de utilización de los subcampos definidos
como opcionales dentro de la presente Norma;
— Las reglas relativas a la recuperación que sigue a la detección
de un campo no reconocido.
6.1.6. Los campos actualmente reconocidos y acordados por todos los
estados miembros de Eurocontrol, para ser utilizados en las dife-
rentes categorías de mensajes que han sido definidos para su uso
utilizando ADEXP, son los indicados en el Anexo A del presente
documento.
6.1.7. Un campo no deberá ser utilizado para ningún fin diferente del
especificado en su descripción semántica.
6.1.8. El Anexo D contiene un índice central de los campos reservados.
La utilización de «campos reservados» no ha sido aprobada
dentro de los mensajes ADEXP actualmente definidos. Por lo
general, son campos que han sido previstos para un posible uso
futuro o que se utilizan localmente dentro de sistemas nacionales.
Su inclusión en la presente Norma tiene por objeto asegurar el
carácter único de los títulos de los campos y evitar redundancias
innecesarias.
6.2.Términosauxiliares
6.2.1. Para obtener una definición legible de los campos, a menudo
resulta útil introducir términos auxiliares en la descripción grama-
tical.
6.2.2. Estos términos auxiliares no sirven para introducir un campo o
subcampo y, porello, no están asociados con ninguna palabr a
clave en particular. Sin embargo, pueden aparecer en la defini-
ción de más de un campo, subcampo o término auxiliar. Por
ejemplo, un término auxiliar como «date» se puede utilizar en la
definición de muchos campos.
6.2.3. Todos los términos auxiliares necesarios deberán introducirse en
orden alfabético y están definidos en el Anexo A (A2) a la
presente Norma.
6.2.4. La descripción podrá presentarse en una tabla como la siguiente, ordenada por orden
alfabético:
Términos
auxiliaresSintaxis SemánticaUtilizados
en Campos
primariosUtilizados
en
SubcamposUtili-
zados
en
Térmi-
nos
auxi-
liares
adexpmsg { CHARACTER } Texto libre
conforme con
la sintaxis
descrita para
un mensaje
ADEXP.ifpdlong
rfpdlong
preproctxtpostproctxt
aidequip-
ment( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipo de
ayuda a la
comunicación
porr adio,
navegación y
aproximación.ceqpt
aircraftid 1{ ALPHANUM
}7Identificación
de aeronave.arcid
arcidk
arcidoldprevarcid2000R2082 — ES — 15.06.2002 — 001.001 — 93
▼B
6.3.Definicióndeloscamposprimarios
6.3.1. Todos los campos primarios utilizados en los mensajes ADEXP
deberán ajustarse a la sintaxis y semántica especificadas en el
Anexo A (A3) a la presente Norma.
6.3.2. En primer lugar se proporcionará la sintaxis de cada campo,
seguida del contenido semántico en términos claros y precisos.
6.3.3. La sintaxis de los campos se expresará utilizando la notación
BNF como se describe en la sección 3 de la presente Norma.
6.3.4. La descripción puede presentarse en una tabla como la siguiente, ordenada por orden
alfabético, en donde:
— La primera columna representa la parte izquierda de una norma BNF (se decir, un
elemento situado a la izquierda del símbolo «::=») y la tercera columna representa
su parte derecha.
— La segunda columna (clase) indica si un campo es básico («b») o compuesto («c»).
Campo primario Clase Sintaxis Semántica
eobt b '-' "EOBT" timehhmm Hora estimada de abandono
del área de estacionamiento
6.4.Definicióndelossubcampos
6.4.1. Todos los subcampos utilizados en los mensajes ADEXP deberán
estarconfor mes con la sintaxis y semántica indicada en el Anexo
A (A4) de la presente Norma.
6.4.2. Adicionalmente, a efectos de referencia cruzada, se identifican los
campos primarios dentro de los que se encuentra un subcampo
dado.
6.4.3. Un subcampo también puede sersubcampo de otr os subcampos y,
por ello, se incluye también una referencia de estos subcampos.
6.4.4. La descripción puede presentarse en una tabla como la siguiente, ordenada por orden
alfabético:
Subcampo Clase Sintaxis SemánticaUtilizado en
Campos
primariosUtili-
zado en
Subca-
mpos
brng b '-' "BRNG"
refbearingRumbo desde
una ayuda a la
navegación a un
punto (en grados
magnéticos)ref
6.5.Grupodemensajes
6.5.1. Las categorías operativas (grupos) de mensajes que han sido defi-
nidas para su uso utilizando el formato ADEXP se incluyen en el
Anexo E de la presente Norma.
6.5.2. Los grupos se definen en términos de naturaleza operativa de los
mensajes intercambiados y se caracterizan a menudo por los
sistemas utilizados.
6.5.3. Para cada grupo de mensajes se hará referencia a los correspon-
dientes documentos de definición.
6.5.4. Ningún valor de título utilizado para un grupo de mensajes podrá
reutilizarse para otro grupo con un significado diferente.
6.5.5. Deberá mantenerse un índice central de títulos de mensaje en el
Anexo B de la presente Norma.
6.5.6. Para cada título de mensaje incluido en el índice central de títulos
de mensaje, se incluye una referencia para el grupo relacionado.
Por consiguiente, para cada mensaje se incluye una referencia a
los documentos de definición a través del grupo de mensaje.
6.5.7. En el Anexo C se incluye también un índice central de títulos de
mensajes reservados. No se ha acordado la utilización de estos2000R2082 — ES — 15.06.2002 — 001.001 — 94
▼B
títulos de mensajes reservados en los grupos de mensajes ADEXP
actualmente definidos. Por lo general, se trata de mensajes defi-
nidos en previsión de una futura utilización dentro de los grupos
definidos o se utilizan de forma local dentro de sistemas nacio-
nales. Su inclusión en la presente Norma tienen por objeto
asegurar el carácter único de los títulos de los mensajes y para
evitar redundancias innecesarias.2000R2082 — ES — 15.06.2002 — 001.001 — 95
▼B
ANEXO A (Normativo)
DEFINICIONESDELOSCAMPOSADEXP
A.1.Introducción
El presente Anexo contiene una lista de todos los campos, Términos
auxiliares, Campos primarios y Subcampos que han sido definidos para
su utilización en el formato ADEXP.
A.2.TérminosauxiliaresADEXP
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
adexpmsg { CHARACTER } Texto libre
conforme a la
sintaxis descrita
para un mensaje
ADEXP.ifpdlong
rfpdlong
preproct-
xt
post-
proctxt
aidequipment ( ('N' | 'S') ! [
equipmentcode ] ) |
equipmentcodeEquipo de ayuda a
la comunicación por
radio, navegación y
aproximación.ceqpt
aircraftid 2{ ALPHANUM }7 Identificación de
aeronave.arcid
arcidk
arcidold
prevarci-
d
aircraf-
tidwldcrd1{ ALPHANUM |
'+' | '?' }7Comodín para iden-
tificación de aero-
naves para utilizar
en mensajes de
interrogación:
«?» reemplaza un
carácter;
«+» reemplaza
cualquiernúmer o de
caracteres.arcidk
atsroute 2 {ALPHANUM} 7 El indicativo de una
ruta ATS.atsrt refatsrte
century 2{DIGIT}2 Dos primeros
dígitos de un siglo.fulldate
coorstatusident 3 {ALPHA} 3 Un indicador del
estado de coordina-
ción de un vuelo.statid
coorstatus-
reason3 {ALPHA} 7 El motivo para la
notificación de un
cambio en el estado
de coordinación.statreas-
on
country 2{ALPHA}2 Indicativo ICAO de
un país de dos
letras.refatsrte2000R2082 — ES — 15.06.2002 — 001.001 — 96
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
datalink 1 {'S' | 'H' | 'V' | 'M'
}4Indicativo ICAO de
la capacidad del
enlace de datos.
Puede contener
cualquiera de los
valores:
S, H, V o M en
cualquieror den,
pero sin repetirse.dat
date year! month ! day Una indicación de
fecha en el formato,
YYMMDD.
Ej.- 930424 = 24 de
abril de 1993.ada
add
aobd
cobd
ctod
eobd
eobdk
eobdold
etod
fstday
iobd
lstdayneweobd
valfrom
valfromk
valfro-
mold
validity-
date
valuntil
valuntilk
valunti-
loldeto datetime
datetime date ! timehhmm Un término «date»
según se describe
arriba y seguido
inmediatamente por
el tiempo en
formato HHMM.
Ej.-
9304240930=0930Z
el 24 de abril de
1993.origindt
datewldcrd 1{ DIGIT | '+' | '?'
)6Un término «date»
que puede llevarun
comodín.valfromk
valuntilk
day ('0' | '1' | '2' | '3') !
DIGITUn número de dos
dígitos que puede
contenerlos dígitos
desde 00 hasta 31.endtime
filtim
starttimeendreg
from
startreg
untildate
fulldate
emergradio 1 {'U' | 'V' | 'E' } 3 Indicador del tipo
de radio de emer-
gencia a bordo del
avión. Puede ser
uno o varios carac-
teres definidos en
cualquieror den,
pero sin repetirse.splr2000R2082 — ES — 15.06.2002 — 001.001 — 97
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
eqptcode 1 {ALPHANUM} 2 Código que identi-
fica una capacidad
de equipo. Puede
seridéntico al
código de equipoeqpt
eqptstatus 2 {ALPHA} 2 Un valorexpr esado
mediante dos letras
que describen el
estado de la capa-
cidad de las aero-
naveseqpt
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' )} 24Código de letras
ICAO que indica el
equipo a bordo.
Puede seruno o
varios caracteres
definidos en cual-
quier orden, pero
sin repetirse.aidequip-
ment
errorcode 1{DIGIT}4 Número de código
de mensaje de error.error
fieldid 1{ ALPHANUM } Nombre de campo
ADEXP válido (p.
ej. palabra clave).errfield
ifpsmod
firindicator 4{ ALPHA }4 Un indicativo ICAO
de un FIR.eetfir
flightlevel ('F' | 'A') ! 3{
DIGIT }3 | ('S' |
'M') ! 4{ DIGIT } 4Un nivel de vuelo
expresado como:
«F» o «A» seguido
de tres dígitos o,
«S» o «M» seguido
de cuatro dígitos.rfl crfl1
crfl2
efl
fl
tfl
sfl
ptrfl
flightplanstatus 'EMER' | 'HUM' |
'HOSP' | 'SAR' |
'HEAD' | 'STATE'Motivo para trata-
miento especial
según se indica en
el Campo 18,
elemento «STS/».
EMER = Emer-
gencia
HUM = Vuelo
humanitario
HOSP = Vuelohospital
SAR = Búsqueda y
rescate
HEAD = Jefe de
estado
STATE = Vuelo
oficialsts
flightrule 'I' | 'V' | 'Y' | 'Z' Indicador de las
normas de vuelo
aplicables a un
vuelo.fltrul
flighttype 'S' | 'N' | 'G' | 'M' |
'X'El tipo de vuelo
conforme al indica-
tivo ICAO utilizado.flttyp
flighttypechg 'OAT' | 'GAT' Indicación, en la
descripción de la
ruta de vuelo, de
una modificación
del tipo de vuelo a
«OAT» o «GAT».chgrul ptrulchg2000R2082 — ES — 15.06.2002 — 001.001 — 98
▼M1
▼B
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
fulldate century ! year !
month ! dayIndicación de la
fecha en formato
CCYYMMDD
Ej.- 19970801 = 1
de agosto de 1997fulldate-
time
fulldatetime fulldate ! timehhmm Indicación de la
fecha en formato
«fulldate», seguida
inmediatamente por
el tiempo en el
formato HHMM
Ej.-
199708010930=09:-
30 horas del 1 de
agosto de 1997mesval-
period
geoname "GEO" !
2{DIGIT}2Identificación dada
a una posición
geográfica expre-
sada en latitud y
longitud.geoid
heading 3{DIGIT}3 Un número de tres
dígitos del rango
001 a 360.ahead
ICAOaero-
drome4{ ALPHA }4 Un indicativo ICAO
de cuatro letras para
un aeródromo.adarr
adep
adepk
adepold
ades
adesk
adesold
altrnt1
altrnt2adid
ICAOaerodro-
mewldcrd1{ ALPHA | '+' | '?'
}4Comodín de aeró-
dromo ICAO para
su uso en mensajes
de interrogación:
«?» reemplaza un
carácter;
«+» reemplaza
cualquiernúmer o de
caracteres.adepk
adesk
ICAOair-
crafttypeALPHA ! 1{
ALPHANUM }3Indicativo ICAO del
tipo de aeronave.arctyp
ICAOmsg { CHARACTER } Mensaje ICAO
(conforme a la
sintaxis descrita en
la Ref. {4})msgtxt
ifpuid 1{ ALPHANUM } Identificadorde una
unidad IFPS.ifpuresp
latitudelong 6{ DIGIT }6 Latitud expresada
con seis dígitos.lattd
latitudeside 'N' | 'S' Indicadorde latitud
«Norte» o «Sur».lattd
lifejackets 1 {'L' | 'F' | 'U' | 'V'}
4IndicadorICAO del
tipo de chaleco
salvavidas embar-
cado.
Puede seruno o
varios de los carac-
teres definidos en
cualquieror den,
pero sin repetirse.splj
longitudelong 7{ DIGIT }7 Longitud expresada
con siete dígitos.longtd2000R2082 — ES — 15.06.2002 — 001.001 — 99
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
longitudeside 'E' | 'W' Indicadorde una
longitud «Este» u
«Oeste».longtd
machnumber'M' ! 3{ DIGIT }3 El númer o de Mach. mach
aspeedcrmach
ptmach
modifind 1{ALPHANUM} Indicación del tipo
de modificación
realizado en uncampo.ifpsmod
month ('0' | '1' ) ! DIGIT Mes, expresado con
un número de dos
dígitos.date
fulldate
numdays ('0' | '1') ! ('0' | '2') !
('0' | '3') ! ('0' | '4') !
('0' | '5') ! ('0' | '6') !
('0' | '7')Indicación de los
días de la semana
en los que un RPL
está activo.days
daysk
daysold
numdayswldcrd 1{ DIGIT | '+' | '?'
}7Indicación de los
días de la semana
en los que un RPL
está activo.
También pueden
utilizarse caracteres
comodín.daysk
originatorid 1{ ALPHANUM
}10Identificadordel
emisorde un
mensaje.orgnid
qrorgn
point 2{ ALPHANUM }5 Indicativo de un
punto significativo.
Puede serun punto
publicado, un punto
geográfico, un
punto de referencia
o un punto dado
artificialmente
como un punto
«renombrado»
(RENxx).atsrt
chgrul
cop
dct
eetpt
mach
rfl
speed
sid
starptid
refatsrte
refbearing 3{ DIGIT }3 Valor del rumbo de
referencia.brng
refname "REF" ! 2{DIGIT}2 El indicativo dado a
un punto definido
porsu r umbo y la
distancia desde un
punto publicado.refid
regulid 1{ ALPHANUM
}20Identificación de
una normativa
ATFM aplicable a
un vuelo.regul regid
renameid "REN" !
2{DIGIT}2Indicativo de un
punto renombrado.renid
rrteid 1{ ALPHANUM}
20Indicativo de una
redistribución.rrteref
rtf 6{DIGIT}6 Frecuencia de radio
expresada en MHz
y redondeada a tres
decimales.freq
rulechg 'VFR' | 'IFR' Indicativos utili-
zados en la descrip-
ción de una ruta
para indicar un
cambio en las
normas de vuelo.chgrul ptrulchg2000R2082 — ES — 15.06.2002 — 001.001 — 100
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
seconds ( '0' | '1' | '2' | '3' | '4'
| '5' ) ! DIGITSegundos.
Dos dígitos desde
«00» hasta «59».eto
sto
spd ('K' | 'N') ! 4{
DIGIT }4Velocidad.
Expresada por «K»
o «N» seguido de
cuatro dígitos.aspeed
speedcrspeed
ptspeed
ssrequipment 1 {ALPHA} 2 Indicativo ICAO de
un equipo SSR a
bordo y, opcional-
mente, indicación
de una capacidad de
enlace de datos.seqpt
stayidentifier'STAY' ! ( '1' | '2' |
'3' | '4' | '5' | '6' | '7' |
'8' | '9' )Indicativo de un
período de
«estancia» o
período de «acti-
vidad especial»
dentro de la ruta de
un vuelo.ptstay
stayident
survivaleqpt 1 {'P' | 'D' | 'M' | 'J'
}4Indicativo ICAO de
equipo de supervi-
vencia a bordo.
Puede seruno o
varios caracteres
definidos en cual-
quier orden, pero
sin repetirse.spls
text20 1{ LIM_CHAR }20 Texto de 1 a 20
caracteres, a excep-
ción del carácter
guión.altnz
com
depz
destz
nav
per
sts
typz
timehhmm ( '0' | '1' | '2' ) !
DIGIT ! ( '0' | '1' |
'2' | '3' | '4' | '5' ) !
DIGITTiempo, expresado
en horas (2 dígitos
00-23) y minutos (2
dígitos 00-59).
Puede serla hor a
del día o una dura-
ción.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-
lapsedDIGIT ! DIGIT !
('0' | '1' | '2' | '3' | '4' |
'5' ) ! DIGITUn número ilimi-
tado de horas y
minutos, utilizado
para duraciones.ttleet
eetfir
eetpt
sple
timewldcrd 1{ DIGIT | '+' | '?'
}4Comodín de un
timehhmm.eobtk2000R2082 — ES — 15.06.2002 — 001.001 — 101
▼B
Términos auxi-
liaresSintaxis SemánticaUtili-
zados en
Campos
primariosUtili-
zados en
Subcam-
posUtilizados
en
Términos
auxiliares
titleid 1{ ALPHA }10 Un título de
mensaje ADEXP
válido. (Véase
Anexo B.)msgtyp
orgmsg
title
waketurbcat 'H' | 'M' | 'L' Indicativo ICAO de
turbulencia de
estela.wktrc
year2{ DIGIT }2 Dos últimos dígitos
de un año.date
fulldate
A.3.CamposprimariosADEXP
Campos
primarios
ADEXPClase Sintaxis Semántica
ad C '-' "AD" adid [(fl | flblock)] [eto]
[to] [cto] [sto] [ptstay] [ptrfl]
[ptrulchg] [(ptspeed | ptmach)]Indicativo de un aeródromo. En el
caso de que el aeródromo forme
parte de la descripción de ruta, se
podrá proporcionar información
complementaria de la ruta.
ada b '-' "ADA" date Fecha real de llegada.
adarr b -' "ADARR" (ICAOaerodrome |
'ZZZZ')Aeródromo real de llegada.
adarrz b '-' "ADARRZ" text20 Nombre del aeródromo real de
llegada cuando no existe indicativo
de situación ICAO.
add b '-' "ADD" date Fecha real de salida.
addrc '-' "BEGIN" "ADDR" 1 { fac } '-'
"END" "ADDR"Lista de destinatarios.
adep b '-' "ADEP" (ICAOaerodrome |
'AFIL' | 'ZZZZ')Indicativo de situación ICAO del
aeródromo de salida o la indicación
«AFIL» para indicar un plan de
vuelo registrado en el aire o
«ZZZZ» cuando el aeródromo de
partida no tiene asignado un indi-
cadorICAO de situación.
adepk b '-' "ADEPK" (ICAOaerodrome |
'AFIL' | 'ZZZZ' | ICAOaerodro-
mewldcrd)Aeródromo de salida utilizado
como clave de base de datos en una
interrogación; puede utilizarse con
comodín.
Puede contenerun indicadorde
situación ICAO o la indicación
«AFIL» para indicar un plan de
vuelo registrado en el aire o
«ZZZZ» cuando el aeródromo de
partida no tiene asignado un indi-
cadorICAO de situación o una
combinación de caracteres alfabé-
ticos y comodines.
adepold b '-' "ADEPOLD" (ICAOaerodrome
| 'AFIL' | 'ZZZZ')Aeródromo de salida «anterior».
Puede contenerel indicadorde
situación ICAO o la indicación
«AFL» para indicar un plan de
vuelo registrado en el aire o
«ZZZZ» cuando el aeródromo de
partida no tiene asignado un indi-
cadorICAO.
ades b '-' "ADES" (ICAOaerodrome |
'ZZZZ')IndicadorICAO de situación del
aeródromo de destino o «ZZZZ»
cuando el aeródromo de destino no
tiene asignado un indicadorICAO.2000R2082 — ES — 15.06.2002 — 001.001 — 102
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
adesk b '-' "ADESK" (ICAOaerodrome |
'ZZZZ' | ICAOaerodromewldcrd)Aeródromo de destino utilizado
como clave de base de datos en una
interrogación; puede utilizarse con
comodín.
Puede contenerun indicadorde
situación ICAO o «ZZZZ» cuando
el aeródromo de destino no tiene
asignado un indicadorICAO o una
combinación de caracteres alfabé-
ticos y comodines.
adesold b '-' "ADESOLD" (ICAOaerodrome
| 'ZZZZ')Aeródromo de destino «anterior».
Puede contenerel indicadorde
situación ICAO o «ZZZZ» cuando
el aeródromo de destino no tiene
asignado un indicadorICAO.
adexptxt c '-' "ADEXPTXT" (preproctxt |
postproctxt)Contiene un mensaje ADEXP.
afildata c '-' "AFILDATA" ptid fl eto Fecha estimada para un plan de
vuelo registrado en el aire. Identi-
ficación de un punto, nivel de
vuelo de unión y la fecha-hora
estimada de paso porla ver tical del
punto.
NOTA: El nivel de vuelo indicado
es el nivel de vuelo al que ha sido
autorizado el vuelo para entrar en
el espacio aéreo controlado sobre el
punto indicado. No tiene que
corresponderse necesariamente con
el RFL.
ahead b '-' "AHEAD" (heading | "ZZZ") Rumbo asignado a un vuelo,
expresado en grados. Tiene que ser
un valor numérico de tres dígitos o
el valor«ZZZ» cuando no se haya
asignado ningún rumbo.
altnz b '-' "ALTNZ" text20 Nombre del aeródromo alternativo
si no existe situación ICAO.
altrnt1 b '-' "ALTRNT1" (ICAOaerodrome |
'ZZZZ')Indicadorde situación ICAO del
primer aeródromo alterativo de
destino o el indicador«ZZZZ»
cuando el aeródromo asignado no
tenga asignado un indicadorde
situación ICAO.
altrnt2 b '-' "ALTRNT2" (ICAOaerodrome |
'ZZZZ')Indicadorde situación del segundo
aeródromo alternativo de destino o
el indicador«ZZZZ» cuando el
aeródromo no tenga asignado un
indicadorde situación ICAO.
aobd b '-' "AOBD" date Fecha real de abandono del área de
estacionamiento.
aobt b '-' "AOBT" timehhmm Hora real de abandono del área de
estacionamiento.
arcid b '-' "ARCID" aircraftid Identificación de la aeronave.
Pueden ser la marca de registro de
la aeronave o el indicativo ICAO
del operador de la aeronave
seguido del identificadorde vuelo.
arcidk b '-' "ARCIDK" (aircraftid | aircraf-
tidwldcrd)Identificación de la aeronave, utili-
zado como clave de base de datos
en una pregunta; puede llevar
comodines.
Debe seruna combinación de
caracteres alfanuméricos y como-
dines hasta un máximo de siete
caracteres en total.2000R2082 — ES — 15.06.2002 — 001.001 — 103
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
arcidold b '-' ARCIDOLD aircraftid La identificación «previa» de la
aeronave. Si es necesario modificar
la identificación de la aeronave, el
nuevo valorvendr á dado en
«ARCID».
arctyp b '-' "ARCTYP" (ICAOaircrafttype |
"ZZZZ")Tipo de aeronave (identificación
ICAO del tipo) o ZZZZ.
aspeed b '-' "ASPEED" (spd | machnumber|
"ZZZ")Velocidad actual asignada del
vuelo, en kilómetros por hora,
nudos o número de Mach.
Tiene que ser«M» seguido de tr es
dígitos, «K» o «N» seguido de
cuatro dígitos o «ZZZ» cuando no
se haya asignado ninguna restric-
ción de velocidad.
ata b '-' "ATA" timehhmm Hora real de llegada.
atd b '-' "ATD" timehhmm Hora real de salida.
atot b '-' "ATOT" timehhmm Hora real de despegue.atsrt b '-' "ATSRT" atsroute point point Indicativos de ruta ATS e identifi-
cadores del primer y último punto.
cassaddrc '-' "BEGIN" "CASSADDR" { fac
} '-' "END" "CASSADDR"Destinatarios a los que deberían ser
dirigidos los mensajes ATFM.
ceqpt b '-' "CEQPT" aidequipment Equipos de ayuda de comunicación
por radio, navegación y aproxima-
ción (según campo 10 de ICAO).
cfl c '-' "CFL" fl [ptid] Nivel autorizado de vuelo. El nivel
de vuelo actualmente asignado por
ATC al piloto (número de nivel de
vuelo).
chgrul b '-' "CHGRUL" ( rulechg | flightty-
pechg | rulechg flighttypechg )
pointIndicación de un cambio en las
«normas de vuelo»«(VFR/IFR) o
en el tipo de vuelo» (OAT/GAT) o
en ambos junto con el punto en el
que se produce el cambio.
cobd b '-' "COBD" date Fecha calculada de abandono del
área de estacionamiento.
cobt b '-' "COBT" timehhmm Hora calculada de abandono del
área de estacionamiento.
com b '-' "COM" text20 Equipo de comunicaciones (según
el campo 18 COM/ de ICAO).
comment b '-' "COMMENT" 1 { LIM_CHAR
}Comentario general en texto libre
pero sin guión.
condid b '-' "CONDID" 1 {LIM_CHAR} 30 Identificación de una «condición
excepcional» surgida en el contexto
de ATFM.
coordata c '-' "COORDATA" ptid (to | sto) tfl
[sfl]Condiciones de transferencia de
control de un vuelo. Identificación
de un punto, nivel de vuelo y hora
estimada de llegada a ese punto e
información complementaria
opcional del nivel de vuelo.
cop b '-' "COP" point Identificadorde un punto de coor -
dinación, ya sea un indicativo
codificado de un punto o un
nombre dado artificialmente
(GEOxx, RENxx o REFxx).2000R2082 — ES — 15.06.2002 — 001.001 — 104
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
crsclimb c '-' "CRSCLIMB" ptid (crspeed |
crmach) crfl1 crfl2Indicación de un ascenso de
crucero. Punto en el que se iniciará
el ascenso, velocidad o número de
Mach y los dos niveles que indican
la banda de nivel de vuelo que se
ocupará durante el ascenso. El
segundo nivel puede ser«PLUS»
cuando no se conoce el nivel supe-
rior.
cstat c '-' "CSTAT" statid [statreason] Indicador que confirma el estado
de la nueva coordinación de un
vuelo y, opcionalmente, el motivo
del cambio.
ctod b '-' "CTOD" date Fecha calculada de despegue.
ctot b '-' "CTOT" timehhmm Hora calculada de despegue
(CTOT): hora de referencia de una
ranura ATFM.
dat b '-' "DAT" datalink Indicación de capacidad de enlace
de datos a bordo de la nave.
days b '-' "DAYS" numdays Días de operación de un plan de
vuelo repetitivo (1234567 donde 1
corresponde a lunes, 2 a martes,
etc., con 0 en las columnas no
operativas.
daysk b '-' "DAYSK" (numdays |
numdayswldcrd)Días de operación de un plan de
vuelo repetitivo, utilizado como
clave de la base de datos en un
mensaje de interrogación; puede
tenercomodines.
daysold b '-' "DAYSOLD" numdays Días de operación «previos». Se
utiliza como clave de base de
datos. Si es necesario corregir los
días de operación de un RPL, los
nuevos valores serán dados en
«DAYS».
dct b '-' "DCT" point point Indica una ruta directa entre dos
puntos.
Los puntos pueden serun indicador
ICAO válido de un punto o un
punto en un campo GEO, REN o
REF de la forma GEOxx, RENxx o
REFxx.
delay b '-' "DELAY" timehhmm Período de tiempo que representa
un retraso. La naturaleza del
retraso, p. ej. retraso de un vuelo,
retraso de procesamiento, etc.
depende del contexto.
depz b '-' "DEPZ" text20 Nombre del aeródromo de salida
cuando no existe indicadorde
situación ICAO.
desc b '-' "DESC" 1 {LIM_CHAR} Descripción de una condición o
entidad que es importante para el
contenido del mensaje.
destz b '-' "DESTZ" text20 Nombre del aeródromo de destino
cuando no existe indicadorde
situación ICAO.
eetfirb '-' "EETFIR" fir indicator
timehhmm_elapsedIdentificación del FIR y tiempo
transcurrido acumulado (en horas y
minutos) hasta el límite del FIR.
eetlat c '-' "EETLAT" lattd time Indicación del tiempo transcurrido
hasta una posición dada solamente
porlatitud.
eetlong c '-' "EETLONG" longtd time Indicación del tiempo transcurrido
hasta una posición dada solamente
porlongitud.2000R2082 — ES — 15.06.2002 — 001.001 — 105
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
eetpt b '-' "EETPT" point timehhmm_e-
lapsedIdentificadorde punto y tiempo
transcurrido acumulado hasta el
punto.
endtime b '-' "ENDTIME" day ! timehhmm Hora en que finaliza un período de
tiempo.
entrydata c '-' "ENTRYDATA" (ptid | airspdes
| (ptid airspdes)) [fl] [ptrfl]
[(ptspeed | ptmach)] [ptfltrul]
[ptmilrul]Datos del plan de vuelo aplicables
a un vuelo en el punto dado o a la
entrada del vuelo en el espacio
aéreo en cuestión. Uno o los dos
campos «ptid» y «airspdes» tienen
que estarpr esentes.
eobd b '-' "EOBD" date Fecha estimada de abandono del
área de estacionamiento.
eobdk b '-' "EOBDK" date Fecha estimada de abandono del
área de estacionamiento usada
como clave de la base de datos en
una interrogación; puede tener
comodines.
Tiene que seruna combinación de
dígitos o comodines hasta un
máximo de 6 caracteres en total.
eobdold b '-' "EOBDOLD" date Fecha «previa» estimada de aban-
dono del área de aparcamiento. Se
utiliza como clave de base de
datos. Si es necesario modificar la
fecha estimada de abandono del
área de estacionamiento, el nuevo
valorestar á dado en «EOBD».
eobt b '-' "EOBT" timehhmm Hora estimada de abandono del
área de estacionamiento (EOBT).
eobtk b '-' "EOBTK" (timehhmm |
timewldcrd)Hora estimada de abandono del
área de estacionamiento usada
como clave de base de datos en una
interrogación, puede tener como-
dines.
eobtold b '-' "EOBTOLD" timehhmm Hora «previa» estimada de aban-
dono del área de aparcamiento. Se
utiliza como clave de base de
datos. Si es necesario modificar la
fecha estimada de abandono del
área de estacionamiento, el nuevo
valorser á dado en «EOBT».
eqcst b '-' "BEGIN" "EQCST" 1 {eqpt}
'-' "END" "EQCST"Lista de los códigos de capacidad
de equipo seguidos porun valor
que refleja el estado actual de la
capacidad
errfield b '-' "ERRFIELD" fieldid Nombre de campo(s) erróneo(s)
ADEXP.
error b '-' "ERROR" [errorcode] 1{
LIM_CHAR }Texto de mensaje de error. Opcio-
nalmente, puede contenerun
código de identificación de error.
estdata c '-' "ESTDATA" ptid eto fl [sfl] Datos estimados. Identificación de
un punto, el nivel de vuelo esti-
mado (número de nivel de vuelo) y
la fecha-hora estimada de llegada a
ese punto seguidos, opcionalmente
porel nivel de vuelo complemen-
tario (números de nivel de vuelo
seguidos porel indicadorA o B).
etod b '-' "ETOD" date Fecha estimada de despegue.
etot b '-' "ETOT timehhmm Hora estimada de despegue.2000R2082 — ES — 15.06.2002 — 001.001 — 106
▼M1
▼B
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
extaddrc '-' "EXTADDR" num | { fac } |
(num {fac})Destinatarios proporcionados
además de los determinados auto-
máticamente, p. ej. «extra
adresses». Puede contener sola-
mente el número de destinatarios,
los destinatarios propiamente
dichos o ambos datos.
filrte b '-' "FILRTE" {LIM_CHAR} Descripción de la ruta exactamente
como se registró, es decir, sin
ningún tipo de procesamiento.
filtim b '-' "FILTIM" day ! timehhmm Grupo día-hora que especifica el
momento en el que fue depositado
el mensaje para su transmisión.
flband c '-' "FLBAND" fl fl Una banda de niveles de vuelo que
define el espacio aéreo vertical-
mente y que incluye los niveles de
vuelo dados.
fltrul b '-' "FLTRUL" flightrule Normas de vuelo, según el campo 8
de ICAO.
flttyp b '-' "FLTTYP" flighttype Tipo de vuelo según campo 8 de
ICAO.
fmp b '-' "FMP" 4{ ALPHA }4 Identificadorde un puesto de
gestión de flujo de tráfico aéreo.
fmplist c '-' "BEGIN" "FMPLIST" fmp
reglist
'-' "END" "FMPLIST"Lista de los FMP y sus normativas
ATFM asociadas.
freq b '-' "FREQ" rtf Frecuencia de radio.
fstday b '-' "FSTDAY" date Primer día de operación de un plan
de vuelo repetitivo. Se utiliza para
proporcionar el primer día real a
partir del cual serán generados los
planes de vuelo a partir de un RPL
(véase campo valfrom) o el primer
día en el que es efectiva una modi-
ficación de un RPL.
furthrte b '-' "FURTHRTE" {LIM_CHAR} Continuación de ruta de un vuelo.
Para utilizar en los mensajes que
contienen datos estimados para
indicarla continuación de la r uta al
punto estimado. Puede contener
solamente el punto siguiente o la
continuación de la ruta completa
hasta el destino.
geo c '-' "GEO" geoid lattd longtd Punto de una ruta definido por su
latitud y longitud e incluido en el
plan de vuelo, como GEOxx
(donde xx es un número de
secuencia).
ifp b '-' "IFP" 1{ALPHA} Indicación de errores conocidos
dentro de un FPL.
ifpdlist c '-' "BEGIN" "IFPDLIST" 1 {
ifpdlong } '-' "END" "IFPDLIST"Lista completa de IFPD correspon-
diente a la palabra clave de base de
datos dadas en un mensaje de inte-
rrogación.
Contiene una lista de información
completa para cada vuelo indivi-
dual que se corresponde con las
palabras clave de interrogación
dadas.2000R2082 — ES — 15.06.2002 — 001.001 — 107
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
ifpdslist c '-' "BEGIN" "IFPDSLIST" 1 {
ifpdsum } '-' "END" "IFPDSLIST"Lista de ifpdsum correspondiente a
la palabra clave de base de datos
dadas en un mensaje de interroga-
ción.
Contiene una lista de información
resumida para cada vuelo indivi-
dual que se corresponde con laspalabras clave de interrogación
dadas.
ifplid b '-' "IFPLID" ALPHA ALPHA {
DIGIT }8Identificadorúnico del plan de
vuelo asignado porel IFPS.
ifpsmod b '-' "IFPSMOD" fieldid modifind Indicación dada porel IFPS de los
campos que han sido modificados y
la naturaleza de la modificación.
ifpuresp b '-' "IFPURESP" ifpuid Identificador de la IFPU respon-
sable de una interrogación. Deberá
procesar esta interrogación y darle
respuesta.
ignore c '-' "BEGIN" "IGNORE" { (condi-
tion | condition ptid ptid) }'-'
"END" "IGNORE"Indicación de las condiciones que
han sido «ignoradas» o circunva-
ladas durante el procesamiento del
mensaje en cuestión. Una condi-
ción «ignorada» puede estar limi-
tada a una porción específica de la
ruta delimitada por los puntos de
ruta dados. Una condición puede,
por ejemplo, ser una restricción de
tiempo (condición de acceso a una
ruta), una restricción de nivel de
vuelo o una violación del TOS.
iobd b '-' "IOBD" date Fecha «inicial» de abandono del
área de estacionamiento: la OBD
indicada en el FPL y actualizada
mediante los mensajes del plan de
vuelo asociados (DLA, CHG, etc.).
Esta es la fecha de referencia utili-
zada para el acceso al plan de
vuelo en la base de datos y es la
única OBD conocida porlas
unidades ATS interesadas.
Nota: La IOBD no resulta afectada
porlos cambios solicitados o noti-
ficados mediante el intercambio de
mensajes ATFM.
iobt b '-' "IOBT" timehhmm Hora inicial de abandono del área
de estacionamiento: la OBD indi-
cada en el FPL y actualizada
mediante mensajes del plan de
vuelo asociados (DLA, CHG, etc.).
Esta es la hora de referencia utili-
zada para el acceso al plan de
vuelo en la base de datos y es la
única OBT conocida porlas
unidades ATS interesadas.
Nota: La IOBT no resulta afectada
porlos cambios solicitados o noti-
ficados mediante el intercambio demensajes ATFM.
lacdr c '-' "BEGIN" "LACDR" { airroute
} '-' "END" "LACDR"Lista de Rutas condicionales
activas.
latsa c '-' "BEGIN" "LATSA" { airspace
} '-' "END" "LATSA"Lista de Zonas de segregación
temporal activas.
lcatsrte c '-' "BEGIN" "LCATSRTE" {
airroute } '-' "END"
"LCATSRTE"Lista de Rutas ATS cerradas.2000R2082 — ES — 15.06.2002 — 001.001 — 108
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
lfirc '-' "BEGIN" "LFIR" 1{ fir ( lacdr |
( lacdr lcatsrte latsa lrar lrca) ) } '-
' "END" "LFIR"Lista de las FIR, incluyendo el
nombre de la región seguido por la
lista de Rutas condicionales dispo-
nibles o las listas de Rutas condi-
cionales disponibles, Rutas ATS
cerradas, Zonas de segregación
temporal activas, Restricciones del
espacio aéreo reducido y Espacios
aéreos de coordinación reducida.
lrar c '-' "BEGIN" "LRAR" { airspace }
'-' "END" "LRAR"Lista de Restricciones del espacio
aéreo reducido.
lrca c '-' "BEGIN" "LRCA" { airspace }
'-' "END" "LRCA"Lista de Zonas de coordinación
reducida.
lstday b '-' "LSTDAY" date Último día de operación de un plan
de vuelo repetitivo. Se utiliza para
indicar el último día real a partir
del cual serán generados los planes
de vuelo desde un RPL (véase
campo valuntil) o el último día de
vigencia de una modificación a un
RPL.
=> Tiene que seruna fecha entr e
VALFROM y VALUNTIL.
mach b '-' "MACH" machnumber[ point ] Númer o de Mach en centésimas de
unidad y opcionalmente el punto en
que se solicita el cambio.
mesvalpe-
riodb '-' "MESVALPERIOD" fulldate-
time fulldatetimePeríodo de validez de un mensaje,
incluyendo las horas dadas.
minlineup b '-' "MINLINEUP" timehhmm Tiempo mínimo para que un vuelo,
que se ha declarado listo para salir,
pase de su posición de espera a
estarvolando.
modifnb b '-' "MODIFNB" 1{ DIGIT }3 Número de modificaciones necesa-
rias para corregir el mensaje inicial.
msgref c '-' "MSGREF" sender recvr
seqnumDatos de referencia para los
mensajes asociados transmitidos
anteriormente.
msgsum c '-' "BEGIN" "MSGSUM" { [arcid]
[adep] [ades] [eobt] [eobd] [orgn]
[days] [valfrom] [valuntil] }
'-' "END" MSGSUM"Contiene un resumen de un
mensaje.
Nota: Tiene que conteneruno o
más* de los campos arcid, adep,
ades, eobt y orgn, pero sin repe-
tirse.
* uno o más de los campos pueden
haberse perdido o desvirtuado en el
mensaje recibido.
msgtxt b '-' "MSGTXT" ICAOmsg Contiene un mensaje ICAO
completo.
msgtyp b '-' "MSGTYP" titleid Contiene el título del mensaje de
referencia o copiado. Puede ser
cualquiertipo de mensaje ADEXP
válido (véase Anexo B).
nav b '-' "NAV" text20 Equipo de navegación significativo,
según el campo 18, NAV/ de
ICAO.
nbarc b '-' "NBARC" 1{ DIGIT }2 Número de aeronaves, si hay más
de una.
nbrfpd b '-' "NBRFPD" 1{ DIGIT }3 Número de datos del plan de vuelo
correspondientes a una interroga-
ción. Tiene que estarcompr endido
entre 0 y 999.
newctot b '-' "NEWCTOT" timehhmm Nueva hora calculada de despegue,
actualizada porel TACT.2000R2082 — ES — 15.06.2002 — 001.001 — 109
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
newend-
timeb '-' "NEWENDTIME" day !
timehhmmNueva hora en la que termina un
período de tiempo.
neweobd b '-' "NEWEOBD" date Nueva fecha estimada de abandono
del área de estacionamiento.
neweobt b '-' "NEWEOBT" timehhmm Nueva hora estimada de abandono
del área de estacionamiento.
newptot b '-' "NEWPTOT" timehhmm Nueva hora provisional de
despegue.
newrte b '-' "NEWRTE" { LIM_CHAR } Nueva ruta entre los mismos aeró-
dromos de salida y llegada que en
el mensaje original.
newstart-
timeb '-' "NEWSTARTTIME" day !
timehhmmNueva hora en la que comienza un
período de tiempo.
oldmsg b '-' "OLDMSG" { CHARACTER } Mensaje original completo, exacta-
mente como se recibió (en el
mismo formato).
opr b '-' "OPR" 1 { LIM_CHAR } Nombre de la compañía u orga-
nismo que opera el vuelo, según el
campo 18, elemento OPR/ deICAO.
orgmsg b '-' "ORGMSG" titleid El título ADEXP de un mensaje
erróneo, como lo recibió el TACT.
orgn b '-' "ORGN" 1{LIM_CHAR}30 Dirección del emisor de un
mensaje.
orgnid b '-' "ORGNID" originatorid Indicativo de un destinatario que ha
emitido un mensaje.
orgrte b '-' "ORGRTE" { LIM_CHAR } Ruta inicial entre los aeródromos
de salida y llegada.
origin c '-' "ORIGIN" networktype | fac |
(networktype fac)Información relativa al emisor de
un mensaje. Puede incluirel tipo
de red utilizada, la dirección en
cuestión o ambos datos.
origindt b '-' "ORIGINDT" datetime Fecha y hora de recepción de un
mensaje inicial porpar te del IFPS.
Nota: No es la hora de cumplimen-
tación del mensaje.
El formato es YYMMDDHHMM.
part c '-' "PART" num lastnum Identificación de la parte del
mensaje identificada porel título,
hora de cumplimentación y período
de validez.
per b '-' "PER" text20 Datos de características de la aero-
nave según el campo 18, PER/ de
ICAO.
position c '-' "POSITION" (adid | ptid)[(to |
sto)] [fl] [cto]Posición de una aeronave definida
por un punto o un aeródromo con
información opcional sobre hora y
nivel de vuelo.
prevarcid b '-' "PREVARCID" aircraftid Indicativo de llamada utilizado
anteriormente.
prevssrcode b '-' "PREVSSRCODE" ALPHA !
4{ '0' | '1' | '2' | '3' | '4' | '5' | '6' | '7'
}4Modo y Código SSR utilizado por
el vuelo inmediatamente anterior al
Modo y Código SSR especificado
en el campo «-SSRCODE».
propfl c '-' "PROPFL" tfl [sfl] Nivel de vuelo propuesto por la
unidad que acepta la transferencia
de un vuelo.
ptot b '-' "PTOT" timehhmm Hora provisional de despegue.
Tiempo de referencia provisional
para una ranura ATFM.2000R2082 — ES — 15.06.2002 — 001.001 — 110
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
qrorgn b '-' "QRORGN" originatorid Indicativo del emisor de una inte-
rrogación.
ralt b '-' "RALT" 1 {LIM_CHAR} 40 Indicativo de aeródromo/s alterna-
tivo/s en ruta.
rate b '-' "RATE" ((("C" | "D")!
2{DIGIT}2 ) | "ZZZ" )Velocidad de cambio: velocidad de
ascenso o descenso asignada a una
aeronave, expresada en cientos de
pies porminuto.
=> Tiene que ser«C» par a una
velocidad de ascenso, o «D» para
una velocidad de descenso, seguido
porun númer o de dos dígitos que
indica la velocidad asignada en
cientos de pies porminuto. Alter -
nativamente puede utilizarse elvalor«ZZZ» par a indicarque no
hay asignación de velocidad de
ascenso o descenso.
ratepdlst c '-' "BEGIN" "RATEPDLST" 1
{rateperiod} '-' "END"
"RATEPDLST"Lista de los períodos de tiempo y
sus respectivas velocidades de flujo
para una condición ATFM.
reason b '-' "REASON" 4{ALPHA}12 Motivo del rechazo de un mensaje
o de la cancelación de una ranura
porpar te del TACT.
La información de apoyo del
mensaje depende de su contexto.
ref c '-' "REF" refid ptid brng distnc Punto de una ruta que se define en
términos de rumbo magnético y
distancia desde otro punto y está
designado porel indicativo REFxx.
refdata c '-' "REFDATA" [sender] [recvr]
seqnumDatos de referencia para mensajes
en proceso de transmisión.
reg b '-' "REG" 1{ LIM_CHAR }7 Marcas de matriculación según el
campo 18, REG/ de ICAO.
regloc b '-' "REGLOC" 1 {LIM_CHAR}
15Lugar de referencia para una
normativa ATFM.
regul b '-' "REGUL" regulid Identificación de una normativa
aplicable a un vuelo.
rejctot b '-' "REJCTOT" timehhmm Hora calculada de despegue recha-
zada: respuesta negativa a una
propuesta de mejora de ranura.
release b '-' "RELEASE" 1{ALPHA}1 Indicación de que un vuelo es
transferido del controlador que
realiza transferencia al controlador
receptor.
C = autorizado para ascender
D = autorizado para descender
T = autorizado para virar
F = autorizado para todas las
maniobras
rename c '-' "RENAME" renid ptid Indicación de un nuevo nombre,
temporal, dado a un «punto signifi-
cativo» que aparece más de una
vez en la descripción de la ruta
para evitar confusión. Este nuevo
nombre temporal se utiliza exclusi-
vamente con el propósito de clari-
ficar la representación de la ruta y
no implica una modificación real
de la verdadera identificación del
punto.
respby b '-' "RESPBY" timehhmm Respuesta a: hora a la que debe
responderse a una Propuesta de
Mejora a una ranura.2000R2082 — ES — 15.06.2002 — 001.001 — 111
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
rfl b '-' "RFL" flightlevel [point] Nivel de vuelo solicitado (número
del nivel de vuelo en decenas de
metros o cientos de pies) y opcio-
nalmente el punto en el que se
requiere un cambio de RFL.
rfp b '-' "RFP" "Q" ( '1' | '2' | '3' | '4' | '5'
| '6' | '7' | '8' | '9' )Indicadordel plan de vuelo de
sustitución (RFP)
Tiene que ser«Q» seguida de un
dígito (1 - 9).
rfpdlist c '-' "BEGIN" "RFPDLIST" {
rfpdlong } '-' "END" "RFPDLIST"Lista de RFPD completos corres-
pondiente a las palabras clave de la
base de datos en una interrogación.
rfpdslist c '-' "BEGIN" "RFPDSLIST" {
rfpdsum } '-' "END"
"RFPDSLIST"Lista de rfpdsum (información
resumida RFPD) correspondiente a
las palabras clave de la base de
datos en una interrogación.
rif b '-' "RIF 4{LIM_CHAR} Ruta revisada en espera de autori-
zación de vuelo que termina con el
indicativo ICAO del nuevo aeró-
dromo de destino.
rmk b '-' "RMK" 1{ LIM_CHAR } Comentarios en lenguaje claro,
según el campo 18 RMK/ de
ICAO.
route b '-' "ROUTE" {LIM_CHAR} Información completa del campo
15 de ICAO que contiene velo-
cidad, RFL y ruta (conforme a la
sintaxis dada en la Ref. 4).
rrtefrom c '-' "RRTEFROM" tfvid refloc
flowlst flblockDescripción de un flujo de tráfico
que va a ser redistribuido.
rrteref b '-' "RRTEREF" rrteid Referencia de redistribución.rrteto c '-' "RRTETO" tfvid refloc flowlst
flblockDescripción de un flujo de tráfico
aéreo hacia el que el tráfico va a
ser redistribuido.
rtepts c '-' "BEGIN" "RTEPTS" { pt [ad]}
'-' "END" "RTEPTS"Lista de puntos de ruta. También
puede contenerel indicativo de un
aeródromo.
rvr b '-' "RVR" 1{ DIGIT }3 Distancia de visión en pista (RVR).
Mínima requerida en caso de que
existan condiciones meteorológicas
especiales. Expresada en metros.
rvrcond c '-' "BEGIN" "RVRCOND" 1
{rvrperiod} '-' "END"
"RVRCOND"Lista de períodos de tiempo y sus
límites RVR aplicables.
rvrperiod c '-' "RVRPERIOD" from until
rvrlimitPeríodo de tiempo dentro del cual
es aplicable el límite RVR especi-
ficado.
sectorb '-' "SECTOR" 1{ ALPHANUM }8 Identificación de un sector ATC.sel b '-' "SEL" 4{ ALPHA }5 Código SELCAL, según el campo
18, elemento «SEL/» de ICAO.
sendto c '-' "BEGIN" "SENDTO" {unit} '-'
"END" "SENDTO"Lista de unidades de navegación
aérea destinatarias de un mensaje.
seqpt b '-' "SEQPT" ssrequipment Equipo de vigilancia, según el
Campo 10 de ICAO.
sid b '-' "SID" point ! 1{DIGIT}1 !
0{ALPHA}1Identificadorde un pr ocedimiento
de salida normalizado por instru-
mentos.
speed b '-' "SPEED" spd [ point ] Velocidad verdadera (en kilómetros
porhor a o nudos) y, opcional-
mente, el punto en el que se soli-
cita un cambio de velocidad.2000R2082 — ES — 15.06.2002 — 001.001 — 112
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
spla b '-' "SPLA" 1{ LIM_CHAR }50 Color de las marcas de una aero-
nave, según en campo 19, elemento
«A/» de ICAO.
spladdrc '-' "BEGIN" "SPLADDR" { fac }
'-' "END" "SPLADDR"Datos de contacto donde se puede
obtener información suplementaria
del plan de vuelo.
splc b '-' "SPLC" 1{ LIM_CHAR }50 Nombre del piloto al mando, según
el campo 19, elemento «C/» de
ICAO.
spldcap b '-' "SPLDCAP" 1{ DIGIT }3 Capacidad total de los botes según
el Campo 19, elemento «D/» de
ICAO.
spldcol b '-' "SPLDCOL" 1{ LIM_CHAR
}50Colorde los botes, según Campo
19, elemento «D/» de ICAO.
spldcov b '-' "SPLDCOV" ('T' | 'F') Botes: indicación de si están
cubiertos, según el Campo 19,
elemento «D/» de ICAO.
T = Verdadero (=> «C» en ICAO)
F = Falso, no cubierto.
spldnb b '-' "SPLDNB" 1{ DIGIT }2 Botes: número, según el Campo 19,
elemento «D/» de ICAO.
sple b '-' "SPLE" timehhmm_elapsed Autonomía de combustible, según
el Campo 19, elemento «E/» de
ICAO.
splj b '-' "SPLJ" lifejackets Chalecos salvavidas, según el
Campo 19, elemento «J/» de ICAO.
spln b '-' "SPLN" 1{ LIM_CHAR } Cualquier otro equipo de supervi-
vencia y comentarios útiles, según
el Campo 19, elemento «N/» de
ICAO.
splp b '-' "SPLP" 1{DIGIT}3 Número de personas a bordo, según
el Campo 19, «P/» de ICAO.
splr b '-' "SPLR" emergradio Equipo de radio de emergencia,
según el Campo 19, elemento «R/»
de ICAO.
spls b '-' "SPLS" survivaleqpt Equipo de supervivencia, según el
Campo 19, elemento «S/» de
ICAO.
src b '-' "SRC" ("RPL" | "FPL" | "AFIL"
| "MFS" | "FNM" | "AFP" | "RQP"
| "RQS" | NIL )Indicación de la fuente de datos. El
contenido depende del campo
TITLE.
ssrcode b '-' "SSRCODE" ('A' ! 4{ '0' | '1' |
'2' | '3' | '4' | '5' | '6' | '7' }4 | "REQ"
)Puede ser
— modo y código SSR, según el
Campo 7, elementos b y c de
ICAO.
O
— las letras «REQ» que significan
que se solicita el código.
starb '-' "STAR" point ! 1{DIGIT}1 !
0{ALPHA}1Identificación de un procedimiento
de llegada normalizado.
starttime b '-' "STARTTIME" day !
timehhmmHora a la que comienza un período
de tiempo.2000R2082 — ES — 15.06.2002 — 001.001 — 113
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
stay c '-' "STAY" stayident time ((adid
adid) | (ptid ptid) (adid | ptid) |
(ptid adid)) [ptspeed] [ptrfl]Indicación en la ruta de vuelo de
un período de «actividad especial»:
la aeronave va a «permanecer» en
la zona definida porlos puntos o
aeródromos especificados durante
el lapso de tiempo indicado, p. ej.
entrenamiento, reaprovisionamiento
a mitad de vuelo, misión fotográ-
fica, etc.
NOTA: El orden en el que
aparecen los puntos o aeródromos
es significativo.
stayinfo c '-' "STAYINFO" stayident remark Información relativa al tipo de
actividad (entrenamiento, misión
fotográfica, etc.) que va a realizarse
durante el período de tiempo de
«permanencia» en la ruta de un
vuelo.
sts b '-' "STS" ( "PROTECTED" |
flightplanstatus | 1{LIM_CHAR} )Motivo para un tratamiento espe-
cial, según el Campo 18, elemento
STS/ de ICAO. Puede ser
«PROTECTED» para indicar un
procesamiento delicado o una de
las etiquetas EMER, HOSP, etc. o
texto libre.
taxitime b '-' "TAXITIME" timehhmm Diferencia en tiempo entre la «hora
de abandono de la zona de estacio-
namiento» y la «hora de
despegue». Pueden sertiempos
reales o estimados, según el
contexto.
tfcvol b '-' "TFCVOL" 1 {ALPHANUM}
15Identificación de un «volumen de
tráfico».
tfv c '-' "TFCVOL" tfvid refloc flowlst
flblockDescripción de un volumen de
tráfico.
title b '-' "TITLE" titleid Título de un mensaje.ttleet b '-' "TTLEET" timehhmm_elapsed Tiempo total transcurrido estimado
en horas y minutos.
typz b '-' "TYPZ" text20 Tipo de aeronave cuando no existe
código ICAO.
unit c '-' "UNIT" unitid [addrinfo] Información relativa a una unidad
de navegación «aérea»: una unidad
ATC, un operador de aeronaves o
un emisorde un plan de vuelo.
Contiene la identificación de la
unidad, seguida opcionalmente de
su dirección.
valfrom b '-' "VALFROM" date Primera fecha a partir de la cual se
programa la operación de un vuelo
(año, mes, día).
valfromk b '-' "VALFROMK" ( date |
datewldcrd )Primera fecha a partir de la cual se
programa la operación de un vuelo,
utilizada como clave de la base de
datos en una interrogación; puede
contenercomodines. Tiene que ser
una fecha válida o una combina-
ción válida de fecha y comodines.
valfromold b '-' "VALFROMOLD" date La fecha «valfrom»«previa». Utili-
zada como palabra clave de base de
datos. Si se corrige la fecha, el
nuevo valorse dar á en
«VALFROM».
validitydate b '-' "VALIDITYDATE" date Fecha de validez.2000R2082 — ES — 15.06.2002 — 001.001 — 114
▼B
Campos
primarios
ADEXPClase Sintaxis Semántica
valuntil b '-' "VALUNTIL" date Última fecha a partir de la cual está
programada la operación del vuelo
(año, mes, día).
valuntilk b '-' "VALUNTILK" ( date |
datewldcrd )Última fecha a partir de la cual está
programada la operación del vuelo,
utilizada como palabra clave de
base de datos en una interrogación;
puede contenercomodines.
Tiene que seruna fecha válida o
una combinación válida de fecha y
comodines.
valuntilold b '-' "VALUNTILOLD" date La fecha «valuntil»«previa». Utili-
zada como clave de la base de
datos. Cuando se corrige la fecha,
el nuevo valorse dar á en
«VALUNTIL».
wktrc b '-' "WKTRC" waketurbcat Categoría de turbulencia de estela.
A.4.SubcamposADEXP
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
addrinfo C '-' "ADDRINFO"
networktype facDirección. Unit
adid b '-' "ADID" ICAOae-
rodrome | 'ZZZZ'Indicativo de un
aeródromo. Puede
contenerel indicador
de situación ICAO o
los caracteres
«ZZZZ» cuando no
se ha asignado
ningún indicadorde
situación.ad
position
stay
airroute c '-' "AIRROUTE"
[num] refatsrte
flblock valperiod
[remark]Descripción total o
parcial de una ruta
ATS durante un
período especificado.lacdr
lcatsrte
airspace c '-' "AIRSPACE"
[num] airspdes
flblock valperiod
respunit [remark]Descripción total o
parcial de un espacio
aéreo durante un
período especificado.latsa
lrar
lrca
airspdes b '-' "AIRSPDES" 3 {
ALPHANUM }12Designa un espacio
aéreo distinto de una
ruta ATS.entrydata airspace
brng b '-' "BRNG" refbea-
ringRumbo desde una
ayuda a la navega-
ción a un punto en
grados magnéticos.ref
condition b '-' "CONDITION" 2
{ALPHA} 20Tipo de condición o
restricción, p. ej.
restricción de TOS,
FL.ignore
crfl1 b '-' "CRFL1" fligh-
tlevelEl límite inferior de
una banda de nivel de
vuelo dentro de la
cual se solicita un
ascenso de crucero.crsclimb ptcrsclimb2000R2082 — ES — 15.06.2002 — 001.001 — 115
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
crfl2 b '-' "CRFL2" (fligh-
tlevel | "PLUS")Límite superior de
una banda de nivel de
vuelo dentro de la
cual se solicita un
ascenso de crucero.
«PLUS» si el límite
superior no se
conoce.crsclimb ptcrsclimb
crmach b '-' "CRMACH"
machnumberEl número de Mach
mantenido durante un
ascenso de crucero.crsclimb ptcrsclimb
crspeed b '-' "CRSPEED" spd La velocidad que
debe mantenerse
durante un ascenso
de crucero.crsclimb ptcrsclimb
cto b '-' "CTO" timehhmm Hora calculada de
paso sobre la vertical
de un punto.ad
positionpt
distnc b '-' "DISTNC" 1{
DIGIT }3Distancia a un punto
desde una ayuda de
navegación en millas
náuticas. Puede ser
de 1 a 3 dígitos,
posiblemente con
ceros delante.ref
efl b '-' "EFL" flightlevel Nivel de vuelo esti-
mado.Reservado
para uso
futuro.
endreg b '-' "ENDREG" day!ti-
mehhmmLa hora a la que
finaliza una norma-
tiva ATFM.exccond
regulation
eqpt b '-' "EQPT" eqptcode !
'/' ! eqptstatusCódigo de la capa-
cidad de equipo
seguido de un valor
que refleja el estado
actual de la capa-
cidadeqcst
eto b '-' "ETO" date !
timehhmm ! secondsEstimación del paso
porla ver tical de un
punto, en año, mes,
día, horas, minutos y
segundos.ad
afildata
estdata
positionpt
exccond c '-' "EXCCOND"
regnum refloc
regreason startreg
endreg [flblock]
[rvrlimit] [remark]Una «condición
excepcional» surgida
en el contexto
ATFM, p. ej. niebla
en un aeródromo.reglist
fac b '-' "FAC" 1{
LIM_CHAR }30Datos de dirección. addr
cassaddr
extaddr
origin
spladdraddrinfo
recvr
sender
firb '-' "FIR" 7{ ALPHA
}7Designa un FIR o un
UIR.lfir
fl b '-' " FL" flightlevel Campo genérico de
nivel de vuelo. Puede
serun «SFL»,
«EFL», «CFL»,
«RFL», etc. depen-
diendo del contexto.ad
afildata
cfl
entrydata
estdata
flband
positionflblock
pt2000R2082 — ES — 15.06.2002 — 001.001 — 116
▼M1
▼B
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
flblock c '-' "FLBLOCK" fl fl Bloque de niveles de
vuelo que definen un
espacio aéreo verti-
calmente, incluyendo
los niveles de vuelo
especificados. Todo
bloque definido por
encima o pordebajo
de un nivel de vuelo
será expresado como
del nivel de vuelo
000 al nivel de vuelo
especificado o desde
el nivel de vuelo
especificado al nivel
de vuelo 999, respec-
tivamente.ad
rrteto
rrtefrom
tfvairspace
airroute
pt
regulation
exccond
flow c '-' "FLOW" frompos
[via1] [via2] topos
[via3] [via4] flowroleDescripción de un
«flujo» que incluye la
zona de origen,
opcionalmente las
rutas o puntos a
sobrevolar desde la
zona de origen, la
zona de destino y,
opcionalmente, las
rutas o puntos a
sobrevolar hasta la
zona de destino.flowlst
flowlst c '-' "BEGIN"
"FLOWLST" 1
{flow} '-' "END"
"FLOWLST"Lista de flujos de
tráfico.rrteto
rrtefrom
tfv
flowrate b '-' "FLOWRATE"
3{LIM_CHAR}7Velocidad impuesta
poruna nor mativa
ATFM.rateperiod
flowrole b '-' "FLOWROLE"
'EX' | 'IE' | 'EM' | 'IN'Indicación del
«papel» asignado a
un flujo.
EX = excluido
IE = incluido exento
EM = exento
IN = incluidoflow
from b '-' "FROM" day!ti-
mehhmmHora de comienzo de
un período de tiempo.rvrperiod rateperiod
frompos b '-' "FROMPOS" 1
{ALPHANUM} 15Una posición desde
la que comienza una
ruta, una porción de
ruta, un «itinerario» o
un flujo. Puede ser
una región, un aeró-
dromo o un punto
significativo.flow
geoid b '-' "GEOID" geoname Identificadorde un
punto geográfico
«GEO» seguido deun número de orden.
(Ejemplo:
«GEO12»).geo
ifpdlong c '-' "BEGIN"
"IFPDLONG"
adexpmsg '-' "END"
"IFPDLONG"Información completa
relativa a un plan de
vuelo individual.ifpdlist2000R2082 — ES — 15.06.2002 — 001.001 — 117
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
ifpdsum c '-' "IFPDSUM" arcid
adep ades eobt orgnInformación resumida
relativa a un plan de
vuelo individual.
Contiene los campos
arcid, adep, ades,
eobt y orgn.ifpdslist
lastnum b '-' "LASTNUM"
3{DIGIT}3Un número de tres
dígitos que indica el
fin de una secuencia.
lattd b '-' "LATTD" latitude-
long ! latitudesideLatitud en grados,
minutos, segundos y
dirección (Norte o
Sur).eetlat
geo
longtd b '-' "LONGTD" longi-
tudelong ! longitude-
sideLongitud en grados,
minutos, segundos y
dirección (Este u
Oeste).eetlong
geo
networkty-
peb '-'
"NETWORKTYPE"
2{ALPHANUM}10Indicación del tipo de
red utilizada en el
intercambio de un
mensaje.origin addrinfo
num b '-' "NUM"
3{DIGIT}3Un número de tres
dígitos.extaddr
partairspace
airroute
penrate b '-' "PENRATE"
3{LIM_CHAR}7La velocidad
pendiente, utilizada
porATFM.rateperiod
postproctxt b '-' "POSTPROCTXT"
adexpmsgContiene un mensaje
ADEXP completo
después de habersido
procesado.adexptxt
preproctxt b '-' "PREPROCTXT"
adexpmsgContiene un mensaje
ADEXP completo
antes de habersido
procesado (es decir,
tal como se ha reci-
bido).adexptxt
pt c '-' "PT" ptid [(fl |
flblock)] [sfl] [eto]
[to] [cto] [sto] [ptrte]
[ptstay] [ptrfl]
[ptrulchg] [(ptspeed |
ptmach)] [ptcrsclimb]Punto a lo largo de
una ruta.=> Contiene
un punto de identifi-
cación y, opcional-
mente:
— un nivel de vuelo
o un bloque de nivel
de vuelo
— un nivel de vuelo
complementario
— una(s) referen-
cia(s) de tiempo
— un ascenso de
crucero
— una indicación de
ruta
— una indicación de
un período de «acti-
vidad especial», p. ej.
que el vuelo va a
«permanecer» en la
zona durante un
período de tiempo.
Modificación en:
— RFL, normas de
vuelo, velocidad/no
de Mach.rtepts2000R2082 — ES — 15.06.2002 — 001.001 — 118
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
ptcrsclimb c '-' "PTCRSCLIMB"
(crspeed | crmach)
crfl1 crfl2Indicación de un
ascenso de crucero en
la ruta de vuelo, que
incluye la velocidad
oe lnode Mach
seguido porlos dos
niveles que indican la
banda de niveles de
vuelo que estará
ocupada durante el
ascenso. El nivel
superior puede
reeemplazarse por
«PLUS» cuando no
se conoce.pt
ptfltrul b '-' "PTFLTRUL"
'VFR' | 'IFR'Indicación de las
normas de vuelo que
son aplicables en el
punto en cuestión.entrydata
ptid b '-' "PTID" point Identificación de un
punto: indicativo
codificado o un
nombre dado artifi-
cialmente (GEOxx,
REFxx o RENxx).afildata
cfl
coordata
crsclimb
entrydata
estdata
ignore
position
ref
rename
staypt
ptmach b '-' "PTMACH" mach-
numberNúmero de Mach, en
centésimas de unidad,asociado a un punto
de una ruta.ad
entrydatapt
ptmilrul b '-' "PTMILRUL"
'OAT' | 'GAT'Indicación de las
normas de vuelo
«militar» que son
aplicables en el punto
en cuestión.entrydata
ptrfl b '-' "PTRFL" fligh-
tlevelNivel de vuelo solici-
tado, asociado a un
punto de la ruta.ad
entrydatapt
ptrte b '-' "PTRTE"
2{LIM_CHAR}Ruta del vuelo a
partir del punto indi-
cado. Puede serla
ruta completa hasta el
aeródromo de destino
o simplemente el
elemento de ruta
hasta el punto
siguiente.pt
ptrulchg b '-' "PTRULCHG"
rulechg | flightty-
pechg | rulechg
flighttypechgIndicación de un
cambio en las
«normas de vuelo»
(VFR/IFR) o en el
«tipo de vuelo»
(OAT/GAT) o en
ambos y asociado a
un punto de la ruta.ad pt
ptspeed b '-' "PTSPEED" spd Velocidad verdadera
del aire (en kilóme-
tros por hora o
nudos) asociada a un
punto de la ruta.ad
entrydatapt2000R2082 — ES — 15.06.2002 — 001.001 — 119
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
ptstay b '-' "PTSTAY" stayi-
dentifiertimehhmmIndica, en la descrip-
ción de la ruta de
vuelo, un período de
«actividad especial»
en el que el avión va
a «permanecer» en la
zona definida durante
el lapso de tiempo
dado, p. ej. entrena-
miento, reaprovisio-
namiento a mitad de
vuelo, etc.ad pt
rateperiod c '-' "RATEPERIOD"
from until flowrate
penratePeríodo de tiempo
durante el cual las
velocidades de flujo
dadas son aplicables
para una normativa
ATFM.ratepdlst regcond
recvr b '-' "RECVR" fac Receptor del mensaje
al que se hace refe-
rencia.msgref
refdata
refatsrte b '-' "REFATSRTE"
atsroute point
[country] point
[country]Indicativo de ruta
ATS e identificadores
de los puntos inicial
y final. Los puntos
enumerados pueden
seridentificador es
ICAO o puntos
GEOxx, RENxx o
REFxx designados
artificialmente.
Opcionalmente puede
incluirse un identifi-
cadordel país en el
que está situado el
punto. El punto final
tiene que sercohe-
rente con la informa-
ción de la ruta.airroute
refid b '-' "REFID" refname Identificación de un
punto de referencia:
«REF» seguido de un
número de secuencia
(ejemplo: «REF02»).ref
refloc b '-' "REFLOC"
1{LIM_CHAR}15Localización de refe-
rencia de una norma-
tiva ATFM.rrteto
rrtefrom
tfvexccond
regulation
regcond c '-' "BEGIN"
"REGCOND" {rate-
period} '-' "END"
"REGCOND"Lista de los períodos
de tiempo y sus
respectivas veloci-
dades de flujo para
una normativa parti-
cular.regulation
regdesc b '-' "REGDESC"
1{LIM_CHAR}Descripción de una
normativa ATFM.regulation
regid b '-' "REGID" regulid Identificación de una
«Normativa» de
gestión de flujo.regulation
reglist c '-' "BEGIN"
"REGLIST" regula-
tion [exccond] '-'
"END" "REGLIST"Lista de «Norma-
tivas» a efectos de
gestionarel flujo.fmplist2000R2082 — ES — 15.06.2002 — 001.001 — 120
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
regnum b '-' "REGNUM"
3{DIGIT}3 ! "/" !
2{DIGIT}2Número de referencia
para una «Norma-
tiva» ATFM. Propor-
ciona una referencia
única seguida del
período de validez.exccond
regulation
regreason b '-' "REGREASON" 4
{ALPHA} 12Motivo de una
Normativa ATFM.exccond
regulation
regulation c '-' "REGULATION"
regnum regid regdesc
refloc startreg endreg
[flblock] [remark]
[tfvid] [regreason]
[regcond]«Normativa»
impuesta a efectos de
gestionarel flujo.reglist
remark b '-' "REMARK"
1{LIM_CHAR}Comentario sobre el
elemento. Este campo
forma parte de la
descripción del
elemento.stayinfo airspace
airroute
exccond
regulation
renid b '-' "RENID" renameid Identificador de un
punto que se repite
en la descripción de
la ruta.rename
respunit b '-' "RESPUNIT"
12{ALPHA}12Unidad ATC respon-
sable.airspace
rfpdlong c '-' "BEGIN"
"RFPDLONG"
{adexpmsg} '-'
"END"
"RFPDLONG"Información completa
relativa a un plan de
vuelo repetitivo.rfpdlist
rfpdsum c '-' "RFPDSUM" arcid
adep ades eobt orgn
days valfrom valuntilResumen de la infor-
mación relativa a un
plan de vuelo repeti-
tivo. Contiene los
campos arcid, adep,
ades, eobt, orgn,
days, valfrom y
valuntil.rfpdslist
rvrlimit b '-' "RVRLIMIT"
3{DIGIT}3Alcance visual en
pista: mínimo reque-
rido en caso de que
existan condiciones
meteorológicas espe-
ciales. Expresada en
metros.rvrperiod exccond
senderb '-' "SENDER" fac El emisor del
mensaje de refe-
rencia.msgref
refdata
seqnum b '-' "SEQNUM"
3{DIGIT}3Número secuencial
de un mensaje
enviado (número de
tres dígitos único
para la combinación
remitente/destina-
tario).msgref
refdata2000R2082 — ES — 15.06.2002 — 001.001 — 121
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
sfl b '-' SFL flightlevel !
('A'|'B')Nivel de vuelo
complementario. El
nivel de vuelo al
cual, porencima opordebajo del cual
un vuelo ha sido o
será coordinado para
pasarporun punto.
Consta de un nivel de
vuelo y una condi-
ción de paso («A» si
la aeronave pasa por
el punto en ese nivel
o porencima del
mismo o «B» si la
aeronave pasa por el
punto en ese nivel o
pordebajo del
mismo).coordata
estdata
propflpt
startreg b '-' "STARTREG"
day!timehhmmHora a la que una
Normativa ATFM
entra en vigor.exccond
regulation
statid b '-' "STATID" coorsta-
tusidentIndicadordel estado
de coordinación de
un vuelo.cstat
statreason b '-' "STATREASON"
coorstatusreasonMotivo de un cambio
en el estado de coor-
dinación de un vuelo.cstat
stayident b '-' "STAYIDENT"
stayidentifierIdentificación de un
período de «actividad
especial» o de una
«permanencia» en
una ruta de vuelo.stay
stayinfo
sto b '-' "STO" timehhmm
! secondsCampo «hora» gené-
rico que puede
contenerla hor a de
llegada a un punto o
aeródromo. El tiempo
puede sercalculado,
estimado o real
dependiendo del
contexto.ad
coordata
positionpt
tfl b '-' "TFL" flightlevel Nivel de vuelo de
transferencia. Nivel
de vuelo al cual ha
sido o será coordi-
nado un vuelo para
pasarporun punto
(número de nivel de
vuelo) si se encuentra
en el nivel de vuelo,
o el nivel de vuelo
autorizado al cual se
dirige si asciende o
desciende en los alre-
dedores del punto.coordata
propfl
tfvid b '-' "TFVID"
1{ALPHANUM}15Identificación de un
«volumen de tráfico»rrteto
rrtefrom
tfvregulation
time b '-' "TIME" timehhmm Indicación de tiempo.
Puede serun tiempo
real o un período de
tiempo, dependiendo
del contexto del
mensaje.stay2000R2082 — ES — 15.06.2002 — 001.001 — 122
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
to b '-' "TO" timehhmm «Time Over/Off».
Campo genérico que
puede contenerla
hora de llegada a un
punto o aeródromo.
El tiempo puede ser
estimado, calculado o
real dependiendo del
contexto.position
coordatapt
topos b '-' "TOPOS" 1
{ALPHANUM} 15Posición a la que se
extiende una ruta,
una porción de ruta,
un «itinerario» o un
flujo. Puede seruna
región, un aeródromo
o un punto significa-
tivo.flow
unitid b '-' "UNITID" 2{
ALPHANUM}10Identificación de una
Unidad de navega-
ción aérea, p. ej. una
unidad ATC, un
operador de aero-
naves o un emisorde
planes de vuelo.unit
until b '-' "UNTIL" day!ti-
mehhmmHora en que termina
un período de tiempo.rvrperiod rateperiod
valperiod b '-' "VALPERIOD"
fulldatetime fulldate-
timePeríodo de validez,
incluyendo las horas
mencionadas.airroute
airspace
via1 b '-' "VIA1" 1
{ALPHANUM} 15Un punto, una ruta
ATS o un espacio
aéreo que figura o
debe figurar en la
ruta de vuelo. Si debe
indicarse más de un
elemento este campo
contendrá el primer
elemento de la
secuencia.flow
via2 b '-' "VIA2" 1
{ALPHANUM} 15Un punto, una ruta
ATS o un espacio
aéreo que figura o
debe figurar en la
ruta de vuelo. Si debe
indicarse más de un
elemento, este campo
contendrá el segundo
elemento de la
secuencia.flow
via3 b '-' "VIA3" 1
{ALPHANUM} 15Un punto, una ruta
ATS o un espacio
aéreo que figura o
debe figurar en la
ruta de vuelo. Si debe
indicarse más de un
elemento, este campo
contendrá el tercer
elemento de la
secuencia.flow2000R2082 — ES — 15.06.2002 — 001.001 — 123
▼B
Subcampo Clase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
via4 b '-' "VIA4" 1
{ALPHANUM} 15Un punto, una ruta
ATS o un espacio
aéreo que figura o
debe figurar en la
ruta de vuelo. Si debe
indicarse más de un
elemento, este campo
contendrá el cuarto
elemento de la
secuencia.flow2000R2082 — ES — 15.06.2002 — 001.001 — 124
▼B
ANEXO B (Normativo)
ÍNDICECENTRALDETÍTULOSDEMENSAJESADEXP
Título DefiniciónIntroducido en la
sección
ABI Mensaje de información de límite de avance E.3
ACK Mensaje de acuse de recibo E.1
ACP Mensaje de aceptación E.5
ACT Mensaje de activación E.3
AUP Mensaje de plan de utilización del espacio aéreo E.4
BFD Mensaje de datos de vuelo básico E.5
CDN Mensaje de coordinación E.3
CFD Mensaje de modificación de datos de vuelo E.5
CNLCOND Mensaje de cancelación de condición excepcional ATFM E.2.3
CNLREG Mensaje de cancelación de normativa ATFM E.2.3
COD Mensaje de asignación de código SSR E.3
COF Mensaje de cambio de frecuencia E.3
CRAM Mensaje de disponibilidad de ruta condicional E.4
DES Mensaje de suspensión E.2.2
ERR Mensaje de error E.2.2
EXCOND Mensaje de notificación de condición excepcional ATFM E.2.3
FCM Mensaje de confirmación de vuelo E.2.2
FLS Mensaje de suspensión de vuelo E.2.2
FSA Mensaje de activación del primer sistema E.2.3
HOP Mensaje de propuesta de transferencia E.3IACH Mensaje de modificación ATC individual E.1
IAFP Mensaje de propuesta de plan de vuelo ATC individual E.1
IAPL Mensaje de plan de vuelo ATC individual E.1
IARR Mensaje de llegada individual E.1
ICHG Mensaje de modificación individual E.1
ICNL Mensaje de cancelación individual E.1
IDEP Mensaje de salida individual E.1
IDLA Mensaje de retraso individual E.1
IFPL Mensaje de plan de vuelo individual E.1
INF Mensaje de información E.3
IRPL Mensaje de plan de vuelo repetitivo individual E.1
IRQS Mensaje de solicitud de plan de vuelo individual comple-
mentarioE.1
ISPL Mensaje de plan de vuelo individual complementario E.1
LAM Mensaje de acuse de recibo lógico E.3, E.5
LRM Mensaje de rechazo lógico E.3
MAC Mensaje de revocación de coordinación E.3
MAN Mensaje de intento de procesamiento manual E.1
MAS Mensaje de asunción manual de comunicaciones E.3
MODCOND Mensaje de modificación de condición excepcional ATFM E.2.3
MODREG Mensaje de modificación de normativa ATFM E.2.3MRA Mensaje de activación de ruta obligatoria E.2.3
MRCNL Mensaje de cancelación de ruta obligatoria E.2.3
MRMOD Mensaje de modificación de ruta obligatoria E.2.3
NEWREG Mensaje de notificación de nueva normativa ATFM E.2.32000R2082 — ES — 15.06.2002 — 001.001 — 125
▼B
Título DefiniciónIntroducido en la
sección
NTA Mensaje de no aceptación de tráfico E.2.3
NTACNL Mensaje de cancelación de no aceptación de tráfico E.2.3
NTAMOD Mensaje de modificación de no aceptación de tráfico E.2.3
OLRA Mensaje de activación de ruta fuera de carga E.2.3
OLRCNL Mensaje de cancelación de ruta fuera de carga E.2.3OLRMOD Mensaje de modificación de ruta fuera de carga E.2.3
PAC Mensaje de activación preliminar E.3
RAP Mensaje de referencia a propuesta de activación E.3
RCHG Mensaje de modificación de datos de plan de vuelo repeti-
tivoE.1
RCNL Mensaje de cancelación de datos de plan de vuelo repetitivo E.1
RDY Mensaje listo E.2.2
REJ Mensaje de rechazo E.1
REV Mensaje de revisión E.3
RJC Mensaje de rechazo de coordinación E.5
RJT Mensaje de rechazo de redistribución E.2.2
ROF Mensaje de solicitud en frecuencia E.3
RRP Mensaje de propuesta de redistribución E.2.2
RRV Mensaje de referencia a propuesta de revisión E.3
SAM Mensaje de adjudicación de ranura E.2.2
SBY Mensaje de puesta en espera E.3
SDM Mensaje de datos complementarios E.3
SIP Mensaje de propuesta de mejora de ranura E.2.2
SLC Mensaje de cancelación de solicitud de ranura E.2.2
SMM Mensaje de pérdida de ranura E.2.2
SPA Mensaje de aceptación de propuesta de ranura E.2.2
SRJ Mensaje de rechazo de propuesta de ranura E.2.2
SRM Mensaje de revisión de ranura E.2.2SRR Mensaje de solicitud de revisión de ranura E.2.2
TIM Mensaje de iniciación de transferencia E.3
UUP Mensaje de actualización de plan de utilización del espacio
aéreoE.4
XAP Mensaje de propuesta alternativa de paso E.5
XCM Mensaje de cancelación de paso E.5
XIN Mensaje de notificación de intención de paso E.5
XRQ Mensaje de solicitud de paso E.52000R2082 — ES — 15.06.2002 — 001.001 — 126
▼B
ANEXO C (Normativo)
ÍNDICECENTRALDETÍTULOSDEMENSAJERESERVADOS
C.1.Introducción
El presente Anexo contiene un índice central de títulos de mensajes
reservados cuyo uso en ADEXP aún no ha sido definido. Su inclusión
en este Anexo indica que se ha previsto su utilización en el futuro o
que están en uso actualmente, pero su utilización está limitada a sistemas
locales.
C.2.Objeto
El objeto de proporcionar una lista de títulos cuya utilización aún no ha
sido adoptada oficialmente en la presente Norma ADEXP es para evitar,
en la medida de lo posible, la aparición de redundancias cuando se nece-
site un nuevo título para un fin determinado o la creación de títulos que
ya están siendo utilizados en un sistema local.
C.3.Títulosdemensajesreservados
Título reservado Tipo de mensaje Reservado por
ACTARR Mensaje de activación para una llegada FRANCIA
ACTDEP Mensaje de activación para una salida FRANCIA
ADMFPL Mensaje de plan de vuelo ADMAR2000 ALEMANIA
ADMFPT Mensaje de fin de plan de vuelo ADMAR2000 ALEMANIAADMFPU Mensaje de actualización de plan de vuelo
ADMAR2000ALEMANIA
ANM Mensaje de notificación ATFM CFMU
ANSWERCT Mensaje de respuesta (Terminal Control System) FRANCIA
ANSWM Mensaje de respuesta (ODS) FRANCIA
ANSXFPLCT Mensaje de respuesta FRANCIA
ATT Mensaje de aterrizaje FRANCIA
BEGINPROC Mensaje de inicio de procesamiento FRANCIA
BEGPROC Mensaje de procedimiento de iniciación de puesto de
controlador (ODS)FRANCIA
BEGPROCCT Mensaje de iniciación de puesto de controlador
(Terminal Control System)FRANCIA
CDA Mensaje de autorización de salida (ARINC 623) FRANCIA
CDAFTX Mensaje de autorización de Salida (ARINC 620) FRANCIA
CHGDEP Mensaje de modificación de un vuelo de salida FRANCIA
CLD Autorización de salida (ARINC 623) FRANCIA
CLDFTX Autorización de salida (ARINC620) FRANCIA
CNLARR Cancelación de una llegada FRANCIA
CNLCOND Cancelación de condición excepcional CFMU
CNLDEP Cancelación de salida FRANCIA
CNLREG Cancelación de una normativa ATFM CFMU
CONFEND Mensaje final para un cambio de configuración opera-
tivaFRANCIA
CONFIDM Mensaje de configuración operativa (ODS) FRANCIA
CONFIDMCT Mensaje de configuración operativa (Terminal Control
System)FRANCIA
DEC Mensaje de despegue FRANCIA
DOUBM Mensaje de duplicación de plan de vuelo FRANCIA
DRT Mensaje de modificación de destino FRANCIA
EATARR Mensaje de actualización de la hora estimada de
llegadaFRANCIA2000R2082 — ES — 15.06.2002 — 001.001 — 127
▼B
Título reservado Tipo de mensaje Reservado por
ENDPROC Último mensaje de procedimiento de iniciación de
puesto de controlador (ODS)FRANCIA
ENDPROCCT Último mensaje de procedimiento de iniciación de
puesto de controlador (Terminal Control System)FRANCIA
EVLARR Mensaje de preactivación para una llegada FRANCIA
EVLDEP Mensaje de preactivación para una salida FRANCIAEXCOND Activación de una condición excepcional CFMU
FICM Creación de un plan de vuelo FRANCIA
FLXVIVO Mensaje de visualización de descripción de «pista
flexible»FRANCIA
FPCLOSE Mensaje de cierre de datos de plan de vuelo (ODS) FRANCIA
FPCLOSECT Mensaje de cierre de datos de plan de vuelo (Terminal
Control System)FRANCIA
FPCLOSED Mensaje de cierre de duplicación de datos de plan de
vuelo (ODS)FRANCIA
FPCRD Mensaje de activación de plan de vuelo (ODS) FRANCIA
FPCRDCT Mensaje de activación de plan de vuelo (Terminal
Control System)FRANCIA
FPCRDD Mensaje de duplicación de datos de plan de vuelo
(ODS)FRANCIA
FPCRE Mensaje de creación de un plan de vuelo (ODS) FRANCIA
FPCRECT Mensaje de creación de un plan de vuelo (Terminal
Control System)FRANCIA
FPINI Mensaje de preactivación de un plan de vuelo (ODS) FRANCIA
FPINICT Mensaje de preactivación de un plan de vuelo
(Terminal Control System)FRANCIA
FPINID Mensaje de duplicación de preactivación de un plan de
vueloFRANCIA
FPNTF Mensaje de preactivación de un plan de vuelo (ODS) FRANCIA
FPNTFD Mensaje de duplicación de preactivación de un plan de
vuelo (ODS)FRANCIA
FPRDU Mensaje de información de datos de vuelo para un
sectorno afectado (ODS)FRANCIA
FPRDUCT Mensaje de información de datos de vuelo para un
sector no afectado (Terminal Control System)FRANCIA
FSM Mensaje de sistema de autorización de salida (ARINC
623)FRANCIA
FSMFTX Mensaje de sistema de autorización de salida (ARINC
620)FRANCIA
FSR Mensaje de solicitud de suspensión de vuelo CFMU
IACHD Mensaje de modificación ATC individual ALEMANIA
ICHGD Mensaje de modificación individual ALEMANIAIDEPD Mensaje de salida individual ALEMANIAIDLAD Mensaje de retraso individual ALEMANIAIFPDQ Mensaje de interrogación de datos de plan de vuelo
individualCFMU
IFPDQR Mensaje de respuesta a una interrogación de datos de
plan de vuelo individualCFMU
IFPDSQ Mensaje de interrogación de resumen de datos de plan
de vuelo individualCFMU
IFPDSQR Mensaje de respuesta a una interrogación de resumen
de datos de plan de vuelo IndividualCFMU
IFPLD Plan de vuelo individual ALEMANIA
INFOM Mensaje de información FRANCIA2000R2082 — ES — 15.06.2002 — 001.001 — 128
▼B
Título reservado Tipo de mensaje Reservado por
IRQS Mensaje de solicitud individual de información comple-
mentariaCFMU
ISPL Mensaje de plan de vuelo individual complementaria CFMU
LGR Lista de mensajes de plan de vuelo FRANCIA
LISTFP Lista de mensajes de plan de vuelo (ODS) FRANCIALISTFPCT Lista de mensajes de plan de vuelo (Terminal Control
System)FRANCIA
LOGON Identificación de mensaje de plan de vuelo FRANCIA
MAJVIVO Mensaje de movimientos diarios FRANCIAMCOM Mensaje de coordinación FRANCIA
MODCOND Modificación de una condición excepcional CFMU
MODREG Modificación de una normativa ATFM CFMUMRA Activación de una ruta obligatoria CFMUMRCNL Cancelación de una ruta obligatoria CFMUMRMOD Modificación de una ruta obligatoria CFMU
MRR Mensaje de redistribución obligatoria CFMU
MVTVIVO Mensaje de información de movimientos FRANCIANEWREG Activación de una normativa ATFM CFMUNTA Activación de flujo de tráfico «no permitido» CFMUNTACNL Cancelación de flujo de tráfico «no permitido» CFMU
NTAMOD Modificación de flujo de tráfico «no permitido» CFMU
OCLM Mensaje de autorización oceánica FRANCIAOCLMD Duplicación de mensaje de autorización oceánica FRANCIAOLRA Activación de una ruta fuera de carga CFMU
OLRCNL Cancelación de una ruta fuera de carga CFMU
OLRMOD Modificación de una ruta fuera de carga CFMUPAMAER Mensaje de aplicación de pista FRANCIAPAMARB Mensaje de confirmación de «puesto de estaciona-
miento»FRANCIA
PAMARRANN Cancelación de asignación de aparcamiento para una
llegadaFRANCIA
PAMARRCRE Asignación de lugar de aparcamiento para una llegada FRANCIA
PAMARRPST Modificación de asignación de aparcamiento para una
llegadaFRANCIA
PAMDAPARB Mensaje de aparcamiento para una aeronave de llegada FRANCIA
PAMDAPCRE Asignación de lugarde apar camiento FRANCIAPAMDEPANN Cancelación de asignación de aparcamiento para una
salidaFRANCIA
PAMDEPCRE Asignación de aparcamiento para una salida FRANCIA
PAMDEPPST Modificación de asignación de aparcamiento para una
salidaFRANCIA
PAMDRB Mensaje de confirmación en «puesto de estaciona-
miento»FRANCIA
QTAARR Retorno al estado original «creado» para una llegada FRANCIA
QTADEP Retorno al estado original «creado» para una salida FRANCIA
RCD Mensaje de solicitud de autorización de salida
(AIRINC 623)FRANCIA
RCDFTX Mensaje de solicitud de autorización de salida
(AIRINC 620)FRANCIA
REVARR Mensaje de revisión para una llegada FRANCIA
RFPDQ Mensaje de interrogación de datos del plan de vuelo
repetitivoCFMU2000R2082 — ES — 15.06.2002 — 001.001 — 129
▼B
Título reservado Tipo de mensaje Reservado por
RFPDQR Mensaje de respuesta a una interrogación de datos de
plan de vuelo repetitivoCFMU
RFPDSQ Mensaje de interrogación de datos resumidos de plan
de vuelo repetitivoCFMU
RFPDSQR Mensaje de respuesta a una interrogación de datos resu-
midos de plan de vuelo repetitivoCFMU
RIEM Mensaje de información de datos de vuelo FRANCIA
RMG Mensaje de aproximación perdido FRANCIA
RRA Mensaje de aceptación de redistribución CFMU
RREC Mensaje de recuperación de plan de vuelo repetitivo CFMURRN Mensaje de notificación de redistribución CFMURSUS Mensaje de suspensión de plan de vuelo repetitivo CFMURWYCHGCT Mensaje de configuración de pista FRANCIATRACT Solicitud de activación de plan de vuelo (ODS) FRANCIATRACTCT Solicitud de activación de plan de vuelo (Terminal
Control System)FRANCIA
TRCNL Solicitud de cancelación de plan de vuelo (ODS) FRANCIA
TRCNLCT Solicitud de cancelación de plan de vuelo (Terminal
Control System)FRANCIA
TRCOR Solicitud de correlación manual FRANCIA
TRDECOR Solicitud de decorrelación manual FRANCIATRFIC Solicitud de creación de datos de plan de vuelo (ODS) FRANCIA
TRFICCT Solicitud de creación de datos de plan de vuelo
(Terminal Control System)FRANCIA
TRFLRQT Mensaje de solicitud de nivel de vuelo FRANCIA
TRMOD Solicitud de modificación de plan de vuelo (ODS) FRANCIATRMODCT Solicitud de modificación de plan de vuelo (Terminal
Control System)FRANCIA
TRMODH Solicitud de modificación de hora FRANCIA
TRMODHD Solicitud de modificación de hora para un vuelo retra-
sadoFRANCIA
TRMVT Solicitud de coordinación para vuelo de salida (ODS) FRANCIA
TRMVTCT Solicitud de coordinación para vuelo de salida
(Terminal Control System)FRANCIA
TRPOINT Mensaje de solicitud de datos de vuelo específicos FRANCIA
TRRET Solicitud de revisión de plan de vuelo para estado
«creado» (ODS)FRANCIA
TRRETCT Solicitud de revisión de plan de vuelo para situación
«creado» (Terminal Control System)FRANCIA
TRRIP Solicitud de visualización de información de datos de
vuelo (ODS)FRANCIA
TRRIPCT Solicitud de visualización de Información de datos de
vuelo (Terminal Control System)FRANCIA
TRRQT Solicitud de plan de vuelo (ODS) FRANCIA
TRRQTCT Solicitud de plan de vuelo (Terminal Control System) FRANCIATRSHRQT Solicitud de acción SHOOT FRANCIATRSTAR Solicitud de inicialización del puesto de controlador
(ODS)FRANCIA
TRSTARCT Solicitud de inicialización del puesto de controlador
(Terminal Control System)FRANCIA2000R2082 — ES — 15.06.2002 — 001.001 — 130
▼B
Título reservado Tipo de mensaje Reservado por
TRTRP Mensaje de posición de transferencia FRANCIA
UNKFP Mensaje de supresión de plan de vuelo (ODS) FRANCIA
UNKFPCT Mensaje de supresión de plan de vuelo (Terminal
Control System)FRANCIA2000R2082 — ES — 15.06.2002 — 001.001 — 131
▼B
ANEXO D (Normativo)
ÍNDICECENTRALDECAMPOSRESERVADOS
D.1.Introducción
El presente Anexo contiene un índice central de campos reservados,
campos primarios, subcampos y términos auxiliares, cuyo uso en
ADEXP aún no ha sido definido. Su inclusión en el presente Anexo
indica que se ha previsto su utilización en el futuro o que están en uso
actualmente, pero que su utilización está limitada a sistemas locales.
D.2.Objeto
El objeto de proporcionar una lista de campos cuya utilización aún no ha
sido adoptada oficialmente en la presente Norma ADEXP es evitar, en la
medida de lo posible, aparición de redundancias cuando se necesite un
nuevo campo para un fin determinado o la creación de una palabra clave
que ya está siendo utilizada en un sistema local.
D.3.Términosauxiliaresreservados
Términos
auxiliares
reservadosSintaxis SemánticaUtilizado en
Campo
primarioUtilizado en
SubcampoUtili-
zado en
Campo
auxiliar
centreidentifi-
cation1{ALPHA}4 Identificación de
centro.ctsrc
ripsrcctripeCtdest
contextfdpsid 'OPEPAL' |
'OPESOS' |
'EVALPAL' |
'TSTOPEPAL'
|'TSTOPESOS'Modo de funcio-
namiento de una
aplicación FDPS.
(Operativo,
Prueba, etc.)ctxtfdps
contextphi-
diasid'OPE'|'EVA-
L1'|'EVAL2'
|('TST'!1{DIGI-
T}1)Específico para el
sistema francésctxtpos
coordpoints ('E'!('S'!('X'!('O'|-
NIL)
|NIL)|NIL)
|'S'!('X'!('O'|NIL)|-
NIL)
|'X'!('O'|NIL)|NIL)
|'O'Punto de entrada
para el puesto de
control («E»).
Punto de salida
para el puesto de
control («S»),
punto XFL (X),
punto OCL (O).coorpt
eoidentifica-
tion1{ALPHANU-
M}6Identificación de
una «entidad
operativa»eosrc eoid
fl3 'F' ! 3{DIGIT}3 Nivel de vuelo
expresado en
cientos de pies.autfl1
autfl2
curfl
flightten-
dancy'U'|'D'|'S' Tendencia
proyectada del
perfil de vuelo.
U para ARRIBAD para ABAJOS para ESTABLEetrfl
trfl
fpcentrestate 'CREE'|'EVEIL'|
'EVLCRT'|'AC-
TIVE'|
'TERM'Situación de plan
de vuelo dentro
de un ACC.fpctst2000R2082 — ES — 15.06.2002 — 001.001 — 132
▼B
Términos
auxiliares
reservadosSintaxis SemánticaUtilizado en
Campo
primarioUtilizado en
SubcampoUtili-
zado en
Campo
auxiliar
latitude 4{ DIGIT }4 Latitud expresada
con cuatro
dígitos.Reservado
para uso
futuro
latitudeshort 2{ DIGIT }2 Latitud expresada
como dos dígitos.Reservado
para uso
futuro
longitude 5{ DIGIT }5 Longitud expre-
sada con cinco
dígitos.Reservado
para uso
futuro
longitudes-
hort3{ DIGIT }3 Longitud expre-
sada con tres
dígitos.Reservado
para uso
futuro
pointcautra 1{ALPHANU-
M}5Específico para el
sistema francésfirstpid pointid
ptcid
ptid
positioniden-
tification1{ALPHANU-
M}6Puesto de trabajo
real o lógicoposid
qfuid ('0'|'1'|'2'|'3')!1{
DIGIT }1!('L'|'C'
|'R'|NIL)QFU para una
pista.
L = Izquierda
C = Centro
R = Derechaqfu qful
secidentifica-
tion1{ALPHANU-
M}2Identificación 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'Motivo para
enviardatos del
plan de vuelo.event
starreason 'TOTAL' Tipo de inicia-
ción de un puesto
con datos del
plan de vuelostreason
temperature ("N" | "P") !
2{DIGIT}2Temperatura
expresada en
grados Celsius
(00-99) con indi-
cación del signo
(Negativo o Posi-
tivo)temp2000R2082 — ES — 15.06.2002 — 001.001 — 133
▼B
Términos
auxiliares
reservadosSintaxis SemánticaUtilizado en
Campo
primarioUtilizado en
SubcampoUtili-
zado en
Campo
auxiliar
updatereason ('T'!('R'|NIL)|'R') Tipo de la última
actualización
realizada a datos
de vuelo.
Transacción de
operador («T»).
Actualización
radar («R»).udpt
D.4.Camposprimariosreservados
Campos
primarios
reservadosClase Sintaxis Semántica
aabd b '-' "AABD" date Fecha real de llegada a la zona de
aparcamiento
aabt b '-' "AABT" timehhmm Hora real de llegada a la zona de
aparcamiento
acnf c '-' "ACNF" ad rcnf [qfulist] Configuración de pista
aobd b '-' "AOBD" date Fecha real de salida de la zona de
aparcamiento
aobt b '-' "AOBT" timehhmm Hora real de salida de la zona de
aparcamiento
apptyp b '-' "APPTYP" 1{ALPHANUM}1 Tipo de aproximación del vuelo (1
dígito, valores: 1, 2 y 3)
arcidao b '-' "ARCIDAO"
1{ALPHANUM}11Identificación de aeronave utilizada
por los operadores de aeronaves
arcidatc b '-' "ARCIDATC" 8{DIGIT}8 Número de identificación local
único de aeronave utilizado por
ATC
atis b '-' "ATIS" 1{ALPHA}1 Indicadorde ser vicio automático de
información terminal.
autfl1 b '-' "AUTFL1" fl3 Nivel de vuelo autorizado 1
autfl2 b '-' "AUTFL2" fl3 Nivel de vuelo autorizado 2automsg c '-' "AUTOMSG" (sendt ptcid flb
pflt)|'NO'Proporciona los datos que son
transmitidos en un mensaje de
coordinación:
hora de emisión, punto de salida,
nivel de vuelo sobre el punto de
salida, nivel de vuelo previsto e
información pertinente si el nivel
de vuelo se corresponde conacuerdos.
avail b '-' "AVAIL" 'YES'|'NO' Indicación de si un sectorestá
autorizado o no a modificar los
datos del plan de vuelo.
bkrow b '-' "BKROW" 1{DIGIT}2 Situación de un punto de referencia
en una lista de puntos de ruta.
bkt b '-' "BKT" datetime Hora de paso por un punto de refe-
rencia para una operación.
codetrb '-' "CODETR" 'YES'|'NO' Indicación de si el código SSR
debería ser transmitido (o no) al
piloto porel puesto de contr ol.
confid b '-' "CONFID" 1{DIGIT}5 Identificación de configuración
operativa (sectores|puestos).
confl c '-' "BEGIN" "CONFL"
1{eopos}
'-' "END" "CONFL"Lista de asociaciones de sectores/
puestos para un centro de control
de ruta.2000R2082 — ES — 15.06.2002 — 001.001 — 134
▼B
Campos
primarios
reservadosClase Sintaxis Semántica
crspd b '-' "CRSPD" 1{DIGIT}4 Velocidad de crucero en nudos
ctripe b '-' "CTRIPE" centreidentification Nombre del centro de control para
una operación
ctrow b '-' "CTROW" 1{DIGIT}1 Posición de un centro en la lista de
centros.
ctsrc b '-' "CTSRC" centreidentification Identificación del centro remitente.
ctxtct b '-' "CTXTCT" 'OPE' | 'TST' Modo de operación del sistema de
control terminal (Terminal Control
System).
ctxtfdps b '-' "CTXTFDPS" contextfdpsid Modo de operación de un FPDSctxtpos b '-' "CTXTPOS" contextphidiasid Modo de operación para ODS
curfl b '-' "CURFL" fl3 Nivel de vuelo actual
curpos c '-' "CURPOS" ptid | (lattd longtd) Posición actual
curpost b '-' "CURPOST" datetime Fecha y hora en la posición actual
curptt b '-' "CURPTT" datetime Fecha y hora de paso por el punto
actual
curptx b '-' "CURPTX" 1{DIGIT}2 Número de posición del punto
actual en la lista de puntos de ruta.
dcatcid b '-' "DCATCID" ICAOaerodrome Aeródromo responsable de la auto-
rización de salida dada por FDPS a
la aeronave por medio del enlace
de datos.
dcbtxt b '-' "DCBTXT" 'PDC REQUEST
RECEIVED'|'PDC REQUEST
UNKNOWN' | 'PDC REQUEST
IGNORED' | 'ACK'Texto básico para mensajes de
autorización de salida ARINC 623.
«ACK» para acuse de recibo del
mensaje.
dcbtxtftx b '-' "DCBTXTFTX" 'PDC
REQUEST RECEIVED'|'PDC
REQUEST UNKNOWN' | 'PDC
REQUEST IGNORED' | 'ACK'Texto básico para mensajes de
autorización de salida ARINC 620.
«ACK» para acuse de recibo del
mensaje.
dccarb '-' "DCCAR" 'DMER'|'CO-
LLAT'|'NO'Estado de autorización de salida
para un vuelo.
dcid b '-' "DCID" 1{DIGIT}3 Número de sistema para autoriza-
ción de salida.
dcmtyp b '-' "DCMTYP" 1{ALPHA}3 Tipo de mensaje de autorización de
salida.
dcref b '-' "DCREF" 1{ALPHANUM}5 Referencia contextual para una
autorización de salida.
dcrmk b '-' "DCRMK" 1{LIM_CHAR}80 Comentario para una autorización
de salida.
dcs1txt b '-' "DCS1TXT"
'REQUEST BEING PROCESSED'
| 'REQUEST ALREADY
RECEIVED' | 'FLIGHT PLAN
NOT HELD' | 'ERROR IN
MESSAGE'.Texto complementario para el
mensaje de autorización de salida
(ARINC 623).
dcs2txt b '-' "DCS2TXT" 'STANDBY'|
'REVERT TO VOICE PROCE-
DURE'Segundo texto complementario
para el mensaje de autorización de
salida (ARINC 623).
dcdt b '-' "DCDT" datetime ! seconds Día, horas, minutos y segundos
para la autorización de salida.
delcode b '-' "DELCODE"
1{ALPHANUM}20Motivo de un retraso
dfdpsid b '-' "DFDPSID datetime ! seconds Datos de identificación del sistema
de procesamiento de datos de vuelo
doubid b '-' "DOUBID" 1{ALPHANUM}2 Identificación de una entidad
«duplicada».2000R2082 — ES — 15.06.2002 — 001.001 — 135
▼B
Campos
primarios
reservadosClase Sintaxis Semántica
ecurptt b '-' "ECURPTT" datetime Hora estimada de paso por el punto
actual
eda b '-' "EDA" date Fecha estimada de llegada.
elastptt b '-' "ELASTPTT" datetime Hora estimada de paso por el
último punto de la ruta.
endhldt b '-' "ENDHLDT" datetime Hora de finalización del circuito de
espera.
entrnb b '-' "ENTRNB" '1' | '2' | '3' | '4' | '5' |
'6' | '7' | '8' | '9' | '10' | '11' | '12' |
'13' | '14' | '15'Número de apariciones de un plan
de vuelo en un centro.
entryt b '-' "ENTRYT" datetime Hora de entrada de la posición.
enxtptt b '-' "ENXTPTT" datetime Hora estimada de paso por el punto
siguiente (no se menciona si el
punto actual es el último).
eobdt b '-' "EOBDT" datetime Fecha y hora estimada de abandono
de la zona de aparcamiento.
eosrc b '-' "EOSRC" eoidentification Identificación de una «entidad»
operativa
espfl b '-' "ESPFL" flightlevel Nivel de vuelo de transferencia
complementario para el puesto de
control precedente.
eta b '-' "ETA" timehhmm Hora estimada de llegada.
etrfl b '-' "ETRFL" flightlevel|flightten-
dancyNivel de vuelo de entrada o
tendencia del perfil de vuelo.
event b '-' "EVENT" sendingreason Hecho que inicia el FDPS.
firstpid b '-' "FIRSTPID" pointcautra Específico para el sistema francés
flbk b '-' "FLBK" flightlevel Nivel de vuelo en el último punto
de operación para un vuelo acti-
vado o nivel modificado para un
punto de referencia para una
operación.
fpbaseid b '-' "FPBASEID" datetime!seconds Identificación de la base de datos
del plan de vuelo.
fpctst b '-' "FPCTST" fpcentrestate Situación del plan de vuelo dentro
de un centro.
fpkwl c '-' "BEGIN" "FPKWL"
1{fpident}300 '-' "END"
"FPKWL"Lista de planes de vuelo conocidos,
pero aún no transferidos para un
puesto.
fplcat b '-' "FPLCAT" "T" | "E" | "S" | "I" Categoría del vuelo:
T = sobrevuelo/paso
E = a la llegada
S = a la salida
I = interior.
fplist c '-' "BEGIN" "FPLIST"
1{fpsum}50
'-' "END" "FPLIST"Lista de información de plan de
vuelo para un indicativo de
llamada.
fpllist c '-' BEGIN "FPLLIST" fpllgr
'-' "END"Lista de campos de plan de vuelo.
fplnb b '-' "FPLNB" 1{DIGIT}1 Número de planes de vuelo de 0 a
5.
fplstat b '-' "FPLSTAT" "T" | "C" Estado del vuelo:
T = finalizado
C = activo.
fprmk b '-' "FPRMK" 1{LIM_CHAR}8 Observaciones del plan de vuelo
inicial.
fpsrc b '-' "FPSRC" ("FICTOT"|"FI-
CEVL"|"FICMOD"|FICABI"|"FI-CACT""|FIC-
PAC"|'FPL"|"RPL"|"NKW")Fuente del plan de vuelo.2000R2082 — ES — 15.06.2002 — 001.001 — 136
▼B
Campos
primarios
reservadosClase Sintaxis Semántica
fpunkl c '-' "BEGIN" "FPUNKL"
1{fpident}300 '-' "END"
"FPUNKL"Lista de planes de vuelo «descono-
cidos».
freetxt c '-' "BEGIN" "FREETXT" 1{txt}3
'-' "FREETXT"Mensaje de texto libre.
ftxid b '-' "FLXID" 1{ALPHANUM}14 Identificación de itinerario flexible.
ftxname b '-' "FLXNAME"
1{ALPHANUM}4Nombre de itinerario flexible.
ftxnum b '-' "FLXNUM" 1{DIGIT}2 Número de creación de itinerario
flexible.
grspd b '-' "GRSPD" 1{DIGIT}4 Velocidad respecto al suelo en
nudos.
hldbkrw b '-' "HLDBKRW" 1{DIGIT}2 Número de orden de un punto de
referencia para un circuito de
espera en una lista de puntos de
ruta.
icing b '-' "ICING" 1{ALPHA}8 Hielo.
«TRACE», «LIGHT», «MODE-
RATE» o «SEVERE».
indstip b '-' "INDSTIP" 'STIP' Específico del sistema francés
initid b '-' "INITID" 1{DIGIT}1 Número e iniciación.
interid b '-' "INTERID"
'V'!2{DIGIT}2!'R'!2{DIGIT}2Identificadorde inter faz de sistema
terminal FDPS/ o FDPS/ODS.
lalglist c '-' BEGIN "LALGLIST" lalg
'-' END "LALGLIST"Lista de latitudes y longitudes de
los puntos de la ruta.
lang b '-' "LANG" '?' Indicadorde lenguaje conver sa-
cional.
«?» = el lenguaje no es usual en la
compañía
lastradt b '-' "LASTRADT" datetime Ultima actualización de tiempo
dada por la información del radar.
lights b '-' "LIGHTS" 1{ALPHANUM}1 Código de luces.
maint b '-' "MAINT" 'YES'|'NO' Indicación de si los datos de infor-
mación para un puesto de control
se mantienen de forma continua o
no.
modea b '-' "MODEA"
'A'!4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'7'}4Información modo A de SSR
modec b '-' "MODEC" flightlevel Información modo C de SSR
msgbody b '-' "MSGBODY"
1{CHARACTER}Contiene una cadena de caracteres
idéntica al cuerpo de un mensaje
no ADEXP equivalente y existente.
msgct b '-' "MSGCT" datetime ! seconds Registro horario de un mensaje en
el formato: Día, horas, minutos,
segundos.
nat b '-' "NAT" 1{ALPHA}1 Identificación de una pista del
Atlántico Norte.
nfc b '-' "NFC" 3{DIGIT}3 ! '.' !
3{DIGIT}3Frecuencia de siguiente contacto.
nxtfir b '-' "NXTFIR" ICAOaerodrome FIR siguiente a contactar.
nxtpos c '-' "NXTPOS" ptid | (lattd longtd) Siguiente posición.
nxtpost b '-' "NXTPOST" datetime Hora de paso por la siguiente posi-
ción.
oclfl b '-' "OCLFL" flightlevel Nivel de vuelo de límite de autori-
zación oceánica (OCL).
oprfl b '-' "OPRFL" flightlevel Solicitud de nivel de vuelo modifi-
cado por un operador.2000R2082 — ES — 15.06.2002 — 001.001 — 137
▼B
Campos
primarios
reservadosClase Sintaxis Semántica
oprmk c '-' "BEGIN" "OPRMK"
1{rmktxt}2 '-' "END" "OPRMK"Lista de comentarios del operador.
oprmkct b '-' "OPRMKCT"
1{LIM_CHAR}20Comentarios del operador.
oriented b '-' "ORIENTED" 'YES'|'NO' Vuelo orientado o no.
pfl b '-' "PFL" flightlevel Nivel de vuelo previsto (PFL).
pistcoord c '-' "PISTCOORD" xpist ypist
vxpist vypistCoordenadas de seguimiento por
radar y coordenadas del vector
velocidad.
pistid b '-' "PISTID" 1{DIGIT}4 Identificación de seguimiento por
radar.
pkarr c '-' "PKARR" [pka] [pkc] pkatt Posición de aparcamiento para un
vuelo de llegada.
pkdep b '-' "PKDEP" 1{ALPHANUM}3 Posición de aparcamiento para un
vuelo de salida.
plnid b '-' "PLNID" 4{DIGIT}4 Identificación de plan de vuelo.
plnold b '-' "PLNOLD" 4{DIGIT}4 Antigua identificación de plan de
vuelo
posst b '-' "POSST" 'MAE'|'MPS'|'-
MAS'|'MPSA'|'MPSLATE'|'NO'Estado de movimiento de coordi-
nación para la posición: movi-
miento aceptado para entrada
(MAE) o para salida (MAS) o
movimiento propuesto para salida(MPS) o movimiento propuesto
para salida en alarma (MPSA) o
estado de movimiento porcoor -
dinar(NO).
ptnb b '-' "PTNB" 1{DIGIT}2 Número de puntos en la ruta.
qfu b '-' "QFU" qfuid Identificación de la pista en uso
(QFU).
quebec b '-' "QUEBEC" 'YES'|'NO' Vuelo Quebec o no.
radioid b '-' "RADIOID"
1{ALPHANUM}20Identificación de radio.
reqid b '-' "REQID" 1{DIGIT}5 Número de una solicitud.
reqtyp b '-' "REQTYP" ('STPV' | 'STIP') Tipo de solicitud de plan de vuelo.ripel c '-' "BEGIN" "RIPEL"
1{destid}12
'-' "END" "RIPEL"Lista de entidades destinatarias de
datos de plan de vuelo.
ripsrc b '-' "RIPSRC" centreidentification Identificación del centro respon-
sable de iniciarla tr ansmisión de
datos del plan de vuelo.
rstid b '-' "RSTID" '1'|'2'|'3'|'4'|'5' Número de operación IFPS en una
solicitud de plan de vuelo.
rte c '-' "BEGIN" "RTE"
1{ptc}22
'-' "END" "RTE"Lista de puntos CAUTRA de ruta
no dirigida.
rtetr c '-' "BEGIN" "RTETR" 1{ptpro}22
'-' "END" "RTETR"Lista de puntos de ruta para deter-
minadas operaciones.
scnf c '-' "BEGIN" "SCNF"
1{acnf}3
'-' "END" "SCNF"Lista de configuraciones de aeró-
dromo.
secdest b '-' "SECDEST" secidentification Identificadorde sectordestinatar io.
seclist c '-' "BEGIN" "SECLIST" 1{sec}30
'-' "END" "SECLIST"Lista global de sectores.
seclistct c '-' "BEGIN" "SECLISTCT"
1{secct}30
'-' "END" "SECLISTCT"Lista global de los sectores.
secsrc b '-' "SECSRC" secidentification Identificador de sector de origen.2000R2082 — ES — 15.06.2002 — 001.001 — 138
▼B
Campos
primarios
reservadosClase Sintaxis Semántica
spfl b '-' "SPFL" flightlevel Nivel de vuelo complementario.
ssrcodes c '-' "SSRCODES" (code1 code2) |
code | codep)Código SSR transmitido.
stamp b '-' "STAMP" 3{DIGIT}3 !
timehhmmSello de identificación.
streason b '-' "STREASON" starreason Motivo de una solicitud de inicia-
ción emitida porun puesto de
control.
strid b '-' "STRID" 1{DIGIT} Identificador RDPS.
temp b '-' "TEMP" temperature Temperatura.
terminal b '-' "TERMINAL"
1{ALPHANUM}2Nombre del terminal.
translist c '-' "BEGIN" "TRANSLIST"
1 {transid}
'-' "END" "TRANSLIST"Lista de operaciones posibles para
el control de posición y para el
plan de vuelo especificado.
trfl b '-' "TRFL" flightlevel | flightten-
dancyNivel de vuelo de transferencia o
información de la tendencia del
perfil de vuelo.
turb b '-' "TURB" 1{ALPHA}8 Turbulencia = LIGHT, MODE-
RATE o SEVERE
validend b '-' "VALIDEND" datetime Hora de fin de visualización.
validst b '-' "VALIDST" datetime Hora de inicio de visualización.
visi b '-' "VISI" 1{ALPHANUM}20 Visibilidad.
wddir b '-' "WDDIR" 1{DIGIT}3 Dirección del viento expresada en
grados desde 0 a 359.
wdspd b '-' "WDSPD" 1{DIGIT}3 Velocidad del viento expresada en
nudos.
xfl b '-' "XFL" flightlevel Nivel de vuelo de salida (XFL).
xfpltxt b '-' "XFPLTXT" 1{CHARACTER |
ASCII_SUP}768Mensaje de respuesta a una soli-
citud de plan de vuelo.
D.5.Subcamposreservados
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
act c '-' "BEGIN" "ACT"
1{fieldid}20
'-' "END" "ACT"Campos de plan de
vuelo modificables
en el momento de
activación de un
vuelo.transid
bkchg c '-' "BKCHG" flimp
flmin flmaxNivel de vuelo (FL)
implícito, mínimo y
máximo para el punto
de referencia de una
operación. El nivel
de vuelo es genérico,
puede serRFL, PFL,
etc.fieldid
bktchg c '-' "BKTCHG"
delta1 delta2Valor(+/-) per mitido
para una modifica-
ción horaria de un
punto.fieldid
cflchg c '-' "CFLCHG" flimp
flmin flmaxNivel de vuelo auto-
rizado (CFL) implí-
cito, mínimo y
máximo para el punto
de referencia para
una operación.fieldid2000R2082 — ES — 15.06.2002 — 001.001 — 139
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
code b '-' "CODE"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR y código
asignado.ssrcodes
codep b '-' "CODEP"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR y código
disponible.ssrcodes
code1 b '-' "CODE1"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR y código
asignado previa-
mente.ssrcodes
code2 b '-' "CODE2"
('A'|'C'|'X')!
4{'0'|'1'|'2'|'3'|'4'|'5'|'6'|'-
7'}4Modo SSR y código
de uso reservado y,
portanto, no dispo-
nible.ssrcodes
coorpt b '-' "COORPT" coord-
pointsCaracterísticas del
punto de coordina-
ción: Inicial, Salida,
OCL, XFLptc
ctdest b '-' "CTDEST"
centreidentificationCentro destinatario
(ACC)destid
delta1 b '-' "DELTA1"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervalo de tiempo
para el cálculo de un
tiempo mínimo.bktchg
delta2 b '-' "DELTA2"
('0'|'1'|'2'|'3'|'4'|'5')!DI-
GITIntervalo de tiempo
para el cálculo de un
tiempo máximo.bktchg
deltsp1 b '-' "DELTSP1"
1{DIGIT}4Intervalo de velo-
cidad para el cálculo
de una velocidad
mínima.spdchg
deltsp2 b '-' "DELTSP2"
1{DIGIT}4Intervalo de velo-
cidad para el cálculo
de una velocidad
máxima.spdchg
destid c '-' "DESTID" ctdest
secripCentro ATC y lista
de sectores destinata-
rios de datos de
planes de vuelo.ripel
edto b '-' "EDTO" dateti-
me|"WT"Tiempo estimado de
paso porun punto en
el formato: año, mes,
día, horas, minutos o
el indicador«punto
sin dato hora-
rio»«WT».ptc
ptpro
eoid b '-' "EOID" eoidentifi-
cationNombre de entidad
operativa.eolist
eolist c '-' "BEGIN"
"EOLIST" 1{eoid}
'-' "END" "EOLIST"Lista de entidades
operativas asociadas
a un puesto de
control.eopos
eopos c '-' "EOPOS" posid
[eolist]Nombre de puesto de
control y lista de
entidades operativas
asociadas a este
puesto.confl2000R2082 — ES — 15.06.2002 — 001.001 — 140
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
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'Identificación de
campos modificables
para una operación.act
mod
mvt
ret
modh
flb b '-' "FLB" flightlevel Nivel de vuelo calcu-
lado en el punto de
coordinación de
salida, que puede ser
transmitido en el
mensaje de coordina-
ción automático diri-
gido al centro
siguiente.automsg
flimp b '-' "FLIMP" fligh-
tlevelNivel de vuelo implí-
cito.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
flmax b '-' "FLMAX" fligh-
tlevelNivel de vuelo
máximo.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
flmin b '-' "FLMIN" fligh-
tlevelNivel de vuelo
mínimo.bkchg
rflchg
pflchg
cflchg
tflchg
sflchg
xflchg
fpident c '-' "FPIDENT" plnid
stamp ctrow entrnbIdentificación de plan
de vuelo en un
mensaje.fpunkl
fpkwl
fpllgrc '-' "FPLLGR" ar ci-
datc arcid adep ades
eobd eobtDatos «resumidos»
de plan de vuelo.fpllist
fpsum c '-' "FPSUM" plnid
eobdt adep ades
ctrow firstpidIdentificación de plan
de vuelo.fplist
lalg c '-' "LALG" lattd
longtdLatitud y longitud de
cada punto de la ruta.laglist
mod c '-' "BEGIN" "MOD"
1{fieldid}20
'-' "END" "MOD"Lista de campos que
son modificables
después de la activa-
ción.transid
modh c '-' "BEGIN"
"MODH" 1{fieldid}2
'-' "END" "MODH"Lista de campos que
son modificables en
una operación de
actualización horaria
después de la activa-
ción.transid
mvt c '-' "BEGIN" "MVT"
1{fieldid}2
'-' "END" "MVT"Lista de campos que
son modificables en
una coordinación
iniciada manualmente
entre sectores.transid2000R2082 — ES — 15.06.2002 — 001.001 — 141
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
pflchg c '-' "PFLCHG" flimp
flmin flmaxNiveles máximo y
mínimo para modifi-
cación de PFL.fieldid
pflt b '-' "PFLT" flightle-
vel!('NA'|NIL)Nivel de vuelo
previsto que será
transmitido en el
mensaje de coordina-
ción automática diri-
gido al centro
siguiente. Más una
indicación de si el
nivel cumple con los
acuerdos de opera-
ciones aplicables.
NA = no cumple.automsg
pka b '-' "PKA"
1{ALPHANUM}3Puesto de estaciona-
miento reservado
todavía sin adjudicar.pkarr
pkatt b '-' "PKATT" 'YES' |
'NO'Indicadorde que la
aeronave está en
espera de un puesto
de aparcamiento.pkarr
pkc b '-' "PKC"
1{ALPHANUM}3Puesto de aparca-
miento asignado.pkarr
pointid b '-' "POINTID" point-
cautraEspecífico para el
sistema francés.ptpro
posid b '-' "POSID" positioni-
dentificationNombre del puesto
de control.eopos
ptc c '-' "PTC" ptcid edto
[fl] [view] [udpt]
[traj] [coorpt] [ref]Características de un
punto de ruta.rte
ptcid b '-' "PTICD" pointcau-
tra|geonameEspecífico para el
sistema francés.automsg ptc
ptpro c '-' "PTPRO" pointid
[edto] [fl] [traj]Descripción de
puntos de ruta
propuestos.rtetr
qful c '-' "QFUL" qfuid QFU válido para una
pista de un aeró-
dromo.qfulist
qfulist c '-' BEGIN"
"QFULIST"
1{qful}8
'-' "END"
"QFULIST"Lista de QFU válidos
para un aeródromo.acnf
rcnf b '-' "RCNF"
1{ALPHA}5Dirección general de
despegue y aterrizaje
para un aeródromo.
(Este, Oeste, etc.)acnf
ref c '-' "REF" (refi-
d|ref1id)Características de un
punto de referencia
para una operación.ptc
refid b '-' "REFID"
'REF'!2{DIGIT}2Identificación de un
punto de referencia
posible para una
operación.ref
ref1id b '-' "REF1ID"
'REF'!2{DIGIT}2Identificación del
punto de referencia
más probable para
una operación.ref
regulid1 b '-' "REGULID1"
1{ALPHANUM}5Información norma-
tiva específica para
los sistemas fran-
ceses.regul2000R2082 — ES — 15.06.2002 — 001.001 — 142
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
regulid2 b '-' "REGULID2"
1{ALPHANUM}5Información norma-
tiva específica para
los sistemas fran-
ceses.regul
regult b '-' "REGULT" date-
timeInformación norma-
tiva específica para
los sistemas fran-
ceses.regul
ret c '-' "BEGIN" "RET"
1{fieldid}1
'-' "END" "RET"Lista de campos que
son modificables en
una operación para
devolverlos datos del
plan de vuelo a su
situación previa.transid
rflchg c '-' "RFLCHG" flimp
flmin flmaxNivel implícito,
mínimo y máximo
para la modificación
del RFL.fieldid
rmktxt b '-' "RMKTXT"
1{LIM_CHAR}20Texto de un comen-
tario de un contro-
lador.oprmk
sec c '-' "SEC" secid
[seccar]Identificación y
características de
sectores ACC desti-
natarios de los datos
del plan de vuelo.seclist secrip
seccarb '-' "SECCAR"
('F'!('L'!('M'!('D'|NI-
L)|NIL)|NIL)|NIL)
|('L'! ('M'!('D'|NIL)|-
NIL)|NIL)
|('M'!('D'|NIL)|NIL)
|'D'Características de un
sectorACC:
— Primer Sector
(«F»)
— Último Sector
(«L»)
— Aceptado para
entrada («M»)
— Sector origen para
«duplicación» («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ísticas de un
sectorTMA:
— Primer sector
(«F»)
— Último sector
(«L»)
— Aceptado para
entrada («M»)secct
secct c '-' "SECCT" secid
[seccarct]Identificación y
características de
sectores TMA.seclistct
secid b '-' "SECID" seciden-
tificationIdentificación de
sector.secct
sec
secrip c '-' "BEGIN"
"SECRIP" 1{sec}40
'-' "END" "SECRIP"Lista de entidades
destinatarias de
planes de vuelo
(sectores o entidades
de control de salida/
llegada).destid
sendt b '-' "SENDT" datetime Hora de emisión de
un mensaje de coor-
dinación.automsg
sflchg c '-' "SFLCHG" flimp
flmin flmaxNivel implícito,
mínimo y máximo
para modificación del
nivel de vuelo
complementario
(SFL)fieldid2000R2082 — ES — 15.06.2002 — 001.001 — 143
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
spdchg c '-' "SPDCHG" deltsp1
deltsp2Intervalos de velo-
cidad inferior y supe-
rior para la
modificación de la
velocidad del plan de
vuelo durante una
operación.fieldid
tflchg c '-' "TFLCHG" flimp
flmin flmaxNivel implícito,
mínimo y máximo
para modificación de
nivel de vuelo de
transferencia (TFL).fieldid
traj b '-' "TRAJ"
('S'!'M')|'S'|'M'|'T'|
('S'!'M'!'A')|('S'!'A')|
('M'!'A')|'A'Características de un
punto en relación a la
trayectoria de un
vuelo:
S = Punto de corte
M = Punto de unión
T = Punto de través
A = Punto STARptc
ptpro
transid b '-' "TRANSID" (act |
mod | mvt | ret |
modh | 'CNL' | 'RIP')
| 'NO'Identificación de
operación posible
para el punto de
control para este plan
de vuelo o el indi-
cador«NO» que
significa que la
operación no es
posible.translist
txt b '-' "TXT"
1{LIM_CHAR}80Texto libre. freetxt
udpt b '-' "UDPT" update-
reasonÚltima actualización
aportada por un
operador o por la
información del
radar.ptc
view b '-' "VIEW"
('V'|'VNX')Indicación del
carácter «visible» de
un punto.
V = visible
VNX = no visible
(punto artificial)ptc
vxpist b '-' "VXPIST" ALPHA
1{DIGIT}5
ALPHA:= P|N
P:= Positif
N:= NegativeCoordenada X del
vectorvelocidad de
un radar.pistcoord
vypist b '-' "VYPIST" ALPHA
1{DIGIT}5ALPHA:= P|N
P:= Positif
N:= NegativeCoordenada Y del
vectorvelocidad deun radar.pistcoord
xflchg c '-' "XFLCHG" flmin
flmaxNivel máximo y
mínimo para modifi-
cación de un nivel de
vuelo de salida
(XFL).fieldid
xpist b '-' "XPIST" 'P'|'N'
1{DIGIT}6
P:= Positif
N:= NegativeCoordenada X de una
posición de radar.pistcoord2000R2082 — ES — 15.06.2002 — 001.001 — 144
▼B
Subcampos
reservadosClase Sintaxis SemánticaUtilizado
en Campo
primarioUtilizado
en
Subcampo
ypist b '-' "YPIST" 'P'|'N'
1{DIGIT}6
ALPHA:= P/N
P:= Positif
N:= NegativeCoordenada Y de una
posición de radar.pistcoord2000R2082 — ES — 15.06.2002 — 001.001 — 145
▼B
ANEXO E (Informativo)
INTRODUCCIÓNDEGRUPOSDEMENSAJES
INTRODUCCIÓN
El presente Anexo es una introducción a los diferentes grupos o categorías de
mensajes que pueden ser intercambiados en ADEXP. En el Anexo B, se propor-
ciona una lista completa de todos los títulos de mensajes ADEXP.
NOTA Si desea conocerlas condiciones, r eglas de aplicación y campos de utili-
zación exactos, particularmente la utilización de campos opcionales,
deberá consultar la documentación pertinente de los sistemas correspon-
dientes (porejemplo, documento de especificación de inter faz).
E.1.Mensajesdeplandevuelo
E.1.1. Introducción
Los mensajes que pertenecen a esta categoría se intercambian princi-
palmente entre los AO, IFPS y las unidades ATS competentes.
E.1.2. Definición de los títulos de mensaje
Los mensajes que pertenecen a esta categoría son los siguientes:ACK, IACH, IAFP, IAPL, IARR, ICHG, ICNL, IDEP, IDLA, IFPL,
IRPL, IRQP, MAN, RCHG, RCNL y REJ.
Toda la documentación necesaria para definir estos mensajes se
encuentra en el Documento de ref. 3.
E.1.3. Composición de los campos primarios
La definición detallada del contenido de los mensajes, reglas de inser-
ción de datos, y la utilización de campos obligatorios u opcionales, se
encuentra en el Documento de ref. 3.
Ejemplo
Mensaje de plan de vuelo-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 — ES — 15.06.2002 — 001.001 — 146
▼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.Mensajesdegestióndeflujodetráficoaéreo
E.2.1. Introducción
Los mensajes que pertenecen a esta categoría se intercambian princi-
palmente entre el sistema TACT de la CFMU de Eurocontrol, los
operadores de aeronaves y las unidades ATS.
E.2.2. Mensajes de asignación de ranuras asistida por ordenador (CASA)
Los títulos de mensaje que pertenecen a esta categoría son:
DES, ERR, FCM, FLS, RDY, RJT, RRP, SAM, SIP, SLC, SMM,
SPA, SRJ, SRM, SRR.
E.2.2.1. Definición de los títulos de mensaje
Toda la documentación necesaria para definir estos mensajes se
encuentra en el Documento de ref. 5.
E.2.2.2. Composición de campos primarios
La definición detallada del contenido de mensaje, reglas de inserción
de datos y la utilización de campos obligatorios u opcionales se
encuentra en el Documento de ref. 5.
Ejemplo
-TITLE SAM -ARCID AMC101 -ADEP EGLL -ADES LMML -
EOBD 980324 -EOBT 0945
-CTOT 010 -REGUL UZZU11 -TAXITIME 0020
E.2.3. Mensajes de información
Los títulos de mensaje que pertenecen a esta categoría son:FSA
E.2.3.1. Definición de los títulos de mensaje
La documentación necesaria para definir este mensaje se encuentra en
el Documento de ref. 5.
E.2.3.2. Composición de los campos primarios
La definición del contenido del mensaje, reglas de inserción de datos
y la utilización de los campos obligatorios y opcionales se encuentra
en el Documento de ref. 5.
Ejemplo
Primer mensaje de activación de sistema
-TITLE FSA -ARCID EIN636 -ADEP EIDW -ADES EBBR -POSI-
TION -PTID LIFFY -TO 16462000R2082 — ES — 15.06.2002 — 001.001 — 147
▼B
E.3.MensajesdecoordinaciónATC
E.3.1. Introducción
Los mensajes de coordinación se utilizan para automatizar la coordi-
nación operativa y el intercambio de información entre unidades
ATC. Los mensajes aseguran el envío oportuno de la información
operativa relacionada con la coordinación por medio de funciones
normalizadas de extracción y transmisión de datos.
E.3.2. Definición de los títulos de mensaje
Los títulos de mensaje que pertenecen a esta categoría son:
ABI, ACT, CDN, COD, COF, HOP, INF, LAM, LRM, MAC, MAS,
PAC, RAP, REV, ROF, RRV, SBY, SDM, TIM.
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 6
E.3.3. Composición de los campos primarios
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 6
Ejemplos
Mensaje de propuesta de transferencia-TITLE HOP -REFDATA -SENDER -FAC L -RECVR -FAC E -
SEQNUM 030 -ARCID AMM253
-CFL F190 -ASPEED N0420 -RATE D25 -DCT BEN STN
Activarmensaje
-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.Mensajesdegestióndelespacioaéreo
E.4.1. Introducción
Mensajes utilizados en la coordinación de la gestión del espacio
aéreo. Estos mensajes cubren la gestión del entorno en el que se
mueve el tráfico: rutas permanentes y condicionales, áreas de segre-
gación temporal, áreas peligrosas y prohibidas, etc.
E.4.2. Definición de títulos de mensaje
Los títulos de mensajes que pertenecen a esta categoría son:
AUP, CRAM y UUP.
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 7.
E.4.3. Composición de los campos primarios
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 7.
Ejemplo
Mensaje condicional de disponibilidad de ruta-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 — ES — 15.06.2002 — 001.001 — 148
▼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.Mensajesdecoordinacióncivil/militar
E.5.1. Introducción
Mensajes utilizados en la coordinación de datos de vuelo y las solici-
tudes de cruce de espacio aéreo entre unidades ATS civiles y
militares.
E.5.2. Definición de títulos de mensaje
Los títulos de mensaje que pertenecen a esta categoría son:
ACP, BFD, CFD, LAM, RJC, XAP, XCM, XIN, XRQ.
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 7.
E.5.3. Composición de los campos primarios
Toda la documentación para definir estos mensajes se encuentra en el
Documento de ref. 7.
Ejemplo
Mensaje de solicitud de autorización de paso
-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
Mensaje de aceptación
-TITLE ACP -REFDATA -SENDER -FAC EBBUZXZQ -RECVR -
FAC EBSZZXZQ
-SEQNUM 014 -MSGREF -SENDER -FAC EBSZZXZQ -RECVR -
FAC EBBUZXZQ
-SEQNUM 0122000R2082 — ES — 15.06.2002 — 001.001 — 149
▼B
ANEXO F (Informativo)
EJEMPLOSDEFORMATODEMENSAJEADEXP
Los siguientes ejemplos se ofrecen a modo de demostración del formato
ADEXP, no como ejemplo de contenido de mensaje. El mensaje utilizado es
un IFPL y aunque correcto en el momento de su publicación, no está garanti-
zada la exactitud en cuanto a la composición de campos.
El EJEMPLO 1 a continuación se presenta de forma fácilmente legible, para lo
cual se han utilizado retornos de carro, cambios de línea, sangrías, etc. Dicha
distribución no forma parte de las reglas de formato ADEXP.
La presentación de un mensaje queda, por consiguiente, a la discreción del
sistema receptor. Los ejemplos proporcionados como EJEMPLO 2 y EJEMPLO
3 son representaciones válidas del mismo mensaje presentado en el EJEMPLO
1.
EJEMPLO 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 — ES — 15.06.2002 — 001.001 — 150
▼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
EJEMPLO 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 — ES — 15.06.2002 — 001.001 — 151
▼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
EJEMPLO 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 — ES — 15.06.2002 — 001.001 — 152
▼B
ANEXO G (Informativo)
DESARROLLOSFUTUROS
G.1.Introducción
El presente Anexo tiene por objeto dar una indicación del desarrollo
futuro propuesto para el ADEXP y los motivos y objetivos de este desa-
rrollo.
G.2.Objetivos
Uno de los objetivos más importantes durante el desarrollo del ADEXP
fue la necesidad de desarrollar un formato que permitiera a un sistema
receptor «ignorar» o «saltar» satisfactoriamente un campo desconocido
o no reconocible sin tener que invalidar necesariamente el mensaje que
estaba procesando. Esta implantación permite añadir un nuevo campo
dentro del mensaje sin que sea necesario modificar todos los sistemas
receptores previamente seguido de un intercambio cuidadosamente coor-
dinado. La enorme flexibilidad que ofrece esta característica es una de
las ventajas del formato ADEXP.
Este objetivo se consigue en la norma actual mediante la utilización de
campos primarios y subcampos predefinidos, introducidos mediante pala-
bras clave únicas. Un analizador de léxico que no «reconozca» una
palabra clave deberá ignorar todo el texto hasta el siguiente Campo
primario conocido, que no esté dentro de un Campo de lista. La recupe-
ración se realiza, por tanto, a nivel de campos primarios.
Los desarrollos actuales y futuros en la definición de nuevos mensajes
indican que ciertas áreas precisan un nivel de complejidad mayor, donde
se necesitan campos englobados en un tercer y cuarto nivel. (El Mensaje
de asignación de ruta condicional (CRAM) es un ejemplo actual de esta
necesidad). Actualmente, el ADEXP nos permite construir un mensaje
con cualquiernivel de englobamiento. Sin embar go, no existe la capa-
cidad de recuperarse de un subcampo no reconocido, cuando el error
ocurre en un tercer o cuarto nivel de englobamiento, sin que exista posi-
bilidad de malinterpretar los datos o tener que invalidar el mensaje. Las
modificaciones propuestas requieren que el formato ADEXP sea dise-
ñado para asegurar que un analizador lógico o sintáctico sea capaz, en
todo momento, de determinar dónde se encuentra dentro de la estructura
de un mensaje o campo individual y, al hacerlo, ser capaz de realizar la
recuperación con cualquier nivel de englobamiento sin peligro de malin-
terpretar los datos.
G.3.Propósito
Para conseguir el objetivo de recuperación a cualquier nivel dentro de un
mensaje, es necesario que el analizador lógico sea capaz de reconocer el
final, así como el inicio, de un campo. El formato actual permite sólo la
determinación del inicio de un campo mediante la utilización del carácter
«-».
Se propondrá, en una versión futura de ADEXP, la introducción del uso
de paréntesis para indicar respectivamente el inicio y el final de un
campo. El uso actual del carácter «-» para la introducción de un camposerá reemplazado por el carácter «(». El final de un campo, que actual-
mente no está indicado explícitamente, estaría indicado en el futuro
mediante el carácter «)». Los ejemplos siguientes ilustran este principio.
Ejemplos
Formato actual Formato propuesto
Ejemplo de campo básico: -RFL F330 (RFL F330)Ejemplo de campo compuesto: -CRSCLIMB
-PTID DUB
-CRSPEED M084-CRFL1 F370-CRFL2 F430(CRSCLIMB
(PTID DUB)
(CRSPEED M084)(CRFL1 F370)(CRFL2 F430))2000R2082 — ES — 15.06.2002 — 001.001 — 153
▼B
ANEXO III
DOCUMENTO DE CONTROL DE INTERFAZ PARA EL INTER-
CAMBIODEDATOSDEVUELO(FDE-ICD),EDICIÓN1.0
(DocumentodereferenciadeEurocontrolCOM.ET1.ST12-STD)2000R2082 — ES — 15.06.2002 — 001.001 — 154
▼B
TABLADECONTENIDOS
DERECHOS DE AUTOR
PRÓLOGO1. INTRODUCCIÓN2. ALCANCE3. REFERENCIAS
3.1. Introducción3.2. Referencias
4. DEFINICIONES, SIMBOLOS Y ABREVIATURAS
4.1. Definiciones4.2. Símbolos y abreviaturas4.3. Notaciones
5. RESUMEN TÉCNICO
5.1. Composición vertical del protocolo5.2. Estructura del perfil5.3. Relación con versiones anteriores de la especificación
6. REQUISITOS DE PERFIL
6.1. Requisitos de conformidad6.2. Requisitos de las capas superiores6.3. Requisitos de las capas inferiores6.3.1. Requisitos de la capa de transporte6.3.2. Requisitos de la capa de red6.3.3. Requisitos de la capa de enlace de datos6.3.4. Requisitos de la capa física
7. MÉTODOS DE PRUEBAANEXO A (NORMATIVO) PROTOCOLO DE TRANSFERENCIA DE MENSAJES
A.1. IntroducciónA.2. Servicio desarrolladosA.3. Servicios necesariosA.4. Especificación de protocoloA.4.1. IntroducciónA.4.2. Tipos de datosA.4.3. Establecimiento de una asociaciónA.4.4. Transferencia de datosA.4.5. Terminación normal de la asociaciónA.4.6. Restablecimiento de una asociaciónA.4.7. Integridad de la asociaciónA.4.8. Terminación anormal de la asociaciónA.4.9. Recuperación tras un fallo2000R2082 — ES — 15.06.2002 — 001.001 — 155
▼B
A.4.10. Formatos de los mensajes
A.5. Tablas de transición de estados de protocoloA.5.1. Introducción
A.5.2. Definiciones de estado
A.5.3. Eventos posiblesA.5.4. TemporizadoresA.5.5. Tabla de transición de estadosA.5.6. Diagrama de transición de estados
ANEXO B (NORMATIVO) PROTOCOLO DE CABECERA DE MENSAJES
B.1. IntroducciónB.2. Servicio desarrolladosB.3. Servicios necesariosB.4. Especificación de protocoloB.4.1. Establecimiento de conexiónB.4.2. Medidas para evitar conexiones de red redundantesB.4.3. Finalización de conexiónB.4.4. Transferencia de datos
ANEXO C (NORMATIVO) PROTOCOLO DE RED
C.1. IntroducciónC.2. Servicios proporcionadosC.3. Servicios necesariosC.4. Direcciones NSAPC.4.1. IntroducciónC.4.2. Estructura de la dirección NSAPC.4.3. Asignación de identificadores y selectores de un organismo ATCC.5. Especificación de protocoloC.5.1. ResumenC.5.2. Codificación de las direccionesC.5.3. Codificación del campo de datos de usuario
C.5.4. Tratamiento de las direcciones en los paquetes INCOMING CALL
C.5.5. Transferencia de datos
ANEXO D (NORMATIVO) FORMULARIOS PICS DE ESPECIFICACIONES DE PERFIL
D.1. Introducción
D.2. Instrucciones para cumplimentar los formularios PICS
D.2.1. Estructura general de los formularios PICSD.2.2. Información adicionalD.2.3. Información excepcionalD.2.4. Elementos condicionalesD.3. Formulario PICS para el Protocolo de Transferencia de MensajesD.3.1. Abreviaturas y símbolos especiales2000R2082 — ES — 15.06.2002 — 001.001 — 156
▼B
D.3.2. Identificación
D.3.3. Desarrollo del protocolo
D.4. Formulario PICS para el Protocolo de Cabecera de MensajeD.4.1. Abreviaturas y símbolos especialesD.4.2. IdentificaciónD.4.3. Desarrollo del protocoloD.5. Formulario PICS para el Protocolo de RedD.5.1. Abreviaturas y símbolos especialesD.5.2. Identificación
D.5.3. Desarrollo de protocolo
ANEXO E (NORMATIVO) LISTA DE REQUISITOS DE PERFIL
E.1. IntroducciónE.2. El papel de las PRL y de los formularios PICSE.3. NotaciónE.4. Instrucciones para cumplimentar los formularios PICSE.5. ReferenciasE.6. Declaración de conformidadE.6.1. Presentación general de conformidad
E.6.2. Requisitos de conformidad dinámica
E.7. Requisitos de la capa superiorE.8. Requisitos de la capa inferiorE.8.1. Requisitos de la capa de transporteE.8.2. Requisitos de la capa de redE.8.3. Requisitos de la capa de enlace de datosE.8.4. Requisitos de la capa física
ANEXO F (INFORMATIVO) MÉTODOS DE PRUEBA DE CONFORMIDAD
F.1. Introducción
F.2. Propósito y alcance
F.3. BibliografíaF.4. Métodos y prácticas de desarrolloF.5. PruebasF.5.1. IntroducciónF.5.2. Prueba de las capas inferiores (Capas 1 — 3)F.5.3. Prueba de la capa de aplicaciónF.5.4. Certificación
F.5.5. Notificación
ANEXO G (INFORMATIVO) ASIGNACIÓN DE IDENTIFICADORES DE ORGANISMO ATC
ANEXO H (INFORMATIVO) DIRECTIVAS SOBRE FIABILIDAD, DISPONIBILIDAD Y SEGU-
RIDAD
H.1. Introducción2000R2082 — ES — 15.06.2002 — 001.001 — 157
▼B
H.2. Propósito y alcance
H.3. BibliografíaH.4. Desarrollos en línea dedicada
H.4.1. Fiabilidad
H.4.2. DisponibilidadH.4.3. SeguridadH.4.4. Ejemplo de configuraciónH.5. Desarrollo de redH.5.1. FiabilidadH.5.2. DisponibilidadH.5.3. SeguridadH.6. Directivas generales para los desarrollos de línea dedicada y de redH.6.1. FiabilidadH.6.2. DisponibilidadH.6.3. Gestión de sistemasH.6.4. Ejemplo de configuración2000R2082 — ES — 15.06.2002 — 001.001 — 158
▼B
DERECHOSDEAUTOR
Este documento ha sido elaborado por Eurocontrol.
Los derechos de autor pertenecen a EurocontrolSi bien el contenido o cualquier parte del mismo está libremente a disposi-
ción de los representantes de los Estados miembros, su copia o divulgación
a un tercero estará sujeta a la autorización previa de Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 159
▼B
PRÓLOGO
1.Órganoresponsable
La presente Norma ha sido preparada por el grupo de operaciones
de Intercambio de Datos relativos a planes de vuelo (FPDE) de la
Organización Europea para la Seguridad de la Navegación Aérea
(Eurocontrol), quien se encarga de su actualización.
2.ProgramadeTrabajoEATCHIP
La presente Norma está relacionada con la Tarea especializada no
12, Tarea ejecutiva 01, Dominio de comunicaciones, del Docu-
mento de Programa de Trabajo EATCHIP (EWPD)
3.AprobacióndelaNorma
3.1. La presente Norma se adopta de acuerdo a los procedimientos
expuestos en las Directivas de Normalización de Eurocontrol,
Ref. 000-2-93.
3.2. La presente Norma entrará en vigor tras su adopción por la Comi-
sión Permanente de Eurocontrol y sustituirá a la Norma
Eurocontrol para el Intercambio de datos en línea (OLDI),
Edición 1, Parte 3: REQUISITOS TÉCNICOS (Documento de
control de interfaz a corto plazo) Ref. 001-3-92.
4.RectificacionesTécnicasyEnmiendas
La presente Norma se mantiene en revisión para verificar las
enmiendas o rectificaciones técnicas necesarias. El procedimiento
para la actualización de la presente Norma se describe en el
Anexo H de las Directivas para la presentación y redacción
uniforme de las Normas Eurocontrol Ref. 000-1-92.
5.Convencioneseditoriales
5.1. El formato de la presente Norma cumple las Directivas para la
presentación y redacción uniforme de las Normas Eurocontrol.
5.2. Para indicar el estado de cada elemento, se ha usado la siguiente
notación:
— Los elementos normativos emplearán el tiempo verbal futuro
«deberá» y estarán impresos en caracteres ordinarios;
— Los elementos recomendados emplearán la forma condicional
del verbo «debería» y estarán impresos en caracteres cursivos,
e irán precedidos por la palabra Recomendación .
5.3. Cualquier otra información que se considere esencial para el
entendimiento de un determinado concepto se incluirá en el texto
como NOTA. Una nota se considera de carácter informativo, por
lo tanto no contiene especificaciones, y se sitúa inmediatamente
después del concepto al que se refiere.
5.4. De forma excepcional, para presentar de forma adecuada la Lista
de requisitos de perfil (PRL) en el Anexo E, algunas tablas no
estarán sangradas ni se continuarán en varias páginas.
6.RelaciónconotrasNormas
6.1. La presente Norma Eurocontrol reemplaza al Documento OLDI
de Control de interfaz a corto plazo (ST-ICD), Parte 3, Edición
1 de la Norma Eurocontrol OLDI [Referencia 13].
6.2. La presente Norma Eurocontrol es la primera parte de una serie
de Documentos de control de interfaz (ICD) de Eurocontrol para
el Intercambio de datos de vuelo.
7.EstadodelosAnexosalapresenteNorma
Los Anexos a la presente Norma tienen el siguiente estado:
— Anexo A — Normativo
— Anexo B — Normativo
— Anexo C — Normativo— Anexo D — Normativo— Anexo E — Normativo
— Anexo F — Informativo2000R2082 — ES — 15.06.2002 — 001.001 — 160
▼B
— Anexo G — Informativo
— Anexo H — Informativo
8.Lenguajeutilizado
Se ha utilizado el idioma inglés en la preparación del presente
documento.2000R2082 — ES — 15.06.2002 — 001.001 — 161
▼B
1.INTRODUCCIÓN
La presente Norma Eurocontrol se basa en el Documento de
control de interfaz a corto plazo desarrollado por el antiguo
Subgrupo Técnico OLDI que estuvo a cargo de la definición de
las nuevas normas de interfaz para la explotación futura de
OLDI entre Centros de control de área.
Los enlaces OLDI iniciales se basaban en protocolos propios tales
como INTERCAUTRA o Datenübertragungs- und Vertei-
lungssystem (DÜV), que funcionaban sobre circuitos dedicados
punto a punto o de redes limitadas y requerían la utilización de
hardware y software especializado.
Cuando se planeó establecerun númer o mayorde enlaces, se vio
la necesidad de cambiar a una arquitectura basada en red y
adoptar la normativa de telecomunicaciones internacional, esta-
bleciendo enlaces que se implementaran de una forma más
rentable gracias a la reducción del número de conexiones en
cada Centro y permitiendo el uso de hardware y software estándar
disponible en el mercado.
La presente Norma Eurocontrol formaliza y amplía el ICD a
corto plazo. El ST-ICD se ha reescrito con el fin de proporcionar
una especificación más rigurosa que facilitará la interoperatividad
y, además, servirá de punto de partida para la elaboración de los
futuros ICD y podrá responder a la evolución de los requisitos
para el Intercambio de datos de vuelo (FDE), incluyendo una
utilización mayor de las redes compartidas y la introducción de
normas nuevas para las capas inferiores. La presente Norma
Eurocontrol proporciona un conjunto mínimo de funciones que
pueden serutilizadas porlas instalaciones OLDI existentes con
modificaciones mínimas, usando bien enlaces punto a punto o
bien redes de conmutación de paquetes conformes a la recomen-
dación X.25 del Comité Consultivo Internacional de Teléfonos y
Telégrafos (CCITT) de 1980 o versiones posteriores. Se pueden
especificar otras posibilidades para su aplicación. El presente
Documento de control de interfaz no impide la ampliación de
los acuerdos bilaterales.
Las instalaciones que deseen llevar a cabo otros protocolos de
aplicación para complementar o sustituir al descrito en este docu-
mento pueden o bien solicitaruna enmienda al pr esente
protocolo, o bien separar su protocolo mediante el uso de
circuitos virtuales diferentes.
2.ALCANCE
2.1. La presente Norma Eurocontrol especifica una interfaz de comu-
nicaciones de datos para el intercambio de mensajes de datos
relativos al vuelo entre Centros de control de área (ACC). Se
presenta en forma de un perfil de Interconexión de sistemas
abiertos (OSI) según la definición dada en el Informe Técnico
(TR) 10000-2 de la Organización Internacional de Normaliza-
ción/Comisión Internacional Electrotécnica (ISO/IEC)
[Referencia 3]. El perfil trata tanto las capas inferiores (Perfil T)
como las superiores (Perfil A).
2.2. La presente Norma Eurocontrol es aplicable en las siguientes
circunstancias:
— apoyo de OLDI como se expone en la Norma Eurocontrol No
001-92 Edición 1;
— apoyo a la transmisión de mensajes de aplicación OLDI desde
las ACC a los sistemas de la Unidad central de gestión de
flujo (CFMU).
2.3. La Norma es aplicable a conexiones que utilicen:
— circuitos punto a punto de línea dedicada, o
— circuitos punto a punto de Red Telefónica Conmutada Pública
(PSTN), o
— redes de datos de conmutación por paquetes o redes interco-
nectadas de datos de conmutación porpaquetes, que
proporcionen una interfaz conforme a la Recomendación
X.25 de CCITT de 1980 o posterior.
NOTAS
1. La configuración entre Sistemas de tratamiento de planes de
vuelo (FPPS) se presenta en la Figura 1.2000R2082 — ES — 15.06.2002 — 001.001 — 162
▼B
2. La Figura 1 no contempla posibles conexiones de seguridad,
tales como PSTN, las cuales se dan en el Anexo H.
Figura 1
Configuración de interfaz
2.4. En la presente Norma no se contemplan aspectos detallados de la
seguridad de la interfaz especificada de comunicaciones de datos.
Sin embargo, en el Anexo se especifican unas disposiciones gene-
rales, y en el Anexo H de la presente Norma Eurocontrol se
encuentran otras indicaciones.
3.REFERENCIAS
3.1.Introducción
Los siguientes documentos y normas contienen las disposiciones
que, mediante la referencia en este texto, constituyen las disposi-
ciones de la presente Norma de Eurocontrol.
Las ediciones indicadas son las que estaban en vigoren el
momento de la publicación de la presente Norma de Eurocontrol.
Cualquier revisión de los documentos de la Organización Interna-
cional de Aviación Civil (ICAO) deberán considerarse
inmediatamente para revisar la presente Norma Eurocontrol.
Las revisiones de otros documentos citados en las referencias no
deberán formar parte de las disposiciones de la presente Norma
Eurocontrol hasta que no sean revisadas e incorporadas formal-
mente en la presente Norma Eurocontrol.
En caso de conflicto entre los requisitos de la presente Norma de
Eurocontrol y el contenido de aquellos otros documentos
incluidos en las referencias, prevalecerá la presente Norma Euro-
control.
3.2.Referencias
1. Recomendación X.25 (1993) (Rev. 1) de ITU-T, Interfaz
entre equipo terminal de datos (DTE) y equipo de termina-
ción de circuito de datos (DCE) para terminales que
funcionen en modo paquete y que estén conectados a redes
públicas de datos mediante circuitos dedicados.
2. ISO/IEC TR 10000-1:1992, Tecnología de la información —
Marco y taxonomía de los perfiles normalizados internacio-
nales — Parte 1: Marco (2aedición).
3. ISO/IEC TR 10000-2:1994, Tecnología de la Información —
Marco y taxonomía de los perfiles normalizados internacio-
nales — Parte 2: Principios y taxonomía para perfiles OSI
(3aedición).2000R2082 — ES — 15.06.2002 — 001.001 — 163
▼B
4. Recomendación X.21 (1992) (Rev. 1) de ITU-T, Interfaz
entre equipo terminal de datos (DTE) y equipo de termina-
ción de circuito de datos (DCE) para operación síncrona en
redes públicas de datos.
5. Recomendación X.21bis (1988) de CCITT, Utilización en
redes públicas de datos de equipo terminal de datos (DTE)
diseñado para la interfaz de módems síncronos de la serie V.
6. ISO/IEC 7776:1994, Tecnología de la información — Tele-
comunicaciones e intercambio de información entre sistemas
— Procedimientos de control de enlace de datos de alto nivel
— Descripción de los procedimientos de enlace de datos
DTE compatible con X.25 LAPB (2aedición).
7. ISO/IEC 8208:1993, Tecnología de la información — Comu-
nicación de datos — Protocolo X.25 de capa de paquete para
equipo terminal de datos (3aedición).
8. ISO/IEC ISP 10609-9:1992, Tecnología de la información —
Perfiles normalizados internacionales TB, TC, TD y TE —
Servicio de transporte en modo conexión sobre un servicio
de red en modo conexión — Parte 9: Requisitos para la
capa de red, capa de enlace de datos y capa física depen-
diendo del tipo de subred, relativos al acceso permanente a
una red de datos de conmutación por paquetes utilizando
comunicaciones virtuales.
9. ISO/IEC 7498-1:1994, Tecnologías de la información —
Interconexión de sistemas abiertos — Modelo de referencia
básico: El modelo básico (2aedición).
10. ISO/IEC 8348:1993, Tecnología de la información — Inter-
conexión de sistemas abiertos — Definición del servicio de
red (1aedición).
11. ISO/IEC 8072:1994, Tecnología de la información — Inter-
conexión de sistemas abiertos — Definición del servicio de
transporte (2aedición).
12. ISO/IEC 8878:1992, Tecnología de la información — Tele-
comunicaciones e intercambio de información entre sistemas
— La utilización de X.25 para proporcionar servicio de red
de modo de conexión OSI (2aedición).
13. Norma Eurocontrol para el intercambio de datos en línea
(OLDI), No001-92, Edición 1, 1992.
14. ISO/IEC 9646-1:1994, Tecnología de la información —
Interconexión de sistemas abiertos — Marco general y meto-
dología de ensayos de conformidad — Parte 1: Conceptos
generales (2aedición).
15. Eurocontrol (Maastricht Upper Area Control (UAC) Systems
Division) FDE ICD Parte 1 Plan de ensayos de integración,
Versión 1.0, de fecha 10 de mayo de 1996.
16. Eurocontrol FDE ICD Parte 1 — Fiabilidad, disponibilidad y
seguridad — Informe técnico versión 1.0, de fecha 20 de
abril de 1997.
17. Recomendación X.32 (1993) (Rev. 1) de ITU-T, Interfaz
entre DTE y DCE para terminales funcionando en modo
paquete y teniendo acceso a una red pública de datos conmu-
tados porpaquete mediante una r ed telefónica conmutada
pública, o una red digital de servicios integrados, o una red
pública de datos en conmutación de circuitos.
18. Recomendación E.164 (1991) (Rev. 1) de ITU-T, Plan de
numeración para la era RDSI.
19. Recomendación X.75 (1993) (Rev. 1) de ITU-T, Sistema de
señalización de conmutación por paquetes entre redes
públicas proporcionando servicio de transmisión de datos.
20. Recomendación X.121 (1993) de ITU-T, Plan de numeración
internacional para redes públicas de datos.2000R2082 — ES — 15.06.2002 — 001.001 — 164
▼B
4.DEFINICIONES,SÍMBOLOSYABREVIATURAS
4.1.Definiciones
4.1.1. A los efectos de la presente Norma Eurocontrol, se aplicarán las
siguientes definiciones:
4.1.2. Perfil: Un conjunto de una o más normas básicas y, en su caso,
la identificación de clases, subconjuntos, opciones y parámetros
de esas normas básicas, necesarias para el cumplimiento de una
determinada función [Referencia 2].
4.1.3. Lista de requisitos de perfil (PRL) : Los requisitos de perfil se
expresan en forma de requisitos de conformidad y se representan
en forma de tabla [Referencia 2].
4.1.4. Perfil T : El Perfil de transporte proporciona un servicio de trans-
porte en modo conexión [Referencia 3].
4.1.5. Perfil A : El Perfil de aplicación necesita de un servicio de trans-
porte en modo conexión [Referencia 3].
4.1.6. Declaración de conformidad de una instancia de protocolo
(PICS) : Una declaración hecha por el proveedor de un sistema
OSI, indicando las capacidades que han sido desarrolladas para
un protocolo OSI dado [Referencia 14].
4.2.Símbolosyabreviaturas
En la presente Norma Eurocontrol, se usan los siguientes
símbolos y abreviaturas:
ACC Centro de control de área
AFI Identificador de autoridad y formatoASCII Código estándar americano para el inter-
cambio de información
ATC Control de tráfico aéreoATCC Centro de control de tráfico aéreo
CAUTRA Coordinador automático de tráfico aéreo
CCITT Comité consultivo internacional telegráfico
y telefónico (en la actualidad ITU-T)
CFMU Unidad central de gestión de flujoCUG Grupo de usuario cerrado
DCE Equipo terminal de circuito de datos
DCTS Sistema terminal de comunicaciones de
datos
DSP Parte específica de dominioDTE Equipo terminal de datosDÜV Datenübertragungs- und Verteilungssystem
FDE Intercambio de datos de vuelo
FEP Procesador frontalFPDE Intercambio de datos relativos al plan de
vuelo
FPPS Sistema de procesamiento del plan de vuelo
ICD Documento de control de interfaz
IDI Identificadorinicial de dominioIDP Parte inicial de dominioIEC Comisión electrotécnica internacionalINTERCAUTRA Protocolo Inter-CAUTRAISDN Red digital de servicios integradosISO Organización Internacional para la Normali-
zación
ITU-T Unión internacional de telecomunicaciones
— Sectorde nor malización de las telecomu-
nicaciones
LAPB Procedimiento de acceso al enlace equili-
brado (de modo simétrico)
LSB Bit menos significativo
M, m Obligatorio
MSB Bit más significativo2000R2082 — ES — 15.06.2002 — 001.001 — 165
▼B
MT Transferencia de mensaje
NA No aplicableNS Servicio de red
NSAP Punto de acceso a servicio de red
NSDU Unidad de datos de servicio de redO, O.<n> Opcional, donde <n> es un número de refe-
rencia
o, o.<n> Opcional, donde <n> es un número de refe-
rencia
OACI Organización internacional de aviación civil
OLDI Intercambio de datos en líneaOSI Interconexión de sistemas abiertosPICS Declaración de conformidad de una
instancia de protocolo
PLP Protocolo de capa de paquete
PRL Lista de requisitos de perfil
PSTN Red telefónica conmutada pública
RDSI Red digital de sistemas integrados
ST-ICD Documento de control de interfaz a corto
plazo
SUT Sistema sometido a ensayo
T<x> Temporizador (donde <x> es una letra
sencilla o doble de referencia)
TA Adaptadorde ter minal
TSDU Unidad de datos de servicio de transporte
TPDU Unidad de datos de protocolo de transporteTR Informe técnico ISO
X Prohibido
x Excluido<item>: Elemento condicional (dependiente del valor
del elemento)
4.3.Notaciones
4.3.1. A los efectos de la presente Norma Eurocontrol, los valores bina-
rios o una secuencia de bits se expresan en formato hexadecimal
usando los símbolos 'd'H donde la letra d representa un dígito o
una secuencia de dígitos hexadecimales.
4.3.2. A los efectos de la presente Norma Eurocontrol, la representación
hexadecimal de una secuencia de bits está constituida por4 bits
juntos, desde el bit más significativo (MSB) hasta el bit menos
significativo (LSB).
NOTA A menos que se especifique lo contrario en las Normas
internacionales de referencia, una secuencia de bits se
transmite desde el MSB al LSB.
4.3.3. A los efectos de la presente Norma Eurocontrol, el estado del
soporte de funciones de una norma básica o de la presente Norma
Eurocontrol, deberá ir en letras mayúsculas (por ejemplo: M, O,
O.<n>, X). El significado exacto de cada símbolo de estado se
describe en los Anexos de la presente Norma Eurocontrol, antes
de su utilización.
4.3.4. Con el fin de definir la Parte 1 del perfil de FDE ICD en la
presente Norma Eurocontrol, el estado del soporte de funciones
de una norma básica o de la presente Norma Eurocontrol, deberá
iren letr as minúsculas (porejemplo: m, o, o.<n>, x).
NOTA Las funciones de las normas básicas que son condicio-
nales, opcionales o dependientes del valor, son más
precisas (E.3.1).2000R2082 — ES — 15.06.2002 — 001.001 — 166
▼B
5.RESUMENTÉCNICO
5.1.Composiciónverticaldelprotocolo
NOTA En la Figura 2 se muestra la disposición vertical (pila)
del protocolo para el perfil de la presente Norma Euro-
control. En la figura se sitúan los protocolos en el marco
del Modelo de referencia básico OSI[Referencia 9]
alineando la disposición vertical con las capas OSI
correspondientes. Sin embargo, la disposición verticaldel protocolo es una especificación para sistemas pre-
OSIy no admite muchas de las funciones que se permiten
en los protocolos OSIde las capas OSIcorrespondientes.
Figura 2
Disposición vertical de Protocolo
5.2.Estructuradelperfil
NOTAS
1. Como se muestra en la Figura 2, la disposición vertical del
perfil combina varios protocolos de capa inferior, en dónde
únicamente el protocolo X.25 en capa de paquete (PLP)
[Referencia 1] y sus protocolos complementarios X.21 [Refe-
rencia 4] y X.21bis [Referencia 5], están definidos en las
normas existentes ISO/IEC y de la Unión Internacional de
Telecomunicación — Sector de Normalización de las Teleco-
municaciones (ITU-T). Los protocolos de capas superiores se
definen en los Anexos (A, B y C) de la presente Norma Euro-
control.
2. Los requisitos de conformidad para el perfil se pueden referir
a estas especificaciones de la misma forma que las normas
externas y se indican en la Sección 6. Los requisitos deta-
llados se representan en forma de tabla de PRL (Anexo E) y
formularios PICS (los formularios para los protocolos defi-
nidos en los Anexos figuran en el Anexo D). La utilización de
estas PRL y formularios PICS para el desarrollo y/o adquisi-
ción se explica en el Anexo E.
5.3.Relaciónconversionesanterioresdelaespecificación
NOTAS1. El presente perfil se basa en el documento ST-ICD desarro-
llado por el antiguo Subgrupo técnico OLDI. Los protocolos
y formatos de paquete definidos en la presente Norma Euro-2000R2082 — ES — 15.06.2002 — 001.001 — 167
▼B
control son un subconjunto compatible de los del documento
ST-ICD con la excepción de que la presente Norma Eurocon-
trol define de forma más detallada los requisitos para el uso
del PLP X.25, incluyen el uso obligatorio del bit M y corrigen
la falta de coherencia de la especificación del valor del Iden-
tificador de autoridad y formato (AFI) en la dirección del
Punto de acceso al servicio de red (NSAP).
2. La principal modificación en el estilo de la presente Norma
Eurocontrol guarda relación con la estructura de la especifi-
cación del ICD. El Protocolo de transferencia de mensaje
(Anexo A) está separado del perfil T que lo completa. Esto
facilitará el uso de otros perfiles T puesto que se hace nece-
sario para la evolución de los requisitos FDE.
3. Las partes de la especificación del ST-ICD que tratan el
control de circuitos virtuales X.25 y delimitan los mensajes
de aplicación aparecen en el Protocolo de cabecera de
mensaje (Anexo B), que constituye una capa de transporte
mínima para el FDE.
6.REQUISITOSDEPERFIL
6.1.Requisitosdeconformidad
6.1.1. Cualquier implantación que se declare conforme con la presente
especificación deberá satisfacer todos los requisitos estipulados
en las secciones 6.2 y 6.3 siguientes.
6.1.2. Cualquier declaración de conformidad deberá estar acompañada
de una Declaración de conformidad de una instancia de perfil,
tal y como se describe en los Anexos D y E.
6.2.Requisitosdelascapassuperiores
6.2.1. Una implantación conforme deberá satisfacer los requisitos de la
norma básica, que se indican en el Anexo A.
6.2.2. Una implantación conforme deberá satisfacer las restricciones
estipuladas en la lista de requisitos de perfil que figura en el
Anexo E.7.
6.3.Requisitosdelascapasinferiores
6.3.1. Requisitos de la capa de transporte
6.3.1.1. Una implantación conforme deberá satisfacer los requisitos de la
norma básica, que se indican en el Anexo B.
6.3.1.2. Una implantación conforme deberá satisfacer las restricciones
estipuladas en la lista de requisitos de perfil que figura en el
Anexo E.8.1.
6.3.1.3. Una implantación conforme deberá satisfacer el requisito de
admitir tamaños de la Unidad de datos de servicio de transporte
(TSDU) de hasta 4 097 octetos inclusive.
NOTA El primer octeto de la TSDU corresponde a un campo
Cabecera de mensaje (véase A.4.10 y B.4.4), lo cual
deja un máximo de 4 096 octetos para los datos del
usuario.
6.3.2. Requisitos de la capa de red
6.3.2.1. Una implantación conforme deberá satisfacer los requisitos de la
norma ISO/IEC 8208 [Referencia 7] de acuerdo con la relación
de protocolos que aparecen en el Anexo C.
6.3.2.2. Una implantación conforme deberá satisfacer las restricciones
estipuladas en la lista de requisitos de perfil que figura en el
Anexo E.8.2.
6.3.2.3. Una implantación conforme deberá de ser capaz de configurar, si
se soporta el funcionamiento del equipo terminal de datos (DTE)-
DTE, mediante mecanismos de gestión del sistema, la elección de
la función DTE o de equipo terminal de procesamiento de datos
(DCE) para el funcionamiento DTE-DTE.
6.3.2.4. Una implantación conforme deberá, en cada una de las funciones
definidas en 6.3.2.3, sercapaz de iniciaruna conexión de acuer do
con la especificación del Anexo C, porejemplo: el pr otocolo es
totalmente simétrico.2000R2082 — ES — 15.06.2002 — 001.001 — 168
▼B
NOTA Puede que alguna de las implantaciones existentes
basadas en el ST-ICD no sean capaces de iniciar cone-
xiones de red de acuerdo con el protocolo del Anexo C.
6.3.2.5. Una implantación conforme deberá cumplir durante un período de
tiempo con el servicio de Tamaños de paquetes por defecto no
estándar, con el valor 256 en las dos direcciones de transmisión.
6.3.2.6. Una implantación conforme deberá utilizar las direcciones NSAP,
tal y como se define en el Anexo C.
6.3.2.7. Una implantación conforme deberá poner el bit D a 0 en los
paquetes CALL REQUEST, CALL ACCEPTED y DATA.
NOTA Al establecer D=0 en los paquetes CALL REQUEST y
CALL ACCEPTED se dejan de utilizar la confirmación
de entrega.
6.3.3. Requisitos de la capa de enlace de datos
6.3.3.1. Una implantación conforme deberá satisfacer los requisitos de la
norma ISO/IEC 7776 [Referencia 6] para el protocolo de enlace
sencillo del Protocolo de acceso al enlace equilibrado (LAPB).
6.3.3.2. Una implantación conforme también deberá satisfacer las restric-
ciones descritas en la Lista de requisitos de perfil del Anexo E.8.3.
6.3.4. Requisitos de capa física
Una implantación conforme deberá satisfacer los requisitos de
conformidad de la norma ISO/IEC ISP 10609-9 cláusula 7 [Refe-
rencia 8].
7.MÉTODOSDEPRUEBA
NOTAS
1. En el Anexo F aparece una introducción a las pruebas desti-
nadas a evaluar la conformidad de la implantación de
acuerdo con la presente especificación.
2. La utilización de las PRL y los formularios PICS que se
proporcionan en esta especificación para documentar la
conformidad se expone en el Anexo E.2000R2082 — ES — 15.06.2002 — 001.001 — 169
▼B
ANEXO A (Normativo)
PROTOCOLODETRANSFERENCIADEMENSAJES
A.1.Introducción
La presente especificación define el protocolo para implantar un
servicio de transferencia de mensajes sencillo para aplicaciones que
necesitan el intercambio de datos de vuelo.
A.2.Serviciosdesarrollados
El protocolo de Transferencia de mensajes (MT) utiliza los
siguientes servicios no confirmados:
Asociación MT: establece una asociación de transferencia de
mensajes de aplicación;
Datos MT: transfiere un mensaje de aplicación compuesto de carac-
teres ASCII (Código estándar americano para el intercambio de
información);
Abandono MT: finaliza una asociación de transferencia de mensajes
de aplicación.
A.3.Serviciosnecesarios
Este protocolo de transferencia de mensajes necesita un subconjunto
del servicio de transporte en modo conexión, definido en la norma
ISO/IEC 8072 [Referencia 11], tal como el propuesto en el proto-
colo definido en el Anexo de la presente Norma Eurocontrol.
A.4.Especificacióndeprotocolo
A.4.1. Introducción
En el siguiente texto se describe únicamente el funcionamiento de
una asociación de transferencia de mensajes iniciada por la aplica-
ción. Se pueden mantener otras asociaciones en la misma interfaz
de red, mediante la repetición de estos procedimientos para cada
conexión de transporte de la capa de nivel inferior.
A.4.2. Tipos de datos
El presente Anexo identifica cuatro tipos de mensajes de aplicación
que son equivalentes a los definidos en la Norma Eurocontrol
No001-3-92 Edición 1:
Mensajes de sistema: Estos mensajes deberán ser usados para el
control del enlace (mensaje HEARTBEAT) y el control de la apli-
cación (mensajes STARTUP y SHUTDOWN).
Mensajes operativos: Estos mensajes deberán estar enlazados a un
contexto operativo específico y están definidos en los Documentos
y Normas Eurocontrol que hacen uso de la presente Norma para el
intercambio de datos. La Norma Eurocontrol para el intercambio dedatos en línea define los mensajes operacionales, tales como los
mensajes de activación (ACT), información de franqueo de límite
(ABI) y acuse de recibo lógico (LAM).
Mensajes de operador: Estos mensajes deberán contener un texto
libre. Su uso deberá ser acordado de forma bilateral. Por ejemplo,
pueden ser usados para el intercambio de información de prueba o
para informar a la otra parte sobre acciones del operador.
Mensajes de estado: El uso y contenido de estos mensajes deberá
ser acordado de forma bilateral. Por ejemplo, pueden ser utilizados
para intercambiar información sobre la gestión del sistema.
NOTAS
1. La utilización de los mensajes de sistema forma parte del funcio-
namiento de este protocolo, y su formato se especifica en el
párrafo A.4.10.3 de este Anexo.
2. La utilización y el formato de los mensajes de estado están
sujetos a acuerdos bilaterales y no se dan más especificaciones
en la presente Norma Eurocontrol.2000R2082 — ES — 15.06.2002 — 001.001 — 170
▼B
3. El estado del protocolo determina los tipos de mensaje que se
pueden transmitir, tal y como se indica en los siguientes
párrafos.
A.4.3. Establecimiento de una asociación
A.4.3.1. El protocolo comienza en el estado IDLE.
A.4.3.2. Para establecer una asociación de aplicación se ejecuta la solicitud
de asociación MT primitiva y el protocolo pasa al estado DATA_-
READY. La primitiva tiene que ser invocada por las dos
aplicaciones, local y remota.
A.4.3.3. Para establecer una conexión de transporte de capa de nivel inferior
es necesario, en primer lugar, seguir los procedimientos primitivos
de conexión T, descritos en el Anexo B, párrafo B.4.1, después de
lo cual el protocolo pasa al estado READY. En esta etapa sólo se
pueden transferir mensajes de sistema (y posiblemente, mediante
acuerdos bilaterales, mensajes de operador). Para transferir un
mensaje de sistema de operador, el emisor utiliza la primitiva de
datos T (véase B.4.4), con el mensaje como parámetro.
A.4.3.4. A continuación, se deberá transmitir un mensaje STARTUP
(mensaje de sistema), poner en marcha un temporizador Tr (véase
A.4.7) y el protocolo pasará al estado ASSOCIATION_PENDING.
Si el temporizador Tr termina mientras el protocolo está todavía en
este estado, se deberá volver a transmitir el mensaje STARTUP y el
temporizador deberá volver a empezar.
NOTA El protocolo permanecerá en el estado ASSOCIATION_-
PENDING hasta que se reciba un mensaje STARTUP. Se
podrían señalar localmente paradas continuas del tempori-
zador Tr.
A.4.3.5. La recepción de un mensaje STARTUP provocará las siguientes
acciones:
— En el estado ASSOCIATION_PENDING, se transmite un nuevo
mensaje STARTUP, el protocolo pasa al estado DATA_READY
y se señala la primitiva de indicación de asociación MT;
— En cualquier otro estado, se ignora el mensaje.
A.4.3.6. La recepción de mensaje STARTUP en el estado ASSOCIATION_-
PENDING corresponde a:
— que la aplicación remota emitió una primitiva de solicitud de
asociación MT y el protocolo de transferencia de mensajes ha
pasado al estado ASSOCIATION_PENDING, o
— que el protocolo de transferencia de mensajes remoto está
contestando a un mensaje STARTUP recibido previamente y ha
pasado al estado DATA_READY.
NOTA Esta incertidumbre ocurre debido a que se utiliza el mismo
mensaje para STARTUP y para responder al STARTUP.
Como consecuencia, el protocolo de Transferencia de
mensajes que pasa en primer lugar al estado DATA_READY
recibirá un nuevo mensaje STARTUP. Como se indica en el
apartado A.4.3.5, este mensaje STARTUP se ignora.
A.4.3.7. Una vez que se han intercambiado los mensajes STARTUP, se esta-
blece la asociación y se pueden transferir todos los tipos de
mensajes identificados (estado DATA_READY).
A.4.4. Transferencia de datos
De la misma manera que los mensajes de sistema se transfieren
otros tipos de mensajes, utilizando el servicio de datos T, con el
mensaje como parámetro. Esto se corresponde con las primitivas
de servicio de Solicitud de datos MT y de Indicación de datos MT.
NOTA Cada mensaje se envía como un único TSDU: a este nivel
no hay concatenación o segmentación de mensajes.
A.4.5. Terminación normal de la asociación
A.4.5.1. La asociación de transferencia de mensajes entre dos aplicaciones
puede ser terminada por cualquiera de ellas. Esto se corresponde
con la primitiva de servicio de Solicitud de abandono MT.2000R2082 — ES — 15.06.2002 — 001.001 — 171
▼B
A.4.5.2. Se deberán llevar a cabo las siguientes acciones:
— en el estado DATA_READY, se deberá transmitir un mensaje
SHUTDOWN (mensaje de sistema), los temporizadores Tr y Ts
se deberán parar, y se deberá finalizar la conexión de transporte;
— en el estado ASSOCIATION_PENDING, se deberá transmitir un
mensaje SHUTDOWN, el temporizador Tr se deberá parar, y se
deberá finalizar la conexión de transporte;
— en el estado READY se deberá finalizar la conexión de trans-
porte;
— en cualquier otro estado no se deberá ejecutar ninguna acción.
NOTA El mensaje SHUTDOWN no es un aviso previo — la asocia-
ción se termina inmediatamente. No hay confirmación de
este mensaje desde el otro lado.
A.4.5.3. La recepción de un mensaje SHUTDOWN provocará las acciones
siguientes:
— en el estado DATA_READY, el temporizador Ts (véase A.4.7)
se deberá parar, se señala una Indicación de abandono MT y la
interfaz pasa al estado ASSOCIATION_PENDING sin enviar un
mensaje STARTUP;
— en cualquier otro estado, no se llevará a cabo ninguna acción.
A.4.6. Restablecimiento de una asociación
La aplicación que inició la terminación de la asociación tiene la
responsabilidad, cuando está preparada, de restablecer la asociación
de la aplicación y cualquier nivel inferior (si es necesario).
NOTA Si la terminación de la asociación provoca la finalización
de la conexión de red de capa inferior, se debe seguir el
procedimiento de establecimiento de la asociación especifi-
cado en el párrafo A.4.3.
A.4.7. Integridad de la asociación
A.4.7.1. La integridad de la asociación entre dos aplicaciones está garanti-
zada porla función HEARTBEAT en r eposo.
A.4.7.2. Cuando se pasa al estado DATA_READY y se está transmitiendo
cualquier tipo de mensaje en la conexión de transporte, deberá
comenzar a contar un temporizador configurable Ts. Si el tempori-
zador Ts en estado DATA_READY, deberá transmitirse un mensaje
HEARTBEAT (mensaje de sistema) (y el temporizador deberá
volvera empezar ).
A.4.7.3. De forma similar, cuando se pasa al estado DATA_READY y se
está recibiendo en la conexión cualquier mensaje excepto el mensaje
STARTUP, deberá comenzar un temporizador configurable Tr. Si el
temporizador Ts finaliza en estado DATA_READY, se señala una
Indicación de abandono MT, se para la transmisión de todos los
mensajes, se para el temporizador Ts y el temporizador Tr vuelve
a empezar. La interfaz está en el estado ASSOCIATION_PEN-
DING.
NOTA La aplicación se recuperará y se volverá a sincronizar
mediante el intercambio de mensajes STARTUP (véase
A.4.3).
A.4.8. Terminación anormal de la asociación
A.4.8.1. La terminación anormal de una asociación puede producirse si:
— falla la conexión de transporte (por ejemplo, fallo en la línea o
error de protocolo),
— falla una de las dos aplicaciones o sistemas (puede serdebido a
un fallo de hardware o de software; en algunos casos, la cone-
xión de transporte de capa inferior puede todavía seguir
funcionando).
NOTA Según la definición de protocolo de transporte del Anexo B,
no existe una conexión de transporte extremo a extremo.
Por lo tanto, el fallo de la conexión de transporte es conse-
cuencia directa del fallo de la conexión de red.
A.4.8.2. Un fallo en una aplicación o sistema puede serdetectado mediante
la finalización de una pausa en la recepción de un mensaje HEART-
BEAT esperado (véase A.4.7) de esta aplicación.2000R2082 — ES — 15.06.2002 — 001.001 — 172
▼B
A.4.9. Recuperación tras un fallo
A.4.9.1. Se tienen que considerar dos casos:
— después de un fallo en la conexión de transporte;
— después de un fallo de aplicación.
A.4.9.2. En ambos casos, el restablecimiento implica el procedimiento
normal de establecimiento de la asociación (véase A.4.3), inclu-
yendo el intercambio de mensajes STARTUP.
NOTA En el caso de fallo de la aplicación a un nivel de aplicación
que no provoque la terminación de la conexión de capa
inferior, el sistema que haya fallado puede transmitir un
mensaje SHUTDOWN (por ejemplo, invocar un L_shutdown
de forma manual o bien como parte de una función lógica
de la aplicación) antes de intentar restablecer el enlace.
Esto disminuirá la pausa Tr de la aplicación remota y
puede dar como resultado una recuperación más rápida
con una menor probabilidad de pérdida de datos.
A.4.10. Formatos de los mensajes
A.4.10.1. Estructura general de los mensajes
Todos los mensajes se componen de un campo de tipo entero
(«TYP») con un rango de 1…63 seguido del cuerpo del mensaje.
El campo «TYP» está codificado en un octeto como un carácter
ASCII añadiendo '40'H a la representación binaria del campo (por
ejemplo, el valor 3 se codifica como '43'H, carácter «C»). El cuerpo
del mensaje está codificado en caracteres ASCII, uno por octeto. Se
obtiene el formato siguiente:
TYP Cuerpo de mensaje
octeto 1 octeto 2 …octeto n
A.4.10.2. L ongitud del cuerpo del mensaje
Deberán admitirse cuerpos de mensaje de longitud igual o inferior a
4 096 octetos.
A.4.10.3. Formatos de mensajes de sistema
Los mensajes de sistema se codifican con TYP = 4, codificados
como '44'H. El cuerpo del mensaje se compone de dos octetos, codi-
ficados de la siguiente forma:
— mensaje STARTUP: '3031'H (ASCII digits "01");
— mensaje SHUTDOWN: '3030'H (ASCII digits "00");— mensaje HEARTBEAT: '3033'H (ASCII digits "03").
A.4.10.4. Otros formatos de mensaje
El campo TYP define el tipo de mensaje, codificado como se ha
descrito anteriormente:
— valor1 (codificado como
'41'H)Mensajes operativos;
— valor2 (codificado como
'42'H)Mensajes de operador;
— valor5 (codificado como
'45'H)Mensajes de estado.
NOTAS
1. El formato del cuerpo del mensaje para los mensajes de estado
no entra en el alcance de la presente Norma Eurocontrol.
2. El formato de los mensajes operativos se especifica en los Docu-
mentos y Normas Eurocontrol que definen las aplicaciones de
mensajería, tales como el Intercambio de datos en línea
[Referencia 13].2000R2082 — ES — 15.06.2002 — 001.001 — 173
▼B
3. Los mensajes de operador se componen de texto ASCII impri-
mible. Si se admiten estos mensajes, se debe proporcionar una
interfaz de usuario para visualizar los mensajes recibidos y
permitir la composición de mensajes para la transmisión.
A.5.Tablasdetransicióndeestadosdeprotocolo
A.5.1. Introducción
Las tablas de estado que aparecen a continuación constituyen las
especificaciones definitivas del protocolo. En el caso de discre-
pancia con el texto principal anterior, prevalecerán las siguientes
especificaciones.
NOTA La notación utilizada para describir los estados, eventos,
temporizadores y acciones están basadas en ST-ICD. Sin
embargo, las siguientes definiciones y acciones resultantes
han sido revisadas y pueden diferir del ST-ICD.
A.5.2. Definiciones de estado
Tabla 1
Definiciones de estado
Estado Descripción del estado Información adicional del estado
estado 0 IDLE No hay conexión de transporte
estado 1 READY Conexión de transporte establecida,
usuario local no disponible, usuario
remoto no disponible
estado 2 ASSOCIATION_PEN-
DINGConexión de transporte establecida,
usuario local disponible, usuario
remoto no disponible
estado 3 DATA_READY Usuario local disponible, usuario
remoto disponible
A.5.3. Eventos posibles
Tabla 2
Eventos posibles
Descripción de
eventoInformación de estado adicional
L_data Indicación de que los datos (mensajes operativos, de operador, o
de estado) van a ser enviados del usuario local al remoto (primi-
tiva de Solicitud de datos MT)
L_shutdown Se ha dado una orden para parar el usuario local (Solicitud de
abandono MT)
L_startup Se ha dado una orden para arrancar el usuario local (Solicitud de
asociación MT)
R_data Indica que han sido recibidos los datos del usuario remoto (Indica-
ción de datos T, TYP ≠«System»)
R_heartbeat Se recibe un mensaje HEARTBEAT del usuario remoto (Indica-
ción de datos T, TYP = «System», Código de mensaje = HEART-
BEAT)
R_shutdown Se recibe un mensaje SHUTDOWN del usuario remoto (Indica-
ción de datos T, TYP = «System», Código de mensaje = SHUT-
DOWN)
R_startup Se recibe un mensaje STARTUP del usuario remoto (Indicación
de datos T, TYP = «System», Código de mensaje = STARTUP)2000R2082 — ES — 15.06.2002 — 001.001 — 174
▼B
Descripción de
eventoInformación de estado adicional
Ts_timeout Finalización del temporizador Ts
Tr_timeout Finalización del temporizador Tr
TC_disconnect Se ha recibido una indicación de terminación de conexión de
transporte (Indicación de desconexión T)
TC_setup Evento (porejemplo, or den explícita, solicitud de aplicación) que
provoca una primitiva de solicitud de conexión T)
A.5.4. Temporizadores
Tabla 3
Temporizadores
Temporizador Información de temporizador
TrTiempo a la esper a de un mensaje HEARTBEAT o de un mensaje
de datos
Ts Tiempo para el envío de un mensaje HEARTBEAT al usuario
remoto
Estos temporizadores deberán tener un valor tal que Tr = 2Ts +
tiempo de tránsito.
NOTA Los valores típicos para estos temporizadores son: Ts = 30s,
Tr = 70s.
A.5.5. Tabla de transición de estados
Tabla 4
Transición de estados
Estado Evento Acciones que deben emprenderse Estado nuevo
Estado 0 TC_setup La capa de transporte intenta esta-
blecerlas conexiones de la capa
inferior entre los usuarios local y
remoto; cuando la conexión se ha
establecido, el usuario es notifi-
cado (1)estado 1
TC_disconnect El sistema ejecuta las acciones
adecuadas pero permanece en el
estado 0estado 0
L_data Se ignora estado 0
L_shutdown
L_startup
Tr_timeout
Ts_timeout
R_data Se ignora (no debería ocurrir el
evento)estado 0
R_heartbeat
R_shutdown
R_startup2000R2082 — ES — 15.06.2002 — 001.001 — 175
▼B
Estado Evento Acciones que deben emprenderse Estado nuevo
Estado 1 L_startup El usuario local envía un mensaje
STARTUP al usuario remoto, se
inicia el temporizador Tr (2)estado 2
R_startup El usuario local recibe un mensaje
STARTUP del usuario remoto,
este mensaje STARTUP es igno-
rado ya que no ha ocurrido el
evento L_startupestado 1
L_data Se ignora estado 1
R_data
R_heartbeat
R_shutdown
TC_setup
Tr_timeout Se ignora estado 1
Ts_timeout
L_shutdown Se finaliza la conexión de trans-
porteestado 0
TC_disconnect Se notifica al usuario local de que
se desconecta la conexión de
transporte (por ejemplo, debido a
un error o a un shutdown remoto)estado 0
Estado 2 R_startup El usuario local recibe un mensaje
STARTUP del usuario remoto; se
inician los temporizadores Tr y Ts;
se notifica al usuario local de que
los datos pueden serenviados en
la asociación y se notifica explíci-
tamente la recepción del mensaje
STARTUP mediante el envío de
una respuesta con otro mensaje
STARTUP (3)estado 3
Tr_timeout El usuario local retransmite un
mensaje STARTUP si no recibe un
mensaje STARTUP del usuario
remoto dentro de un período de
tiempo Trespecificado, el tempo-
rizador Tr se reiniciaestado 2
L_startup Se ignora estado 2
L_data
R_data
R_heartbeat
R_shutdown
Ts_timeout
TC_setup
L_shutdown El usuario local es invitado a fina-
lizarla asociación: se tr ansmite un
mensaje SHUTDOWN, se para el
temporizador Tr y se termina la
conexión de transporteestado 0
TC_disconnect Se notifica al usuario local de que
se ha desconectado la conexión de
transporte (por ejemplo, debido a
un error), se para el temporizador
Try se finaliza la asociaciónestado 02000R2082 — ES — 15.06.2002 — 001.001 — 176
▼B
Estado Evento Acciones que deben emprenderse Estado nuevo
Estado 3 L_data Se reinicia el temporizador Ts estado 3
R_data Se reinicia el temporizador Tr estado 3
R_heartbeat
R_startup Si se recibe un mensaje STARTUP
del usuario remoto, se considera
como un acuse de recibo de un
mensaje STARTUP enviado
previamente; no se reinicia el
temporizador Trestado 3
Ts_timeout Se envía un mensaje HEART-
BEAT y se reinicia el tempori-
zadorTsestado 3
L_startup Se ignora estado 3 (4)
TC_setup
R_shutdown Se para el temporizador Ts; se
señala una indicación de abandono
MT al usuario localestado 2
Tr_timeout Se para el temporizador Ts. Se
señala una indicación de abandono
MT al usuario local; se reinicia el
temporizador Trestado 2
L_shutdown Se transmite un mensaje SHUT-
DOWN; se paran los temporiza-
dores Tr y Ts y se finaliza la
conexión de transporteestado 0
TC_disconnect El usuario local es notificado de
que la conexión de transporte ha
sido desconectada (porejemplo,
debido a un error); se paran los
temporizadores Tr y Ts y se fina-
liza la asociaciónestado 0
NOTAS
(1) Cuando se pasa al estado 0, se considera que se genera automáticamente el evento TC_setup.
(2) Únicamente en caso de pasaral estado 1 mediante un evento TC_setup gener ado automáticamente
como se describe en el estado 0, se puede generar automáticamente el evento L_startup.
(3) Este método garantiza que un mensaje STARTUP recibido de un usuario remoto es siempre reco-
nocido gracias a otro mensaje STARTUP.
(4) Algunos desarrollos anteriores a la presente Norma Eurocontrol, pueden tratar este evento como un
TC_disconnect, volviendo al estado 0.2000R2082 — ES — 15.06.2002 — 001.001 — 177
▼B
A.5.6. Diagrama de transición de estados
NOTA El protocolo está descrito en la Figura A.1 en forma de
diagrama de transición de estados. El diagrama es sólo
informativo: en el caso de conflicto entre el diagrama y
las tablas de estado anteriores, éstas deberán tener prio-
ridad.
Figura A.1
Protocolo de transferencia de mensajes: Diagrama de transición de
estados2000R2082 — ES — 15.06.2002 — 001.001 — 178
▼B
ANEXO B (Normativo)
PROTOCOLODECABECERADEMENSAJES
B.1.Introducción
El presente Anexo define el protocolo de cabecera de mensajes,
protocolo de transporte mínimo para ser utilizado por aplicaciones
tales como OLDI.
B.2.Serviciodesarrollados
B.2.1. El protocolo de cabecera de mensajes corresponde a un subconjunto
del servicio de transporte en modo conexión, tal y como se define en
el documento ISO/IEC 8072 [Referencia 11], y comprende las
siguientes primitivas de servicio.
Conexión T: establece una conexión de transporte para una aplicación
Datos T: transfiere datos ASCII
Desconexión T: finaliza la conexión de transporte de una aplicación
B.2.2. El servicio no permite la multiplexión, recuperación provocada por
un error, ni la segmentación ni recomposición.
B.3.Serviciosnecesarios
El protocolo necesita un servicio de red básico fiable como el que
proporciona el protocolo X.25 en capa de paquetes.
NOTA En cada conexión de red se permite una única conexión de
transporte.
B.4.Especificacióndeprotocolo
B.4.1. Establecimiento de conexión
La primitiva de conexión T deberá implantarse utilizando el servicio
de conexión N del servicio de red de capa inferior. Existe una corres-
pondencia directa entre los dos grupos de primitivas (solicitud,
indicación). Alternativamente, se puede utilizar una conexión de red
existente (porejemplo, una r ed establecida porlos mecanismos de
gestión del sistema).
Recomendaciones1. En el caso anterior, la conexión de red se debería reiniciar antes
de su uso. Se debería volver a enviar automáticamente la primi-
tiva conexión N si no se recibe ninguna respuesta en un período
determinado de tiempo.
2. Si se implanta esta repetición automática, se debería intentar
aproximadamente cada 15 s.
B.4.2. Medidas para evitar conexiones de red redundantes
Si una primitiva de solicitud de conexión N está pendiente (por
ejemplo, ha sido señalada una confirmación de conexión N no corres-
pondiente o una primitiva de desconexión N) y se señala una
indicación de conexión N, el intento de estableceruna conexión de
red deberá ser rechazado o finalizado mediante el envío de una primi-
tiva de solicitud de desconexión N, únicamente cuando se den las dos
condiciones siguientes:
— la dirección NSAP que emite la Indicación de conexión N es la
misma que la dirección NSAP que ha recibido la solicitud de
conexión N pendiente;
— la dirección NSAP que envía la solicitud de conexión N pendiente
es mayor que la dirección NSAP que recibe la solicitud de cone-
xión N pendiente, la comparación se hace en la cadena de bits
formados por la codificación binaria preferente de cada dirección
NSAP, según la definición estipulada en el documento ISO/IEC
8348 Anexo A [Referencia 10] (una cadena deberá ser conside-
rada mayor que cualquiera de sus subcadenas iniciales, por
ejemplo, '8800'H > '88'H).2000R2082 — ES — 15.06.2002 — 001.001 — 179
▼B
B.4.3. Finalización de conexión
B.4.3.1. La finalización de la conexión deberá utilizar las primitivas de
servicio desconexión N y reinicio N del servicio de red de capa infe-
rior.
B.4.3.2. Para realizar una solicitud de desconexión T, se deberá señalar una
solicitud de desconexión N. Por otra parte, si no es posible el estable-
cimiento de conexiones de red utilizando primitivas de conexión N,
la conexión de red no deberá ser finalizada explícitamente.
Recomendación En este último caso, se debería reiniciar la conexión
de red.
B.4.3.3. Se deberá señalar una indicación de desconexión T en la recepción en
cada una de las primitivas de servicio de red siguientes, en una cone-
xión de red correspondiente total o parcialmente con una conexión de
transporte establecida:
— Indicación de desconexión N;
— Indicación de reinicio N.
B.4.4. Transferencia de datos
B.4.4.1. La primitiva de datos T se deberá aplicar mediante el uso de la primi-
tiva de datos N del servicio de red de la capa inferior. Existe una
correspondencia directa entre los dos grupos de primitivas (solicitud,
indicación). La correspondencia se establece mediante el uso de la
unidad de datos de protocolo de transporte (TPDU) que es transferida
por el servicio de red.
B.4.4.2. La TPDU deberá tener el siguiente formato, transmitido de izquierda
a derecha, por lo que la estructura de mensajes definida en el párrafo
A.4.10.1 será insertada en los campos data(1), data(2)…data(n).
STX LENG ADEST DEST AEMM EMM data(1) ADRdata(2)…
data(n)ETX
'02'H '48'H '40'H '40'H '40'H '40'H '40'H '03'H
NOTAS
1. Se define así esta cabecera para que sea idéntica a la que se
utiliza en el procedimiento INTERCAUTRA definido para el inter-
cambio de mensajes ACT entre CAUTRA París, el sistema 9020D
del Centro de Control de Tráfico Aéreo de Londres y el Sistema
Terminal de Comunicaciones Digital (DCTS) de Maastricht/Karls-
ruhe, en el caso de transportar los formatos de mensaje definidos
en el Anexo A; en este caso el campo «data(1)» corresponde al
campo TYP.
2. El empleo de los campos ADEST, DEST, AEMM, EMM y ADR
con valores distintos a '40'H no entra en el alcance de la presente
Norma Eurocontrol, pero puede estar sujeto a acuerdos bilate-
rales.
B.4.4.3. El servicio de datos T deberá estar restringido a la transferencia de
datos en caracteres ASCII imprimibles. En particular, ninguno de los
octetos de datos deberá tener el valor '03'H (el carácter ETX, fin de
texto).
B.4.4.4. Una implantación conforme deberá satisfacer el requisito de admitir
tamaños de la Unidad de datos de servicio de red (NSDU) de hasta
4 105 octetos.
B.4.4.5. Una implantación conforme no deberá permitir la concatenación de
múltiples TSDU en una única NSDU.
B.4.4.6. Una implantación conforme no deberá permitir la segmentación de
una única TSDU en múltiples NSDU.2000R2082 — ES — 15.06.2002 — 001.001 — 180
▼B
ANEXO C (Normativo)
PROTOCOLODERED
C.1.Introducción
El presente Anexo especifica un Protocolo de red básico utilizando el
protocolo X.25 de capa de paquetes, para el uso en entornos de red
punto a punto y de conmutación por paquetes, para permitir la trans-
ferencia de datos de vuelo. El subconjunto de protocolo es
compatible con el definido en el documento [Referencia 1] en las
versiones posteriores a 1980.
C.2.Serviciosprestados
C.2.1. El protocolo desarrolla el Servicio de red OSI en modo conexión,
como se define en ISO/IEC 8348 [Referencia 10], con las siguientesexcepciones.
— las direcciones NSAP se limitan a la forma definida en el párrafo;
— no hay posibilidad de establecer un acuerdo entre los usuarios del
Servicio de red (NS) y el proveedor del NS sobre la calidad del
servicio asociado con una conexión de red;
— no se permite la transferencia de Datos de usuario del NS durante
el establecimiento y la terminación de la conexión de red excepto
para la condiciones descritas en el párrafo C.5.3.
C.2.2. No se ofrecen las siguientes opciones de proveedor del NS:
— Confirmación de recepción;
— Transferencia de datos acelerada.
C.3.Serviciosnecesarios
El protocolo supone la utilización de un Servicio de enlace de datos
OSI, como el definido en la norma ISO/IEC 7776 (LAPB) [Refe-
rencia 6].
C.4.DireccionesNSAP
C.4.1. Introducción
C.4.1.1. La estructura de las direcciones NSAP está de acuerdo a la definida
en ISO/IEC 8348 Anexo A [Referencia 10], como se muestra a conti-
nuación.
C.4.1.2. Los componentes de la dirección NSAP son los siguientes:
IDP: Parte inicial del dominio, que comprende los campos AFI y
IDI
AFI: Identificador de autoridad y formato
IDI: Identificadorde dominio inicial
DSP: Parte específica de dominio
C.4.2. Estructura de la dirección NSAP
C.4.2.1. A los efectos de la presente Norma Eurocontrol, los componentes de
la dirección deberán estar limitados de la siguiente forma.
C.4.2.2. Se deberá utilizar el valor AFI 48, indicando un formato local de IDI
con una sintaxis decimal abstracta.
C.4.2.3. El IDI es cero, siguiendo el formato local.2000R2082 — ES — 15.06.2002 — 001.001 — 181
▼B
C.4.2.4. El DSP deberá consistir de 2 pares de dígitos decimales, de la
siguiente forma:
— el primer par es un identificador de unidad de Control de Tráfico
Aéreo (ATC), el cual identifica un sistema ATC e indirectamente
una posición;
— el segundo pares un selectorde unidad ATC, el cual puede ser
utilizado para identificar un extremo dado en el interior de un
organismo ATC.
C.4.2.5. A continuación se muestra la estructura de la dirección NSAP resul-
tante.
AFI DSP
48 Identificadorde unidad
ATCSelectorde unidad ATC
C.4.3. Asignación de identificadores y selectores de unidad ATC
C.4.3.1. La asignación de identificadores de unidad ATC únicos para cada
sistema ATC será responsabilidad de Eurocontrol, mientras que los
selectores de unidad ATC serán asignados por la autoridad compe-
tente de la administración u organización ATC.
C.4.3.2. La distribución de los identificadores de unidad ATC en el momento
de la redacción de la presente Norma aparece en el Anexo G.
C.5.Especificacióndeprotocolo
C.5.1. Resumen
El protocolo está basado en el Protocolo de convergencia dependiente
de subredes para X.25(1980), definido en el Anexo A de ISO/IEC
8878 [Referencia 12], con las siguientes diferencias:
— no se utiliza la función de Selección rápida de usuario; sin
embargo, la codificación definida en el Anexo A de ISO/IEC
8878 [Referencia 12] para el uso con el campo Datos de usuario
de formato extendido disponible en la función Selección rápida,
se utiliza aquí con el campo Datos de usuario de formato básico
en los paquetes CALL REQUEST e INCOMING CALL, dado
que las restricciones en los parámetros de servicio de red permi-
tidos aseguran que la información codificada cabe en 16 octetos;
— de los parámetros de servicio de red para los que se define la
codificación en ISO/IEC 8878 [Referencia 12], sólo se envían
las direcciones NSAP emisoras o receptoras (y sólo en la forma
definida en ) en el paquete CALL REQUEST;
— el campo Datos de usuario no se utiliza en los paquetes CALL
ACCEPTED, CALL CONNECTED, CLEAR REQUEST o
CLEAR INDICATION;
— no se utilizan los procedimientos alternativos para el estableci-
miento y la terminación de la conexión de red;
— no se admite la confirmación de recepción usando el bit D.
NOTA De estas restricciones, las tres primeras aseguran que toda la
información que se transmita entre dos DTE respetará las
limitaciones del campo Datos de usuario de la PLP X.25
(1980).
C.5.2. Codificación de las direcciones
Las direcciones NSAP emisoras y receptoras deberán ser codificadas
utilizando la codificación binaria preferente definida en ISO/IEC
8348 Anexo A [Referencia 10].
C.5.3. Codificación del campo Datos de usuario
C.5.3.1. A consecuencia de los requisitos establecidos anteriormente, el
campo Datos de usuario en los paquetes CALL REQUEST e INCO-
MING CALL deberá ser codificado como se muestra a continuación.
Se deberán transmitir los 16 octetos.2000R2082 — ES — 15.06.2002 — 001.001 — 182
▼B
Tabla 1
Codificación del campo de datos de usuario
Descripción del campoSemiocteto de orden
altoSemiocteto de orden
bajo
Octeto 0: Identidad de protocolo Bin(1000) bin(0100)
Octeto 1: Tipo de código de mensaje Bin(0010) bin(0000)
Octeto 2: Valorde código de mensaje (N
CR)Bin(0000) bin(0001)
Octeto 3: Tipo de parámetro = NSAP
receptoraBin(1100) bin(1001)
Octeto 4: Longitud de parámetro Bin(0000) bin(0110)
Octeto 5: Valor de parámetro (1erocteto) =
valorAFIbin(0100) bin(1000)
Octeto 6: Valor de parámetro (2oocteto) =
identificadorde unidad ATCdígito de orden
altodígito de orden bajo
Octeto 7: Valor de parámetro (3erocteto) =
selectorde unidad ATCdígito de orden
altodígito de orden bajo
Octeto 8: Tipo de parámetro = NSAP
remitentebin(1100) bin(1011)
Octeto 9: Longitud de parámetro bin(0000) bin(0110)
Octeto 10: Valor de parámetro (1erocteto) =
valorAFIbin(0100) bin(1000)
Octeto 11: Valor de parámetro (2oocteto) =
identificadorde unidad ATCdígito de orden
altodígito de orden bajo
Octeto 12: Valor de parámetro (3erocteto) =
selectorde unidad ATCdígito de orden
altodígito de orden bajo
Octeto 13: Reservado para uso futuro bin(0000) bin(0000)
Octeto 14: Reservado para uso futuro bin(0000) bin(0000)
Octeto 15: Reservado para uso futuro bin(0000) bin(0000)
C.5.3.2. No deberán utilizarse los otros parámetros descritos en ISO/IEC 8878
[Referencia 12].
C.5.4. Tratamiento de las direcciones en los paquetes INCOMING CALL
C.5.4.1. Direcciones DTE
Las direcciones DTE emisoras en un paquete INCOMING CALL
deberán ser validadas por comparación con una lista local de direc-
ciones DTE remotas válidas para el sistema. Si se detecta una
dirección no válida, deberá determinarse la llamada.
NOTAS
1. La dirección DTE recibida, en su caso, en un paquete INCOMING
CALL, en su caso, también se puede validar opcionalmente por
comparación con una lista (normalmente de un elemento) de
direcciones DTE locales válidas del sistema.
2. En algunos casos la dirección DTE de una unidad puede diferir
en valor y/o longitud cuando la unidad está actuando como el
sistema emisor o receptor. Por lo tanto, se debe prestar especial
atención a este problema cuando se especifique o apliquen la
funcionalidad de validación de direcciones DTE.
C.5.4.2. Direcciones NSAP
Las direcciones NSAP emisoras codificadas como se ha descrito ante-
riormente en un paquete INCOMING CALL se deberán validar por
comparación con una lista local de direcciones NSAP remotas válidas
para el sistema. Si se detectara una dirección no válida, deberá termi-
narse la llamada.
NOTA La dirección NSAP receptora también puede opcionalmente
ser validada por comparación con una lista (normalmente2000R2082 — ES — 15.06.2002 — 001.001 — 183
▼B
de un elemento) de direcciones NSAP locales válidas para el
sistema.
C.5.5. Transferencia de datos
C.5.5.1. Como se describe en ISO/IEC 8878 Anexo A.5.3 [Referencia 12], las
NSDU se transfieren en el campo Datos de usuario como un paquete
DATA.
NOTA Como consecuencia, está prohibido transmitir más de un
mensaje de usuario, como un mensaje OLDI, por paquete
X.25 o secuencia de bit M.
C.5.5.2. Las NSDU de longitud superior al máximo permitido para los Datos
de usuario en el circuito virtual deberán ser segmentadas y transmi-
tidas en los campos Datos de usuario de una secuencia de paquetes
DATA, donde todos excepto el último deberán tener longitud máxima
y el bit M (secuencia de más bits).
C.5.5.3. A la recepción, los campos Datos de usuario de secuencia de más bits
deberán ser reensambladas para formar la NSDU receptora.2000R2082 — ES — 15.06.2002 — 001.001 — 184
▼B
ANEXO D (Normativo)
FORMULARIOSPICSDEESPECIFICACIONESDEPERFIL
D.1.Introducción
D.1.1. El proveedor de una implantación de protocolo que se declare
conforme a las especificaciones de los Anexos A-C deberá cumpli-
mentar los siguientes formularios PICS.
NOTA Derechos de autor aplicables a la difusión de los formularios
PICS: los usuarios de la presente Norma Eurocontrol podrán
reproducir libremente los formularios PICS que aparecen en
el presente Anexo, de forma que puedan ser utilizados para
el fin para el que han sido diseñados y podrán asimismo
publicar los PICS cumplimentados.
D.1.2. Un formulario PICS cumplimentado es el PICS para la implantación
en cuestión. El PICS es una declaración que indica las capacidades y
opciones del protocolo que han sido implantadas.
D.1.3. Los PICS pueden tenermúltiples usos, entr e los que se incluye la
utilización:
— por parte del implantador del protocolo, como lista de control
para reducir el riesgo de fallo de conformidad con la norma poromisión;
— por parte del proveedor y del comprador, o posible comprador, de
la implantación, como indicación detallada de las capacidades de
la implantación, expuesta en relación con la base común para el
entendimiento proporcionada por el formulario PICS estándar;
— por parte del usuario, o potencial usuario, de la implantación,
como base para la comprobación inicial de la posibilidad de inter-
conexión con otra implantación (destacar que aunque la
interconexión nunca puede estar garantizada, a menudo se puede
predecir el fallo de interconexión a causa de PICS incompatibles);
— por parte del probador del protocolo, como base para la selección
de pruebas apropiadas mediante las que se asegure el cumpli-
miento de la conformidad de la implantación.
D.2.InstruccionesparacumplimentarlosformulariosPICS
D.2.1. Estructura general de los formularios PICS
D.2.1.1. El Resumen de identificación y protocolo de implantación es la
primera parte de cualquier formulario PICS y deberá ser cumplimen-
tado como se indica, con la información necesaria para identificar
perfectamente tanto al proveedor como a la implantación.
D.2.1.2. La parte principal del formulario PICS está constituido por un cues-
tionario de formato fijo. Las respuestas a las diversas cuestiones
deberán proporcionarse en la columna de la derecha, mediante una
simple marca en la respuesta indicando la opción (normalmente Sí o
No) o introduciendo un valor, conjunto o rango de valores.
NOTAS1. Cada elemento está identificado por una única referencia en la
primera columna; en la segunda columna figura el texto de la
pregunta; en la tercera columna está la referencia o referencias
a la información que especifica el elemento en la presente Norma
Eurocontrol. El resto de las columnas se utilizan para indicar el
estado del elemento (obligatorio, opcional, prohibido o condi-
cional) y proporciona espacio para las respuestas: véase también
el párrafo D.2.4.
2. Un proveedor también puede proporcionar, o se le puede exigir
que proporcione, más información clasificada como Información
complementaria o Información excepcional. Cada tipo de informa-
ción adicional, en su caso, se proporcionará como una
subcláusula complementaria de elementos, etiquetada A<i> o
X<i> respectivamente a efectos de referencia cruzada, donde
<i> representa cualquier identificación no ambigua del elemento
(p. ej., un simple número): no hay más restricciones en su formato
o presentación.
D.2.1.3. Un formulario PICS cumplimentado, que incluya cualquier Informa-
ción complementaria o excepcional, deberá tomarse como2000R2082 — ES — 15.06.2002 — 001.001 — 185
▼B
Declaración de conformidad de la implantación del protocolo para la
implantación en cuestión.
NOTA Cuando sea posible configurar una implantación de más de
una forma, un solo PICS podrá describir todas las configu-
raciones. Sin embargo, queda a elección del proveedor el
proporcionar más de un PICS, cada uno de los cuales
cubrirá un subconjunto de posibilidades de configuración
de la implantación, cuando ello suponga una presentación
más simple y clara de la información.
D.2.2. Información complementaria
Los elementos de Información complementaria permiten a un
proveedor proporcionar más información con el fin de ayudar a inter-
pretar el PICS.
NOTAS
1. No se prevé ni se pretende que se suministre una gran cantidad de
información complementaria, y se puede considerar que un PICS
está completo sin necesidad de recurrir a este tipo de informa-
ción. Un ejemplo puede ser una reseña de las formas en las que
se puede configurar una implantación (única) para funcionar en
diversos entornos y configuraciones o una breve explicación
(basada quizás en las necesidades de una aplicación específica)
de los motivos de exclusión de ciertas funciones que, aunque
opcionales, normalmente están presentes en las implantaciones
del protocolo en cuestión.
2. Se podrán introducir referencias a elementos de Información
complementaria a continuación de cualquier respuesta en el cues-
tionario y podrán estar incluidas en elementos de Información
excepcional.
D.2.3. Información excepcional
D.2.3.1. Ocasionalmente puede suceder que un proveedor quiera responder a
un elemento con un estado obligatorio o prohibido (tras la aplicación
de cualquier condición) de forma que entre en conflicto con el requi-
sito indicado. En este caso no existirá ninguna respuesta previamente
impresa en la columna Soporte. En su lugar, el proveedor deberá
escribir la respuesta que falte en la columna Soporte, junto con unareferencia X<i> para un elemento de Información excepcional.
D.2.3.2. El proveedor deberá proporcionar la justificación apropiada al
elemento excepcional.
D.2.3.3. Una implantación que requiera un elemento excepcional en estas
condiciones no cumplirá la presente especificación.
NOTA Una posible razón para la situación descrita anteriormente
es que se haya informado de un defecto en la norma, cuya
la corrección se prevé que cambie el requisito incumplido
por la implantación.
D.2.4. Elementos condicionales
D.2.4.1. Los elementos condicionales individuales se indican mediante un
símbolo condicional de la forma «<item>: 
» en la columna
Estado, donde «<item>» designa una referencia que aparece en la
primera columna de la tabla para algún otro elemento y «
» es un
símbolo de estado, M, O, O.<n> o X.
NOTA Un formulario PICS puede contener varios elementos condi-
cionales. Para estos elementos la aplicación del propio
elemento, y su estado, en caso de ser aplicable (obligatorio,
opcional o prohibido) dependen de cómo se admitan otros
elementos.
D.2.4.2. Si el elemento al que hace referencia el símbolo condicional está
marcado como admitido, el elemento condicional es aplicable y su
estado vendrá dado por «
»: la columna Soporte deberá cumpli-
mentarse en la forma habitual. De no ser así, el elemento
condicional no es pertinente y la respuesta deberá marcarse como
No Aplicable (NA).
D.2.4.3. Cada elemento afectado de un símbolo condicional se resaltará con
un asterisco en la columna Elemento.2000R2082 — ES — 15.06.2002 — 001.001 — 186
▼B
D.3.FormularioPICSparaelProtocolodetransferenciademensajes
D.3.1. Abreviaturas y símbolos especiales
D.3.1.1. Símbolos de estado
M: ObligatorioO: Opcional
D.3.1.2. Referencias de elemento
Los elementos en el formulario PICS se identifican mediante el
empleo de referencias mnemónicas. Los elementos con funciones
relacionadas se identifican con referencias que tienen la misma letra
o par de letras iniciales (en mayúsculas). A continuación se presenta
una lista de estas iniciales, en orden de aparición en los grupos de
elementos del formulario PICS.
— MTsy, MTop, MTst, MTortipos de mensaje
— MAE, MAR, MCI, MDT,
MAVprocedimientos
— MEsu, MEsd, MEhb, MEty códigos
— MNmsg tamaños de mensaje— Ts, Tr temporizadores
D.3.2. Identificación
2000R2082 — ES — 15.06.2002 — 001.001 — 187
▼B
D.3.3. Implantación del protocolo
D.4.FormularioPICSparaelProtocolodecabecerademensaje
D.4.1. Abreviaturas y símbolos especiales
D.4.1.1. Símbolos de estado
M obligatorio
O opcional
O.<n> opcional, pero es necesario que se admita al menos uno
de los grupos de opciones identificados por el mismo
número <n>
X prohibido<item>: símbolo de elemento condicional, dependiente del
soporte marcado por el <item> (véase D.2.4)2000R2082 — ES — 15.06.2002 — 001.001 — 188
▼B
D.4.1.2. Abreviaturas
NA no aplicable
D.4.1.3. Referencias de elemento
Los elementos en el formulario PICS se identifican mediante referen-
cias mnemotécnicas. Los elementos con funciones relacionadas se
identifican con referencias que tienen la misma letra o par de letras
iniciales (en mayúsculas). A continuación se presenta una lista de
estas iniciales, en orden de aparición en los grupos de elementos
aparecen en el formulario PICS.
— IHC1, IHC2, IHC3, IHC4,
IHCCestablecimiento de la conexión
— IHR1, IHR2 terminación de la conexión
— IHT1, IHTx transferencia de datos— Tcrtempor izador
D.4.2. Identificación
2000R2082 — ES — 15.06.2002 — 001.001 — 189
▼B
D.4.3. Implantación del protocolo
D.5.FormularioPICSparaelProtocolodered
D.5.1. Abreviaturas y símbolos especiales
D.5.1.1. Símbolos de estado
M obligatorio
O opcional
D.5.1.2. Referencias de elemento
Los elementos en el formulario PICS se identifican mediante referen-
cias mnemotécnicas. Los elementos con funciones relacionadas se
identifican con referencias que tienen la misma letra o par de letras
iniciales (en mayúsculas). A continuación, se presenta una lista de2000R2082 — ES — 15.06.2002 — 001.001 — 190
▼B
estas iniciales, en orden de aparición en los grupos de elementos del
formulario PICS.
— SNDCP1 campo de identificación de
protocolo
— NCRdae, NCRgae, NCCx,
NDRxparámetros en mensajes de
protocolo
— NCD1, NCD2, NCN1, NCN2 validación de direcciones
— NDT transferencia de datos
D.5.2. Identificación
2000R2082 — ES — 15.06.2002 — 001.001 — 191
▼B
D.5.3. Implantación de protocolo
2000R2082 — ES — 15.06.2002 — 001.001 — 192
▼B
ANEXO E (Normativo)
LISTADEREQUISITOSDEPERFIL
E.1.Introducción
E.1.1. El presente Anexo proporciona la PRL para el perfil FDE ICD defi-
nido en la presente Norma Eurocontrol. La declaración de
conformidad aplicable a una implantación declarada conforme para
este perfil deberá ser generado de acuerdo con las instrucciones que
se dan a continuación.
NOTA Los formularios del presente Anexo están basados en los que
acompañan a las normas básicas a las que se ha hecho refe-
rencia.
E.1.2. Una implantación conforme deberá satisfacer los requisitos de confor-
midad obligatorios de las normas básicas a las que se ha hecho
referencia en este perfil.
E.2.ElpapeldelasPRLydelosformulariosPICS
El carácter de esta sección (E.2) es informativo: no constituye una
disposición de la presente Parte de esta Norma Eurocontrol.
— El objetivo de presentar los requisitos de conformidad en el
formato tabular de las PRL y de los formularios PICS es propor-
cionaruna lista de contr ol de las funciones que deben o pueden
serimplantadas. Los conceptos fundamentales están definidos y
descritos en ISO/IEC 9646-1 [Referencia 14] (ITU-T
Recomendación X.290 es equivalente) e ISO/IEC TR 10000-1
[Referencia 2].
— Un perfil combina y selecciona las opciones de varias normas
básicas para satisfacer una función de procesamiento de informa-
ción específica. Cada norma básica tiene un formulario PICS, que
enumera los requisitos de la norma. La PRL comprende el
subconjunto de elementos del formulario PICS de la norma básica
que están restringidos por el perfil, junto con los requisitos del
perfil específicos; define las respuestas que se deben dar a los
formularios PICS de la norma básica para ajustarse al perfil.
Además, la PRL contendrá los elementos de tipo PICS que son
específicos del perfil (al menos, habrá un elemento para
comprobar si todos los formularios PICS necesarios han sido
cumplimentados correctamente); estos elementos deben ser
cumplimentados junto con los formularios PICS de la norma
básica. El conjunto de formularios cumplimentados constituye la
Declaración de Conformidad de la implantación del perfil (ICS).
— Siguiendo la metodología de ISO/IEC TR 10000-1 [Referencia 2],
una declaración de conformidad de un perfil tendrá que estar
respaldada por los formularios PICS cumplimentados de acuerdo
con la PRL. La utilización de estos documentos dependerá del
método de adquisición para una implantación FDE ICD.
— Existen varios métodos de adquisición para una implantación
FDE:
— Implantación interna por un Organismo o Administración
Nacional: la PRL se debería utilizar como base de la especifi-
cación de requisitos y pruebas de aceptación de la
implantación; el ICS cumplimentado se debería emitir como
parte del procedimiento de aceptación.
— Desarrollo del perfil por un contratista: el material será utili-
zado y producido en la misma forma que para una
implantación interna, pero el contratista debería proporcionar
el ICS y esta condición debe ser un requisito contractual.
— Implantación del perfil por un contratista como parte de un
contrato de integración de sistema de llave en mano: el mate-
rial será utilizado y producido de la misma forma que para
una implantación interna, pero el contratista debe realizar
esto de forma interna, así como proporcionar el ICS cumpli-
mentado. La conformidad del perfil asegura, por ejemplo,
que un proveedor que trabaja para dos administraciones no
pueda introducir sus protocolos privados para cumplir los
requisitos FDE y así contribuir a dar el control a las adminis-
traciones contratantes.
— Integración de productos disponibles en el mercado en una
implantación de perfil en cualquiera de los casos previos: el2000R2082 — ES — 15.06.2002 — 001.001 — 193
▼B
proveedor de un producto debería de proporcionar los formu-
larios PICS pertinentes del producto cumplimentados de
acuerdo con la presente PRL y garantizar la conformidad del
producto con los requisitos de perfil aplicables; estos PICS
pueden ser adelantados como parte del ICS del perfil.
— Después de la implantación, el ICS se debería conservar como
parte de la documentación del desarrollo; se puede utilizar para
prever la interoperatividad con otras administraciones y para iden-
tificarlos cambios que puedan sernecesar ios en la adopción de
otros protocolos.
E.3.Notación
E.3.1. Las siguientes notaciones de la norma ISO/IEC TR 10000-1
[Referencia 2] se utilizan en la PRL para indicar el estado de las
funciones:
m: obligatorio
o: opcional—: no aplicable (p. ej., lógicamente imposible en el marco de este
perfil)
x: excluido
NOTAS1. Se pueden usar combinaciones de dos caracteres, en este caso el
primer carácter se refiere al estado estático (implantación), y el
segundo al dinámico (uso); de este modo «mo» significa «implan-
tación obligatoria, pero uso opcional».
2. La notación «o.<n>» se utiliza para mostrar un conjunto de
opciones seleccionables (p. ej., se debe desarrollar al menos una
del conjunto) con el mismo identificador n.
3. Una función marcada con la letra «x» puede formar parte de una
implantación aunque no se utilizará cuando la implantación esté
funcionando en el marco del perfil.
4. La utilización de funciones marcadas con «x» podría exigir de
acuerdos bilaterales. En este caso, se debería revisar el estado
de las funciones debido a la posible incidencia en otras implan-
taciones.
E.3.2. Se utiliza la siguiente notación de predicados:
<predicado>: introduce un grupo de elementos en el cual todos son
condicionales en función del <predicado> (la importancia del grupo
se indica pormedio de la pr esentación).
<predicado>: introduce un único elemento condicional al <predi-
cado>.
NOTA En cada caso, el predicado puede ser el identificador de una
función de perfil o una combinación booleana de predicados
(«¬» es el símbolo de la negación lógica).
E.3.3. Los requisitos de las normas básicas se muestran utilizando las
notaciones equivalentes en letras mayúsculas (p. ej., M, O, O.<n>,
X).
E.4.InstruccionesparacumplimentarlosformulariosPICS
E.4.1. Para proporcionar el ICS del perfil, se deberán cumplimentar los
formularios PICS para las normas básicas a las que se ha hecho refe-
rencia, junto con los elementos PICS relativos al perfil mencionados
en el presente Anexo.
E.4.2. Cuando este perfil ponga a punto las funciones de las normas básicas,
se deberán aplicar los requisitos descritos en esta PRL (como se
indica en los elementos PRL con una columna «Funciones del
perfil») a fin de limitar las respuestas admisibles en los formularios
PICS de la norma básica.
E.4.3. Cuando este perfil fije requisitos adicionales, se deberá cumplimentar
la columna de respuesta para cada elemento. En esta columna, cada
respuesta deberá seleccionarse de un conjunto de respuestas indicadas
o constar de un valor o rango de valores para el parámetros requerido.
E.4.4. Si no se cumple un requisito obligatorio, se debe proporcionar infor-
mación excepcional introduciendo una referencia X<i>, donde <i> es2000R2082 — ES — 15.06.2002 — 001.001 — 194
▼B
un identificadorúnico, en una explicación del motivo de la falta de
conformidad.
NOTA Un posible motivo para esta excepción es que exista un
informe de defecto pendiente en una disposición del perfil;
si se acepta el informe de defecto, entonces el desarrollo
será conforme.
E.5.Referencias
E.5.1. El presente perfil hace referencia a las siguientes especificaciones de
protocolo:
— Protocolo de Transferencia de mensajes (Anexo A de la presente
Norma Eurocontrol);
— Protocolo de Cabecera de mensajes (Anexo B de la presente
Norma Eurocontrol);
— Protocolo de Red de modo conexión, utilizando ISO/IEC 8208
(Anexo C de la presente Norma Eurocontrol);
— ISO/IEC 7776 [Referencia 6];— Normas de la capa física mencionadas en la cláusula 1 de la
Recomendación X.25 (1993) de ITU-T [Referencia 1].
E.5.2. Como no existen formularios PICS explícitos para las normas aplica-
bles a la capa física, se deberán utilizar los formularios PICS
provisionales para la capa física que figuran en ISO/IEC ISP 10609-
9 cláusula A.4 [Referencia 8].2000R2082 — ES — 15.06.2002 — 001.001 — 195
▼B
E.6.Declaracióndeconformidad
E.6.1. Presentación general de conformidad
2000R2082 — ES — 15.06.2002 — 001.001 — 196
▼B
E.6.2. Requisitos de conformidad dinámica
E.7.Requisitosdelacapasuperior
Tabla 3
Protocolo de Transferencia de mensajes
Funciones de la norma básica Funciones del perfil
Elemen-
toProtocolo de transferencia
de mensajesReferencias Estado Referencias Estado
MTst — mensajes de estado A.4.2 O ox
MTor— mensajes de
operadorA.4.2 O ox
E.8.Requisitosdelacapainferior
E.8.1. Requisitos de la capa de transporte
Tabla 4
Protocolo de Cabecera de mensaje
Funciones de la norma básica Funciones del perfil
Elemen-
toProtocolo de cabecera de
mensajeReferencias Estado Referencias Estado
IHTx Uso de los campos
ADEST, DEST,
AEMM, EMM y ADR
con valores distintos
de '40'HB.4.4 O ox
E.8.2. Requisitos de la capa de red
Las PRL dadas en la presente sección se basan en el formulario PICS
de la norma ISO/IEC 8208:1993 [Referencia 7]. Las entradas de la
columna «Referencias» en «Funciones de la norma básica» de las
siguientes tablas son referencias a cláusulas de dicha norma.2000R2082 — ES — 15.06.2002 — 001.001 — 197
▼B
E.8.2.1. Características generales de DTE
Tabla 5
Características generales de DTE
Funciones de la norma básica Funciones del perfil
Elemen-
toCaracterísticas generales
DTEReferencias Estado Referencias Estado
Servicio admitido:
Vs — llamada virtual O.1 m
Vp — circuito virtual
permanenteO.1 x
Entornos admitidos: 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 en
función fija como DTEO.2 6.3.2 o.2
Et/c — DTE/DTE en
función fija como DCEVs: O.2 6.3.2 o.2
Et/d — DTE/DTE con
selección dinámica de
función4.5 Vs: O.2 x
Numeración secuencial
de paquetes admitida:
M8 — Módulo 8 13.2, 12.1.1,
Tabla 3O.3 m
M128 — Módulo 128 13.2, 12.1.1,
Tabla 3O.3 x
Servicio admitido de
usuario opcional para
Número de Referencia,
para asignación alter-
nativa de identificador
de canal lógico:13.29, 13.29.1,
13.29.2, 13.29.3,
13.29.4, Fig 31
RNa — Sin posibilidad de
volvera usar
rangos de canales
lógicos13.29.2.1 Et:O
¬Et:Xx
RNb — Con posibilidad de
volvera usar
rangos de canales
lógicos13.29.2.1 Et:O
¬Et:Xx
E.8.2.2. Procedimientos, tipos y formatos de paquete
Tabla 6
Funciones de la capa de paquete independientes de los canales lógicos
Funciones de la norma básica Funciones del perfil
Elemen-
toFunciones de la capa de
paquete independientes de
los canales lógicosReferencias Estado Referencias Estado
¿Se admiten las
siguientes funciones de
capa de paquete:
Z2s Emisión de paquetes
de diagnóstico?12.7, Tabla 24 Et:O
¬Et:Xx2000R2082 — ES — 15.06.2002 — 001.001 — 198
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toFunciones de la capa de
paquete independientes de
los canales lógicosReferencias Estado Referencias Estado
Z4i Iniciación del servicio
de registro en línea:13.1, 13.1.1.1,
13.1.1.3,
13.1.1.4Oo x
— envío de REGIS-
TRATION REQUEST12.9.1
— recepción de
REGISTRATION
CONFIRMATION12.9.2, Tabla 10
Z4rRespuesta al ser vicio
de registro en línea:13.1, 13.1.1.1,
13.1.1.4Et:O –
— recepción de
REGISTRATION
REQUEST12.9.1
— envío de REGIS-
TRATION CONFIR-
MATION12.9.2, Tabla 10
Tabla 7
Establecimiento de comunicación
Funciones de la norma básica Funciones del perfil
Elemen-
toEstablecimiento de comuni-
caciónReferencias Estado Referencias Estado
¿Se permiten las
comunicaciones
virtuales de salida:5.2.1, 5.2.5,
Tabla 33
S1a — Selección rápida sin
restricción de
respuesta?5.2.4, 13.16 O x
S1b — Selección rápida
con restricción de
respuesta?13.16 O x
S1c — Selección no
rápida?5.2.4 O m
SP1b CALL REQUEST,
formato básico12.2.3.1 S1c:M
S1ab: O.4m
SP1e Envío de CALL
REQUEST, formato
extendido12.2.3.1,
12.2.3.2S1ab: O.4 x
SP2b Recepción de CALL
CONNECTED,
formato básico12.2.4.1 S1ac:M m
SP2e Recepción de CALL
CONNECTED,
formato extendido12.2.4.1,
12.2.4.2S1a:M –
¿Se permite direccio-
namiento alternativo
para llamadas virtuales
de salida:13.28
— Usando A = 1 y el
formato extendido de
bloque de dirección?13.28.2.1,
12.2.1.2Ec/3:O
¬Ec/3:Xx
— Usando el servicio
de extensión de direc-
ción emisor?13.28.2.2. Ec/3:O
¬Ec/3:Xx
¿Se permiten comuni-
caciones virtuales de
entrada:5.2.2, 5.2.5,
Tabla 332000R2082 — ES — 15.06.2002 — 001.001 — 199
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toEstablecimiento de comuni-
caciónReferencias Estado Referencias Estado
S2a — Selección rápida
con aceptación
posible?5.2.3, 13.17 O –
S2b — Selección rápida,
terminada siempre?13.17 O m
S2c — Selección no rápida
con aceptación
posible?5.2.3 O m
S2d — Selección no rápida,
terminada siempre?5.2.3 O x
SP3b Recepción de INCO-
MING CALL, formato
básico12.2.3.1 S2:M m
SP3e Recepción de INCO-
MING CALL, formato
extendido12.2.3.1,
12.2.3.2S2ab:M
S2axc:
O.5–
SP4b Envío de CALL
ACCEPTED, formato
básico12.2.4.1 S2c:M
S2axc:
O.5m
SP4e Envío de CALL
ACCEPTED, formato
extendido12.2.4.1,
12.2.4.2S2axc:
O.5
S2anc:O–
Se permite negociación
de bit D:
DN1 — para comunica-
ciones virtuales de
salida6.3 S1ac:O m
DN2 — para comunica-
ciones virtuales de
entrada6.3 S1ac:O m
NOTA El bit D deberá ser siempre negociado a 0.
Tabla 8
Terminación de comunicación
Funciones de la norma básica Funciones del perfil
Elemen-
toTerminación de comunica-
ciónReferencias Estado Referencias Estado
¿Se permite la termi-
nación de la comuni-
cación para:5.5.4, Tabla 33
C1 — responder a una
indicación de termina-
ción?5.5.2 O m
C2a — abortar un intento
de comunicación
virtual de salida?5.4, 5.5.1, 5.5.3 S1:O o
C2b — rechazar una comu-
nicación virtual de
entrada?5.3, 5.5.1, 5.5.3 S2bd:M
S2acxbd :
Om
C2c — originar la termina-
ción de una comunica-
ción virtual
establecida?5.5.1, 5.5.3 O o
CP1b Recepción de CLEAR
INDICATION,
formato básico12.2.5.1 Cany:M m2000R2082 — ES — 15.06.2002 — 001.001 — 200
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toTerminación de comunica-
ciónReferencias Estado Referencias Estado
CP1e Recepción de CLEAR
INDICATION,
formato extendido12.2.5.1,
12.2.5.2Cany:M –
CP2b Envío de CLEAR
CONFIRMATION,
formato básico12.2.6.1 C1:M m
CP2e Envío de CLEAR
CONFIRMATION,
formato extendido12.2.6.1,
12.2.6.2C1rn:M x
CP3b Envío de CLEAR
REQUEST, formato
básico12.2.5.1 C2a:M
C2bcxa :
O.6m
CP3e Envío de CLEAR
REQUEST, formato
extendido12.2.5.1,12.2.5.2 C2bcxa :
O.6
C2axbc :
Xx
CP4b Recepción de CLEAR
CONFIRMATION,
formato básico12.2.6.1 C2:M m
CP4e Recepción de CLEAR
CONFIRMATION,
formato extendido12.2.6.1,
12.2.6.2C2rnci :M –
Tabla 9
Reinicialización de canales lógicos
Funciones de la norma básica Funciones del perfil
Elemen-
toReinicialización de canales
lógicosReferencias Estado Referencias Estado
¿Se permite el reinicio: 8, 8.4, Tabla 34
RSi — como iniciador? 8.1, 8.3 O mm
envío de RESET
REQUEST12.5.1
recepción de RESET
CONFIRMATION/
INDICATION12.5.2, 12.5.1
RSr— como contestador ? 8.2 O mm
recepción de RESET
INDICATION12.5.1
envío de RESET
CONFIRMATION12.5.2
Tabla 10
Procedimientos de error
Funciones de la norma básica Funciones del perfil
Elemen-
toProcedimientos de error
(Servicio de comunicación
virtual)Referencias Estado Referencias Estado
¿El procedimiento de
ERROR-C:5.2.1, 5.4, 8.1,
Tabla 33
W1a — finaliza la comuni-
cación virtual?O.7 m2000R2082 — ES — 15.06.2002 — 001.001 — 201
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toProcedimientos de error
(Servicio de comunicación
virtual)Referencias Estado Referencias Estado
W1b — reinicia la capa de
paquete?O.7 x
¿El procedimiento de
ERROR-R para comu-
nicaciones virtuales: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,
Tablas 34-36
W2sc — reinicia la capa de
paquete?O.8 x
Tabla 11
Transferencia de interrupciones
Funciones de la norma básica Funciones del perfil
Elemen-
toTransferencia de interrup-
cionesReferencias Estado Referencias Estado
Is ¿Se permite el envío
de interrupciones en:6.8, 6.8.1, 6.8.3,
Tabla 35Oo x
—envío de INTE-
RRUPT REQUEST?12.3.2
recepción de INTE-
RRUPT CONFIRMA-
TION?12.3.3
Ir ¿Se permite la recep-
ción de interrupciones
en:6.8, 6.8.2, 6.8.3,
Tabla 35O–
— recepción de INTE-
RRUPT INDICA-
TION?12.3.2
— envío de INTE-
RRUPT CONFIRMA-
TION?12.3.3
Tabla 12
Envío de datos
Funciones de la norma básica Funciones del perfil
Elemen-
toEnvío de datos Referencias Estado Referencias Estado
DS1 ¿Se permite el envío
de paquetes DATA?6, 6.1, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
¿Se permiten los casos
siguientes:
DS2 — rotación de la
ventana de envío en
valores de recepción
P(R) actualizados?7.1, 7.1.2, 7.1.3 O mm
DS4a — envío de M = 0 en
paquetes DATA?6.4, 6.5, 6.7 M mo.9
DS4b — envío de M = 1 en
paquetes DATA?6.4, 6.5, 6.7 O mo.9
DS5a — envío de Q = 0 en
paquetes DATA?6.6 O.10 mm
DS5b — envío de Q = 1 en
paquetes DATA?6.6 O.10 ox2000R2082 — ES — 15.06.2002 — 001.001 — 202
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toEnvío de datos Referencias Estado Referencias Estado
DS6 — respuesta a la soli-
citud de retransmisión
de paquetes (paquetes
REJECT recibidos)?13.4.2 12.8 Et:O –
— Procedimiento de
temporización de rota-
ción de ventana:
DS7a — acción ERROR-R
al vencimiento11.2.1(a) O ox
DS7b — retransmisión de
paquetes al venci-
miento11.2.1(b) Et:O
¬Et:Xox
DS8 — descarte de
paquetes de control de
flujo de longitud exce-
siva (en lugarde
ERROR-R)?Tabla 36 Nota 2 O ox
Tabla 13
Recepción de datos
Funciones de la norma básica Funciones del perfil
Elemen-
toRecepción de datos Referencias Estado Referencias Estado
DR1 ¿Se permite la recep-
ción de paquetes
DATA?6, 6.1, 6.2, 7.1.1,
7.1.2, 7.1.3,
12.3.1Om m
¿Se permite lo
siguiente:
DR2 — la rotación de
ventanas de recepciónmediante el envío de
valores P(R) actuali-
zados?7.1.2, 7.1.3 O mm
DR3 — control de flujo
mediante el envío de
RECEIVE NOTREADY y RECEIVE
READY?7.1.5, 7.1.6,
12.4.1, 12.4.2Om m
DR4b — recepción de M = 1
en paquetes DATA?6.4, 6.5, 6.7 O mm
DR5a — recepción de Q = 0
en paquetes DATA?6.6 O.11 mm
DR5b — recepción de Q = 1
en paquetes DATA?6.6 O.11 –
DR6 — solicitud de retrans-
misión de paquete
mediante el envío de
paquetes REJECT?13.4.1, 12.8 O ox
— recuperación a
partir de la recepción
de paquetes DATA con
P(S) inválidos,
mediante:
DR7a — acción ERROR-R? 11.3(a) O.12 mm
DR7b — solicitud de retrans-
misión de paquete?11.3(b) O.12 ox2000R2082 — ES — 15.06.2002 — 001.001 — 203
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toRecepción de datos Referencias Estado Referencias Estado
DR7c — ignorando el
paquete y esperando
una retransmisión
correcta del paquete?11.3(c) O.12 ox
— recuperación a
partir de la recepción
de paquetes DATA con
campo de datos de
usuario inválido,
mediante:
DR8a — acción ERROR-R? 11.3(a) O.13 mm
DR8b — solicitud de retrans-
misión de paquete?11.3(b) O.13 ox
DR8c — ignorando el
paquete y esperando
una retransmisión
correcta del paquete?11.3(c) O.13 ox
DR9 — procedimiento de
temporizador de trans-
misión de estado de
ventana?11.2.2 O ox
Tabla 14
Confirmación de entrega
Funciones de la norma básica Funciones del perfil
Elemen-
toConfirmación de entrega Referencias Estado Referencias Estado
DC ¿Se permite la confir-
mación de entrega?6.3, 6.5, 6.7,
7.1.4Ox
E.8.2.3. Características y opciones diversas
Tabla 15
Valores de códigos de causa y diagnóstico
Funciones de la norma básica Funciones del perfil
Elemen-
toValores de código de causa
y diagnósticoReferencias Estado Referencias Estado
En el envío de
paquetes RESTART
REQUEST:12.6.1.1,
12.6.1.2, Tablas
24-25
Y1d — Causa = 128,
códigos de diagnóstico
privadosO.14 ox
En la recepción de
paquetes RESTART
INDICATION:12.6.1.1, Tabla
9, 12.6.1.2
Y2b — Causa ni 0 ni 128,
cualquiervalorde
código de diagnósticoEC:M
¬EC:Om
En el envío de
paquetes CLEAR
REQUEST:12.2.3.1.1,
12.2.3.1.2,
Tablas 24-25
Y3d — Causa = 128,
códigos de diagnóstico
privadosO.15 ox2000R2082 — ES — 15.06.2002 — 001.001 — 204
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toValores de código de causa
y diagnósticoReferencias Estado Referencias Estado
En la recepción de
paquetes CLEAR
INDICATION:12.2.3.1.1, Tabla
7, 12.2.3.1.2,
Y4b — Causa ni 0 ni 128,
cualquiervalorde
código de diagnósticoEC:M
¬EC:Om
En el envío de
paquetes RESET
REQUEST:12.5.1.1,
12.5.1.2, Tablas
24-25
Y5d — Causa = 128,
códigos de diagnóstico
privadosO.16 ox
En la recepción de
paquetes RESET
INDICATION:12.5.1.1, Tabla
8, 12.5.1.2
Y6b — Causa ni 0 ni 128,
cualquiervalorde
código de diagnósticoEC:M
¬EC:Om
E.8.2.4. Servicios
Tabla 16
Servicios enviados en los paquetes CALL REQUEST
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios enviados en los
paquetes CALL REQUESTReferencias Estado Referencias Estado
FS1pi Negociación de
parámetro de control
de flujo, tamaño de
paquete13.12, 15.2.2.1.1 O x
FS1wi Negociación de
parámetro de control
de flujo, tamaño de
ventana13.12, 15.2.2.1.2 O x
FS2ib Negociación de clase
de salida básica13.13,
15.2.2.2.1, Tabla20aOx
FS2ie Negociación de clase
de salida extendida13.13,
15.2.2.2.2, Tabla
20bOx
FS3b Selección de grupo de
usuario cerrado,
formato básico13.14.6,
15.2.2.3.1Oo
FS3e Selección de grupo de
usuario cerrado,
formato extendido13.14.6,
15.2.2.3.2Ox
FS4b Grupo de usuario
cerrado con selección
de acceso de salida,
formato básico13.14.7,
15.2.2.4.1Ox
FS4e Grupo de usuario
cerrado con selección
de acceso de salida,
formato extendido13.14.7,
15.2.2.4.2Ox
FS5 Selección de grupo de
usuario cerrado bila-
teral13.15, 15.2.2.5 O x
FS6a Selección rápida 13.16, 15.2.2.6 O x2000R2082 — ES — 15.06.2002 — 001.001 — 205
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios enviados en los
paquetes CALL REQUESTReferencias Estado Referencias Estado
FS6b Cargo inverso 13.18, 15.2.2.6 O x
FS6c Selección de estado
ICRD13.25.4.2,
15.2.2.6Ox
FS7i Identificación de
usuario de red13.21, 13.21.3,
15.2.2.7Ox
FS8i Información de cargo,
solicitud de servicio13.22, 15.2.2.8.1 O x
FS9b Selección RPOA,
formato básico13.23, 13.23.2,
15.2.2.9.1Ox
FS9e Selección RPOA,
formato extendido13.23, 13.23.2,
15.2.2.9.2Ox
FS12 Selección e indicación
de retraso de tránsito13.27, 15.2.2.13 O x
FS99i Servicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FS98i Servicios remotos no-
X.25, según elmarcador del servicio15.1, Tabla 18 O x
FS20i Marcador del servicio,
especificación CCITT
de servicios DTE15.1 O x
FS21i Extensión de dirección
emisora14.1, 15.3.2.1 x
FS22i Extensión de dirección
receptora14.2, 15.3.2.2 x
FS23ib Negociación de clase
de salida mínima,
formato básico14.3, 15.3.2.3.1,
Tabla 20aOx
FS23ie Negociación de clase
de salida mínima,
formato extendido14.3, 15.3.2.3.2,
Tabla 20bO
FS24i Negociación de retraso
de tránsito extremo a
extremo14.4, 15.3.2.4 O x
FS25i Negociación de datos
acelerados14.7, 15.3.2.7 O x
FS26i Prioridad 14.5, 15.3.2.5 O x
FS27i Protección 14.6, 15.3.2.6 O x
Tabla 17
Servicios enviados en paquetes CALL ACCEPT
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios enviados en
paquetes CALL ACCEPTReferencias Estado Referencias Estado
FS1prNegociación de
parámetro de control
de flujo, tamaño de
paquete13.12,
15.2.2.1.1, Tabla
13Ox
FS1wrNegociación de
parámetro de control
de flujo, tamaño de
ventana13.12,
15.2.2.1.2, Tabla
13Ox
FS2rb Negociación de clase
de salida básica13.13,
15.2.2.2.1, Tabla
20aOx2000R2082 — ES — 15.06.2002 — 001.001 — 206
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios enviados en
paquetes CALL ACCEPTReferencias Estado Referencias Estado
FS2re Negociación de clase
de salida extendida13.13,
15.2.2.2.2, Tabla
20bOx
FS7rIdentificación de
usuario de red13.21, 13.21.3
15.2.2.7Ox
FS8r Información de cargo,
solicitud de servicio13.22, 15.2.2.8.1 O x
FS10rNotificación de modi-
ficación de la dirección
de la línea receptora13.26, 15.2.2.12 O x
FS99rSer vicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FS98r Servicios remotos no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FS20r Marcador del servicio,
especificación CCITT
de servicios DTE15.1 O x
FS22rExtensión de dir ección
receptora14.2, 15.3.2.2 O x
FS24r Negociación de retraso
de tránsito extremo a
extremo14.4, 15.3.2.4 O x
FS25rNegociación de datos
acelerados14.7, 15.3.2.7 O x
FS26r Prioridad 14.5, 15.3.2.5 O x
FS27rPr otección 14.6, 15.3.2.6 O x
Tabla 18
Servicios enviados en paquetes CLEAR REQUEST
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios enviados en
paquetes CLEAR
REQUESTReferencias Estado Referencias Estado
FS10d Notificación de modi-
ficación de la dirección
de la línea receptora13.26, 15.2.2.12 O x
FS13 Selección de desvío de
llamada13.25.2.2,
15.2.2.10Ox
FS99d Servicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FS98d Servicios remotos no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FS20d Marcador del servicio,
especificación CCITT
de servicios DTE15.1 O x
FS22d Extensión de dirección
receptora14.2, 15.3.2.2 O x2000R2082 — ES — 15.06.2002 — 001.001 — 207
▼B
Tabla 19
Servicios recibidos en paquetes INCOMING CALL
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios recibidos en
paquetes INCOMING
CALLReferencias Estado Referencias Estado
FR1pi Negociación de
parámetro de control
de flujo, tamaño de
paquete13.12, 15.2.2.1.1 O x
FR1wi Negociación de
parámetro de control
de flujo, tamaño de
ventana13.12, 15.2.2.1.2 O x
FR2ib Negociación de clase
de salida básica13.13,
15.2.2.2.1, Tabla
20aOx
FR2ie Negociación de clase
de salida extendida13.13,
15.2.2.2.2, Tabla
20bOx
FR3b Selección de grupo de
usuario cerrado,
formato básico13.14.6,
15.2.2.3.1Oo
FR3e Selección de grupo de
usuario cerrado,
formato extendido13.14.6,
15.2.2.3.2Ox
FR4b Grupo de usuario
cerrado con selecciónde acceso de salida,
formato básico13.4.7,
15.2.2.4.1Ox
FR4e Grupo de usuario
cerrado con selección
de acceso de salida,
formato extendido13.4.7,
15.2.2.4.2Ox
FR5 Selección de grupo de
usuario cerrado bila-
teral13.15, 15.2.2.5 O x
FR6a Selección rápida 13.16, 13.17,
15.2.2.6Ox
FR6b Cargo inverso 13.18, 13.19,
15.2.2.6Ox
FR11 Notificación de desvío
o redirección de
llamada13.25.3,
15.2.2.11Ox
FR12i Selección e indicación
de retraso de tránsito13.27, 15.2.2.13 O x
FR99i Servicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FR20i Marcador del servicio,
especificación CCITT
de servicios DTE15.1 O x
FR21 Extensión de dirección
emisora14.1, 15.3.2.1 x
FR22i Extensión de dirección
receptora14.2, 15.3.2.2 x
FR23b Negociación de clase
de salida mínima,
formato básico14.3, 15.3.2.3.1,
Tabla 20aOx
FR23e Negociación de clase
de salida mínima,
formato extendido14.3, 15.3.2.3.2,
Tabla 20bOx2000R2082 — ES — 15.06.2002 — 001.001 — 208
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios recibidos en
paquetes INCOMING
CALLReferencias Estado Referencias Estado
FR24i Negociación de retraso
de tránsito extremo a
extremo14.4, 15.3.2.4 O x
FR25i Negociación de datos
acelerados14.7, 15.3.2.7 O x
FR26i Prioridad 14.5, 15.3.2.5 O x
FR27i Protección 14.6, 15.3.2.6 O x
Tabla 20
Servicios recibidos en paquetes CALL CONNECTED
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios recibidos en
paquetes CALL
CONNECTEDReferencias Estado Referencias Estado
FR1prNegociación de
parámetro de control
de flujo, tamaño de
paquete13.12,
15.2.2.1.1, Tabla
14Ox
FR1wrNegociación de
parámetro de control
de flujo, tamaño de
ventana13.12,
15.2.2.1.2, Tabla
14Ox
FR2rb Negociación de clase
de salida básica13.13,
15.2.2.2.1, Tabla
20aOx
FR2re Negociación de clase
de salida extendida13.13,
15.2.2.2.2, Tabla
20bOx
FR10rNotificación de modi-
ficación de la dirección
de la línea receptora13.26, 15.2.2.12 O x
FR12rSelección e indicación
de retraso de tránsito13.27, 15.2.2.13 O x
FR99rSer vicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FR20r Marcador del servicio,
especificación CCITT
de servicios DTE15.1 O x
FR22rExtensión de dir ección
receptora14.2, 15.3.2.2 O x
FR24r Negociación de retraso
de tránsito extremo a
extremo14.4, 15.3.2.4 O x
FR25rNegociación de datos
acelerados14.7, 15.3.2.7 O x
FR26r Prioridad 14.5, 15.3.2.5 O x
FR27rPr otección 14.6, 15.3.2.6 O x2000R2082 — ES — 15.06.2002 — 001.001 — 209
▼B
Tabla 21
Servicios recibidos en paquetes CLEAR INDICATION
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios recibidos en
paquetes CLEAR INDICA-
TIONReferencias Estado Referencias Estado
FR8ad Información de cargo,
unidad monetaria13.22, 15.2.2.8.2 O x
FR8bd Información de cargo,
cuenta de segmento13.22, 15.2.2.8.3 O x
FR8cd Información de cargo,
duración de llamada13.22, 15.2.2.8.4 O x
FR10d Notificación de modi-
ficación de la dirección
de la línea receptora13.26, 15.2.2.12 O x
FR99d Servicios locales no-
X.25, según el
marcador del servicio15.1, Tabla 18 O x
FR20d Marcador del servicio,
especificación ITU-T
de servicios DTE15.1 O x
FR22d Extensión de dirección
receptora14.2, 15.3.2.2 O x
Tabla 22
Servicios recibidos en paquetes CLEAR CONFIRMATION
Funciones de la norma básica Funciones del perfil
Elemen-
toServicios recibidos en
paquetes CLEAR CONFIR-
MATIONReferencias Estado Referencias Estado
FR8af Información de cargo,
unidad monetaria13.22, 15.2.2.8.2 O x
FR8bf Información de cargo,
cuenta de segmento13.22, 15.2.2.8.3 O x
FR8cf Información de cargo,
duración de llamada13.22, 15.2.2.8.4 O x
E.8.2.5. Valores y rangos de los parámetros
Tabla 23
Valores y rangos de los parámetros
Funciones de la norma básica Funciones del perfil
Elemen-
toValores y rangos de los
parámetrosReferencias Estado Referencias Estado
¿Qué valores son
admitidos:
V1s — Tamaños de
paquete pordefecto
(envío)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096octe-
tos6.3.2 Al
menos
128 y
2562000R2082 — ES — 15.06.2002 — 001.001 — 210
▼B
Funciones de la norma básica Funciones del perfil
Elemen-
toValores y rangos de los
parámetrosReferencias Estado Referencias Estado
V1r— Tamaños de
paquete pordefecto
(recepción)?16.2.2.5 16, 32,
64, 128,
256, 512,
1 024,
2 048,
4 096octe-
tos6.3.2 Al
menos
128 y
256
V2s — Tamaños de
ventana pordefecto
(envío)?16.2.2.6 ( M8:e ne l
rango 1-7)2
V2r— Tamaños de
ventana pordefecto
(recepción)?16.2.2.6 ( M8:e ne l
rango 1-7)2
E.8.3. Requisitos de la capa de enlace de datos
Las PRL dadas en la presente sección se basan en el formulario PICS
de la norma ISO/IEC 7776:1994 [Referencia 6]. Las entradas de la
columna «Referencias» en «Funciones de la norma básica» de las
siguientes tablas son referencias a cláusulas de dicha norma.
Tabla 24
Protocolo de enlace de datos
Funciones de la norma básica Funciones del perfil
Elemen-
toProtocolo de enlace de
datosReferencias Estado Referencias Estado
Lm Procedimiento multien-
lace6O o x
Lc Operación DTE/DCE 1, 5.1 M mo.1
Lt Operación DTE/DTE 1, 5.1 O mo.1
M8 Operación básica
(Módulo 8)1, 3, 4.1.1 O.1 mm
M128 Operación extendida
(Módulo 128)1, 3, 4.1.1 O.1 ox
T4 Procedimiento de
temporizador T45.3.2, 5.6.1 O mm
SPN1 Número máximo de
bits (N1) en una trama
I5.7.3 N1 ≥
1 080N1≥
2 104
SPk Número máximo de
tramas pendientes (k)5.7.4 1 ≤k≤
7k=7
E.8.4. Requisitos de la capa física
Véase ISO/IEC TR 10609-9 cláusula A.4 [Referencia 8].2000R2082 — ES — 15.06.2002 — 001.001 — 211
▼B
ANEXO F (Informativo)
MÉTODOSDEPRUEBADECONFORMIDAD
F.1.Introducción
F.1.1. Es importante que en las implantaciones de este ICD sean tales que
exista un alto nivel de confianza, para el funcionamiento entre
Centros de Control de Tráfico Aéreo (ATCC) que operan a ambos
lados de la interfaz.
F.1.2. Las implantaciones de la interfaz se llevan a cabo por estados miem-
bros de forma que es probable utilizar varias fuentes de
aprovisionamiento. Para alcanzar un alto nivel de confianza en el
funcionamiento de las implantaciones, es necesario establecer un
conjunto común de requisitos de prueba de conformidad con el fin
de normalizar la preparación de la prueba, la prueba y la presentación
resultados.
F.2.Objetoyalcance
F.2.1. El presente Anexo define los requisitos para la prueba de confor-
midad de las implantaciones de la presente Norma Eurocontrol de la
que este Anexo forma parte.
F.2.2. Identifica los mecanismos porlos que se establece la confianza en la
interfaz declarada mediante un proceso de prueba para validar la
demanda.
F.3.Bibliografía
El siguiente documento está relacionado con la prueba de las implan-
taciones de la presente Norma Eurocontrol:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Divi-
sion) FDE ICD Parte 1 Plan de Pruebas de Integración, Versión 1.0,
de fecha 10 de mayo de 1996 [Referencia 15].
F.4.Métodosyprácticasdeimplantaciones
F.4.1. Las implantaciones del presente ICD pueden ser llevadas a cabo utili-
zando ciertas opciones y versiones del propio ICD. Para establecer el
potencial de interoperación, un Estado miembro que implemente la
interfaz debe identificar qué partes del ICD se permiten, mediante
una declaración precisa de las capacidades y limitaciones, en su
caso, de los parámetros variables permitidos.
F.4.2. Toda implantación debería ser sometida a una prueba de conformidad
según lo descrito a continuación.
F.5.Pruebas
F.5.1. Introducción
F.5.1.1. Para proporcionar confianza y apoyo a la interfaz FDE dentro de un
ATCC para la interoperación entre aplicaciones FDE cooperantes, es
recomendable que cada una de ellas sea probada de conformidad a las
normas de las cuales forma parte el presente Anexo. Estas pruebas se
enfrentan al comportamiento externo del Sistema en prueba (SUT) y
están destinadas a poner a prueba la interoperación, más que la capa-
cidad de servicio del sistema final.
F.5.1.2. Los resultados de cada prueba pueden servir como testimonio para las
declaraciones de conformidad hechas de acuerdo con la sección de la
presente Norma Eurocontrol. Los formularios PICS y las PRL citadas
en la presente especificación de perfil se pueden utilizar como base
para las pruebas de conformidad; además, las normas internacionales
(p. ej., ISO/IEC 8208 [Referencia 7]) pueden incluir conjuntos de
pruebas abstractas definidas que se pueden utilizar en las pruebas de
conformidad.
F.5.1.3. El objeto del presente documento es proporcionar un programa
normalizado de prueba que se apoye en un conjunto de pruebas
normalizadas y su uso debería garantizar la capacidad de comparación
de los resultados de la prueba, una amplia aceptación de estos resul-
tados y la minimización de las pruebas de conformidad necesarias. El2000R2082 — ES — 15.06.2002 — 001.001 — 212
▼B
conjunto de pruebas normalizadas ha sido desarrollado, en parte, por
Eurocontrol.
F.5.1.4. Basada en la Figura 2, la prueba final y completa del sistema tiene la
forma de las pruebas de las 3 capas inferiores. Es conveniente que se
incluyan pruebas de los mensajes de estado, de sistema y de operador
de la aplicación FDE.
F.5.1.5. Cada una de las pruebas descritas a continuación se debería ejecutar
en el orden dado. La última prueba sólo tendrá éxito si las capas infe-
riores funcionan correctamente y es probable averiguarlo con las
primeras pruebas.
F.5.1.6. No obstante, la prueba descrita en esta sección es voluntaria.
F.5.2. Prueba de las capas inferiores (Capas 1- 3)
Para garantizar la interoperación entre cualquier ATCC y sus homó-
logos es recomendable que cualquier prueba esté basada en la
utilización del plan de prueba que se proporciona en el Plan de
prueba de integración FDE ICD establecido por Eurocontrol (Maas-
tricht UAC Systems Division). Los procedimientos de prueba serán
acordados de forma bilateral entre ATCC cooperantes.
F.5.3. Prueba de la capa de aplicación
Se deberían acordar y llevar a cabo una serie de pruebas de forma
bilateral entre ATCC cooperantes.
F.5.4. Certificación
Los resultados de las pruebas deberían ser registrados y aprobados
por las partes cooperantes.
F.5.5. Notificación
Es conveniente que los Estados miembros comuniquen a Eurocontrol
los detalles de los resultados de cualquier prueba.2000R2082 — ES — 15.06.2002 — 001.001 — 213
▼B
ANEXO G (Informativo)
ASIGNACIÓNDEIDENTIFICADORESDEUNIDADATC
La siguiente tabla muestra los identificadores de unidad ATC asignados a fecha
22 de abril de 1997. Eurocontrol puede proporcionar información de la asigna-
ción actual de identificadores. La tabla también muestra el código binario en
hexadecimal del identificador, que forma parte del código de la dirección
NSAP definida en el Anexo C.
Tabla 1
Identificadores de unidad ATC
Identificadorde unidad
ATCCodificación Descripción
00 Reservado
01 '01'H CATCAS, Copenhague
02 '02'H MADAP, Maastricht
03 '03'H ZKSD, Francfort/Main
04 '04'H CANAC Bruselas
05 '05'H CAUTRA genérico, Francia
06 '06'H Dublín
07 '07'H Shannon
08 '08'H LATCC, Londres
09 '09'H ATCC Oslo
10 '10'H ATCC Karlsruhe
11 '11'H Langen (futuro sistema alemán)
12 '12'H FATMI-system, Tampere13 '13'H ROVA-system, Rovaniemi
14 '14'H VAS, Viena
15 '15'H CFMU Haren
16 '16'H CFMU Brétigny
17 '17'H ACC/FMP Ginebra
18 '18'H ACC/FMP Zurich
19 '19'H Barcelona
20 '20'H Madrid
21 '21'H Palma
22 '22'H Milán
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 Burdeos
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 Sevilla
37 '37'H Gran Canaria2000R2082 — ES — 15.06.2002 — 001.001 — 214
▼B
Identificadorde unidad
ATCCodificación Descripción
38 '38'H Praga
39 '39'H Amsterdam
40 '40'H LIZ Offenbach
41 '41'H Sistema militaralemán
42 '42'H Sistema militaralemán43 '43'H Sistema militaralemán
44 '44'H Sistema militaralemán
45 '45'H Sistema militaralemán
46 '46'H Sistema militaralemán
47 '47'H Sistema militaralemán
48 '48'H Sistema militaralemán
49 '49'H Sistema militaralemán
50 '50'H Munich (futuro sistema alemán)
51 '51'H Zagreb
52 '52'H Aeropuerto Hahn, Alemania
53 '53'H FIR de Santa María
54 '54'H Ljubljana
55 '55'H Sistema militarbelga
56 '56'H Budapest
57 '57'H Varsovia2000R2082 — ES — 15.06.2002 — 001.001 — 215
▼B
ANEXO H ( Informativo )
DIRECTIVASSOBREFIABILIDAD,DISPONIBILIDADYSEGURIDAD
H.1.Introducción
Se prevé que las aplicaciones ATC tales como OLDI deberán hacer
uso de redes X.25 interconectadas y/o servicios de telecomunicación
públicos o privados. Como consecuencia, se considera necesario
proporcionar directivas a los desarrollos FDE ICD Parte 1.
H.2.Objetoyalcance
H.2.1. El objeto del presente Anexo es proporcionar pautas en relación con
la fiabilidad, disponibilidad y seguridad.
H.2.2. El alcance del presente Anexo se basa en dos escenarios. El primer
escenario corresponde a una conexión punto a punto sobre línea dedi-
cada. El segundo escenario se basa en un entorno de red X.25
interconectado.
NOTA Para el segundo escenario, no se tiene en cuenta ningún
aspecto en interconexión de redes X25.
H.2.3. Se asegura que las implantaciones están físicamente protegidas contra
intrusión, fallos de alimentación y cualquier otra amenaza externa
que pueda afectaral funcionamiento nor mal.
H.3.Bibliografía
El siguiente documento es un análisis técnico detallado del cual el
presente Anexo es un resumen:
Eurocontrol FDE ICD Parte 1: Fiabilidad, Disponibilidad y Seguridad
— Informe Técnico [Referencia 16].
H.4.Implantacionesenlíneadedicada
H.4.1. Fiabilidad
Para aumentar la fiabilidad del servicio, los cables de las líneas dedi-
cadas, PSTN y Red digital de servicios integrados (RDSI) deben
seguirdifer entes caminos físicos y estarconectados a distintos
conmutadores del operador de telecomunicaciones (lo cual se deberá
especificaral oper adorde telecomunicaciones).
H.4.2. Disponibilidad
H.4.2.1. Debido al mayortiempo de establecimiento de PSTN, que es incom-
patible con las aplicaciones de restricción de tiempo, la RDSI se
debería utilizar como un sistema de seguridad.
H.4.2.2. En el caso de conmutación DTE, el DTE de seguridad debería
generar una trama DISC para acelerar el restablecimiento de la cone-
xión.
H.4.3. Seguridad
H.4.3.1. Cuando se utilice una RDSI como sistema de seguridad, el adaptador
de terminal (TA) de la RDSI de la llamada receptora debería validar
la dirección E.164 de la llamada emisora [Referencia 18].
H.4.3.2. El DTE de la llamada entrante debería cumplir con la Recomenda-
ción X.32 [Referencia 17] de ITU-T e incluir información de
identificación y autenticación de la llamada.2000R2082 — ES — 15.06.2002 — 001.001 — 216
▼B
H.4.4. Ejemplo de configuración
Figura H.1
Ejemplo de configuración de línea dedicada
H.5.Implantacióndered
H.5.1. Fiabilidad
Para aumentar la fiabilidad del servicio, los servidores de una deter-
minada ubicación deberían estar conectados a dos DCE que
pertenezcan a conmutadores de red distintos (este requisito debería
ser especificado al operador de red).
H.5.2. Disponibilidad
H.5.2.1. El servicio de búsqueda de grupo se debería utilizar para asignar una
única dirección X.121 [Referencia 20] a los DCE de un mismo sitio,
optimizando así la ruta de red y limitando el fallo en las llamadas.
H.5.2.2. En el caso de que se utilicen otros mecanismos que impliquen un
valor distinto en la dirección DTE de la llamada receptora en los
paquetes CALL REQUEST y CALL ACCEPT, la DTE entrante
debería ser configurada de forma que no afectase al establecimiento
de la comunicación.
H.5.2.3. En el caso de que se produzca una desconexión DCE motivada por
un fallo de red y esté disponible un segundo acceso a la red, el resta-
blecimiento de la comunicación se debería efectuar a través de este
segundo acceso.
H.5.3. Seguridad
Dentro del alcance del presente Anexo, el servicio de Grupo de
usuario cerrado (CUG) es el único aplicable a red que se debería
utilizar.
H.6.Directivasgeneralesparalasimplantacionesdelíneadedicaday
dered
H.6.1. Fiabilidad
H.6.1.1. Debido al tiempo necesario para una conmutación total entre servi-
dores, es conveniente tener en cuenta el uso de un procesador
frontal (FEP, Front-End Processor) para paliar los fallos de servidor.
H.6.1.2. Una arquitectura basada en un FEP puede aumentar la fiabilidad del
servicio.
NOTA La inclusión de una pila de transporte en la especificación del
perfil se puede desarrollar en el contexto de una futura norma
FDE ICD Parte 2.2000R2082 — ES — 15.06.2002 — 001.001 — 217
▼B
H.6.2. Disponibilidad
Cuando falla un intento de comunicación, el sitio que realiza la
llamada debería realizar un segundo intento utilizando la segunda
dirección X.121 (si está disponible).
H.6.3. Gestión de sistemas
H.6.3.1. Siempre que sea posible, es conveniente la utilización de conmuta-
dores que funcionen automáticamente mediante la búsqueda de las
señales de interfaz.
H.6.3.2. Se puede utilizar una indicación de error local durante la transmisión
de datos para realizar la conmutación de servidores.
H.6.3.3. La conmutación de un FEP debería generar una desconexión TC para
asegurar que el servidor local está en el estado IDLE.
H.6.3.4. Cuando finalizan los temporizadores de la red X.25 o de las capas de
enlace de datos, las capas superiores deberían ser liberadas.
H.6.3.5. Un fallo total en un FEP debería generar una desconexión TC.H.6.3.6. La gestión del sistema debería interrogar a la capa de Protocolo de
transferencia de mensajes (Anexo A) y comprobar la máquina de
estado para distinguir entre un fallo de Protocolo de transferencia de
mensajes y un fallo de aplicación.
H.6.4. Ejemplo de configuración
Figura H.2
Ejemplo de configuración de red2000R2082 — ES — 15.06.2002 — 001.001 — 218