Reglamento (CE) no 2082/2000 de la Comisión

de 6 de septiembre de 2000

por el que se adoptan normas de Eurocontrol y se modifica la Directiva 97/15/CE por la que se adoptan algunas normas de Eurocontrol y se modifica la Directiva 93/65/CEE del Consejo

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éro(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

>SITIO PARA UN CUADRO>

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

>SITIO PARA UN CUADRO>

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

>SITIO PARA UN CUADRO>

Tabla 5-3

Procedimiento de Diálogo - Mensajes de fase de coordinación

(Complementaria a la Tabla 5-2)

>SITIO PARA UN CUADRO>

Tabla 5-4

Procedimiento de diálogo - Mensajes de fase de transferencia

>SITIO PARA UN CUADRO>

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