Agencia Estatal Boletín Oficial del Estado
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, relativa a la definición y a la utilización de especificaciones técnicas compatibles para la adquisición de equipos y de sistemas para la gestió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 la Directiva 93/65/CEE del Consejo relativa a la definición, a la utilización de especificaciones técnicas compatibles para la adquisición de equipos, de sistemas para la gestión del trafico aéreo (2),
Considerando lo siguiente:
(1) Mediante la Directiva 97/15/CE se adoptó la norma de Eurocontrol para el intercambio de datos en línea (OLDI), edición 1.0, y la 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áfico aéreo, principalmente por lo que respecta a la transferencia de vuelos entre centros de control del tráfico aéreo (OLDI), la gestión del flujo del tráfico aéreo (ADEXP) y las comunicaciones entre regímenes nacionales (FDE-ICD).
(4) Las ediciones 2.2 de OLDI y 2.0 de ADEXP sustituyen a las versiones anteriores, que estaban vigentes en virtud del artículo 1 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 obligatorios 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 presente Reglamento,
- norma de Eurocontrol para la presentación del intercambio de datos de servicios de tráfico aéreo (ADEXP), edición 2.0 (Documento de 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.
Hecho en Bruselas, el 6 de septiembre de 2000.
Por la Comisión
Loyola De Palacio
Vicepresidente
____________________
(1) DO L 187 de 29.7.1993, p. 52.
(2) DO L 95 de 10.4.1997, p. 16.
ANEXO I
INTERCAMBIO DE DATOS EN LÍNEA (OLDI), EDICIÓN 2.2
(Documento de referencia de Eurocontrol DPS.ET1.ST06-STD)
ÍNDICE
DERECHOS DE AUTOR .................... 11
PRÓLOGO .................... 12
1. INTRODUCCIÓN .................... 15
1.1. Objetivo .................... 15
1.2. Campo de aplicación .................... 15
2. REFERENCIAS .................... 15
3. DEFINICIONES, SÍMBOLOS Y ABREVIATURAS .................... 16
3.1. Definiciones .................... 16
3.2. Símbolos y Abreviaturas .................... 18
4. REQUISITOS GENERALES .................... 19
4.1. Introducción .................... 19
4.2. Requisitos de los sistemas de procesamiento de datos de vuelo .................... 20
4.2.1. Base de datos de vuelo .................... 20
4.2.2. Funcionamiento en Tiempo Real .................... 20
4.2.3. Capacidad de comunicación de datos .................... 20
4.2.4. Funciones de aplicación .................... 20
4.2.5. Interfaz hombre-máquina (HMI) .................... 21
4.2.6. Inicio de mensajes .................... 21
4.2.7. Recepción de mensajes .................... 22
4.3. Actualización a partir de datos de vigilancia .................... 22
4.4. Registro de datos OLDI .................... 22
4.4.1. Contenido .................... 22
4.4.2. Dispositivos .................... 22
4.5. Disponibilidad, fiabilidad, seguridad e integridad de datos .................... 22
4.5.1. Disponibilidad .................... 22
4.5.2. Fiabilidad .................... 23
4.5.3. Seguridad de los datos .................... 23
4.5.4. Integridad de los datos .................... 23
4.6. Evaluación operativa .................... 23
4.6.1. Período de evaluación .................... 23
4.6.2. Fecha de introducción operativa .................... 23
5. CATEGORÍAS DE MENSAJE .................... 23
5.1. General .................... 23
5.1.1. Objeto .................... 23
5.1.2. Categorías de mensaje .................... 23
5.2. Tiempos de transacción .................... 24
5.2.1. Condiciones del tiempo de transacción .................... 24
5.3. Clasificación y categorización de mensajes .................... 24
5.3.1. Clasificación de mensajes: obligatorio y complementario .................... 24
5.3.2. Categorización de mensajes .................... 25
6. PROCEDIMIENTO BÁSICO - MENSAJES OBLIGATORIOS .................... 26
6.1. General .................... 26
6.1.1. Descripción de requisitos .................... 26
6.1.2. Implantación .................... 26
6.2. Mensaje de información de paso de límite (ABI) .................... 26
6.2.1. Objeto del mensaje ABI .................... 26
6.2.2. Contenidos de mensaje .................... 27
6.2.3. Normas de aplicación .................... 27
6.2.4. Acuse de recibo de mensaje ABI .................... 28
6.2.5. Ejemplos .................... 28
6.3. Mensaje de activación (ACT) .................... 29
6.3.1. Objeto de mensaje ACT .................... 29
6.3.2. Contenidos de mensaje .................... 29
6.3.3. Normas de aplicación .................... 29
6.3.4. Acuse de recibo de mensaje ACT .................... 31
6.3.5. Ejemplos .................... 31
6.4. Mensaje de acuse de recibo lógico (LAM) .................... 31
6.4.1. Objeto del mensaje LAM .................... 31
6.4.2. Contenidos de mensaje .................... 32
6.4.3. Normas de aplicación .................... 32
6.4.4. Acuse de recibo de mensaje LAM .................... 32
6.4.5. Ejemplos .................... 32
7. PROCEDIMIENTO BÁSICO - MENSAJES COMPLEMENTARIOS .................... 32
7.1. General .................... 32
7.1.1. Descripción de requisitos .................... 32
7.1.2. Implantación .................... 32
7.2. Mensaje de activación preliminar (PAC) .................... 33
7.2.1. Objeto de mensaje PAC .................... 33
7.2.2. Contenidos del mensaje .................... 33
7.2.3. Normas de aplicación .................... 33
7.2.4. Acuse de recibo de mensaje PAC .................... 35
7.2.5. Ejemplos .................... 35
7.3. Mensaje de revisión (REV) .................... 36
7.3.1. Objeto de mensaje REV .................... 36
7.3.2. Contenidos del mensaje .................... 36
7.3.3. Normas de aplicación .................... 36
7.3.4. Acuse de recibo de mensaje REV .................... 38
7.3.5. Ejemplos .................... 39
7.4. Mensaje para anulación de coordinación (MAC) .................... 39
7.4.1. Objeto del mensaje MAC .................... 39
7.4.2. Contenidos del mensaje .................... 39
7.4.3. Normas de aplicación .................... 39
7.4.4. Acuse de recibo de un mensaje MAC .................... 41
7.4.5. Ejemplos .................... 41
7.5. Mensaje de asignación de código SSR (COD) .................... 42
7.5.1. Objeto del mensaje COD .................... 42
7.5.2. Contenidos de mensaje .................... 42
7.5.3. Normas de aplicación .................... 42
7.5.4. Acuse de recibo de COD .................... 43
7.5.5. Ejemplos .................... 43
7.6. Mensaje de información (INF) .................... 43
7.6.1. Objeto del mensaje INF .................... 43
7.6.2. Contenidos de mensaje .................... 43
7.6.3. Normas de aplicación .................... 44
7.6.4. Acuse de recibo de mensaje INF .................... 44
7.6.5. Ejemplos .................... 44
8. PROCEDIMIENTO DE DIÁLOGO - COORDINACIÓN
8.1. General .................... 45
8.1.1. Introducción .................... 45
8.1.2. El filtro .................... 45
8.1.3. Secuencia de mensajes .................... 46
8.1.4. Gestión simultánea de mensajes .................... 47
8.1.5. Tratamiento de los mensajes de rechazo .................... 47
8.1.6. Tiempo de respuesta operativo .................... 47
8.1.7. Implantación .................... 47
8.2. Mensaje de activación (ACT) .................... 48
8.2.1. Objeto del mensaje ACT .................... 48
8.2.2. Contenidos del mensaje .................... 48
8.2.3. Normas de aplicación .................... 48
8.2.4. Acuse de recibo de mensaje ACT .................... 49
8.3. Mensaje de referencia a propuesta de activación (RAP) .................... 49
8.3.1. Objeto del mensaje RAP .................... 49
8.3.2. Contenidos del mensaje .................... 49
8.3.3. Normas de aplicación .................... 49
8.3.4. Acuse de recibo de mensaje RAP .................... 50
8.3.5. Respuesta operativa al mensaje RAP .................... 51
8.3.6. Ejemplos .................... 51
8.4. Mensaje de revisión (REV) .................... 51
8.4.1. Objeto del mensaje REV .................... 51
8.4.2. Contenidos del mensaje .................... 51
8.4.3. Normas de aplicación .................... 51
8.4.4. Acuse de recibo de mensaje REV .................... 52
8.4.5. Respuesta operativa a mensaje REV .................... 52
8.5. Mensaje de referencia a propuesta de revisión (RRV) .................... 53
8.5.1. Objeto del mensaje RRV .................... 53
8.5.2. Contenidos del mensaje .................... 53
8.5.3. Normas de aplicación .................... 53
8.5.4. Acuse de recibo de mensaje RRV .................... 53
8.5.5. Respuesta operativa a mensaje RRV .................... 54
8.5.6. Ejemplos .................... 54
8.6. Mensaje de puesta en espera (SBY) .................... 54
8.6.1. Objeto del mensaje SBY .................... 54
8.6.2. Contenidos del mensaje .................... 54
8.6.3. Normas de aplicación .................... 55
8.6.4. Acuse de recibo de mensaje SBY .................... 55
8.6.5. Ejemplos .................... 55
8.7. Mensaje de aceptación (ACP) .................... 55
8.7.1. Objeto del mensaje ACP .................... 55
8.7.2. Contenidos de mensaje .................... 55
8.7.3. Normas de aplicación .................... 56
8.7.4. Acuse de recibo de mensaje ACP .................... 56
8.7.5. Ejemplos .................... 57
8.8. Mensaje de coordinación (CDN) .................... 57
8.8.1. Objeto del mensaje CDN .................... 57
8.8.2. Contenidos del mensaje .................... 57
8.8.3. Normas de aplicación .................... 58
8.8.4. Acuse de recibo de mensaje CDN .................... 58
8.8.5. Respuesta operativa a mensaje CDN .................... 59
8.8.6. Ejemplos .................... 59
8.9. Mensaje de rechazo de coordinación (RJC) .................... 59
8.9.1. Objeto del mensaje RJC .................... 59
8.9.2. Contenidos del mensaje .................... 59
8.9.3. Normas de aplicación .................... 60
8.9.4. Acuse de recibo de mensaje RJC .................... 60
8.9.5. Ejemplos .................... 60
9. PROCEDIMIENTO DE DIÁLOGO - TRANSFERENCIA DE COMUNICACIÓN .................... 60
9.1. General .................... 60
9.1.1. Introducción .................... 60
9.1.2. Secuencia de mensaje .................... 61
9.1.3. Transferencia de comunicaciones .................... 61
9.2. Mensaje de inicio de transferencia (TIM) .................... 61
9.2.1. Objeto del mensaje TIM .................... 61
9.2.2. Contenidos del mensaje .................... 61
9.2.3. Normas de aplicación .................... 62
9.2.4. Acuse de recibo de mensaje TIM .................... 62
9.2.5. Ejemplo .................... 63
9.3. Mensaje de datos complementarios (SDM) .................... 63
9.3.1. Objeto del mensaje SDM .................... 63
9.3.2. Contenidos del mensaje .................... 63
9.3.3. Normas de aplicación .................... 64
9.3.4. Acuse de recibo de mensaje SDM .................... 64
9.3.5. Ejemplo .................... 65
9.4. Propuesta de transferencia (HOP) .................... 65
9.4.1. Objeto del mensaje HOP .................... 65
9.4.2. Contenidos del mensaje .................... 65
9.4.3. Normas de aplicación .................... 65
9.4.4. Acuse de recibo de mensaje HOP.................... 66
9.4.5. Ejemplo .................... 66
9.5. Mensaje de solicitud de frecuencia (ROF) .................... 67
9.5.1. Objeto del mensaje ROF .................... 67
9.5.2. Contenidos del mensaje .................... 67
9.5.3. Normas de aplicación .................... 67
9.5.4. Acuse de recibo de mensaje ROF .................... 67
9.5.5. Ejemplo .................... 68
9.6. Mensaje de cambio de frecuencia (COF) .................... 68
9.6.1. Objeto del mensaje COF .................... 68
9.6.2. Contenidos del mensaje .................... 68
9.6.3. Normas de aplicación .................... 68
9.6.4. Acuse de recibo de mensaje COF .................... 69
9.6.5. Ejemplos .................... 69
9.7. Mensaje de asunción manual de comunicaciones (MAS) .................... 69
9.7.1. Objeto del mensaje MAS .................... 69
9.7.2. Contenidos del mensaje .................... 69
9.7.3. Normas de aplicación .................... 69
9.7.4. Acuse de recibo de mensaje MAS .................... 70
9.7.5. Ejemplo .................... 70
ANEXO A (NORMATIVO) NORMAS DE INTRODUCCIÓN DE DATOS .................... 71
ANEXO B (NORMATIVO) REQUISITOS DE PROCESAMIENTO DE RUTAS ESPECIALES .................... 82
ANEXO C (INFORMATIVO) FASES DEL PROCEDIMIENTO DE DIÁLOGO (SYSCO NIVEL 1) - SECUENCIA DE MENSAJE .................... 88
DERECHOS DE AUTOR
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 disposició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.
PRÓLOGO
1. Organismo responsable
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 integració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 dirigirse 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ón con el Programa de Trabajo EATCHIP
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 Documento Programa de Trabajo (EWPD) Edición 2.0, de fecha 30/09/94.
3. Aprobación y correcciones
La presente Norma ha sido sometida al siguiente procedimiento de aprobación según se detalla en las Directivas para la Normalizació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 representantes 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 por la Comisión permanente.
Las disposiciones de la presente Norma son efectivas a partir del momento de su adopción por la Comisión permanente.
Con el fin de seguir la evolución de los procedimientos de Control de tráfico Aéreo (ATC), se pueden proponer correcciones y adiciones a través del ODT para su debate y posible aprobació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ácticas editoriales
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 Recomendació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 recomendados se utiliza el verbo en tiempo condicional (debería).
Las Notas están escritas en cursiva normal precedida por la palabra "NOTA".
5. Relación con la Edición 1 de la Norma Eurocontrol para el Intercambio de datos en lí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.
6. Cambios significativos respecto a la Edición 1
A continuación se indican los cambios y las adiciones más significativas 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 transferencia 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 únicamente 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 por parte de los Estados
G Directrices para la Implantación
H Directrices para la Evaluación de OLDI
6. Separación en la Parte 3 (Requisitos Técnicos) de las aplicaciones de la Norma.
7. Relación con otros documentos
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 documento, 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 Referencia 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.
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 seguridad 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 interesados 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. Campo de aplicació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 contenido;
- 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 Conferencia de la Aviación Civil Europea (ECAC) apliquen esta Norma a:
- los dispositivos OLDI internacionales entre puestos que dan servicio a un área ATC dentro de un área ECAC;
- los dispositivos OLDI entre 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 vigor las ediciones indicadas de los documentos de referencia.
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 Eurocontrol 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 mencionados, prevalecerá la presente Norma Eurocontrol.
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, 13a Edició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ÍMBOLOS Y ABREVIATURAS
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 realizarse 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 por el límite) según las cuales el vuelo va a pasar del control 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 por los puestos ATC en una secuencia de coordinación y mencionado en los mensajes de coordinación.
3.1.16. Correlación: Proceso, basado en criterios definidos, que consiste en enlazar datos 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.
3.1.17. Norma Eurocontrol: Cualquier norma aplicable a las características 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 incluir condiciones complementarias 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 contenida 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 por la aeronave 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 por encima del cual, o por debajo del cual ha sido coordinado un vuelo para pasar por el punto de transferencia de control. El nivel complementario, 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, procesamiento 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 coordinació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: Comunicar un mensaje de un sistema a otro.
3.1.36. Puesto: Puesto de servicio de tráfico aéreo.
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ímbolos y Abreviaturas
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éreo
ATM Gestión del tráfico aéreo
ATS Servicios de tráfico aéreo
CDN Mensaje de coordinación
CNL 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, Eurocontrol
EATCHIP 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 despegue
EWPD Documento programa de trabajo EATCHIP
FDPS Sistema de procesamiento de datos de vuelo
FRF Ruta de vuelo complementaria
HMI 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ógico
LoA Carta de acuerdo
MAC Mensaje para anulación de coordinación
MAS Aceptación manual de comunicaciones
NM 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ón
REV Mensaje de revisión
RJC Mensaje de rechazo de coordinación
ROF Mensaje de solicitud de frecuencia
RRV Mensaje de referencia a propuesta de revisión
SBY Mensaje de puesta en espera
SDM Mensaje de datos complementarios
SSR Radar secundario de vigilancia
SYSCO Coordinación apoyada en sistemas
TI Inicio de transferencia
TIM Mensaje de iniciación de transferencia
TWR/APP Control de torre (control de aeródromo) y aproximación
4. REQUISITOS GENERALES
4.1. Introducción
Esta sección describe los requisitos operativos generales necesarios para la implantación de un dispositivo OLDI entre puestos ATC, así como su clasificación y los requisitos de funcionamiento de los diferentes tipos de mensajes utilizados.
4.2. Requisitos de los sistemas de procesamiento de datos de vuelo
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 transferencia 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 aplicaciones:
- 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, actualizados automáticamente, manualmente o combinando ambos métodos;
- ser capaz de extraer dichos elementos de la base de datos del plan de vuelo;
- identificar el siguiente puesto ATC en la ruta 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.
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:
- visualizar los contenidos operativos de los mensajes OLDI y los avisos importantes relacionados con los mensajes recibidos, 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 correspondiente ATC o puesto técnico, si no se ha recibido un acuse de recibo dentro del parámetro de tiempo que sigue a una transmisió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 HMI en 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 transferencia.
- 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 informació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 transmisió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.
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 presentació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ón a partir de datos de vigilancia
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 vigilancia para la actualización de la base de datos del plan de vuelo.
4.4. Registro de datos OLDI
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 visualización de los datos registrados.
4.5. Disponibilidad, fiabilidad, seguridad e integridad de datos
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 OLDI deberí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 bilateralmente 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 % (equivalente 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ón Deberían aplicarse métodos para la seguridad datos (p. ej., derechos de acceso, verificación de emisor) a los dispositivos OLDI y, 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 2000 mensajes.
4.6. Evaluación operativa
4.6.1. Período de evaluación
Cada nuevo dispositivo OLDI, incluyendo cualquier nuevo dispositivo 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 OLDI se encuentra disponible en la Secretaría OLDI, Eurocontrol.
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ÍAS DE MENSAJE
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 complementarios;
- 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. Tiempos de transacció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 especificado 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ón y categorización de mensajes
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.
5.3.1.2. Cuando un mensaje esté descrito como de transmisión (TX) obligatoria (M), deberá incluirse el procesamiento para poder enviar dichos mensajes.
5.3.1.3. Cuando un mensaje esté descrito como de recepción (REC) obligatoria, 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 complementaria (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 coordinació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 comunicaciones 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ímite .................. ABI .................. 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ógico ................. LAM ................ - ................... 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 acordada ................. RAP ................. 2 .................. C ..................... M
Revisión acordada ......................................... RRV ................ 2 .................. C ..................... M
Coordinación ................................................. CDN ................ 2 .................. M .................... M
Puesta en espera (1) ....................................... SBY ................. - .................. M .................... M
Aceptación ..................................................... ACP ................. 2 .................. M .................... M
Rechazo de coordinació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) .............................. COP ................ 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 emisor deberá enviar un mensaje COF o el puesto receptor deberá enviar un mensaje MAS
6. PROCEDIMIENTO BÁSICO - MENSAJES OBLIGATORIOS
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 bilateralmente 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. Mensaje de información de paso de lí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 mensaje;
- 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;
- 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 acordada (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 ABI deberí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 ABI y 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 ABI precedente 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 identifica 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.
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 solicitando FL390. A continuación se proporcionan ejemplos equivalentes del mensaje ABI enviado desde Reims a Londres ACC.
6.2.5.1. ICAO
(ABIE/L001-AMM253/A7012-LMML-BNE/1221F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)
6.2.5.2. ADEXP
-TITLE ABI -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 001 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1221 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON
6.3. Mensaje de activació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 mensaje;
- 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;
- 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.
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 transmitido, 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áticamente 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 coordinada 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 procesamiento:
- 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.
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 ser identificado:
-- 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ón
6.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 acordada 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 transferencia 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. ICAO
(ACTE/L005-AMM253/A7012-LMML-BNE/1226F350-EGBB-9/B757/M-15/N0480F390 UB4 BNE UB4 BPK UB3 HON)
6.3.5.2. ADEXP
-TITLE ACT -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 005 -ARCID AMM253 -SSRCODE A7012 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F350 -ADES EGBB -ARCTYP B757 -ROUTE N0480F390 UB4 BNE UB4 BPK UB3 HON
6.4. Mensaje de acuse de recibo lógico (LAM)
6.4.1. Objeto del mensaje LAM
El mensaje LAM es el medio por el cual el puesto receptor indica 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 transmisiones 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 COMPLEMENTARIOS
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 Procedimiento básico - Mensajes obligatorios.
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. Mensaje de activación preliminar (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/coordinació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. General
7.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 por cada vuelo que salga y deba ser objeto de una notificación o coordinació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 similar de la que pueda deducirse el ETO en el COP e iniciar la transmisió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 bilateral, el mensaje deberá:
- contener el número de mensaje del primer mensaje PAC enviado para el vuelo;
- estar incluido en el segundo mensaje PAC y en los posteriores.
7.2.3.1.6. La utilización del dispositivo de solicitud de código, si es necesaria, 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 acordado 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 discrepancias en el mensaje que puedan 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;
- Deberá enviarse un LAM en respuesta.
7.2.3.2.3. Si el mensaje no puede ser asociado a ningún plan de vuelo o se encuentra una discrepancia que obstaculiza el correcto procesamiento del mensaje:
- si el sector responsable de aceptar el control del vuelo puede ser identificado:
-- 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 cualquier PAC posterior 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 circunstancias 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.
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 responsable 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 valor de tiempo que debe aplicarse deberá acordarse bilateralmente.
7.2.5. Ejemplos
7.2.5.1. Hora estimada de despegue y solicitud de código
7.2.5.1.1. ICAO
(PACBA/SZ002-CRX922/A9999-LFSB1638-LSZA-9/B737/M)
7.2.5.1.2. ADEXP
-TITLE PAC -REFDATA -SENDER -FAC BA -RECVR -FAC SZ -SEQNUM 002 -ARCID CRX922 -SSRCODE REQ -ADEP LFSB -ETOT 1638 -ARCTYP B737 -ADES LSZA
7.2.5.2. Hora 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. Mensaje de revisió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;
- Referencia de mensaje (opcional);
- Identificación de la aeronave;
- Modo y código SSR (opcional);
- Aeródromo de salida;
- Datos Estimados;
- Punto de coordinación (opcional);
- Aeródromo de destino;
- 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.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.
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 o en el código SSR.
7.3.3.1.4. Deberá enviarse un mensaje REV, si se ha acordado bilateralmente, cuando se produzca algún cambio que afecte a:
- el COP;
- la ruta;
- otros datos del plan de vuelo (ICAO campos 8, 10 y 18).
NOTA Las normas operativas pueden exigir que las modificaciones 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 condiciones 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 ICAO
Todos los mensajes de revisión incluyen los campos tipo 3, 7, 13, 14 y 16. Los siguientes tipos de revisión están incluidos dentro de esos campos:
- Cualquier cambio del ETO en el COP o del nivel o niveles de transferencia deberá figurar en los datos revisados en el campo 14;
- Cualquier cambio en el código SSR deberá incluirse en el campo 7;
- los cambios de ruta que incluyan cambios en el COP se indicarán en los datos de los campos 14 y 15, incluidos en el formato del campo 22 después de los cinco campos iniciales. Dichos mensajes incluirán dos campos 14, el primero contendrá únicamente el elemento a), el COP a través del cual el vuelo ha sido coordinado previamente. Las normas para la coordinación de dichos cambios, incluyendo rutas directas, se especifican en el Anexo B, Requisitos especiales para el procesamiento de rutas;
- las modificaciones a los campos 8, 10 y 18 deberán incluirse como datos del campo 22 después de los cinco campos iniciales.
7.3.3.2.2. Formato ADEXP
Todos los mensajes de revisión en formato ADEXP deberán incluir los siguientes campos primarios: TITLE REFDATA ARCID ADEP ADES. Se aplicarán las siguientes normas:
- cualquier cambio 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;
- los cambios de ruta, incluyendo los cambios de COP, deberán incorporarse en los campos primarios COORDATA y ROUTE. Dichos mensajes deberán incluir el Campo primario COP que contiene el Punto de coordinación a través del cual se ha coordinado el vuelo previamente. Las normas para la coordinación de dichos cambios, incluyendo rutas directas, se especifican en el Anexo B;
- cualquier cambio en el código SSR deberá indicarse mediante la inclusión del Campo primario SSRCODE;
- las modificaciones en otros datos del plan de vuelo deberán incorporarse mediante la inclusión de los campos primarios requeridos según se define en el Anexo A para Otros datos del plan de vuelo.
Si se envía un mensaje de revisión para coordinar solamente el Código SSR y/o Otros datos del plan de vuelo, en lugar del campo COORDATA se incluirá el Campo primario COP.
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 receptor
7.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 correspondiente.
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ón
7.3.3.4.1. El mensaje REV está desencadenado por un suceso y deberá transmitirse inmediatamente después de la introducción o actualizació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 determinada 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).
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 recibo
7.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 responsable 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. ICAO
a. (REVE/L002-AMM253-LMML-BNE/1226F310-EGBB)
b. (REVE/L010-AMM253/A2317-LMML-BNE/1226F310-EGBB)
7.3.5.2. ADEXP
a. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 002 -ARCID AMM253 -ADEP LMML -COORDATA -PTID BNE -TO 1226 -TFL F310 -ADES EGBB
b. -TITLE REV -REFDATA -SENDER -FAC E -RECVR -FAC L -SEQNUM 010 -ARCID AMM253 -ADEP LMML -COP BNE -ADES EGBB -SSRCODE A2317
7.4. Mensaje para anulación de coordinació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).
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 supuestos:
- 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 coordinació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 bilateralmente.
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 transferencia;
--- 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 por cualquier otro 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á dar lugar al envío de un mensaje ABI o ACT revisado, 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 por cualquier otro 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 correctamente un nuevo mensaje de notificación y/o de coordinación procedente del puesto transmisor previo o de un puesto diferente 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 recibo
7.4.4.1.1. Si el mensaje MAC puede ser asociado con un plan de vuelo dentro del sistema receptor y puede ser procesado, deberá transmitirse un mensaje LAM en señal de acuse de recibo.
7.4.4.1.2. Si el mensaje MAC no puede ser asociado 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 recibo
7.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 Maastricht, 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 CAN
7.5. Mensaje de asignación de código SSR (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 asignación de código de manera central, por ejemplo por un ACC, puede ser necesario asignar individualmente 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 por cada puesto ATS a otro 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áticamente 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 especifica en Plan de navegación aérea para la región europea, en caso de no poder disponer de 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 impedir el 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.
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. Mensaje de informació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 acordadas 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 ser duplicados por un 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 o 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, dependiendo 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 subir a FL410, estima llegar al VOR de Koksy (KOK) a las 1905, transpondedor 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. PROCEDIMIENTO DE DIÁLOGO - COORDINACIÓN
8.1. General
8.1.1. Introducción
8.1.1.1. El procedimiento de diálogo proporciona los medios de comunicación y negociación entre controladores en la fase de coordinación y los medios de comunicación en la fase de transferencia.
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 transferencia, 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 interdependientes, pueden ser aplicados 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 ser aceptadas 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 identificar cualquier discrepancia entre ellas.
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 conformidad 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 bilateralmente.
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 disconformidad con la LoA". Salvo acuerdos bilaterales en contrario, los mensajes enviados por puestos de transferencia para coordinaciones que se sabe que son estándar deberán utilizar tipos 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 condiciones 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 transferencia no son estándar, deberá comunicarse este hecho al controlador de la transferencia para su confirmación o modificación.
8.1.2.3. Acciones en el puesto receptor
8.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 transferencia 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é en 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 coordinació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 coordinació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 por telé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 controlador 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 finalizació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 diferentes mensajes en cada una de las fases y los tiempos de transacción requeridos son diferentes. Los mensajes de coordinació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 coordinació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;
- en el diálogo de coordinación el tiempo no es tan primordial y, por consiguiente, sus requisitos de HMI son menos rigurosos.
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 complementario 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. Mensaje de activació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 transferencia 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 Activació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 correspondiente 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 procesados 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.
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 lugar de un LAM para indicar la aceptación por parte del puesto receptor de un ACT que contenga condiciones 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 coordinación del vuelo.
8.3. Mensaje de referencia a propuesta de activació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 transferencia 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. General
8.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 condiciones de transferencia no son estándar;
- el controlador de transferencia ha indicado que las condiciones 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 transmitir 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.
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 ser asociado 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 manual
8.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ón
8.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)
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. Mensaje de revisió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 transferencia 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 especificadas 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 continuació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 receptor
8.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 transferencia 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 recibo
8.4.4.1.1. El acuse de recibo del mensaje REV, en su caso, deberá realizarse mediante:
- un mensaje LAM, si se estima que las condiciones de transferencia son estándar;
- un mensaje SBY, si se estima que las condiciones de transferencia 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.
8.4.4.1.3. Si se ha acordado bilateralmente, puede utilizarse un mensaje ACP en lugar de un mensaje LAM para indicar la aceptación por parte del puesto receptor de un REV conteniendo las condiciones 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á visualizarse 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 sistema del 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. Mensaje de referencia a propuesta de revisió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 revisió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 opcionalmente 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 condiciones de transferencia no son estándar;
o
- el controlador de transferencia ha indicado que las condiciones 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 receptor
8.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 generación y transmisión de un mensaje SBY.
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á enviar un 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. Mensaje de puesta en espera (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)
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. Mensaje de aceptació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 lugar de 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 contener los 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 transferencia 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 acordadas 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 ser asociado con un plan de vuelo, la aceptación deberá ser indicada al controlador.
8.7.3.2.3. Si el ACP no puede ser asociado 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 recibo
8.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 generació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 aceptació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. Mensaje de coordinació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 transferencia 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. General
8.8.3.1.1. Sólo el controlador receptor podrá iniciar mensajes CDN.
8.8.3.1.2. Deberá utilizarse para transmitir una nueva propuesta del controlador 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 bilateral; 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 anterior 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 coordinació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ón del 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 ser vinculantes para 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 ser asociado o existe una discrepancia 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 generació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 transferencia propuestas en un mensaje CDN.
8.8.5.1. Aceptación
Cuando el controlador de transferencia elige aceptar las condiciones de transferencia propuestas, deberá enviar en respuesta un mensaje ACP.
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. Mensaje de rechazo de coordinació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. General
8.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 cualquier coordinació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 receptor
8.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 responsable 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 procesamiento, 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.
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 DE COMUNICACIÓ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 ser implantados a menos que el puesto esté utilizando los dispositivos 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 disponibilidad 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 decir que 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 coordinación esté en curso.
9.1.3. Transferencia de comunicaciones
9.1.3.1. El método de denotar el cambio real 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 transferencia de comunicación.
9.2. Mensaje de inicio de transferencia (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);
- enviar simultáneamente los datos de control 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. General
9.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 disponibles 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 disposiciones 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ámetros 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 coordinació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 ser asociado 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 ser asociado sin ambigüedad con el plan de vuelo, no deberá realizarse ningún acuse de recibo.
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. Mensaje de datos complementarios (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 ser utilizado por el 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 transferencia
9.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 transferencia 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 apartado 9.3.3.1.1 deberán transmitirse antes del TI, si se ha acordado bilateralmente.
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 receptor
9.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. Propuesta de transferencia (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;
- 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 transferencia (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 receptor
9.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 transferencia 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 transferencia 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 ser asociado con un plan de vuelo, se enviará automáticamente 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 STJ
9.5. Mensaje de solicitud de frecuencia (ROF)
9.5.1. Objeto del mensaje ROF
El ROF es enviado por el puesto receptor al puesto de transferencia, 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 controlador 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 receptor
9.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 generació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. Mensaje de cambio de frecuencia (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 transferencia 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 controlador 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 transferencia (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 recibo
9.6.4.1.1. Si el mensaje COF puede ser asociado 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 ser asociado 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. Mensaje de asunción manual de comunicaciones (MAS)
9.7.1. Objeto del mensaje MAS
El MAS es enviado por el puesto receptor al puesto de transferencia para indicar que ha sido establecido contacto de radio bidireccional con el vuelo.
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. General
9.7.3.1.1. El mensaje MAS deberá ser iniciado manualmente por el controlador 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 receptor
9.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á comunicado 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 ser asociado 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 ser asociado 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 AMM253
ANEXO A (Normativo)
NORMAS DE INTRODUCCIÓN DE DATOS CONTENIDO
A.1. Objeto
A.2. Formatos genéricos de mensaje
A.3. Tipo de mensaje
A.4. Número de mensaje
A.5. Referencia de mensaje
A.6. Identificación de aeronave
A.7. Modo y código SSR
A.8. Aeródromo de salida
A.9. Datos estimados
A.10. Punto de coordinación
A.11. Aeródromo de destino
A.12 Número y tipo de aeronave
A.13. Ruta
A.14. Otros datos del plan de vuelo
A.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 directa
A.21. Posición (sólo ADEXP)
A.22. Indicación de transferencia (sólo ADEXP)
A.23. Frecuencia
A.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 despeque
A.28. Tipo de mensaje de referencia
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 aplicación para un mensaje determinado se indican específicamente otras alternativas o excepciones a estas normas.
A.2. Formatos genéricos de mensaje
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.
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 anteriormente.
A.2.3. Todos los mensajes descritos en el presente documento pueden ser transmitidos utilizando el formato Eurocontrol ADEXP. Los contenidos, 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 opcionales 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 solamente en formato ADEXP.
A.3. Tipo de Mensaje
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".
A.4. Número de mensaje
Los datos de número de mensaje incluyen los identificadores asignados a los puestos de transferencia y receptor y el número de orden del mensaje. El número de orden del mensaje varía secuencialmente desde 001 hasta 000 (que representa a 1000), después se repite desde 001 para todos los mensajes enviados al mismo destinatario, 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. Referencia de mensaje
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ón de aeronave
A.6.1. ICAO
Campo de tipo 7, elemento (a).
A.6.2. ADEXP
Campo primario "arcid".
A.7. Modo y Código SSR
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 transferencia;
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 desconocido, 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".
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ódromo de salida
A.8.1. ICAO
Campo de tipo 13, elemento (a).
A.8.2. ADEXP
Campo primario "adep".
A.9. Datos estimados
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 complementarios 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 conocido, como queda definido en el Campo primario "REF" o "GEO" del mismo mensaje.
A.10. Punto de coordinación
A.10.1. General
A.10.1.1. El punto de coordinación mencionado por los puestos ATC de transferencia 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; o
- un rumbo y una distancia desde un punto de referencia conocido, según queda definido en el Campo primario "REF" o "GEO" del mismo mensaje.
A.11. Aeródromo de Destino
A.11.1. ICAO
Campo 16, elemento (a).
A.11.2. ADEXP
Campo primario "ades".
A.12. Número y tipo de aeronave
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á disponible. 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 significativo).
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. Otros datos del plan de vuelo
A.14.1. ICAO
Campos del tipo 8, 10, y 18, en formato del campo tipo 22.
A.14.2. ADEXP
Campos primarios: "afildata", "ceqpt", "com", "comment", "depz", "destz", "eetfir", "eetpt", "fltrul", "flttyp", "mach", "nav", "opr", "per", "reg", "rif", "rmk", "sel", "seqpt", "sts" y "typz".
A.15. Estado de coordinación y motivo
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 estar en un estado de notificación;
-- CRD, cuando el plan de vuelo en el sistema deba estar en 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, por cualquier otro 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 indicador que especifica el motivo.
A.15.2. ADEXP
Campo primario "cstat".
Los elementos auxiliares "coordstatusident" y "coordstatusreason" deberán contener el nuevo estado y el motivo, respectivamente, según se ha especificado anteriormente.
A.16. Rumbo asignado (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. Velocidad asignada (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. Velocidad de ascenso/descenso asignada (sólo ADEXP)
El Campo primario "rate" deberá contener:
- la velocidad de ascenso o descenso asignada al vuelo, expresada en cientos de pies por minuto;
o
- si no se ha asignado la velocidad de ascenso/descenso, el indicador "ZZZ" en la parte numérica del campo, por ejemplo, cuando se utilice un mensaje SDM para indicar que una velocidad de ascenso/descenso asignada previamente ya no es aplicable.
A.19. Autorización de ruta directa (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 acordados 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 conocido, según se define en el Campo primario "REF" del mismo mensaje;
o
-- el valor "ZZZ", si el puesto transmisor no 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 conocido, según se define en el Campo primario "REF" del mismo mensaje.
A.20. Solicitud de ruta directa
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 acordados bilateralmente, es decir, conocidos por ambos sistemas.
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 conocido;
o
-- el valor "ZZZ", si el puesto ATC receptor esta solicitando una ruta directa.
- la abreviatura "DCT",
- seguido por el punto situado en la ruta 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 conocido.
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 conocido, según se define en el Campo primario "REF" del mismo mensaje;
o
-- el valor "ZZZ", si el puesto ATC receptor recibe una solicitud 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 conocido, 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 horizontal actual del avión. Los puntos utilizados para la indicación de distancia o rumbo en el Campo primario "ref" deberán ser acordados 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 bilateral.
A.22. Indicación de transferencia (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.
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. Nivel de vuelo autorizado (sólo ADEXP)
Campo primario "cfl".
A.26. Nivel de vuelo propuesto para la transferencia (sólo ADEXP)
Campo primario "propfl".
A.27. Hora estimada de despegue
A.27.1. ICAO
Campo tipo 13, elemento (b).
A.27.2. ADEXP
Campo primario "etot".
A.28. Tipo de mensaje de referencia
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".
ANEXO B (Normativo)
REQUISITOS DE PROCESAMIENTO DE RUTAS ESPECIALES
B.1. Introducción
B.1.1. General
B.1.1.1. El presente Anexo describe las normas y los requisitos para introducció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 registrado en el plan de vuelo;
- después de la transmisión de un mensaje ABI o ACT, redireccionamiento 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 modificació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ón de mensajes
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 cualquier mensaje 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 ABI y antes de la de un ACT
Deberá enviarse un nuevo mensaje ABI con los datos correspondientes 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;
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. Contenidos de campo
B.3.1. Rutas ATS
Para los vuelos que son redireccionados vía una ruta ATS alternativa, 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).
IMAGEN OMITIDA
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
IMAGEN OMITIDA
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 intersecció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)
IMAGEN OMITIDA
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.
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 coordinación EMT. Se transmite el siguiente mensaje ACT:
(ACTK/G206-GKP217/A2332-EGNX-EMT/1211F270-DTTA-9/FK28/M)
IMAGEN OMITIDA
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 revisión:
(REVK/G214-GKP217-EGNX-EMT-DTTA-14/XAT/1225F270-15/N0430F290 UM247 XAT UJ124)
IMAGEN OMITIDA
A continuación, se autoriza al vuelo para dirigirse a FL290, lo que da lugar al siguiente mensaje (que contiene el nuevo COP):
(REVK/G233-GKP217-EGNX-XAT/1225F290-DTTA)
IMAGEN OMITIDA
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 DTTA
ANEXO C (Informativo)
FASES DEL PROCEDIMIENTO DE DIÁLOGO (SYSCO NIVEL 1) - SECUENCIA DE MENSAJES
Secuencia de mensajes
IMAGEN OMITIDA
ANEXO II
PRESENTACIÓN DEL INTERCAMBIO DE DATOS DE SERVICIOS DE TRÁFICO AÉREO (ADEXP), EDICIÓN 2.0
(Documento de referencia de Eurocontrol DPS.ET1.ST09-STD)
ÍNDICE
DERECHOS DE AUTOR .................... 91
PRÓLOGO .................... 92
1. CAMPO DE APLICACIÓN .................... 94
2. REFERENCIAS .................... 94
3. DEFINICIONES, SIMBOLOS Y ABREVIATURAS .................... 95
3.1. Notación .................... 95
3.2. Definiciones .................... 95
3.3. Construcción .................... 95
3.4. Convenciones .................... 95
3.5. Operadores .................... 96
3.6. Abreviaturas .................... 97
4. PRINCIPIOS ADEXP .................... 98
4.1. Formato de texto de lectura directa .................... 98
4.2. Campos identificados y recuperables .................... 99
4.3. Campos no reconocidos .................... 99
5. REGLAS SINTÁCTICAS ADEXP .................... 100
5.1. Elementos de léxico .................... 100
5.2. Campos .................... 104
6. DESCRIPCIÓN NORMALIZADA DE LOS MENSAJES ADEXP .................... 106
6.1. Introducción .................... 106
6.2. Términos auxiliares .................... 107
6.3. Definición de los campos primarios .................... 108
6.4. Definición de los subcampos .................... 108
6.5. Grupo de mensajes .................... 108
ANEXO A (NORMATIVO) DEFINICIONES DE CAMPOS ADEXP .................... 110
ANEXO B (NORMATIVO) ÍNDICE CENTRAL DE TÍTULOS DE MENSAJE ADEXP .................. 137
ANEXO C (NORMATIVO) ÍNDICE CENTRAL DE TÍTULOS DE MENSAJE RESERVADOS .................... 140
ANEXO D (NORMATIVO) ÍNDICE CENTRAL DE CAMPOS RESERVADOS .................... 145
ANEXO E (INFORMATIVO) INTRODUCCIÓN DE GRUPOS DE MENSAJES .................... 159
ANEXO F (INFORMATIVO) EJEMPLOS DE FORMATO DE MENSAJES ADEXP .................... 164
ANEXO G (INFORMATIVO) FUTUROS DESARROLLOS .................... 167
DERECHOS DE AUTOR
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 disposició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.
PRÓLOGO
1. Órgano responsable
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. Programa de trabajo EATCHIP
La presente Norma es el resultado del Programa de trabajo EATCHIP (EWPD), Dominio de sistemas de procesamiento de datos, Tarea ejecutiva 09.
3. Aprobación de la Norma
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 por la Comisión Permanente de Eurocontrol en 1995 y su fecha de aplicación es a partir del 1o de Diciembre de 1997.
4. Rectificaciones técnicas y enmiendas
La presente Norma está sujeta a revisión para determinar las posibles 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 Directivas 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 usuarios (ADEXP), Eurocontrol.
5. Convenciones editoriales
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ón con otros documentos normativos
La presente Norma está relacionada con:
La Norma Eurocontrol para el Intercambio de datos en línea (OLDI).
7. Estado de los Anexos a la presente Norma
Anexo A Normativo;
Anexo B Normativo;
Anexo C Normativo;
Anexo D Normativo;
Anexo E Informativo;
Anexo F Informativo;
Anexo G Informativo.
8. Idioma utilizado
El texto original de la presente Norma ha sido redactado en lengua inglesa.
1. CAMPO DE APLICACIÓ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 informació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/militar y mensajes que crucen 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 disposiciones 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 inmediato 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 formalmente 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 n° 6 de noviembre de 1995);
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, SIMBOLOS Y ABREVIATURAS
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 determinan 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 ser denominado un mensaje ADEXP sintácticamente correcto.
3.2. Definiciones
A los efectos de la presente Norma Eurocontrol, deberán aplicarse 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
NOTAS
1) 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 por un analizador de léxico debido a la presencia de separadores.
3.4. Convenciones
A los efectos de la presente Norma Eurocontrol, deberán aplicarse 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 (por ejemplo el lado derecho de una producción gramatical) figuran en letras minúsculas.
- Los Caracteres y Cadenas literales que aparecen dentro de las reglas aparecen entre apóstrofos (') o comillas ("), respectivamente.
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 utilizando 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 combinaciones 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 aplicarse 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 representa mediante un trazo vertical "|".
Concatenación: Representación de símbolos ordenados secuencialmente, 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 indicando 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 concatenació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 equivalente a: a ::= (B C) | D y NO es 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 ATS
ADEXP Presentación de intercambio de datos ATS
AFIL Plan de vuelo registrado en el aire
AFP Propuesta de plan de vuelo ATC
AFTN Red fija de telecomunicaciones aeronáuticas
ANM Mensaje de notificación ATFM
AO Operador(es) de aeronaves
APL Plan de vuelo ATC
ATC Control del tráfico aéreo
ATCU Unidad(es) de control de tráfico aéreo
ATFM Gestión de flujo de tráfico aéreo
ATS Servicios de tráfico aéreo
BNF Backus Naur Form
CASA Asignación de ranura asistida por ordenador
CIDIN Red común de intercambio de datos de la ICAO
CFL Nivel de vuelo autorizado
CFMU Unidad central de gestión fe flujo de tráfico aéreo
CMTP Plan común a medio plazo
CNL Mensaje de cancelación
CTOT 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 estacionamiento
ESTO Hora estimada de paso por la vertical
EUROCONTROL 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 vuelo
FPL Mensaje del plan de vuelo (formato ICAO)
GAT Tráfico aéreo genral
IA Alfabeto internacional
IAFP Propuesta de plan de vuelo individual ATC
ICAO organización de aviación civil internacional
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 normalizació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ón
RFPD Datos de plan de vuelo repetitivo
RPL Plan de vuelo repetitivo
RVR Alcance visual en pista
SFL Nivel de vuelo complementario
SRD Documento de requisitos de software
SSR Radar secundario 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. PRINCIPIOS ADEXP
4.1. Formato de texto de lectura directa
4.1.1. El formato ADEXP es un formato de texto, basado en caracteres.
4.1.2. Los mensajes ADEXP pueden ser leídos por un operador 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. Campos identificados y recuperables
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 por palabras 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 los campos permitidos.
4.2.5. Los campos pueden ser básicos o compuestos.
4.2.6. Los elementos que constituyen los campos compuestos se denominan 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.
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 ser bá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 ser opcionales u obligatorios, según su sintaxis.
4.3. Campos no reconocidos
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 reconoce 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 reconocido.
4.3.4. Si el campo no reconocido es un campo de lista (que se ha identificado 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.
3) Campo de lista
-BEGIN RTEPTS -PT -PTID CMB -ETO 9305091430 -RFL F370 -PT -PTID
.....
-END RTEPTS
donde "-BEGIN" es el indicador de campo de lista y "RTEPTS" es un campo primario.
NOTA "RFL" está definido como un campo primario. La inclusió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. REGLAS SINTÁCTICAS ADEXP
5.1. Elementos de lé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 n° 5 (IA-5), según se define en la Referencia 1.
5.1.1.2. El formato ADEXP está diseñado como formato para el intercambio 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 relacionados 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 telegráfico n° 2 (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 caracteres 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 ser transmitidos por medio 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ínea
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 valor es un "valor con 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" indistintamente.
5.1.4.4. La sintaxis de un campo que admite un valor con signo será la siguiente:
'-' "KEYWORD" ("P" | "N") ! 1{DIGIT}
Ejemplo:
Un campo titulado "NUMBER" que puede contener un valor negativo de uno a ocho dígitos se definiría de la siguiente forma:
'-' "NUMBER" ("P" | "N") ! 1{DIGIT}8
Por lo tanto:
-NUMBER P5 - el valor de "number" es +5
-NUMBER N5 - el valor de "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 precedida 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 or contained value >
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 valor contenido pertinente.
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 (Las siguientes secuencias introducen un campo de forma válida.)
1) -TITLE IFPL
2) - TITLE IFPL
3) - 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 recomendada.
2) También es importante tener en cuenta que una palabra clave tiene que ir seguida inmediatamente por al menos un separador.
5.1.5.4. A lo largo del documento, la concatenación de elementos separados por al menos un separador se representa implícitamente por la 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 (observaciones).
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_field
basic_field ::= '-' keyword contained_values
contained_values ::= {CHARACTER}
list_field ::= '-' "BEGIN" keyword {subfields} '-' "END" keyword
structured_field ::= '-' keyword field_1 field_2 ....field_n
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 valor del campo y puede no introducir ningú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 recomienda 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 ser cualquier combinació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).
Ejemplo de regla 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_n
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).
Ejemplo de regla pt ::= '-' "PT" ptid [fl] [eto]
NOTAS
1) 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 estimado de paso por la vertical (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 individual;
- 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 (especificación de interfaz) que es aplicable al grupo de mensajes pertinente (Véase sección 6.5.7).
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 particular, 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 diferentes 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érminos auxiliares
6.2.1. Para obtener una definición legible de los campos, a menudo resulta útil introducir términos auxiliares en la descripción gramatical.
6.2.2. Estos términos auxiliares no sirven para introducir un campo o subcampo y, por ello, no están asociados con ninguna palabra clave en particular. Sin embargo, pueden aparecer en la definició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:
TABLA OMITIDA
6.3. Definición de los campos primarios
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 (es 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").
TABLA OMITIDA
6.4. Definición de los subcampos
6.4.1. Todos los subcampos utilizados en los mensajes ADEXP deberán estar conformes 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 ser subcampo de otros 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:
TABLA OMITIDA
6.5. Grupo de mensajes
6.5.1. Las categorías operativas (grupos) de mensajes que han sido definidas 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 correspondientes 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 estos títulos de mensajes reservados en los grupos de mensajes ADEXP actualmente definidos. Por lo general, se trata de mensajes definidos en previsión de una futura utilización dentro de los grupos definidos o se utilizan de forma local dentro de sistemas nacionales. 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.
ANEXO A (Normativo)
DEFINICIONES DE LOS CAMPOS ADEXP
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érminos auxiliares ADEXP
TABLA OMITIDA
A.3. Campos primarios ADEXP
TABLA OMITIDA
A.4. Subcampos ADEXP
TABLA OMITIDA
ANEXO B (Normativo)
ÍNDICE CENTRAL DE TÍTULOS DE MENSAJES ADEXP
TABLA OMITIDA
ANEXO C (Normativo)
ÍNDICE CENTRAL DE TÍTULOS DE MENSAJE RESERVADOS
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 necesite 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ítulos de mensajes reservados
TABLA OMITIDA
ANEXO D (Normativo)
ÍNDICE CENTRAL DE CAMPOS RESERVADOS
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érminos auxiliares reservados
TABLA OMITIDA
D.4. Campos primarios reservados
TABLA OMITIDA
D.5. Subcampos reservados
TABLA OMITIDA
ANEXO E (Informativo)
INTRODUCCIÓN DE GRUPOS DE MENSAJES
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 proporciona una lista completa de todos los títulos de mensajes ADEXP.
NOTA Si desea conocer las condiciones, reglas de aplicación y campos de utilización exactos, particularmente la utilización de campos opcionales, deberá consultar la documentación pertinente de los sistemas correspondientes (por ejemplo, documento de especificación de interfaz).
E.1. Mensajes de plan de vuelo
E.1.1. Introducción
Los mensajes que pertenecen a esta categoría se intercambian principalmente 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 inserció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 980305123152
-PT -PTID LOTEE -FL F330 -ETO 980305124401
-PT -PTID AVS -FL F330 -ETO 980305125357
-PT -PTID KORET -FL F330 -ETO 980305130137
-PT -PTID BARKO -FL F330 -ETO 980305130734
-PT -PTID CANAR -FL F330 -ETO 980305131544
-PT -PTID VIS -FL F330 -ETO 980305132220
-PT -PTID FTM -FL F234 -ETO 980305133230
-PT -PTID LPPT -FL F000 -ETO 980305134529
-END RTEPTS
-ATSRT UR41 SAM ORTAC -ATSRT UR1 ORTAC QPR -ATSRT UR107 QPR AVS
-ATSRT UG41 AVS FTM
E.2. Mensajes de gestión de flujo de tráfico aéreo
E.2.1. Introducción
Los mensajes que pertenecen a esta categoría se intercambian principalmente 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 -POSITION -PTID LIFFY -TO 1646
E.3. Mensajes de coordinación ATC
E.3.1. Introducción
Los mensajes de coordinación se utilizan para automatizar la coordinació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
Activar mensaje
-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. Mensajes de gestión del espacio aé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 segregació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 LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803290600 199803290730
-AIRROUTE -NUM 003 -REFATSRTE UA44 ESP LP BEJ LP
-FLBLOCK -FL F245 -FL F255 -VALPERIOD 199803291830 199803300600
-AIRROUTE -NUM 004 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803290600 199803290730
-AIRROUTE -NUM 005 -REFATSRTE A44 ESP LP BEJ LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803291830 199803300600
-AIRROUTE -NUM 006 -REFATSRTE A44 BEJ LP ROSAL LP
-FLBLOCK -FL F105 -FL F245 -VALPERIOD 199803292030 199803300530
-AIRROUTE -NUM 007 -REFATSRTE UA57 FFM ED DIK EL
-FLBLOCK -FL F250 -FL F450 -VALPERIOD 199803290700 199803291330
-END LACDR
E.5. Mensajes de coordinación civil/militar
E.5.1. Introducción
Mensajes utilizados en la coordinación de datos de vuelo y las solicitudes 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 012
ANEXO F (Informativo)
EJEMPLOS DE FORMATO DE MENSAJE ADEXP
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á garantizada 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 TALAS
-ALTRNT1 LBSF
-EETFIR EDUU 0014
-EETFIR LOVV 0035
-EETFIR LJLA 0054
-EETFIR LHCC 0057
-EETFIR LYBA 0113
-EETFIR LWSS 0148
-EETFIR LGGG 0159
-BEGIN RTEPTS
-PT -PTID EDDF -FL F000 -ETO 980317071500
-PT -PTID NDG -FL F311 -ETO 9803173414
-PT -PTID RIDER -FL F327 -ETO 980317073726
-PT -PTID MAH -FL F330 -ETO 980317074130
-PT -PTID MUN -FL F330 -ETO 980317074449
-PT -PTID CHIEM -FL F330 -ETO 980317074754
-PT -PTID UNKEN -FL F330 -ETO 980317075109
-PT -PTID GRZ -FL F330 -ETO 9803170080830
-PT -PTID DIMLO -FL F330 -ETO 980317081443
-PT -PTID BABIT -FL F330 -ETO 980317083107
-PT -PTID SAVIN -FL F330 -ETO 980317083613
-PT -PTID UPIVO -FL F330 -ETO 980317084054
-PT -PTID KLENA -FL F330 -ETO 980317084204
-PT -PTID VAL -FL F330 -ETO 980317084629
-PT -PTID KAVOR -FL F330 -ETO 980317085329
-PT -PTID BUI -FL F330 -ETO 980317090135
-PT -PTID SARAX -FL F330 -ETO 980317090650
-PT -PTID PEP -FL F312 -ETO 980317091414
-PT -PTID TALAS -FL F241 -ETO 980317091746
-PT -PTID LGTS -FL F000 -ETO 980317093138
-END RTEPTS
-SID NDG3D
-ATSRT UW70 NDG MUN
-ATSRT UB103 MUN UNKEN
-ATSRT UT23 UNKEN BABIT
-ATSRT UR26 BABIT SAVIN
-ATSRT UG18 SAVIN BUI
-ATSRT UB1 BUI TALAS
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 -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 3
-TITLE IFPL-BEGIN ADDR-FAC CFMUTACT-FAC LFFFSTIPFAC EDFFZRZL-FAC EDZZZQZA-FAC EDUUZQZA-FAC LOVVZQZX-FAC LHBPZEZX-FAC LYBAZQZX-FAC LWSSZQZX-FAC LGTSZAZX-END ADDR-ADEP EDDF-ADES LGTS-ARCID DLH3728-ARCTYP B73A-CEQPT SDMR-EOBD 980517-EOBT 0715-FILTIM 170421-IFPLID AA05986101-ORGNID DLHAOCC-ORIGIN-NETWORKTYPE SITA-FAC FRAOXLH-REG DABHM-SEL KMGJ-SRC FPL-FLTTYP S-WKTRC M-TTLEET 0210-RFL F330-SPEED N0417-FLTRUL I-SEQPT C-ROUTE N0417F330 NDG3D NDG UW70 MUN UB103 UNKEN UT23 BABIT UR26 SAVIN UG18 BUI UB1 TALAS-ALTRNT1 LBSF-EETFIR EDUU 0014-EETFIR LOVV 0035-EETFIR LJLA 0054-EETFIR LHCC 0057-EETFIR LYBA 0113-EETFIR LWSS 0148-EETFIR LGGG 0159-BEGIN RTEPTS-PT-PTID EDDF-FL F000-ETO 980317071500-PT-PTID NDG-FL F311-ETO 9803173414-PT-PTID RIDER-FL F327-ETO 980317073726-PT-PTID MAH-FL F330-ETO 980317074130-PT PTID MUN-FL F330-ETO 980317074449-PT-PTID CHIEM-FL F330-ETO 980317074754-PT-PTID UNKENFL F330-ETO 980317075109-PT-PTID GRZ-FL F330-ETO 9803170080830-PT-PTID DIMLO-FL F330-ETO 980317081443-PT-PTID BABIT-FL F330-ETO 980317083107-PT-PTID SAVIN-FL F330-ETO 98031708361-PT-PTID UPIVO-FL F330-ETO 980317084054-PT-PTID KLENA-FL F330-ETO 980317084204-PT-PTID VAL-FL F330-ETO 980317084629-PT-PTID KAVOR-FL F330-ETO 980317085329-PT-PTID BUI-FL F330-ETO 980317090135-PT-PTID SARAX-FL F330-ETO 980317090650-PT-PTID PEP-FL F312-ETO 980317091414-PT-PTID TALAS-FL F241-ETO 980317091746-PT-PTID LGTS-FL F000-ETO 980317093138-END RTEPTS-SID NDG3D-ATSRT UW70 NDG MUN-ATSRT UB103 MUN UNKEN-ATSRT UT23 UNKEN BABIT-ATSRT UR26 BABIT SAVIN-ATSRT UG18 SAVIN BUI-ATSRT UB1 BUI TALAS
ANEXO G (Informativo)
DESARROLLOS FUTUROS
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 desarrollo.
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 coordinado. 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 palabras 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 recuperació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 cualquier nivel de englobamiento. Sin embargo, no existe la capacidad de recuperarse de un subcampo no reconocido, cuando el error ocurre en un tercer o cuarto nivel de englobamiento, sin que exista posibilidad 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 malinterpretar 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 campo será reemplazado por el carácter "(". El final de un campo, que actualmente no está indicado explícitamente, estaría indicado en el futuro mediante el carácter ")". Los ejemplos siguientes ilustran este principio.
Ejemplos
TABLA OMITIDA
ANEXO III
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)
TABLA DE CONTENIDOS
DERECHOS DE AUTOR .................... 174
PRÓLOGO .................... 175
1. INTRODUCCIÓN .................... 177
2. ALCANCE .................... 177
3. REFERENCIAS .................... 178
3.1. Introducción .................... 178
3.2. Referencias .................... 178
4. DEFINICIONES, SÍMBOLOS Y ABREVIATURAS .................... 179
4.1. Definiciones .................... 179
4.2. Símbolos y abreviaturas .................... 180
4.3. Notaciones .................... 181
5. RESUMEN TÉCNICO .................... 182
5.1. Composición vertical del protocolo .................... 182
5.2. Estructura del perfil .................... 182
5.3. Relación con versiones anteriores de la especificación .................... 183
6. REQUISITOS DE PERFIL .................... 183
6.1. Requisitos de conformidad .................... 183
6.2. Requisitos de las capas superiores .................... 183
6.3. Requisitos de las capas inferiores .................... 183
6.3.1. Requisitos de la capa de transporte .................... 183
6.3.2. Requisitos de la capa de red .................... 183
6.3.3. Requisitos de la capa de enlace de datos .................... 184
6.3.4. Requisitos de la capa física .................... 184
7. MÉTODOS DE PRUEBA .................... 184
ANEXO A (NORMATIVO) PROTOCOLO DE TRANSFERENCIA DE MENSAJES .................... 185
A.1. Introducción .................... 185
A.2. Servicios desarrollados .................... 185
A.3. Servicios necesarios .................... 185
A.4. Especificación de protocolo .................... 185
A.4.1. Introducción .................... 185
A.4.2. Tipos de datos .................... 185
A.4.3. Establecimiento de una asociación .................... 186
A.4.4. Transferencia de datos .................... 186
A.4.5. Terminación normal de la asociación .................... 187
A.4.6. Restablecimiento de una asociación .................... 187
A.4.7. Integridad de la asociación .................... 187
A.4.8. Terminación anormal de la asociación .................... 188
A.4.9. Recuperación tras un fallo .................... 188
A.4.10. Formatos de los mensajes .................... 188
A.5. Tablas de transición de estados de protocolo .................... 189
A.5.1. Introducción .................... 189
A.5.2. Definiciones de estado .................... 189
A.5.3. Eventos posibles .................... 190
A.5.4. Temporizadores .................... 190
A.5.5. Tabla de transición de estados .................... 191
A.5.6. Diagrama de transición de estados .................... 192
ANEXO B (NORMATIVO) PROTOCOLO DE CABECERA DE MENSAJES .................... 194
B.1. Introducción .................... 194
B.2. Servicio desarrollados .................... 194
B.3. Servicios necesarios .................... 194
B.4. Especificación de protocolo .................... 194
B.4.1. Establecimiento de conexión .................... 194
B.4.2. Medidas para evitar conexiones de red redundantes .................... 194
B.4.3. Finalización de conexión .................... 195
B.4.4. Transferencia de datos .................... 195
ANEXO C (NORMATIVO) PROTOCOLO DE RED .................... 197
C.1. Introducción .................... 197
C.2. Servicios proporcionados .................... 197
C.3. Servicios necesarios .................... 197
C.4. Direcciones NSAP .................... 197
C.4.1. Introducción .................... 197
C.4.2. Estructura de la dirección NSAP .................... 198
C.4.3. Asignación de identificadores y selectores de un organismo ATC .................... 198
C.5. Especificación de protocolo .................... 198
C.5.1. Resumen .................... 198
C.5.2. Codificación de las direcciones .................... 199
C.5.3. Codificación del campo de datos de usuario .................... 199
C.5.4. Tratamiento de las direcciones en los paquetes INCOMING CALL .................... 199
C.5.5. Transferencia de datos .................... 200
ANEXO D (NORMATIVO) FORMULARIOS PICS DE ESPECIFICACIONES DE PERFIL .................... 201
D.1. Introducción .................... 201
D.2. Instrucciones para cumplimentar los formularios PICS .................... 201
D.2.1. Estructura general de los formularios PICS .................... 201
D.2.2. Información adicional .................... 202
D.2.3. Información excepcional .................... 202
D.2.4. Elementos condicionales .................... 202
D.3. Formulario PICS para el Protocolo de transferencia de mensajes .................... 203
D.3.1. Abreviaturas y símbolos especiales .................... 203
D.3.2. Identificación .................... 203
D.3.3. Desarrollo del protocolo .................... 204
D.4. Formulario PICS para el Protocolo de cabecera de mensaje .................... 204
D.4.1. Abreviaturas y símbolos especiales .................... 204
D.4.2. Identificación .................... 205
D.4.3. Desarrollo del protocolo .................... 206
D.5. Formulario PICS para el Protocolo de red .................... 206
D.5.1. Abreviaturas y símbolos especiales .................... 206
D.5.2. Identificación .................... 207
D.5.3. Desarrollo de protocolo .................... 207
ANEXO E (NORMATIVO) LISTA DE REQUISITOS DE PERFIL .................... 208
E.1. Introducción .................... 208
E.2. El papel de las PRL y de los formularios PICS .................... 208
E.3. Notación .................... 209
E.4. Instrucciones para cumplimentar los formularios PICS .................... 209
E.5. Referencias .................... 210
E.6. Declaración de conformidad .................... 211
E.6.1. Presentación general de conformidad .................... 211
E.6.2. Requisitos de conformidad dinámica .................... 212
E.7. Requisitos de la capa superior .................... 212
E.8. Requisitos de la capa inferior .................... 212
E.8.1. Requisitos de la capa de transporte .................... 212
E.8.2. Requisitos de la capa de red .................... 213
E.8.3. Requisitos de la capa de enlace de datos .................... 226
E.8.4. Requisitos de la capa física .................... 227
ANEXO F (INFORMATIVO) MÉTODOS DE PRUEBA DE CONFORMIDAD .................... 228
F.1. Introducción .................... 228
F.2. Propósito y alcance .................... 228
F.3. Bibliografía .................... 228
F.4. Métodos y prácticas de desarrollo .................... 228
F.5. Pruebas .................... 228
F.5.1. Introducción .................... 228
F.5.2. Prueba de las capas inferiores (Capas 1- 3) .................... 229
F.5.3. Prueba de la capa de aplicación .................... 229
F.5.4. Certificación .................... 229
F.5.5. Notificación .................... 229
ANEXO G (INFORMATIVO) ASIGNACIÓN DE IDENTIFICADORES DE UNIDAD ATC .................... 230
ANEXO H (INFORMATIVO) DIRECTIVAS SOBRE FIABILIDAD, DISPONIBILIDAD Y SEGURIDAD .................... 232
H.1. Introducción .................... 232
H.2. Propósito y alcance .................... 232
H.3. Bibliografía .................... 232
H.4. Desarrollos en línea dedicada .................... 232
H.4.1. Fiabilidad .................... 232
H.4.2. Disponibilidad .................... 232
H.4.3. Seguridad .................... 232
H.4.4. Ejemplo de configuración .................... 233
H.5. Desarrollo de red .................... 233
H.5.1. Fiabilidad .................... 233
H.5.2. Disponibilidad .................... 233
H.5.3. Seguridad .................... 233
H.6. Directivas generales para los desarrollos de línea dedicada y de red .................... 233
H.6.1. Fiabilidad .................... 233
H.6.2. Disponibilidad .................... 234
H.6.3. Gestión de sistemas .................... 234
H.6.4. Ejemplo de configuración .................... 234
DERECHOS DE AUTOR
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 disposició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.
PRÓLOGO
1. Órgano responsable
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. Programa de Trabajo EATCHIP
La presente Norma está relacionada con la Tarea especializada n° 12, Tarea ejecutiva 01, Dominio de comunicaciones, del Documento de Programa de Trabajo EATCHIP (EWPD)
3. Aprobación de la Norma
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 Comisió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. Rectificaciones Técnicas y Enmiendas
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. Convenciones editoriales
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ón con otras Normas
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. Estado de los Anexos a la presente Norma
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 - Informativo
- Anexo G - Informativo
- Anexo H - Informativo
8. Lenguaje utilizado
Se ha utilizado el idioma inglés en la preparación del presente documento.
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 Verteilungssystem (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ó establecer un número mayor de enlaces, se vio la necesidad de cambiar a una arquitectura basada en red y adoptar la normativa de telecomunicaciones internacional, estableciendo 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 ser utilizadas por las instalaciones OLDI existentes con modificaciones mínimas, usando bien enlaces punto a punto o bien redes de conmutación de paquetes conformes a la recomendació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 documento pueden o bien solicitar una enmienda al presente 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 comunicaciones 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 Normalizació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 N° 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 interconectadas de datos de conmutación por paquetes, 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.
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
IMAGEN OMITIDA
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 generales, 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 disposiciones de la presente Norma de Eurocontrol.
Las ediciones indicadas son las que estaban en vigor en el momento de la publicación de la presente Norma de Eurocontrol.
Cualquier revisión de los documentos de la Organización Internacional 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 formalmente 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 Eurocontrol.
3.2. Referencias
1. Recomendación X.25 (1993) (Rev. 1) de ITU-T, Interfaz entre equipo terminal de datos (DTE) y equipo de terminació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 internacionales - Parte 1: Marco (2ª edición).
3. ISO/IEC TR 10000-2:1994, Tecnología de la Información - Marco y taxonomía de los perfiles normalizados internacionales - Parte 2: Principios y taxonomía para perfiles OSI (3ª edición).
4. Recomendación X.21 (1992) (Rev. 1) de ITU-T, Interfaz entre equipo terminal de datos (DTE) y equipo de terminació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 - Telecomunicaciones 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 (2ª edición).
7. ISO/IEC 8208:1993, Tecnología de la información - Comunicación de datos - Protocolo X.25 de capa de paquete para equipo terminal de datos (3ª edició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 dependiendo 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 (2ª edición).
10. ISO/IEC 8348:1993, Tecnología de la información - Interconexión de sistemas abiertos - Definición del servicio de red (1ª edición).
11. ISO/IEC 8072:1994, Tecnología de la información - Interconexión de sistemas abiertos - Definición del servicio de transporte (2ª edición).
12. ISO/IEC 8878:1992, Tecnología de la información - Telecomunicaciones e intercambio de información entre sistemas - La utilización de X.25 para proporcionar servicio de red de modo de conexión OSI (2ª edición).
13. Norma Eurocontrol para el intercambio de datos en línea (OLDI), N° 001-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 metodología de ensayos de conformidad - Parte 1: Conceptos generales (2ª edició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 conmutados por paquete mediante una red 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.
4. DEFINICIONES, SÍMBOLOS Y ABREVIATURAS
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 transporte en modo conexión [Referencia 3].
4.1.5. Perfil A: El Perfil de aplicación necesita de un servicio de transporte 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ímbolos y abreviaturas
En la presente Norma Eurocontrol, se usanlos siguientes símbolos y abreviaturas:
ACC Centro de control de área
AFI Identificador de autoridad y formato
ASCII Código estándar americano para el intercambio de información
ATC Control de tráfico aéreo
ATCC 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 flujo
CUG Grupo de usuario cerrado
DCE Equipo terminal de circuito de datos
DCTS Sistema terminal de comunicaciones de datos
DSP Parte específica de dominio
DTE Equipo terminal de datos
DÜV Datenübertragungs- und Verteilungssystem
FDE Intercambio de datos de vuelo
FEP Procesador frontal
FPDE Intercambio de datos relativos al plan de vuelo
FPPS Sistema de procesamiento del plan de vuelo
ICD Documento de control de interfaz
IDI Identificador inicial de dominio
IDP Parte inicial de dominio
IEC Comisión electrotécnica internacional
INTERCAUTRA Protocolo Inter-CAUTRA
ISDN Red digital de servicios integrados
ISO Organización Internacional para la Normalización
ITU-T Unión internacional de telecomunicaciones - Sector de normalización de las telecomunicaciones
LAPB Procedimiento de acceso al enlace equilibrado (de modo simétrico)
LSB Bit menos significativo
M,m Obligatorio
MSB Bit más significativo
MT Transferencia de mensaje
NA No aplicable
NS Servicio de red
NSAP Punto de acceso a servicio de red
NSDU Unidad de datos de servicio de red
O,O.<n> Opcional, donde <n> es un número de referencia
O,o.<n> Opcional, donde <n> es un número de referencia
OACI Organización internacional de aviación civil
OLDI Intercambio de datos en línea
OSI Interconexión de sistemas abiertos
PICS 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 Adaptador de terminal
TSDU Unidad de datos de servicio de transporte
TPDU Unidad de datos de protocolo de transporte
TR 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 binarios 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 por 4 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á ir en letras minúsculas (por ejemplo: m, o, o.< n > , x).
NOTA Las funciones de las normas básicas que son condicionales, opcionales o dependientes del valor, son más precisas (E.3.1).
5. RESUMEN TÉCNICO
5.1. Composición vertical del protocolo
NOTA En la Figura 2 se muestra la disposición vertical (pila) del protocolo para el perfil de la presente Norma Eurocontrol. 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 vertical del protocolo es una especificación para sistemas pre-OSI y no admite muchas de las funciones que se permiten en los protocolos OSI de las capas OSI correspondientes.
Figura 2
Disposición vertical de Protocolo
IMAGEN OMITIDA
5.2. Estructura del perfil
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 [Referencia 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 Telecomunicaciones (ITU-T). Los protocolos de capas superiores se definen en los Anexos (A, B y C) de la presente Norma Eurocontrol.
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 detallados se representan en forma de tabla de PRL (Anexo E) y formularios PICS (los formularios para los protocolos definidos en los Anexos figuran en el Anexo D). La utilización de estas PRL y formularios PICS para el desarrollo y/o adquisición se explica en el Anexo E.
5.3. Relación con versiones anteriores de la especificación
NOTAS
1. El presente perfil se basa en el documento ST-ICD desarrollado por el antiguo Subgrupo técnico OLDI. Los protocolos y formatos de paquete definidos en la presente Norma Eurocontrol son un subconjunto compatible de los del documento ST-ICD con la excepción de que la presente Norma Eurocontrol 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 Identificador 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 especificació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 necesario 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. REQUISITOS DE PERFIL
6.1. Requisitos de conformidad
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. Requisitos de las capas superiores
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. Requisitos de las capas inferiores
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 4097 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 4096 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, ser capaz de iniciar una conexión de acuerdo con la especificación del Anexo C, por ejemplo: el protocolo es totalmente simétrico.
NOTA Puede que alguna de las implantaciones existentes basadas en el ST-ICD no sean capaces de iniciar conexiones 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 restricciones 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 [Referencia 8].
7. MÉTODOS DE PRUEBA
NOTAS
1. En el Anexo F aparece una introducción a las pruebas destinadas 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.
ANEXO A (Normativo)
PROTOCOLO DE TRANSFERENCIA DE MENSAJES
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. Servicios desarrollados
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 caracteres 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. Servicios necesarios
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 protocolo definido en el Anexo de la presente Norma Eurocontrol.
A.4. Especificación de protocolo
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 aplicació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 N° 001-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 aplicació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 de datos 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 funcionamiento 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.
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 temporizador 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 establece 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.
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 transporte;
- en cualquier otro estado no se deberá ejecutar ninguna acción.
NOTA El mensaje SHUTDOWN no es un aviso previo - la asociació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 especificado 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á garantizada por la función HEARTBEAT en reposo.
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 temporizador Ts en estado DATA_READY, deberá transmitirse un mensaje HEARTBEAT (mensaje de sistema) (y el temporizador deberá volver a 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_PENDING.
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 ser debido a un fallo de hardware o de software; en algunos casos, la conexió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 consecuencia directa del fallo de la conexión de red.
A.4.8.2. Un fallo en una aplicación o sistema puede ser detectado mediante la finalización de una pausa en la recepción de un mensaje HEARTBEAT esperado (véase A.4.7) de esta aplicación.
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), incluyendo 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 componene 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 del mensaje
Octeto 1 ....................... octeto 2 ...octeto n
A.4.10.2. Longitud del cuerpo del mensaje
Deberán admitirse cuerpos de mensaje de longitud igual o inferior a 4096 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, codificados 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:
- valor 1 (codificado como '41'H) Mensajes operativos;
- valor 2 (codificado como '42'H) Mensajes de operador;
- valor 5 (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 Documentos y Normas Eurocontrol que definen las aplicaciones de mensajería, tales como el Intercambio de datos en línea [Referencia 13].
3. Los mensajes de operador se componen de texto ASCII imprimible. 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. Tablas de transición de estados de protocolo
A.5.1. Introducción
Las tablas de estado que aparecen a continuación constituyen las especificaciones definitivas del protocolo. En el caso de discrepancia 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_PENDING ... Conexió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
TABLA OMITIDA
A.5.4. Temporizadores
Tabla 3
Temporizadores
Temporizador .... Información de temporizador
Tr ....................... Tiempo a la espera 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
TABLA OMITIDA
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 prioridad.
Figura A.1
Protocolo de transferencia de mensajes: Diagrama de transición de estados
IMAGEN OMITIDA
ANEXO B (Normativo)
PROTOCOLO DE CABECERA DE MENSAJES
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. Servicio desarrollados
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. Servicios necesarios
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ón de protocolo
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 correspondencia directa entre los dos grupos de primitivas (solicitud, indicación). Alternativamente, se puede utilizar una conexión de red existente (por ejemplo, una red establecida por los mecanismos de gestión del sistema).
Recomendaciones
1. 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 primitiva 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 correspondiente o una primitiva de desconexión N) y se señala una indicación de conexión N, el intento de establecer una conexión de red deberá ser rechazado o finalizado mediante el envío de una primitiva 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 conexió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 considerada mayor que cualquiera de sus subcadenas iniciales, por ejemplo, '8800'H > '88'H).
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 inferior.
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 establecimiento 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 conexió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 primitiva 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).
TABLA OMITIDA
NOTAS
1. Se define así esta cabecera para que sea idéntica a la que se utiliza en el procedimiento INTERCAUTRA definido para el intercambio 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/Karlsruhe, 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 bilaterales.
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 4105 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.
ANEXO C (Normativo)
PROTOCOLO DE RED
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 transferencia 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. Servicios prestados
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 siguientes excepciones.
- 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. Servicios necesarios
El protocolo supone la utilización de un Servicio de enlace de datos OSI, como el definido en la norma ISO/IEC 7776 (LAPB) [Referencia 6].
C.4. Direcciones NSAP
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 continuación.
IMAGEN OMITIDA
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: Identificador de 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.
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 par es un selector de 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 resultante.
AFI ............................................... DSP
48 ................... Identificador de unidad ATC .... Selector de 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 competente 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ón de protocolo
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 permitidos 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 establecimiento 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 INCOMING CALL deberá ser codificado como se muestra a continuación. Se deberán transmitir los 16 octetos.
Tabla 1
Codificación del campo de datos de usuario
TABLA OMITIDA
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 direcciones 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 anteriormente 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á terminarse la llamada.
NOTA La dirección NSAP receptora también puede opcionalmente ser validada por comparación con una lista (normalmente 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 transmitidas 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.
ANEXO D (Normativo)
FORMULARIOS PICS DE ESPECIFICACIONES DE PERFIL
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á cumplimentar 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 tener múltiples usos, entre 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 por omisió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 interconexió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 cumplimiento de la conformidad de la implantación.
D.2. Instrucciones para cumplimentar los formularios PICS
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 cumplimentado 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 cuestionario 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.
NOTAS
1. 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 condicional) 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 informació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 Información complementaria o excepcional, deberá tomarse como 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 configuraciones. 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 interpretar 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 informació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 cuestionario 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 requisito 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 una referencia 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 > : < s > " en la columna Estado, donde "< item > " designa una referencia que aparece en la primera columna de la tabla para algún otro elemento y "< s > " es un símbolo de estado, M, O, O.< n > o X.
NOTA Un formulario PICS puede contener varios elementos condicionales. 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 "< s > ": la columna Soporte deberá cumplimentarse 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.
D.3. Formulario PICS para el Protocolo de transferencia de mensajes
D.3.1. Abreviaturas y símbolos especiales
D.3.1.1. Símbolos de estado
M: Obligatorio
O: 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, Mtor ... tipos de mensaje
- MAE, MAR, MCI, MDT, MAV ... procedimeintos
- MEsu, MEsd, MEhb, MEty ... códigos
- MNmsg ... tamaños de mensaje
- Ts, Tr ... temporizadores
D.3.2. Identificación
Tabla 1
Identificación de la implantación de transferencia de mensajes
Proveedor .....................
Punto de contacto para consultas sobre el PICS .....................
Nombre/versión de la implantación .....................
Nombre/versión de la máquina .....................
Nombre/versión del sistema operativo .....................
Otro hardware y sistemas operativos solicitados .....................
Nombre del sistema (si es aplicable) .....................
D.3.3. Implantación del protocolo
Tabla 2
Implantación del protocolo de transferencia de mensajes
TABLA OMITIDA
D.4. Formulario PICS para el Protocolo de cabecera de mensaje
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)
D.4.1.2. Abreviaturas
NA no aplicable
D.4.1.3. Referencias de elemento
Los elementos en el formulario PICS se identifican mediante referencias 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, IHCC ... establecimiento de la conexión
- IHR1, IHR2 ... terminaicón de la conexión
- IHT1, IHTx ... transferencia de datos
- Tcr ... temporizador
D.4.2. Identificación
Tabla 3
Identificación de la implantación de cabecera de mensaje
Proveedor .....................
Punto de contacto para consultas sobre el PICS .....................
Nombre/versión de la implantación .....................
Nombre/versión de la máquina .....................
Nombre/versión del sistema operativo .....................
Otro hardware y sistemas operativos solicitados .....................
Nombre del sistema (si es aplicable) .....................
D.4.3. Implantación del protocolo
Tabla 4
Implantación del protocolo de cabecera de mensaje
TABLA OMITIDA
D.5. Formulario PICS para el Protocolo de red
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 referencias 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 de formulario PICS.
- SNDCP1 ... campo de identificación de protocolo
- NCRdae, NCRgae, NCCx, NDRx ... parámetros en mensajes de protocolo
- NCD1, NCD2, NCN1, NCN2 ... validación de direcciones
- NDT ... transferencia de datos
D.5.2. Identificación
Tabla 5
Identificación de implantación de red
Proveedor .....................
Punto de contacto para consultas sobre el PICS .....................
Nombre/versión de la implantación .....................
Nombre/versión de la máquina .....................
Nombre/versión del sistema operativo .....................
Otro hardware y sistemas operativos solicitados .....................
Nombre del sistema (si es aplicable) .....................
D.5.3. Implantación de protocolo
Tabla 6
Implantación de protocolo de red
TABLA OMITIDA
ANEXO E (Normativo)
LISTA DE REQUISITOS DE PERFIL
E.1. Introducción
E.1.1. El presente Anexo proporciona la PRL para el perfil FDE ICD definido 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 referencia.
E.1.2. Una implantación conforme deberá satisfacer los requisitos de conformidad obligatorios de las normas básicas a las que se ha hecho referencia en este perfil.
E.2. El papel de las PRL y de los formularios PICS
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 proporcionar una lista de control de las funciones que deben o pueden ser implantadas. 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 informació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 especificació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á utilizado 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 material 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 cumplimentado. 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 administraciones contratantes.
-- Integración de productos disponibles en el mercado en una implantación de perfil en cualquiera de los casos previos: el proveedor de un producto debería de proporcionar los formularios 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 identificar los cambios que puedan ser necesarios 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
NOTAS
1. 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 "implantació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 implantaciones.
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 por medio de la presentación).
< predicado > : introduce un único elemento condicional al < predicado > .
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. Instrucciones para cumplimentar los formularios PICS
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 referencia, 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 información excepcional introduciendo una referencia X< i > , donde < i > es 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 aplicables 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].
E.6. Declaración de conformidad
E.6.1. Presentación general de conformidad
Tabla 1
Presentación general de conformidad
TABLA OMITIDA
E.6.2. Requisitos de conformidad dinámica
Tabla 2
Requisitos de coformidad dinámica
TABLA OMITIDA
E.7. Requisitos de la capa superior
Tabla 3
Protocolo de Transferencia de mensajes
TABLA OMITIDA
E.8. Requisitos de la capa inferior
E.8.1. Requisitos de la capa de transporte
Tabla 4
Protocolo de Cabecera de mensaje
TABLA OMITIDA
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.
E.8.2.1. Características generales de DTE
Tabla 5
Características generales de DTE
TABLA OMITIDA
E.8.2.2. Procedimientos, tipos y formatos de paquete
Tabla 6
Funciones de la capa de paquete independientes de los canales lógicos
TABLA OMITIDA
Tabla 7
Establecimiento de comunicación
TABLA OMITIDA
Tabla 8
Terminación de comunicación
TABLA OMITIDA
Tabla 9
Reinicialización de canales lógicos
TABLA OMITIDA
Tabla 10
Procedimientos de error
TABLA OMITIDA
Tabla 11
Transferencia de interrupciones
TABLA OMITIDA
Tabla 12
Envío de datos
TABLA OMITIDA
Tabla 13
Recepción de datos
TABLA OMITIDA
Tabla 14
Confirmación de entrega
TABLA OMITIDA
E.8.2.3. Características y opciones diversas
Tabla 15
Valores de códigos de causa y diagnóstico
TABLA OMITIDA
E.8.2.4. Servicios
Tabla 16
Servicios enviados en los paquetes CALL REQUEST
TABLA OMITIDA
Tabla 17
Servicios enviados en paquetes CALL ACCEPT
TABLA OMITIDA
Tabla 18
Servicios enviados en paquetes CLEAR REQUEST
TABLA OMITIDA
Tabla 19
Servicios recibidos en paquetes INCOMING CALL
TABLA OMITIDA
Tabla 20
Servicios recibidos en paquetes CALL CONNECTED
TABLA OMITIDA
Tabla 21
Servicios recibidos en paquetes CLEAR INDICATION
TABLA OMITIDA
Tabla 22
Servicios recibidos en paquetes CLEAR CONFIRMATION
TABLA OMITIDA
E.8.2.5. Valores y rangos de los parámetros
Tabla 23
Valores y rangos de los parámetros
TABLA OMITIDA
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
TABLA OMITIDA
E.8.4. Requisitos de la capa física
Véase ISO/IEC TR 10609-9 cláusula A.4 [Referencia 8].
ANEXO F (Informativo)
MÉTODOS DE PRUEBA DE CONFORMIDAD
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 miembros 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. Objeto y alcance
F.2.1. El presente Anexo define los requisitos para la prueba de conformidad de las implantaciones de la presente Norma Eurocontrol de la que este Anexo forma parte.
F.2.2. Identifica los mecanismos por los 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 implantaciones de la presente Norma Eurocontrol:
Eurocontrol (Maastricht Upper Area Control (UAC) Systems Division) 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étodos y prácticas de implantaciones
F.4.1. Las implantaciones del presente ICD pueden ser llevadas a cabo utilizando 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 capacidad 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 resultados y la minimización de las pruebas de conformidad necesarias. El 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 inferiores 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 (Maastricht 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.
ANEXO G (Informativo)
ASIGNACIÓN DE IDENTIFICADORES DE UNIDAD ATC
La siguiente tabla muestra los identificadores de unidad ATC asignados a fecha 22 de abril de 1997. Eurocontrol puede proporcionar información de la asignació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
TABLA OMITIDA
ANEXO H (Informativo)
DIRECTIVAS SOBRE FIABILIDAD, DISPONIBILIDAD Y SEGURIDAD
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. Objeto y alcance
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 dedicada. 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 afectar al funcionamiento normal.
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. Implantaciones en línea dedicada
H.4.1. Fiabilidad
Para aumentar la fiabilidad del servicio, los cables de las líneas dedicadas, PSTN y Red digital de servicios integrados (RDSI) deben seguir diferentes caminos físicos y estar conectados a distintos conmutadores del operador de telecomunicaciones (lo cual se deberá especificar al operador de telecomunicaciones).
H.4.2. Disponibilidad
H.4.2.1. Debido al mayor tiempo de establecimiento de PSTN, que es incompatible 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 conexió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 Recomendación X.32 [Referencia 17] de ITU-T e incluir información de identificación y autenticación de la llamada.
H.4.4. Ejemplo de configuración
Figura H.1
Ejemplo de configuración de línea dedicada
IMAGEN OMITIDA
H.5. Implantación de red
H.5.1. Fiabilidad
Para aumentar la fiabilidad del servicio, los servidores de una determinada 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 restablecimiento 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. Directivas generales para las implantaciones de línea dedicada y de red
H.6.1. Fiabilidad
H.6.1.1. Debido al tiempo necesario para una conmutación total entre servidores, 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.
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 conmutadores 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 red
IMAGEN OMITIDA
Agencia Estatal Boletín Oficial del Estado
Avda. de Manoteras, 54 - 28050 Madrid
