ENAIRE

Expediente Desarrollo e
Implantación de A-CDM fase II:

Mejoras funcionales y nueva
interfaz Torre-Plataforma
Código: STGEX2922.100
Elaborado: 14/04/16
Página: 1/202
El contenido de este documento es propiedad de ENAIRE, no pudiendo ser reproducido, ni comunicado total o parcialmente, a otras
personas distintas de las autorizadas por ENAIRE. Cualquier versión impresa o en soporte informático, total o parcial de este documento se
considera como copia no controlada y siempre debe ser contrastada con su versión vigente en el Gestor Documental de ENAIRE.
Elaborado: 14/04/16
Página: 2/201
Desarrollo e Implantación de A-CDM fase II: Mejoras funcionales y nueva interfaz Torre-
Plataforma
Aprobaciones del documento
Elaborado por: Revisado por: Aprobado por:
Victoria Díez Fernández Francisco Martínez Rico José Luis Rodríguez Castro
Jefa Departamento Desarrollo de Jefe Departamento Desarrollo e

Jefe División Automatización
Sistemas Auxiliares SACTA Ingeniería de Sistemas ATM
Control de Cambios
En la siguiente tabla figuran al menos las tres últimas modificaciones efectuadas en el presente documento.
Edición Fecha Páginas afectadas Cambios
1 14/04/16 Todas
Hoja de Control de Documentación Impresa
Fecha de
Responsable de la Fecha de
Edición Entrada en Páginas Impresas Firma
Impresión Impresión
Vigor
Esta hoja de control garantiza que la copia del documento en papel se corresponde con el documento contenido en el gestor documental de
ENAIRE vigente en el momento de la impresión. En caso de que esta hoja de control no esté cumplimentada se considerará que la copia en
papel es meramente informativa pudiendo no corresponder con la versión en vigor del documento.
Formato empleado: A14-09-PL-001-2.1
Cualquier versión impresa o en soporte informático, total o parcial de este documento, se considera como copia no controlada y siempre
debe ser contrastada con su versión vigente en el Gestor Documental de ENAIRE.
Elaborado: 14/04/16
Página: 3/201
Plataforma
ÍNDICE DE DOCUMENTACIÓN
1. MEMORIA
2. PLIEGO DE PRESCRIPCIONES TÉCNICAS
ANEXOS:
 ANEXO A: CLÁUSULAS DE FORMACIÓN
 ANEXO B: NORMAS PARA LA EDICIÓN Y CODIFICACIÓN DE LA DOCUMENTACIÓN

CONTRACTUAL
 ANEXO C: MATRIZ TRAZABILIDAD CON GARANTÍA SEGURIDAD DE LOS SERVICIOS Y

SUMINISTROS EXTERIORES
 ANEXO D: POLÍTICA DE GESTIÓN INTEGRADA
3. PRESUPUESTO
Elaborado: 14/04/16
Página: 4/201
Plataforma
ÍNDICE
1. Memoria ......................................................................................................................................10
1.1. Antecedentes .......................................................................................................................10
1.2. Necesidad del servicio ........................................................................................................10
1.3. Objeto del servicio ...............................................................................................................10
1.4. Importe límite ......................................................................................................................12
1.5. Plazo de ejecución ...............................................................................................................12
2. Pliego de prescripciones técnicas ............................................................................................13

2.1. Lista de acrónimos, siglas y abreviaturas ........................................................................13
2.2. Documentación de referencia ............................................................................................15
2.2.1. Normativa aplicable .....................................................................................................17
2.3. Introducción .........................................................................................................................18
2.3.1. Objeto.............................................................................................................................18
2.3.2. Necesidad del servicio .................................................................................................18
2.3.3. Alcance...........................................................................................................................19
2.3.4. Estructura del documento ...........................................................................................20
2.4. Descripción general y estrategia de evolución ................................................................23
2.4.1. Situación actual ............................................................................................................23
2.4.2. Estrategia de evolución ...............................................................................................23
2.5. Requisitos técnicos .............................................................................................................24
2.5.1. General...........................................................................................................................24
Elaborado: 14/04/16
Página: 5/201
Plataforma
2.5.2. Composición del proyecto ............................................................................................25
2.5.2.1. Equipamiento SW ............................................................................................................................ 25
2.5.2.2. Servicios ........................................................................................................................................... 26
2.5.3. Requisitos funcionales y operativos a nivel usuario-sistema para CDM .............28
2.5.3.1. SA#4427. CDM. Mejora en el tratamiento de condiciones adversas .......................................... 28
2.5.3.2. SA#4428. CDM. Cambios en el tratamiento de PVs con CTOT ..................................................... 41
2.5.3.3. SA#4430. Función de extensión de tiempos de taxi ..................................................................... 45
2.5.3.4. SA#4563. Cambio programado de capacidades pista .................................................................. 53
2.5.3.5. SA#4564. CDM. Función de paradas de puesta en marcha ......................................................... 56
2.5.3.6. SA#4982. Modificación al cambio programado de aerodromos para CDM ................................ 64
2.5.3.7. SA#6597. CDM. No caducidad de PV con STS ................................................................................ 67
2.5.3.8. SA#7135. CDM. No recalculo de TSAT si ASAT antes de TSAT...................................................... 67
2.5.3.9. SA#8165. Funcionalidad en TWR con configuraciones de pistas ............................................... 68
2.5.3.10. SA#8181. No actualización de EOBT por mensaje SLC ................................................................. 77
2.5.3.11. SC#11773. Implementación de la interfaz SACTA-CDM ............................................................... 77
2.5.3.12. SC#14014. Tratamiento de las horas de despegue y fuera de calzos en SSD ..........................110
2.6. Aseguramiento del proyecto ........................................................................................... 121
2.6.1. Metodología de desarrollo SW ................................................................................. 122
2.6.1.1. General ...........................................................................................................................................122
2.6.1.2. Fases de desarrollo e hitos ..........................................................................................................123
2.6.1.3. Planificación ...................................................................................................................................123
2.6.1.4. Entrega en el CED ..........................................................................................................................124
2.6.1.5. Instalación y despliegue ...............................................................................................................125
2.6.1.6. Transición .......................................................................................................................................126
2.6.1.7. Formación ......................................................................................................................................126
2.6.1.8. Seguimiento ...................................................................................................................................127
Elaborado: 14/04/16
Página: 6/201
Plataforma
2.6.2. Elaborar el plan de gestión de proyecto .................................................................. 127
2.6.2.1. Control del proyecto ......................................................................................................................128
2.6.2.2. Métricas del proyecto ....................................................................................................................130
2.6.2.3. Gestión de riesgos .........................................................................................................................133
2.6.2.4. Control de subcontratistas y proveedores ..................................................................................133
2.6.3. Elaborar el Plan de Gestión de la Configuración .................................................... 133
2.6.3.1. Control de cambios ........................................................................................................................135
2.6.3.2. Resolución de problemas / incidencias ......................................................................................135
2.6.4. Elaborar el Plan de Gestión de la Documentación ................................................. 135
2.6.4.1. Revisión de documentos...............................................................................................................137
2.6.5. Elaborar el Plan de Gestión de la Calidad ............................................................... 137
2.6.5.1. Plan de gestión de la calidad ........................................................................................................137
2.6.5.2. Auditorías .......................................................................................................................................138
2.6.5.3. Proceso de mejora continua .........................................................................................................139
2.6.6. Elaborar el Plan de Verificación ............................................................................... 139
2.6.6.1. Revisiones ......................................................................................................................................140
2.6.6.2. Verificación de entregas parciales ...............................................................................................141
2.6.7. Elaborar el Plan de Pruebas de Integración SW ..................................................... 141
2.6.7.1. Consideraciones generales sobre las pruebas ...........................................................................141
2.6.7.2. Pruebas del SW..............................................................................................................................142
2.6.7.3. Documentación de pruebas ..........................................................................................................143
2.6.7.4. Requisitos previos para la realización de pruebas ....................................................................144
2.6.7.5. Pruebas de aceptación en emplazamiento .................................................................................144
2.6.8. Procedimientos ante desviaciones y concesiones................................................. 145
2.6.9. Actividades de verificación CE de sistemas (Conformity assessment) ............... 145
2.6.9.1. Preparación de la verificación CE de sistemas ...........................................................................146
Elaborado: 14/04/16
Página: 7/201
Plataforma
2.6.9.2. Ejecución de la verificación CE .....................................................................................................146
2.6.10. Gestión safety ............................................................................................................ 148
2.6.10.1. Elaborar plan de gestión de safety ..............................................................................................148
2.6.10.2. Informes de pruebas de integración ............................................................................................148
2.6.11. Gestión de SW assurance ......................................................................................... 149
2.6.11.1. Plan de garantía de la integridad del SW del suministrador (PSAA-s) ....................................149
2.6.11.2. Informe de asignación definitiva de SWAL .................................................................................149
2.6.11.3. Sumario de garantía de la integridad del SW del suministrador (SAS-S) ................................149
2.6.11.4. Demostración de la integridad de COTS SW ...............................................................................150
2.6.11.5. Informe de conformidad de cots para actualizaciones del COTS SW .......................................150
2.6.12. Prestación del servicio de formación al personal de Enaire ................................. 150
2.6.13. Servicios logísticos .................................................................................................... 151
2.6.13.1. Elaborar el manual técnico de mantenimiento (MTM) ...............................................................151
2.6.13.2. Manuales del sistema y manuales de usuario ...........................................................................152
2.6.13.3. Garantías ........................................................................................................................................152
2.6.14. Calendario de los entregables .................................................................................. 153
2.6.15. Criterios sujetos a las evidencias ............................................................................ 153
2.7. Lista de documentación a entregar por el adjudicatario (LDEC) ................................. 153
2.8. Requisitos de calendario para el proyecto .................................................................... 169
2.9. Seguros.............................................................................................................................. 169
2.10. Importe límite ................................................................................................................... 171
2.11. Lugar de prestación del servicio ..................................................................................... 171
2.12. Plazo de ejecución ............................................................................................................ 171
2.13. Plazo de garantía ............................................................................................................. 171
2.14. Forma de pago .................................................................................................................. 171
Elaborado: 14/04/16
Página: 8/201
Plataforma
2.15. Pago en divisas al adjudicatario ..................................................................................... 172
2.16. Prórrogas .......................................................................................................................... 172
2.17. Responsabilidades ........................................................................................................... 172
2.18. Incompatibilidades .......................................................................................................... 172
2.19. Locales............................................................................................................................... 173
2.20. Medios informáticos ........................................................................................................ 174
2.21. Dirección del servicio ....................................................................................................... 174
2.22. Posibles incidencias relativas a los medios humanos ................................................ 175
2.23. Cláusula de medios humanos ........................................................................................ 175
2.24. Cláusula de huelga ........................................................................................................... 178
2.25. Cláusula de prevención de riesgos laborales ................................................................ 178
2.26. Cláusula medioambiental ............................................................................................... 178
2.27. Propiedad intelectual e industrial de los trabajos realizados ..................................... 178
2.28. Negligencia ....................................................................................................................... 178
2.29. Subcontrataciones ........................................................................................................... 178
2.30. Inspecciones ..................................................................................................................... 179
2.31. Cláusula LOPD para contratos de prestación de servicios con acceso a datos de
carácter personal ....................................................................................................................... 179
Anexos ............................................................................................................................................ 180

Anexo A: Cláusulas de formación................................................................................................. 181
1. Objeto ....................................................................................................................................... 181
2. Fase de ejecución del expediente.......................................................................................... 181
2.1. Metodología de Impartición ............................................................................................ 181
2.2. Control de Asistencia ....................................................................................................... 181
2.3. Valoración de las Actividades Formativas .................................................................... 182
Elaborado: 14/04/16
Página: 9/201
Plataforma
2.4. Evaluación del Aprendizaje de las Actividades Formativas ........................................ 182
2.4.1. Proceso de evaluación del aprendizaje para acciones formativas complejas .... 182
2.5. Documentación Asociada a Acciones Formativas ........................................................ 183
2.5.1. Formato de la documentación asociada ................................................................. 184
2.6. Diplomas ........................................................................................................................... 184
3. Tabla de seguimiento de formación ..................................................................................... 185

Anexo B: Normas para la edición y codificación de la documentación contractual ............... 186
1. Garantía de conformidad de la documentación contractual .............................................. 186
2. Edición...................................................................................................................................... 187
2.1. Redacción................................................................................................................................. 187
2.2. Presentación ........................................................................................................................... 188
2.3. Normas de envío y recepción................................................................................................. 189
2.3.1. Documentos a Enviar ....................................................................................................... 189
2.3.2. Documentos a distribuir a emplazamientos. ................................................................ 190
2.3.3. Informes de Gestión de la Documentación. .................................................................. 190
3. Documentación a entregar .................................................................................................... 190
4. Codificación del documento ................................................................................................... 190
4.1. Edición / Revisión de documentos ....................................................................................... 192
4.2. Codificación del fichero .......................................................................................................... 193
5. Revisión de la documentación contractual .......................................................................... 193
Anexo C: Matriz trazabilidad con garantía seguridad de servicios y suministros exteriores 194
Anexo D: Política de Gestión Integrada ....................................................................................... 199
3. Presupuesto ............................................................................................................................ 200
Elaborado: 14/04/16
Página: 10/201
Plataforma
1. Memoria
1.1. Antecedentes
El proyecto A-CDM está dividido en varias fases, En un primera fase se contemplan los requisitos mínimos
exigidos para poder llevar a cabo la integración de los distintos sistemas involucrados (Aeropuerto, Compañías
Aéreas, Agentes handling, Sistema de Torre y NMOC).
Esta primera fase ha sido implementada en los sistemas de Torre SACTA Madrid-Barajas y Barcelona.
Como continuación del proyecto, queda pendiente abordar en una Fase II una serie de cambios en el sistema
con el objetivo de mejorar la gestión de los planes de vuelo que se realiza actualmente.
1.2. Necesidad del servicio

Los cambios descritos en este expediente son debidos a la evolución necesaria de la operativa completa A-CDM,
así como cambios requeridos por NMOC, Aeropuerto y ATC tras la puesta en servicio de la Fase I.
Un Aeropuerto con certificación A-CDM implica que todos los participantes en dicho entorno (Compañías,
agentes handling, NMOC y Torre) compartan su información, de modo que cualquier circunstancia particular en
uno, se traslade al resto, y al realimentarse los sistemas de dicha información, se mejore la eficiencia de la
operación global de todo el entorno aeroportuario.
En este expediente se establecen los cambios propuestos, cuya finalidad es la adaptación de la secuencia de
planes de vuelo de despegue cuando se dan en el aeropuerto situaciones como: necesidades de deshielo,
necesidad de paradas de puestas en marcha durante un periodo de tiempo, necesidad de extensión de tiempos
de taxi por alguna circunstancia imprevista en las rodaduras, cambios en el tratamiento de vuelos con
regulación, necesidad de un interfaz que permita monitorizar/supervisar el estado del enlace y reducir los
tiempos de comunicación.
Actualmente en determinadas ocasiones , al no poder dar respuesta automáticamente a través del sistema
SACTA, se utilizan procedimientos operativos manuales que pueden provocar un aumento en la carga de trabajo
operativa, además, al no dar cobertura a determinadas situación que ocurren en el Aeropuerto (reducciones de
capacidad
reduce la optimización de la capacidad y los indicadores de NMOC como consecuencia de los datos enviados
hace que no se cumplan los criterios de tolerancia y validez establecidos.
1.3. Objeto del servicio

Los cambios descritos en este expediente se indican a continuación:
- Nuevo interfaz de comunicación entre los sistemas SACTA y Aeropuerto (SCENA) basado en mensajes
bidireccionales (con el actual basado en ftp no es posible esta comunicación) que permita monitorizar y
supervisar el estado del enlace, reducir los tiempos de envío/recepción de datos y permitir el reinicio de
los sistemas ante paradas tanto programadas como, sobre todo, no programadas (actualmente una
caída de los sistemas conlleva perdida de datos de PVs afectando de forma importante a la operación y
a la funcionalidad CDM).
Elaborado: 14/04/16
Página: 11/201
Plataforma
- Adecuar la secuencia de planes de vuelo de despegue a la gestión de vuelos con regulación, de forma
que NMOC pueda detectar posibles incumplimientos de CTOT, ya que actualmente al no considerar la
TOBT para vuelos regulados, se están dando incompatibilidades entre dicha hora declarada por la
compañía y la regulación.
- Modificación del algoritmo de secuenciación para mejorar la gestión de vuelos que solicitan deshielo, lo
que requiere que el secuenciador se alimente de las características de deshielo concretas así como de
la gestión de secuencias de deshielo en las bases para evitar pérdidas de capacidad, esto implica el
procesado de nuevos campos (Base, tiempo medio de deshielo, solicitud de deshielo, tiempo de inicio de
deshielo) y nuevos resaltes en la posición de control.
- Modificación del cambio de parámetros de aeródromo programado, para que en lugar de tener en
cuenta la EOBT, el cambio sea en base a la TOBT.
- Nueva funcionalidad que permita realizar extensión de los tiempos de taxi por circunstancias
operativas que hace que varíen de manera general los tiempos medios de rodaje, de esta manera se
recalculan TSAT/TTOTs de vuelos que se van a ver afectados y así enviar a NMOC los datos más
aproximados a la realidad de lo que está sucediendo en tierra.
- Nueva funcionalidad para poder programar cambios programados de capacidad, de forma que cuando
se prevea que se va a producir cualquier circunstancia operativa que provoque una variación en las
capacidades de una pista en servicio es muy importante que las horas de TSAT se calculen con estos
parámetros con la antelación suficiente para q NMOC tenga la información más aproximada de la
secuencia durante ese periodo de reducción de capacidad, y tras dicho periodo.
- Nueva funcionalidad que contempla la posibilidad de parar las puestas en marcha, de modo que se
mejora la calidad de la información de huecos (TTOTs) que se envían a NMOC y mejora la estimación de
la secuencia al poder tener en cuenta la resecuenciacion de vuelos a partir de la hora que finaliza la
parada; es decir, no dar TSATs a los vuelos en un periodo en el cual realmente no se van a autorizar las
puestas en marcha.
- Modificación del algoritmo de secuencia que evite la caducidad de planes de vuelo con STS (Ambulancia,
Rescate, Humanitarios, Emergencia), ya que estos vuelos por la condición de su status deben
permanecer en la secuencia para que se les pueda anotar la puesta en marcha en el momento que la
soliciten.
- Modificación al recalculo de la secuencia de despegue para evitar recalculos cuando se anote la

autorización de puesta en marcha (ASAT) antes del valor proporcionado por el secuenciador (TSAT),
evitando así penalizar a vuelos con tiempos de TAXI menores y estabilizando la secuencia de
despegues.
- Nueva funcionalidad que permita adaptar capacidades y tiempos de taxi en función de las
configuraciones de pista, realizar y visualizar cambios inmediatos o programados en base a las
mismas, además de recalcular de manera automática la secuencia en función de la capacidad y
tiempos de taxi, o establecer el orden en el que los planes de vuelo irán cambiando de pista.
- No actualización de la hora estimada de retirada de calzas (EOBT) cuando se reciba un mensaje de

cancelación de CTOT (SLC) independientemente de la hora de recepción del mismo, de modo que no se
provoquen desalineaciones entre EOBT y TOBT, lo cual invalidaría la autorización de puesta en marcha.
Elaborado: 14/04/16
Página: 12/201
Plataforma
- Modificación de la hora de activación del vuelo para el piloto así como las indicaciones de las horas en
las que el piloto debe ponerse en contacto con la torre, teniendo en cuenta la TOBT y la ETOT MANUAL,
además de la EOBT y ETOT que son las utilizadas actualmente.
1.4. Importe límite

 El importe límite del presente expediente asciende UN MILLON NOVECIENTOS NOVENTA Y TRES MIL
DOSCIENTOS NOVENTA Y NUEVE EUROS ( ) IMPUESTOS NO INCLUIDOS.
1.5. Plazo de ejecución

El plazo de ejecución del servicio es de TREINTA MESES (30 MESES), a partir de la fecha que figure en el
contrato y en su defecto la de firma del Acta de Inicio del Servicio.
Madrid, a 14 de abril de 2016
El Jefe de la División de Automatización
Fdo.: José Luis Rodríguez Castro
Elaborado: 14/04/16
Página: 13/201
Plataforma
2. Pliego de prescripciones técnicas
2.1. Lista de acrónimos, siglas y abreviaturas

AFTN : Aeronautical Fixed Telecommunication Network
AOBT : Hora real de fuera de calzos.
ASAT : Hora Autorización de Puesta en Marcha
ASRT : Hora de Solicitud de Puesta en Marcha
ATC : Control de Tránsito Aéreo
ATM : Gestión de Tráfico Aéreo
ATN : Aeronautical Telecommunication Network
BDAC : Base de Datos de Adaptación Central
BDAP : Base de Datos de Adaptación
BIR : Botón Izquierdo del Ratón
CAP : Plan de Aseguramiento de COSTS
CDR : Revisión Crítica de Diseño
CDM : Collaborative Decision Making
CED : Centro de Experimentación y Desarrollo
CFMU : Unidad Central de Gestión de Afluencia
CNS: : Comunicaciones, Navegación y Vigilancia
COM : Área de Comunicaciones de la Región
COTS : Producto Comercial
CI : Configuration Item (Elemento de Configuración)
CMP : Plan de Gestión de la Configuración
CP : Propuesta de Cambio de Ingeniería
CSC : Computer SW Component (Partes en que se divide un CSCI)
CSCI : Computer SW Configuration Item (Elemento de Configuración SW).
CTOT : Calculated Take-Off Time
DAUT : División de Automatización
DDE : Digital Data Extractor.
DMAN : Gestor de despegues
DMP : Plan de Gestión de la Documentación
DPI : Planificador de mensajes de salida
DSH : Deshielo
DTOT-R : Hora de Despegue Asignada por el Secuenciador de Despegues
EDIT : Estimated Deice Time
EOBT : Estimated Off-Block Time
ESARR : Eurocontrol Safety Regulating Requirements
EXOT : Tiempo de Taxi de Salida
FMEA : Failure Modes and Effects Analysis
FT : Fault Tree (Árbol de Fallos)
FTP : File Transfer Protocol
FUM : Mensajes de Actualización de Vuelo
GBDA : Programa de Gestión de Base de Datos de Adaptación
GIV : Gestión de Plan de Vuelo
GSI : Subsistema Grabador y Servidor de Información
Cualquier versión impresa o en soporte informático, total o parcial de este documento, se considera como copia no controlada y siempre debe
ser contrastada con su versión vigente en el Gestor Documental de ENAIRE.
Elaborado: 14/04/16
Página: 14/201
Plataforma
GTA : Gestión de Tráfico Aéreo

GPVT : Gestor de Planes de Vuelo de Torre
HPMR : Start-up Clearance Time
HW : Hardware
HWCI : Hardware Configuration Item
ICMP : Internet Control Management Protocol
LAN : Local Area Network (Red de Área Local).
LDEC : Lista de Documentación Contractual
LOPD : Ley Orgánica de Protección de Datos
NMOC : Network Manager Operations Centre
MTBF : Tiempo medio entre fallos
MTM : Manual Técnico de Mantenimiento
N/A : No Aplicable
OR : Objeto de Responsabilidad
PC : Personal Computer
PCI : Propuesta de Cambio de Ingeniería
PICT : Posición de Integrada de Control de Torre
P/N : Part Number
PMP : Plan de Gestión del Proyecto
POS : Posición de Control
PSSA-S : Plan de Aspectos para la aprobación del SW del Suministrador
PV : Plan de Vuelo
PPT : Pliego de Prescripciones Técnicas
PRAD : Programa de Reducción y Análisis de Datos
PSI : Posición de Supervisión Integrada.
PV : Plan de Vuelo
QMP : Plan de Gestión de la Calidad
RBD : Reliability Block Diagram (Diagramas de Fiabilidad de Bloques)
REA : Ready Message (CFMU)
REDAN : Red de Datos de Navegación Aérea
REQ : Requisito
SACTA : Sistema Automatizado del Control del Tráfico Aéreo
SARAD : Descripción de la Arquitectura del Sistema y Asignación de Requisitos
SCENA : Sistema de Información de Aeropuertos.
SCV : Sistema de Comunicaciones Voz
SDL : Subsistema de Enlaces de Datos
SDP : Plan de Desarrollo del SW
SDR : Subsistema de Proceso y Presentación de Datos Radar
SIA : Subsistema de Información Auxiliar
SMDT : Servidor Multifuncional de Torre
SIDD : Descripción del Diseño de Interfaces del SW
SO : Sistema Operativo
SPV : Supervisión
SRD : Descripción de Requisitos SW
SRS : Especificación de Requisitos del Sistema
STS : Status del Plan de Vuelo
Elaborado: 14/04/16
Página: 15/201
Plataforma
SSA : System Safety Assessment

SW : Software
TB : Test Build
TCPV : Tratamiento Central de Planes de Vuelo
TDEP : Inverse of Take-off runway rate.
TDVM : Tratamiento de Datos de Vigilancia Multidependencia
TL : Test List
TLPV : Tratamiento Local de Planes de Vuelo
TOBT : Target Off Block Time
TPV : Tratamiento de Planes de Vuelo
TPVT : Tower FP Data Processing
TQP : Plan de Cualificación de Herramientas
TSAT : Target StartUp Approval Time
TTOT : Target Take Off Time
TWR : Torre
UAST : Unidad Adquisición de Datos Radar Asterix
UCR : Petición de Cambio de usuario
UDDE : Unidad de Adquisición de Datos Radar DDE.
VP : Plan de Verificación
WAN : Red de Área Extensa
2.2. Documentación de referencia

La siguiente lista de documentos corresponde a la Especificación de Requisitos y a la descripción de Diseño del
Sistema SACTA aplicables a la versión actualmente en operación SACTA 3.5.
Nombre fichero Título documento

SACTA3DS1I.069 SACTA architectural model
SACTA3DSI.526 System Architecture and Requirements Allocation Description (SARAD)
SACTA3ERI.525 System Requirements Specification (SRS) (CORE, GEODESYS, PALESTRA, SIMDIN)
SAMANERI.017 Software Requirements Description (SRD) for the Arrivals Manager (AMAN)
Software Requirements Description (SRD) for the Calculation of Optimum Landing Runway
SCAHTAERI.020 Tool (CALIPSO)
SCMHTAERI.019 Software Requirements Description (SRD) for the Medium Term Conflicts Tool (COMEHTA)
SCOORTERI.046 Software Requirements Description (SRD) for the Coordination and Transfer (COOR-TRF)
Software Requirements Description (SRD) for Correlation and Conforming Monitoring
SCRCMERI.081 (COOR+CMON)
Software Requirements Description (SRD) for the Adaptation Data Base Management
SDADBERI.029 (ADAPDB)
Software Requirements Description (SRD) for the Adaptation Data Generation and
SDAGVERI.030 Validation (ADAPGV)
SDDVEERI.033 Software Requirements Description (SRD) for the External Surveillance Data Exchande
(DDVE)
SDMANERI.019 Software Requirements Description (SRD) for the Departures Manager (DMAN)
SFASTERI.047 Software Requirements Description (SRD) for the Tower System Strips (FAST)
SFDTERI.017 Software Requirements Description (SRD) for the Flight Data Tools (FDPT)
Elaborado: 14/04/16
Página: 16/201
Plataforma

Software Requirements Description (SRD) for the Information Server for External Users
SGIPVERI.014 (GIPV)
SGIVERI.115 Software Requirements Description (SRD) for the Visual Image Generator (GIV)
SGPVAERI.045 Software Requirements Description (SRD) for the GPVA
SGPVTERI.044 Software Requirements Description (SRD) for the GPVT
SGTAERI.113 SRD for the Air Traffic Generator (GTA)
SMTCDERI.018 Software Requirements Description (SRD) for Medium Term Conflict Detection (MTCD)
SMWALNKERI.027 Software Requirements Description (SRD) for Middleware-AFTN Link (MwALNK)
SMWCERI.032 Software Requirements Description (SRD) for Middleware-Communications (MwCOM)
SMWCMERI.050 Software Requirements Description (SRD) for Middleware-Control and Monitoring (MwCM)
SMWEDCERI.028 Software Requirements Description (SRD) for Middleware-X25 Link (MwLLNK)
SMWFTPERI.034 Software Requirements Description (SRD) for Middleware-FTP Management (MwFTP)
Software Requirements Description (SRD) for Middleware-Distributed Information
SMWGDERI.051 Management (MwDC)
SMWGSIERI.055 Software Requirements Description (SRD) for Middleware-GSI (MwREC)
Software Requirements Description (SRD) for Middleware-Execution Environment
SMWMEERI.054 Management (MwEEM)
SMWRHERI.053 Software Requirements Description (SRD) for Middleware-Historical Report (MwER)
SMWSERI.052 Software Requirements Description (SRD) for Middleware-Statics (MwSTA)
SMWTCPERI.033 Software Requirements Description (SRD) for Middleware-TCP Management (MwTCP)
SPALADERI.114 Software Requirements Description (SRD) for PALESTRA-Administration (PAL-ADM)
SPALAPERI.116 Software Requirements Description (SRD) for PALESTRA-Analysis and Replay
SPALARERI.113 Software Requirements Description (SRD) for PALESTRA-Architecture
SPALATERI.117 Software Requirements Description (SRD) for PALESTRA-ATM Incidents
SPALFPERI.118 Software Requirements Description (SRD) for PALESTRA-Flight Plan Exploitation (PAL-FP)
SPALMAERI.115 Software Requirements Description (SRD) for PALESTRA-Maintenance
SPAPOERI.112 Software Requirements Description (SRD) for the Session Preparating Position (PAPO)
SPDVERI.043 Software Requirements Description (SRD) for the Flight Plan Position (PDV)
SPIVERI.020 Software Requirements Description (SRD) for the PIV Client (PIV)
Software Requirements Description (SRD) for the Pilot Position and Session Control
SPLPCERI.114 Position (PPL/PCS)
SPOSCOERI.057 Software Requirements Description (SRD) for the Controller Working Position (POS)
SPOSTERI.060 Software Requirements Description (SRD) for the Controller Working Position (POS-T)
SPPSERI.111 Software Requirements Description (SRD) for the Session Preparating and Planning (PPS)
Software Requirements Description (SRD) for the Control Monitoring and Display Position
SPSIHMERI.045 (PSI)
SREPROERI.009 Software Requirements Description (SRD) for the Replay (REPRO)
SREPROTERI.011 Software Requirements Description (SRD) for the Replay (REPRO-T)
SRMETERI.068 Software Requirements Description (SRD) for Metereological Radar Processing (METR)
SSDAERI.080 Software Requirements Description (SRD) for System Data Adquisition (SDA)
SSEIERI.022 Software Requirements Description (SRD) for the Interfaces Edition Subsystem (SEI)
SSEITERI.023 Software Requirements Description (SRD) for the Interfaces Edition Subsystem (SEI-T)
Elaborado: 14/04/16
Página: 17/201
Plataforma

Software Requirements Description (SRD) for the Air Navigation Information Server for
SSINAERI.018 Airports (SINA)
SSMETERI.006 Software Requirements Description (SRD) for the MET/AIS Simulation (SIM-MET)
SSMEVAERI.049 Software Requirements Description (SRD) for SIMEVA
SSNETSERI.069 Software Requirements Description (SRD) for Safety Nets (SNETS)
SSPIVERI.019 Software Requirements Description (SRD) for the Flight Information Position Server (SPIV)
SSUASTERI.084 Software Requirements Description (SRD) for the UAST Simulation (UAST-SIM)
SSURVAERI.082 Software Requirements Description (SRD) for Air Survillance (SURV-A)
SSURVSERI.083 Software Requirements Description (SRD) for Surface Survillance (SURV-S)
STCPVERI.041 Software Requirements Description (SRD) for the Central Flight Plan Data Processing (TCPV)
STLAISERI.024 Software Requirements Description (SRD) for AIS Local Information (TILAIS)
STLATISERI.026 Software Requirements Description (SRD) for ATIS Local Information (TILATIS)
STLMETERI.025 Software Requirements Description (SRD) for MET Local Information (TILMET)
STLPVERI.042 Software Requirements Description (SRD) for the local Flight Plan Data Processing (TLPV)
STMDTERI.027 Software Requirements Description (SRD) for TIMDT
STVGE2447.100 FUNCIONALIDAD_CDM_EN_SISTEMA_DE_TORRE_SACTA
STVMC2425.400 Operativa CDM en TORRE SACTA
SGXCF2292.500 Configuración Envío de datos de Plan de vuelo a CDM
2.2.1. Normativa aplicable

Ref. Titulo Código
N1 Guidelines for ANS Software Safety Assurance ED153
N2 Capability Maturity Model Integration - V1.3 CMMi V 1.3
N3 Standard for Information Technology-Software Life Cycle Process- ISO 12207
Description
N4 Earned Value Management Systems ANSI/EIA 748-2007
N5 Sistemas de gestión de la calidad Requisitos UNE-EN ISO 9001:2015
N6 Sistemas de gestión de la calidad Fundamentos y vocabulario UNE-EN ISO 9000:2015
N7 REGLAMENTO (CE) No 552/2004 DEL PARLAMENTO EUROPEO Y CE Nº 552/2004
DEL CONSEJO de 10 de marzo de 2004 relativo a la
Interoperabilidad de la red europea de gestión del tránsito aéreo
(Reglamento de interoperabilidad)
N8 Procedimiento de Verificación CE de Sistemas de la Dirección de S22-07-PES-001
Navegación Aérea
N9 REGLAMENTO (CE) No 482/2008 DE LA COMISIÓN de 30 de mayo (CE) No 482/2008
de 2008 por el que se establece un sistema de garantía de la
seguridad del software que deberán implantar los proveedores de
servicios de navegación aérea y por el que se modifica el anexo II
del Reglamento (CE) no 2096/2005
N10 Risk Assessment and Mitigation in ATM ESARR 4
N11 REGLAMENTO (CE) No 1035/2011 DE LA COMISIÓN de 20 de CE Nº 1035/2011
diciembre de 2005 por el que se establecen requisitos comunes
Elaborado: 14/04/16
Página: 18/201
Plataforma
Ref. Titulo Código

para la prestación de servicios de navegación aérea
N12 Ley 31/1995, del 8 de noviembre, de Prevención de Riesgos Ley 31/1995, del 8 de noviembre
Laborales,
N13 Real Decreto 1435/1992 de 27 de Noviembre por el que se dictan
las disposiciones de aplicación de la Directiva del Consejo Real Decreto 1435/1992 de 27 de
89/392/CEE, relativa a la aproximación de las legislaciones de los Noviembre
Estados miembros sobre máquinas.
N14 Instrucción de trabajo para la garantía de seguridad de los servicios
A111B-12-INS-001-2.0
y suministros externos
N15 Systems and software engineering - Life cycle process
ISO / IEC 29148
Requirements engineering
N16 Procedimiento de gestión de observaciones, incidencias y
A132-07-PES-020
propuestas de cambio
N17 Procedimiento Gestión de Requisitos SACTA S22-14-PES-001

N18 Software and systems engineering -- Software testing -- Part 2:
ISO/IEC/IEEE 29119-2:2013
Test processes
N19 EUROCONTROL A-CDM
Airport CDM Implementation. The Manual (Eurocontrol/IATA/ACI)
Implementation Manual version 4
N20 Normas para la edición y codificación de la documentación
A141-03-PES-001-9.4
contractual destinada a la División de Automatización.
N21 Procedimiento y requisitos para las acciones formativas derivadas

S22-10-PES-001-3.0
de expedientes de Instalación de Sistemas CNS/ATM
N22 Procedimiento para la Revisión Formal de Requisitos de Sistema en

S22-08-PES-001
la División de Automatización
2.3. Introducción
2.3.1. Objeto
En el presente expediente se establecen los requisitos del Expediente Desarrollo e Implantación de A-CDM
fase II: Mejoras funcionales y nueva interfaz Torre-Plataforma cuyo objeto es mejorar la gestión de los
planes de vuelo que se realiza actualmente.
Los cambios propuestos tienen como finalidad la adaptación de la secuencia de planes de vuelo de despegue
cuando se dan en el aeropuerto situaciones como: necesidades de deshielo, necesidad de paradas de puestas en
marcha durante un periodo de tiempo, necesidad de extensión de tiempos de taxi por alguna circunstancia
imprevista en las rodaduras, cambios en el tratamiento de vuelos con regulación, necesidad de un interfaz que
permita monitorizar/supervisar el estado del enlace y reducir los tiempos de comunicación.
2.3.2. Necesidad del servicio

Los cambios descritos en este expediente son debidos a la evolución necesaria de la operativa completa A-CDM,
así como cambios requeridos por NMOC, Aeropuerto y ATC tras la puesta en servicio de la Fase I.
Elaborado: 14/04/16
Página: 19/201
Plataforma
Un Aeropuerto con certificación A-CDM implica que todos los participantes en dicho entorno (Compañías, agentes
handling, NMOC y Torre) compartan su información, de modo que cualquier circunstancia particular en uno, se
traslade al resto, y al realimentarse los sistemas de dicha información, se mejore la eficiencia de la operación
global de todo el entorno aeroportuario.
Actualmente, en determinadas ocasiones, al no poder dar respuesta automáticamente a través del sistema
SACTA, se utilizan procedimientos operativos manuales que pueden provocar un aumento en la carga de trabajo
operativa, además, al no dar cobertura a determinadas situaciones que ocurren en el Aeropuerto (reducciones de
capacidad, que supone la disminución de la calidad de la secuencia calculada, se reduce
la optimización de la capacidad y los indicadores de NMOC como consecuencia de los datos enviados hace que no
se cumplan los criterios de tolerancia y validez establecidos.
2.3.3. Alcance
El alcance de los cambios que se describen en el presente expediente es el que se indica a continuación:
- Nuevo interfaz de comunicación entre los sistemas SACTA y Aeropuerto (SCENA) basado en mensajes
bidireccionales (con el actual basado en ftp no es posible esta comunicación) que permita monitorizar y
supervisar el estado del enlace, reducir los tiempos de envío/recepción de datos y permitir el reinicio de
los sistemas ante paradas tanto programadas como, sobre todo, no programadas (actualmente una
caída de los sistemas conlleva perdida de datos de PVs afectando de forma importante a la operación y a
la funcionalidad CDM).
- Adecuar la secuencia de planes de vuelo de despegue a la gestión de vuelos con regulación, de forma que
NMOC pueda detectar posibles incumplimientos de CTOT, ya que actualmente al no considerar la TOBT
para vuelos regulados, se están dando incompatibilidades entre dicha hora declarada por la compañía y
la regulación.
- Modificación del algoritmo de secuenciación para considerar la gestión de vuelos que solicitan deshielo,
lo que requiere que el secuenciador se alimente de las características de deshielo concretas así como de
la gestión de secuencias de deshielo en las bases para evitar pérdidas de capacidad, esto implica el
procesado de nuevos campos (Base, tiempo medio de deshielo, solicitud de deshielo, tiempo de inicio de
deshielo) y nuevos resaltes en la posición de control.
- Modificación del cambio de parámetros de aeródromo programado, para que en lugar de tener en cuenta
la EOBT, el cambio sea en base a la TOBT.
- Nueva funcionalidad que permita realizar extensión de los tiempos de taxi por circunstancias operativas
que hace que varíen de manera general los tiempos medios de rodaje, de esta manera se recalculan
TSAT/TTOTs de vuelos que se van a ver afectados y así enviar a NMOC los datos más aproximados a la
realidad de lo que está sucediendo en tierra.
- Nueva funcionalidad para poder programar cambios programados de capacidad, de forma que cuando se
prevea que se va a producir cualquier circunstancia operativa que provoque una variación en las
capacidades de una pista en servicio es muy importante que las horas de TSAT se calculen con estos
parámetros con la antelación suficiente para q NMOC tenga la información más aproximada de la
secuencia durante ese periodo de reducción de capacidad, y tras dicho periodo.
Elaborado: 14/04/16
Página: 20/201
Plataforma
- Nueva funcionalidad que contempla la posibilidad de parar las puestas en marcha, de modo que se
mejora la calidad de la información de huecos (TTOTs) que se envían a NMOC y mejora la estimación de
la secuencia al poder tener en cuenta la resecuenciacion de vuelos a partir de la hora que finaliza la
parada; es decir, no dar TSATs a los vuelos en un periodo en el cual realmente no se van a autorizar las
puestas en marcha.
- Modificación del algoritmo de secuencia que evite la caducidad de planes de vuelo con STS (Ambulancia,
Rescate, Humanitarios, Emergencia), ya que estos vuelos por la condición de su status deben permanecer
en la secuencia para que se les pueda anotar la puesta en marcha en el momento que la soliciten.
- Modificación al recalculo de la secuencia de despegue para evitar recalculos cuando se anote la

autorización de puesta en marcha (ASAT) antes del valor proporcionado por el secuenciador (TSAT),
evitando así penalizar a vuelos con tiempos de TAXI menores y estabilizando la secuencia de despegues.
- Nueva funcionalidad que permita adaptar capacidades y tiempos de taxi en función de las
configuraciones de pista, realizar y visualizar cambios inmediatos o programados en base a las mismas,
además de recalcular de manera automática la secuencia en función de la capacidad y tiempos de taxi, o
establecer el orden en el que los planes de vuelo irán cambiando de pista.
- No actualización de la hora estimada de retirada de calzas (EOBT) cuando se reciba un mensaje de

cancelación de CTOT (SLC) independientemente de la hora de recepción del mismo, de modo que no se
provoquen desalineaciones entre EOBT y TOBT, lo cual invalidaría la autorización de puesta en marcha.
- Modificación de la hora de activación del vuelo para el piloto así como las indicaciones de las horas en las
que el piloto debe ponerse en contacto con la torre, teniendo en cuenta la TOBT y la ETOT MANUAL,
además de la EOBT y ETOT que son las utilizadas actualmente.
Debido a la naturaleza del servicio, todo el equipamiento HW necesario para cumplir con el objeto del
proyecto será proporcionado por Enaire, según indique el Director del Expediente o persona que el designe.
En particular, se reutilizará toda la infraestructura HW instalada y operativa con la versión operacional SACTA
y del Centro de Experimentación y Desarrollo (CED).
Todo el servicio prestado se instalará, y entregará en estado operativo conforme a los requisitos de este PPT,
siendo responsabilidad del Adjudicatario la configuración, y puesta en servicio de todos los elementos sobre
el HW proporcionado por Enaire, según indique el Director del Expediente o persona que el designe.
Los productos obtenidos tras la ejecución de este expediente serán propiedad de Enaire.
2.3.4. Estructura del documento

Este Pliego de Prescripciones Técnicas se estructura de la forma siguiente:
APARTADO 2.1: LISTA DE ACRÓNIMOS

Lista acrónimos, siglas y abreviaturas utilizadas en la redacción del expediente.
APARTADO 2.2: DOCUMENTACIÓN DE REFERENCIA

Documentos de referencia de los diferentes sistemas y subsistemas que conforman la documentación
del sistema objeto de este pliego y que son relevantes para la comprensión de temas o requisitos que se
solicitan en el expediente.
Elaborado: 14/04/16
Página: 21/201
Plataforma
APARTADO 2.3: INTRODUCCIÓN

Describe el objeto, necesidad y alcance del presente expediente.
APARTADO 2.4: DESCRIPCIÓN GENERAL Y ESTRATEGIA DE EVOLUCIÓN

Describe la situación actual del sistema y la estrategia para su evolución.
APARTADO 2.5: REQUISITOS TÉCNICOS

Presenta la composición del proyecto, tanto en hardware como en software y en las disciplinas de
ingeniería aplicables al desarrollo y control del proyecto, así como, los requisitos de carácter técnico del
proyecto clasificados por tipos: Arquitectura, interfaces externos, ambientales, funcionales, operativos,
etc.
APARTADO 2.6: ASEGURAMIENTO DEL PROYECTO

Relaciona los requisitos relativos a Metodología, Gestión del Proyecto, Gestión de Calidad, Gestión de
Configuración y Documentación, Safety, Garantías, Validación y adecuación a la normativa del cielo único.
APARTADO 2.7: LISTA DE ENTREGABLES CONTRACTUALES

Incluye la relación de los documentos contractuales que deberán ser entregados por el Adjudicatario
como parte del proyecto.
APARTADO 2.8: REQUISITOS DE CALENDARIO PARA EL PROYECTO

Detalla los requisitos sobre plazo y secuencia de las actividades principales a considerar en la prestación
del servicio por el Adjudicatario para la elaboración del Plan de Gestión del Proyecto.
APARTADO 2.9: SEGUROS

Se establece los requisitos sobre pólizas de seguro necesarios para la ejecución de este expediente.
APARTADO 2.10: IMPORTE LÍMITE

Se establece el importe límite para la ejecución de este expediente
APARTADO 2.11: LUGAR DE PRESTACIÓN DE SERVICIOS

Se establece el lugar para la prestación del servicio de la empresa Adjudicataria.
APARTADO 2.12: PLAZO DE EJECUCIÓN

Se establece el periodo de tiempo de cada tarea prevista en este documento.
APARTADO 2.13: PLAZO DE GARANTÍA

Se establece el tiempo y alcance de la garantía.
APARTADO 2.14: FORMA DE PAGO

Define la forma de realizar las certificaciones.
APARTADO 2.15: PAGO EN DIVISAS AL ADJUDICATARIO
En la ejecución de este expediente no procede.
APARTADO 2.16: PRÓRROGAS
En la ejecución de este expediente no procede.
APARTADO 2.17: RESPONSABILIDADES
Determina los casos de responsabilidad por parte del adjudicatario y las acciones que Enaire se reserva
para tales situaciones.
Elaborado: 14/04/16
Página: 22/201
Plataforma
APARTADO 2.18: INCOMPATIBILIDADES

Se describen las incompatibilidades que pudieran aparecer por la realización de este expediente y otras
tareas
APARTADO 2.19: LOCALES
Se describen las condiciones de arrendamiento de locales de Enaire.
APARTADO 2.20: MEDIOS INFORMÁTICOS
Acerca de los medios informáticos.
APARTADO 2.21: DIRECCIÓN DEL SERVICIO
Se establece la designación de la persona que deberá ser designada como interlocutor con Enaire.
APARTADO 2.22: POSIBLES INCIDENCIAS RELATIVAS A LOS MEDIOS HUMANOS

Se describen las acciones a realizar ante posibles incidencias relacionadas con los medios humanos y la
forma de informar al Director del Expediente.
APARTADO 2.23: CLÁUSULA DE MEDIOS HUMANOS

Se describen las condiciones para los medios humanos que la empresa deberá de aportar para la
consecución de los trabajos.
APARTADO 2.24: CLÁUSULA DE HUELGA

Se describen las cláusulas en caso de huelga del personal de la empresa adjudicataria.
APARTADO 2.25: CLÁUSULA DE PREVENCIÓN DE RIESGOS LABORALES

Se describen las cláusulas y obligaciones de la empresa en materia de Prevención de Riesgos laborales.
APARTADO 2.26: CLÁUSULA MEDIOAMBIENTAL

Se establece la referencia a la cláusula de obligaciones medioambientales a tener en cuenta en la
ejecución de este expediente.
APARTADO 2.27: CLÁUSULA DE PROPIEDAD INTELECTUAL E INDUSTRIAL

Se establece la referencia a la cláusula de propiedad intelectual e industrial a tener en cuenta en la
ejecución de este expediente.
APARTADO 2.28: NEGLIGENCIA

Se establece la referencia a las cláusulas a tener en cuenta ante cualquier negligencia que pudiera existir
en la ejecución de este expediente.
APARTADO 2.29: SUBCONTRATACIÓN

Se establece la referencia a la cláusula de subcontrataciones a tener en cuenta en la ejecución de este
expediente.
APARTADO 2.30: INSPECCIONES

Se detalla la responsabilidad de las inspecciones y la obligatoriedad de la empresa adjudicataria de
facilitar tales inspecciones por parte de Enaire.
APARTADO 2.31: CLÁUSULA LOPD PARA CONTRATOS DE PRESTACIÓN DE SERVICIOS CON ACCESO A DATOS
DE CARÁCTER PERSONAL
Se describen las cláusulas aplicables de la LOPD.
Elaborado: 14/04/16
Página: 23/201
Plataforma
2.4. Descripción general y estrategia de evolución

En los siguientes apartados se realizará una descripción de la situación actual que ha llevado a la necesidad de
acometer los cambios que han generado la redacción de este Expediente, así como los objetivos de evolución y
mejora que la operativa actual plantea en términos de continuidad del proyecto, mejora de calidad de información
proporcionada al Aeropuerto, Compañías, Handling y NMOC y adecuación del algoritmo de secuenciación a
situaciones hasta ahora no contempladas.
2.4.1. Situación actual

El proyecto A- CDM (Airport-Collaborative Decision Making) se trata de una herramienta de mejora de eficiencia
de las operaciones aeroportuarias mediante el tratamiento del proceso de rotación de los aviones, basándose en
la compartición e intercambio de información entre los distintos actores implicados. Parte de esta información
es utilizada para el cálculo de una nueva información más completa y exacta.
El objetivo es:
- Reducir tiempos de espera en plataforma y en vuelo
- Aumentar la eficiencia de los recursos
- Mejorar la puntualidad
- Mayor predictibilidad mediante un mayor seguimiento de los vuelos
El proceso está basado en eventos denominados Milestones, los cuales facilitan el seguimiento del progreso de
los vuelos. En cada milestone se realizará una serie de acciones (validación de datos, envíos de alertas, registro
de horas, etc.,) de cara a mejorar la calidad de los datos del vuelo y facilitar la toma de decisiones en caso de verse
afectada la puntualidad del mismo.
A lo largo de la progresión de vuelo, se intercambiarán mensajes (DPI/FUM) con CFMU de cara a informar y
mantener actualizada la información (horas/estado) del vuelo; así como mejorar la eficiencia de la Red Aérea
Europea.
El proyecto A-CDM está dividido en varias fases, siendo el objeto de la primera fase la implementación de los
requisitos mínimos exigidos para poder llevar a cabo la integración de los distintos sistemas involucrados
(Aeropuerto, Compañías Aéreas, Agentes handling, Sistema de Torre y NMOC).
Se ha realizado la puesta en servicio de la Fase I de A-CDM en:
- Sistema de Torre SACTA Madrid- 17 de

Julio de 2014 certificado el Aeropuerto como CDM por Eurocontrol,
Además de las pruebas realizadas previamente a la puesta en servicio en entorno de maqueta CED, se
realizan pruebas operacionales a nivel local, y posteriormente, de integración con NMOC, lo que conlleva
a la validación de la operación completa.
- Sistema de Torre SACTA Barcelona: la puesta en servicio tiene lugar en Noviembre 2014, siendo 20 de
Octubre de 2015 certificado el Aeropuerto como CDM por Eurocontrol.
2.4.2. Estrategia de evolución

Una vez implementada la primera fase, queda pendiente acometer en una Fase II una serie de cambios en el
sistema con el objetivo de mejorar la gestión de los planes de vuelo que se realiza actualmente.
Elaborado: 14/04/16
Página: 24/201
Plataforma
Los cambios propuestos tienen como objetivo la mejora del cálculo de la secuencia cuando se dan en el
aeropuerto situaciones como: necesidad de paradas de puestas en marcha durante un periodo de tiempo, mejora
en la gestión de condiciones de deshielo, necesidad de extensión de tiempos de taxi por alguna circunstancia
imprevista en las rodaduras, cambios en el tratamiento de vuelos con regulación, etc.
Dichos cambios son debidos a la evolución necesaria de la operativa completa A-CDM, así como cambios
requeridos por NMOC, Aeropuerto y ATC tras la puesta en servicio de la Fase I.
Actualmente, cuando se da alguna de estas circunstancias que generan la solicitud de cambios en el sistema
SACTA de Torre, se utilizan procedimientos operativos manuales que pueden provocar un aumento en la carga de
trabajo operativa y una disminución de la calidad de la secuencia calculada. Esto implica, además, que los datos
relativos a la secuencia enviados al Aeropuerto y, por tanto, al NMOC no cumplan con los requisitos de calidad
establecidos cuando se opera en dichas condiciones.
2.5. Requisitos técnicos

Se considerarán requisitos técnicos del proyecto todos los que se describen en este apartado o se pudieran
derivar de su interpretación, así como todos los que, pudiéndose encuadrar en esta clase, se pudieran desprender
de otros apartados del PPT.
2.5.1. General
1) El sistema cumplirá los requisitos que se detallan en el presente PPT.
2) El servicio prestado resultante de la aplicación del presente Pliego de Prescripciones Técnicas cumplirá
todos los requisitos del Sistema de Torre SACTA, actualmente en servicio con excepción de aquellos que se
vean modificados o eliminados por los requisitos detallados en este PPT.
3) Todos los servicios prestados con cargo a este expediente actualizarán el sistema de Torre SACTA
operativo actualmente, por lo que deberán ser compatibles con todos los elementos HW y SW asociados
con dicho sistema.
4) El sistema operativo será, por homogeneización con el Sistema actual, la versión de Solaris y Linux Red Hat
que en el momento de ejecución de este proyecto se encuentre validado para cada uno de los CSCI del
Sistema.
5) El rendimiento y la funcionalidad de los nuevos equipos, dispositivos y aplicaciones suministrados tanto en

SW de base como de aplicación, no se verán afectados por el tratamiento de los años bisiestos. Se tendrá
en cuenta lo siguiente:
- Ningún valor posible de fecha producirá detenciones o errores en el sistema de información.
- Todas las operaciones relativas a fechas, incluyendo entre otros tratamientos el cálculo, la
comparación y la ordenación, tendrán los resultados previstos para todos los valores de fechas
válidas dentro del dominio de la aplicación.
- En los elementos lógicos susceptibles de contener fechas, tanto en interfaces como en

almacenamiento de datos, especificarán los años de manera completa, eliminando cualquier posible
ambigüedad.
Elaborado: 14/04/16
Página: 25/201
Plataforma
- Cuando en cualquier elemento de fecha se representa el año sin los dos dígitos iniciales,
correspondientes al millar y a la centena, ello no será obstáculo para que se emplee el año completo
en todas las operaciones en las que intervenga dicho año.
- El formato de almacenamiento de las fechas deberá seguir la norma ISO 8601, que especifica la
notación estándar utilizada para almacenar éstas.
2.5.2. Composición del proyecto

En este proyecto el objetivo fundamental es la implementación de la siguiente fase del proyecto A-CDM para dar
una mejor cobertura a situaciones de deshielo, así como satisfacer necesidades operativas con funcionalidades
requeridas tanto por el Aeropuerto, NMOC y Torre, de forma que se consideren situaciones no contempladas
hasta ahora (paradas de puesta en marcha, cambios en gestión de vuelos con regulación, capacidades
programadas,..) las cuales mejoran la estimación y calidad de información de la secuencia de despegues enviada
a NMOC y que actualmente, al no disponer de ellas, los datos enviados no proporcionan información acerca de
determinadas circunstancias que acontecen en el aeropuerto.
Para este fin, el proyecto incluye las actividades de: diseño, desarrollo e integración de Software (SW), pruebas
internas del Adjudicatario, pruebas de aceptación en el CED, transición operacional y garantía de 2 años,
tomando como referencia para el ciclo de vida de desarrollo de SW la norma ISO/IEC 12207.Este apartado
contiene los requisitos que identifican al conjunto de elementos SW que forman parte de los entregables
asociados a este PPT. También se considerarán parte del proyecto un conjunto de Actividades con carácter de
servicio no directamente relacionado con la producción del software, cuyas características y alcance se detallan
en diversos apartados del PPT. No se contempla la fase de especificación de requisitos por no formar parte del
proyecto, los requisitos detallados se proporcionaran como entrada del proyecto mediante la SRS, SRD y SARAD.
Según lo anterior los elementos asociados a este proyecto se considerarán distribuidos en 2 grupos
denominados:
1. Equipamiento SW
2. Servicios, agrupados en:
a. Estudios sobre Ergonomía del Entorno y de la Posición de Trabajo
b. Actividades de Simulación - Validación Operativa del sistema
c. Actividades y Logística para la Transición y Soporte a la Operación
d. Actividades adicionales de ingeniería de Sistemas y Desarrollo
e. Actividades de Gestión de la Prestación del Servicio
2.5.2.1. Equipamiento SW
2.5.2.1.1. Desarrollo de los cambios SW
Según apartado 2.6.1 de este documento.

 Diseño, codificación y pruebas unitarias SW
 Integración del SW y pruebas de Sistema
2.5.2.1.2. COTS SW de base
1) Como software comercial de base se entregará:

1. La familia de protocolos TCP/IP.
Elaborado: 14/04/16
Página: 26/201
Plataforma
2. El Sistema operativo de los ordenadores a considerar en el expediente.

3. El protocolo ICMP entre máquinas UNIX y Routers, u otro que garantice la conmutación automática.
4. -
compilación.
5. Licencias de todo el software enunciado anteriormente, así como su documentación.
2) El Adjudicatario incluirá, describiendo en detalle, aquellos elementos que, no estando contemplados en

este pliego, considere necesarios para soportar los requisitos que se pudieran desprender de cualquiera de
sus capítulos.
2.5.2.1.3. SW de aplicación
1) El software de aplicación del Sistema ATM que resulte tras la aplicación de los requisitos establecidos en
este PPT se instalará sobre el SW de base o comercial que actualmente están instalados en el sistema
Operacional del Sistema. Se incluirá dentro de este apartado la instalación, integración, y puesta a punto
del software así como las modificaciones necesarias al software de aplicación del Sistema.
2) El SW de aplicación se corresponderá con las actualizaciones de la versión en servicio desarrolladas según
los requisitos del apartado 2.6 ASEGURAMIENTO DEL PROYECTO (en ese apartado del PPT se describen los
requisitos para las actividades de Ingeniería de Sistemas) y conlleva la generación de entregables
Documentales (LDEC) especificados en el apartado 2.7 LISTA DE DOCUMENTACIÓN A ENTREGAR POR EL
ADJUDICATARIO.
2.5.2.2. Servicios
2.5.2.2.1. Actividades y logística para transición y soporte a la operación del sistema
2.5.2.2.1.1. Actividades de gestión de configuración y documentación
Para la ejecución del proyecto se requiere la realización de actividades de Gestión de la Configuración y

Documentación según los Requisitos que se detallan en el apartado 2.6.3 ELABORACIÓN DEL PLAN DE GESTIÓN
DE CONFIGURACIÓN y 2.6.4 ELABORACIÓN DEL PLAN DE GESTIÓN DE LA DOCUMENTACIÓN de este PPT.
2.5.2.2.1.2. Actividades de instalación y, pruebas en emplazamiento
Para la ejecución del proyecto se requiere la realización de actividades de verificación y pruebas según los
Requisitos que se detalla en el apartado 2.6.6 y 2.6.7 de este PPT.
1) Se considerarán para SACTA todas las actividades de carácter logístico, necesarias para hacer frente a los
procesos de despliegue e implantación operacional de las versiones del Sistema ATM, así como de
actualizaciones a las mismas con funcionalidad adicional cuando se planifique de forma desacoplada,
según la planificación establecida, siendo éstas:
 Procedimiento de Instalación
 instalación y pruebas en emplazamiento
 puesta en marcha en CED y en Emplazamiento
 documentación
2) A los efectos de comprobar que se cumplen con los niveles de calidad exigidos en el presente expediente, el
oferente deberán exponer de manera clara en qué forma y con qué recursos técnicos y humanos estiman
Elaborado: 14/04/16
Página: 27/201
Plataforma
hacer frente a estas actividades, habida cuenta del grado de criticidad y especialización que representan la
mayoría de ellas, al tratarse de servicios a ejecutar sobre dependencias y equipamiento en estado
operacional.
2.5.2.2.1.3. Manuales de operación y manual técnico de mantenimiento
Se realizará una actualización de los Manuales del Sistema (Manual del Operador del Sistema), Manuales de
Usuario (MU) del Sistema ATM que pudieran verse afectados por la implementación de los Requisitos contenidos
en este PPT, así como el Manual Técnico de Mantenimiento de acuerdo al apartado 2.6.13 de este documento.
2.5.2.2.1.4. Actividades de transición y puesta en servicio de las actualizaciones y/ o versiones
1) Se considerarán para la funcionalidad CDM todas las actividades de carácter logístico necesarias para hacer
frente a los procesos de TRANSICIÓN operacional de las diferentes versiones según la planificación
establecida para el proyecto y los procedimientos generales acordados con el Director del Expediente o
persona en quien delegue:
 Procedimiento de transición
 Puesta en marcha
 Apoyo durante los procesos de transición
 Documentación
2) A los efectos de comprobar que se cumplen con los niveles de calidad exigidos en el presente expediente, se
deberá exponer la forma en la que va a llevar a cabo la prestación del servicio objeto del contrato, así como
los medios humanos y materiales que estima necesarios para la prestación del servicio, habida cuenta del
grado de criticidad y especialización que representa la prestación del servicio, al tratarse de servicios a
ejecutar sobre dependencias y equipamiento en estado operacional.
3) A los efectos de garantizar el mejor servicio, al tratarse de servicios a ejecutar sobre dependencias y
equipamiento en estado operacional se proporcionarán los mecanismos necesarios para minimizar y
garantizar el menor impacto en el servicio.
2.5.2.2.1.5. Garantía
Será de aplicación todas las consideraciones y requisitos del apartado 2.6.13.3 de este documento.
El Adjudicatario deberá, sin coste adicional y hasta la fecha de finalización del período de garantía:
 subsanar o sustituir todos los defectos de diseño, material, fabricación y funcionamiento que apareciesen en
cualquiera de los equipos suministrados o de las funciones de la nueva versión de la operativa CDM
resultante del proceso de desarrollo de Software (lo que incluye el coste de los medios humanos y materiales
necesarios para ello).
 actualizar el software de base durante el período de garantía.
 prestar servicio de asesoramiento al Director del Expediente o persona a en quien delegue, en la preparación
de los procedimientos para la operación y mantenimiento del Sistema.
La garantía se extiende por un período de dos (2) años a partir de la firma del Acta de Recepción y Liquidación
Provisional.
Elaborado: 14/04/16
Página: 28/201
Plataforma
2.5.2.2.2. Actividades adicionales de ingeniería de sistemas y desarrollo
El Adjudicatario de este expediente y durante la duración del mismo deberá proporcionar los siguientes servicios
de ingeniería:
o Revisión de la documentación de nuevas versiones de organismos internacionales que afecten a la
funcionalidad CDM para realizar un análisis de impacto al Sistema, y proponer en su caso las
adaptaciones SW más adecuadas en cada caso.
2.5.2.2.3. Actividades de gestión de la prestación del servicio
De forma particular, se aplicarán las disciplinas descritas en todos los subapartados del apartado 2.6
Aseguramiento del proyecto:
- Gestión de Proyecto,
- Gestión de la Configuración,
- Gestión de la Documentación,
- Gestión de Calidad,
- Gestión de la Verificación y Pruebas,
- Gestión de Safety,
- Gestión de SW Assurance,
- Gestión de las actividades de Declaración de Componentes según reglamento EC 552/2004,
según los requisitos que detallan en este PPT apartado 2.6 Aseguramiento del Proyecto.
Las actividades formativas serán descritas de manera detallada a medida que se concreten los cambios en el SW.
2.5.3. Requisitos funcionales y operativos a nivel usuario-sistema para CDM

A modo informativo en este apartado se describen de forma resumida los requisitos a nivel de usuario sistema
que deben cumplir las nuevas funciones y prestaciones que serán objeto de desarrollo en este Proyecto. Los
requisitos aquí expuestos son una aproximación, estos requisitos están explicitados en la SRS, SRD y SARAD de
los objetivos, que se proporcionarán a la empresa adjudicataria al comienzo del proyecto.
2.5.3.1. SA#4427. CDM. Mejora en el tratamiento de condiciones adversas

2.5.3.1.1. Especificación
Los siguientes requisitos aplican para Torres configuradas en MODO CDM.
La torre tendrá TPVT con Gestor de Secuencia de Despegues (DMAN).
Es necesario que la UCR SC#11301. Operativa para Aeropuertos de tipo CDM esté implementada.
Para la implementación de esta UCR será necesario disponer del interfaz XML descrito en la UCR SC#11773.
2.5.3.1.1.1. GPVT
2.5.3.1.1.2. Mejora en la gestión de planes de vuelo con deshielo
COM -
Elaborado: 14/04/16
Página: 29/201
Plataforma
REQ - En un sistema de torre con TPVT se podrá seleccionar mediante la lectura de una variable de entorno
MODO DEICE CDM si el modo de operación de deshielo es CDM o el actualmente en servicio descrito en la
SC#11301.
REQ -
descrito en la SC#11301.
REQ -
descrito en esta UCR.
REQ -
independientemente del valor de la variable MOD DEICE CDM.
2.5.3.1.1.2.1. SCENA. Recepción de datos desde la Plataforma CDM
REQ - La plataforma CDM enviará los siguientes datos al servidor de Torre (SMDT):
- Solicitud / Anulación de Solicitud de deshielo (1 carácter)
- EDIT: tiempo estimado de deshielo (2 caracteres)
- BASE: base por la que va a deshelar ese vuelo. (2 caracteres)
- ECZT: Hora de comienzo de deshielo negociada con la base. (13 caracteres)
REQ - Los posibles valores del campo solicitud de deshielo serán:

-
- Vacío
REQ - Los posibles valores de Base de deshielo serán por defecto los definidos en la Tabla de Base- Pista de
despegue definidos en la adaptación, siendo dos caracteres.
REQ - El valor de EDIT (tiempo medio de deshielo) por defecto será el definido en adaptación, siendo dos
caracteres.
REQ - El valor de ECZT (hora de comienzo de deshielo) será un campo horario con el formato AAAAMMDDhh:mm
(13 caracteres)
REQ - Cuando el valor del campo Solicitud de deshielo sea ´D´ se considerará que el vuelo solicita deshielo y los
datos EDIT, Base y ECZT serán obligatorios. En caso de que alguno de los tres no exista o sea incorrecto se
considerará que el vuelo no tiene solicitud de deshielo.
REQ - Cuando el valor del campo Solicitud de deshielo sea <blanco> o un valor distinto de ´D´, se considerará que
el vuelo no solicita deshielo y los campos EDIT, ECZT y Base serán ignorados aunque estén rellenos.
COM - Se descartarán dichos datos aunque el mensaje SCENA para ese vuelo se procesará.
2.5.3.1.1.2.2. Envío de datos a la Plataforma CDM
REQ - Desde el sistema SACTA se podrán enviar a la plataforma los siguientes datos:
- anotación de solicitud de deshielo.
- anulación de solicitud de deshielo.
- cambio de base de deshielo para un vuelo con solicitud de deshielo.
REQ - En el caso que se anote desde la Posición de Control la anotación de deshielo, entonces se asignará Base
de Deshielo definida por defecto en adaptación.
Elaborado: 14/04/16
Página: 30/201
Plataforma
2.5.3.1.1.2.3. Secuenciación de planes de vuelo con deshielo
2.5.3.1.1.2.4. Asignación de datos de deshielo si plan de vuelo no secuenciado
REQ - Cuando para un plan de vuelo que no está en secuencia (no tiene TOBT o su estado no es válido) se reciba
desde la Plataforma CDM un mensaje de SCENA con la solicitud de deshielo se anotará la Base, EDIT y EZCT
recibidos, aunque en este momento no se utilizarán para el cálculo de TTOT.
2.5.3.1.1.2.5. Cálculo inicial de TSAT para plan de vuelo (con datos de deshielo antes de estar secuenciado)
REQ - Cuando se reciba de la Plataforma CDM una TOBT distinta de provisional (P) o inválida (I), para un vuelo que
tiene anotada la solicitud de deshielo, su TTOT se calculará como:
- TTOTini = ECZT +EDIT+EXOTbc,
- Se busca un hueco (TTOT) en la secuencia con prioridad exceptuando los vuelos con autorización de
puesta en marcha (ASAT) o que tengan asignado CTOT,
- Se calcula la TSAT = TTOT-EXOTbc-EDIT-EXOT
- Los valores de TSAT y TTOT se enviarán a la Plataforma CDM.
Siendo
EDIT = Tiempo estimado de deshielo para ese tipo de solicitud.
EXOT = tiempo de taxi desde el stand hasta la pista de deshielo asignado.
EXOTbc= tiempo de taxi desde la base de deshielo hasta la cabecera de despegue.
ECZT= hora de comienzo de deshielo
2.5.3.1.1.2.6. Calculo de TSAT para un vuelo secuenciado que recibe Solicitud de deshielo.
REQ - Cuando un plan de vuelo en secuencia reciba la solicitud de deshielo a través de la Plataforma CDM:
- Se intenta mantener el hueco que el plan de vuelo tiene asignado antes de la solicitud de deshielo,
recalculándose su TSAT = TTOT- (EXOT+EDIT+EXOTbc).
- En caso de que TSAT < TOBT:
 se buscará el mejor TTOT disponible como si fuese una entrada nueva, siendo el óptimo:
TTOTini = EZCT+EDIT+EXOTbc,
- se calculará TSAT=TTOT-EXOTbc-EDIT-EXOT y se envía a la Plataforma CDM
2.5.3.1.1.2.7. Anotación de solicitud de deshielo desde la Posición de Control
REQ - Cuando desde la Posición de Control se anote deshielo, se enviará a la plataforma CDM la anotación de
deshielo pero no se recalculará TSAT/TTOT hasta que no se reciba desde la Plataforma CDM la solicitud de
deshielo.
REQ - El mensaje enviado a la plataforma CDM se enviará también al registro histórico.
2.5.3.1.1.2.8. Anulación de solicitud de deshielo desde la Posición de Control
REQ - Cuando desde la Posición de control se anule la solicitud de deshielo se enviará a la plataforma CDM la
anulación de deshielo pero no se hará ningún recalculo hasta que no se reciba desde la Plataforma CDM la
anulación de solicitud de deshielo.
Elaborado: 14/04/16
Página: 31/201
Plataforma
2.5.3.1.1.2.9. Cambio de base desde la Posición de Control
REQ - Cuando desde la Posición de control se cambie la Base de deshielo a un plan de vuelo se enviará a la
plataforma CDM la nueva base pero no se recalculará la TSAT/TTOT hasta que no se reciba desde la Plataforma
CDM el cambio de Base.
REQ - Un cambio de Base introducido manualmente desde la Posición de Control prevalecerá sobre cualquier
cambio recibido de la Plataforma CDM, aunque no se producirá ningún recalculo hasta que se reciba la base de la
plataforma.
COM - La Base por defecto podrá ser modificada por la base enviada por la Plataforma CDM
2.5.3.1.1.2.10. Condiciones para el recálculo de TSAT para plan de vuelo con deshielo.
REQ - La TSAT/TTOT de un plan de vuelo que tenga anotado deshielo se podrá recalcular por los siguientes
eventos.
REQ - Anulación de deshielo:

- no empeorará el hueco del plan de vuelo por anular la solicitud de deshielo.
- En caso de no poder mejorar su hueco, se mantendrá el hueco y se recalculará su TSAT.
REQ - Cambio de base.

- Si es posible, se mejorará el hueco asignado, y se recalculará su TSAT.
- si TSAT< TOBT, se buscara un nuevo hueco con prioridad sobre todos los vuelos exceptuando los que
tengan ASAT y CTOT.
REQ - Cambio de EDIT.

- Si es posible, se mejorará el hueco asignado, sin penalizar a nadie, y se recalculará su TSAT.
- Si no mejora, se mantiene el hueco asignado y se recalcula TSAT.
En este caso, si TSAT< TOBT, se buscará un nuevo hueco, teniendo en cuenta los criterios definidos
según el estado de la TOBT
REQ - Cambio de pista de despegue.

Cuando se produzca un cambio de pista al plan de vuelo con solicitud de deshielo, pasará a formar parte
de la nueva pista como una entrada nueva, y provocará un recalculo en la pista que deja.
REQ - Cambio de stand. El recalculo será el mismo que el descrito en la UCR SC#11301.
REQ - Cambio de capacidades de pista. El recalculo será el mismo que el descrito en la UCR SC#11301.
REQ - Cambio de ECZT

 Si se recibe una nueva ECZT para un PV su TTOT se calculará como:
 TTOTini = ECZT+EDIT+EXOTbc,
 Se busca un hueco en la secuencia con prioridad exceptuando los vuelos con Aut S/U (tienen ASAT) o con
CTOT,
 Se calcula la TSAT = TTOT-EXOTbc-EDIT-EXOT.
 Se enviará el TTOT y la TSAT a la Plataforma CDM
Elaborado: 14/04/16
Página: 32/201
Plataforma
2.5.3.1.1.2.11. Cambio de TOBT
REQ - Si cambia la TOBT sin cambiar el ECZT, no se recalculará la secuencia.
2.5.3.1.1.2.12. Actualización temporal de vuelos en secuencia
REQ - La actualización temporal de un plan de vuelo con deshielo y solicitud de S/U (es decir, tendrá anotada
ASRT), podrá provocar el recálculo del hueco de los planes de vuelo que estén marcados para deshielo; teniendo
prioridad para ocupar huecos en secuencia los planes de vuelo que no están marcados para deshielo.
COM - El objetivo es que si a un vuelo con deshielo se le anota la solicitud ya que no se puede dar la autorización
de S/U por capacidad de la base de deshielo, los vuelos sin deshielo no se vean afectados. De esta forma, los
vuelos sin deshielo podrían aprovechar los huecos que vayan dejando los que tienen deshielo.
Cuando se anote solicitud de S/U a un vuelo sin deshielo, sí se actualiza toda la secuencia (planes de vuelo con y
sin deshielo).
REQ - La actualización temporal de un plan de vuelo sin Sol DSH y solicitud de S/U (es decir, tendrá anotada
ASRT), provocará el recálculo del hueco de todos los planes de vuelo, estén o no, marcados para deshielo
desplazando la secuencia de la pista.
2.5.3.1.1.3. Requisitos de POS
2.5.3.1.1.3.1. Objeto gráfico ‘DE-ICE INDICATOR’
REQ - En modo NO CDM, el objeto gráfico -

servicio:
 Símbolo 1 configurable cuando el PV no está marcado para deshielo
 Símbolo 2 configurable cuando el PV está marcado para deshielo
REQ - En modo CDM, el objeto gráfico -

 Símbolo 1, para PVs que no tienen Solicitud de deshielo recibida vía PLATAFORMA CDM ni deshielo
marcado manualmente por el controlador o deshielo marcado manualmente por el controlador y para los
cuales el controlador posteriormente ha ejecutado la acción manual de borrar marca manual de deshielo
 Símbolo 2 en color configurable, para PVs que cumplan alguna de las siguientes condiciones:
1. Solicitud de deshielo recibida vía PLATAFORMA CDM no marcado manualmente por el
controlador.
2. Con Solicitud de deshielo recibida vía PLATAFORMA CDM y deshielo marcado manualmente por
el controlador y para los cuales el controlador posteriormente ha ejecutado la acción manual de
borrar la marca manual de deshielo.
1. Sin Solicitud de deshielo recibida vía PLATAFORMA CDM para los cuales el controlador ha
ejecutado la acción manual de marcar deshielo.
2. Con Solicitud de deshielo recibida vía PLATAFORMA CDM para los cuales el controlador había
ejecutado la acción manual de marcar deshielo y para los cuales posteriormente se ha recibido
vía PLATAFORMA CDM la anulación de Solicitud de deshielo.
1. Con solicitud de deshielo recibida vía PLATAFORMA CDM para los cuales el controlador ha
ejecutado la acción manual de marcar deshielo.
Elaborado: 14/04/16
Página: 33/201
Plataforma
2. Con deshielo marcado manualmente por el controlador para los cuales posteriormente se ha
recibido la solicitud de deshielo vía PLATAFORMA CDM
REQ - El símbolo 2 (en Modo CDM) configurable presentará el siguiente resalte configurable Discrepancia entre
base de deshielo y pista de despegue asociadas al PV
REQ - El símbolo 3 (en Modo CDM) configurable presentará el siguiente resalte configurable:
 Discrepancia entre base de deshielo y pista de despegue asociadas al PV
REQ - El símbolo 4 (en Modo CDM) configurable presentará el siguiente resalte configurable Discrepancia entre
base de deshielo y pista de despegue asociadas al PV
REQ - En Modo CDM se presentará el resalte de discrepancia entre base de deshielo y pista de despegue
asociadas al PV cuando la base de deshielo presentada no es la configurada off-line (Datos de adaptación) para la
pista de despegue asignada al PV
2.5.3.1.1.3.2. Objeto gráfico ‘ACCESS TO DE-ICE INDICATOR’
REQ - En modo CDM, el objeto gráfico -

-
REQ - En modo CDM y NO CDM, el objeto gráfico - asociada la siguiente

función configurable:
 Marcar/Desmarcar deshielo
COM - Para ejecutar estas acciones desde el campo del Tabular de Previstos de Despegue es necesario que el PV
esté seleccionado.
REQ - disponible siempre que el PV no tenga Solicitud de

deshielo recibida vía PLATAFORMA CDM ni deshielo marcado manualmente por el controlador (símbolo 1 y 2)
REQ -
deshielo manualmente por el usuario (símbolo 3 y 4)
REQ - A continuación se describen las transiciones posibles entre estados del indicador de deshielo en modo
CDM:
1. De símbolo 1 a símbolo 2
Esta transición se produce de forma automática al recibirse de PLATAFORMA CDM la solicitud de
deshielo = D
Esta transición se produce de forma automática al recibirse por PLATAFORMA CDM la solicitud de
deshielo = vacio,
Esta transición se produce de forma manual al ejec
acción tendrá panel de confirmación
Esta acción tendrá panel de confirmación

Elaborado: 14/04/16
Página: 34/201
Plataforma
acción no tendrá panel de confirmación.

Esta transición se produce de forma manual al ejecutar el co
deshielo marcado manualmente por el controlador. Esta acción tendrá panel de confirmación
deshielo= vacío, únicamente para PVs que tenían deshielo marcado manualmente por el controlador y
también solicitud deshielo recibida vía PLATAFORMA CDM
REQ - En modo CDM el símbolo presentado e - -ice
dichos campos estén presentando un valor marcado manualmente.
COM - Cualquier actualización que se reciba de PLATAFORMA CDM será procesada. En la Posición de Control se
presentará la información actualizada de PLATAFORMA CDM a pesar de que el controlador haya modificado
manualmente algún dato.
Así cuando el valor del indicador de deshielo haya sido fijado manualmente por el controlador, dicho campo podrá
actualizarse con el valor que se reciba de PLATAFORMA CDM a través del nuevo interfaz.
REQ - de
NOMBRE DEL VUELO
REQ -
símbolo 2) tendrá un panel de confirmación con texto NOMBRE DEL VUELO
y los botones ACP y ANLR
REQ - En modo no CDM no se presentarán paneles de confirmación para ejecutar las funciones
marcar/desmarcar deshielo
REQ - Cada transición del indicador de deshielo de un PV generará un registro histórico.
REQ - En Modo CDM, cuando se modifique el estado de solicitud de deshielo recibido de PLATAFORMA CDM (es
decir pasa de tener solicitud de deshielo = D a tener solicitud = vacio, o viceversa), -ice
in - cación (recuadro verde parpadeante)
 en los PVs que tengan al menos alguna de las siguientes acciones: Autorización ATC, Solicitud de puesta
en marcha o REA, Autorización de puesta en marcha, y
 en las Posiciones que cumplan alguna de las siguientes condiciones:
1. El estado de progresión del PV en la Posición es asumido en frecuencia, asumido-liberado o
entrante.
2. En la Posición que tiene asignado el OR de tipo Autorizaciones de la ruta de control del PV,
cuando el PV no está asumido (ni asumido en frecuencia ni asumido liberado) en ninguna
posición de la torre.
Elaborado: 14/04/16
Página: 35/201
Plataforma
Nota: se refiere a las transiciones posibles entre estados del indicador de deshielo siguientes:
Transición 1: De símbolo 1 a símbolo 2
REQ - -ice
sobre otras funciones configuradas sobre el objeto.
REQ - -ice
e-
viceversa
REQ - - -
presentará de forma simultánea a otros resaltes presentados sobre el objeto gráfico
REQ - El reconocimiento del re - -ice
NOTA: Si el vuelo estuviera liberado en la Pos de Autorizaciones (por tener autorización de puesta en marcha) y el
reconocimiento fuera local, el resalte se propagaría a otras posiciones aunque Clearance reconociera el resalte.
Para evitar la propagación del resalte, se especifica que el reconocimiento sea global.
REQ - - o de-
presentarán:
 Símbolo 1 (Modo No CDM) si estaba presentando símbolo 1 (Modo CDM) en Modo CDM.
COM - En Modo NO CDM los objetos gráficos De- - presentan los

siguientes símbolos:
 Símbolo 1: para PVs que no tienen Solicitud deshielo marcado manualmente por el controlador
 Símbolo 2: para PVs que tienen Solicitud deshielo marcado manualmente por el controlador
REQ - - -ice indicator

presentarán:
 Símbolo 3 (Modo CDM) si estaba presentando símbolo 2 (Modo No CDM) en Modo No CDM.
 Símbolo 1 (Modo CDM) si estaba presentando símbolo 1 (Modo No CDM) en Modo NO CDM.
2.5.3.1.1.3.3. Objeto gráfico BASE DE DESHIELO
REQ -
REQ -
 - ando el símbolo 1, el campo Base de deshielo
estará vacío. Nota: El campo Base no presentará guión, estará vacío.
 -
presentará, de mayor a menor prioridad:
Elaborado: 14/04/16
Página: 36/201
Plataforma
o El valor editado manualmente por el controlador, si existe, o bien

o El valor recibido por PLATAFORMA CDM
 -
presentará la primera de las bases de deshielo asociada off-line (Adaptación o fichero de configuración) a
la pista de despegue.
 -
presentará, de mayor a menor prioridad:
o El valor recibido por PLATAFORMA CDM, si existe, o bien
o La primera de las bases de deshielo asociada off-line (Adaptación o fichero de configuración) a la
pista de despegue
REQ - En Modo NO CDM el objeto gráf

 -
Base de deshielo presentará
o El valor que tenía previamente en modo CDM (si se ha realizado un cambio de modo), o bien
o Valor vacío. Nota: El campo Base no presentará guión, estará vacío.
 -
Base de deshielo presentará, de mayor a menor prioridad:
o El valor que tenía previamente en modo CDM (si se ha realizado un cambio de modo), o bien
o La primera de las bases de deshielo asociada off-line (Adaptación o fichero de configuración) a la
pista de despegue.
REQ - El objeto gráfico Base de deshielo tendrá asociada la siguiente función configurable tanto en modo CDM
como en modo No CDM:
 Selección manual de base de deshielo.
REQ - se presentará un panel con todas las bases

de deshielo configuradas off-line (Adaptación o fichero de configuración). Al seleccionar un valor, el panel se
cerrará automáticamente y se ejecutará la modificación de la base.
Nota: En el panel se presentarán las bases de deshielo asociadas a todas las pistas.
REQ -
campo
REQ - los siguientes resaltes listados por orden de

prioridad:
 Discrepancia entre base de deshielo y pista de despegue asociadas al PV
 Resalte de notificación
REQ - Se presentará el resalte de discrepancia entre base de deshielo y pista de despegue asociadas al PV
cuando la base de deshielo presentada no es la configurada off-line (Datos de adaptación) para la pista de
despegue asignada al PV.
Elaborado: 14/04/16
Página: 37/201
Plataforma
REQ -
resaltes presentados sobre el objeto (valor manual, discrepancia entre base de deshielo y pista de despegue
asociadas al PV).
REQ - En Modo CDM, cuando se modifique el valor de la base de deshielo recibido de PLATAFORMA CDM (es decir,
pasa de tener un valor1 (distinto de vacío) a tener un valor2 (distinto de vacío)),
otificación en las Posiciones que cumplan alguna de las siguientes condiciones:
 El estado de progresión del PV en la Posición es asumido en frecuencia, asumido-liberado o entrante.
 En la Posición que tiene asignado el OR de tipo Autorizaciones de la ruta de control del PV, cuando el PV
no está asumido (ni asumido en frecuencia ni asumido liberado) en ninguna posición de la torre.
para PVs que cumplan simultáneamente las siguientes condiciones:
 el PV no tiene valor manual en el campo Base de deshielo (no se ha ejecutado la acción manual
 El PV tiene anotada al menos alguna de las siguientes acciones: Autorización ATC, Solicitud de puesta en
marcha o REA, Autorización de puesta en marcha.
Nota: El resalte de notificación no afectará a PVs cuyo Indicador de deshielo esté presentando símbolo 1 ó
símbolo 2 (en Modo CDM) pues tal como se ha definido para estos casos el campo Base de deshielo estará vacío o
con valor manual
REQ -
sobre otras acciones configuradas sobre el objeto.
REQ - El reconocimiento
NOTA: Si el vuelo estuviera liberado en la Pos de Autorizaciones (por tener autorización de puesta en marcha) y el
reconocimiento fuera local, el resalte se propagaría a otras posiciones aunque Clearance reconociera el resalte.
Para evitar la propagación del resalte, se especifica que el reconocimiento sea global.
REQ - Cuando se haya modificado manualmente por un controlador, dicho campo

dejará de actualizarse con el valor que se reciba posteriormente vía PLATAFORMA CDM excepto en el caso de que
se reciba por PLATAFORMA CDM la anulación de Solicitud (en este caso sí será procesada la información para
presentar el campo BASE vacío)
REQ - Al pasar de Modo CDM a Modo No CDM, y viceversa, el campo Base conservará el valor editado
manualmente.
2.5.3.1.1.3.4. Contador de deshielo por base:
REQ - Existirá una nueva Ventana que contabilizará PVs con deshielo por base, tanto en Modo CDM como en
Modo No CDM.
REQ - Se
actualmente existe en el menú principal. Será una opción añadida a las ya existentes:
 S/U por pista

 S/U + TAX por pista
 S/U + TAX por OR
 Deshielo por pista
Elaborado: 14/04/16
Página: 38/201
Plataforma
COM -
nuevo adicional.
REQ - Tendrá como título DESHIELO POR BASE y tendrá formato de tabla.
Presentará las siguientes columnas:
 BASE. En esta columna se presentará el nombre de la base.
 S/U*. En esta columna se contabilizarán los PVs que cumplan simultáneamente las siguientes
condiciones:
o Son PVs no Activos
o
o En Modo CDM tienen deshielo marcado manualmente por el controlador y también solicitud de
deshielo vía Plataforma CDM(símbolo 4 en Modo CDM),
o En Modo NO CDM tienen deshielo marcado manualmente por el controlador (símbolo 2 en Modo
CDM)
Esta columna presentará un resalte amarillo cuando el valor sea mayor que el LIM asociado a la base.
 LIM: límite configurado por Adaptación, modificable online desde la posición de supervisor (PST). Este
límite aplica a la columna S/U*.
 PEND: En esta columna se contabilizarán los PVs que cumplan simultáneamente las siguientes
condiciones:
o Son PVs no Activos
o Tienen Solicitud de S/U o REA, pero no Autorización S/U.
o En Modo CDM tienen deshielo marcado manualmente por el controlador y también solicitud de
deshielo vía Plataforma CDM (símbolo 4 en Modo CDM),
o En Modo NO CDM tienen deshielo marcado manualmente por el controlador (símbolo 2 en Modo
CDM)
La tabla presentará una fila por cada base de deshielo que tenga asignado al menos un PV. En caso de
discrepancia entre base editada por controlador y base recibida por Plataforma CDM el PV se contabilizará en la
fila correspondiente a la base editada por el controlador. Presentará una fila TOTAL con la suma de valores de las
demás filas.
Ejemplo:
BASE S/U* LIM PND

BE 4 7 6
BW 3 8 2
TOT 7 8
REQ - El valor del Límite de PVs con Autorización de S/U y deshielo será configurable offline (Datos de
Adaptación o fichero de configuración), para cada Base.
REQ - El valor del Límite de PVs con Autorización de S/U y deshielo será modificable online desde la PST, para
cada Base.
2.5.3.1.1.4. Requisitos de simulación
REQ - Se podrá simular la recepción para un plan de vuelo de la siguiente información:
Elaborado: 14/04/16
Página: 39/201
Plataforma
- Solicitud de deshielo
- Desolicitud de deshielo
- Base de deshielo
- EDIT (tiempo estimado de deshielo)
- ECZT(hora estimada de inicio de deshielo)
2.5.3.1.1.5. SPV
REQ -
PVs con Autorización de S/U y deshielo para cada Base.
2.5.3.1.1.5.1. Registros históricos
REQ - Cuando se reciba una solicitud de deshielo para un PV en un mensaje de Plataforma CDM se generará un
histórico con el siguiente texto:
PV <indicativo> - <origen> - <destino> SOL. DSH por <origen solicitud> en <base> durante <edit>
Donde <origen solicitud> podrá ser Plataforma CDM
REQ - Cuando se anote una solicitud de deshielo para un PV desde una Posición de control se generará un
PV <indicativo> - <origen> - <destino> CONFIRMAR DSH por <origen solicitud>
Donde <origen solicitud> será los ORs que tenga asignados la PICT desde la que se anota la confirmación de
deshielo.
REQ - Cuando se reciba una solicitud de deshielo para un PV en un mensaje de Plataforma CDM se generará un
PV <indicativo> - <origen> - <destino> ANULAR SOL. DSH por <origen solicitud>.
Donde <origen solicitud> podrá ser Plataforma CDM
REQ - Cuando se desmarque deshielo para un PV desde una Posición de control se generará un histórico con el
siguiente texto:
PV <indicativo> - <origen> - <destino> ANULAR CONFIRMAR DSH por <origen solicitud>.
Donde <origen solicitud> será los ORs que tenga asignados la PICT desde la que se anota la confirmación de
deshielo.
REQ - Cuando se modifique la base de deshielo para un PV se generará un histórico con el siguiente texto:
PV <indicativo> - <origen> - <destino> MODIF BASE DSH por <origen solicitud> de <base antigua> a <base
nueva>
Donde <origen solicitud> podrá ser Plataforma CDM o los ORs que tenga asignados la PICT desde la que se anota
la confirmación de deshielo.
REQ - Cuando se reciba la ECZT para un PV se generará un histórico con el siguiente texto:
PV <indicativo> - <origen> - <destino> EZCT <valor antiguo> // <valor nuevo>
REQ - Cuando se reciba la EDIT para un PV se generará un histórico con el siguiente texto:
PV <indicativo> - <origen> - <destino> EDIT <valor antiguo> // <valor nuevo>
REQ - Todos estos históricos generados se almacenarán en el GSI local de torre
Elaborado: 14/04/16
Página: 40/201
Plataforma
REQ - Tanto en modo CDM como NO CDM, existirá un registro histórico de asignación/modificación de STAND de
despegue al plan de vuelo que se almacenará en el GSI local de torre indicando si ha sido recibido de SCENA
(texto:SCENA) o modificado desde la Posición (texto: ORs de la Posición)
REQ - Tanto en modo CDM como NO CDM, existirá un registro histórico de asignación/modificación de STAND de
arribada al plan de vuelo que se almacenará en el GSI local de torre. indicando si ha sido recibido de SCENA
(texto:SCENA) o modificado desde la Posición (texto: ORs de la Posición)
REQ - Tanto en modo CDM como NO CDM, existirá un registro histórico que indique las
asignaciones/modificaciones/cancelación de CTOT.
REQ - Tanto en modo CDM como NO CDM, cuando se recibe un tipo de aeronave de SCENA diferente al del plan
de vuelo, se generará un histórico.
2.5.3.1.1.6. GEODESYS
REQ - En la BDAP > Configuración de Dependencias > Dependencia > Funcionalidad TPVT> Configuración de
Superficie Aeródromo Asociado, se definirá los Tiempos de Taxi base de deshielo- pista (EXOTbc), que consistirá
en una tabla de datos entre cada base de deshielo y cada pista de despegue.
REQ - Los datos de la tabla podrán tener hasta dos caracteres numéricos.
Superficie Aeródromo Asociado-> Límites de PV S/U-TAX, se definirá el valor del Límite de PVs con Autorización
de S/U y deshielo para cada Base
-
Pista
REQ - Cada pista tendrá siempre una base de deshielo asociada.
REQ - Una misma base podrá estar asociada a varias pistas.
REQ - Será obligatorio definir todos los datos de la Tabla
COM - Por ejemplo, Los valores para esta Tabla en el caso de la dependencia de Torre Barajas serán:
Base de deshielo Pista

BE 36R
BW 36L
BE 32R
BW 32L
BW 18R
BE 18L
BW 14R
BE 14L
Elaborado: 14/04/16
Página: 41/201
Plataforma
2.5.3.1.1.7. Herramientas.
REQ - En la herramienta PV Máquina de TPVT se almacenarán los siguientes datos:

- ECZT
- EDIT
- Base de deshielo asignado
REQ - Se dispondrá de una herramienta que permita encolar los mensajes definidos en la PCI SC#11773
IMPLEMENTACIÓN DE LA INTERFAZ SACTA CDM y que incluya los datos de deshielo descritos en esta UCR.
COM - Con la implementación de la UCR SC#11773, la información que se recibe de la plataforma CDM se enviará
a través del nuevo interfaz, y no vía SCENA.
2.5.3.1.1.8. Requisitos de tolerancia a fallos
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Gestión de Salidas en
los distintos entornos operacionales.
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Gestión de Planes de
Vuelo de Torre.
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Gestión de la
Configuración Operativa en los distintos entornos operacionales.
2.5.3.2. SA#4428. CDM. Cambios en el tratamiento de PVs con CTOT

Los siguientes requisitos aplican para aeropuertos que operen como CDM.
2.5.3.2.1.1. TPV
2.5.3.2.1.1.1. Cálculo de TSAT para vuelos con CTOT en base a TOBT
REQ - Para un plan de vuelo con CTOT, si

 su TSAT (calculada como CTOT-EXOT,), es anterior a la TOBT, y
 la TOBT tiene un estado diferente de P (provisional) o I (inválido) ,
entonces, se recalculará su TTOTini como TOBT + EXOT, y se buscará el primer hueco disponible en la secuencia
con prioridad sobre los demás planes de vuelo exceptuando los que tengan ASAT y CTOT. Una vez obtenido el
TTOT, se recalculará su TSAT.

 su TSAT (calculada como CTOT-EXOT,) , es posterior o igual a la TOBT, y
 la TOBT tiene un estado diferente de P (provisional) o I (inválido) ,
entonces, se calculará TSAT como CTOT-EXOT teniendo en cuenta los criterios de prioridad y separación.

 su TSAT (calculada como CTOT-EXOT,), es anterior a la TOBT, y
 la TOBT tiene estado P (provisional) o I (inválido) ,
Elaborado: 14/04/16
Página: 42/201
Plataforma
entonces, no se calculará su TSAT/TTOT.

 su TSAT (calculada como CTOT-EXOT,) , es posterior o igual a la TOBT, y
 la TOBT tiene estado P (provisional) o I (inválido) ,
entonces, se calculará TSAT como CTOT-EXOT teniendo en cuenta los criterios de prioridad y separación.
REQ - Para un plan de vuelo con CTOT que no tiene TOBT:

- la TSAT se calcula en base al CTOT,
- en el momento que tenga TOBT valida, se deberá comparar los valores de TSAT y TOBT y realizar el
cálculo en base a lo descrito en los requisitos previos.
COM - Actualmente, un vuelo con CTOT, su TSAT se calcula como CTOT- EXOT, independientemente de su TOBT y
ocupa hueco con prioridad exceptuando los vuelos con ASAT.
REQ - Si para un plan de vuelo cuya TSAT ha sido calculada en base a los requisitos descritos anteriormente,
aplicarán los criterios del cálculo de TSAT para pvs con CTOT.
2.5.3.2.1.1.2. Caducidad de vuelos con CTOT
REQ - Un plan de vuelo con CTOT sin autorización de puesta en marcha, independientemente de que su TSAT
esté calculada en base a su CTOT o su TOBT, se caducará cuando se cumpla que Hora Actual +EXOT +
EDIT+EXOTbc > CTOT+ PARAM_RESALTE_CTOT, siendo dicho parámetro por defecto 8 minutos.
REQ - En el fichero de configuración PARAMETROS_CDM.TXT se definirá el parámetro PARAM_RESALTE_CTOT.
COM - Actualmente, un vuelo sin CTOT, tendrá un criterio de caducidad distinto a los PVs con CTOT, caducando a
TSAT+5.
2.5.3.2.1.1.3. Cálculo de TSAT para vuelos con igual CTOT
COM - Actualmente, los planes de vuelo con CTOT tienen asignado un TTOT igual a su CTOT, aunque internamente
se reservan huecos si hay varios planes de vuelo con el mismo CTOT o CTOT que no cumple las reglas de
separación con respecto a otros con CTOT. Estos huecos reservados se denominan DTOT-R.
En el nuevo requisito se especifica que a los planes de vuelo con CTOT se les asigne un hueco diferente, es decir,
el DTOT-R que actualmente ya se calcula. Además esta asignación será por orden de llegada del CTOT en caso de
igualdad de CTOT, y en caso de vuelos con diferente CTOT, vuelos con CTOT anterior penalizan a vuelos con CTOT
posterior, aunque los primeros se reciben más tarde. Es decir, hay que aplicar las mismas reglas de cálculo de
TTOT para vuelos con o sin CTOT, respetando las reglas de prioridad y separación.
REQ - El hueco asignado (TTOT) a un Plan de Vuelo con CTOT será el primero disponible teniendo en cuenta los
criterios de separación y prioridad. Se recalculará su TSAT en base a su TTOT.
REQ - Un Plan de Vuelo con CTOT tendrá prioridad respecto a los planes de vuelo cuyo CTOT sea posterior.
COM - Esto implica que la asignación de un nuevo CTOT para un plan de vuelo (nuevo o modificado) puede
empeorar la TSAT de otros planes de vuelo con CTOT.
Elaborado: 14/04/16
Página: 43/201
Plataforma
COM - Ejemplos:
Caso 1: Partimos de tres vuelos con el mismo CTOT que se van recibiendo en el distinto momento, su hueco TTOT
se les asigna por orden en el que se va recibiendo CTOT.
Si TDEP es 3 min
Hora recepción
CTOT TTOT
CTOT
Pv1 0800 1000 1000
Pv2 0830 1000 1003
Pv3 0840 1000 1006
Caso 2: tenemos un vuelo PV1 regulado ocupando un TTOT,
Hora recepción
CTOT TTOT
CTOT
Pv1 0800 1004 1004
Y posteriormente van llegando vuelos con CTOT anterior al PV1 :

Si TDEP es 2 min
Hora recepción
CTOT TTOT
CTOT
Pv1 0800 1004 1008
Pv2 0830 1000 1000
Pv3 0840 1000 1002
PV4 0900 1000 1004
Pv5 0910 1000 1006
2.5.3.2.1.2. POS
REQ - El objeto gráfico TSAT para vuelos con CTOT (tanto para los que tengan TSAT calculada en base a su CTOT
como los que tengan TSAT calculada en base aTOBT) presentará los siguientes resaltes:
 Resalte 1: TSAT anterior a margen, cuando
CTOT-5˃Hora Actual +EXOT+ EDIT+EXOTbc
siendo
EDIT: tiempo medio de deshielo. Dato proporcionado por la Plataforma. Sólo
se aplica si el plan de vuelo tiene solicitud de deshielo.
EXOTbc: tiempo entre base de deshielo y cabecera. Dato de adaptación.
Sólo se aplica si el plan de vuelo tiene solicitud de deshielo.
Este resalte desaparecerá cuando el vuelo tenga Autorización S/U o cuando se cancele el CTOT
 Resalte 2: TSAT dentro de margen, cuando
CTOT-
Este resalte desaparecerá cuando el vuelo tenga Autorización S/U o cuando se cancele el CTOT
 Resalte 3: TSAT posterior a margen, cuando el PV no tenga Autorización de puesta en marcha y
Elaborado: 14/04/16
Página: 44/201
Plataforma
siendo PARAM_RESALTE_CTOT será parámetro configurable, por defecto 8 min
COM - Los resaltes definidos en el requisito previo, dejarán de aplicarse si se cancela el CTOT, pasando a aplicar
los correspondientes a los vuelos sin CTOT.
COM - Cambian las reglas para la presentación de los resaltes ya existentes (TSAT anterior a margen, TSAT
dentro del margen y TSAT posterior a margen)
REQ - Para un plan de vuelo (con y sin CTOT), el resalte de invalidez sobre la TOBT se presentará siempre que:

 Tenga anotada Solicitud de REA o Solicitud de S/U
Y se dejará de presentar cuando tenga anotada la Autorización de S/U.
COM - Actualmente, el resalte se presenta SOLO SI el vuelo tiene autorización o solicitud de puesta en marcha, y
se deja de presentar cuando tiene anotada la autorización de taxi.
REQ - Para un plan de vuelo sin CTOT, se presentará el resalte de precaducidad desde TSAT + PARAM_Caducidad
hasta TSAT+5; posteriormente se presentará el resalte de caducidad.
REQ - El PARAM_Caducidad será un parámetro definido en unidades de segundos.
REQ - Por defecto, el valor del parámetro PARAM_Caducidad será 240 segundos (4 minutos).
COM - La idea es advertir de la próxima caducidad del vuelo, presentando un resalte en el mismo color que el
definido actualmente para caducidad desde TSAT+4 hasta TSAT+5.
REQ - En el fichero de configuración PARAMETROS_CDM.TXT se definirá el parámetro PARAM_Caducidad.
REQ - REQ- 7 Los resaltes de TSAT para los planes de vuelo sin CTOT serán:.
 Resalte 1 (TSAT anterior a margen) : Hora Actual < TSAT -5
 Resalte 2 (TSAT dentro del margen): TSAT-5
 Resalte 4 (TSAT próximo a caducar): TSAT+ PARAM_Caducidad
 Resalte 3 (TSAT posterior a margen): Hora Actual > TSAT+5
COM - Cambian las reglas para la presentación de los resaltes ya existentes (TSAT anterior a margen, TSAT
dentro del margen y TSAT posterior a margen) y se especifica un nuevo resalte (TSAT próximo a caducar)
2.5.3.2.1.3. SEI
REQ -
Vuelo de Torre.
Elaborado: 14/04/16
Página: 45/201
Plataforma
2.5.3.3. SA#4430. Función de extensión de tiempos de taxi
La siguiente funcionalidad afecta a Torres CDM.
2.5.3.3.1.1. GPVT
REQ - Existirá una nueva función en la Posición de supervisión de Torre que permita extender los tiempos de taxi
2.5.3.3.1.1.1. Configuración de la extensión de tiempos de taxi
REQ - Para configurar la extensión de tiempos de taxi existirán:

 Filtros:
o Terminal/Rampa: será una lista plana con scroll. Se podrán seleccionar uno o varios valores:
definidos en la tabla Terminal y Rampa de la BDAP en el orden en el que se presenten en la
tabla.
o Cabeceras de pistas:
Valores: los definidos en la tabla Aeródromos de la BDAC.
 Periodo de aplicación.
Intervalo horario definido mediante los campos de Hora Inicio y Hora Fin.
Condiciones:
o Será obligatorio introducir hora de inicio. Si no se introduce una hora de fin la restricción se
aplicará hasta que se anule o se vuelva a configurar otra extensión.
o El comienzo del intervalo (Hora de Inicio de aplicación de la extensión de tiempos de taxi)
siempre será futuro con respecto a la hora actual.
 Factor de extensión: se podrá sumar o multiplicar.
o Para sumar: entre 1 y 99 minutos
o Para multiplicar: entre 0.5 y 5.0 con resolución de décimas.
2.5.3.3.1.1.2. Nuevo Campo “Orden de Asignación”
COM - La idea es disponer de un campo que permita definir el orden en el que se atendieron los planes de vuelo
y en base al cual se realizarán los recálculos de la secuencia.
REQ -
REQ -
REQ -
Provisional o Inválida.
REQ - E cada plan de vuelo se rellenará cada vez que se asigne una nueva
TOBT a un plan de vuelo que está en secuencia, incrementándose cada nueva TOBT (distinta de Provisional e
Invalida) que se reciba para dicho plan de vuelo de la Plataforma CDM teniendo en cuenta el orden de asignación
del resto de planes de vuelo de la secuencia.
Elaborado: 14/04/16
Página: 46/201
Plataforma
REQ -
recalculo de los valores de orden de asignación de todos los vuelos para optimizar la numeración.
COM - Ejemplo.
A) Partiendo de tres planes de vuelo, que se confirman en el siguiente orden: PV1, PV2 y PV3
PV O.A.
PV1 1
PV2 2
PV3 3
B) Se recibe TOBT Modificada para el PV2

PV O.A.
PV1 1
PV2 4
PV3 3
C) Se recibe TOBT Invalida para el PV1

PV O.A.
PV1 0
PV2 4
PV3 3
D) Se recibe TOBT Confirmada para el PV1

PV O.A.
PV1 5
PV2 4
PV3 3
PV O.A.
PV1 1000
PV2 987
PV3 993
E) Recalculo del orden de asignación:

PV O.A.
PV1 3
PV2 1
PV3 2
REQ - Los planes de vuelo sin TOBT, su campo ORDEN de ASIGNACIÓN estará vacío.
REQ - Existirá una herramienta que se ejecutará desde el SMDT, la cual generará un fichero denominado
asignado un orden, con el
siguiente formato:
INDICATIVO ORIGEN DESTINO ORDEN_ASIGNACIÓN
Elaborado: 14/04/16
Página: 47/201
Plataforma
2.5.3.3.1.1.3. Algoritmo de Extensión de tiempos de taxis
REQ - En función de la forma de definir el Factor de extensión se calculará el EXOTextendido de la siguiente

forma:
- Si se ha seleccionado sumar: EXOTextendido = EXOT + Valor introducido
- Si se ha seleccionado multiplicar: EXOTextendido = EXOT * Valor introducido.
Los tiempos de TAXI resultantes de aplicar el factor de extensión se redondearan al valor más cercano. (nota: los
tiempos de taxis se definen actualmente en minutos).
REQ - Identificación de planes de vuelo afectados: Cuando se configure la extensión de tiempos de taxi, se
aplicará a los vuelos que cumplan las siguientes condiciones:
- TOBT con estado C, M o S esté dentro del periodo de aplicación
- CTOT esté dentro del periodo de aplicación
- no tengan ASAT
- cumplan los filtros definidos.
REQ - El recálculo de TTOT para los vuelos sin CTOT ya en secuencia que se ven afectados por la extensión de
EXOT se hará de la siguiente forma, partiendo de menor valor de orden de asignación de los planes de vuelo
afectados por la extensión, se realiza el siguiente recálculo:
- Se mantiene la TSAT que tiene el plan de vuelo antes de la extensión.
- Se recalcula el TTOT como TTOTini = TSATini + EXOTextendido.
o Si está libre se asignará.
o Si no está libre, partiendo de este TTOTini se buscará el primer hueco disponible sin penalizar a
ningún plan de vuelo.
Si recalcula la nueva TSAT = TTOT - EXOTextendido.
REQ - El recálculo de TTOT para los vuelos con CTOT ya en secuencia que se ven afectados por la extensión de
EXOT se hará de la siguiente forma:
- TSAT= CTOT- EXOTextendido.
COM - El vuelo con CTOT deberá tener en cuenta lo especificado en la UCR SA#4428. En caso de no tener
implementada dicha UCR, la prioridad de un plan de vuelo con CTOT, será la definida en la SC#11301.
REQ - Cuando exista un extensión de taxis programada, y un vuelo que no tenía TOBT o no tenía TOBT valida,
pasa a tenerla, y su TOBT esté dentro del intervalo de extensión de TAXI se utilizará el EXOTextendido para el
cálculo de su TSAT, se calculará:
- TTOT= TOBT+ EXOTextendido, si el hueco está disponible, se le asigna el hueco y se calcula su TSAT=
TTOT-EXOTextendido.
- Si el hueco no está disponible, se irá buscando un TTOT sin penalizar a ningún otro plan de vuelo y se
calculará la TSAT correspondiente.
REQ - En caso de que el vuelo tenga anotado deshielo, la extensión del tiempo de taxi, aplica sobre el EXOT (
definido en adaptación como Tiempo de Taxi Stand Pista), no se aplicará sobre los tiempos deshielo EDIT (Tiempo
Medio de Deshielo) o EXOTb (Tiempo de Taxi entre base y cabecera)
COM - Cuando se anote la autorización de S/U (ASAT) a un vuelo al que se le ha aplicado la extensión del tiempo
de taxi, se utilizará el tiempo de taxi extendido para calcular su TTOT.
Elaborado: 14/04/16
Página: 48/201
Plataforma
2.5.3.3.1.1.4. Modificación de la extensión programada
REQ - Una extensión de tiempos de taxi podrá ser modificada,

- antes de comenzar la Hora inicial previamente programada: se deberán recalcular los vuelos
afectados con respecto a la nueva programación.
- antes de terminar la Hora Final previamente programada: se deberán recalcular aquellos vuelos cuya
TOBT sea mayor o igual a la Hora Actual a la que se realiza la modificación.
REQ - Cuando se modifique la extensión de tiempos de taxi, se identificarán los planes de vuelos que:
- con la extensión anterior no estaban afectados y que lo están por la modificación.
- con la extensión anterior sí estaban afectados y que siguen estando afectados.
- con la extensión anterior sí estaban afectados y que dejan de estarlo con la modificación.
REQ - Para aquellos planes de vuelos que

- con la extensión anterior no estaban afectados y que lo están por la modificación.
- con la extensión anterior sí estaban afectados y que dejan de estarlo con la modificación.
Se aplicarán los requisitos descritos en el algoritmo de cálculo de vuelos con extensión de taxis.
REQ - Para aquellos planes de vuelos que con la extensión anterior sí estaban afectados y que siguen estando
afectados, se mantendrán en la secuencia sin recalcularse.
2.5.3.3.1.1.5. Anulación de la extensión programada
REQ - Una extensión de tiempos de taxi podrá ser anulada,

- antes de comenzar la Hora inicial previamente programada: se deberán recalcular los vuelos
afectados.
- antes de terminar la Hora Final previamente programada: se deberán recalcular aquellos vuelos cuya
TOBT sea mayor o igual a la Hora Actual a la que se realiza la anulación.
REQ - El algoritmo para el recalculo de TTOTs por anulación de la extensión programada será:
- Se identificarán los planes de vuelo afectados por la anulación.
- Se sacan de la secuencia dichos planes de vuelo, y teniendo en cuenta el orden de asignación de los
planes de vuelo, comenzando por el de menor valor, se irán calculando sus TTOT en base a su EXOT no
extendido:
o si el TTOT está libre, se le asigna dicho TTOT
o si no está libre, se le asigna el primer hueco TTOT disponible, sin penalizar a ningún otro plan de
vuelo.
- Finalmente, cuando haya finalizado el recalculo de los planes de vuelo afectados por la anulación, se
realizará un recalculo de la secuencia completa por si hubiese planes de vuelo que pudiesen mejorar,
teniendo en cuenta en dicho recalculo del resto de planes de vuelo el orden de asignación.
REQ - Cuando se anule la extensión de tiempos de taxi, se identificarán los planes de vuelos que:
- con la extensión sí estaban afectados y que siguen estando afectados.
- con la extensión sí estaban afectados y que dejan de estarlo con la modificación.
REQ - Para aquellos planes de vuelos que con la extensión sí estaban afectados y que dejan de estarlo con la
modificación. Se aplicarán el requisito donde se describe el algoritmo de recálculo por anulación de la extensión
de tiempos de taxi.
Elaborado: 14/04/16
Página: 49/201
Plataforma
REQ - Para aquellos planes de vuelos que con la extensión anterior sí estaban afectados y que siguen estando
afectados, se mantendrán en la secuencia sin recalcularse.
REQ - Los planes de vuelo que tengan autorizada la puesta en marcha, no se verán afectados por la anulación de
la extensión.
2.5.3.3.1.2. SPV
REQ - El aspecto gráfico de la ventana será similar a la siguiente:
REQ -
rellenar por el usuario
REQ -
no editables y sus valores serán los definidos en adaptación, además existirá el valor TODOS, que comprenderá
todas las terminales/rampas o cabeceras de pista.
REQ -
rellenar por el usuario.
REQ -
aparecerán vacíos al abrir la pantalla.
REQ -
REQ - En la parte derecha de la pantalla exist
Elaborado: 14/04/16
Página: 50/201
Plataforma
REQ -
REQ -
columnas correspondientes
REQ -
REQ - Se podrá seleccionar una línea de dicha ventana, y sólo una, haciendo click con el BIR.
REQ -
REQ -
REQ -
REQ - El fun
-
-
-
REQ - Se presentará un mensaje de confirmación al usuario al modificar la EXTENSION PROGRAMADA.
REQ -
REQ -
REQ - S
REQ -
REQ -
REQ - Cuando una extensión programada caduque se borrará automáticamente.
REQ - Independientemente del orden de introducción de las extensiones programadas la ventana las mostrará
en orden cronológico.
REQ -
programadas que se hayan configurado y cerrará la ventana.
REQ -
informativo y no cerrará la ventana.
Elaborado: 14/04/16
Página: 51/201
Plataforma
REQ -
REQ - Las acciones realizadas en esta pantalla se enviarán a grabación para su posterior explotación.
REQ -
REQ - cerrará la ventana.
REQ -
programada falta alguno de los siguientes campos, indicando qué campo/s causa/n la no ejecución:
- Al menos un filtro
- Fecha de inicio
- Factor de extensión
REQ -
Extensiones programadas cuyo periodo de aplicación se solapan y coinciden en los filtros, de forma que no se
ejecutará la extensión hasta que se resuelva el solape indicando el motivo que causa la no ejecución.
COM - Ejemplo:
Se programa:

Filtro: Terminal T123 Cabecera 36L Periodo :04/06/2014 10:00 04/06/2014 11:00 Factor: x 1.5

Filtro: Terminal T123Cabecera 36L, 36R Periodo :04/06/2014 10:10; 04/06/2014 10:30 Factor: + 10
REQ -
final es anterior a la fecha inicial, de forma que no se ejecutará la extensión hasta que se corrija indicando el
motivo que causa la no ejecución.
REQ -
inicial y/o final es anterior a la Hora Actual, de forma que no se ejecutará la extensión hasta que se corrija
indicando el motivo que causa la no ejecución.
REQ -
la extensión hasta que se corrija indicando el motivo que causa la no ejecución.
REQ -
de forma que no se ejecutará la
extensión hasta que se corrija indicando el motivo que causa la no ejecución. .
REQ -
programado una extensión idéntica a otra ya ejecutada.
REQ - No se permitirá editar los dos factores de extensión para una misma programación de extensión de
tiempos de taxi.
Elaborado: 14/04/16
Página: 52/201
Plataforma
REQ -
ninguna extensión.
COM - Si hay varios motivos de los descritos anteriormente por los que no se puede ejecutar la extensión, se
listarán en el mismo mensaje.
COM - Todos los mensajes de advertencia y confirmación se acordaran con DAUT.
REQ - Tras un arranque de sistema o de tándem SMDT las extensiones programadas que aún estén vigentes
deberán ser recuperadas y mostrarse en la pantalla.
2.5.3.3.1.3. GEODESYS
REQ -
Terminal
REQ -
REQ - En la Tabla Terminal/Rampas: se definirán los valores de las rampas y terminales a los que se asociarán
los stands, de la misma manera que actualmente se definen los terminales.
REQ - En la definición de Rampas, no será necesario definir el valor a imprimir en la ficha cuando un plan de
vuelo tenga asignado un stand de esa rampa.
2.5.3.3.1.4. POS
REQ - Existirá un nuevo
2.5.3.3.1.5. Históricos
REQ - Se generará un registro histórico cuando se programe, modifique o cancele una extensión de tiempos de
taxi, indicando respectivamente:
- PROGRAMACION
- MODIFICACION PROGRAMACION
- CANCELACION PROGRAMACION
Además, se indicará: periodo de aplicación, filtros, y factor de extensión.
REQ - En caso de modificación o cancelación se indicará en el registro histórico la programación original.
REQ - Se generará un histórico cada vez que se modifique el valor del EXOT por una extensión, indicando el valor
del EXOT anterior y el nuevo.
REQ - Cada vez que se modifique el ORDEN de ASIGNACION a un plan de vuelo, se generará un histórico con el
siguiente formato:
<fecha><hora> PV <indicativo-Origen-Destino> CAMBIO ORDEN ASIGNACION xxx /// xxx
Elaborado: 14/04/16
Página: 53/201
Plataforma
Vuelo de Torre.
2.5.3.4. SA#4563. Cambio programado de capacidades pista
REQ - Los siguientes requisitos aplican en MODO CDM y MODO NO CDM.
2.5.3.4.1.1. TPV
2.5.3.4.1.1.1. Descripción de la Ventana Configuración de capacidades de aeródromo
REQ -
presentará por cada pista los siguientes campos:

- Capacidad
- Hora Inicio
- Hora Fin
REQ -
REQ - Se podrán programar al mismo tiempo capacidades para diferentes pistas.
2.5.3.4.1.1.2. Función de programación de capacidades de pistas
REQ - En caso de que se programe una capacidad para una pista de despegue introduciendo el valor de
- En el momento en que se ejecute la capacidad programada definida, los planes de vuelo cuya DTOT-R
Hora Inicio, recalcularán su DTOT-r para aplicar la nueva capacidad. Se recalcula su TSAT/TSAT-r en modo
CDM y HPMD en modo NO CDM.
- Cuando HoraActual = Hora Inicio,
o Zona Capacidades de Aeródromo: el valor de capacidad para dicha pista se presentará en el
algún valor editado en
dicho campo anteriormente.
o Zona Capacidades Programadas: se borrarán los valores de Capacidad y Hora Inicio.
COM - El recálculo de la secuencia para los planes de vuelo afectados se produce en el momento en el tras editar
las capacidades progr
cuando la hora actual se iguala a la hora de inicio.
REQ - En caso de que se programe una capacidad para una pista de despegue introduciendo el valor de
Elaborado: 14/04/16
Página: 54/201
Plataforma
- En el momento en que se ejecute la capacidad programada, los planes de vuelo que cumplan Hora
Inicio DTOT-R -r para aplicar la nueva capacidad. Se recalcula su
TSAT/TSAT-r en modo CDM y HPMD en modo NO CDM.
- Los planes de vuelo cuya DTOT-r > Hora Fin, mantendrán la capacidad definida en la zona de
Capacidades de Aeródromo.
- Cuando HoraActual = Hora Inicio,
o Se resaltará el valor de la Capacidad y de la Hora Inicio en un color hasta que Hora Actual= Hora
Fin.
o Cuando Hora Actual= Hora Fin: se borrarán los valores programados para dicha pista de
despegue de la Zona de Capacidades Programadas.
REQ - En el caso de que se programe una configuración sin Hora Final, y teniendo en cuenta que la hora Actual <<
Hora Inicio (es decir, no se han borrado los datos de la programación de dicha zona), si se modifica la
programación indicando una Hora Fin, se recalcularán los nuevos planes de vuelo afectados tal y como se ha
descrito el requisito anterior.
REQ - En caso de desprogramar una capacidad antes de la Hora de Inicio, o durante la parada, se reordenará la
secuencia de vuelos cuyas DTOT-r se vean afectadas.
REQ - En el caso de reducir/ampliar el periodo de aplicación de la capacidad programada, se reordenará la

secuencia de vuelos cuyas DTOT-r se vean afectadas.
2.5.3.4.1.2. SPV
2.5.3.4.1.2.1. Ventana de Configuración de Capacidades de Aeródromo y mensajes de usuario
COM - Se propone modificar la ventana actualmente operativa por la siguiente:
Elaborado: 14/04/16
Página: 55/201
Plataforma
REQ -
 Capacidad: el usuario sólo podrá introducir un valor numérico. Al pulsar Ejecutar o Analizar el sistema
 Hora Inicio:

REQ - ellas pistas que tengan
REQ - Al pulsar
contrario aparecerá un Mensaje de advertencia indicando este hecho.
REQ - Después de realizar una modificación de las capacidades (programación, desprogramación o modificación
Mensaje de
- Aceptar, que aplicará el cambio cerrando la ventana de confirmación y la ventana de Capacidades
- Cancelar, que cerrará la ventana de confirmación y nos devolverá el foco a la ventana de capacidades
REQ - Una vez implantado el cambio en el sistema se presentará al usuario un mensaje informativo con el
REQ - Si el usuario configura manualmente una capacidad programada cuyo periodo de aplicación supera 1 hora
drá dos botones:

- Aceptar: se cerrará el mensaje de información, se realizará el análisis y si es correcto se cerrará la
ventana de Capacidades
- Cancelar: que cerrará la ventana de información y nos devolverá el foco a la ventana de capacidades.
REQ - La Hora de Inicio siempre se considerará anterior a la Hora Final.
REQ -
programado de capacidades es superior a 1 hora Dicho mensaje tendrá:
- botón de Aceptar, al pulsarlo se cerrará dicho mensaje y ejecutará la programación
- Botón de Cancelar, devolverá el foco a la ventana de capacidades.
REQ -
- botón de Aceptar, al pulsarlo se cerrará dicho mensaje y ejecutará la programación

- Botón de Cancelar, devolverá el foco a la ventana de capacidades.
REQ - Mensaje de Información. Se presentará un mensaje si se programan capacidades para pistas no activas al
REQ - Mensaje de advertencia. Se presentará un mensaje si al pulsar el botón

inicial y/o final es anterior a la Hora Actual, de forma que no se ejecutará la programación hasta que se corrija
indicando el motivo que causa la no ejecución. Dicho mensaje tendrá un botón de Aceptar, al pulsarlo se cerrará
dicho mensaje y nos devolverá el foco a la ventana de capacidades.
Elaborado: 14/04/16
Página: 56/201
Plataforma
COM - Si como Hora Inicio= 23:50 y Hora Fin= 00:10, se entenderá que el periodo comienza en el dia N, y termina
en día N+1, siendo la duración de 20 minutos.
COM - El texto de todos los mensajes de usuario será acordado previamente con la División de Automatización.
REQ - Tras un arranque de sistema o de tándem SMDT las capacidades programadas que aún estén vigentes
deberán ser recuperadas y mostrarse en la pantalla.
COM - El SMDT guardará en memoria las capacidades programadas mientras estén vigentes en hora, de modo
que tras un arranque de servidor con datos, el SMDT pueda mostrar dichas capacidades.
REQ - la ventana de
REQ - Si se pulsa el botón Ejecutar sin haber realizado ningún cambio el sistema generará un mensaje
e ha realizado ninguna modificación en las Capacidades, no
2.5.3.4.1.2.2. Registros históricos
REQ - Cuando se programe (texto PROGRAMACION) o desprograme (texto ANULACION) una capacidad o se
modifique (texto MODIFICACIÓN) cualquiera de sus valores (hora Inicio, hora Fin y/o Capacidad) se generará un
registro histórico indicando el texto correspondiente a cada acción, así como el valor antiguo y el actual de
capacidad, hora inicio y/o fin para la/s pista/s de despegue/s.
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Consulta de Histórico de
Planes de Vuelo en los distintos entornos operacionales.
Vuelo de Torre.
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Supervisión Técnica en
2.5.3.5. SA#4564. CDM. Función de paradas de puesta en marcha
Los siguientes requisitos aplican para aeropuertos que operen como CDM y NO CDM.
Elaborado: 14/04/16
Página: 57/201
Plataforma
2.5.3.5.1.1. TPV
2.5.3.5.1.1.1. Operativa CDM
REQ - Los siguientes requisitos aplican cuando la variable de entorno MODO _CDM está a SI.
REQ - Cuando se configure una parada de puesta en marcha para una pista, se recalcularán las TSATs de la
secuencia cuya TSAT Hora Inicio, de forma que se verán afectados todos los vuelos secuenciados con TSAT ora
Inicio.
REQ - El algoritmo de recalculo de TSAT cuando se ejecute una parada de puesta en marcha será:
- la TSAT del primer vuelo afectado por la parada, deberá ser TSAT= Hora Fin, y se calculará su TTOT.
- El resto de vuelos se irán secuenciando en el mismo orden de TSATs en el que estaban antes de la
parada:
1. Primer vuelo:
Antes de la parada tiene TSAT1
Después de la parada: TSAT1final= Hora Fin
2. Siguiente vuelo
Antes de la parada tiene TSAT2
Después de la parada tiene: TSAT2final=TSAT2+t,
Siendo t=HoraFin TSAT1
3.
Antes de la parada tiene TSATn
Después de la parada tiene: TSATnfinal=TSATn+t,
Siendo t=HoraFin TSAT1
REQ - El cálculo de TTOT será TTOT= TSATfinal+EXOT, en caso de no poder asignar ese hueco por estar ocupado
por otro vuelo con mayor prioridad, se asignará el siguiente hueco disponible, y se recalculará la TSAT
COM - Ejemplo: Aplicación del algoritmo a una parada de puesta en marcha.
REQ - No se restringirá ninguna anotación de solitudes, autorizaciones o modificaciones de datos del plan de
vuelo desde la POS durante el periodo de parada.
Elaborado: 14/04/16
Página: 58/201
Plataforma
REQ - Si anota una autorización de puesta en marcha a un plan de vuelo, se calculará su hueco
independientemente del periodo de parada, teniendo en cuenta la hora a la que se anotó la puesta en marcha y el
tiempo entre stand-pista.
REQ - En caso de incrementar el periodo de parada de puesta en marcha, se aplicarán los requisitos anteriores.
REQ - En el caso de decrementar el periodo de parada, se reordenará la secuencia de vuelos cuyas TSATs mayor o
igual a la primera Hora Fin de Parada,
- la TSAT del primer vuelo afectado por la parada, deberá ser TSAT= Hora Fin, y se calculará su TTOT.
- El resto de vuelos se irán secuenciando en el mismo orden de TSATs en el que estaban antes de la
modificación de la hora final de la parada:
1. Primer vuelo:
Tiene TSAT1
Tras modificación de hora fin de la parada: TSAT1final= Hora Fin
2. Siguiente vuelo
Tiene TSAT2
Tras modificación de hora fin de la parada: TSAT2final=TSAT2-t1,
Siendo t1= TSAT1 - HoraFin
3.
Tiene TSAT2
Tras modificación de hora fin de la parada: TSATnfinal=TSATn-t1,
Siendo t1= TSATn - HoraFin
COM - Ejemplo de modificación (decremento) de una parada de puesta en marcha:
REQ - En caso de deshabilitar la parada de puestas antes de la Hora de Inicio de Parada, o durante la parada, se
reordenará la secuencia de vuelos cuyas TSATs Hora Fin de Parada (programada), teniendo en cuenta el
algoritmo descrito para el decremento de la hora de finalización de la parada.
Elaborado: 14/04/16
Página: 59/201
Plataforma
REQ - Cuando un plan de vuelo con ASRT, con TSAT HoraInicialParada, si por actualización temporal debido a la
solicitud de puesta en marcha, su TSAT resultante está dentro del periodo de parada de puestas en marcha, se
recalculará su TSAT de forma que:
- su TSAT será posterior a la HoraFinParada
- No penalizará a otros vuelos con ASRT en caso de competir por el mismo TTOT
- tendrá prioridad en la asignación de TTOT frente a otros vuelos sin ASRT, exceptuando vuelos con CTOT o
ASAT.
REQ - Cuando un plan de vuelo con TSAT HoraInicialParada, si por alguna actualización (modificación Stand,..),
su TSAT HoraInicialParada, se recalculará su TSAT de forma que sea posterior a la Hora Fin de Parada y no
penalice a nadie en la secuencia.
COM - Se siguen manteniendo los criterios de prioridad en la versión en servicio, solo en el caso del requisito
descrito previamente, los vuelos con ASRT tendrán prioridad frente a otros vuelos.
REQ - Cuando un plan de vuelo tenga anotada ASAT, no se verá afectado por la parada de puestas en marcha,
hasta que se revoque. Es decir, no habrá restricción a la anotación de la autorización de puesta en marcha
durante el periodo de parada.
REQ - Cuando un plan de vuelo tenga CTOT, no se verá afectado por la parada de puestas en marcha, es decir,
queda excluido del algoritmo de paradas de puesta en marcha.
COM - En los casos en los que la cancelación o modificación de la parada se produzca a una hora próxima a la
hora actual, en la resecuenciación de vuelos se deberá tener en cuenta el parámetro PCDM2.
2.5.3.5.1.1.2. Operativa NO CDM
REQ - Los siguientes requisitos aplican cuando la variable de entorno MODO _CDM está a NO.
REQ - El sistema permitirá anotar solicitudes, autorización y modificaciones de cualquier tipo durante el periodo
de parada programada. Y a aquellos PVs afectados por la función de Paradas de Puesta en Marcha. Es mejor
decir que no se restringirá ninguna acción (anotación/solicitud/autorización) o modificación de datos a PVs
durante el periodo en el que esté activa la función de Paradas de Puesta en Marcha.
REQ - Si anota una autorización de puesta en marcha a un plan de vuelo, se calculará su hueco
independientemente del periodo de parada, teniendo en cuenta la hora a la que se anotó la puesta en marcha y el
tiempo entre stand-pista.
REQ - Cuando se configure una parada de puesta en marcha para una pista, se recalcularán las HPMDs de la
Hora Inicio.
REQ - El algoritmo de recalculo de HPMD cuando se ejecute una parada de puesta en marcha será:
o la HPMD del primer vuelo afectado por la parada, deberá ser HPMD= Hora Fin, y se calculará su DTOT.
o El resto de vuelos se irán secuenciando en el mismo orden de HPMDs en el que estaban antes de la
parada:
1. Primer vuelo:
Antes de la parada tiene HPMD1
Después de la parada: HPMD1final= Hora Fin
Elaborado: 14/04/16
Página: 60/201
Plataforma
2. Siguiente vuelo
Antes de la parada tiene HPMD2
Después de la parada tiene: HPMD2final=HPMD2+t,
Siendo t=HoraFin HPMD1
3.
Antes de la parada tiene HPMDn
Después de la parada tiene: HPMDnfinal= HPMDn+t,
Siendo t=HoraFin HPMD1
REQ - Cuando un PV cuya HPMD < H. Inicio de la parada, y se actualice la HPMD por actualización temporal de la
forma que su
nueva HPMD = H. Fin de la Parada y se recalculará el resto de la secuencia.
REQ - Los PVs con CTOT no recalcularán su HPMDs. Seguirán manteniendo su HPMD:
o HPMD= CTOT - TaxiStandPista TmedioDeshieloPista (*).
o (*) El parámetro Tiempo medio de deshielo por avión para cada pista
o y aquellos PVs cuyas HPMDs estén comprendidas en el intervalo horario de paradas de Puesta en
Marcha presentarán un resalte configurable.
REQ - Cuando un PV cuya HPMD < H. Inicio de la parada, y se actualice la HPMD por modificación de STAND,
HPMD será posterior a la H. Fin de la Parada ocupando el mejor hueco disponible sin penalizar a nadie.
REQ - Cuando se configure una parada de puesta en marcha para una pista, se recalcularán las HSSs de la
Inicio.
REQ - Cuando un PV cuya HSS < H. Inicio de la parada y por actualización temporal debe actualizarse la HSS, de
Fin de la Parada y se recalculará el resto de la secuencia.
REQ - El algoritmo de recalculo de HSS cuando se ejecute una parada de puesta en marcha será:
o la HSS del primer vuelo afectado por la parada, deberá ser HSS= Hora Fin
o El resto de vuelos se irán secuenciando en el mismo orden de HSS en el que estaban antes de la parada
teniendo en cuenta TDEP y TDSH:
1. Primer vuelo:
Antes de la parada tiene HSS1
Después de la parada: HSS1final= Hora Fin
2.
HSS n=Hora fin+(n-m-1)*TDEP + m*(TDSH+MAX(TDSH- TDEP,TDEP))/2
Dónde:
n es la posición que ocupa el PV en la zona de PVs sin CTOT (siendo 1 el PV que ocupa el primer
lugar tras la parada
una pista)
m osición anterior a n en la zona de
Elaborado: 14/04/16
Página: 61/201
Plataforma
REQ - Los PVs con CTOT no recalcularán su HSSs. Seguirán manteniendo su HSS (HSS=HOPM) y aquellos PVs
cuyas HSSs estén comprendidas en el intervalo horario de paradas de Puesta en Marcha presentarán un resalte
configurable.
2.5.3.5.1.2. POS
REQ - Existirá un resalte (configurable) sobre el campo TSAT para aquellos planes de vuelo con CTOT
(independientemente de que se haya calculado o no en base a CTOT o TOBT) cuando se cumpla
HoraInicialParada TSAT HoraFinParada. Dicho resalte desaparecerá cuando el PV con CTOT tenga anotado
Autorización S/U.
REQ - El objeto gráfico HPMD presentará un resalte configurable sobre aquellos PVs con CTOT cuando su HPMD
esté comprendida en el intervalo horario de paradas de puestas en marcha (HoraInicialParada HPMD
HoraFinParada). Dicho resalte desaparecerá cuando el PV con CTOT tenga anotado Autorización S/U.
REQ - El objeto gráfico HSS presentará un resalte configurable sobre aquellos PVs con CTOT cuando su HSS esté
comprendida en el intervalo horario de paradas de puestas en marcha (HoraInicialParada HSS HoraFinParada).
Dicho resalte desaparecerá cuando el PV con CTOT tenga anotado Autorización S/U.
REQ - Cuando se ejecute la función de paradas de puesta en marcha sobre una pista activa, se presentará una
ventana de aviso al usuario en la Posición que tenga asignado al menos un OR de tipo CLD. Esta ventana se
mostrará en la Posición desde el momento en que se ejecute la acción de paradas de puestas en marcha
independientemente del intervalo horario programado.
o Esta ventana no se podrá cerrar manualmente, se podrá mover de pantalla y recolocar en otra ubicación
de la posición.
o Esta ventana se cerrará automáticamente cuando finalice la parada o se cancele desde la Posición de
Supervisor.
o
activa en ese momento, no se presentará el mensaje en la POS hasta que se active dicha pista.
o
activa, se cerrará automáticamente la ventana de aviso en la POS y se cancelará la función.
o El texto que presentará la ventana de aviso será:
PARADAS DE PUESTA EN MARCHA DE hh:mm A hh:mm EN LA PISTA XXX..
o Esta ventana se actualizará si cambia la hora inicio y/o fin.
2.5.3.5.1.3. SPV
REQ -
paradas de puesta en marcha para una o varias pistas, estén o no activas.
REQ -
REQ -
siguiente:
Elaborado: 14/04/16
Página: 62/201
Plataforma
Nota: la Hora de inicio y fin sería por ejemplo: 10:00 a 10:20.
REQ - Al ejecutar la función se mostrarán, en dicha ventana, todas las pistas de la dependencia (activas o no).
REQ - El valor por defecto de las campos de Hora Inicio y Fin tras un arranque de los procesadores SMDT será
nulo, sin ninguna hora programada.
REQ - Cuando una pista supere la hora fin el contenido de las casillas se borrará.
REQ - Si el operador ha introducido en el sistema unos valores válidos, mientras una línea esté vigente en
tiempo, el valor de las casillas se mantendrá al cerrar la ventana, de modo que al volver a abrirla muestre dichos
valores en los campos de Hora Inicio y Fin.
REQ -
duración sea igual o superior a 30 minutos, al ejecutar la parada, se presentará un mensaje al usuario solo si la
pista está activa.
REQ - El mensaje informativo de una parada superior a 30 minutos aparecerá en una nueva ventana tipo pop-up
con un mensaje con
REQ - El mensaje informativo de una parada superior a 30 minutos contendrá el botón de Aceptar, que al
presionarlo implantará los cambios en el sistema y cerrará ambas ventanas, la del pop-up y la de paradas
programadas
Elaborado: 14/04/16
Página: 63/201
Plataforma
REQ - El mensaje informativo de una parada superior a 30 minutos contendrá el botón de Cancelar, que al
presionarlo cerrará la ventana de pop-up sin implantar ningún cambio, devolviendo el cursor a la pantalla de
paradas programadas.
REQ -
REQ - Por cada pista, se presentará:

 Hora Inicio (formato hh:mm): campo editable. Por defecto, Hora Actual
 HoraFin (formato hh:mm): campo editable. Por defecto, Hora Actual

Decr
REQ - Los campos Hora de Inicio y de Fin, serán editables por el usuario.
REQ - El botón Ejecutar realizará las comprobaciones definidas en el botón analizar e implantará los cambios
configurados y cerrará la ventana. Ejecutando el cambio si supera dichas comprobaciones, o mostrando un
mensaje de error indicando la comprobación que no ha superado así como el motivo del error.
REQ - El botón Analizar realizará las siguientes comprobaciones:

- Hora inicio deberá ser anterior que la Hora de Fin. Teniendo en cuenta los cambios de día.
- Hora de inicio u Hora Fin no deberán ser anteriores a la hora Actual.
- Si la parada definida contiene un periodo cuya duración sea igual o superior a 30 minutos se presentará
un mensaje al usuario, pero solo si la pista está activa.
la comprobación que no ha superado así como el motivo del error. La ventana permanecerá abierta tras aceptar
el mensaje correspondiente
REQ - El botón Salir cerrará la ventana sin aplicar los cambios.
REQ - El periodo de paradas de puesta en marcha podrá modificarse en cualquier momento, siempre y cuando el
procesador SMDT esté operativo.
REQ - Si el procesador SMDT no está operativo la función aparecerá en vídeo débil en los menús de la PSI.
REQ - La función estará disponible en el menú contenedor indicado en el archivo de perfil así como con el botón
derecho sobre el procesador SMDT operativo.
REQ - Cuando se modifique una parada de puesta en marcha, se presentará un mensaje de confirmación al
usuario.
REQ - Cuando se habilite/deshabilite una parada de puestas en marcha, se generará un registro histórico con, al
menos los siguientes datos:
- Pista de despegue afectada
- Periodo de aplicación de la parada
- Pistas activas
REQ - Las actividades realizadas de configuración de parada de puestas en marcha desde la PSI se enviarán a
grabación para su posterior explotación.
Elaborado: 14/04/16
Página: 64/201
Plataforma
Vuelo de Torre.
2.5.3.6. SA#4982. Modificación al cambio programado de aerodromos para CDM
COM - Los requisitos indicados a continuación solo afectan a Torres con Operativa CDM.
2.5.3.6.1.1. TPV
2.5.3.6.1.1.1. Nuevo campo “ORDEN DE ASIGNACIÓN”
COM - Existirá un nuevo campo con la idea de poder determinar el orden en el que se atendieron los planes de
vuelo y en base al cual se realizarán los recálculos de la secuencia.
REQ - Existirá un nuevo campo en el plan de vuelo máquina de torre que se llamará
REQ - L
REQ -
REQ -
REQ -
COM - Ejemplo.
Partiendo de tres planes de vuelo, que se confirman en el siguiente orden: PV1, PV2 y PV3
PV O.A.
PV1 1
PV2 2
PV3 3
Se recibe TOBT Modificada para el PV2

PV O.A.
PV1 1
PV2 4
PV3 3
Se recibe TOBT Invalida para el PV1
Elaborado: 14/04/16
Página: 65/201
Plataforma
PV O.A.
PV1 0
PV2 4
PV3 3
Se recibe TOBT Confirmada para el PV1

PV O.A.
PV1 5
PV2 4
PV3 3
Al llegar a asignar con O.A. 999:

PV O.A.
PV1 999
PV2 987
PV3 993
Se producirá un recálculo del orden de asignación:

PV O.A.
PV1 3
PV2 1
PV3 2
REQ - Los planes de vuelo sin TOBT, su campo ORDEN de ASIGNACIÓN estará vacío.
REQ - Existirá una herramienta que se ejecutará desde el SMDT, la cual generará un fichero denominado
los planes de vuelo que tienen asignado un orden, con el
siguiente formato: INDICATIVO ORIGEN DESTINO ORDEN_ASIGNACIÓN
2.5.3.6.1.1.2. Cambio de pista teniendo en cuenta el ORDEN DE ASIGNACION
REQ - Cuando se produzca un cambio de parámetros de aeródromo INMEDIATO o PROGRAMADO, el orden de

asignación de la pista de despegue a los planes de vuelo con TOBT afectados se realizará en orden creciente de
COM - De esta forma se establece un orden de entrada en secuencia teniendo en cuenta las últimas
modificaciones de TOBT.
2.5.3.6.1.1.3. Cambio programado en base a TOBT / EOBT
REQ - Para planes de vuelo sin CTOT, un cambio de parámetros de aeródromo programado cambiará la pista de
despegue teniendo en cuenta:
- Si el plan de vuelo tiene TOBT valida (diferente de estado Invalido o Provisional), deberá cumplir que TOBT
+ EXOT sea mayor o igual que la hora de inicio del cambio programada.
- Si el plan de vuelo no tiene TOBT o su estado no es válido, deberá cumplir que EOBT + EXOT sea mayor o
igual que la hora de inicio del cambio programada.
COM - Ejemplo. Partiendo del siguiente ejemplo:
Elaborado: 14/04/16
Página: 66/201
Plataforma
PV EOBT TOBT/Estado EXOT EOBT+EXOT TOBT+EXOT

PV1 1000 1000 10 1010 1010
PV2 1000 -- 15 1015 1015
PV3 1005 1000/I 15 1020 1020
PV4 1007 -- 20 1027 1027
PV5 1010 1010 10 1020 1020
PV6 1000 0950 15 1015 1005
PV7 1010 1020/P 5 1015 1015
Si como hora de validez se edita: 1020, serían los vuelos PV3, PV4 y PV5 los que cambiarán de pista. El resto se
mantendrán en la pista anterior.
REQ - Si se
vuelo regulados,
- Si la TSAT del PV está calculada en base al CTOT, el cambio programado tendrá en cuenta el CTOT,
independientemente de la TOBT/EOBT. Solo en caso de que se cancele el CTOT, se replanteará la pista
teniendo en cuenta el requisito anterior.
- Si la TSAT del PV está calculada en base a la TOBT, se aplicará el requisito anterior.
REQ -
de vuelo regulados,
- el cambio programado tendrá en cuenta el CTOT, independientemente de la TOBT/EOBT. Solo en caso de
que se cancele el CTOT, se replanteará la pista teniendo en cuenta el requisito anterior.
REQ - En caso de que no exista stand asignado al plan de vuelo (no habría por tanto EXOT), el cálculo se realizará
en base al TaxiSACTA, que es el valor por defecto con el que se calcula la TSAT en estos casos.
COM - Se denomina EXOT al valor de TaxiStandPista definido en adaptación para ese stand y pista de despegue.
2.5.3.6.1.2. Registros históricos
REQ - Cada vez que se modifique el ORDEN de ASIGNACION a un plan de vuelo, se generará un histórico con el
siguiente formato:
<fecha><hora> PV <indicativo-Origen-Destino> CAMBIO ORDEN ASIGNACION xxx /// xxx
Vuelo de Torre.
Elaborado: 14/04/16
Página: 67/201
Plataforma
2.5.3.7. SA#6597. CDM. No caducidad de PV con STS
2.5.3.7.1.1. GPVT
REQ - Cuando un plan de vuelo tenga STS (uno o más valores), si está secuenciado (tiene TSAT/TTOT), se
mantendrá en la misma sin caducar al superar TSAT +5minutos.
REQ - El requisito anterior se aplicará a los STS que actualmente tienen prioridad en la secuencia sobre pvs no
regulados: EMG(MEDEVAC), AMB (HOSP), EST (HEAD/STATE),HUM(HUM) y SAR (SAR).
REQ - En caso de que el vuelo tenga varios STS, con que uno de los STS sea EMG, AMB, EST,HUM o SAR, se
aplicará el requisito de no caducidad.
Vuelo de Torre.
2.5.3.8. SA#7135. CDM. No recalculo de TSAT si ASAT antes de TSAT
Los siguientes requisitos aplican para aeropuertos que operen como CDM.
2.5.3.8.1.1. GPVT
REQ - En el fichero de configuración PARAMETROS_CDM.TXT se definirá el parámetro RECALCULO_ASAT,
REQ -
REQ -
REQ -
plan de vuelo antes de TSAT (ASAT< TSAT), se recalculara el DTOT-r/DTOT del plan de vuelo, y por tanto no se
recalcularán los DTOT-r/TSAT-r del resto de la secuencia que se viesen afectados.
REQ -
plan de vuelo antes de TSAT (ASAT< TSAT), no se recalculara el DTOT-r/DTOT del plan de vuelo, y por tanto no se
recalcularán los DTOT-r/TSAT-r del resto de la secuencia que se viesen afectados, de forma que este vuelo tendrá
como DTOT-r/DTOT el que tuviese antes de anotar ASAT.
Vuelo de Torre.
Elaborado: 14/04/16
Página: 68/201
Plataforma
2.5.3.9. SA#8165. Funcionalidad en TWR con configuraciones de pistas
REQ - Los siguientes requisitos aplican para aeropuertos que operen como CDM y NO CDM.
2.5.3.9.1.1. TPVT
2.5.3.9.1.1.1. Nuevo campo “Orden de Asignación”
COM - COM- Existirá un nuevo campo con la idea de poder determinar el orden en el que se atendieron los
planes de vuelo y en base al cual se realizarán los recálculos de la secuencia.
REQ -
REQ -
REQ -
REQ - E
REQ -
COM - Ejemplo.
Partiendo de tres planes de vuelo, que se confirman en el siguiente orden: PV1, PV2 y PV3
PV O.A.
PV1 1
PV2 2
PV3 3
Se recibe TOBT Modificada para el PV2
PV O.A.
PV1 1
PV2 4
PV3 3
Se recibe TOBT Invalida para el PV1
PV O.A.
PV1 0
PV2 4
PV3 3
Se recibe TOBT Confirmada para el PV1
Elaborado: 14/04/16
Página: 69/201
Plataforma
PV O.A.
PV1 5
PV2 4
PV3 3
Al llegar a asignar con O.A. 999:
PV O.A.
PV1 999
PV2 987
PV3 993
Se producirá un recalculo del orden de asignación:
PV O.A.
PV1 3
PV2 1
PV3 2
2.5.3.9.1.1.2. Configuración de Pistas
REQ - Una configuración de pistas en adaptación se definirá con los siguientes posibles campos:
 Nombre de Configuración
 Pistas de Despegue
 Capacidades para las pistas de despegue
 Pistas de Arribada
REQ - Para las pistas de despegue definidas para una determinada configuración de pistas, se podrán adaptar
opcionalmente tiempos de taxi stand-pista, aplicables únicamente a esa configuración
REQ - En caso de que no se definan tiempos de taxi stand-pista, se aplicarán los tiempos de taxi stand pista por
defecto.
2.5.3.9.1.1.3. Descripción de la Ventana de Parámetros de Aeródromo
REQ -
Configuraciones Pistas definidas en la adaptación local de la dependencia de Torre, tanto para un cambio
programado como para cambio inmediato
REQ - Cuando se selecciona un cambio de pistas con una configuración de pistas, los campos de pistas de
despegues y arribadas de la Ventana de Parámetros de Aeródromo, se deberán rellenar con las pistas que tenga
definidas en la adaptación dicha configuración.
COM - Ejemplo: Se selecciona PROGRAMAR, se introduce la HORA VALIDEZ 1200. A continuación, se selecciona
utomáticamente las pistas de despegue y arribada según lo
definido en la Tabla del punto 1 (ver imagen de la ventana):
Pista Desp 1 : 25L
Pista Desp 2: blanco
Pista Arr1: 25R
Pista Arr2: blanco
Elaborado: 14/04/16
Página: 70/201
Plataforma
REQ - Para hacer un cambio de pistas, no será obligatorio seleccionar la configuración de pistas, se pueden seguir
editando las pistas como en la funcionalidad en servicio.
2.5.3.9.1.1.4. Descripción de la Ventana de Configuración de Capacidades de aeródromo
REQ - sin título y no editable, que se rellenará

con el nombre de la configuración de pistas (adaptada) seleccionada previamente en la ventana de Parámetros
de Aeródromo.
REQ - Cuando se selecciona la configuración de pistas en la parte inmediata de la ventana de Cambio de

Parámetros de Aeródromo, al Ejecutar dicha configuración, se rellenará automáticamente la casilla de la parte de
REQ - Existirá una nueva zona en la Ventana de Configuración de Capacidades de aeródromos denominada
parámetros de aeródromo basado en configuraciones de pistas. La información presentada será:

- Casilla no editable en la que se presentará el nombre de la configuración de pistas seleccionada en la
VAEROD
- Hora de Validez: no editable. Se mostrará la hora editada en la VAEROD
- Pistas de despegue de la configuración.
- Capacidad adaptada para cada una de las pistas de despegue de la configuración. Será un campo
editable.
REQ -
2.5.3.9.1.1.5. Comportamiento de la secuencia teniendo en cuenta cambios de parámetros de aeródromo

con configuración de pistas
2.5.3.9.1.1.5.1. Cambio de parámetros de aeródromo PROGRAMADO seleccionando configuración de pistas
REQ - Cuando se ejecute un cambio programado de parámetros de aeródromo seleccionando una configuración
de pistas, en la Ventana de Parámetros de Aeródromo:
- se presentarán la/s pista/s de despegue y arribada definidas en adaptación para dicha configuración
Elaborado: 14/04/16
Página: 71/201
Plataforma
- se deberá rellenar el campo Hora Validez.
REQ - Si se introducen manualmente en la Ventana de Parámetros de Aeródromo, los valores de los campos
en el desplegable se presentará la configuración correspondiente de modo automático.
COM - Se entenderá como cambio programado de parámetros de aeródromo basado en configuración de pistas,
tanto si se ha seleccionado la configuración desde el desplegable directamente como si se han editado pistas
que coinciden con una configuración adaptada.
REQ - Cuando se ejecute un cambio programado de parámetros de aeródromo basado en configuración de

pistas, en la Ventana de Configuración de Capacidades de Aeródromo, en la parte de Configuración Programada,
se presentarán:
- las pistas de despegue definidas en la configuración de la ventana de parámetros de aeródromo junto
con la capacidad.
- Hora de Validez introducida en la VAEROD para el cambio programado
Se actualizará la casilla de la configuración de pistas de la parte de Configuración Programada, con el nombre de
la configuración en VAEROD.
REQ - Los planes de vuelo afectados por el cambio de pista serán:

- si implementada la UCR SA#4982. MODIFICACIÓN AL CAMBIO PROGRAMADO DE AERODROMOS PARA
CDM: requisitos descritos en dicho documento correspondiente.
- Si no implementada la UCR SA#4982, se aplicarían los requisitos actualmente en servicio:
MODO CDM/NO CDM: PVs cuya Hora Validez es superior a ETOT (=EOBT+ TaxiTime)
REQ - Cuando se ejecute un cambio programado de parámetros de aeródromo basado en una configuración de
pistas,
- el orden en el que los planes de vuelo irán cambiando de pista será el establecido por el campo ORDEN
de ASIGNACION.
- Se buscará un hueco para el plan de vuelo en la nueva secuencia teniendo en cuenta la TOBT, criterios de
prioridad, además de los datos definidos en la adaptación para dicha configuración de pistas:
 EXOT para el stand-pista
 capacidad de la pista
- A partir del DTOT-R, se calculará su TSAT (modo CDM) o HPMD (modo NO CDM).
REQ - Debido al recalculo completo de la secuencia por las nueva/s pista/s, hasta que no finalice el recalculo de
todos los planes de vuelo, no se enviarán TSAT/TTOT a la plataforma CDM.
REQ - Cuando la Hora de inicio se iguale a la hora de validez:

-
-
o
o Se actualizará la/s capacidad/es de despegue/s correspondiente/s a la/s pista/s de
despegue/s definidas en la configuración de pistas.
REQ - Si hubiese alguna capacidad en la zona de Capacidades de Aeródromo definida que coincida con las pistas
de la configuración implantada desde la VAEROD, prevalecerá la correspondiente a la nueva configuración. Se
presentará un mensaje de confirmación.
Elaborado: 14/04/16
Página: 72/201
Plataforma
REQ - En el caso en el que la Hora de Inicio es anterior a la Hora de Validez, de forma que se modifica la
zona), se recalcularán los vuelos afectados teniendo en cuenta la hora de Validez y los datos adaptados para
dicha configuración.
REQ - En el caso en el que la Hora de Inicio es anterior a la Hora de Validez, cuando se ejecute la
desprogramación de la configuración de pistas desde la ventana de parámetros de aeródromo:
- En la ve
- Se producirá el recalculo de la secuencia teniendo en cuenta:
o La capacidad establecida en la parte de Capacidades de Aeródromo
o El orden de asignación
todos los planes de vuelo afectados por el cambio, no se enviarán TSAT/TTOT a la plataforma CDM ni se
procesarán mensajes nuevos.
2.5.3.9.1.1.5.2. Cambio de parámetros de aeródromo PROGRAMADO sin seleccionar configuración de pistas
REQ - El comportamiento del sistema será el actualmente en servicio.
2.5.3.9.1.1.5.3. Cambio de parámetros de aeródromo INMEDIATO seleccionando configuración de pistas
REQ - Cuando se ejecute un cambio inmediato (con o sin T) de parámetros de aeródromo seleccionando una
configuración de pistas, en la Ventana de Parámetros de Aeródromo se presentarán la/s pista/s de despegue y
arribada definidas en adaptación para dicha configuración
REQ - Cuando se ejecute un cambio inmediato (con o sin T) de parámetros de aeródromo seleccionando una
configuración de pistas, en la ventana de Configuración de Capacidades de Aeródromo,, se presentará para cada
pista de despegue definida en la configuración seleccionada:
 Capacidad: capacidad definida en adaptación para las pistas de despegue
 Se actualizará la casilla de la configuración de pistas de la parte de Capacidades, con el nombre de la
configuración seleccionada en VAEROD.
REQ - Si se introducen manualmente en la Ventana de Parámetros de Aeródromo, los valores de los campos
en el desplegable se presentará la configuración correspondiente de modo automático.
COM - Se entenderá como cambio inmediato de parámetros de aeródromo basado en configuración de pistas,
tanto si se ha seleccionado la configuración desde el desplegable directamente como si se han editado pistas
que coinciden con una configuración adaptada.
REQ - Los planes de vuelo afectados por el cambio de pista serán:

- si implementada la UCR SA#4982. MODIFICACIÓN AL CAMBIO PROGRAMADO DE AERODROMOS PARA
CDM: requisitos descritos en dicho documento correspondiente.
- Si no implementada la UCR SA#4982, se aplicarían los requisitos actualmente en servicio para el cambio
de parámetros inmediato.
COM - Los planes de vuelo afectados por un cambio de parámetros de aeródromo con o sin T no varía con
respecto a lo actualmente en servicio:
Elaborado: 14/04/16
Página: 73/201
Plataforma
- Con T: afectados todos los planes de vuelo

- Sin T: solo afectados a los planes de vuelo sin autorizaciones o con solicitud de puesta en marcha
REQ - Cuando se ejecute un cambio inmediato sin o con T de parámetros de aeródromo basado en una
configuración de pistas,
- el orden en el que los planes de vuelo irán cambiando de pista tendrá en cuenta el valor del campo
ORDEN de ASIGNACION.
- Se buscará un hueco para el plan de vuelo en la nueva secuencia teniendo en cuenta la TOBT, criterios de
prioridad, además de los datos definidos en la adaptación para dicha configuración de pistas:
 EXOT para el stand-pista
 capacidad de la pista
- A partir del DTOT-R, se calculará su TSAT (modo CDM) o HPMD (modo NO CDM).
todos los planes de vuelo afectados por el cambio, no se enviarán TSAT/TTOT a la plataforma CDM ni se
procesarán mensajes nuevos.
REQ - Si hubiese alguna capacidad definida que coincida con las pistas de la configuración implantada desde la
VAEROD, prevalecerá la correspondiente a la nueva configuración. Se presentará un mensaje de confirmación.
2.5.3.9.1.1.5.4. Cambio de parámetros de aeródromo INMEDIATO sin seleccionar configuración de pistas
REQ - El comportamiento del sistema será el actualmente en servicio.
2.5.3.9.1.2. SPV
COM - Se propone modificar la ventana actualmente operativa por la siguiente:

A) Si esta implementada la UCR SA#4563:
Elaborado: 14/04/16
Página: 74/201
Plataforma
B) Si no está esta implementada la UCR SA#4563:
REQ -
- Casilla no editable en la que se presentará el nombre de la configuración de pistas seleccionada en la
VAEROD
- Hora de Validez: campo horario no editable. Se presentará la Hora de Validez editada en la VAEROD.
- Pista/s de despegue de la configuración de pista seleccionada en la VAEROD
- Capacidad/es adaptada/s para cada una de las pistas de despegue de la configuración. Será un campo
editable.
REQ - El SMDT guardará en memoria la configuración vigente antes de la parada, de modo que tras un arranque
de servidor con datos, el SMDT pueda mostrar dicha configuración.
COM - Se aceptará que si hay alguna configuración programada, ésta no se almacenara.
REQ - Tras un arranque de sistema o de tándem SMDT la configuración de pista deberá ser recuperadas y
mostrarse en la pantalla.
REQ - la zona de
es al cambio de parámetros de aeródromos
programado con configuración de pistas.
Elaborado: 14/04/16
Página: 75/201
Plataforma
REQ - se mostrará los datos

correspondientes a la configuración de pistas.
REQ - La casilla desple
selecciona dicho valor vacío las casillas dependientes del valor de
REQ - Si se selecciona una configuración de pistas del desplegable, los campos correspondientes a las pistas no
serán editables/modificables manualmente.
2.5.3.9.1.3. GEODESYS
REQ - En el (BDAP > Funcionalidad TPVT > Configuración

Superficie Aeródromo Asociado), se podrá definir por cada configuración de pistas:
- Dos pistas de despegue . Los campos se denominarán :
Pista de Despegue 1
Pista de Despegue 2
- Dos pistas de arribada . Los campos se denominarán :
Pista de Arribada 1
Pista de Arribada 2
REQ - Serán datos obligatorios como mínimo una pista de despegue y una de arribada por cada Conf. Pistas de
Interés.
REQ -
REQ - Se considerarán iguales aunque el orden de las pistas sea diferente.
REQ - A la Configuración de pistas por Defecto, también se le añadirán los cuatro campos, siendo igualmente
necesario indicar al menos una pista de arribada y otra de despegue por defecto.
REQ - Deberán existir además dos campos más por cada Configuración de Pista referidos a las Capacidades de
Despegue. Los campos se denominarán:
Capacidad de despegue de la pista 1
Capacidad de despegue de la pista 2
REQ - Las capacidades definidas para cada pista en este Mantenimiento prevalecerán sobre las definidas en el
NOTA. La capacidad no será un dato obligatorio.
REQ - Los campos de Capacidades de Pistas de Despegue incluidos en la ventana de Configuración de Pista
admitirán valores de 0 a 99 vuelos/hora.
REQ - Se deberá permitir definir hasta una máximo de 30 Configuraciones de Pistas de Interés.
REQ - En el d- (BDAP > Funcionalidad TPVT > Configuración

Superficie Aeródromo Asociado) se añadirá una nueva columna denominada Configuraciones de Pista.
Elaborado: 14/04/16
Página: 76/201
Plataforma
d
Pista seleccionada.
REQ - Con la implementación de esta PCI se deberán mantener todos los tiempos Taxi Stand-Pista asociados a
cada Pista ya existentes en la tabla. Estos valores serán visibles pulsando una nueva opción denominada
- REQ - Los Tiempos de Taxi Stand-Pista por Defecto podrán ser
modificados, borrados o creados.
REQ - A la hora de añadir una nueva Configuración podremos elegir de entre todas las definidas en el
REQ - Para insertar los Tiempos de Taxi Stand-Pista de la pista seleccionada (botón derecho Añadir o link en
Tiempos de Taxi Stand/Pista) nos permitirá seleccionar de una ventana auxiliar los Stands y sus Taxi Stand-Pista
asociados de entre todos los definidos por Defecto.
Todos ellos podrán ser modificados posteriormente, prevaleciendo los nuevos valores a los definidos por defecto.
Es decir, todos los Tiempos de Taxi Stand-Pista implementados en esta ventana serán prioritarios a los definidos
por Defecto.
REQ - Todos los Tiempos de Taxi Stand-Pista podrán ser modificados, borrados o creados y cada Pista podrá
tener diferentes tiempos dependiendo de la Configuración a la que pertenezca.
REQ - Cuando se cree un nuevo Stand en el Mantenimient

-
obligatorio definir el tiempo para ese Stand.
REQ - Cuando se realice un cambio de parámetros de aeródromo (inmediato o programado) basado en

configuración de pistas se generará:
- El Registro histórico actual de cambio de parámetros de aeródromo añadirá el valor del campo
- El Registro histórico actual de capacidades con configuración programada, mostrará, además, el valor del
2.5.3.9.1.5. Requisitos DE TOLERANCIA A FALLOS
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Consulta de Histórico de
Planes de Vuelo en los distintos entornos operacionales.
Vuelo de Torre.
Elaborado: 14/04/16
Página: 77/201
Plataforma
2.5.3.10. SA#8181. No actualización de EOBT por mensaje SLC
2.5.3.10.1.1. TPV
REQ - Cuando se reciba un mensaje de cancelación de CTOT (SLC), la EOBT del plan de vuelo no deberá
actualizarse con la hora de recepción de dicho mensaje (SLCT), manteniéndose la EOBT que tuviese el plan de
vuelo antes de la recepción del mensaje SLC.
2.5.3.10.1.2. REQUISITOS DE TOLERANCIA A FALLOS
Vuelo de Torre.
2.5.3.11. SC#11773. Implementación de la interfaz SACTA-CDM
REQ - Dentro del sistema SACTA, la interfaz con CDM estará ubicada como un servicio más proporcionado por la
funcionalidad TPVT.
2.5.3.11.1.1. Comunicaciones y supervisión
2.5.3.11.1.1.1. Pila de protocolos
REQ - La interfaz física entre SACTA y CDM será mediante Par trenzado (10 Base T), a través de firewalls.
REQ - El protocolo del nivel de enlace será Ethernet, conforme IEEE 802.3 [4].
REQ - El protocolo del nivel de red será IP, conforme RFC 791[3].
Nota : Las direcciones IP unicast necesarias para la comunicación SACTA - CDM estarán definidas, para sus tres
primeros octetos, en el documento RDN_IP_031127 Plan de Numeración IP de Redes conectadas con REDAN [6]
y, para el cuarto octeto, en los documentos, actualmente en redacción, Plan de Numeración IP de Redes SACTA
III.5 [8] y Plan de numeración IP de Redes SCEnA [9].
REQ - El protocolo del nivel de transporte será TCP, conforme RFC 793 [2].
Elaborado: 14/04/16
Página: 78/201
Plataforma
2.5.3.11.1.1.2. Fichero de configuración
REQ - Existirá un fichero de configuración, propio del procesador donde se ejecuta la interfaz con CDM, en el que
se especificarán las distintas variables necesarias para la configuración del protocolo de comunicaciones entre
SACTA y CDM.
2.5.3.11.1.1.2.1. Variables del fichero de configuración
REQ - El interfaz de envío y recepción de datos será configurable mediante un parámetro en el fichero de
configuración PARAMETROS_CDM.TXT, del TPVT, denominado TIPO_INTERFAZ, con valores:
a. se leerá y procesará el actual fichero
generado por SCENA . No se procesará ni enviará ningún mensaje XML.
b.
basado en el protocolo XML definido en este documento.
REQ - Aunque inicialmente está previsto que SACTA siempre sea cliente y CDM servidor, esto podrá cambiarse
mediante el uso de la variable SACTAClient . Esta variable puede tomar los valores CLIENTE y SERVIDOR y, por
defecto valdrá CLIENTE . Esta variable se considera opcional, y, de no estar definida, se le adjudicará el valor por
defecto.
REQ - La dirección IP del servicio CDM se configurará a través de la variable IPDir , que será una variable IPv4 en
formato numérico. Esta variable es obligatoria, y no tiene un valor por defecto.
REQ - Las variables PortTx (para transmitir) y PortRx (para recibir) definirán los puertos necesarios para la
comunicación entre SACTA y CDM. Ambas variables serán números enteros. Estas variables son obligatorias, no
existirá valor por defecto.
REQ - Los identificadores de usuario necesarios para la comunicación entre SACTA y CDM estarán definidos por
las variables UsOri (para la identificación del usuario origen) y UsDst (para la identificación del usuario destino).
REQ - El tamaño del buffer de mensaje de datos estará definido mediante la variable TamBuf y será un número
entero positivo mayor que cero, que representa el total de mensajes a almacenar. Esta variable es opcional, y, de
no aparecer en el fichero, tomará por defecto el valor 60.000 mensajes.
Nota : Este buffer se define para almacenar los datos que vayan a ir enviando para que, en caso de ser requeridos,
se puedan volver a enviar. El buffer será una estructura circular, de modo que cuando se llene, se comiencen a
sobreescribir los datos más antiguos que hubiera almacenados.
REQ - El tiempo máximo de espera de recepción de ACK antes de finalizar la conexión de datos se definirá a
través de la variable TMaxACK y será un número entero positivo mayor que cero representando milisegundos.
Esta variable es obligatoria y no tendrá un valor por defecto.
REQ - El tiempo máximo de espera antes de cortar la comunicación ante falta de presencia vendrá dado por la
variable TMaxWait y será un número entero que representa segundos. Esta variable es opcional, de no aparecer
en el fichero tomará por defecto el valor 30 segundos.
Elaborado: 14/04/16
Página: 79/201
Plataforma
Nota : Por la propia definición del sistema de comunicaciones, el valor máximo que podrá tomar la variable
TMaxWait será 120 segundos, ya que transcurrido un periodo superior de tiempo se cerrará el socket.
REQ - El periodo de envío de mensajes de presencia en ausencia de datos se definirá a través de la variable
TPeriod y será un número entero que representa segundos. Esta variable es obligatoria, no existirá un valor por
defecto.
REQ - Siempre se ha de cumplir que TPeriod < TMaxWait , de lo contrario ambas variables se considerarán no
válidas.
REQ - Siempre se ha de cumplir que TMaxACK < TPeriod , de lo contrario ambas variables se considerarán no
válidas.
REQ - Cuando el chequeo de las variables definidas en el fichero produzca un error, el servicio quedará
desactivado (además, se debería poder detectar la variable que no tiene un valor correcto).
2.5.3.11.1.1.2.2. Parámetros funcionales del fichero de configuración
REQ - En el fichero de configuración PARAMETROS_CDM.TXT se definirán los siguientes parámetros:

 PCDM1
 PCDM2
 ASAT_VALIDITY_TIME
Actualmente, estos parámetros se encuentran definidos como variables de entorno en

fs_gen_def_entorno.local, con la implementación de esta CP pasarán a definirse únicamente en el fichero de
configuración PARAMETROS_CDM.TXT.
REQ - Existirán dos parámetros de configuración en el fichero PARAMETROS_CDM.TXT que aplicarán a la

mensajería enviada a través del protocolo XML:
 UMBRAL_MENSAJES_PVS_DESPEGUE: Se definirá en segundos. Cuando alguno de los campos

horarios definidos en los mensajes enviados para PVs de Despegue (CREAC, PREAC, CDM, DEICE, etc)
supere el umbral definido en esta variable con respecto al último valor enviado, se enviará el mensaje,
en caso contrario, no se generará el envío.
 UMBRAL_MENSAJES_PVS_ARRIBADA: Se definirá en segundos. Cuando alguno de los campos

horarios definidos en los mensajes enviadosS para PVs de Arribada (ARR, FIN, SEC) supere el umbral
definido en esta variable con respecto al último valor enviado, se enviará el mensaje, en caso
contrario, no se generará el envío.
Por defecto, el valor de ambos parámetros será 60 segundos.
2.5.3.11.1.1.3. Tipos de Mensaje
REQ - Mensaje de petición de carga. Se enviará por cualquiera de los dos sistemas para solicitar al otro una
carga de datos. Se enviará a través del socket de emisión de datos. Tendrá el siguiente formato y contenido:
CAMPO CONTENIDO TAMAÑO

USUARIO ORIGEN SACTA o CDM 5 caracteres
USUARIO DESTINO SACTA o CDM 5 caracteres
Elaborado: 14/04/16
Página: 80/201
Plataforma

TIPO DE MENSAJE CARGA 5 caracteres
NÚMERO DE SECUENCIA 8 caracteres
LONGITUD STRING 9 caracteres
HORA Con precisión de hasta milésimas de segundo. 15 caracteres
DATOS XML definido por el GT Indefinido.
Diagrama de secuencia para el mensaje de petición de carga:
Nodo1 Nodo2
Mensaje de Petición de Carga
REQ - Mensaje de test. Un sistema lo enviará para mantener informado al otro de su presencia. Se enviará
indistintamente por los sockets de emisión y recepción de datos cuando el periodo de ausencia de tráfico por
cualquiera de ellos sea igual a TPeriod segundos. Tendrá el siguiente formato y contenido:

TIPO DE MENSAJE TEST 5 caracteres
Diagrama de secuencia para el mensaje de test:
Nodo1 Nodo2
Mensaje de Test t
Mensaje de ACK
Mensaje de Test t + TPeriod
Mensaje de ACK
Elaborado: 14/04/16
Página: 81/201
Plataforma
REQ - Mensaje de ACK. Se enviará como respuesta ante la llegada de un mensaje de datos o de un mensaje de
test. Se enviará por el mismo socket por el que llegó el mensaje al que se está respondiendo. Tendrá el siguiente
formato y contenido:

TIPO DE MENSAJE ACK 5 caracteres
Diagramas de secuencia para el mensaje de ACK:

 Como respuesta a mensaje de Test:
Nodo1 Nodo2
Mensaje de Test
Mensaje de ACK
 Como respuesta a mensaje de Datos:
Nodo1 Nodo2
Mensaje de Información CDM
Mensaje de ACK
Elaborado: 14/04/16
Página: 82/201
Plataforma
REQ - Mensaje de datos. Este mensaje se enviará por cualquiera de los dos sistemas. Podrá mandarse como
respuesta a la recepción de un mensaje de petición de carga, o bien ante un cambio en los datos que sea
necesario transmitir al otro sistema. Se enviará siempre por el socket de transmisión de datos. Tendrá el
siguiente formato y contenido:

TIPO DE MENSAJE INFO 5 caracteres
DATOS XML definido por el GT Indefinido.
 Diagrama de secuencia para el mensaje de información CDM:
Nodo1 Nodo2
Mensaje de Petición de Carga (opcional)
Mensaje de Información CDM
REQ - Si un campo de la cabecera del mensaje tiene un tamaño inferior al máximo definido, se procederá a
rellenar con caracteres en blanco dicho campo hasta alcanzar el tamaño establecido.
REQ -
Minuto (2 caracteres) Segundo (2 caracteres) Décimas de segundo (1 carácter) Centésimas de segundo (1 carácter)
Milésimas de segundo (1 carácter).
REQ - El campo DATOS definido en los mensajes de Información CDM y de Petición de Carga será una estructura
XML en texto plano. Dicha estructura será la definida previamente por el Grupo de Trabajo, tal y como se muestra
en los siguientes ficheros adjuntos.
COM - Esquemas:
Elaborado: 14/04/16
Página: 83/201
Plataforma
FlightPlan
FlightData
Elaborado: 14/04/16
Página: 84/201
Plataforma
AirportResources (dentro de FlightData)
Dates
Elaborado: 14/04/16
Página: 85/201
Plataforma
Deice
CDMFlightInfo.xsd CDM_CommonTypes. DateCDM.xsd CDMInfoRQ.xsd

xsd
(Estos ficheros se visualizan con Internet Explorer)
2.5.3.11.1.1.4. Funcionamiento del protocolo
REQ - SACTA siempre se conectará como cliente, y CDM siempre actuará como servidor de datos. Este
comportamiento se podrá modificar mediante el uso de la variable SACTAClient definida en el fichero de
configuración.
Nota : El protocolo de comunicaciones exige que uno de los extremos actúe como Servidor y el otro como Cliente.
Estos dos roles se fijarán únicamente para realizar la conexión inicial, por lo que a lo largo del diálogo, tanto el
cliente como el servidor serán capaces de realizar peticiones de datos y responder a ellas, o enviar datos ante un
cambio de los mismos.
REQ - Tanto SACTA como CDM podrán pedir al otro sistema carga de datos.
REQ - Para establecer la comunicación entre SACTA y CDM se hará uso de dos sockets: uno de transmisión de
datos y otro de recepción.
REQ - De manera excepcional, se permitirá transmitir los mensajes de test (ó presencia) y ACK por el socket de
recepción de datos, además de por el de transmisión, cuando así se requiera.
Nota : Esto es únicamente para poder responder con un ACK al mensaje de test recibido, usando el mismo socket.
Elaborado: 14/04/16
Página: 86/201
Plataforma
REQ - Cuando no se tenga información que mandar durante un periodo igual a TPeriod segundos, se enviará una
presencia (mensaje Test) al otro sistema. A cada mensaje de Test recibido, se contestará por el mismo socket con
un ACK al sistema originador.
REQ - Por cada mensaje de información que se envíe, el originador esperará a recibir confirmación (ACK) desde el
receptor antes de enviar el siguiente mensaje.
REQ - Los mensajes de datos estarán definidos por un número de secuencia y una marca de tiempo.
Nota : La capa de comunicaciones tendrá sus propios números de secuencia para la monitorización de mensajes,
y estos números serán independientes de los números de secuencia que los propios datos transmitidos en el
mensaje (en formato XML) puedan llevar.
REQ - Todos los mensajes enviados sumarán una unidad en el número de secuencia.
REQ - Los mensajes que se hayan transmitido se irán almacenando en un buffer de envío, para que puedan ser
reenviados ante una petición de carga.
REQ - En el buffer de envío sólo se almacenarán mensajes de datos, en ningún caso se almacenarán los
mensajes de Test, petición de carga o ACK.
REQ - Al enviar un mensaje, el emisor pondrá en funcionamiento un Timer de recepción. Si transcurrido

TMaxACK segundos no se ha recibido por parte del receptor la confirmación de su recepción (ACK), se procederá a
cortar la conexión, y a volverla a establecer.
REQ - Ante la llegada de cualquier mensaje no esperado (el tipo de la cabecera sea desconocido, o un ACK
inesperado), se procederá a cortar la conexión.
REQ - Las peticiones de carga deberán ser de alguno de los siguientes tipos:
 Por número de secuencia : Se enviarán (cuando se responda a una petición de este tipo) o se
solicitarán (cuando queramos solicitar datos) todos los mensajes encolados en el buffer a partir del
número de secuencia indicado en el mensaje de petición de carga.
 Todo lo almacenado : Se enviarán (cuando se responda a una petición de este tipo) o se solicitarán
(cuando queramos solicitar datos) todos los mensajes que se tuvieran encolados en el buffer.
 Limpieza de buffer : Se le indica al emisor que borre todo lo encolado en el buffer. (Se implementarán
las acciones a realizar al recibir una petición de carga de este tipo, pero SACTA no enviará nunca este
tipo de peticiones.)
 Fecha y Hora : se enviarán (cuando se responda a una petición de este tipo) o se solicitarán (cuando
queramos solicitar datos) todo lo que se tenga (en el buffer) desde una determinada fecha y hora
hasta el momento actual.
REQ - Al establecerse una conexión, el sistema que actúe como cliente deberá pedir al servidor una petición de
carga de datos (esta información vendrá especificada dentro del XML enviado como campo de datos).
REQ - SACTA, por defecto, al establecer una nueva conexión, realizará una petición de carga por número de
secuencia, a partir del último número que SACTA hubiera recibido en una comunicación anterior.
REQ - En caso de no tener acceso al número de secuencia, la petición de carga que realizará SACTA por defecto
Elaborado: 14/04/16
Página: 87/201
Plataforma
REQ - Cualquiera de los dos sistemas podrá realizar una petición de carga (de alguno de los tipos indicados
anteriormente) al otro sistema en cualquier momento.
REQ - Si, mientras se está atendiendo a una petición de carga de datos llega otro mensaje de petición de carga,
se descartará éste último.
REQ - Para informar de la presencia, se enviará cada TPeriod segundos por parte del sistema origen en unicast
un mensaje de test hacia el sistema destino cuando no exista tráfico de datos entre ellos. Si pasados TMaxWait
segundos, el sistema destino no recibe ningún mensaje de presencia del sistema origen, el sistema destino
procederá a terminar la conexión, y volverla a establecer inmediatamente.
2.5.3.11.1.1.4.1. Ejemplos de funcionamiento del protocolo SACTA CDM
a. Comunicación Normal
Nodo1 Nodo2
Mensaje petición de carga

Mensaje de información
CDM
Mensaje de ACK
TPeriod
TPeriod
Mensaje de Test
Mensaje de ACK
Mensaje de Test
Mensaje de ACK
TPeriod
TPeriod
Mensaje de Test
Mensaje de ACK
Mensaje de Test
Mensaje de ACK
Mensaje de información
CDM
Mensaje de ACK
Elaborado: 14/04/16
Página: 88/201
Plataforma
b. Fallo por no recepción de ACK
Nodo1 Nodo2
Mensaje de información CDM
TMaxWait
Cierre de comunicaciones
Mensaje de información CDM
Mensaje de ACK
2.5.3.11.1.2. PSI y monitorización
REQ - Sólo podrá existir enlace SACTA-CDM en aquellas torres que dispongan de TPVT.
REQ - La monitorización del estado del enlace SACTA-CDM se hará a través de la PSI en el escenario donde esté
ubicada la funcionalidad TPVT.
REQ - Se representará el enlace SACTA-CDM mediante una caja, conectada al servidor a través de la línea
correspondiente al LAN de usuario.
REQ - En el interior de la caja que representa al enlace SACTA-CDM se pintarán otras dos cajas, denominadas Tx
y Rx, que representarán, respectivamente, el socket de transmisión de datos y el socket de recepción de datos
(desde el punto de vista de SACTA).
REQ - La monitorización del enlace SACTA-CDM se hará de acuerdo a la siguiente tabla:
Elaborado: 14/04/16
Página: 89/201
Plataforma
Azul Verde Rojo Rojo intermitente

Socket de mensajes
Socket de mensajes Socket de mensajes
salientes no
salientes conectado salientes a fallo
Enlace SACTA-CDM no disponible
definido Socket de mensajes
Socket de mensajes Socket de mensajes
entrantes no
entrantes conectado entrantes a fallo
disponible
REQ -
ha desconectado de forma ordenada, sin que haya habido ningún fallo de comunicaciones, es decir, por timeout.
REQ - Cuando se pierda o se recupere la conexión en alguno de los dos sockets, se notificará a la PSI para que
ésta pueda pintar correctamente el estado del enlace SACTA-CDM.
REQ - Se permitirá habilitar o deshabilitar el enlace entre SACTA y CDM desde la PSI, para ello, al seleccionar con
el botón derecho en la caja que representa el enlace SACTA-CDM aparecerá una opción en el menú denominada
como de envío de datos estén disponibles. En cualquier otro caso, la opción aparecerá en vídeo débil.
NOTA: Esto solo será posible si el tipo de interface es XML. Si el tipo de interface es FTP este enlace estará
siempre deshabilitado.
REQ - Cuando el enlace SACTA-

no se enviará mensaje alguno a CDM.
REQ - Cuando el enlace SACTA- Deshabilitar enlace

con
REQ - La habilitación/deshabilitación del enlace CDM es a nivel lógico, es decir, el enlace físico ha de seguir
manteniéndose vivo, por lo que se seguirán procesando y enviando los mensajes de presencia oportunos.
REQ - La interfaz SACTA-CDM llevará una cuenta del total de mensajes enviados y recibidos, así como del tipo de
cada uno de ellos, desde la última reconexión. Esta información estará disponible para la PSI en cualquier
instante.
REQ - Al presionar con el botón derecho en el interior de la caja que representa el enlace SACTA-CDM, se
-
este texto se mostrará una ventana con las estadísticas correspondientes.
REQ - Si el estado del enlace SACTA-CDM es inactivo (azul), al presionar con el botón derecho en la caja que
representa el enlace, el texto para la presentación de estadísticas aparecerá en vídeo débil y no será posible
acceder al elemento.
REQ - Las estadísticas se resetearán con cada reconexión del sistema, y, además, a las 0:00.
REQ - -
 Fecha de la última reconexión.
Elaborado: 14/04/16
Página: 90/201
Plataforma
 Fecha del último mensaje recibido procesado.

 Peticiones de carga recibidas desde la última reconexión.
 Peticiones de carga enviadas desde la última reconexión.
 Número de mensajes de datos recibidos desde la última reconexión.
 Número de mensajes de datos enviados desde la última reconexión.
REQ - El aspecto de la ventana de estadísticas será el mostrado en la siguiente figura:
REQ -
pasar por ningún escenario de procesador.
REQ - Las estadísticas descritas anteriormente serán grabadas en GSI para su posterior explotación en
PALESTRA.
REQ - Será posible recuperar mensajes de la plataforma CDM desde la PSI a través de una ventana a la que se
botón derecho sobre la caja que representa el enlace SACTA-CDM en el escenario del procesador donde se ejecute
la funcionalidad CDM. Se podrán recuperar los mensajes desde una determinada fecha, estableciendo una fecha y
hora iniciales, pidiendo a CDM que nos envíe todos los mensajes desde ese momento hasta el presente.
REQ -
Elaborado: 14/04/16
Página: 91/201
Plataforma
REQ - El botón con el icono calendario desplegará en pantalla un calendario en el que se mostrará el mes en
curso (con posibilidad de desplazarse en el tiempo) para poder seleccionar de forma gráfica la fecha desde la que
se quieren recuperar los datos.
REQ -
correcto. En caso de encontrar algún campo no válido se informará de cuál es, y en caso de que todo esté correcto
también se informará.
REQ -
esté correcto mostrará un -
usuario. En caso de que éste de su OK, se comenzará con la petición de datos a CDM, en otro caso, se descartarán
los datos de búsqueda y se cerrará la ventana.
REQ - Si, una vez analizado los datos completados en la ventana de Petición de reenvío de Datos CDM, éstos son
correctos, pero se están recibiendo datos provenientes de una petición previa, se mostrará un mensaje indicando
esta contingencia y no se pedirán los datos. La ventana permanecerá abierta con los datos que se hubieran
puesto.
REQ - La petición a CDM de los datos seleccionados se realizará a través de un mensaje de Petición de Carga de
Datos.
REQ - ceder cuando estén disponibles tanto

el socket Rx como el socket Tx. En cualquier otro caso, la opción del menú que permite acceder a esta ventana se
mostrará en vídeo débil.
REQ - La petición de envío de datos generará un Registro Histórico en el que se indique el resultado de la
operación.
REQ - Cualquier cambio de estado en cualquiera de los dos sockets provocará la generación de un Registro
Histórico.
Elaborado: 14/04/16
Página: 92/201
Plataforma
REQ - Cuando el chequeo de las variables definidas en el fichero produzca un error, se generará el siguiente
de este Registro Histórico se mostrará información sobre la variable que produjo el fallo.
2.5.3.11.1.3. Mensajes enviados a través del interfaz XML
REQ - A través del nuevo interfaz basado en el XML, los mensajes enviados serán los relativos a los planes de
vuelo cuyo origen o destino sea un aeródromo de la dependencia.
REQ - Únicamente será posible el uso de esta interfaz en torres con servidor TPVT. Actualmente, esto aplica a los
aeródromos de LEMD, LEMG y LEBL.
REQ - Para todos los aeródromos (incluidos los mencionados previamente) la mensajería de plan de vuelo de
SACTA se seguirá enviando por el interfaz actual, GIPV.
2.5.3.11.1.3.1. Tipos de mensajes enviados desde Sistema Torre SACTA con TPVT
COM - En este apartado se listan los mensajes enviados a la Plataforma CDM desde el sistema de Torre SACTA.
Corresponden con los mensajes enviados actualmente desde el subsistema GIPV.
REQ - Los datos serán procesados como en la versión actualmente en servicio. Para el caso de información de
CDM,
 los datos enviados/recibidos actualmente (TOBT, estado TOBT, AOBT, ASRT, ASAT, TSAT, TTOT) serán
procesados con los mismos criterios que actualmente.
 el tratamiento de los datos relativos a deshielo, ha sido acordado en las reuniones del Grupo de
Trabajo CDM y se indicará en el documento de requisitos de usuario de SACTA correspondiente, UCR
SA#4427.
2.5.3.11.1.3.1.1. Definición de mensajes enviados a la Plataforma CDM
REQ - Para cada mensaje se enviará:



a. CREAC
b. PREAC
c. PUSH
d. TAXI
e. CHGDS
f. PTRDE
g. PTRAR
h. DEP
i. ARR
j. ASADT
k. CANPV
l. FIN
m. SEC
n. CDM
o. DEICE
Elaborado: 14/04/16
Página: 93/201
Plataforma

formada por:
a. INDICATIVO
b. IOBT
c. ORIGEN
d. DESTINO
e. IFPLID

REQ - En caso de que la creación del Plan de vuelo sea MANUAL,

a. En el campo IOBT se incluirá la EOBT editada en la creación del plan de vuelo.
b. El campo IFPLID estará vacío.
REQ -
REQ - Cuando en los mensajes se hace referencia al origen o destino SACTA del plan de vuelo, significa el/los
aeródromo/s (y sus sinónimos) origen o destino de la Dependencia del Sistema de Torre SACTA desde la cual se
establece la conexión TPVT-Plataforma CDM con el interfaz basado en el protocolo XML.
2.5.3.11.1.3.1.1.1. Tipo de Mensaje CREAC
REQ - Se enviará un mensaje CREAC, cuando:

- se cree un plan de vuelo cuyo origen o destino sea un aeródromo de la dependencia
- Se modifique la EOBT del plan de vuelo
- Siendo su estado pendiente, coordinado o preactivo,
con los siguientes datos:
 NUMERO DE AERONAVES
 TIPO DE AERONAVE
 EOBT
 ELDT
COM- Ejemplo para el mensaje CREAC:
<CdmFlightInfo Action="update" TimeStamp="19/02/2015 08:01:14.928" Source="PVT" Message="CREAC"

SequenceNmbr="8284274" xmlns="urn:aoml">
<CdmFlightInfo Action="update" TimeStamp="19/02/2015 08:01:14.928" Source="PVT" Message="CREAC"

<FlightID>
<FlightPlan>
Airline y Flight Number.
<Airline >IBE</Airline>
<Flight Number> 1234</ Flight Number>
<FlightDate urn:DateID="IOBT" xmlns:urn="urn:aoml">19/02/2015 08:45</FlightDate>
<DepartureAirport urn:CodeContext="OACI"
xmlns:urn="urn:aoml">LEMD</DepartureAirport>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LIRP</ArrivalAirport>
Elaborado: 14/04/16
Página: 94/201
Plataforma
<ifplID>AA39161656</ifplID>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="PVT" Message="CREAC">
<DateName>EOBT</DateName>
<DateValue>19/02/2015 08:45</DateValue>
<Result>commited</Result>
</CdmDate>
<DateName>ELDT</DateName>
</CdmDate>
<DateName> AircraftType</DateName>
<DateValue>A320</DateValue>
</CdmDate>
<DateName>NumberofAircrafts</DateName>
<DateValue>01</DateValue>
</CdmDate>
</Dates>
</CdmFlightInfo>
2.5.3.11.1.3.1.1.2. Tipo de Mensaje PREAC
REQ - Cuando se preactive un plan de vuelo cuyo origen sea un aeródromo de la dependencia SACTA, y su estado
sea PREACTIVO, se enviará un mensaje PREAC con los siguientes datos:
 Numero de Aeronaves
 Tipo de Aeronave
 ETOT
 CTOT
 PISTA DESPEGUE
2.5.3.11.1.3.1.1.3. Tipo de Mensaje PUSH
REQ - Cuando se solicite y/o se autorice push/back a un plan de vuelo cuyo origen sea un aeródromo de la
dependencia SACTA, se enviará un mensaje PUSH con los siguientes datos:
 APRT (Hora de Solicitud de PB)
 APAT (Hora de Autorización de PB)
Elaborado: 14/04/16
Página: 95/201
Plataforma
2.5.3.11.1.3.1.1.4. Tipo de Mensaje TAXI
REQ - Cuando se anote la autorización de rodadura a un plan de vuelo cuyo origen sea un aeródromo de la
dependencia SACTA, se enviará un mensaje TAXI con los siguientes datos:
 ATXT (Hora de Autorización de Rodadura )
2.5.3.11.1.3.1.1.5. Tipo de Mensaje CHGDS
REQ - Cuando el aeródromo destino de un plan de vuelo cuyo origen un aeródromo de la dependencia
(independientemente del estado de plan de vuelo) cambie su valor, se enviará un mensaje CHGDS con los
siguientes datos:
 DESTINO ANTIGUO
 ELDT
2.5.3.11.1.3.1.1.6. Tipo de Mensaje PTRDE
REQ - Cuando un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia, se le asigne o
modifique su pista de despegue, se enviará un mensaje CPTRDE con los siguientes datos:
 SID
 PISTA DE DESPEGUE
2.5.3.11.1.3.1.1.7. Tipo de Mensaje PTRAR
REQ - Cuando un plan de vuelo cuyo aeródromo destino sea un aeródromo de la dependencia, se le asigne o
modifique su pista de arribada, se enviará un mensaje CPTRAR con los siguientes datos:
 STAR
 PISTA DE ARRIBADA
2.5.3.11.1.3.1.1.8. Tipo de Mensaje DEP
REQ - Cuando un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia, se active en el
primer segmento, se enviará un mensaje DEP con los siguientes datos:
 ATOT
 CTOT
 PISTA DE DESPEGUE
2.5.3.11.1.3.1.1.9. Tipo de Mensaje ARR
REQ - Cuando un plan de vuelo cuyo aeródromo destino sea un aeródromo de la dependencia y su estado sea
ACTIVO, se enviará un mensaje ARR cuando
o se modifica el valor de la ELDT
o se activa el plan de vuelo en cualquiera de los segmentos del plan de vuelo
con los siguientes datos:
 NÚMERO DE AERONAVES
Elaborado: 14/04/16
Página: 96/201
Plataforma
 ELDT
 MLDT
2.5.3.11.1.3.1.1.10. Tipo de Mensaje ASADT
REQ - Cuando a un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia, se le asigne un
CTOT (mensaje SAM) o modifique su valor de CTOT (mensaje SRM o SLC), se enviará un mensaje ASADT con los
siguientes datos
 CTOT
 EOBT PISTA DE DESPEGUE
2.5.3.11.1.3.1.1.11. Tipo de Mensaje CANPV
REQ - Para un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia y su estado sea
Pendiente, Coordinado o Preactivo, cuando se termine en el primer segmento , se enviará un mensaje CANPV sin
datos.
2.5.3.11.1.3.1.1.12. Tipo de Mensaje FIN
REQ - Para un plan de vuelo cuyo aeródromo destino sea un aeródromo de la dependencia y su estado sea
Activo, cuando se produzca el paso por el ultimo fijo de la ruta (, se enviará un mensaje FIN con los siguientes
datos:
 ELDT
 MLDT
 ULTIMO FIJO
Nota : Este mensaje ya se envía desde el GIPV. Analizar cuánto complica el sistema enviarlo también desde el
sistema de torre.
2.5.3.11.1.3.1.1.13. Tipo de Mensaje SEC
REQ - Cuando un plan de vuelo cuyo aeródromo destino sea SACTA y su estado sea Activo, cuando se produzca
el paso por el antepenúltimo sector, se enviará un mensaje SEC con el dato de ELDT.
Nota : Este mensaje ya se envía desde el GIPV. Analizar cuánto complica el sistema enviarlo también desde el
sistema de torre.
2.5.3.11.1.3.1.1.14. Tipo de Mensaje CDM
REQ - Para un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia cuando se
asigne/modifique el valor de CTOT o se confirme el valor de TOBT, se enviará un mensaje CDM con los siguientes
datos:
Elaborado: 14/04/16
Página: 97/201
Plataforma
 TOBT
 ESTADO TOBT
 AOBT
 TSAT
 ASRT
 REA
 ASAT
 TTOT
 CTOT
 EXOT
 STAND
REQ - Para un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia cuando se produzca un
cambio en el valor en cualquiera de los siguientes campos:
 TSAT
 ASRT
 REA
 ASAT
 TTOT
 CTOT
 EXOT
Se enviará un mensaje CDM con los siguientes datos:

 TOBT
 ESTADO TOBT
 AOBT
 TSAT
 ASRT
 REA
 ASAT
 TTOT
 CTOT
 EXOT
 STAND
REQ - En caso de que un plan de vuelo cambia de pista, no se enviará el mensaje correspondiente a la salida de la
secuencia de la pista antigua (valor de TSAT en blanco), si no que se enviará solamente el mensaje CDM con el
valor de TSAT en la secuencia de la nueva pista.
REQ - El mensaje CDM dejará de enviarse cuando el plan de vuelo tenga estado ACTIVO.
Elaborado: 14/04/16
Página: 98/201
Plataforma
2.5.3.11.1.3.1.1.15. Tipo de Mensaje DEICE
REQ - Para un plan de vuelo cuyo aeródromo origen sea un aeródromo de la dependencia, cuando se produzca
un cambio en el valor de cualquiera de los siguientes datos:
 Solicitud/Anulación deshielo
 BASE
 EDIT
Se enviará un mensaje DEICE con los siguientes datos:

 Solicitud/Anulación deshielo
 BASE
 EDIT
 ECZT
2.5.3.11.1.3.1.2. Denominación de los datos
COM - En este apartado se indican para cada dato enviado de los mencionados anteriormente, el nombre con el
que se denominará a ese dato en el esquema XML asi como sus posibles valores.
REQ - alor el Código OACI de

AEROPUERTO ORIGEN.
REQ -
DESTINO.
REQ -
REQ - El campo IOBT se denom

Vuelo es de creación Manual.
REQ -
REQ - El campo Número de aeronaves se denominará

numéricos correspondiente al mismo campo del Plan de vuelo.
REQ -
caracteres alfanuméricos correspondiente al mismo campo del Plan de vuelo
REQ -
REQ -
valor.
REQ - El campo Soli

solicitud de push back.
REQ -
autorización de push back.
Elaborado: 14/04/16
Página: 99/201
Plataforma
REQ -
autorización de taxi.
REQ -
plan de vuelo.
REQ - El cam
plan de vuelo.
REQ - El campo PROCEDIMIENTO DE DESPEGUE se denominará

vuelo.
REQ - El campo PROCEDIMIENTO DE ARR siendo su valor la STAR asignada al plan de

vuelo.
REQ -
AEROPUERTO DESTINO del plan de vuelo
REQ -
REQ -
REQ -
REQ -
Plataforma CDM con valores P, I, C, M o S.
REQ - El campo AOBT
REQ - El campo TSAT
REQ - El campo ASRT

marcha.
REQ - El campo REA a la solicitud de REA.
REQ - El envío de ASRT solo se producirá cuando se anote la Solicitud S/U, pero funcionalmente se mantiene que
la anotación de REA anote internamente la ASRR/HSPM.
REQ - El campo ASAT

en marcha
REQ - El campo TTOT -R.
REQ -
 el tiempo de TaxiStandPista definido en la Tabla de BDAP correspondiente teniendo en cuenta el
stand de despegue y la pista de despegue
 si el plan de vuelo no tiene stand, el TaxiTime del aeródromo origen de la dependencia.
 En caso de que el plan de vuelo esté afectado por la extensión de EXOT, este campo incluirá el valor
del EXOT resultado de la extensión.
Elaborado: 14/04/16
Página: 100/201
Plataforma
COM - La extensión del tiempo de taxis está definido en la UCR SA#4430. FUNCION DE EXTENSION DE TIEMPOS
DE TAXI.
REQ - siendo su valor el campo STAND
REQ -
procesado por SACTA. .
REQ - posibles
valores:
deshielo)
Enviados por SACTA: D
n SACTA, se procesará como si estuviese vacío.
REQ -
por la Plataforma CDM.
REQ - rma CDM.
REQ -
2.5.3.11.1.3.1.3. Formato de campos horarios
REQ - Los campos horarios tendrán el siguiente formato: DD/MM/AAAA HH:MM.

Ejemplo para la TOBT: 10/03/2015 12:35
2.5.3.11.1.3.1.4.
REQ -
por cada uno de los datos, se incluirá el campo Result con valor Commited., a excepción de la TOBT y AOBT que se
enviarán con Result
COM - Ejemplo:
<Dates>
<DateName>EOBT</DateName>
</CdmDate>
<DateName>ELDT</DateName>
</CdmDate>
</Dates>
REQ - Para la recepción de los mensajes de la plataforma CDM en el aparta

cada uno de los datos , el campo Result podrá tener dos valores:
Elaborado: 14/04/16
Página: 101/201
Plataforma


2.5.3.11.1.3.2. Ejemplos de mensajes
COM - A continuación se muestran varios ejemplos de mensajes recibidos desde la Plataforma CDM a través del
nuevo interfaz.
COM - Ejemplo de mensaje con TOBT enviada por Swissport, en este caso el estado es P, y el sistema es
SWPORT con tipo de mensaje TOBT
La Exot usada (Result used)la que tenía Scena (calculada con SACTA) se recalcula la TTOT con TOBT (Result
commited)
<CdmFlightInfo Action="update" TimeStamp="22/05/2015 03:30:25.031" Source="SWPORT" Message="TOBT"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">TAP</Airline>
<FlightNumber>1023</FlightNumber>
<FlightDate urn:DateID="SOBT" xmlns:urn="urn:aoml">22/05/2015 05:30</FlightDate>
<DepartureAirport urn:MessageIssued="true" urn:CodeContext="IATA"
xmlns:urn="urn:aoml">MAD</DepartureAirport>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">LIS</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">TAP</Airline>
<DepartureAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LEMD</DepartureAirport>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LPPT</ArrivalAirport>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="SWPORT" Status="P" Message="TOBT">
<DateName>TOBT</DateName>
</CdmDate>
<CdmDate DateType="number" Source="SACTA" Message="TAXI">
<DateName>EXOT</DateName>
<NumberValue>15</NumberValue>
<Result>used</Result>
</CdmDate>
<CdmDate DateType="date" Source="SACTA" Message="CDM">
<DateName>TTOT</DateName>
Elaborado: 14/04/16
Página: 102/201
Plataforma
</CdmDate>
</Dates>
<Handling>
<Handling_Group Type="CDM">3</Handling_Group>
<Handling_Agent>HY2</Handling_Agent>
</Handling>
<Handling>
<Handling_Group Type="RAMP">3</Handling_Group>
</Handling>
<Handling>
<Handling_Group Type="RAMP">4B</Handling_Group>
</Handling>
<Handling>
<Handling_Group Type="RAMP">5A</Handling_Group>
</Handling>
<Handling>
</Handling>
<Handling>
<Handling_Group Type="RAMP">5C</Handling_Group>
</Handling>
<Handling>
<Handling_Agent>HG3</Handling_Agent>
</Handling>
<Handling>
<Handling_Agent>IBE</Handling_Agent>
</Handling>
</CdmFlightInfo>
COM- A partir de este ejemplo se elimina la parte de los handling para reducir el tamaño del mensaje, pero
esta información vendrá en todos.
COM- Ejemplo de TOBT confirmada con TOBT de aeropuerto. En este caso el mensaje es CDM con tipo de
mensaje M9, se trata M9 a un vuelo que no tiene TOBT y se da una.
<CdmFlightInfo Action="update" TimeStamp="22/05/2015 04:50:46.277" Source="CDM" Message="M9"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">AEA</Airline>
Elaborado: 14/04/16
Página: 103/201
Plataforma

<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">FRA</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">EDDF</ArrivalAirport>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="CDM" Status="C" Message="M9">
</CdmDate>
</CdmDate>
<CdmDate DateType="date" Source="SACTA" Message="CDM">
</CdmDate>
</Dates>
</CdmFlightInfo>
COM- Ejemplo de TOBT inválida de IBERIA

<CdmFlightInfo Action="update" TimeStamp="22/05/2015 06:13:54.193" Source="IBERIA" Message="TOBT"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">AVA</Airline>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">BOG</ArrivalAirport>
</AirportSlot>
<FlightPlan>
Elaborado: 14/04/16
Página: 104/201
Plataforma
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">AVA</Airline>

<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">SKBO</ArrivalAirport>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="IBERIA" Status="I" Message="TOBT">
</CdmDate>
<CdmDate DateType="date" Source="CDM" Message="M9">
<DateValue/>
</CdmDate>
</Dates>
</CdmFlightInfo>
COM- Ejemplo de AOBT, en este caso se ha operado el vuelo por operación automática, con ayuda de SACTA y
VAP, con lo que el sistema es SACTA y tipo de mensaje OBK de salida de stand
<CdmFlightInfo Action="update" TimeStamp="22/05/2015 07:05:10.661" Source="SACTA" Message="OBK"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">ANE</Airline>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">SDR</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">ANE</Airline>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LEXJ</ArrivalAirport>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="SACTA" Message="OBK">
<DateName>AOBT</DateName>
Elaborado: 14/04/16
Página: 105/201
Plataforma
</CdmDate>
<DateName>POBT</DateName>
<Result>rejected</Result>
<Reason>(655)Sistema o mensaje incorrecto</Reason>
</CdmDate>
<CdmDate DateType="number" Source="SACTA" Message="OBK">
<DateName>ATTT</DateName>
</CdmDate>
</CdmDate>
</CdmDate>
</Dates>
</CdmFlightInfo>
COM- Ejemplo de mensaje con AOBT pero no hay que tenerlo en cuenta porque la hora es Used para calcular la
ttot
<CdmFlightInfo Action="update" TimeStamp="22/05/2015 07:06:05.461" Source="IBERIA" Message="ATOT"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">IBE</Airline>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">VCE</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<FlightNumber>32RC</FlightNumber>
Elaborado: 14/04/16
Página: 106/201
Plataforma
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LIPZ</ArrivalAirport>

</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="IBERIA" Message="ATOT">
<DateName>ATOT</DateName>
</CdmDate>
<DateName>AOBT</DateName>
</CdmDate>
<CdmDate DateType="number" Source="IBERIA" Message="ATOT">
<DateName>AXOT</DateName>
</CdmDate>
</Dates>
</CdmFlightInfo>
COM- Ejemplo stand

<CdmFlightInfo Action="update" TimeStamp="22/05/2015 07:06:11.089" Source="SADAMA" Message="SADAMA"
<FlightID>
<AirportSlot>
<FlightDate urn:DateID="SIBT" xmlns:urn="urn:aoml">22/05/2015 08:00</FlightDate>
<DepartureAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">BIO</DepartureAirport>
<ArrivalAirport urn:MessageIssued="true" urn:CodeContext="IATA"
xmlns:urn="urn:aoml">MAD</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<DepartureAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LEBB</DepartureAirport>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LEMD</ArrivalAirport>
</FlightPlan>
</FlightID>
<FlightData>
<AirportResources>
<AircraftParkingPosition>T18</AircraftParkingPosition>
Elaborado: 14/04/16
Página: 107/201
Plataforma
<BaggageMakeupBelt>
<Code>N613</Code>
<StartDate>22/05/2015 08:18:00</StartDate>
<EndDate>22/05/2015 08:46:00</EndDate>
</BaggageMakeupBelt>
<AircraftTerminal>2</AircraftTerminal>
</AirportResources>
</FlightData>
</CdmFlightInfo>
COM- Ejemplo de tipo de aeronave a partir de un mensaje de Icaro de FPL

<CdmFlightInfo Action="update" TimeStamp="21/05/2015 23:52:11.051" Source="ICARO" Message="FPL"
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">RYR</Airline>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">VNO</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">EYVI</ArrivalAirport>
<AircraftType>B738</AircraftType>
<TailNumber>EIDYS</TailNumber>
</FlightPlan>
</FlightID>
</CdmFlightInfo>
COM- Ejemplo de cómo sería el mensaje de deshielo:

<CdmFlightInfo Action="update" TimeStamp="07/11/2014 13:55:11.051" Source=" DEICE " Message=" DEICE "
<FlightID>
<AirportSlot>
<Airline urn:CodeContext="OACI" xmlns:urn="urn:aoml">RYR</Airline>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">VNO</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">EYVI</ArrivalAirport>
<AircraftType>B738</AircraftType>
Elaborado: 14/04/16
Página: 108/201
Plataforma
<TailNumber>EIDYS</TailNumber>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="number" Source="DEICE" Message="DEICE">
<DateName>EDIT</DateName>
</CdmDate>
<CdmDate DateType="date" Source="DEICE" Message="DEICE">
<DateName>ACZT</DateName>
</CdmDate>
</Dates>
<DeIce>
<DeIceCode>1AM</DeIceCode>
<RequestState>D</RequestState>
<DeIceBase>38</DeIceBase>
</DeIce>
</CdmFlightInfo>
COM- Ejemplo mensaje DeIce:

<?xml version="1.0" encoding="UTF-8"?>
<CdmFlightInfo Action="update" TimeStamp="05/09/2014 10:33:44.872" Source="ECDM" Message="ECDM"
<FlightID>
<AirportSlot>
<ArrivalAirport urn:CodeContext="IATA" xmlns:urn="urn:aoml">TLV</ArrivalAirport>
</AirportSlot>
<FlightPlan>
<ArrivalAirport urn:CodeContext="OACI" xmlns:urn="urn:aoml">LLBG</ArrivalAirport>
</FlightPlan>
</FlightID>
<Dates>
<CdmDate DateType="date" Source="ECDM" Message="ECDM">
Elaborado: 14/04/16
Página: 109/201
Plataforma
<DateName>ACZT</DateName>
<DateValue>05/09/2014 08:20</DateValue> <Result>commited</Result>
</CdmDate>
<CdmDate DateType="number" Source="DEICE" Message="DEICE">
<DateName>EDIT</DateName>
</CdmDate>
</Dates>
<DeIce>
<DeIceCode>1AFM</DeIceCode>
<RequestState>P</RequestState>
<DeIceBase>B1</DeIceBase>
</DeIce>
<Handling>
<Handling_Group Type="RAMP">3</Handling_Group>
</Handling>
<Handling>
</Handling>
<Handling>
<Handling_Group Type="RAMP">5A</Handling_Group>
</Handling>
<Handling>
</Handling>
<Handling>
<Handling_Group Type="RAMP">5C</Handling_Group>
</Handling>
</CdmFlightInfo>
REQ - Existirá un registro histórico de los mensajes recibidos de la Plataforma CDM.
REQ - Los datos recibidos en el mensaje recibido, y en base al cual se generará un registro indicando la
procesados, dispuestos en una línea, manteniendo el mismo orden de los datos, independientemente del Source
o Message.
Elaborado: 14/04/16
Página: 110/201
Plataforma
COM - El objeto de esta disposición de los históricos, es facilitar una exportación de mensajes a otra aplicación
(por. Ejemplo Excel) para poder realizar análisis.
COM - Los datos registrados serán los mencionados anteriormente en los mensajes CDM y DEICE, ya que
existirán otros datos que SACTA no procesa, correspondientes a información para otros usuarios.
REQ - Existirá un registro histórico que indicará el resultado del proceso (MENSAJE PROCESADO o MENSAJE
RECHAZADO) del mensaje recibido de la Plataforma CDM.
REQ - Existirá un registro histórico de los mensajes enviados a la Plataforma CDM.
REQ - Los datos enviados para cada mensaje y en base al cual se generará un registro indicando la identificación
dispuestos en una línea, manteniendo el mismo orden de los datos, por Message.
COM - El histórico para el Mensaje SEC sería:

SOURCE MESSAGE INDICATIVO ORIGEN DESTINO N/TAERO ELDT MLDT PISTARRIBADA
COM - Se acordará con la División de Automatización (Área TPV) los formatos de los históricos.
2.5.3.11.1.5. Herramientas para encolar mensajes
REQ - Será necesario una herramienta que permita simular la recepción de mensajes con información CDM de la
Plataforma CDM.
REQ - La herramienta generará mensajes en formato XML que pueda procesar el sistema a partir de los datos
incluidos en un fichero con el siguiente formato
INDICATIVO ORIGEN DESTINO IOBT IFPLID STAND TAERO TOBT ESTADO_TOBT AOBT SOL/ANUL_DESH BASE EDIT ECZT
Para la definición del tamaño de los campos, el contenido de los campos se ha explicado en apartados anteriores.
Vuelo de Torre.
REQ - El sistema implementará mitigaciones para evitar errores o fallos en el Servicio de Gestión de Llegadas en
2.5.3.12. SC#14014. Tratamiento de las horas de despegue y fuera de calzos en SSD
2.5.3.12.1.1. Requisitos de GTA
Elaborado: 14/04/16
Página: 111/201
Plataforma
2.5.3.12.1.1.1. Datos del vuelo
REQ - Para cada vuelo existirá un registro denominado TOBT de hora, tanto para la tabla de vuelos activos como
para la tabla de vuelos inactivos.
REQ - Para cada vuelo existirá un registro denominado ESTADO_TOBT, tanto para la tabla de vuelos activos como
REQ - Para cada vuelo existirá un registro denominado TSAT de hora, tanto para la tabla de vuelos activos como
REQ - Para cada vuelo existirá un registro denominado CTOT de hora, tanto para la tabla de vuelos activos como
REQ - Para cada vuelo existirá un registro denominado ETOT_MANUAL de hora para la tabla de vuelos activos.
REQ - Para cada vuelo existirá un registro denominado DESHIELO que indicará si se ha enviado un mensaje de
deshielo de tipo SOLICITUD (S) o ANULACIÓN (N), tanto para la tabla de vuelos activos como inactivos.
REQ - Para cada vuelo existirá un registro denominado TIEMPO_DESHIELO de hora que almacenará el campo
EDIT incluido en el mensaje de deshielo, tanto para la tabla de vuelos activos como inactivos.
REQ - Para cada vuelo existirá un registro denominado BASE_DESHIELO que almacenará el campo BASE incluido
en el mensaje de deshielo, tanto para la tabla de vuelos activos como inactivos.
REQ - Para cada vuelo existirá un registro denominado ECZT de hora que almacenará el campo ECZT incluido en
el mensaje de deshielo, tanto para la tabla de vuelos activos como inactivos.
REQ - El TAXITIME para un vuelo activo será:

- el valor de TIEMPO TAXI_STAND_PISTA de los Datos de Adaptación (BDAP) si el STAND está definido en
dichos datos.
- TAXITIME global definido para el aeródromo si el STAND sólo está definido en los datos de suelo (fichero
WORD) no en Datos de Adaptación.
2.5.3.12.1.1.2. Ejecución de A.A. de mensajes externos
REQ - Al ejecutarse una A.A. de MSJ. EXTERNO de origen SCENA de tipo CDM sobre un vuelo, activo o inactivo:
- se rellenará el registro TOBT de vuelo con la hora incluida en el mensaje.
- Se rellenará el registro ESTADO_TOBT con el valor del estado incluido en el mensaje.
- se enviará al componente de tratamiento de PV de TWR el mensaje que incluya la TOBT y el ESTADO de
dicha TOBT, tal como lo envía, el proceso que trata el fichero de SCENA a dicho componente.
REQ - Al ejecutarse una A.A. de MSJ. EXTERNO de origen SCENA de tipo DESHIELO sobre un vuelo, activo o
inactivo:
- se rellenará el registro DESHIELO con S si el mensaje es de SOLICITUD o con N si el mensaje es de
ANULACIÓN.
- Se rellenará el registro TIEMPO_DESHIELO con el valor del campo EDIT si el mensaje es de SOLICITUD o
se vaciará el campo si el mensaje es de tipo ANULACION (N).
- Se rellenará el registro BASE_DESHIELO con el valor del campo BASE si el mensaje es de SOLICITUD o se
vaciará el campo si el mensaje es de tipo ANULACION (N).
Elaborado: 14/04/16
Página: 112/201
Plataforma
- Se rellenará el registro ECZT con el valor del campo ECZT si el mensaje es de SOLICITUD o se vaciará el
campo si el mensaje es de tipo ANULACION (N).
- se enviará al componente de tratamiento de PV de TWR el mensaje que incluya el tipo de mensaje
(SOLICITUD (S) o ANULACIÓN (N)), el campo EDIT, el campo BASE y la hora ECZT.REQ - Al ejecutarse una
A.A. de MSJ. EXTERNO de origen CFMU de tipo SAM o SRM sobre un vuelo activo se borrará el contenido
del registro del vuelo ETOT MANUAL.
REQ - Al ejecutarse una A.A. de MSJ. EXTERNO de origen CFMU de tipo SAM o SRM sobre un vuelo, activo o
inactivo, se rellenará el valor del registro del vuelo CTOT con dicho valor.
REQ - Al ejecutarse una A.A. de MSJ. EXTERNO de origen CFMU de tipo SLC o FLS sobre un vuelo, activo o
inactivo, se borrará el contenido del registro del vuelo CTOT.
2.5.3.12.1.1.3. Ejecución de comando ETOT
REQ - Al ejecutarse un comando de PPL de cambio de ETOT sobre un vuelo, se rellenará el contenido del registro
ETOT_MANUAL con el valor incluido en el campo ETOT del comando.
2.5.3.12.1.1.4. Creación de vuelos inactivos
REQ - Al crearse un vuelo inactivo el campo EOBT se rellenará con el valor incluido en la ventana de
CREACIÓN/MODIFICACIÓN DE PV.
REQ - Al crearse un vuelo inactivo el campo ETOT se rellenará con el valor incluido en la ventana de
CREACIÓN/MODIFICACIÓN DE PV.
REQ - Al crearse un vuelo inactivo el campo TOBT se creará vacío.
REQ - Al crearse un vuelo inactivo el campo ESTADO_TOBT se creará vacío.
REQ - Al crearse un vuelo inactivo el campo TSAT se creará vacío.
REQ - Al crearse un vuelo inactivo el campo CTOT se creará vacío.
REQ - Al crearse un vuelo inactivo el campo DESHIELO se rellenará con N.
REQ - Al crearse un vuelo inactivo el campo TIEMPO_DESHIELO se creará vacío.
REQ - Al crearse un vuelo inactivo el campo BASE_DESHIELO se creará vacío.
REQ - Al crearse un vuelo inactivo el campo ECZT se creará vacío.
2.5.3.12.1.1.5. Activación de vuelos inactivos
REQ - Al activarse un vuelo inactivo el campo EOBT de la tabla de vuelos activos se rellenará con el valor del
mismo campo de la tabla de vuelos inactivos.
REQ - Al activarse un vuelo inactivo el campo ETOT de la tabla de vuelos activos se rellenará con el valor del
Elaborado: 14/04/16
Página: 113/201
Plataforma
REQ - Al activarse un vuelo inactivo el campo TOBT de la tabla de vuelos activos se rellenará con el valor del
REQ - Al activarse un vuelo inactivo el campo ESTADO_TOBT de la tabla de vuelos activos se rellenará con el valor
del mismo campo de la tabla de vuelos inactivos.
REQ - Al activarse un vuelo inactivo el campo TSAT de la tabla de vuelos activos se rellenará con el valor del
REQ - Al activarse un vuelo inactivo el campo CTOT de la tabla de vuelos activos se rellenará con el valor del
REQ - Al activarse un vuelo inactivo el campo DESHIELO de la tabla de vuelos activos se rellenará con el valor del
REQ - Al activarse un vuelo inactivo el campo TIEMPO_DESHIELO de la tabla de vuelos activos se rellenará con el
valor del mismo campo de la tabla de vuelos inactivos.
REQ - Al activarse un vuelo inactivo el campo BASE_DESHIELO de la tabla de vuelos activos se rellenará con el
valor del mismo campo de la tabla de vuelos inactivos.
REQ - Al activarse un vuelo inactivo el campo ECZT de la tabla de vuelos activos se rellenará con el valor del
REQ - Al activarse un vuelo inactivo, el registro ETOT_MANUAL de la tabla de vuelos activos se creará vacío.
REQ - Los vuelos inactivos que nacen en un aeródromo simulado se activarán el TIEMPO DE PRESENTACIÓN AL
PILOTO antes de la menor de las siguientes horas:
- EOBT
- CTOT TAXITIME
- TOBT
REQ - Los vuelos inactivos que nacen en un aeródromo no simulado se activarán el TIEMPO DE PRESENTACIÓN
AL PILOTO antes de la menor de las siguientes horas:
- CTOT
- ETOT
REQ - Los vuelos que nacen en un aeródromo simulado nacerán en el aire cuando la hora actual sea superior a la
mayor de las siguientes horas:
- TSAT + TAXITIME
- CTOT
- ETOT
REQ - Los vuelos que nacen en un aeródromo no simulado nacerán en el aire cuando la hora actual sea superior
a la mayor de las siguientes horas:
- CTOT
- ETOT
Elaborado: 14/04/16
Página: 114/201
Plataforma
2.5.3.12.1.1.6. Atender eventos externos
REQ - El GTA capturará y leerá el mensaje que contiene el valor de la TSAT del vuelo y asignará dicho valor al
vuelo en el registro TSAT, ya esté en la tabla de vuelos activos como en la de vuelos inactivos.
REQ - Si el mensaje de capturado que contiene la TSAT de un vuelo tiene dicho valor vacío se eliminará el registro
de TSAT del vuelo.
REQ - Si el mensaje de capturado que contiene la TSAT de un vuelo tiene dicho valor vacío y el registro del vuelo
ESTADO_TOBT contiene I o P se eliminaran los registros de TSAT y TOBT del vuelo.
2.5.3.12.1.2. Requisitos de PPL
2.5.3.12.1.2.1. Tabular de vuelos activos propios
REQ - Para vuelos que despegan de un aeródromo simulado en fase TAX SUR en el tabular de vuelos activos
propios se presentará en el campo ETOF la menor hora de las siguientes, en el color especificado:
- ETOT_MANUAL TAXITIME (en color verde).
- TSAT si se ha cumplido la TOBT (en color naranja).
- TOBT (en color amarillo)
- CTOT TAXITIME (en color blanco)
- EOBT (en color verde)
REQ - Para vuelos que despegan de un aeródromo simulado en fase TAXI, excepto para subfase SUR, en el
tabular de vuelos activos propios se presentará en el campo ETOF (en color verde) la menor hora de las
siguientes:
- ETOT_MANUAL
- TSAT + TAXITIME
- TOBT + TAXITIME
- CTOT
- ETOT
REQ - Para vuelos que despegan de un aeródromo no simulado en fase TAXI en el tabular de vuelos activos
propios se presentará en el campo ETOF (en color verde) la menor hora de las siguientes:
- CTOT
- ETOT
REQ - Para vuelos que despegan de un aeródromo simulado el campo ORIGEN iniciará un parpadeo en color
verde cuando el vuelo esté en fase TAX SUR y la hora actual sea mayor que la menor hora de las siguientes:
- ETOT_MANUAL TAXITIME
- TOBT
- SAT
- CTOT TAXITIME
- EOBT
REQ - Para vuelos que despegan de un aeródromo simulado el campo ETOF iniciará un parpadeo en el color de
presentación del campo cuando el vuelo esté en fase TAX SUR y la hora actual sea mayor que la menor hora
de las siguientes:
- TOBT
Elaborado: 14/04/16
Página: 115/201
Plataforma
- TSAT
REQ - Para vuelos que despegan de un aeródromo simulado el campo ORIGEN iniciará un parpadeo en color rojo
cuando el vuelo esté en fase TAX SUR y hora actual sea mayor que:
- CTOT TAXITIME si el vuelo tiene CTOT
REQ - Para vuelos que despegan de un aeródromo simulado el parpadeo del campo ORIGEN y del campo ETOF
terminará al cambiar la fase de TAX SUR a TAX SUC.
REQ - Para vuelos que despegan de un aeródromo no simulado el campo ORIGEN iniciará un parpadeo, en el
color especificado, cuando el vuelo esté en fase TAXI y la hora actual sea mayor que la menor hora de las
siguientes:
- CTOT: parpadeo en color rojo
- ETOT: parpadeo en color verde
REQ - Para vuelos que despegan de un aeródromo no simulado el parpadeo del campo ORIGEN terminará al
cambiar la fase de TAXI a DESPEGUE.
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el campo ORIGEN de un vuelo en el
tabular de vuelos activos propios mientras dicho campo parpadea, cesará el parpadeo del campo ORIGEN y del
campo ETOF, si parpadease, de dicho vuelo del tabular de vuelos activos propios y el campo ORIGEN y el campo
ETOT, sí parpadease, para la etiqueta EXTENDIDA de dicho vuelo.
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el campo ETOF de un vuelo en el
tabular de vuelos activos propios mientras dicho campo parpadea, cesará el parpadeo de los campos ORIGEN y
ETOF de dicho vuelo del tabular de vuelos activos propios y el campo ORIGEN y ETOT para la etiqueta EXTENDIDA
de dicho vuelo.
REQ - Se creará una nueva columna DESHIELO de un solo carácter con rótulo I que contendrá para cada vuelo si
tiene un mensaje de deshielo.
REQ - Cuando el vuelo esté en fase TAXI en cualquiera de sus subfases y tenga el campo DESHIELO a S
presentará el símbolo de hielo en la columna DESHIELO en color amarillo.
NOTA: El símbolo de hielo que se utilizará se acordará previamente y será el mismo en todos los elementos
(tabulares y etiquetas) del interfaz.
REQ - Para el resto de casos la columna DESHIELO del tabular se presentará vacío.
REQ - El símbolo de hielo de la columna DESHIELO del tabular de vuelos activos propios parpadeará cuando:
- El vuelo esté en fase TAXI,
- el campo DESHIELO tenga un valor S,
- el vuelo esté parado en una Barra de Parada cuya denominación esté definida en la tabla BASES DE
DESHIELO (BDAP > Configuración de Dependencias > Dependencia > Funcionalidad TPVT > Configuración
de Superficie Aeródromo Asociado),
- y la hora actual sea mayor que la hora de parada en la Barra de Parada más el TIEMPO_DESHIELO.
REQ - Para vuelos que despegan de un aeródromo simulado el parpadeo del símbolo de hielo de la columna
DESHIELO terminará al iniciar la rodadura desde la Barra de Parada de Deshielo.
Elaborado: 14/04/16
Página: 116/201
Plataforma
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el símbolo de hielo de la columna
DESHIELO de un vuelo en el tabular de vuelos activos propios mientras dicho campo parpadea, cesará el
parpadeo del símbolo de hielo de la columna DESHIELO para el tabular de vuelos activos propios como el
parpadeo del símbolo de hielo del campo DESHIELO de la etiqueta del vuelo.
2.5.3.12.1.2.2. Tabular de vuelos activos del ejercicio
REQ - Para vuelos que despegan de un aeródromo simulado en el tabular de vuelos activos del ejercicio en fase
TAX SUR se presentará en el campo ETOF la menor hora de las siguientes:
- ETOT_MANUAL TAXITIME
- TSAT si se ha cumplido la TOBT
- TOBT
- CTOT TAXITIME
- EOBT
REQ - Para vuelos que despegan de un aeródromo simulado en fase TAXI, excepto para subfase SUR, en el
tabular de vuelos activos del ejercicio se presentará en el campo ETOF la menor hora de las siguientes:
- ETOT_MANUAL
- TSAT si se ha cumplido la TOBT
- TOBT
- CTOT
- ETOT
REQ - Para vuelos que despegan de un aeródromo no simulado en fase TAXI en el tabular de vuelos activos del
ejercicio se presentará en el campo ETOF la menor hora de las siguientes:
- CTOT
- ETOT
2.5.3.12.1.2.3. Tabular de vuelos inactivos propios o del ejercicio
REQ - Para vuelos que despegan de un aeródromo simulado en el tabular de vuelos inactivos propios o del
ejercicio se presentará en el campo H.INI la menor hora de las siguientes:
- TSAT
- TOBT
- CTOT - TAXITIME
- EOBT
REQ - Para vuelos que despegan de un aeródromo no simulado en el tabular de vuelos inactivos propios o del
ejercicio se presentará en el campo H.INI la menor hora de las siguientes:
- CTOT
- ETOT
REQ - Al activar manualmente un vuelo, desde el tabular de vuelos inactivos propios, se modificará el valor del
registro EOBT del vuelo con el valor actual de la hora y el campo ETOT con el valor calculado a partir de la EOBT.
Elaborado: 14/04/16
Página: 117/201
Plataforma
2.5.3.12.1.2.4. Etiqueta del vuelo
REQ - En la etiqueta BÁSICA del vuelo, para vuelos situados en un aeródromo simulado, se presentará un campo,
denominado DESHIELO, de un carácter situado debajo del campo E (emergencia) de la etiqueta, que contendrá el
estado de deshielo del vuelo.
REQ - En la etiqueta EXTENDIDA del vuelo, para vuelos situados en un aeródromo simulado, se presentará un
campo, denominado DESHIELO, de un carácter situado debajo del campo E (emergencia) de la etiqueta, que
contendrá el estado de deshielo del vuelo.
REQ - Para el resto de etiquetas no se presentará el campo DESHIELO.
REQ - El campo DESHIELO de la etiqueta presentará el símbolo de hielo en color amarillo sí el vuelo está en fase
TAXI en cualquiera de sus subfases y el campo DESHIELO tenga el valor S.
REQ - Para el resto de casos el campo DESHIELO de la etiqueta se presentará vacío.
REQ - El símbolo de hielo del campo DESHIELO de la etiqueta parpadeará cuando:

- el vuelo esté en fase TAXI,
- el campo DESHIELO tenga un valor S,
- el vuelo esté parado en una Barra de Parada cuya denominación esté definida en la tabla BASES DE
DESHIELO (BDAP > Configuración de Dependencias > Dependencia > Funcionalidad TPVT > Configuración
de Superficie Aeródromo Asociado),
- y la hora actual sea mayor que la hora de parada en la Barra de Parada + TIEMPO_DESHIELO.
REQ - Para vuelos que despegan de un aeródromo simulado el parpadeo del símbolo de hielo del campo
DESHIELO de la etiqueta terminará al iniciar la rodadura desde la Barra de Parada de Deshielo.
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el símbolo de hielo del campo
DESHIELO de un vuelo mientras dicho campo parpadea, cesará el parpadeo del campo D para dicho vuelo tanto de
la etiqueta del vuelo como del tabular de vuelos activos propios.
REQ - En la etiqueta EXTENDIDA para vuelos situados en un aeródromo simulado el campo ETOT presentará, en
el color especificado, la menor hora de las siguientes:
- ETOT_MANUAL TAXITIME (en color verde)
- TSAT si se ha cumplido la TOBT (en color naranja)
- TOBT (en color amarillo)
- CTOT TAXITIME (en color blanco)
- EOBT (en color verde)
REQ - En la etiqueta EXTENDIDA del vuelo, para vuelos situados en un aeródromo simulado en fase TAXI excepto
la subfase SUR, el campo ETOT presentará en color verde la menor hora de las siguientes:
- ETOT_MANUAL
- TSAT + TAXITIME
- TOBT + TAXITIME
- CTOT
- ETOT
Elaborado: 14/04/16
Página: 118/201
Plataforma
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el campo ORIGEN de un vuelo en la
etiqueta EXTENDIDA mientras dicho campo parpadea, cesará el parpadeo del campo ORIGEN y del campo ETOT, si
parpadease, para la etiqueta EXTENDIDA de dicho vuelo y el campo ORIGEN y el campo ETOF, sí parpadease, de
dicho vuelo del tabular de vuelos activos propios.
REQ - Al pulsar con el botón izquierdo del ratón cuando el cursor esté sobre el campo ETOT de la etiqueta
EXTENDIDA de un vuelo mientras dicho campo parpadea, cesará el parpadeo de los campos ORIGEN y ETOT para
la etiqueta EXTENDIDA de dicho vuelo y el campo ORIGEN y ETOF de dicho vuelo del tabular de vuelos activos
propios.
2.5.3.12.1.2.5. Ventana de información de vuelo
REQ - En la ventana de información de vuelo se presentarán para cada vuelo los siguientes campos:
- CTOT (Básico)
- ETOT (Básico)
- EOBT (Ground)
- TOBT (Ground)
- ESTADO TOBT (Ground)
- DESHIELO (Ground)
- TIEMPO DESHIELO (Ground)
- BASE (Ground)
- ECZT (Ground)
REQ - El contenido del campo ETOT se rellenará con el valor ETOT_MANUAL del vuelo si lo tiene y en su ausencia
con el valor ETOT del vuelo.
2.5.3.12.1.2.6. Panel acción automática de SOP
REQ - El campo STAND tendrá un menú desplegable asociado con los ítems de tipo stand definidos en la
aplicación.
REQ - El campo STAND presentará el menú desplegable al pulsar con el BI del ratón cuando el cursor esté dentro
de dicho campo.
2.5.3.12.1.2.7. Panel acción automática de SDP
aplicación.
de dicho campo.
2.5.3.12.1.2.8. Panel acción automática de deshielo
REQ - Se creará una nueva Acción Automática DEICE de Mensaje Externos de origen SCENA para el mensaje de
deshielo.
REQ - La Acción Automática presentará un panel de introducción de datos con sus campos correspondientes:
- TIPO MENSAJE
- EDIT
Elaborado: 14/04/16
Página: 119/201
Plataforma
- BASE
- ECZT
REQ - El panel se presentará al seleccionar el mensaje en la ventana de EDICIÓN DE MSJ.EXTERNOS con el origen
SCENA seleccionado con todos los campos vacíos.
REQ - El panel se presentará al seleccionar un mensaje de tipo DEICE en la ventana de CRECIÓN/MODIFICACIÓN

DE MSJ.EXTERNOS con todos los campos rellenos con los valores del mensaje seleccionado.
REQ - El campo TIPO MENSAJE será un campo obligatorio no editable.
REQ - El campo TIPO_MENSAJE presentará un menú desplegable asociado con los valores S (Solicitud) o N
(Anulación).
REQ - El menú desplegable del campo TIPO_MENSAJE se presentará al pulsar con el botón derecho del ratón
cuando el cursor está situado en dicho campo.
REQ - El campo EDIT será opcional y será un campo de tipo numérico que admitirá valores de cero a 99, siendo su
valor el tiempo de deshielo para el vuelo, en minutos.
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo EDIT deberá tener un valor diferente de 0.
REQ - El campo BASE será un campo opcional no editable, que indica la zona de deshielo seleccionada por la
compañía para el vuelo.
REQ - El campo BASE presentará un menú desplegable asociado con los valores definidos en la tabla BASES DE
DESHIELO (BDAP > Configuración de Dependencias > Dependencia > Funcionalidad TPVT > Configuración de
Superficie Aeródromo Asociado).
REQ - El menú desplegable del campo BASE se presentará al pulsar con el botón derecho del ratón cuando el
cursor está situado en dicho campo.
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo BASE deberá tener un valor diferente de vacío.
REQ - El campo ECZT será un campo opcional editable que indica la hora prevista de inicio del deshielo, en
formato de horas y minutos.
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo ECZT deberá tener un valor diferente de vacío.
2.5.3.12.1.2.9. Items de acciones automáticas
REQ - REQ-0100. Existirá un ítem de tipo tiempo F_CTOT, con el valor del registro interno CTOT del vuelo.
REQ - REQ-0101. Existirá un ítem de tipo tiempo F_ETOT_MANUAL, con el valor del registro interno
ETOT_MANUAL del vuelo.
REQ - Existirá un ítem de tipo tiempo F_TOBT, con el valor del registro interno TOBT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_ESTADO_TOBT, con el valor del registro interno ESTADO_TOBT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_TSAT, con el valor del registro interno TSAT del vuelo.
Elaborado: 14/04/16
Página: 120/201
Plataforma
REQ - Existirá un ítem de tipo tiempo F_DEICE, con el valor del registro interno DESHIELO del vuelo.
REQ - Existirá un ítem de tipo tiempo F_DEICE_MINUTES, con el valor del registro interno TIEMPO_DESHIELO del
vuelo.
2.5.3.12.1.3. Requisitos de PAPO
2.5.3.12.1.3.1. Panel acción automática de SOP
aplicación.
de dicho campo.
2.5.3.12.1.3.2. Panel acción automática de SDP
aplicación.
de dicho campo.
2.5.3.12.1.3.3. Panel de acción automática de deshielo
REQ - Se creará una nueva Acción Automática DEICE de Mensaje Externos de origen SCENA para el mensaje de
deshielo.
REQ - La Acción Automática presentará un panel de introducción de datos con sus campos correspondientes:
- TIPO MENSAJE
- EDIT
- BASE
- ECZT
REQ - El panel se presentará al seleccionar el mensaje en la ventana de EDICIÓN DE MSJ.EXTERNOS con el origen
SCENA seleccionado con todos los campos vacíos.
REQ - El panel se presentará al seleccionar un mensaje de tipo DEICE en la ventana de CRECIÓN/MODIFICACIÓN

DE MSJ.EXTERNOS con todos los campos rellenos con los valores del mensaje seleccionado.
REQ - El campo TIPO MENSAJE será un campo obligatorio no editable.
REQ - El campo TIPO_MENSAJE presentará un menú desplegable asociado con los valores S (SOLICITUD) o N
(ANULACIÓN).
REQ - El menú desplegable del campo TIPO_MENSAJE se presentará al pulsar con el botón derecho del ratón
cuando el cursor está situado en dicho campo.
REQ - El campo EDIT será opcional y será campo de tipo numérico que admitirá valores de cero a 99, siendo su
valor el tiempo de deshielo para el vuelo, en minutos.
Elaborado: 14/04/16
Página: 121/201
Plataforma
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo EDIT deberá tener un valor diferente de 0.
REQ - El campo BASE será un campo opcional no editable, que indica la zona de deshielo seleccionada por la
compañía para el vuelo.
REQ - El campo BASE presentará un menú desplegable asociado con los valores definidos en la tabla BASES DE
DESHIELO (BDAP > Configuración de Dependencias > Dependencia > Funcionalidad TPVT > Configuración de
Superficie Aeródromo Asociado).
REQ - El menú desplegable del campo BASE se presentará al pulsar con el botón derecho del ratón cuando el
cursor está situado en dicho campo.
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo BASE deberá tener un valor diferente de vacío.
REQ - El campo ECZT será un campo opcional editable que indica la hora prevista de inicio del deshielo, en
formato de horas y minutos.
REQ - Si el campo TIPO_MENSAJE presenta una S, el campo ECZT deberá tener un valor diferente de vacío.
2.5.3.12.1.3.4. Items de acciones automáticas
REQ - Existirá un ítem de tipo tiempo F_CTOT, con el valor del registro interno CTOT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_ETOT_MANUAL, con el valor del registro interno ETOT_MANUAL del
vuelo.
REQ - Existirá un ítem de tipo tiempo F_TOBT, con el valor del registro interno TOBT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_ESTADO_TOBT, con el valor del registro interno ESTADO_TOBT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_TSAT, con el valor del registro interno TSAT del vuelo.
REQ - Existirá un ítem de tipo tiempo F_DEICE, con el valor del registro interno DESHIELO del vuelo.
REQ - Existirá un ítem de tipo tiempo F_DEICE_MINUTES, con el valor del registro interno TIEMPO_DESHIELO del
vuelo.
2.6. Aseguramiento del proyecto

El Adjudicatario deberá hacer referencia, de forma precisa, a la aplicación de los estándares aplicables en aquellas
áreas en las que su aplicación representa una mejora o beneficio.
El Coordinador de la empresa Adjudicataria deberá acordar con el Director del Expediente o persona en quien
delegue, los planes, procedimientos, metodologías y buenas prácticas a aplicar en la prestación de este servicio.
El Coordinador de la empresa Adjudicataria entregará al Director del Expediente o persona en quien delegue, una
copia de los documentos que describan procedimientos, metodologías y estándares referenciados en cualquier
Documento Entregable, siempre que así lo requiera.
Todas las comunicaciones que puedan afectar a los términos y condiciones del contrato y concernientes a su
ejecución, deberán ser efectuadas o confirmadas por escrito.
Elaborado: 14/04/16
Página: 122/201
Plataforma
Cualquier actividad o documento publicitario relativo al contrato realizado con Enaire, y destinado por el
Adjudicatario a cualquier medio de comunicación, deberá ser acordado con el Director de Expediente.
Todos los productos, servicios o documentos, que se puedan obtener como resultado del desarrollo o de la
ejecución final de las actividades de la prestación del servicio, deberán ser exportables.
2.6.1. Metodología de desarrollo SW

2.6.1.1. General
1) La Metodología de desarrollo utilizada cumplirá la norma ED153: GUIDELINES FOR ANS SOFTWARE SAFETY
ASSURANCE con el propósito de cumplir con el SISTEMA DE LA GARANTIA DE LA SEGURIDAD DEL SW de la
organización a la que se presta el servicio objeto de este Pliego de Prescripciones Técnicas.
2) Para asegurar la viabilidad real de la aplicación de la Metodología descrita en este PPT se requerirá una
Organización de desarrollo SW, perteneciente al Adjudicatario, que demuestre poseer en cada uno de los
procesos aplicables a este proyecto, al menos, un Nivel de Madurez 3 de CCMI-DEV , en la versión actual, y
reconocido oficialmente por Carnegie Mellon Software Engineering Institute.
3) El Adjudicatario deberá aplicar las normas identificadas en el apartado 2.2.1 de esta sección, de acuerdo
con las características específicas del proyecto, en los Planes del mismo (como mínimo: Gestión del
Proyecto, Gestión de la Calidad, Gestión de la Configuración, Gestión de la Documentación, Proceso de
Desarrollo, de Verificación y Gestión de Seguridad), así como los de Estándares de Desarrollo y Verificación.
4) El Adjudicatario identificará en el Plan de Desarrollo de SW, los Estándares de Desarrollo que aplicarán a lo
largo del desarrollo del proyecto.
5) El Director del Expediente o persona en quien delegue, acordará con el Adjudicatario todos y cada uno de
los documentos contractuales (LDEC) que se generen a lo largo del desarrollo del proyecto.
6) Para la identificación de los documentos del ciclo de desarrollo se seguirá la norma ISO/IEC 12207.
7) Por defecto, para la realización y entrega de los documentos generados en la ejecución del proyecto se
realizará en idioma Español Castellano, o puntualmente en idioma acordado previamente con el Director
del Expediente o persona en quien delegue.
8) La documentación contractual ligada a este expediente estará sujeta a lo exigido en este apartado
METODOLOGÍA DE DESARROLLO, y al Anexo B Normas para la edición y codificación de la documentación
9) Aclaraciones sobre Matriz de Cumplimiento de la Garantía de Software :

Los procesos y tareas que cumplen algún objetivo identificado en la Matriz de Cumplimiento de la
Garantía de Software, deberán ser documentados y trazados con la misma granularidad que el objetivo.
10) Aclaraciones de segregación :

La segregación entre componentes deberá estar protegida por un componente independiente o el
componente protegido deberá tener una vía de recuperación en el caso que falle un componente
del cual se protege.
Elaborado: 14/04/16
Página: 123/201
Plataforma
2.6.1.2. Fases de desarrollo e hitos

1) En este apartado se detallan las entradas a cada fase del desarrollo del proyecto, así como los productos
(entregables) que el Adjudicatario deberá generar en ellas, las herramientas que deben utilizarse (las
cuales deben ser compatibles con la versiones que posee Enaire) y los hitos asociados. En el apartado 2.7
de este pliego, se incluye una lista de productos a entregar por el Adjudicatario, el propósito de cada uno de
ellos (orientativo no limitativo a las necesidades del proyecto o a lo establecido en los estándares
aplicables al proyecto) y la periodicidad con la que deben ser entregados.
2) Las diferentes fases de desarrollo podrán seguir estrategias de solapamiento entre sí para poder
optimizar el plazo de ejecución del proyecto, siempre que la valoración del riesgo asociado a estas
estrategias sea acordado con el Director del Expediente o persona en quien delegue.
3) El Adjudicatario deberá definir en el Plan de Gestión del Proyecto las fechas concretas de comienzo y fin de
las distintas fases, y la planificación de los entregables correspondientes.
4) Se deberán tener en cuenta las siguientes fases del proyecto:

 PLANIFICACIÓN, el resultado son los planes de gestión y control aplicables al proyecto.
 ENTREGA EN EL CED, el resultado incluye el producto y documentos que den evidencia de su estado
de aceptación, antes de su instalación en los diferentes emplazamientos, generados durante:
- Codificación
- Integración SW.
- Integración de Sistema.
- Pruebas Unitarias,
- Pruebas Integración SW
- Pruebas Integración de Sistema.
 INSTALACIÓN Y DESPLIEGUE, el resultado son los documentos que den evidencia de su estado de
aceptación y entrega, en los diferentes emplazamientos.
 TRANSICIÓN, el resultado son los documentos necesarios para la explotación y mantenimiento del
Sistema.
 FORMACIÓN, el resultado son los planes y materiales de formación.
 SEGUIMIENTO, esta fase es transversal a todas las demás, el resultado son los informes necesarios
para gestionar el avance del proyecto de acuerdo a lo planificado.
2.6.1.3. Planificación
1) ENTRADAS
 Pliego de Prescripciones Técnicas (PPT).
 Oferta del Adjudicatario.
2) RESULTADOS DE LA FASE
Documentos de Gestión y Control del Proyecto:
 LDEC-01 Plan de Gestión del Proyecto (PMP)
 LDEC-02 Plan de Gestión de la Calidad (QMP)
 LDEC-03 Plan de Gestión de la Configuración (CMP)
 LDEC-04 Plan de Gestión de la Documentación (DMP)
 LDEC-26 Plan de Aspectos para la Aprobación del SW del Suministrador (PSAA-S)
Elaborado: 14/04/16
Página: 124/201
Plataforma
 LDEC-29 Plan de Verificación (VP)

 LDEC-31 Plan de Aseguramiento de COTS (CAP)
 LDEC-32 Plan de Cualificación de Herramientas (TQP)
 LDEC-33 Plan de Desarrollo de SW (SDP)
 LDEC-34 Plan de Seguridad y Salud (PSS)
 LDEC-35 Plan de Gestión de Seguridad (Safety) (SMP)
 LDEC-38 Entorno de Desarrollo del SW.
 LDEC-44 Certificado de cumplimiento con la ISO 9001.
 LDEC-59 Certificado de CMMI.
 LDEC-65 Guía de uso de Herramienta TIMES (TIMES User Guide)
 LDEC-67 Asignación definitiva del SWAL.
Estos documentos deberán recoger los requisitos que sobre estos aspectos se especifican en el PPT.
3) HITOS
 Entrega de los documentos de gestión y control del proyecto.
 Aceptación de los documentos de gestión y control del proyecto.
4) HERRAMIENTAS
 Procesador de Textos Word para Windows.
 Microsoft Project.
 Adobe Acrobat.
2.6.1.4. Entrega en el CED

Para cada entrega de SW en el CED, el adjudicatario enviará un Informe de Pruebas de Integración SW (LDEC-
13.1). El informe reflejará el estado de las pruebas para todos los requisitos nuevos, modificados o afectados por
la actualización. La oficina de programa podrá utilizar los resultados de las pruebas internas del sistema y las
pruebas de aceptación con el propósito de preparar y emitir un informe único.
1) ENTRADAS
 Especificación de Requisitos del Sistema (SRS)
 Diseño de la Arquitectura del Sistema y Asignación de Requisitos (SARAD)
 Descripción del Diseño de Interfaces del SW (SIDD)
 Descripción de Requisitos de SW (SRD)
 Estudios de Seguridad de los Servicios (ES)
 Documentos entregados en la fase de planificación aplicables a esta fase.
2) RESULTADO DE LA FASE
 LDEC-12.1 Procedimientos o Casos de Prueba.
 LDEC-18 Plan de Pruebas de Integración SW.LDEC-13.1 Informes de Pruebas de Integración SW.
 LDEC-17 Producto SW.
o Programas Fuente probados de forma unitaria en el entorno de desarrollo.
o Programas Ejecutables probados a nivel de cada CSCI en el entorno de desarrollo.
 LDEC-20.2 Procedimientos de Instalación de versiones y actualizaciones del Sistema.
 LDEC-40.2 Informes de Control de la Configuración SW.
 LDEC-40.3 Informes de Control de la Configuración COTS.
Elaborado: 14/04/16
Página: 125/201
Plataforma
 LDEC-41.2 Informe Final de Producto.

 LDEC-42 Matriz de Verificación Extendida.
 LDEC-45 Declaraciones CE de los Componentes.
 LDEC-47.1 Informe de Cumplimiento de la Garantía del SW del Suministrador (SAS-S)
 LDEC-47.2 Informe de Conformidad de (CAS)
 LDEC-54 Sumario de la Cualificación de Herramientas (TAS)
 LDEC-55 Registro de Revisión de Aseguramiento de la Calidad de Procesos (RAC)
3) HITOS
 Entrega del SW en el CED.
 Entrega de la documentación asociada al SW.
 Aceptación de la documentación asociada al SW.
4) HERRAMIENTAS A UTILIZAR
 DOORS (9.2)
 Herramientas definidas en el SDP y TQP.
2.6.1.5. Instalación y despliegue

1) ENTRADAS
 LDEC-17 SW Instalado y probado en el CED.
 LDEC-13.1 Informes de Pruebas de Integración SW.
 LDEC-15 Manual Técnico de Mantenimiento (MTM)
3) HITOS
 Entrega de la documentación asociada a la Instalación y Despliegue.
 Aceptación de la documentación asociada a la Instalación y Despliegue.
 DOORS (9.2)
Elaborado: 14/04/16
Página: 126/201
Plataforma
2.6.1.6. Transición
1) ENTRADAS
 LDEC-06 Especificación de Requisitos del Sistema (SRS).
 LDEC-07 Diseño de la Arquitectura del Sistema y Asignación de Requisitos (SARAD).
 LDEC-08 Descripción del Diseño de Interfaces del SW (SIDD).
 LDEC-09 Descripción de Requisitos de SW (SRD).
 LDEC-13.1 Informes de Pruebas de Integración SW.
 LDEC-17 SW Instalado y preparado para las pruebas de aceptación en el emplazamiento.
 LDEC-21 Manuales del Sistema (Manual del Operador del Sistema).
 LDEC-22 Manuales de Usuario.
3) HITOS
 Entrega de la documentación asociada a la Transición.
 Aceptación de la documentación asociada a la Transición.
 DOORS (9.2)
2.6.1.7. Formación
1) ENTRADAS
 LDEC-15 Manual Técnico de Mantenimiento (MTM)
 LDEC-21 Manuales del Sistema (Manual del Operador del Sistema)
 LDEC-22 Manuales de Usuario.
 LDEC-16 Plan de Formación.
 LDEC-39.1 Material didáctico para la Formación.
 LDEC-39.2 Informe de la Formación.
3) HITOS
 Inicio de la Formación.
 Fin de la Formación.
Elaborado: 14/04/16
Página: 127/201
Plataforma
2.6.1.8. Seguimiento
Esta fase se realiza desde el inicio, a lo largo y hasta la finalización del proyecto. El objetivo es mantener siempre
informado al Director del Expediente o persona en quien delegue, del estado del proyecto.
1) ENTRADAS
 LDEC-01 Plan de Gestión del Proyecto (PMP).
 LDEC-02 Plan de Gestión de la Calidad (QMP).
 LDEC-03 Plan de Gestión de la Configuración (CMP).
 LDEC-04 Plan de Gestión de la Documentación (DMP).
 LDEC-29 Plan de Verificación (VP).
 LDEC-32 Plan de Cualificación de Herramientas (TQP).
 LDEC-33 Plan de Desarrollo de SW (SDP).
 LDEC-23 Informes de Seguimiento
 LDEC-40.5 Informes de Gestión de la Documentación del Proyecto
 LDEC-41.3 Informes de Auditorias
3) HITOS
 Entrega de la documentación asociada al Seguimiento.
2.6.2. Elaborar el plan de gestión de proyecto

El Plan de Gestión del Proyecto (LDEC-01) deberá ser entregado al inicio del proyecto y será acordado con el
Director del Expediente o persona en quien delegue, así como cada actualización del mismo que se produzca.
El Adjudicatario producirá y mantendrá el Plan de Gestión del Proyecto a lo largo de la duración del proyecto.
El Adjudicatario será el único responsable del mantenimiento del Plan de Gestión del Proyecto y se asegurará de
la aplicación de la versión aprobada y acordada más reciente.
El Plan de Gestión del Proyecto deberá incluir como mínimo lo siguiente:

o Alcance.
o Documentos de Referencia y Aplicables al proyecto.
o Estructura organizativa del proyecto, autoridades y responsabilidades.
o Medios humanos y materiales destinados al proyecto.
o Entorno de Ingeniería (para desarrollo, instalaciones, equipamiento, herramientas, etc.).
o Descomposición estructurada del trabajo a lo largo del ciclo de vida, procesos y actividades.
o Planificación del proyecto incluyendo calendarios, hitos, fases, entregas, etc.
o Relaciones con otros planes del proyecto.
o Relaciones con otros proyectos.
o Gestión de recursos a lo largo del ciclo de vida del proyecto.
o Gestión de subcontratistas.
Elaborado: 14/04/16
Página: 128/201
Plataforma
o Gestión de las Adquisiciones y Aprovisionamientos.

o Gestión de Riesgos.
o Métricas de los procesos y productos del Proyecto.
o Procedimientos de Control e Información del estado del proyecto.
o Procedimientos para la toma de decisiones.
o Plan de Comunicación.
o Garantía y Mantenimiento.
2.6.2.1. Control del proyecto
2.6.2.1.1. Informes
El Coordinador de la empresa Adjudicataria informará periódicamente al Director del Expediente o persona en

quien delegue, por escrito del estado del proyecto para su control.
La periodicidad se determinará de mutuo acuerdo entre el Coordinador de la citada empresa Adjudicataria y el

Director del Expediente o persona en quien delegue, si no se determina algo diferente, la periodicidad propuesta
será mensual.
El Director del Expediente o persona en quien delegue convocará a la empresa adjudicataria a reuniones
periódicas de Control de Proyecto en las que se tratará la marcha y las incidencias en la ejecución del proyecto.
Los Informes de Seguimiento (LDEC-23) serán revisados en la siguiente reunión de control de proyecto posterior
a la fecha de su entrega.
El Coordinador de la Adjudicatario entregará al Director del Expediente o persona en quien delegue en los cuatro
(4) primeros días laborables siguientes a la finalización del periodo a informar, el informe conteniendo como
mínimo:
o Plan de Proyecto actualizado.
o Avance del proyecto en el periodo informado y el estado del mismo mediante el método de Valor
Añadido.
o Un resumen del estado actual del diseño del sistema, software producido, documentación, y pruebas
(métricas de producto y de proceso).
o Problemas encontrados, incluyendo posibles soluciones.
o Dificultades en la ejecución del proyecto, especialmente si ocasiona deslizamientos o desviaciones
en el calendario.
o Previsiones y perspectivas del trabajo a realizar hasta la próxima Reunión de Control de Proyecto.
o Diagrama de Gantt del proyecto y principales hitos.
o Información del estado de las tares del proyecto y los subcontratistas (si es aplicable).
o Lista completa y actualizada de los riesgos detectados y las acciones de mitigación planeadas.
o Lista completa de Acciones.
Para cada paquete de trabajo se reportará mensualmente:

 Costes Incurridos
 Horas Incurridas por perfil y tasa
 Desglose de horas por cada Recurso y Área de conocimiento
 Actividades realizadas en el período distinguiendo entre :
o Actividades Planificadas
Elaborado: 14/04/16
Página: 129/201
Plataforma
o Actividades No Planificadas
Los hitos de proyecto serán actualizados periódicamente de común acuerdo con el Director del Expediente o
persona en quien delegue.
El Coordinador de la empresa Adjudicataria y el Director del Expediente o persona en quien delegue acordarán
una plantilla o esquema para el formato y contenido de los informes periódicos.
Toda la información contenida en los informes periódicos estará a disposición del Director del Expediente o
persona en quien delegue a través de correo electrónico u otros medios.
2.6.2.1.2. Reuniones conjuntas y auditorías
El Adjudicatario preverá la convocatoria de auditorías de gestión del proyecto (con aviso de no menos de cinco (5)
días de antelación) para la verificación del progreso del calendario de actividades e hitos.
El Adjudicatario permitirá al Director del Expediente o persona en quien delegue, la realización de auditorías al
proyecto.
Tanto el Adjudicatario como Enaire podrán convocar reuniones no programadas (con no menos de cinco (5) días
de antelación) al objeto de tratar asuntos del proyecto inesperados y que considere trascendentes.
El lugar, fecha, hora y agenda de las reuniones de Control de Proyecto será acordadas entre el Coordinador de la
empresa Adjudicataria y el Director del Expediente con al menos dos semanas de antelación.
Cualquier documento necesario para el desarrollo de la reunión de Control de Proyecto será distribuido con al
menos una semana de antelación.
Las Actas de las reuniones de Control de Proyecto deberán ser elaboradas por el Adjudicatario y deberá contener,
al menos, la siguiente información:
o Lugar, fecha, hora y duración.
o Participantes y lista de distribución.
o Puntos de la agenda
o Lista de acciones pendientes y completadas.
o Acuerdos alcanzados.
Las Actas de las reuniones de Control de Proyecto se distribuirán a aquellas personas incluidas en la lista de
distribución definida por Enaire no más tarde de una semana después de la finalización de la misma.
Si no se reciben objeciones a las Actas en las dos semanas siguientes a su distribución, éstas se considerarán
aprobadas.
El Adjudicatario prestará el servicio de asesoramiento en todos aquellos asuntos de naturaleza operativa, técnica
o de gestión, relacionados con el objeto del pliego.
El Adjudicatario deberá realizar auditorías internas con el objetivo de asegurar:

o Que el software desarrollado sigue la documentación de diseño.
o Que las revisiones de aceptación y los requisitos de prueba son adecuados para la aceptación de los
productos software.
o Que los datos de prueba cumplen con la especificación.
Elaborado: 14/04/16
Página: 130/201
Plataforma
o Que los informes de pruebas son correctos y las discrepancias entre los resultados reales y los
esperados han sido resueltas satisfactoriamente.
o Que la documentación de usuario cumple con los estándares acordados.
o Que las actividades han sido dirigidas y ejecutadas de acuerdo a los requisitos específicos, el
contrato y los planes establecidos.
o Que los costes y calendarios se ajustan a lo fijado en los planes.
El Adjudicatario permitirá e invitará al Director del Expediente o persona en quien delegue, a presenciar todas las
auditorías que realice, tanto de las internas como de las externas a subcontratistas.
El Adjudicatario pondrá a disposición del Director del Expediente o persona en quien delegue, la documentación
detallada y los resultados de todas las auditorías que se realicen en el proyecto.
El Adjudicatario estará obligado a permitir a Enaire o a representantes suyos, visitar las instalaciones donde se
estén desarrollando el programa, tanto suyas como de sus subcontratistas.
El Adjudicatario estará obligado a permitir a Enaire o a representantes suyos la realización de auditorías

relativas al avance parcial o total de los trabajos así como del coste, la calidad y de los recursos asignados
para la prestación del servicio.
Enaire se reserva el derecho de realizar auditorías también en el caso de que ya hub ieran existido
comprobaciones por parte de terceros. Para ello, el Adjudicatario pondrá a disposición de Enaire todos los
documentos y datos del proyecto objeto de auditoría y permitirá acceso a sus sistemas de gestión para la
comprobación de la veracidad de éstos. La auditoría se realizará exclusivamente sobre costes directos del
proyecto que sean perfectamente identificables y que el Adjudicatario entregará evidencia documentada a
Enaire en cualquier fase del proyecto. El Adjudicatario estará obligado a justificar todos y cada uno de los
costes imputados al proyecto, pudiendo ser todos ellos auditables por Enaire o quien delegue en su
nombre. La justificación de los costes se hará de acuerdo a los parámetros de calidad generalmente
aceptados en las normas de contabilidad fiscalidad y auditoría vigente.
Se considera requisito, tal como aparece en la Matriz de cumplimiento del Anexo 3 del Pliego de cláusulas
particulares (PPCP), la presentación por parte del licitador en su oferta de la aceptación expresa de dichas
auditorías para el servicio de gestión de aplicación.
2.6.2.2. Métricas del proyecto

El Adjudicatario deberá considerar los siguientes aspectos para la definición de Métricas del Proyecto:
1) En este proyecto se aplicarán una serie de métricas con el fin de:
 Analizar y cuantificar diversos atributos y magnitudes relativos al nivel de adecuación de los requisitos
del SW respecto de los requisitos de Usuario.
 Obtener indicadores respecto de la calidad general del SW.
 Sistematizar el control y la gestión de la desviaciones mediante la aplicación del método de desviaciones
-1998 Earned Value Management
Systems) consistente en el cálculo mensual de una serie de desviaciones, índices de rendimiento,
porcentajes de avance y estimaciones de coste final.
2) Para la consecución de estos objetivos estás métricas cubrirán las áreas de:
 Cumplimiento de Programa
Elaborado: 14/04/16
Página: 131/201
Plataforma
 Esfuerzo
 Gestión de Requisitos
 Tamaño del Código
 Cambios
 Calidad de SW
 Anomalías de SW
 Recursos/ Prestaciones de HW
 Avance de Pruebas (trazabilidad de pruebas y requisitos)
3) Para cada medida, el Adjudicatario incluirá su definición, método de estimación, método de toma de datos
reales formato y mecanismos y herramientas asociadas.
4) En el caso de que alguna medida no estuviese disponible el Coordinador de la empresa Adjudicataria

informará de ello y propondrá, si es conveniente, una medida alternativa o de sustitución.
5) La petición de cambio de una medida será justificada por parte del Coordinador de la empresa
Adjudicataria, demostrando que la nueva medida es adecuada a las necesidades detectadas y cómo será
su uso.
6) Estos datos se presentarán periódicamente por el Coordinador de la empresa Adjudicataria, como una de
las partes esenciales de los Informes de Seguimiento de Proyecto.
7) El Director del Expediente o persona en quien delegue, acordará con el Adjudicatario la forma de
documentar la lista concreta de métricas a incluir en los informes de seguimiento de acuerdo a la
definición y las frecuencias que a continuación se indican. Estos datos se presentarán periódicamente por
el adjudicatario como una de las partes esenciales de los Informes de Seguimiento de Proyecto.
ÁREAS MÉTRICA ITEMS Frecuencia Formato Comentario

Cumplimiento Earned Value Los valores asociados a coste Mensual Gráfico Se concretará en
de Programa se tomarán como % del Tabular el Plan de Gestión
presupuesto del proyecto del Proyecto las
1) Planned Value (PV) actividades
2) Earned Value (EV) principales sobre
3) Actual Cost (AC) las que se
4) Cost Variance (CV) aplicará esta
5) Schedule Variance (SV) métrica.
6) Cost Performance Index (CPI)
7) Schedule Performance Index
(SPI)
Cumplimiento Cumplimiento Para cada hito (externo o Mensual Gráfico
de Programa de Hitos interno) Tabular
Fecha
Esfuerzo Esfuerzo real Mensual Gráfico
Cada mes:
frente a Tabular
1) Esfuerzo Planificado (Horas)
esfuerzo
2) Esfuerzo Real (Horas)
planificado
Elaborado: 14/04/16
Página: 132/201
Plataforma
ÁREAS MÉTRICA ITEMS Frecuencia Formato Comentario

Tamaño SLOC Para el total del código para Mensual Gráfico
(Software Size) cada CSCI: (Sólo
- SLOC (Total, Añadidas, Totales)
Modificadas y Borradas) Tabular
Cambios Estado de Mensual Gráfico
Número de PCIs Totales y por
propuestas de Tabular
estado
cambio
Calidad de SW Calidad de SW Para el total del código y para Mensual Gráfico
cada CSCI: (Para el
- Distribución del Cyclomatic Total)
number (McCabe) en Tabular
porcentaje
(1-5, 5-10, 10-15, >15)
Anomalías de Nº de abiertas Para la totalidad: Mensual Gráfico
SW y cerradas por - Núm. Por estado (Para el
CSCI (Abierta/Cerrada/En Pruebas) Total)
- Para las abiertas y "En Tabular
pruebas", por prioridad
Para cada CSCI:
- Núm. Abiertas por prioridad
- Núm. "En Pruebas" por
prioridad
Anomalías de Nº de abiertas Para las Abiertas, para las "En Mensual Gráfico
SW y cerradas por Pruebas" y para ambas: Tabular
Antigüedad - Núm. Tiempo > 90 días
- Núm. Tiempo entre 60 y 90
días
- Núm. Tiempo entre 30 y 60
días
- Núm. Tiempo < 30 días
Recursos de HW Uso de CPU Por prueba Gráfico
Para cada HWCI de Tabular
prestaciones
Recursos de HW Uso de Por prueba Gráfico

Memoria de Tabular
Para cada HWCI
prestaciones
Recursos de HW Uso de Red Por prueba Gráfico

(LAN/WAN) Para cada LAN y para cada de Tabular
WAN prestaciones
Elaborado: 14/04/16
Página: 133/201
Plataforma
2.6.2.3. Gestión de riesgos
El Coordinador de la empresa Adjudicataria deberá acordar con el Director del Expediente o persona en quien
delegue, .el procedimiento para la Gestión de Riesgos, que cubra el ciclo de vida del proyecto.
El Plan de Gestión del Proyecto, incluirá un capítulo para la Gestión de los Riesgos en el cual el Coordinador de la
empresa Adjudicataria describirá como prevé identificar todos los riesgos y limitaciones que pudieran aparecer a
lo largo del ciclo de vida del proyecto, y que pudieran poner en riesgo la correcta ejecución del mismo, además
deberá incluir un catálogo de riesgos junto con sus valoraciones de severidad y posibles acciones preventivas y /
o correctivas.
2.6.2.4. Control de subcontratistas y proveedores
El Adjudicatario deberá incluir en el Plan de Gestión del Proyecto (LDEC-01), un capítulo sobre Adquisiciones y
Aprovisionamientos (PAA) donde describa cómo se va a llevar a cabo la gestión de las adquisiciones,
subcontrataciones y aprovisionamientos necesarios para la completa ejecución del proyecto.
2.6.3. Elaborar el Plan de Gestión de la Configuración

El Coordinador de la empresa Adjudicataria producirá, mantendrá y hará entrega del Plan de Gestión de la
Configuración (LDEC-03) acordado con el Director del Expediente o persona en quien delegue, que cubra el ciclo
de vida del proyecto.
El Plan de Gestión de la Configuración detallará la organización, los procedimientos y las herramientas

empleadas para:
 identificar la configuración y todos sus ítems,
 establecer y gestionar las líneas básicas (baseline),
 controlar la configuración hasta la finalización del período de garantía,
 auditar y revisar la configuración,
 controlar todos los CIs (Configuration Items / Elementos de Configuración) subcontratados o comprados,
 conservar las versiones antiguas de CIs junto a su documentación,
 informar del estado de la configuración manteniendo un historial,
 informar a todos los grupos participantes en el proyecto de los cambios que se produzcan a cualquier nivel,
 gestionar todos los cambios por medio de peticiones, evaluaciones o implantaciones,
 actualizar toda la documentación afectada por cualquier tipo de cambio,
 mantener actualizada una base de datos de cambios, con soporte informático, para todo el Proyecto.
Si existieran versiones, el Coordinador de la empresa Adjudicataria deberá asegurarse de:

 establecer una planificación para cada versión,
 determinar los contenidos de cada versión,
 realizar la documentación completa de cada versión.
Se usará un procedimiento para el Control de Cambios aplicable a los productos entregables (hardware, software,
documentación, etc.) el cual contendrá los siguientes elementos:
 identificación de la necesidad del cambio (mejora, adaptación o error),
 realización de una Propuesta de Cambio,
 registro informático de la Petición de Cambio,
 preparación del Informe de la Evaluación del Cambio y distribución a los evaluadores,
Elaborado: 14/04/16
Página: 134/201
Plataforma
 evaluación del cambio,

 comunicación del resultado de la evaluación,
 realización del cambio,
 seguimiento de la realización de los cambios.
La Gestión de la Configuración permitirá determinar el estado general de proyecto (incluyendo todo el software,
hardware, datos de configuración, versiones y documentación) en todo momento, y entregará al Director del
Expediente o persona en quien delegue los Informes de Control de la Configuración correspondientes.
El Coordinador de la empresa Adjudicataria deberá referenciar los estándares aplicables, y demostrar su

cumplimiento, para todas las actividades de Gestión del Proyecto.
El Coordinador de la empresa Adjudicataria será el responsable de la Gestión de la Configuración de todos los

elementos de configuración entregables y productos durante el ciclo de vida del servicio.
configuración que las compondrán (trazabilidad).
Al final de cada fase del ciclo de vida (planificación, especificación, diseño, desarrollo, etc.) el Adjudicatario hará
Se realizarán auditorías periódicas de configuración, auditorías de configuración física y auditorías de

configuración funcional.
El Adjudicatario implantará un proceso de auditorías de configuración, el cual se definirá en el Plan de Gestión de

la Configuración. El Director del Expediente o persona en quien delegue podrá solicitar al Adjudicatario la entrega
de los Informes de Auditoría de Gestión de la Configuración (LDEC- 43.1) que estime necesarios o la participación
en los mismos por parte de ENAIRE o de quien esta entidad designe.
El Coordinador de la empresa Adjudicataria implantará, ejecutará y mantendrá un Sistema de Gestión de la

Configuración que cumpla con el Plan de Gestión de la Configuración acordado con el Director del Expediente o
El Sistema de Gestión de la Configuración será entregado al Director del Expediente o persona en quien delegue,
a petición de éste. La entrega del Sistema de Gestión de la Configuración incluirá todos los documentos,
repositorios de datos y archivos que afecten a todos los productos desarrollados hasta la fecha. Igualmente las
herramientas automáticas y todo lo necesario para que Enaire pueda mantener el control de los elementos de la
misma forma que lo hacía el Adjudicatario.
Los Datos de Gestión de la Configuración serán entregados al Director del Expediente o persona en quien delegue
de forma que puedan ser incorporados a sus propias herramientas.
El Sistema de Gestión de la Configuración deberá soportar un interfaz conforme a estándares internacionales que
permitan la interconexión de los Sistemas de Control de la Configuración de la empresa Adjudicataria y de Enaire.
El Sistema de Gestión de la Configuración del servicio prestado por el Adjudicatario, estará disponible las 24
Horas los 365 días, para el Director del Expediente o personas en quien delegue.
Elaborado: 14/04/16
Página: 135/201
Plataforma
El procedimiento de propuestas de cambios deberá describir las actividades de revisión de los cambios que se
acuerden, y en las que intervendrán el Director del Expediente o personas en quien delegue.
2.6.3.1. Control de cambios

El Adjudicatario será responsable de la Gestión de los Cambios solicitados para todas las configuraciones y
elementos recibidos o creados en cualquier fase del proyecto.
El Adjudicatario definirá:
o La identificación y registro de las peticiones de cambio.
o El análisis y evaluación de los cambios.
o Los procedimientos para acordar las peticiones de cambio con el Director del Expediente o persona
en quien delegue.
o Entrega de los elementos software modificados.
El Adjudicatario implantará mecanismos para estimar el coste y el tiempo necesario para implementar cada
cambio, e indicando su capacidad para acometerlos.
El Adjudicatario implantará y ejecutará un sistema de Gestión de Cambios que cumpla con el Plan de Gestión de
la Configuración e indicará:
o Todas sus capacidades integradas, cuando sea posible, con otros elementos tales como el sistema
de Gestión de la Configuración que se ejecutará sobre plataformas estándares.
o Capacidad y flexibilidad para conectarse con otros sistemas de Gestión de Cambios, herramientas de
diseño, herramientas de pruebas, etc.
o Bajo coste de explotación.
o Justificación de su madurez.
o Uso probado en aplicaciones similares.
o Que requiere formación sencilla.
o Justificación de soporte y mantenimiento para todo el ciclo de vida del sistema.
El Adjudicatario implantará y ejecutará el sistema de Gestión de Cambios antes mencionado, este sistema deberá
ser previamente acordado con el Director del Expediente o persona en quien delegue.
El sistema de Gestión de Cambios del servicio prestado por el Adjudicatario, permitirá acceso protegido y
controlado las 24 Horas los 365 días, a la información de Gestión de Cambios al Director del Expediente o
personas en quien delegue.
El Adjudicatario siempre trabajará sobre un baseline definido, si bien este podrá trabajar en ciertos momentos en
más de un baseline a la vez.
2.6.3.2. Resolución de problemas / incidencias

El Plan de Gestión de la Configuración incluirá los procedimientos de resolución de problemas / incidencias
relacionadas al producto.
2.6.4. Elaborar el Plan de Gestión de la Documentación

El Coordinador de la empresa Adjudicataria definirá, mantendrá durante la vida del contrato y hará entrega de un
Plan de Gestión de la Documentación (LDEC-04), acordado con el Director del Expediente o persona en quien
Elaborado: 14/04/16
Página: 136/201
Plataforma
delegue, en el que se identifiquen todos los documentos que se entregarán al Director del Expediente o persona
en quien delegue durante el ciclo de vida del producto considerando lo descrito en el Anexo B de este pliego.
El Plan de Gestión de la Documentación incluirá como mínimo:

o Formatos
o Identificación
o Codificación
o Procedimientos y responsabilidades en contenidos, producción, revisión, modificación, aprobación,
almacenamiento, distribución, gestión de configuración y estándares.
o Calendario de borradores y versiones finales.
o Back-up y recuperación.
o Acceso y confidencialidad.
El Adjudicatario será responsable de la gestión y mantenimiento de todos los documentos definidos en el Plan de
Gestión de la Documentación.
El Plan de Gestión de la Documentación incluirá como mínimo los documentos descritos en la sección de Lista de
Documentos a Entregar por el Adjudicatario (LDEC) de este pliego.
El Adjudicatario definirá y empleará un sistema de Gestión de la Documentación, acordado con el Director del
Expediente o persona en quien delegue, que cumpla con el Plan de Gestión de Documentación.
Todos aquellos documentos que se encuentren bajo control de configuración, será creados, modificados y
gestionados de acuerdo al Plan de Gestión de la Documentación.
El Adjudicatario acordará con el Director del Expediente o persona en quien delegue, la periodicidad de entrega de
los Informes de Gestión de la Documentación (LDEC-40.5), si no se determina algo diferente, la periodicidad
propuesta será mensual.
Todos los documentos, salvo aquellas excepciones que se acuerden entre el Coordinador de la Adjudicatario y el
Director del Expediente o persona en quien delegue, serán escritos en castellano-español.
Todos los documentos, salvo aquellas excepciones que se acuerden entre el Coordinador de la Adjudicatario y el
Director del Expediente o persona en quien delegue, serán entregados en formato electrónico (MS Office y Adobe
PDF).
Todos los documentos estarán a disposición del Director del Expediente o persona en quien delegue, en formato
electrónico compatible con las herramientas de uso en Enaire (DOORS, MS Office, etc.).
Las herramientas y métodos acordados entre el Coordinador de la Adjudicatario y el Director del Expediente o
persona en quien delegue, para la ejecución del proyecto en el momento de la firma del contrato serán vinculante
durante la duración completa del contrato. Cualquier cambio deberá ser de mutuo acuerdo entre el Coordinador
de la Adjudicatario y el Director del Expediente o persona en quien delegue.
En el caso de que el Adjudicatario emplee herramientas adicionales a las acordadas, deberá informar por escrito
de las mismas, junto con la información de origen, versiones, etc. para acordarlo con al Director del Expediente o
Elaborado: 14/04/16
Página: 137/201
Plataforma
El Adjudicatario será responsable de la protección antivirus en cualquiera de los medios de almacenamiento o

transmisión de información empleados.
2.6.4.1. Revisión de documentos
Previo al envío de un entregable, el Adjudicatario deberá asegurarse que los documentos son conformes a los
requisitos descritos en este pliego, normativas y estándares, aplicables y acordados con el Director del
Expediente o persona en quien delegue.
Cada entregable se deberá acordar con el Director del Expediente o persona en quien delegue, quién comprobará
la adecuación del documento al propósito del mismo. El Adjudicatario deberá enviar las portadas firmadas de los
documentos a acordar con el Director del Expediente o persona en quien delegue.
El Adjudicatario hará entrega de los documentos al Director del Expediente o persona en quien delegue (la
entrega se hará siguiendo los procedimientos acordado) con veinte o treinta (20-30) días naturales de antelación
a la fecha acordada para su revisión. Se podrán acordar entre el Coordinador de la empresa Adjudicataria y el
Director del Expediente o persona en quien delegue periodos de tiempo diferentes a éste según la extensión o
complejidad de los documentos objeto de la revisión.
Los cambios acordados en la revisión de los documentos deberán ser aplicados dentro de los quince (15) días
siguientes a dicha revisión.
Todo documento actualizado deberá ser presentado de nuevo a revisión por parte del Director del Expediente o
Todo documento modificado deberá presentar marcas de control de cambios que faciliten su revisión.
2.6.5. Elaborar el Plan de Gestión de la Calidad

El Adjudicatario demostrará que dispone de un Sistema de Aseguramiento de la Calidad establecido para el
desarrollo del contrato.
El Adjudicatario demostrará que aquellas partes de la Empresa responsables de la ejecución del contrato están
certificadas según ISO 9001:2015 (LDEC-44), en Gestión de Calidad para todas las actividades relacionadas con el
desarrollo del contrato (se aceptarán certificados según ISO 9001:2008 que tengan validez durante el periodo de
transición a la versión vigente de la norma).
El Adjudicatario deberá estar reconocido oficialmente, al menos, con un nivel de madurez en CMMI-DEV
(Capability Maturity Model Integration.) Nivel 3 (LDEC-59), en la versión actual, en cada uno de los procesos
aplicables a este proyecto.
Los estándares de Gestión de Calidad aplicables al desarrollo del proyecto se remitirán al Director del Expediente
o persona en quien delegue junto con las evidencias de su cumplimiento.
2.6.5.1. Plan de gestión de la calidad
El Adjudicatario hará uso de todos los procesos de soporte, verificación, validación, revisiones conjuntas,
auditorías y resolución de problemas para ejecutar el Plan de Gestión de la Calidad.
Elaborado: 14/04/16
Página: 138/201
Plataforma
2.6.5.1.1. Aseguramiento de los procesos y del sistema de calidad
El Adjudicatario documentará y ejecutará un Plan de Gestión de la Calidad (LDEC-02) en el que se detallan cómo
el Aseguramiento de la Calidad se aplica a las actividades del contrato.
El Plan de Gestión de la Calidad incluirá, pero no estará limitado a:

- Descripción de los objetivos de Calidad del Sistema aplicables al proyecto
- Organización para el Aseguramiento de la Calidad.
- Actividades de Aseguramiento de la Calidad (verificación, validación, revisiones conjuntas, auditorías y
resolución de problemas) a lo largo del ciclo de vida del proyecto.
- Interfaces con otros procesos.
- Recursos, calendario y responsabilidades para la ejecución de las tareas de Aseguramiento de la
Calidad.
- Identificación de cada entregable.
- Técnicas, métodos, estándares, procedimientos, convenios y herramientas para el desarrollo de las
actividades de Aseguramiento de la Calidad.
- Métricas para el Aseguramiento de la Calidad.
- Procedimientos para subcontrataciones.
- Procedimientos para la gestión de no conformidades, defectos, desviaciones aplicables los entregables
y los procesos.
2.6.5.1.2. Aseguramiento de la calidad del software
El Adjudicatario detallará en el Plan de Gestión de la Calidad (LDEC-02) cómo será aplicado el Aseguramiento de
Calidad del Software a todos los procesos de desarrollo software.
El Plan de Gestión de la Calidad deberá hacer referencia al Plan de Aspectos para la Aprobación del SW del
Suministrador LDEC-26 (PSAA-S).
Todos los procesos definidos y las evidencias de su cumplimiento estarán enfocados a prestar apoyo al
argumento sobre la aplicación de la norma ED153: GUIDELINES FOR ANS SOFTWARE SAFETY ASSURANCE.
2.6.5.2. Auditorías
La organización de Calidad del Adjudicatario realizará, a lo largo del proyecto, auditorías internas, para asegurarse
de que se están siguiendo los procedimientos y métodos establecidos en el Plan de Gestión de la Calidad y en el
Plan de Gestión del Proyecto para la realización de las diferentes actividades definidas en las que Enaire podrá, si
así lo solicita, tener participación propia o a través de terceros.
Las auditorías internas del proyecto estarán especificadas en el Plan de Gestión de la Calidad del mismo. La
definición incluirá: el número de auditorías y los procesos o productos auditados de acuerdo con las
características particulares del proyecto, así como el procedimiento (o referencia) a seguir para su realización.
El Adjudicatario controlará y auditará todos los accesos a elementos que puedan suponer riesgos para funciones
En el plazo más breve posible después de la realización de la auditoría, Garantía de Calidad del Adjudicatario
elaborará un informe sobre la misma.
Elaborado: 14/04/16
Página: 139/201
Plataforma
Los informes de resultados de la auditoría (LDEC-41.3), aunque son internos del Adjudicatario, deberán ser
entregados al Director del Expediente o persona en quien delegue, cuando así sea requerido.
El Sistema de Garantía de Calidad del Adjudicatario registrará y archivará los informes de auditoría, colaborará en
la definición de las Acciones Correctoras y realizará el seguimiento y cierre de las mismas.
2.6.5.3. Proceso de mejora continua
El Adjudicatario establecerá el método para registrar procesos que no se ajustan a los planes y estándares y para
asegurar la resolución de estos casos.
El Adjudicatario implantará un proceso de mejora continua (para métodos, procesos, técnicas, etc.) a lo largo del
ciclo de vida del proyecto.
2.6.6. Elaborar el Plan de Verificación

Las actividades de verificación y validación implantan los procedimientos continuados que permiten garantizar la
correcta ejecución y finalización de una fase del ciclo de vida, poniendo en evidencia los errores, omisiones y
resultados inadecuados tan pronto como sea posible, para evitar procesos de vuelta atrás, centrándose en
aspectos no contemplados por las pruebas.
Las pruebas son actividades encaminadas a verificar y validar que el Sistema, o una parte del mismo, cumple
todos y cada uno de los requisitos para él especificados.
El Plan de Verificación (LDEC-29) incluirá, pero no estará limitado a:

o Organización y responsabilidades para las actividades de verificación, deberá estar definida la
autoridad para resolver cualquier conflicto y la aprobación de los productos / entregables
contractuales.
o Calendario para la ejecución de las tareas de verificación a realizar a lo largo de todo el ciclo de vida
del proyecto, incluyendo la creación de los informes correspondientes.
o Nivel de Integridad aplicable al SW, se debe describir el nivel de integridad acordado aplicable al SW a
entregar (SWAL), cuando existan diferentes niveles de integridad aplicables, se deberá indicar los
componentes que difieran.
o Recursos para el desarrollo de las actividades de verificación, incluyendo las instalaciones (maqueta
de pruebas).
o Documentos, herramientas de verificación HW y SW, técnicas y métodos, estándares, procedimientos
y convenios a aplicar o usar, deberá incluirse la información sobre la cualificación de cada
herramienta, tecnología y método a usar.
o Actividades de verificación a lo largo del ciclo de vida del proyecto (revisiones internas, revisiones
formales, inspecciones, pruebas, etc.) incluyendo para cada actividad de verificación: tareas, métodos
y procedimientos, entradas, salidas, responsables y recursos, y tiempo asignado para su ejecución.
o Interfaces con otros procesos.
o Requisitos para los informes de verificación a crear.
o Registro, solución y comunicación de incidencias, se debe incluir los criterios para la clasificación de
incidencias y las tareas de verificación a ejecutar para comprobar que las incidencias han sido
resueltas.
o Política de desviación, se deben describir los procedimientos y criterios a aplicar cuando exista una
desviación de lo establecido en este plan, considerando la identificación de la tarea afectada, las
Elaborado: 14/04/16
Página: 140/201
Plataforma
razones de la desviación y en impacto en la calidad del SW. Se debe identificar la autoridad

responsable de aprobar la desviación.
o Requisitos para la documentación de pruebas.
o Tareas de soporte para la validación del sistema.
o Abreviaturas y definiciones aplicables al plan.
2.6.6.1. Revisiones
Las revisiones realizadas a lo largo del desarrollo de un proyecto son parte del proceso de Verificación de un
producto.
Las revisiones proporcionarán al Director del Expediente o persona en quien delegue, los medios para evaluar y
supervisar las tareas a realizar por el Adjudicatario, asegurando que se mantiene la integridad del diseño, se
identifican las posibles deficiencias técnicas y se comprueba que se introducen los cambios necesarios.
Las revisiones realizadas por el Director del Expediente o persona en quien delegue, no exime al Adjudicatario de
su responsabilidad de suministrar productos/entregables conformes, cualquier defecto detectado posterior a la
aceptación, deberá ser corregido por el Adjudicatario. El Adjudicatario es el único responsable del contenido y de
la conformidad de los productos/entregables suministrados.
El objetivo, por lo tanto, de las revisiones será:

- evaluar la idoneidad técnica de los productos parciales de cada fase del proyecto.
- asegurar que se cumplen los requisitos establecidos.
- asegurar que los productos/entregables son completos y correctos.
- asegurar la calidad de los productos intermedios y, como consecuencia, del producto final.
El Adjudicatario deberá especificar en su Plan de Verificación las actividades que deben realizarse para llevar a
cabo estas revisiones y su relación con el Plan de Gestión de la Calidad.
Habrá dos tipos de revisiones:

- Formales, con intervención del personal de Enaire, que el Director del Expediente o persona en quien
delegue asigne, siendo aplicable a:
 Revisión de documentos contractuales del proyecto (LDEC), el proceso a ejecutar se describe en el
Anexo B de este pliego.
- Internas, realizadas por el Adjudicatario, a las que el Director del Expediente o persona en quien delegue,
podrá reservarse el derecho de asistir. En este caso, el Coordinador de la empresa Adjudicataria deberá
enviar deberá enviar las evidencias de su realización y resultados al Director del Expediente o persona en
quien delegue. En este tipo se encuadran:
 Revisión de documentos contractuales.
 Revisión de Procedimientos de Prueba.
 Revisión de Disponibilidad para Pruebas (TRR).
 Revisión de Pruebas.
 Revisión de Requisitos de SW (SSR).
 Revisiones de Calidad de Procesos y Productos.
 Revisión de Conformidad del SW.
Elaborado: 14/04/16
Página: 141/201
Plataforma
2.6.6.2. Verificación de entregas parciales
El grupo de Verificación, Validación y Pruebas o el grupo de Garantía de Calidad del Adjudicatario, realizará las
tareas de verificación aplicables a Entregas Parciales para demostrar la capacidad funcional alcanzada en los
puntos establecidos en la planificación de integración y pruebas y comprobar si se cumplen las prestaciones del
conjunto de elementos integrados.
Estas revisiones no se darán por finalizadas hasta que el Director del Expediente o personas en quien delegue, no
haya realizado el mínimo de pruebas que considere suficientes para demostrar que se ha alcanzado la capacidad
funcional y las prestaciones marcadas como objetivo.
El Director del Expediente o personas en quien delegue, a la vista del protocolo de pruebas presentado y/o
resultados obtenidos, preparará un protocolo de pruebas complementario que deberá ser ejecutado como parte
de las pruebas de validación de las entregas parciales.
2.6.7. Elaborar el Plan de Pruebas de Integración SW

2.6.7.1. Consideraciones generales sobre las pruebas
El objeto de las pruebas es asegurar el correcto funcionamiento de los elementos del Sistema conforme a los
requisitos especificados.
El Adjudicatario deberá realizar y llevar a cabo un Plan de Pruebas de Integración SW (LDEC-18) incluyendo los
Procedimientos de Prueba y registrar los datos y resultados de las pruebas para generar los correspondientes
Informes de Pruebas de Integración SW (LDEC-13.1).
El orden de realización de las pruebas será el adecuado a las dependencias entre ellas, comenzando por los
componentes de más bajo nivel y terminando por las pruebas del SW completo.
El Adjudicatario proporcionará asesoramiento y soporte a la realización de las de Pruebas de Aceptación al

Director del Expediente o personas en quien delegue, en las siguientes actividades:
 Instalación del SW para las Pruebas de Aceptación.
 Elaboración de la Documentación de Pruebas de Aceptación.
 Ejecución de las Pruebas de Aceptación.
En general los siguientes requisitos son aplicables a todas las pruebas:

 el Director del Expediente o personas en quien delegue tendrá derecho a presenciar cualquier prueba que se
realice.
 toda herramienta necesaria para la realización de una prueba, deberá ser documentada y esta
documentación deberá ser acordada con el Director del Expediente o persona en quien delegue.
 todos los requisitos SW modificados deberán ser verificados, a través de pruebas o método de verificación
definido y acordado con el Director del Expediente o persona en quien delegue, así mismo se deberán
entregar las evidencias documentales correspondientes que demuestren que han sido verificados, su estado
de conformidad y su impacto en los Requisitos de Usuarios (RUs).
 el Adjudicatario podrá obviar las pruebas de aquellos Elementos de Configuración (CIs) obtenidos en otros
contratos con Aena (hoy Enaire) y que no hayan sufrido ningún cambio.
 el Adjudicatario deberá remitir al Director del Expediente o persona en quien delegue, los resultados de las
pruebas de los ítems comerciales.
Elaborado: 14/04/16
Página: 142/201
Plataforma
 el Director del Expediente o persona en quien delegue podrá requerir pruebas acerca de cualquier requisito
del PPT, de la Especificación de Requisitos del Sistema o de cualquier otro del que haya constancia
documental.
 la terminación de las pruebas, no implicará en ningún caso la asunción de la no existencia de defectos o de
incumplimiento de otros requisitos.
 Se seguirá la norma ISO/IEC/IEEE 29119-2:2013 para la planificación y documentación de las pruebas.
2.6.7.2. Pruebas del SW
Se considerarán dos tipos de pruebas diferentes:
 Pruebas internas del Adjudicatario.- Se requerirá contractualmente la realización de pruebas por parte del
Adjudicatario sin la participación directa de personal de Enaire. El Director del Expediente o personas en
quien delegue podrá participar en estas pruebas en calidad de observadores y con el fin de optimizar la fase
de pruebas de aceptación. Los resultados de la Pruebas internas estarán expresados (trazados) a nivel de los
Requisitos de Sistema / Subsistema / CSCI y deberán estar disponibles para ser analizados por parte del
Director del Expediente o personas en quien delegue. El Director del Expediente o persona en quien delegue
tomará como referencia estos resultados para establecer los criterios y el dimensionado de la actividad de
las Pruebas formales de aceptación.
Como parte de este tipo de pruebas internas se incluyen las Pruebas de Aceptación en Fábrica, que deberán
ser realizadas por el Adjudicatario, empleando sus propios Medios Humanos y materiales (entornos de
prueba, herramientas de pruebas, simuladores, maquetas, equipos, subsistemas (HMI, supervisión, etc.), datos
de entorno y configuración y cualquier elemento necesario para el completo y correcto desarrollo de las
pruebas). La finalización de las Pruebas de Aceptación en Fábrica será acordada entre el Coordinador de la
empresa Adjudicataria y el Director del Expediente o persona en quien delegue.
Para cualquier entrega de SW que incluye un cambio en el mismo, el adjudicatario entregará un Informes de
Pruebas de Integración SW (LDEC-13.1) en el que conste el alcance y el estado final de las pruebas ejecutadas
en fábrica para el SW que se va a entregar a Enaire.
 Pruebas formales de aceptación del Sistema.- Además del soporte requerido contractualmente, los
resultados de la pruebas de aceptación serán válidas para el Adjudicatario quien deberá realizar las
correcciones de las incidencias detectadas durante la ejecución de estas pruebas. Dirigidas por el Director del
Expediente o persona en quien delegue, con presencia del Coordinador del Adjudicatario. Estas pruebas
pueden ser:
- Pruebas de Aceptación de Sistema en las instalaciones que el Director del Expediente defina, para este
expediente será el Centro de Experimentación y Desarrollo (CED), a nivel de los Requisitos de Sistema /
Subsistema.
- Pruebas de Aceptación de Sistema en Emplazamiento a nivel del comportamiento con las interfaces
externas, la infraestructura HW instalada y los Datos de Adaptación de Usuario.
La planificación, a alto nivel, de las pruebas deberá estar incluida en el Plan de Gestión del Proyecto y en el Plan
de Verificación.
Se deberán definir pruebas para demostrar los diferentes tipos de requisitos definidos en las Especificaciones del
Sistema (Funcionales, Operativos, etc.).
Elaborado: 14/04/16
Página: 143/201
Plataforma
Los requisitos de Prestaciones y Capacidades del Sistema se demostrarán mediante la realización de una Prueba
de Capacidades y Carga del Sistema que será realizada sobre el Sistema funcionando correctamente y en estados
degradados del mismo.
Se definirá también una prueba de Estabilidad del Sistema que deberá realizarse en las instalaciones que el
Director del Expediente defina, para este expediente será el Centro de Experimentación y Desarrollo (CED). El
Adjudicatario reflejará en el procedimiento correspondiente a esta prueba, cuando sea solicitado por el Director
del Expediente o persona en quien delegue, la duración de la misma, la carga del Sistema, las acciones a realizar,
las medidas a obtener y los criterios de evaluación de los resultados. Como referencia esta prueba se realizará
con diferentes niveles de carga del Sistema y simulando acciones de mantenimiento preventivo y correctivo del
mismo.
2.6.7.3. Documentación de pruebas
La documentación de pruebas estará formada por el Plan de Pruebas de Integración SW (LDEC-18), los
procedimientos o listas de CASOS de Pruebas y los Informe de Pruebas de Integración SW (LDEC-13.1). La
decisión sobre el uso de Procedimientos de Prueba (LDEC-12.1) detallados con secuencias de acciones-pasos de
prueba etc., o listas de CASOS de Prueba se tomará en función de criterios de oportunidad y de gestión de
proyecto por el Director del Expediente o persona en quien delegue.
El Plan de Pruebas de Integración SW (LDEC-18), deberá describir, al menos, el alcance de las pruebas a realizar
(funcionalidades, componentes, CP), la estrategia de pruebas aplicable, incluyendo pruebas de regresión y los
criterios para la finalización de las pruebas, entorno de pruebas, recursos, calendario, documentos de prueba.
Los procedimientos de prueba deberán incluir la definición de los "Casos de Prueba" (LDEC-12.1) y de los pasos
que deben realizarse durante la ejecución de la prueba, especificando, así mismo, los requisitos que cada caso
pretende probar (trazabilidad), la configuración bajo pruebas que es necesaria y las herramientas a utilizar.
También se especificarán los valores concretos de los datos de entrada/salida para cada caso de prueba.
Los procedimientos serán realizados por el Adjudicatario teniendo en cuenta las características particulares del
Sistema bajo pruebas.
Deberán estar aprobadas las Especificaciones de Requisitos que van a servir de base para verificar si el Sistema o
el Elemento bajo pruebas funciona de forma correcta.
Los documentos referentes a Interfaces, Datos de Adaptación u otros específicos, etc., que vayan a ser utilizados
en las pruebas, deberán también estar aprobados (para pruebas formales) o definido su estado.
El Informe de Pruebas de Integración SW (LDEC-13.1) deberá incluir, al menos, un resumen de la ejecución de las
pruebas, con la información de participantes, número de pruebas realizadas, identificación de las incidencias
abiertas con su correspondiente prioridad y su impacto en seguridad, y puntos abiertos aparecidos, conclusiones,
puntos de acción, pruebas realizadas (especificando para cada prueba: número, nombre, fecha de ejecución,
trazabilidad con los requisitos probados y resultado), Incidencias registradas, métricas de pruebas, configuración
de entorno de pruebas: HW, SW, documentación utilizada en las pruebas, herramientas, datos de adaptación y
escenarios, información en relación a la demostración del cumplimiento de las mitigaciones y barreras
identificadas en los Estudios de Seguridad (ESs), análisis de incidencias de los Requisitos de Seguridad (Safety).
Elaborado: 14/04/16
Página: 144/201
Plataforma
2.6.7.4. Requisitos previos para la realización de pruebas

Antes de la ejecución de las pruebas internas y de las pruebas formales se realizará una Revisión de
Disponibilidad para Pruebas.
Se verificará también que se encuentran disponibles la configuración bajo pruebas y las herramientas de pruebas
necesarias.
Se realizará una Auditoría de Configuración Física para establecer la configuración (tanto HW como SW) antes del
comienzo de las pruebas. Cualquier cambio a la misma será notificado, registrado por Control de Configuración y,
en su caso, acordado con el Director del Expediente o persona en quien delegue.
Antes de la realización de las pruebas formales se constituirá un Equipo de Pruebas formado por el Director del
Expediente o personas que en su momento se designen y por representantes del Adjudicatario (Ingeniería de
Sistemas, Ingeniería de SW, Garantía de Calidad).
El Adjudicatario definirá en el Plan de Gestión de la Calidad del Proyecto las actividades que Garantía de Calidad
del Adjudicatario deberán realizar antes, durante y después de la ejecución de las pruebas, así como las normas a
seguir.
El Adjudicatario registrará los resultados de las pruebas durante la ejecución de las mismas. Estos resultados
serán evaluados al final de cada una de las pruebas y, de forma global, al final de las mismas. Esta evaluación
será parte de la Auditoría de Configuración Funcional.
Al final de las pruebas el Adjudicatario elaborará el Informe de Pruebas de Integración SW (LDEC-13.1).
2.6.7.5. Pruebas de aceptación en emplazamiento

Previo a la pruebas de aceptación, el Coordinador de la empresa Adjudicataria entregará el Informe Final de
Producto (LDEC-41.2), que describe el estado final del SW, que será sometido a las pruebas de aceptación, y su
documentación correspondiente.
El Coordinador de la empresa Adjudicataria dará soporte al Director del Expediente o persona en quien delegue,
para la realización de las Pruebas de Aceptación en Emplazamiento incluyendo la entrega de las herramientas de
pruebas necesarias, ayuda a la integración y cualquier ayuda requerida para la completa y correcta ejecución de
las mismas.
El Adjudicatario someterá a Control de Configuración y mantenimiento cualquier problema detectado durante las
Pruebas de Aceptación en Emplazamiento.
2.6.7.5.1. Informe final de producto
El Coordinador de la empresa Adjudicataria producirá, mantendrá y hará entrega del Informe Final de Producto
(LDEC-41.2) acordado con el Director del Expediente o persona en quien delegue, que cubra el ciclo de vida del
proyecto.
El objeto del Informe Final de Producto es mostrar toda la información relacionada con la versión del SW
entregado. El contenido mínimo será:
o Identificación de la versión del SW asociada a este informe.
Elaborado: 14/04/16
Página: 145/201
Plataforma
o La lista completa de documentación de planificación, su versionado y su estado.

o La lista completa de los informes esperados.
o Calidad (especificación)
o Configuración (registros de control de configuración)
o Pruebas de integración SW.
o El sumario de las auditorías internas contra los procesos definidos para el proyecto.
o Lista de acciones abiertas para el proyecto.
2.6.8. Procedimientos ante desviaciones y concesiones

Se definirá la autorización para apartarse de los requisitos originalmente
especificados a la prestación del servicio y sus productos asociados a entregar por el Adjudicatario, antes de su
realización. El permiso de desviación se dará para una cantidad limitada de producto o para un periodo de tiempo
limitado, y para un uso específico.
Las concesiones, se autorizan para aceptar un servicio, utilizar o liberar un producto que no es conforme con los
requisitos especificados. La concesión está limitada a la entrega de un producto o prestación del servicio que
tiene características no conformes, dentro de límites definidos por un tiempo o una cantidad de productos
acordados.
Cualquier desviación y concesión deberá ser acordada entre el Coordinador de la empresa Adjudicataria y el
Director del Expediente o persona en quien delegue, previa justificación del impacto técnico, económico, de calidad
y plazo.
Las concesiones y desviaciones deberán ser los últimos recursos a utilizar por el Adjudicatario, estarán limitadas
en su alcance y no deberán ser usadas para una alteración permanente de los requisitos, estando orientadas a
permitir continuar con la prestación del servicio del Adjudicatario a corto plazo. Los cambios permanentes
deberán seguir el procedimiento de acciones correctivas establecido.
2.6.9. Actividades de verificación CE de sistemas (Conformity assessment)

Previamente a la entrada en servicio de los sistemas de la red europea para la gestión de tránsito aéreo (EATMN),
éstos deben someterse a un proceso de Verificación CE que tenga como resultado final una Declaración CE de
Verificación de Sistemas, que garantice que el sistema satisface los Requisitos Esenciales del Anexo II del
Reglamento CE552/2004.
Como metodología a aplicar para el cumplimiento del reglamento CE552/2004 se aplicará la descrita en el
documento S22-07-PES-001
Esta metodología se estructura en varias fases, en cada una de las cuales el Adjudicatario deberá cumplir con los
requisitos que a continuación se detallan.
En lo sucesivo en este apartado, en el marco de la Verificación CE de Sistemas, cuando se haga referencia a
componentes HW o SW que conforman la arquitectura del sistema.
Elaborado: 14/04/16
Página: 146/201
Plataforma
Toda versión del producto (parcial o final) que se ponga en servicio como consecuencia de este expediente deberá
llevar asociada una Declaración CE de Verificación de Sistemas. Esto implica que para cada puesta en servicio
(parcial o final) se seguirá el proceso que se describe a continuación.
2.6.9.1. Preparación de la verificación CE de sistemas
2.6.9.1.1. Determinación del sistema
Según el Anexo I del Reglamento CE552/2004 relativo a interoperabilidad (IOP), la red europea de gestión del
tránsito aéreo (EATMN) se subdivide en 8 sistemas genéricos potencialmente afectados por la aplicación del
mismo.
Se tendrán en cuenta, para la ejecución de este proceso de Verificación CE de Sistemas, que el sistema SACTA
pertenecen al grupo 3 (Sistemas y Procedimientos para los Servicios del Tránsito Aéreo)
El Adjudicatario realizará una descripción del sistema sujeto a la Verificación CE en su entorno operacional, que
contendrá, entre otra información, la descomposición del sistema en componentes.
2.6.9.1.2. Determinación de la reglamentación aplicable
La reglamentación de interoperabilidad aplicable a cambios del sistema SACTA de este expediente es la siguiente:
 Reglamento EC 552/2004
De entre los requisitos Esenciales del Reglamento CE 552/2004, a continuación se identifican aquellos requisitos
que afectan al sistema, y en base a los cuales se realizará la Verificación CE:
Anexo II, Parte A (Requisitos Generales GR):

 GR1: Funcionamiento continuo
 GR2: Apoyo a los nuevos conceptos de operación
 GR3: Safety
 GR4: Coordinación civil-militar
 GR5: Requisitos medioambientales
El alcance de la aplicación de cada uno de ellos a los cambios objeto de este expediente será determinado por
Enaire a través de la Matriz de Verificación que se define a continuación.
2.6.9.2. Ejecución de la verificación CE

En este segundo grupo de actividades se recogerán todas las evidencias necesarias para que Enaire pueda
elaborar finalmente la Declaración CE de Verificación de Sistemas y su Expediente Técnico asociado.
2.6.9.2.1. Plan de Verificación CE del sistema
Enaire elaborará un Plan de Verificación CE del Sistema en el que se describirán todas las tareas a realizar para
ejecutar la verificación CE del sistema SACTA.
Basado en las tareas realizadas previamente por Enaire (Determinación del Sistema y Determinación de la
Reglamentación Aplicable), este plan describirá:
- El sistema.
- La Reglamentación aplicable.
Elaborado: 14/04/16
Página: 147/201
Plataforma
- Los Requisitos de interoperabilidad.

- Las posibles restricciones en materia de verificación de sistemas impuestas por la reglamentación aplicable
- Las tareas de Verificación, de acuerdo al Anexo IV de la 552/2004. Se detallará la documentación/evidencias
a producir en cada una de las 4 fases indicadas en dicho Anexo IV.
Dentro del Plan de Verificación se incluirá la Matriz de Verificación del Sistema. En esta matriz se presentará la
trazabilidad entre los requisitos o cambios que son objeto del proceso de Verificación CE, la documentación de
referencia utilizada en su elaboración, los requisitos de interoperabilidad aplicables y las fases del desarrollo en
las que se verificará cada uno de los Requisitos de Usuario (RUs).
Basándose en la Matriz de Verificación, y con el formato que definirá Enaire, el contratista elaborará la
denominada Matriz de Verificación Extendida (LDEC-42). En esta nueva matriz se indicará, para cada uno de los
requisitos o cambios incluidos en ella, las evidencias aportadas para cada una de las 4 fases de la verificación, de
acuerdo con lo especificado en los apartados siguientes.
2.6.9.2.2. Comprobación del diseño del sistema
En esta fase se elaborarán las evidencias necesarias para demostrar que el diseño del sistema cumple con la
Reglamentación de Interoperabilidad aplicable.
El contratista entregará:
 Declaraciones CE de Conformidad o Idoneidad para el Uso de los Componentes que forman el sistema.
 Documentación de diseño del sistema.
 Documentación de Safety que evidencie el cumplimiento del diseño del sistema con los requisitos de
seguridad establecidos.
 Informe de evidencias de la trazabilidad (Matriz de verificación Extendida) entre los requisitos o cambios
objeto de verificación CE en esta fase (según se indica en la Matriz de verificación) y los Requisitos de
Sistema (documentación de diseño del sistema) derivados de ellos.
2.6.9.2.3. Comprobación del desarrollo en integración del sistema
Esta actividad se realiza para verificar que el sistema ha sido desarrollado e integrado en fábrica de acuerdo al
diseño y cumple con los requisitos de interoperabilidad, verificados en un entorno de pruebas en fábrica.
 Informe de resultados de las pruebas de integración en fábrica (pruebas internas) que evidencie la
verificación de los requisitos o cambios objeto de Verificación CE.
 Informe de evidencias de la trazabilidad (Matriz de verificación Extendida) entre los requisitos de usuario
objeto de verificación CE en esta fase (según se indica en la Matriz de verificación) y el Informe de Pruebas
anterior.
2.6.9.2.4. Comprobación de la integración operacional del sistema
Esta actividad se realiza para verificar que el sistema cumple con los requisitos identificados en su entorno
operacional, exigidos en el Pliego de Prescripciones Técnicas, y por tanto conforme a los requisitos de
interoperabilidad, verificados en un entorno operativo.
Elaborado: 14/04/16
Página: 148/201
Plataforma
El Director del Expediente definirá el entorno operacional, siendo éste en principio el Centro de Experimentación y
Desarrollo (CED).
Las evidencias correspondientes a esta fase son responsabilidad de Enaire.
2.6.9.2.5. Comprobación de los procedimientos de mantenimiento del sistema
Esta actividad se realiza para verificar que los procedimientos de mantenimiento del sistema cumplen con los
requisitos identificados.
 La documentación de operación y mantenimiento requerida en este PPT.
 Certificado de cumplimiento con la normativa de calidad ISO: 9001.
 Informe de evidencias de la trazabilidad (Matriz de verificación Extendida) entre los requisitos o cambios
objeto de verificación CE en esta fase (según se indica en la Matriz de Verificación) y los contenidos de los
manuales de operación y mantenimiento.
2.6.10. Gestión safety

Las exigencias de Seguridad (Safety) en ATM imponen la necesidad de realizar unos procesos formales y
sistemáticos que cumplan los requisitos del Reglamento (CE) Nº 1035/2011 y en particular la ESARR 4 sobre
análisis y mitigación de riesgos en ATM para los cambios relacionados con la seguridad.
2.6.10.1. Elaborar plan de gestión de safety
El Adjudicatario entregará un Plan de Gestión de Safety (LDEC-35) los siguientes contenidos:

 Organización interna de Safety y su interrelación con otros grupos de ingeniería.
 Planificación de actividades propias de safety y su relación con el ciclo de vida del proyecto.
 Entradas y Salidas asociadas a cada una de las tareas de safety.
 Herramientas y Técnicas utilizadas.
 Seguimiento y revisiones del Plan de Seguridad.
Este plan se deberá actualizar por cambios producidos en la gestión del Proyecto, actualización de estándares y
procedimientos en materia de seguridad que le sean aplicables, por cambios de versiones que se pongan en
servicio del sistema objeto de este pliego, u otras razones que a petición del Director del Expediente o persona a
quien delegue considere conveniente.
2.6.10.2. Informes de pruebas de integración
El Adjudicatario debe demostrar que todas las mitigaciones y barreras identificadas en los ESs como necesarias
(para reducir el impacto de la ocurrencia de las amenazas analizadas o su frecuencia) han sido correctamente
implementadas en el producto SW mediante los Informes de pruebas de integración (LDEC-13.1), referidos en el
apartado 2.6.7.
Además dichos informes de pruebas analizarán el conjunto de incidencias reportadas al sistema y en un estado
no solucionado en la versión a instalar, si las hubiera, incluyendo una demostración de que estas incidencias no
incumplen los requisitos de seguridad establecidos.
Elaborado: 14/04/16
Página: 149/201
Plataforma
2.6.11. Gestión de SW assurance

2.6.11.1. Plan de garantía de la integridad del SW del suministrador (PSAA-S)
El adjudicatario entregará un Plan de garantía de la integridad del SW del suministrador (PSAA-S, LDEC-26)
cuyo contenido mínimo consistirá de lo siguiente:
 Matriz de cumplimiento de los objetivos de la ED153.
2.6.11.2. Informe de asignación definitiva de SWAL

El adjudicatario, llevará a cabo la asignación de SWAL definitivo teniendo en cuenta el material guía para la
asignación de SWAL de Enaire [N17] y elaborará un informe de Asignación definitiva de SWAL (LDEC-67) cuyo
contenido incluirá:
 Asignación del SWAL fase producto, identificados por ENAIRE, a las funciones.
 Elaboración de informe de descripción de relación entre CSCs, Servicios ATC y HWCI (Descripción de los
componentes CSC del sistema).
 las restricciones de diseño identificados
durante el proceso de asignación fase producto.
 Confirmación de la asignación del SWAL a los componentes SW del sistema. El SWAL mínimo será
SWAL4.
 Descripción del sistema donde se identifican las redundancias SW y todas la barreras de protección
entre elementos SW con distinto nivel de integridad (estos incluyen cualquier SW cuya funcionalidad este
integridad en los equipos de SACTA pero que no tienen un nivel integridad demostrable.
2.6.11.3. Sumario de garantía de la integridad del SW del suministrador (SAS-S)

El adjudicatario entregará un Sumario de garantía de la integridad del SW (SAS-S), LDEC 47.1 cuyo contenido
mínimo consistirá de lo siguiente:
 Confirmación que las redundancias y barreras identificadas en el PSAA-S.
 Identificación del producto SW:
o Versión del SW
 Lista de evidencias identificadas, para la versión del SW dentro del alcance de este sumario, en la matriz
de cumplimiento. La lista de evidencias irán acompañados por los siguientes atributos:
o Título del Documento
o Id/Referencia del Documento
o Sección del documento que contiene la evidencia
o Nombre del responsable
o Fecha de aprobación de documento
 Lista de deficiencias asociadas a la generación de las evidencias identificadas durante el ciclo de vida del
SW.
 Plan de acción de corrección de las deficiencias.
Nota: Cada SAS-S solo demostrara la integridad para una sola versión o actualización del SW. Todas las
evidencias identificadas en el SAS-S serán evidencias directamente asociadas a la versión de SW identificadas al
mismo SAS-S.
Elaborado: 14/04/16
Página: 150/201
Plataforma
2.6.11.4. Demostración de la integridad de COTS SW

Para todo COTS SW nuevo se entregará un Informe de Conformidad de COTS SW (CAS) LDEC-47.2, para COTS
SW nuevos y actualizados, cuya entrega se hace en dos fases (CAS I y CAS II).
Se considera COTS SW nuevo todo COTS SW que se instala por primera vez o aquel cuyo modelo de COTS SW ya
instalado vaya a cambiar.
El contenido del CAS I incluirá lo siguiente:

 Trazabilidad entre los requisitos del SW del sistema con las funciones o servicios del COTS SW nuevo.
 Análisis e identificación de funciones SW no intencionadas e Identificación de las mitigaciones necesarias
para evitar la ejecución de funcionalidad indeseada del COTS SW nuevo o que su ejecución no tenga un
impacto en safety.
 Identificación de decisiones de diseño y cambios en la arquitectura o funcionalidad SW del sistema por el uso
de COTS SW nuevo.
 Actualización de los procesos de soporte (calidad, gestión de la configuración, documentación, verificación,
etc.) para incluir el tratamiento de COTS SW nuevo.
 Identificación de los requisitos SW de integridad (SRD) y FMEA SW (capacidad, precisión, tiempos, uso de los
recursos SW en el HW elegido, robustez a condiciones anormales de operación y tolerancia a la sobrecarga)
de la interfaz entre los componentes del sistema y el COTS SW.
Con la entrega en el CED del producto COTS SW se entregará la actualización del CAS de la primera fase
(denominado CAS II) añadiendo lo siguiente:
 Evidencias de trazabilidad completa entre los distintos niveles de especificación y entre los requisitos y las
pruebas asociadas a los requisitos del COTS SW nuevo.
 Resultados de las pruebas y/o actividades de verificación específica (incluidas en el informe de pruebas de
integración SW) para todas los requisitos del COTS SW nuevo.
 Registro de incidencias no cerradas.
 Identificación del impacto de incidencias no cerradas.
2.6.11.5. Informe de conformidad de COTS para actualizaciones del COTS SW
Para cada actualización del COTS SW el adjudicatario entregará un único CAS (LDEC-47.2) que además de los
elementos descritos a continuación incluye los contenidos identificados para CAS I y CAS II. Las evidencias
incluidas en el CAS serán solo para aquellos elementos del COTS SW que cambian (funciones nuevas, modificadas
y eliminadas):
 Identificación de la versión y fecha de publicación de la actualización.
 Identificación de las prestaciones nuevas o modificadas obtenidas con la actualización del COTS SW.
 Identificación de las incidencias resueltas con la actualización.
2.6.12. Prestación del servicio de formación al personal de Enaire

El objetivo es formar al personal de Enaire, de manera que adquieran los conocimientos necesarios para hacer
uso de las mejoras funcionales realizadas.
El número de sesiones formativas necesarias y el lugar donde se desarrolle el servicio de formación se concretará
en los Planes de Formación, pudiendo realizarse en las instalaciones que el Director del Expediente determine y
no siendo superior a tres sesiones de 24 horas por sesión.
Elaborado: 14/04/16
Página: 151/201
Plataforma
El Adjudicatario preparará y entregará al Director del Expediente o persona en quien delegue, un Plan de
Formación (LDEC-16) que cubra todos los aspectos de la prestación del servicio de formación, tales como
calendario, recursos y medios de formación.
Previo a la ejecución de la formación, el Adjudicatario deberá entregar el Material didáctico para la formación
(LDEC-39.1).El Material didáctico para la formación deberá aportarse a la División de Desarrollo Profesional en
formato digital y editable.
El Adjudicatario prestará el servicio de formación al personal de Enaire en las instalaciones que el Director del
Expediente o persona en quien delegue o designe.
Al finalizar la acción formativa, el Adjudicatario deberá entregar un Informe de la Formación impartida por
emplazamiento (LDEC-39.2)
La prestación del servicio de formación al personal de Enaire, ligadas a este expediente estarán sujetas a lo
2.6.13. Servicios logísticos

2.6.13.1. Elaborar el manual técnico de mantenimiento (MTM)
1) El Adjudicatario hará entrega al Director del Expediente o persona en quien delegue, del Manual Técnico de
Mantenimiento del Sistema (MTM) LDEC-15, en el que se detallarán todas aquellas actividades y
procedimientos necesarios para el mantenimiento del sistema a lo largo de todo su ciclo de vida.
2) En caso de existir un Manual General de Explotación (MGE) editado por Enaire para la Familia de
Instalación objeto del expediente, la propuesta del Manual Técnico de Mantenimiento entregada por el
Adjudicatario, se basará en este MGE, desarrollando los procedimientos reflejados en el mismo.
3) Para la generación del Manual Técnico de Mantenimiento (MTM) entregado por expediente, el Adjudicatario
coordinará con la División de Explotación Técnica del SNA (DETSNA), a través del Director del Expediente o
persona en quien delegue, su elaboración. Una vez realizado, se entregará a la DETSNA una copia.
4) En general el Manual Técnico de Mantenimiento deberá contener:

 Portada: La primera página de los Manuales de Mantenimiento estará compuesta por el código, fecha y
título del Manual.
 Hojas de Control: Se detallan datos como el autor del Manual, la lista de distribución, los cambios
introducidos, etc.
 Índice: Incluirá un listado de los títulos de los capítulos, secciones, apartados y apéndices, en orden de
aparición en el texto, indicando la página en que se inicia cada una de estas unidades. En el caso que
haya tablas y/o figuras, éstas también estarán referenciadas en un índice aparte.
 Capítulo 1: "Información General": Incluirá directrices e información de tipo general relativa al tema objeto
del Manual.
 Capítulo 2: "Características Técnicas y Teoría de Funcionamiento": Incluirá la descripción resumida de las
funciones, características técnicas y teoría del funcionamiento de las Instalaciones y Elementos objeto
del Manual.
 Capítulo 3: "Valores Nominales y Tolerancias": Incluirá los valores nominales y tolerancias prescritas para
las Instalaciones y Elementos objeto del Manual.
Elaborado: 14/04/16
Página: 152/201
Plataforma
 Capítulo 4: "Programación de Mantenimiento": Debe incluirse en una tabla el listado de las actividades
esenciales de mantenimiento que SE PROPONE realizar de una forma programada periódica, sugiriendo
la periodicidad. Así mismo, se indicarán aquellas tareas, que sin tener carácter periódico se deben
realizar como acción correctiva o simplemente a demanda (caracterizándolas como Especiales). En caso
de existir MGE, se debe basar en éste.
 Capítulo 5: "Procedimientos de Mantenimiento": Incluirá, de forma detallada, y paso a paso, los
procedimientos a seguir para la realización de todas las actividades de mantenimiento programadas o no
programadas, indicando, en su caso, las precauciones de seguridad a adoptar para la realización de los
mismos. En caso de existir MGE, se deben desarrollar los procedimientos reflejados en éste
 Capítulo 6: "Verificación en Vuelo": Incluirá, en aquellos Manuales en que sea necesario, los
procedimientos a seguir en tierra para la realización de este tipo de inspecciones.
 Capítulo 7: "Varios": Incluirá todo aquello que, por su naturaleza, no es apropiado introducir en los
capítulos anteriores. Es un capítulo opcional, no siendo obligatoria su inclusión en todos los Manuales.
 Adicionalmente a estos capítulos, se podrán incluir todos los apéndices necesarios para completar la
información contenida en el Manual. el Adjudicatario deberá incluir siempre al menos un apéndice con
los impresos de Registros de Prestaciones Técnicas aplicables a la Instalación objeto del Manual. En
estos impresos se anotarán todos los resultados y medidas obtenidas durante las pruebas contenidas
estos impresos, además de que en cada procedimiento se deberá indicar qué impreso utilizar y cómo
hacerlo.
2.6.13.2. Manuales del sistema y manuales de usuario
Se realizará una actualización de los Manuales de Usuario del Sistema SACTA (LDEC-22) y de los Manuales del
Sistema /Manual del Operador del Sistema (LDEC-21) que pudieran verse afectados por la implementación de los
Requisitos contenidos en este PPT.
2.6.13.3. Garantías
1) Hasta la finalización del período de garantía del software, a contar desde su recepción y cada vez que se
produzca una incidencia, avería o fallo en la funcionalidad del software, el Adjudicatario estará obligado a
realizar las reparaciones necesarias para devolverlo a su estado operativo correcto en el menor tiempo
posible.
2) Para asegurar tales objetivos, el Adjudicatario elaborará los procedimientos correspondientes con objeto
de:
 Asegurar que los detalles de los problemas y cambios son documentados, controlados,
mantenidos, diseminados a todos los afectados y/o interesados e informadas las autoridades en
el caso de cambios o actualizaciones que requieran su aprobación.
 Implementar todos los cambios acordados de acuerdo con el Plan de Gestión de la Configuración.
 Asegurar que las versiones que incluyan cambios serán entregadas en las fechas acordadas.
 Asegurar una solución rápida y eficaz.
 Documentar cualquier impacto en los datos y parámetros de adaptación / configuración,
documentación u operación del sistema.
 Permitir la integración y pruebas del sistema junto con otros sistemas o productos cuyo
mantenimiento se haga de forma independiente a éste.
Elaborado: 14/04/16
Página: 153/201
Plataforma
 Establecer diferentes niveles de servicio incluyendo los tiempos de respuesta para la evaluación
de problemas y soporte 24 Horas, los 365 días del año.
3) El Adjudicatario deberá, sin coste adicional y hasta la fecha de finalización del período de garantía:
- subsanar o sustituir todos los defectos de diseño, material, mano de obra, fabricación y
funcionamiento que apareciesen en cualquiera de los equipos suministrados o en las funciones de la
nueva versión del Sistema SACTA resultante del proceso de desarrollo de Software (lo que incluye el
coste de los medios humanos y materiales necesarios para ello).
- actualizar el software de base durante el período de garantía.
- prestar un servicio de asesoramiento al Director del Expediente o persona en quien delegue, en la
preparación de los procedimientos para la operación y mantenimiento del Sistema.
4) La garantía se extiende por el período de dos (2) años a partir de la firma del Acta de Recepción y
Liquidación Provisional de cada elemento.
5) El Adjudicatario detallará el nivel de servicio en garantía que ofrece a Enaire en el Plan de Gestión del
Proyecto LDEC-01.
6) Además, el Adjudicatario se comprometerá al mantenimiento del objeto del Contrato durante el plazo de
cinco (5) años, si el órgano de contratación así lo solicitara, indicando el precio de realización de dicho
servicio y las fórmulas de incremento para años sucesivos.
2.6.14. Calendario de los entregables

La entrega de todos los documentos y productos objeto de este expediente (LDECs) deberán estar planificados en
su entrega, previendo el tiempo necesario para poder ser acordado con el Director del Expediente o persona en
quien delegue, antes del inicio de la fase o proceso en la que se aplicará.
2.6.15. Criterios sujetos a las evidencias

Los procesos definidos proporcionarán la estructura y contenido de todas las evidencias necesarias para poder
determinar su cumplimiento. Las evidencias necesarias para determinar el cumplimiento de un proceso, se
proporcionará al cliente antes de la finalización de la fase en la cual corresponde.
2.7. Lista de documentación a entregar por el adjudicatario (LDEC)

1) Este apartado relaciona los documentos contractuales que deberán ser entregados por el Adjudicatario
como parte del proyecto y las fases en que deberán ser generados de acuerdo con lo especificado en este
PPT.
2) La documentación contractual ligada a este expediente estará sujeta a lo exigido en el Anexo B Normas
3) El Adjudicatario deberá incluir esta lista en su Plan de Gestión del Proyecto, especificando para cada
documento, su periodicidad y las fechas concretas de entrega.
4) La lista incluida a continuación muestra el número de LDEC (número único) asociado a cada documento o
producto, su título, la fase del proyecto en que deberá entregarse.
Elaborado: 14/04/16
Página: 154/201
Plataforma
5) La lista de documentación a entregar por el Adjudicatario (LDEC) es la lista de documentación inicial que el
Adjudicatario deberá presentar al Director del Expediente y que se establece en el PPT. Antes del inicio del
proyecto, se acordará entre el Adjudicatario y el Director del Expediente cuales son los documentos
aplicables a este proyecto, sus actualizaciones o múltiples entregas (por razones de cambios de versión del
sistema objeto de este pliego u otras razones), la fase del proyecto en que deberá entregarse, quedando
esto reflejado en el Plan de Gestión del Proyecto y en Plan de Gestión de la Documentación.
6) El Adjudicatario deberá mantener actualizado los entregables, algunas de las razones a considerar para su
actualización son:
 Por cambios en la gestión del proyecto.
 Por cambios de metodología.
 Por acuerdos en el proyecto.
 Por tiempo de validez (aplicable por ejemplo a los Certificados ISO 9001 y CMMI)
7) Cada documento deberá incluir en el apartado de Alcance, la versión, fase o temporalidad de su aplicación.
En la portada se deberá indicar la versión del sistema a la que aplica.
8) Cuando se habla de CP, si se agrupan varias CP, la entrega no se realizará por CP, sino por la agrupación.
9) Al finalizar el proyecto la documentación del sistema objeto de este pliego se adecuará a la metodología de
desarrollo a las exigencias de la reglamentación vigente REGLAMENTO (CE) Nº 1035/2011, ejecutar los
procesos de Safety y dar cumplimiento a la reglamentación de interoperabilidad del Cielo Único Europeo
REGLAMENTO (CE) Nº 552/2004 para la cual se tendrá en cuenta la lista de documentación especificada.
10) Los entregables en formato DOORS, serán entregados además, en formato Word y PDF para su publicación
interna, según lo acordado con el Director del Expediente o persona en quien delegue.
11) El propósito de cada LDEC incluido en la siguiente tabla, es orientativa y no debe limitar cualquier otra
necesidad que se derive en la ejecución del proyecto o normativa aplicable.
Elaborado: 14/04/16
Página: 155/201
Desarrollo e Implantación de A-CDM fase II: Mejoras funcionales y nueva interfaz Torre-Plataforma
PROPÓSITO
FASE Nº LDEC NOMBRE DEL ENTREGABLE DESARROLLO SW FORMATO
(el propósito es orientativo no limitativo)
Establecer y proporcionar una descripción detallada de
la organización del Proyecto, así como de las líneas
principales de planificación y gestión del mismo para
satisfacer los requisitos del cliente.
* Por Expediente
Este entregable incluye la información correspondiente
Plan de Gestión del Proyecto al Plan de Métricas, al Plan de Comunicaciones, al Plan * Por versión de
Planificación LDEC-01 WORD / PDF
(PMP) de Riesgos y al Plan de Adquisiciones y Sistema
Aprovisionamiento.
Según aplique.
Incluirá las referencias de los Planes válidos para cada
versión del Sistema/Despliegue, en caso de no ser
necesario la actualización de los planes, deberá quedar
documentado en el PMP.
Define las actividades a realizar para asegurar la

Calidad de los productos o servicios en el proyecto,
identificando la normativa, los procesos, las actividades
y recursos asociados que se aplicarán para cumplir los * Por Expediente
requisitos del proyecto. * Por versión de
Plan de Gestión de la Calidad
Planificación LDEC-02 Sistema WORD / PDF
(QMP)
Cuando el producto a desarrollar sea SW, el Plan de
Calidad debe definir las actividades de aseguramiento Según aplique.
de la calidad del software a realizar durante el ciclo de
vida del SW de acuerdo a los planes y estándares de
desarrollo del SW (ED-153).
Describe las responsabilidades y actividades para

realizar la gestión de la configuración durante todo el * Por Expediente
ciclo de vida del proyecto, identificando o haciendo * Por versión de
Plan de Gestión de la
Planificación LDEC-03 referencia a procedimientos aplicables y describiendo Sistema WORD / PDF
Configuración (CMP)
los diferentes informes de Control de Configuración.
Según aplique.
Cuando el producto sea SW, este plan debe considerar
las actividades de gestión de la configuración a ser
Cualquier versión impresa o en soporte informático, total o parcial de este documento, se considera como copia no controlada y siempre debe ser contrastada con su versión vigente en el
Gestor Documental de ENAIRE.
Elaborado: 14/04/16
Página: 156/201
PROPÓSITO
realizadas durante el ciclo de vida del SW, incluyendo el
control del entorno de desarrollo y de verificación del
SW.
Además, debe describir el procedimiento de Control de

Cambios aplicable al expediente, soportado con
herramientas (DOORS y Change), incluyendo:
• Procedimiento para propuestas de cambio o

solución de incidencias aplicable a la
especificación y otros documentos
identificados como elementos de configuración.
• Uso de DOORS para los procesos de revisión.
• Gestión de Líneas Base (Baseline) para
módulos de DOORS.
Describe las responsabilidades y actividades de Gestión
* Por Expediente
de Documentación necesarias para la elaboración,
* Por versión de
Plan de Gestión de la control, archivo y distribución de la documentación
Planificación LDEC-04 Sistema WORD / PDF
Documentación (DMP) durante todo el ciclo de vida del proyecto. La lista de
documentos a producir está incluida en el PMP y este
Según aplique.
Plan hace referencia a dicha lista.
El propósito del Plan de Aspectos para la Aprobación del

SW (PSAA) es describir y planificar las actividades de
aprobación/garantía que se llevarán a cabo durante el
proyecto.
* Por Expediente
Plan de Aspectos para la * Por versión de
Este Plan servirá como soporte para proveer la garantía
Planificación LDEC-26 Aprobación del SW del Sistema WORD / PDF
de la integridad del SW para el desarrollo del SW
Suministrador (PSAA-S) contenido en el proyecto.
Según aplique.
En este plan se incluye la matriz de cumplimiento de
ED-153, que identifica las evidencias necesarias para
demostrar cumplimiento con cada objetivo del ED-153
según los niveles de integridad SW exigido (SWAL). La
Elaborado: 14/04/16
Página: 157/201
PROPÓSITO
ejecución de este plan proveerá la suficiente certeza
para afirmar que el SW cumple con los objetivos de la
ED-153.
El plan se trata de las actividades del ciclo de vida y los

productos de software sujetos a verificación, las tareas
de verificación requerida en cada actividad del ciclo de
vida y producto de software, y los recursos
relacionados, las responsabilidades, y la planificación. El
* Por versión de
Planificación LDEC-29 Plan de Verificación (VP) plan incluye los procedimientos para el envío de WORD / PDF
Sistema
informes de verificación al cliente y otras
organizaciones involucradas.
Describe los procedimientos para satisfacer los

objetivos del proceso de verificación del SW.
Describe las actividades a realizar para dar las

garantías necesarias que demuestren la idoneidad de
los COTS utilizados en el proyecto.
El objetivo básico de la planificación de garantía de

COTS es definir el conjunto de las actividades de
garantía y / o las evidencias necesarias para asegurar
la integridad del SW producido y documentado con los
Plan de Aseguramiento de
COTS utilizados en el proyecto. * Por versión de
Planificación LDEC-31 COTS / COTS Assurance Plan WORD / PDF
Sistema
(CAP) El estándar a seguir para la integridad del Software
(SW) será el ED-153 y el nivel de Assurance aplicado de
los COTS cumplirá lo establecido para los componentes
SW que usan esos COTS.
El Plan indicará que existen dos ediciones del CAS

(LDEC-47.2), una con la entrega de la especificación y
otra con las entregas en el CED.
Elaborado: 14/04/16
Página: 158/201
PROPÓSITO
Describe las herramientas utilizadas en el desarrollo y
verificación del Sistema y si deben ser o no cualificadas.
Plan de Cualificación de
Describe también el conjunto de actividades a realizar * Por versión de
Planificación LDEC-32 Herramientas / Tools WORD / PDF
sobre las herramientas a cualificar para la obtención de Sistema
Qualification Plan (TQP)
las evidencias necesarias para demostrar su
cualificación.
Define los objetivos, el ciclo de vida y el entorno de

desarrollo que se utilizará en el desarrollo del software.
Además se identifican los procedimientos y estándares
* Por versión de
Planificación LDEC-33 Plan de Desarrollo de SW (SDP) a utilizar. WORD / PDF
Sistema
Este entregable incluye la Descripción de Estándares de
Especificación, Diseño y Desarrollo de Software (SDSD).
El Plan de Seguridad y Salud (PSS) establece las

previsiones respecto a prevención de riesgos de
accidentes y enfermedades profesionales durante la
realización de los trabajos del proyecto.
Plan de Seguridad y Salud Se requerirá sólo si el Expediente incluye actividades de

Planificación LDEC-34 *Por Expediente WORD / PDF
(PSS) obra o instalación asociada, en los que sea aplicable el
Real Decreto 1627/1997. En general se requerirá este
entregable para aquellos proyectos que en el Estudio de
Seguridad y Salud, realizado por el Área de Prevención
de Riesgos Laborales / División Infraestructura Soporte
CNS/ATM, se identifique su necesidad.
Define los procesos y actividades de seguridad que

darán lugar a la puesta en operación de un sistema
Plan de Gestión de Seguridad * Por versión de
Planificación LDEC-35 seguro, así como garantizar que se obtiene y WORD / PDF
(Safety) (SMP) Sistema
documenta un Aseguramiento apropiado de la
Seguridad en el tiempo adecuado.
Elaborado: 14/04/16
Página: 159/201
PROPÓSITO
Describe el entorno donde se llevarán a cabo los
procesos de desarrollo y verificación definidos en el
proyecto, considerando:
* Por versión de
Planificación LDEC-38 Entorno de Desarrollo del SW a. Definición de los entornos a utilizar en los procesos WORD / PDF
Sistema
de desarrollo, incluyendo la verificación.
b. Lenguajes de Programación
c. Consideraciones para la Compilación
* Por Expediente
Evidencia del cumplimiento de acuerdo a lo solicitado * Actualización del
en el Pliego de Prescripciones Técnica. certificado cuando
Certificado de cumplimiento expire su validez,
Planificación LDEC-44 PDF
con la ISO 9001 La información de este entregable podrá estar durante la ejecución
incorporada en: del Expediente.
LDEC-2 Plan de Gestión de la Calidad (QMP)
Según aplique.
* Por Expediente
Evidencia del cumplimiento de acuerdo a lo solicitado * Actualización del
en el Pliego de Prescripciones Técnica. certificado cuando
expire su validez,
Planificación LDEC-59 Certificado de CMMI PDF
La información de este entregable podrá estar durante la ejecución
incorporada en: del Expediente.
LDEC-2 Plan de Gestión de la Calidad (QMP)
Según aplique.
El propósito de este documento es servir como guía,

para usuarios y administradores, de las herramientas
utilizadas para Gestión de Requisitos, de Pruebas, de * Inicio del Expediente
Guía de uso de Herramienta
Planificación LDEC-65 Incidencias y de Cambios (TIMES, DOORS y CHANGE); * Actualización de las PDF/DOORS
TIMES (TIMES User Guide)
incluirá: Herramientas
- Guía de usuario
- Guía de explotación y mantenimiento
Elaborado: 14/04/16
Página: 160/201
PROPÓSITO
* Por CP
asignación definitiva del SWAL y la arquitectura
definitiva asociada a la asignación definitiva de SWAL. Que lleve asociado un
Planificación LDEC-67 Asignación definitiva del SWAL estudio de seguridad PDF/DOORS
Incluye un análisis de la arquitectura SW del sistema
para confirmar la asignación de SWAL realizada. Esto
incluye un análisis de las barreras entre componentes asignado
con diferente SWAL
Describe los casos y procedimientos de prueba a

Procedimientos o Casos de * Por CP
ejecutar para verificar el sistema/software, recogiendo
Prueba, de acuerdo al alcance * Por versión de
para cada prueba, el entorno necesario (HW, datos de
del proyecto podrán ser de: Sistema
Entrega en el CED LDEC-12.1 adaptación, herramientas, etc.), las acciones a realizar y DOORS
§ Sistema
los resultados esperados. Asimismo, se incluirá la
§ SW
trazabilidad de las pruebas con los requisitos a verificar
§ HW Según aplique.
(el alcance de la versión).
Este Plan es aplicable a Desarrollo SW y debe:

- Describir la organización, funciones y
responsabilidades relacionadas con las pruebas.
- Describir la estrategia de pruebas específicas al
producto, si existen.
- Presentar la relación de pruebas establecidas.
- Proporcionar un calendario detallado de la actividad
Plan de Pruebas de Integración * Por versión de
Entrega en el CED LDEC-18 de pruebas. WORD / PDF
SW - Describir los entornos de prueba HW, SW y Datos de Sistema
Adaptación, que se utilizará en la ejecución de las
pruebas.
- Describir dónde se registrarán los resultados de
pruebas.
- Describe la lista de Cambio/Requisitos de Usuario
(CPs) y sus TPs asociados.
- Describir el procedimiento de desarrollo de las TLs y
Elaborado: 14/04/16
Página: 161/201
PROPÓSITO
TBs de CPs.
Proporciona información sobre el resultado de las

pruebas de integración realizadas, incluyendo la
trazabilidad con los requisitos probados.
Permite al cliente medir el avance de las pruebas y el

estado del sistema en cuanto al grado de cumplimiento
de los requisitos.
Informes de Pruebas de * Por entrega de SW
Entrega en el CED LDEC-13.1 Proporciona información en relación a la demostración WORD / PDF
Integración SW en el CED
del cumplimiento de las mitigaciones y barreras
identificadas en los Estudios de Seguridad (ESs).
Describe el análisis de incidencias de los Requisitos de

Seguridad (Safety).
Identificación de las incidencias abiertas con su

correspondiente prioridad y su impacto en seguridad.
* Por actualización
(CP/PTR)
Entrega en el CED LDEC-17 Producto SW * Por versión de

Sistema
Producto Según aplique.
Describe los procedimientos a seguir para realizar la

Procedimientos de Instalación instalación/actualización del Software del Sistema.
* Por entrega de SW
Entrega en el CED LDEC-20.2 de versiones y actualizaciones Cuando sea necesario, deberá incluir la descripción del PDF
Proceso de Migración y Retirada del SW. en el CED
del Sistema.
Este entregable podrá estar incorporado en:
Elaborado: 14/04/16
Página: 162/201
PROPÓSITO
LDEC-40.2 Informe de Control de Configuración SW
Recogen el estado de la configuración de los distintos

elementos SW bajo control de configuración
identificados en el proyecto.
Estos informes deben incluir los cambios (CP) e

Informes de Control de la * Por entrega de SW
Entrega en el CED LDEC-40.2 incidencias (PTRs) resueltas en el SW de aplicación PDF
Configuración SW en el CED
entregado al CED.
El contenido de estos Informes se concretará en el Plan

de Gestión de Configuración (CMP) LDEC-03 del
Proyecto.
Recogen los componentes COTS (SW y HW) que forman

parte del Sistema y están bajo control de configuración
en el proyecto. Se recogerá su estado y cuando exista * Por entrega de SW
un cambio para alguno de ellos, se identificará de la en el CED
misma forma que para los componentes SW (CP, PTR). * Por versión de
Informes de Control de la
Entrega en el CED LDEC-40.3 Sistema PDF
Configuración COTS Estos informes deben incluir el SW Base/Firmware e
incidencias (PTRs) resueltas y que afectan al COTS SW.
El contenido de estos Informes se concretará en el Plan Según aplique.

Proyecto.
Recogerá toda la información asociada al producto

(Sistema, versión SW) con todas las evidencias
identificadas en la matriz de cumplimiento del PSAA * Por versión de
Entrega en el CED LDEC-41.2 Informe Final de Producto que documente el estado del mismo cuando se entrega WORD / PDF
Sistema
al cliente.
Se incluirán como Anexo los RAC de Proceso (LDEC-55)
Elaborado: 14/04/16
Página: 163/201
PROPÓSITO
Requisitos establecidos por el proceso de Verificación
CE de Sistemas, incluye para cada CP:
- Normativa de Referencia
Matriz de Verificación - Trazabilidad de RUs (CP) con requisitos (SRS y SRD) y * Por versión de
Entrega en el CED LDEC-42 WORD
Extendida con las especificaciones correspondientes Sistema
- Trazabilidad de RUs (CP) con casos de prueba de
integración en fábrica
- Trazabilidad de RUs (CP) con manuales de operación y
mantenimiento
Declaraciones CE de los Requisitos establecidos por el proceso de Verificación * Por versión de

Entrega en el CED LDEC-45 WORD / PDF
Componentes CE de Sistemas Sistema
Recoge el conjunto de evidencias que proporcionan la

Informe de Cumplimiento de la garantía suficiente para confirmar que el software
Garantía del SW del desarrollado cumple con los objetivos de la ED-153,
* Por versión de
Entrega en el CED LDEC-47.1 Suministrador / Software correspondiente al SWAL definido. WORD / PDF
Sistema
Accomplishment Summary
(SAS-S) El alcance será la parte técnica aportada por el
suministrador.
El propósito de este informe es presentar las

evidencias y los resultados de las actividades de
aseguramiento realizadas en el marco del proyecto
para los elementos COTS usados en el SW del mismo.
2ª Edición (edición
Informe de Conformidad de Estas actividades aparecen descritas en el Plan de
final):
Aseguramiento de COTS (CAP)-LDEC-31.
Entrega en el CED LDEC-47.2 COTS /COTS Accomplishment WORD / PDF
Summary (CAS) * Por versión de
Da evidencias del cumplimiento de los objetivos
Sistema
definidos en el ED-153, asegura que los COTS usados en
el proyecto cumplen con el SWAL establecido para los
componentes SW que usan esos COTS.
Se entregará una primera edición del CAS en la fase de

Elaborado: 14/04/16
Página: 164/201
PROPÓSITO
Especificación (CAS-1) y una segunda edición ampliada
(edición final) con la Entrega en el CED (CAS-2).
El propósito de este Sumario de Cualificación de

Herramientas (TAS) es reunir las evidencias que
garantizan la idoneidad de las Herramientas usadas en
el proyecto y que corresponden a las actividades
Sumario de la Cualificación de detalladas en el Plan de Cualificación de Herramientas * Por versión de
Entrega en el CED LDEC-54 WORD / PDF
Herramientas (TAS) (TQP) LDEC-32 para aquellas herramientas a cualificar. Sistema
El TAS solo recogerá las evidencias de las herramientas

a cualificar. No se entregará si no hubiese herramientas
a cualificar.
Son los registros de las revisiones realizadas a los

procesos aplicables al proyecto, en base a la matriz de
cumplimiento de la ED-153.
Se definen en el QMP del proyecto.
Se entregarán incluidos como Anexo en el Informe Final

de Producto (LDEC-41.2)
Registro de Revisión de
* Por versión de
Entrega en el CED LDEC-55 Aseguramiento de la Calidad de - Planificación y Gestión WORD / PDF
- Configuración Sistema y por proceso.
Procesos (RAC)
- Documentación
- Calidad
- Verificación
- Revisiones Conjuntas
- Gestión
- Infraestructura
- Mejora
- Entrenamiento
- Manuales
Elaborado: 14/04/16
Página: 165/201
PROPÓSITO
- COTS y Tools
Define las directrices a seguir para el mantenimiento

apropiado del HW y SW del Sistema, así como sus
subsistemas, todos descritos en el documento System
Architecture and Requirements Allocation Description
(SARAD), además recoge:
- las actuaciones que han de realizarse de forma

Instalación y Manual Técnico de * Por versión de
LDEC-15 periódica para detectar fallos esporádicos, parámetros WORD / PDF
Despliegue Mantenimiento (MTM) Sistema
de funcionamiento fuera de márgenes seguros o
cualquier evento que pueda ser anticipo de un mal
funcionamiento en el sistema.
- los procedimientos técnicos de mantenimiento del

sistema, incluyendo mantenimiento correctivo y
mantenimiento preventivo.
Recoge el conjunto de operaciones que deberán ser

realizadas por el operador para la puesta en servicio y el
mantenimiento "off line" del sistema.
El operador, como responsable del sistema, dispone de

Manuales del Sistema (Manual * Por versión de
Transición LDEC-21 una serie de utilidades de atención a su posición que le WORD / PDF
del Operador del Sistema) Sistema
permiten realizar las operaciones previas al arranque
del ordenador, así como su posterior mantenimiento;
siempre que no afecten al correcto funcionamiento en
tiempo real del ordenador en el conjunto de la
aplicación.
Este documento tiene por objeto familiarizar al usuario

con las funciones, instrucciones y manejo de las * Por versión de
Transición LDEC-22 Manuales de Usuario WORD / PDF
Sistema
opciones del subsistema / CSCI del Sistema,
describiendo detalladamente los procedimientos a
Elaborado: 14/04/16
Página: 166/201
PROPÓSITO
seguir. Pretende también orientar en la interpretación
de las ayudas que el Sistema ofrece.
Se describe cada función, así como las entradas y

salidas operativas del mismo. Además se describe el
entorno de la posición concreta y los elementos que la
componen.
* Por Expediente
Recoge la planificación de las actividades de formación * Por versión de
dirigida a los usuarios del sistema (cliente) Incluirá los Sistema
Formación LDEC-16 Plan de Formación cursos a realizar, a quien van dirigidos (grupos, WORD / PDF
perfiles,...), la infraestructura necesaria (lugar,
documentación a entregar, equipamiento) y el
calendario. Según aplique.
Presentación y documentos a entregar durante la

* De acuerdo a lo
Material didáctico para la ejecución de la actividad formativa. CBT / POWER
Formación LDEC-39.1 definido en el Plan de
Formación POINT / PDF
Incluye CBTs (Computer Based Training) Formación.
Este documento tiene por objeto informar sobre la fase

de formación técnica del Sistema correspondiente al
proyecto, incluye:
- la relación de documentos aplicables para la
realización de la formación.
- las acciones formativas realizadas. * Por emplazamiento y
Formación LDEC-39.2 Informe de la Formación - las hojas de asistencia. WORD / PDF
por acción formativa
- los Informes de Valoración de ENAIRE elaborados con
los cuestionarios de evaluación de los alumnos.
- Batería de preguntas indicando las respuestas
correctas e informes correspondientes. a la evaluación
del aprendizaje.
- Certificados de asistencia y aprovechamiento con los
Elaborado: 14/04/16
Página: 167/201
PROPÓSITO
logos
* Definido por el Jefe

de Proyecto /
Describen el estado del proyecto: calendario, Expediente
actividades, cumplimiento de hitos, estado de acciones, * Definido en el Pliego
Seguimiento LDEC-23 Informes de Seguimiento riesgos y métricas (si aplicable). de Prescripciones WORD / PDF
Técnicas (PPT)
Nota:
La periodicidad de entrega de los Informes de
Seguimiento debe estar definida en el PMP (LDEC-01) Según aplique.
Recogen el estado de la configuración de los distintos

documentos (LDECs) del alcance del proyecto,
incluyendo:
- Número de LDEC
- Código
- Título
- Fecha de entrega * Definido por el Jefe
- Fecha del documento de Proyecto /
- Estado Expediente
- Versión del Sistema al que aplica * Definido en el Pliego
Informes de Gestión de la de Prescripciones
Seguimiento LDEC-40.5 - Edición
Documentación del Proyecto - Revisión Técnicas (PPT)
Si no se define otra
Además, incluye la información sobre los documentos
frecuencia, será
recibidos por parte de Enaire.
mensual.
El contenido de estos Informes se concretará en el Plan
Proyecto.
La información de este entregable podrá estar

incorporada en:
Elaborado: 14/04/16
Página: 168/201
PROPÓSITO
LDEC-23 Informe de Seguimiento
Informes de Auditorías Internas realizadas por el

Seguimiento LDEC-41.3 Informes de Auditorias Contratista para control de sus procesos de Ingeniería y * A petición PDF
Desarrollo.
Elaborado: 14/04/16
Página: 169/201
Plataforma
2.8. Requisitos de calendario para el proyecto

Para el Plan de Gestión del Proyecto y para la versión objeto de desarrollo, se considerarán una serie de Hitos y
un grupo de actividades de alto nivel. Las fechas definitivas y las duraciones de cada actividad son estimativas
y están condicionadas a la confirmación final por parte de Enaire. La confirmación del Director del Expediente o
persona en quien delegue, se producirá como input a la actividad de Aceptación del Plan de Gestión del
Proyecto.
Para la ejecución del proyecto se tendrá en cuenta que los cambios solicitados se abordarán en al menos dos
versiones de implantación y desarrollo cuyos contenidos concretos se acordarán y cerrarán según las
necesitadas estratégicas de versiones definidas por Enaire.
El Plazo total del servicio será de treinta (30) meses
2.9. Seguros
El contenido de este apartado sigue las directrices de la División Gestión de Tributos y Gerencia Riesgos y
Seguros.
El adjudicatario deberá contratar y presentar al Director del Expediente las siguientes pólizas de seguros.
Las pólizas de seguros para la ejecución del presente Expediente están definidas de acuerdo a las
características del mismo. Se resumen en:
 Responsabilidad Civil Aviación
 Responsabilidad Civil General
 Responsabilidad Civil Patronal
 Responsabilidad Civil Profesional
 Responsabilidad Civil de Productos
Se definen en los siguientes subapartados:

Póliza de Responsabilidad Civil Aviación que garantice la responsabilidad civil del adjudicatario frente a
terceros por daños a aeronaves, pasajeros, carga, equipajes e instalaciones de Enaire E.P.E. que pueda surgir
durante y por causa de la ejecución del expediente.
Asimismo este seguro deberá garantizar, en el caso que sea necesaria, la responsabilidad civil que pueda
derivar del uso y circulación de vehículos y/o maquinaria para la actividad a realizar en zona restringida.
Enaire E.P.E. tendrá que figurar como asegurado adicional y a todos los efectos tendrá la consideración de
tercero.
El límite de indemnización de este seguro será de .

A efecto de lo anterior, el adjudicatario entregará al director del expediente póliza o certificado de seguros en el
que aparezcan, los siguientes datos:
 Número y título del expediente
 Efecto y vencimiento de la póliza
 Riesgos cubiertos
 Límites de indemnización
 Franquicias aplicables.
Elaborado: 14/04/16
Página: 170/201
Plataforma
Póliza Responsabilidad Civil General por daños materiales, lesiones personales y sus consecuencias
ocasionados a ENAIRE E.P.E. y/o a terceros por hechos acaecidos en relación con la actividad objeto del
expediente, con un límite de indemnización mínimo de si es por siniestro y año de si es
por siniestro.
ENAIRE E.P.E. tendrá que figurar como asegurado adicional y tercero en la póliza.
A efecto de lo anterior, el adjudicatario entregará al Director del Expediente un certificado de seguros en el que
aparezcan, como mínimo, los siguientes datos:
 Número y título del expediente.
 Efecto y vencimiento de la póliza.
 Riesgos cubiertos.
 Límites de indemnización.
Póliza Responsabilidad Civil Patronal que garantice los daños personales ocasionados a los propios
empleados del contratista en relación con la ejecución de los trabajos realizados en las instalaciones de ENAIRE
E.P.E., con un límite de indemnización mínimo de por víctima.
ENAIRE E.P.E. tendrá que figurar como asegurado adicional.
Póliza Responsabilidad Civil Productos en la que se garantice la responsabilidad del adjudicatario frente a
ENAIRE E.P.E. y/o terceros que se deriven de los bienes suministrados a ENAIRE E.P.E. o sobre los cuales el
adjudicatario haya realizado trabajos o los haya manipulado, para aquellos productos o servicios críticos
relacionados con la actividad de Navegación Aérea, con un límite mínimo de indemnización por anualidad de
12 .
Póliza Responsabilidad Civil Profesional en la que se garantice la responsabilidad del adjudicatario frente a
ENAIRE E.P.E. y/o terceros que se deriven de cualquier error u omisión, real o presunto, cometido en el ejercicio
de su actividad profesional, con un límite mínimo de indemnización de , por siniestro.
Elaborado: 14/04/16
Página: 171/201
Plataforma
2.10. Importe límite

Este contrato se nomina en euros y se adjudicará igualmente en euros de manera que sus incidencias, facturas
y certificaciones deberán ser confeccionadas en la referida unidad monetaria.
 El importe límite de este expediente asciende a la cantidad de: UN MILLON NOVECIENTOS NOVENTA Y TRES
MIL DOSCIENTOS NOVENTA Y NUEVE EUROS IMPUESTOS NO INCLUIDOS
El importe de este expediente se desglosa detalladamente en el Apartado 3.- Presupuesto.
2.11. Lugar de prestación del servicio

La entrega del SW y de los Documentos suministrados se realizará al Director del Expediente. La Puesta en
servicio de las nuevas versiones del Sistema SACTA se efectuará en todos los Centros de Control según se
describe en el apartado 2.5.2 COMPOSICIÓN DE PROYECTO.
2.12. Plazo de ejecución

El plazo de ejecución del servicio es de TREINTA (30) MESES a partir de la fecha que figure en el contrato o en
su defecto la de firma del Acta de Inicio del Servicio.
2.13. Plazo de garantía

El Adjudicatario proporcionará los servicios de soporte y mantenimiento sobre todos los productos software
que se implanten, garantizando la solución completa durante un plazo de dos años (2) a partir de la fecha de
firma del Acta de Recepción y Liquidación Provisional.
La garantía incluirá todos los costes relacionados con los productos que fuesen requeridos para asegurar el
buen funcionamiento continuado de la solución y con los servicios que se presten a este efecto, con
independencia de la naturaleza de los mismos.
Durante este tiempo, el Adjudicatario queda obligado a rectificar y reparar, por su cuenta, todos los defectos de
fabricación e instalación que puedan aparecer y que sean imputables a la defectuosa ejecución del servicio o a
la mala calidad de los materiales empleados y/o suministrados.
2.14. Forma de pago

La forma de pago se realizará mediante certificación ante entrega de cambios software teniendo en cuenta la
programación y priorización planificada.
Para cambios software con formación asociada, la certificación desglosará una partida independiente
correspondiente a dicha formación.
Elaborado: 14/04/16
Página: 172/201
Plataforma
El director del expediente establecerá si lo estima conveniente o necesario la fijación de cualquier garantía para
el pago o certificación.
Los pagos a la Empresa Adjudicataria, se valorarán por Enaire y se efectuarán aplicando los precios por servicio
prestado.
La empresa adjudicataria deberá emitir todas sus facturas relativas a formación según los requerimientos
formales impuestos por la FEFE (Fundación Estatal para la Formación en el Empleo) para la bonificación de la
misma. En concreto, en la factura se hará referencia explícita a la o las acciones formativas facturadas,
incluyendo denominación, lugar de impartición y fecha de realización, de cada una de ellas de tal forma que se
puedan identificar con claridad los costes asociados a las mismas. Además, y como requisito imprescindible
para la certificación y el pago de los diferentes trabajos, el adjudicatario elaborará la documentación que se
precise para la justificación de la realización de la formación y sus costes ante la FEFE.
2.15. Pago en divisas al adjudicatario

No procede.
2.16. Prórrogas
No se admiten.
2.17. Responsabilidades
El Adjudicatario se hará responsable de los errores que pudieran cometerse en los servicios realizados por su
personal y de su comportamiento, así como de aquellas actuaciones que pudieran inducir a Enaire al error. La
declaración de comportamientos y errores será siempre a juicio de Enaire, por indicación expresa del Director
del Expediente.
El Adjudicatario deberá señalar explícitamente que conoce en detalle el objeto del expediente y las funciones
que ha de cumplir, de acuerdo con lo descrito en este PPT, no pudiendo alegar posteriormente falta o defecto de
información en lo referente al mismo. Por consiguiente, aceptará la aportación a su cargo exclusivo, sin
variación en el plazo establecido, de los servicios adicionales que, no habiendo sido considerados en su oferta,
resulten luego necesarios para la completa realización del expediente.
A estos efectos, el Adjudicatario especificará en su oferta que aceptará que el Director del Expediente o persona
en quien delegue certifique únicamente aquellos servicios o productos que, incluidos en la oferta, hayan sido
efectivamente realizados y que la totalidad de servicios que ofrece suministrar son los adecuados y suficientes
para el fin perseguido.
El adjudicatario deberá contratar y presentar al Director del Expediente las pólizas de seguros descritas en el
apartado 2.9 de este pliego.
2.18. Incompatibilidades
La empresa Adjudicataria se compromete a no participar directa o indirectamente, financiera o técnicamente,
en áreas de trabajo que entren en competencia con las actividades de Enaire, objeto de este expediente, sin
previa autorización del Director del Expediente designado por Enaire.
Elaborado: 14/04/16
Página: 173/201
Plataforma
2.19. Locales
Dependiendo de la disponibilidad, Enaire podrá arrendar, previa petición escrita de la Empresa Adjudicataria al
Director de Navegación Aérea o al Director Regional de Navegación Aérea correspondiente, locales para
utilización y realización de actividades relacionadas con el contrato y durante la vigencia del mismo.
El equipamiento interior de los locales alquilados a la empresa adjudicataria será totalmente a cargo de la
misma. Cualquier reforma o modificación de los locales para su adaptación al uso, incluso los necesarios para
cumplir las exigencias de la Legislación Laboral vigente y la normativa de Seguridad y Salud Laboral que
resultasen aplicables a los medios humanos de la empresa adjudicataria, con motivo o derivados de la relación
contractual que se establezca para la ejecución de este expediente. Dichas reformas deberán ser autorizadas
previamente por Enaire.
Al final del período de vigencia del contrato, los locales serán devueltos a Enaire en perfecto estado de uso,
resultando en beneficio de los mismos cualquier reforma o mejora efectuada de acuerdo con los párrafos
anteriores, sin que pueda ser reclamada cantidad alguna a Enaire por dichos conceptos. Cuando así se indique
al Adjudicatario, por Enaire, aquél devolverá los locales en la situación inicial en que los recibió.
Si a la finalización del contrato los locales no estuviesen en perfecto estado de conservación y limpieza, Enaire
se reserva el derecho de realizar por su cuenta los trabajos necesarios, siendo imputable su coste al
Adjudicatario, al margen de las sanciones que procedan.
Asimismo, y durante todo el periodo de duración del contrato, Enaire se reserva el derecho de traslado o
desalojo de los locales concedidos, sin que el Adjudicatario tenga derecho a ningún tipo de indemnización.
Los locales asignados ya sean para oficina, taller, almacén, etc., se utilizarán sólo y exclusivamente para las
actividades relacionadas con la prestación del servicio contratado, incluido, si procede, el almacenaje de
repuestos y consumibles.
En caso de que el adjudicatario solicitara disponer de mayor espacio, Enaire facilitará, dentro de la
disponibilidad que al efecto exista, los locales necesarios, repercutiendo el coste de dicho incremento de
superficie a la adjudicataria.
Si Enaire no dispusiera de los locales necesarios para atender las necesidades de mayor espacio demandadas
por la adjudicataria, podrá facilitar a dicha empresa una superficie en el recinto de Enaire, siendo por cuenta de
esa adjudicataria el valor del módulo prefabricado autorizado, así como todas las instalaciones, acometidas
necesarias y demás gastos.
Los gastos de agua, electricidad, teléfono, etc, correspondientes a los locales utilizados por la adjudicataria,
serán a su cargo y están desglosados en el siguiente cuadro:
Importes por persona/MES
Alquiler/Gastos Comunitarios sede SS.CC.

Navegación Aérea (7 m2 por persona)
Gastos luz
Gastos Generales
Elaborado: 14/04/16
Página: 174/201
Plataforma
Limpieza
Gastos teléfono
Vigilancia
Gas 12,55
Puesto operativo (mesa y sillón giratorio)
TOTAL
Enaire estará libre de cualquier responsabilidad en cuanto a robo, deterioro, rotura o cualquier otro perjuicio que
pudiera sufrir el material almacenado en dichos locales, de cuya custodia será único responsable la Empresa
Adjudicataria.
2.20. Medios informáticos

La empresa adjudicataria aportará los medios informáticos. En el caso de que se considere inviable el uso de los
ordenadores de la empresa adjudicataria en las oficinas de ENAIRE, debido a la imposibilidad de adaptar la
infraestructura a las configuraciones de las distintas asistencias, ENAIRE podrá facilitar los medios
informáticos, siendo el coste de alquiler mensual de los mismos, el siguiente:
Puesto con PC normal: 155 euros
Puesto con PC portátil: 168 euros
Dichos importes incluyen el soporte técnico así como licencias de software base, etc.
En cualquier caso, el importe actualizado de estos costes de alquiler, deberá ser consultado con la Dirección de
Sistemas de Información.
2.21. Dirección del servicio

Tanto Enaire como la empresa Adjudicataria se comprometen a designar representantes.
Durante el desarrollo del servicio, todas las relaciones con Enaire referentes al contrato, se establecerán a
través del Director del Expediente o persona en quien delegue.
El Director del Expediente establecerá los criterios y líneas generales para la actuación en relación con el
servicio contratado para el cumplimiento de los fines del mismo.
Por otra parte, la empresa Adjudicataria deberá nombrar un Coordinador que actuará como interlocutor con el
Director del Expediente, cuya función principal será la de responder de la correcta realización del servicio
contratado, responsabilizándose del nivel de calidad deseado en los resultados. Dicho Coordinador deberá estar
presente en el lugar de prestación del servicio, al menos, durante el horario de prestación del mismo y, en todo
caso, permanentemente localizado.
En cuanto al personal de la empresa Adjudicataria corresponderá al Coordinador:

a) Actuar como interlocutor de la empresa contratista frente a Enaire, canalizando la comunicación entre
la empresa contratista y el personal integrante del equipo de trabajo adscrito al contrato, de un lado, y
Enaire, de otro lado, en todo lo relativo a las cuestiones derivadas de la ejecución del contrato.
Elaborado: 14/04/16
Página: 175/201
Plataforma
b) Distribuir el trabajo entre el personal encargado de la ejecución del contrato, e impartir a dichos
trabajadores las órdenes e instrucciones de trabajo que sean necesarias en relación con la prestación
del servicio contratado.
c) Supervisar el correcto desempeño por parte del personal integrante del equipo de trabajo de las
funciones que tienen encomendadas, así como controlar la asistencia de dicho personal al puesto de
trabajo.
d) Organizar el régimen de vacaciones del personal adscrito a la ejecución del contrato, debiendo a tal
efecto coordinarse adecuadamente la empresa contratista con ENAIRE, a efectos de no alterar el buen
funcionamiento del servicio.
e) Informar a Enaire acerca de las variaciones, ocasionales o permanentes, en la composición del equipo
de trabajo adscrito a la ejecución del contrato.
2.22. Posibles incidencias relativas a los medios humanos

Durante el período de vigencia del expediente, la empresa Adjudicataria deberá contar con los Medios Humanos
necesarios para garantizar el buen funcionamiento de la prestación y la calidad en el servicio prestado,
cumpliendo con lo exigido en el pliego.
Con el objetivo de evitar la paralización de las actividades, la distribución de los periodos vacacionales del
personal de la empresa Adjudicataria no afectará a la prestación del servicio contratado que deberá estar
siempre cubierto.
Los profesionales que sean asignados por la empresa Adjudicataria serán reemplazados por la misma, por
otros profesionales de igual valía en los supuestos de incapacidad temporal, vacaciones, asuntos personal, etc.
La empresa Adjudicataria deberá garantizar el traspaso de conocimientos de la prestación del servicio, cuando
se produzca algún reemplazo en los Medios Humanos, sin coste adicional para Enaire.
La empresa Adjudicataria informará a Enaire de cualquier incidencia o consecuencia del cambio de los Medios
Humanos que afecten a la prestación del servicio en, costes, retrasos, solapamiento o formación del nuevo
personal.
2.23. Cláusula de medios humanos

El Adjudicatario se compromete a realizar la actividad, objeto del Pliego, con los medios humanos y materiales
adecuados a tal fin.
La facultad de control y dirección de los trabajadores corresponde a la Empresa Adjudicataria, por disponer la
misma de una titularidad independiente a la de Enaire, así como de organización autónoma.
No obstante, con el fin de que no quede dañada la imagen de Enaire, la Empresa Adjudicataria se compromete a
adoptar aquellas medidas que considere necesarias para que su personal cumpla los siguientes requisitos:
1. Realizar la actividad laboral con la máxima diligencia y corrección.
2. Desempeñar sus funciones sujeto al cumplimiento de la normativa que regule los recintos de Enaire;
resultando la Empresa Adjudicataria la única y exclusiva responsable por las infracciones en que pueda
incurrir dicho personal, siendo Enaire ajena a esta responsabilidad.
Elaborado: 14/04/16
Página: 176/201
Plataforma
En el supuesto de que se produzcan quejas motivadas contra trabajadores, por falta de capacidad o
incorrecto comportamiento, el Director del Expediente dará traslado de las mismas a la Empresa
Adjudicataria, a los efectos oportunos.
3. En particular, en el Centro de Trabajo, deberá llevar visible la tarjeta de identificación individual

asignada por los servicios de Seguridad del Centro de Trabajo de Enaire donde se encuentren,
cumpliendo escrupulosamente las autorizaciones y restricciones de la misma.
Respecto al personal, la Empresa Adjudicataria se obliga expresamente a:
a) Realizar su actividad con una plantilla de trabajadores adecuada para el rendimiento óptimo y calidad del
servicio. Respecto del personal del adjudicatario, adscrito a la actividad objeto de este pliego, una vez
finalizada ésta o si la misma se resolviera antes de finalizar la vigencia pactada se estará a lo dispuesto en
la legislación vigente y en los propios convenios colectivos que resulten de aplicación en materia de
subrogación empresarial.
En ningún caso, el personal de la adjudicataria se incorporará a la plantilla de Enaire, ni ésta se subrogará

en las relaciones laborales existentes entre el adjudicatario y sus trabajadores; siendo Enaire totalmente
ajena a las referidas relaciones laborales, así como a las eventuales responsabilidades que de las mismas
pudieran derivarse, que el adjudicatario acepta expresamente serán de su cuenta y cargo
b) Aceptar todas las responsabilidades que se deriven de las relaciones que pueda establecer con terceras
personas, durante la vigencia de la concesión, para desarrollar el objeto de la misma, por lo que Enaire no
se subrogará en dichas relaciones.
c) Remitir a las autoridades de Enaire competentes, a los solos efectos de control y seguridad aeroportuarios,
relación nominal de los medios humanos que la empresa adjudicataria vaya a asignar a la prestación del
servicio, con indicación del horario de trabajo de los mismos y del periodo de vinculación, así como la
documentación que sea exigible, todo ello, a los solos efectos de determinar el período de validez de las
tarjetas de seguridad (acreditaciones).
Sin esta remisión, no se entregará la tarjeta de seguridad (acreditación) que, a efectos de seguridad
aeroportuaria, será exigible portar.
Es responsabilidad de la empresa adjudicataria comunicar, con carácter inmediato, al Director del

Expediente, cualquier variación de los datos contenidos en la citada relación nominal (nombre, vinculación,
horario, etc.) con el objeto de que estén debidamente actualizadas las tarjetas de seguridad (acreditación).
Enaire, en atención al servicio público que presta, podrá retirar las tarjetas de identificación cuando, por
razones debidamente justificadas, peligre la seguridad aeroportuaria o pueda quedar dañada la imagen de
la Entidad.
d) El personal del adjudicatario quedará sometido a las normas que sobre la seguridad, policía y régimen
interior rijan en el Centro de trabajo.
e) Cumplimiento de toda la normativa aplicable a los trabajadores en materia de trabajo, empleo, Seguridad
Social y prevención de riesgos laborales.
Elaborado: 14/04/16
Página: 177/201
Plataforma
El Adjudicatario deberá especificar los Medios Humanos previstos para llevar a cabo la prestación del servicio,
en los plazos establecidos, teniendo en cuenta que deben disponer de experiencia acreditable en:
 actividades de desarrollo, validación, formación, despliegue, puesta en servicio operacional y
mantenimiento de Sistemas de Control de Tráfico Aéreo, en el marco regulatorio del Cielo Europeo.

Methodology.
 Para el caso particular de las actividades de desarrollo de Software los medios humanos dispondrán de
experiencia acreditable en la aplicación de la ISO 12207 y de la ED-153
Además, el Adjudicatario deberá demostrar que los Medios Humanos previstos para llevar a cabo la prestación
del servicio poseen una alta cualificación técnica y están en posesión de un conocimiento exhaustivo de la
funcionalidad CDM.
Enaire estima que para que el servicio se preste dentro de los niveles de calidad exigidos, los medios humanos
asignados por la empresa Adjudicataria al mismo, deberían ser, al menos los siguientes:
o Coordinador de la empresa Adjudicataria / Jefe de Proyecto y su adjunto.
o Responsable de Calidad (esta persona deberá ser independiente del Jefe de Proyecto).
o Responsable de Safety del Proyecto.
o Responsable de SW Assurance del Proyecto.
o Responsable de Especificación y Diseño.
o Responsable de Desarrollo Software.
o Responsable de Actividades de Verificación (esta persona deberá ser independiente del
Responsable de Desarrollo Software).
o Responsable de Actividades de Pruebas (esta persona deberá ser independiente del
Responsable de Desarrollo Software).
o Responsable de Integración
o Responsable de Control de Configuración para el Proyecto.
o Responsable de Documentación.
El Coordinador de la Adjudicataria informará de cualquier incidencia o consecuencia del cambio de los Medios
Humanos que afecten a la ejecución de este expediente en costes, retrasos, solapamiento o formación del
nuevo personal.
Cualquier cambio del responsable del proyecto o de alguno de los miembros clave del equipo deberá ser
notificado por escrito y aprobado por Enaire.
Asimismo, Enaire considera que los recursos asignados por el adjudicatario para la prestación del servicio, y de
forma complementaria a su perfil profesional, deben tener las siguientes cualificaciones:
 Titulación Superior o Media.
 Cinco años de experiencia, y más de diez para la persona que gestione y coordine el trabajo.
 Áreas de experiencia de acuerdo con el servicio a prestar.
 Idiomas y nivel de los mismos a nivel de lectura, escritura y conversación.
 Conocimientos de Ingeniería de Sistemas SW.
 Conocimientos de Herramientas SW y Entornos HW aplicables al sistema ATM
 Ofimática.
Elaborado: 14/04/16
Página: 178/201
Plataforma
El Coordinador de la empresa Adjudicataria informará de cualquier incidencia o consecuencia del cambio de los
Medios Humanos que afecten a la prestación del servicio en costes, retrasos, solapamiento o formación del
nuevo personal.
2.24. Cláusula de huelga

En el caso de originarse algún conflicto del que pudiera verse afectado este servicio, dicha circunstancia deberá
ponerse en conocimiento de la Dirección del Expediente, con una antelación mínima de diez días naturales.
Asimismo el Adjudicatario tendrá la obligación de comunicar a la Dirección del Expediente, con la suficiente y
máxima antelación posible, los servicios mínimos acordados, en su caso, por la Autoridad competente, en el
supuesto de huelgas o paros que afecten a su personal.
Durante el desarrollo de la huelga, el adjudicatario estará obligado a informar a la Dirección de Navegación

Aérea de la evolución e incidentes, en los plazos y formas fijados por el Director del Expediente.
En las situaciones de huelga que afecten al personal de la empresa Adjudicataria, se deberán mantener los
servicios necesarios a fin de asegurar la prestación de los mismos, de acuerdo con la legislación vigente.
Durante el periodo de huelga, se suspenderá la contraprestación por parte de Enaire, en tanto el Adjudicatario
acuerde con ésta los niveles de servicio que se van a prestar y las formas de retribución correspondientes.
2.25. Cláusula de prevención de riesgos laborales

El contenido de esta cláusula se encuentra recogido en el ANEXO D del Pliego de Cláusulas Particulares.
2.26. Cláusula medioambiental

El contenido de esta cláusula se encuentra recogido en el ANEXO G del Pliego de Cláusulas Particulares.
2.27. Propiedad intelectual e industrial de los trabajos realizados

El contenido de esta cláusula se encuentra recogido en el ANEXO E del Pliego de Cláusulas Particulares.
2.28. Negligencia
En caso de negligencia de la Empresa Adjudicataria en el desarrollo de los servicios realizados con este
expediente, o incumplimiento de las cláusulas del mismo, Enaire podrá dar por terminado el contrato,
notificándolo por escrito a la Empresa Adjudicataria.
2.29. Subcontrataciones
La subcontratación, por parte del Adjudicatario, de obras, suministros, consultorías, asistencias, servicios, etc.,
requerirá la conformidad previa del Director del Expediente o persona en quien delegue, no implicando un
cambio en la relación contractual, que se mantendrá inalterable entre el Director del Expediente y el
Coordinador de la empresa Adjudicataria.
En caso de producirse algún tipo de subcontratación, el Director del Expediente o persona en quien delegue, se
reserva el derecho de verificar que los subcontratistas y vendedores actúan conforme a lo especificado en este
PPT, siendo el Coordinador de la empresa Adjudicataria quien deba realizar todas las provisiones necesarias
Elaborado: 14/04/16
Página: 179/201
Plataforma
para ello. Estas verificaciones no relevan, en ningún caso, al Adjudicatario de sus obligaciones en materia de
Gestión de la Calidad.
En el caso de que la empresa contratista pueda subcontratar los servicios, se deberá indicar el porcentaje
máximo permitido que, en ningún caso, podrá superar el 60%.
2.30. Inspecciones
El Director del Expediente o persona en quien delegue , se reserva el derecho de realizar las inspecciones que
oficinas de la Empresa Adjudicataria.
2.31. Cláusula LOPD para contratos de prestación de servicios con acceso a datos de
carácter personal
El contenido de esta cláusula se encuentra recogido en el ANEXO F del Pliego de Cláusulas Particulares.
EL JEFE DE LA DIVISIÓN DE AUTOMATIZACIÓN
Elaborado: 14/04/16
Página: 180/201
Plataforma
Anexos
Elaborado: 14/04/16
Página: 181/201
Plataforma
Anexo A: Cláusulas de formación
Procedimientos y requisitos para las acciones

formativas derivadas de expedientes de instalación de sistemas -10-PES-001-3.0.
1. Objeto
Se describen los aspectos que los licitadores y adjudicatarios deberán tener en cuenta respecto a los requisitos
de la formación derivada de este expediente, en cada una de sus fases.
2. Fase de ejecución del expediente
2.1. Metodología de Impartición

Toda formación se impartirá en idioma castellano o en inglés con traductor, por personal experto en la
materia a impartir y con experiencia docente.
La relación teoría/práctica de los cursos tenderá a ser 60/40 %, que se podrá modificar si las condiciones
específicas de algún curso así lo aconsejaran. Buscando la máxima efectividad de las acciones formativas, se
alternarán frecuentemente las clases teóricas con las prácticas.
Con el fin de disponer de unos criterios homogéneos. La relación instructor/alumno estará determinada por la
relación teoría/práctica. Si la parte práctica de la acción formativa es:
 Igual o superior al 40%, la relación numérica instructor/alumno tenderá a ser como máximo 1/10.
 Entre el 25 y el 40%, la relación numérica instructor/alumno tenderá a ser como máximo 1/15.
 Inferior al 25%, la relación numérica instructor/alumno tenderá a ser como máximo 1/20.
2.2. Control de Asistencia

Cada jornada de la acción formativa, e l formador pasará a la firma de los asistentes una hoja de
control de asistencia, donde figurarán los datos del curso:
 Denominación
 Fechas de celebración
 Fecha a la que corresponde la hoja de control
 Nombre de cada uno de los convocados al curso, con su DNI y lugar para la firma.
Si la acción formativa se realizara en jornada de mañana y de tarde, se pasarán 2 hojas de control de

asistencia. El Formador recogerá las hojas de control de asistencia, al finalizar el curso y se remitirá una
copia de ellas a la Dirección del Expediente.
Esta hoja debe firmarla cada jornada el formador, debiendo hacer constar en la misma las posibles incidencias
de la jornada.
En el caso de que el lugar en el que se imparta la formación no sean dependencias de ENAIRE, la empresa
adjudicataria hará llegar a la Unidad de Formación o al Director del Expediente las hojas de control de asistencia
lo antes posible (como máximo 10 días después de finalizada la acción formativa).
Elaborado: 14/04/16
Página: 182/201
Plataforma
2.3. Valoración de las Actividades Formativas

Con el fin de valorar la calidad de la acción formativa que se ha organizado, cada uno de los asistentes a la misma
deberá cumplimentar al terminar dicha acción formativa, un cuestionario de satisfacción según el formato A332-
10-PL-004 en su versión en vigor, en el que se recogerán sus impresiones sobre dicha acción.
Las unidades de formación facilitarán al formador dicho formulario que deberá ser entregado a los asistentes al
finalizar las acciones formativas, recogiéndolo una vez cumplimentado por los asistentes.
Si la empresa que imparte la formación dispone de una certificación de calidad con cuestionario propio de
valoración de actividades formativas, podrá utilizar dicho cuestionario además del cuestionario que facilite
ENAIRE.
En todo caso, tendrá prioridad la cumplimentación del cuestionario que facilite la unidad de formación de ENAIRE,
a los efectos de cumplir lo previsto en sus procesos internos de calidad.
En el caso de que el lugar en el que se imparta la formación no sean dependencias de ENAIRE, la empresa
adjudicataria hará llegar a la Unidad de Formación o al Director del Expediente los cuestionarios lo antes posible
(como máximo 10 días después de finalizada la acción formativa).
Las unidades de formación elaborarán un informe que resuma los resultados de estos cuestionarios y se los
remitirán a los directores de los expedientes y a la unidad de explotación regional. Si como resultado de este
informe la acción formativa no cumple con el mínimo de calidad exigible, el adjudicatario deberá repetirla.
2.4. Evaluación del Aprendizaje de las Actividades Formativas

Conforme a lo establecido en la normativa de ENAIRE, toda acción formativa conllevará la evaluación del
aprendizaje, para ello el adjudicatario entregará a la Unidad de Formación una batería de 60 preguntas, de las
cuales:
 30 preguntas de dificultad 1
Las unidades de formación iniciarán dicho proceso de evaluación. El proceso de evaluación se definirá en
función de la complejidad de la formación y de los conocimientos a adquirir.
A continuación se detallan los principales aspectos a tener en cuenta para la gestión de dicha evaluación.
2.4.1. Proceso de evaluación del aprendizaje para acciones formativas complejas

Para acciones formativas complejas, que así lo requieran a juicio de la unidad proponente y/o la unidad
receptora del sistema, se seguirán los siguientes requisitos de evaluación:
 La Unidad de Formación gestora de cada acción formativa, a través del Director del Expediente o
persona en quien delegue, deberá solicitar a la empresa impartidora una batería de preguntas, en
el formato establecido, donde cada pregunta tendrá 4 opciones de respuesta, siendo solo una la
correcta, indicándose cuál es y la página/apartado del manual asociado al curso en el que aparece,
así como su grado de dificultad.
 Cuando sea necesario, las evaluaciones y su correspondiente plantilla de correcciones se crearán a
Elaborado: 14/04/16
Página: 183/201
Plataforma
través del generador de pruebas teniendo en cuenta los siguientes aspectos:

 Si la acción formativa es de más de 8 horas, la batería deberá contener 60 preguntas, de las
cuales:
 Si la acción formativa es de menos de 8 horas, la evaluación constará de 30 preguntas, de las
cuales:
 El tiempo de realización de la prueba de evaluación será de 45 minutos.
 Las evaluaciones se superarán cuando se obtenga un 50% de respuestas correctas del total de
las preguntas del examen, teniendo todas las respuestas el mismo valor. Las preguntas no
contestadas no se valorarán y las falladas no penalizarán. El resultado se registrará en la
aplicación de formación como apto o no apto, indicándose la nota del 0 al 10.
 En las convocatorias de los alumnos se deberá incorporar el siguiente texto: curso finalizará
con una prueba de Evaluación del Aprendizaje (según Convenio Colectivo en vigor) que se
realizará el último día del curso, dentro del horario previsto
 El mismo día de inicio del curso se le hará entrega al formador externo de las evaluaciones de
aprendizaje.
 Al finalizar el curso, el formador/monitor aplicará las pruebas de Evaluación del Aprendizaje.
 El formador/monitor será el encargado de corregir las evaluaciones.
 El formador/monitor deberá entregar a la Unidad de Formación las evaluaciones

cumplimentadas y corregidas en sobre cerrado.
 Se hará entrega del diploma a todos los asistentes, en función de:
Nota: Para aprendizajes de carácter práctico o técnico para maquinaria, instalaciones, etc. se
podrá valorar métodos de valoración específicos.
2.5. Documentación Asociada a Acciones Formativas

La empresa adjudicataria proporcionará a cada uno de los asistentes a las acciones formativas la
documentación técnica necesaria para el seguimiento de las clases, consistente en:
 Manuales técnicos de los sistemas de que el curso trate.
Elaborado: 14/04/16
Página: 184/201
Plataforma
 Documentación de la que el formador se sirva a modo de presentación para impartir el curso.
Esta documentación asociada a formación estará controlada como los demás documentos sometidos
al Plan de Documentación.
La empresa adjudicataria deberá ceder a ENAIRE los derechos de reproducción y explotación del material
para uso interno de formación de personal de ENAIRE.
2.5.1. Formato de la documentación asociada

Toda la documentación asociada a acciones formativas estará impresa en color y se editará con programas
Microsoft Office 2000 o posterior, debiendo estar integrado en un solo documento tanto el texto
como figuras, calendarios, etc., utilizando papel DIN A4. Los ficheros resultantes de esta
documentación se entregarán a la Dirección del Expediente en formato original editable (Word, Power Point
o similar) y PDF.
La documentación irá encuadernada con portada, y cuando su tamaño lo permita llevará lomeras con
el título del documento.
En estos documentos debe figurar el logotipo de ENAIRE al menos en la portada. El logotipo o nombre
de la empresa adjudicataria podrá aparecer solo en la portada, como autor. Los manuales técnicos, al
tratarse de documentación contractual, estarán sujetos al formato expuesto en el plan de
documentación ligado al expediente.
La documentación utilizada a modo de presentación por el formador también deberá entregarse a

los asistentes al curso, de forma que cada página del documento debe estar formada por la diapositiva
en la parte superior y en la parte inferior las notas correspondientes a dicha diapositiva, como texto
explicativo de la misma, para que en posteriores consultas del material entregado, un simple vistazo a
la página pueda llevar a la idea pretendida por la diapositiva.
2.6. Diplomas
Siguiendo los modelos fijados por la Dirección de Recursos Humanos de la DNA, se elaborarán los
diplomas de aquellas acciones formativas que sean gestionadas en su ámbito de actuación, conforme a
los procedimientos establecidos para ello (A332-09-PES-001), pudiendo solicitar a las empresas
contratistas la elaboración y firma conjunta de dichos diplomas.
El certificado de asistencia / diploma se entregará a los asistentes que hayan asistido, al menos, al 75% del
total de las horas de la formación. En el caso de que exista evaluación, en el diploma se incluirá el concepto
Para cursos gestionados por el Departamento de Gestión de la Formación (que afecten a personal de SSCC
y/o a varias DRNA), los diplomas deben ir firmados por la responsable de la unidad correspondiente
de SSCC. Para aquellos cursos que se gestionen en cada una de las DRNAs los diplomas irán firmados
por los Directores Regionales y/o por las Unidades de RRHH o de Formación regional.
En cualquier caso, los diplomas serán enviados en formato electrónico a la unidad de formación
gestora correspondiente.
Elaborado: 14/04/16
Página: 185/201
Plataforma
Si el diploma corresponde a cursos impartidos por entidades/empresas externas, en la parte

superior derecha puede ir el anagrama de la empresa que imparta el curso, y en la parte inferior derecha la
firma del representante de la misma, figurando su cargo y nombre.
La fecha que figurará en la firma del diploma nunca superará en 3 meses a la fecha de finalización de
la acción formativa a la que hace alusión.
En el reverso del diploma debe figurar el contenido o programa del curso al que se refiere.
3. Tabla de seguimiento de formación
Los campos con el texto en color azul claro de la tabla siguiente deberán ser rellenados por el adjudicatario
como seguimiento del proceso.
Esta tabla representa un entregable de obligado cumplimiento como respuesta a los pliegos.
El adjudicatario y las unidades involucradas continuarán completando la información y evidencias oportunas

como parte del Plan de Formación o de los informes de seguimiento del expediente durante su ejecución.
Tabla de seguimiento de las acciones formativas derivadas del expediente
Fase del Información licitador

Requisito Responsable Evidencia
proceso / adjudicatario
Coordinar con las DET regionales
Director del
y RRHH (DRNA o SSCC) una Envío de la planificación
expediente
planificación inicial
Definición de los contenidos de Unidades Durante la
la formación. Elaboración del afectadas / Programa de contenidos ejecución del
programa / contenidos del curso adjudicatario expediente
Entrega del material (preparación de la
Entrega del material de formación Adjudicatario formación)
exigido
Aprobación materiales de Unidades
Fase de Materiales aprobados
formación afectadas
ejecución
del Impartición de la formación Adjudicatario Impartición
expediente
RRHH /
Control de asistencia Listado de firmas
adjudicatario
Durante la
Baterías de preguntas y RRHH / ejecución del
Evaluaciones
evaluación de la formación adjudicatario expediente
(realización de la
Envío de los formularios de RRHH / formación)
Los formularios
calidad adjudicatario
RRHH /
Generación de los diplomas Los diplomas
adjudicatario
Elaborado: 14/04/16
Página: 186/201
Plataforma
Anexo B: Normas para la edición y codificación de la documentación contractual
Este Anexo está basado en el procedimiento Normas para la edición y codificación de la documentación
contractual destinada a la División de Automatización ( A141-03-PES-001-9.4 .
1. Garantía de conformidad de la documentación contractual
Es objetivo de la División de Automatización establecer los mecanismos para garantizar la conformidad de la

documentación contractual y alcanzar el mayor grado de estandarización posible en lo que se refiere a las
características de redacción, presentación y codificación de la documentación asociada a los diferentes
expedientes gestionados en esta División, de forma que permita tanto manual como automáticamente:
 facilitar su empleo durante la explotación de los Sistemas,
 obtener la máxima fiabilidad en sus contenidos,
 facilitar la implantación de modificaciones,
 minimizar los errores de su interpretación.
Para conseguir tal fin, el Adjudicatario deberá:

 presentar una metodología de gestión de la documentación para ser acordada con el Director del
Expediente o persona en quien delegue, consistente con lo descrito en este procedimiento y en el Pliego de
Prescripciones Técnicas,
 desarrollar la documentación de acuerdo a un Plan de Gestión de la Documentación,
 elaborar la documentación de acuerdo a los requisitos de redacción, presentación, codificación y otros,
indicados en este anexo,
 ejercer un control de la documentación, previo a su entrega al Director del Expediente o persona en quien
delegue, que garantice la corrección, coherencia y uniformidad de la misma,
 presentar una metodología de revisión de los documentos contractuales, consistente con los requisitos
descritos en el Pliego de Prescripciones Técnicas, y documentada en los planes de Gestión de la Calidad y
Verificación.
 revisar y aprobar todo documento a ser enviado, por el Grupo de Garantía de Calidad del Adjudicatario antes
de la entrega al Director del Expediente o persona en quien delegue, el objetivo, por lo tanto, de las
revisiones será, al menos:
o evaluar la idoneidad técnica de la documentación a entregar,
o asegurar que la documentación cumple con los requisitos establecidos,
o asegurar que los documentos son completos y correctos,
o asegurar la calidad de borradores, entregas parciales y, como consecuencia, de la documentación final.
 entregar las evidencias que demuestren que el documento ha sido revisado y cumplen con los requisitos
establecidos por la División de Automatización.
 actualizar la documentación de acuerdo a los cambios aprobados.
 registrar y archivar todos los documentos del Proyecto y mantener la Biblioteca del Proyecto.
 entregar informes de control de la documentación, conforme a lo descrito en este procedimiento.
Se aplicarán los siguientes principios:

 El Adjudicatario es el único responsable del contenido y de la conformidad de la documentación
suministrada.
Elaborado: 14/04/16
Página: 187/201
Plataforma
 Las revisiones realizadas por el Director del Expediente o persona en quien delegue, no exime al
Adjudicatario de su responsabilidad de suministrar productos/entregables conformes. Cualquier defecto
detectado posterior a la entrega / aceptación, deberá ser corregido por el Adjudicatario.
2. Edición
Todos los documentos deberán estar escritos en idioma español si no se especifica otro idioma en el pliego de
prescripciones técnicas, aunque Enaire podrá aceptar, de forma excepcional, versiones de documentos en otros
idiomas.
Toda la documentación técnica generada por el Adjudicatario, a entregar al Director del Expediente o persona en
quien delegue, se entregará en soporte informático, en formato editable y .PDF, estando cada documento
integrado en un solo fichero, que contenga tanto el texto como las posibles figuras, gráficos, calendarios, etc.
Cuando así lo solicite el Director del Expediente o persona en quien delegue, se entregará todo el documento
impreso en papel.
Para la edición de la documentación se utilizarán los paquetes integrados en Microsoft Office 2000 o versiones
posteriores:
 Procesador de textos Microsoft Word.
 Editor de gráficos Microsoft PowerPoint.
 Microsoft Excel.
2.1. Redacción
Para cualquier documento del proyecto, el Adjudicatario deberá fijar el tipo y tamaño de letra, interlineado,
márgenes, cabeceras, pies, presentación de títulos de apartados y cualquier parámetro que defina el estilo de
los documentos, que deberá ser acordado con el Director del Expediente o persona en quien delegue.
Todo documento deberá contener:

 si el tamaño del documento lo permite, una lomera conteniendo al menos la siguiente información:
 proyecto / programa,
 título,
 código,
 logotipo de Enaire.
 una portada común para todo el proyecto conteniendo:
 denominación del proyecto / programa al que pertenece,
 versión del sistema para los expedientes de desarrollo SW,
 número del expediente de Enaire,
 nº de LDEC correspondiente al documento,
 código del documento,
 fecha de edición del documento,
 número de edición/revisión del documento,
 título del documento,
Elaborado: 14/04/16
Página: 188/201
Plataforma
 logotipo de Enaire,
 firmas de los responsables de la edición del documento,
 espacio en blanco con el texto Recibido para el sello de entrada del documento en Gestión de
Documentación de la División de Automatización.
 una hoja de distribución, que contendrá para cada persona:
 nombre y apellidos,
 departamento,
 empresa / organismo,
 nº de copias.
 hoja de control, que contendrá la siguiente información:
 una tabla que indicará, para cada edición, las revisiones que tiene, fecha, páginas afectadas y razones
de los cambios.
Cada página de un documento deberá tener como mínimo en su encabezado/pie esta información: código,
número de edición/revisión, fecha de edición, nº de página, identificación del proyecto y título.
Las páginas que no conformen el cuerpo del documento, deberán numerarse con números romanos en
mayúscula. El cuerpo del documento, en números arábigos relativos a cada capítulo o anexo.
El índice deberá contener los números en que comienzan los diferentes capítulos del documento, con una línea
de puntos desde el final del título del apartado al número de página.
Todo documento deberá contener un capítulo inicial con el siguiente contenido:

 objeto: que deberá describir la finalidad del documento,
 alcance: que indicará el ámbito de aplicación del documento,
 identificación: deberá identificar de forma precisa el Sistema y el Proyecto a que se aplica el documento,
así como la finalidad y objetivos de los mismos,
 estructura del documento: describirá la organización y las partes fundamentales del mismo,
 documentación de referencia: identificará otros documentos a los que se haga referencia desde éste,
agrupándolos por tipos (normas, LDEC, etc.), especificando para cada uno de ellos el título, código y versión,
 definiciones: deberá contener las definiciones necesarias para la comprensión del documento,
 siglas y abreviaturas: deberá contener todas las siglas, abreviaturas y acrónimos que se encuentren a lo
largo del texto, tablas y dibujos del documento.
Las definiciones, siglas y abreviaturas pueden ser incluidas en Anexos o Apéndices del documento.
2.2. Presentación
Todos los documentos impresos sobre papel deberán ir encuadernados, teniendo en cuenta que el sistema
utilizado para la encuadernación permita que lleve lomera, para permitir que el documento sea fácilmente
identificable cuando se encuentre archivado. Las portadas y lomeras podrán ser de colores en función del tipo
de documento.
En todos los documentos deberá figurar el logotipo de Enaire, pero nunca el del Adjudicatario, el cual solo
deberá aparecer como autor del mismo.
Elaborado: 14/04/16
Página: 189/201
Plataforma
Para las hojas de los documentos, se deberá utilizar el formato DIN A4, pudiéndose utilizar DIN A3 si el tamaño
de dibujos o tablas así lo justificaran.
La documentación a entregar a asistentes a cursos de formación será impresa en formato de página de notas,
de forma que en la parte de debajo de la página se puedan tomar notas respecto al contenido de la diapositiva.
En el caso de que el tamaño de la imagen de la diapositiva no sea legible, se imprimirá la diapositiva en tamaño
completo.
2.3. Normas de envío y recepción
2.3.1. Documentos a Enviar
 De cada documento se deberá enviar a la División de Automatización, una copia en soporte informático
con extensión .DOC (fichero Microsoft Word) o .PPT (fichero Microsoft Power Point) y .PDF (fichero
Adobe Acrobat), ya sea borrador, primera o última versión. Cuando se requiera, la División de
Automatización podrá solicitar copias en papel.
 La entrega deberá ser a través del Área de Documentación de la División de Automatización,

(DocDivAUT@enaire.es).
 Cuando el fichero correspondiente a un documento sobrepase el tamaño de 8Mb, éste no podrá ser
enviado por correo electrónico. En estos casos se procederá al envío a través de CD / DVD u otro medio
de almacenamiento magnético, informando de su fecha de envío al Área de Gestión de la
Documentación (DocDivAut@enaire.es).
 Los documentos (tanto las copias en papel como en soporte magnético CD / DVD) se entregarán en la
Secretaría de la División de Automatización, dirigidas al Jefe de División y a la atención de Gestión de la
Documentación de la División (sin menoscabo de su entrega informal al Director del Expediente).
 Solo los documentos entregados oficialmente al Área de Documentación de la División de

Automatización (DocDivAUT@enaire.es) o en la Secretaría de la División de Automatización y
la Base de Datos de Documentación de la División de Automatización.
 Los documentos entregados oficialmente deberán ser solo documentos que hayan concluido el proceso
de revisión interna del adjudicatario, enviando evidencias de ello, asegurando que no se harán cambios
en paralelo y que la siguiente versión solo incluirá cambios solicitados por Enaire. Solo en casos
excepcionales y previa autorización del Director del Expediente, se podrán realizar cambios en paralelo.
En el caso de que el adjudicatario incluyera algún cambio no solicitado por Enaire o cambios realizados
en paralelo, lo especificará en un formato de revisión que enviará anexo al documento.
 Cuando un documento no cumpla con los requisitos de documentación o de validación, deberá ser
modificado por el Adjudicatario tantas veces como sea necesario hasta que cumpla con dichos
requisitos.
 Cuando el contenido de un documento sufra cambios en conceptos, estrategias o elementos básicos, el

Adjudicatario deberá generar una nueva versión.
Elaborado: 14/04/16
Página: 190/201
Plataforma
 Todo cambio a un documento, se deberá realizar siguiendo los procedimientos establecidos para ello y
aprobados por Enaire.
2.3.2. Documentos a distribuir a emplazamientos.
El Adjudicatario enviará, previa petición de Gestión de Documentación de la División de Automatización de

Enaire, copias del documento en papel y soporte informático a cada uno de los emplazamientos afectados por
su contenido, que deberán ser entregadas como máximo en los 10 días siguientes a la petición.
2.3.3. Informes de Gestión de la Documentación.
 Informes por expediente: Se enviará mensualmente un informe de los documentos generados

aplicables a un expediente y enviados a la División de Automatización y también los enviados a los
distintos emplazamientos en el mes en curso, de todos los expedientes, conteniendo al menos para
cada documento: título, código, nº de LDEC (de acuerdo al PPT), edición / versión, fecha de edición y
fecha de remisión. Este informe puede ser incluido en el Informe de Seguimiento.
 Informe de varios expedientes adjudicados: Cuando el Adjudicatario tenga más de un expediente

adjudicado, enviará mensualmente un informe de los documentos generados y enviados a la División
de Automatización y también los enviados a los distintos emplazamientos en el mes en curso, de todos
los expedientes que tenga adjudicados, conteniendo al menos para cada documento: título, código, nº
de LDEC (de acuerdo al PPT), edición / versión, fecha de edición y fecha de remisión.
Este informe debe ser firmado por el Responsable del Departamento de Gestión de Documentación del
Adjudicatario y debe contener un espacio para la firma de validación de su homólogo en Enaire.
3. Documentación a entregar
En la reunión de inicio del proyecto entre el Adjudicatario y el Director del expediente por parte de Enaire,
basándose en lo establecido en el PPT, se concretará qué documentos constituirán la lista de documentación a
entregar por el Adjudicatario (LDEC), que es la documentación mínima que el Adjudicatario deberá presentar a
Enaire. Esta LDEC figurará en el Plan de Documentación del Proyecto.
Además de la documentación contemplada en la LDEC, el Adjudicatario deberá entregar los manuales y

documentos del fabricante que acompañan a cada equipo, necesarios para la explotación del hardware, así
como uso y mantenimiento del software de base a adquirir en el expediente.
4. Codificación del documento
Todo documento deberá tener un código único que lo identifique unívocamente, el cual contendrá información
relativa a:
- proyecto,
- elemento del proyecto,
- tipo de documento,
Elaborado: 14/04/16
Página: 191/201
Plataforma
- edición,
- nº secuencial dentro del elemento del proyecto.
El código de identificación seguirá el modelo: XYYYYYZZI.NNN , en el que:

- X: Identificativo del proyecto:
Ejemplo:
 A: ICARO,
 G: General,
 S: SACTA,
 V: SCV.
- YYYYY: Acrónimo del componente sobre el que trata el documento.

La longitud del acrónimo puede variar entre 1 y 5 caracteres máximo.
Al ser editado el PPT para el nuevo proyecto, sistema o elemento, se especificarán los acrónimos a utilizar
en la documentación que se origine.
Ejemplo: AIS, AMAN, CMON, COM, CORA, DMAN, FOCUC, GBDA, GIPV, GIV, GPVR, GSI, GTA, MET, MTCD, PDV,
PGRAF, PIV, PIVL, PLATN, POSCO, PPS, PRAD, PRR, PSI, PSIAT, SACTA, SCOM, SDL, SEI, SINA, SIS,
SMAN, SPV, SSD, TCPV, TDVM, TLPV, TPV, UAST, UDDE, VICTO, ....
- ZZ: Identificativo del tema del documento.

Ejemplo:
AQ: Arquitectura.
CF: Configuración.
CI: Propuestas de cambio
CP: Control proyecto.
DE: Documentación de Entrenamiento.
DI: Diseño de la Instalación.
DS: Diseño del sistema.
DU: Diseño software.
ER: Especificaciones de Requisitos.
GC: Garantía de calidad.
GE: General.
IC: Informe de Configuración.
IF: Interfaces.
IG: Informes (genérico)
IP: Informes de Pruebas.
IS: Informe de seguimiento.
IT: Instalación.
MC: Manual Curso.
MS: Manual del Sistema.
MT: Manual de Mantenimiento.
MU: Manuales de Usuario.
NR: Normas y procedimientos.
NT: Nota Técnica
PC: Plan de Gestión de Calidad / Plan de Calidad.
PD: Plan de Gestión de Documentación.
PE: Plan de Formación o Entrenamiento.
Elaborado: 14/04/16
Página: 192/201
Plataforma
PF: Plan de Gestión de Configuración.

PG: Plan de Gestión del Proyecto.
PH: Plan de Cualificación de Herramientas
PI: Plan de Instalación.
PL: Planes (genérico)
PN: Plan de Integración
PP: Plan de Pruebas.
PR: Procedimientos de Pruebas.
PS: Plan de Seguridad y Salud/ Evaluación de Riesgos y Plan de Medidas Preventivas.
PU: Plan de Aseguramiento de COTS
PV: Plan de Verificación
PW: Plan de Desarrollo de SW
PY: Plan Safety
SF: Safety
SG: Seguridad.
- I: Indicativo del idioma del documento:

 Para documentos en español, E
 Para documentos en inglés, I
- NNN: Nº de orden de publicación dentro del elemento del proyecto.
4.1. Edición / Revisión de documentos
Se determinará como identificador de los documentos su edición y revisión, lo que figurará en cada una de las
páginas de los mismos.
 E: Indicativo de la edición del documento:

Cuando se trate de la edición final de un documento se utilizarán sólo cifras numéricas en orden
creciente: 1 para la 1ª, 2 para la 2ª, 3 para la 3ª, etc.
 R: Indicativo de revisión del documento, que solo aparecerá cuando se trate de borradores:
Para la edición de un documento en versión borrador, se utilizará el número de versión que se trata
más una letra del abecedario en orden ascendente: A para primer borrador, B para 2º, C para 3º, etc.
Ejemplo:
Creación de documento, primer borrador: XYYYYYZZE.NNN Ed/Rv 1A
Creación de documento, segundo borrador XYYYYYZZE.NNN Ed/Rv 1B
Primera edición aprobada: XYYYYYZZE.NNN Ed/Rv 1
Primera revisión a la edición aprobada: XYYYYYZZE.NNN Ed/Rv 2A
Segunda edición aprobada: XYYYYYZZE.NNN Ed/Rv 2
A modo de ejemplo se citan algunos documentos que serán únicos para cada proyecto de la División de
Automatización, con su codificación correspondiente a la 1ª edición:
Plan de Gestión del Proyecto XYYYYYPGE.001 Ed/Rv 1
Plan de Gestión de Calidad XYYYYYPCE.002 Ed/Rv 1
Elaborado: 14/04/16
Página: 193/201
Plataforma
Plan de Gestión de Documentación XYYYYYPDE.003 Ed/Rv 1

Plan de Gestión de Configuración XYYYYYPFE.004 Ed/Rv 1
Plan de Pruebas XYYYYYPPE.006 Ed/Rv 1
Plan de Instalación XYYYYYPIE.007 Ed/Rv 1
Plan de Formación XYYYYYPEE.008 Ed/Rv 1
4.2. Codificación del fichero
El nombre del fichero de los documentos enviados en formato electrónico deberá ser:
<ZZ>_<Título del documento abreviado>_< XYYYYYZZE_NNN_ E_R >. <extensión>
Ejemplo:
1er borrador: PC_Plan Calidad_XYYYYYPCE_002_1_A. doc
1ª edición aprobada: PC_Plan Calidad_XYYYYYPCE_002_1. doc
PC_Plan Calidad_XYYYYYPCE_002_1. pdf
5. Revisión de la documentación contractual
Cuando existan comentarios a un documento recibido por parte de la División de Automatización, se notificará
al Adjudicatario, indicando de forma detallada las discrepancias y las acciones correctoras que se requieren:
 El Adjudicatario implantará las correcciones requeridas y enviará los cambios a la División de

Automatización en una nueva edición / revisión del documento, junto con las hojas de comentarios que
incluirá las acciones realizadas, y en caso de existir posibles discrepancias, éstas se indicarán también en
la hojas de comentarios para ser analizadas por los autores de los comentarios, comenzando de nuevo el
procedimiento de revisión.
 Caso de estar en desacuerdo la División de Automatización con las respuestas enviadas por el
Adjudicatario, se procederá a su aclaración, pudiendo ser tratadas en una reunión o en la siguiente revisión
formal.
Toda notificación se realizará a través de Gestión de Documentación de la División de Automatización.
Elaborado: 14/04/16
Página: 194/201
Plataforma
Anexo C: Matriz trazabilidad con garantía seguridad de los servicios y suministros

exteriores
El contenido de este anexo se ajusta a lo requerido en el documento código A111B-12-INS-001-2.0
[N14].
RSGS APLICABLES A TODOS LOS SERVICIOS CON POTENCIAL AFECCIÓN A LASEGURIDAD
Núm. Req SECCION
RSG1. Requisitos para la gestión de seguridad
RSG1.1. El proveedor exterior se comprometerá a colaborar con Pliego 2.2.1 Normativa

la unidad de Enaire responsable del servicio para el aplicable
cumplimiento de los sus procedimientos internos,
instrucciones, métodos de trabajo, manuales, Pliego 2.25 Cláusula de
acuerdos, o similar, que le puedan ser de aplicación en prevención de riesgos
función de la naturaleza del servicio, y en particular laborales.
con lo establecido en relación a la gestión de la
Enaire.
RSG2. Requisitos para los sistemas de gestión documental y registro
RSG2.1. El proveedor exterior deberá disponer de un sistema Pliego 2.6.4 Elaborar el

de gestión documental y registro aplicado por lo Plan de Gestión de la
menos al servicio a proporcionar. Documentación
Pliego 2.6.5 elaborar el

Plan de Gestión de la
Calidad
RSG2.2. El proveedor exterior deberá proporcionar a Enaire Pliego 2.6.4 Elaborar el

todas las evidencias documentales relacionadas con la Plan de Gestión de la
seguridad que le sean solicitadas a lo largo de la Documentación
prestación del servicio.
Pliego 2.6.5 elaborar el
plan de Gestión de la
Calidad
Pliego 2.7 Lista de

Documentación a entregar
por el adjudicatario (LDEC)
RSG3. Requisitos para la supervisión de seguridad
RSG3.1. El proveedor exterior se deberá someter, cuando se le Pliego 2.31 Inspecciones

solicite, a auditorías o inspecciones de seguridad por Pliego 2.6.2.1.2 Reuniones
parte de Enaire, o de quién ésta designe conjuntas y auditorías
Pliego 2.6.5.2 Auditorías
Elaborado: 14/04/16
Página: 195/201
Plataforma
RSG4. Requisitos para corrección de desviaciones detectadas
RSG4.1 A solicitud de Enaire, el proveedor exterior deberá Pliego 2.6.8

llevar a la práctica las medidas correctivas que sean Procedimientos ante
necesarias para subsanar desviaciones detectadas en desviaciones y
los requisitos de seguridad exigibles al servicio. concesiones
RSG4.2 El proveedor exterior deberá documentar la Pliego 2.6.8

implantación de las medidas correctivas y proporcionar Procedimientos ante
a Enaire las nuevas evidencias de cumplimiento de desviaciones y
requisitos de seguridad o las evidencias actualizadas concesiones
según sea necesario.
RSG4.3 En el caso de que el proveedor exterior sea un Pliego 2.6.8

proveedor de servicios de navegación aérea o un Procedimientos ante
gestor aeroportuario y siempre que se identifique la desviaciones y
necesidad de implantación de medidas de mitigación concesiones
adicionales respecto a un servicio prestado por un
proveedor exterior, se realizará un análisis objetivo de
necesidad, conveniencia y viabilidad técnica y
económica para alcanzar un acuerdo respecto a su
implantación.
En caso de que las partes no alcancen un acuerdo,

Enaire remitirá la discrepancia a la AESA, de acuerdo a
lo establecido por ésta al efecto.
RSG5. Requisitos para el traslado de responsabilidades a terceros
RSG5.1 El proveedor será responsable de trasladar y hacer Pliego 2.23 Cláusula de

cumplir los requisitos de seguridad que le sean medios humanos
aplicables tanto a su propio personal como a los
trabajadores de sus contratas o subcontratas y de
cualesquiera otras empresas o entidades que tengan
algún tipo de contacto formal o de colaboración con el
contratista para el servicio que va a proporcionar a
ENAIRE, así como de obtener las evidencias de
cumplimiento correspondientes
RSGs relativos al personal del proveedor exterior
RSG6. Requisitos de competencia mínima del personal aplicables a todos los

servicios
RSG6.1 El proveedor exterior deberá garantizar que todo el Pliego 2.23 Cláusula de
personal asignado al Servicio, incluyendo las nuevas medios humanos
incorporaciones, tiene los conocimientos mínimos
necesarios en materia de seguridad operacional Para PCP Anexo 1
ello deberá evidenciar, mediante registro de entrega de Documentación
documentación con acuse de recibo o similar, que todo acreditativa de Solvencia
el personal asignado al servicio objeto del expediente técnica
ha recibido la documentación de seguridad operacional
establecida, en función de la naturaleza del mismo, y
Elaborado: 14/04/16
Página: 196/201
Plataforma
que se detalla en el anexo D de la instrucción.
RSG6.2 El proveedor exterior deberá garantizar que el personal Pliego 2.23 Cláusula de
destinado al servicio exterior ha recibido la formación medios humanos
adecuada y es competente para el desempeño de la
tarea asignada, según lo que se haya establecido al PCP Anexo 1
efecto en el contacto formal. Documentación
acreditativa de Solvencia
técnica
RSG6.3 El proveedor exterior deberá garantizar que cualquier Pliego 2.23 Cláusula de
nueva incorporación es formada adecuadamente y que medios humanos
todo el personal destinado al servicio continúa siendo
competente para el desempeño de la tarea asignada a PCP Anexo 1
lo largo del periodo de prestación. Documentación
técnica
RSG6.4 El proveedor exterior deberá mantener los registros Pliego 2.23 Cláusula de
apropiados sobre la formación y competencia de su medios humanos
personal.
PCP Anexo 1
Documentación
técnica
RSGs relativos al SW de equipos ATM/CNS homologados relacionados con la

seguridad
RSG10 Requisitos sobre los niveles de garantía de seguridad del SW (SWAL)
RSG 10.1 El proveedor exterior deberá asegurar que el software Pliego 2.6.11 Gestión de
incluido en el suministro cumple con los niveles de SW Assurance
garantía de seguridad del SW (SWAL) solicitados por
ENAIRE de acuerdo con el SSAS descrito en el Anexo A
Procedimiento Específico de Análisis de Riesgos y
Estudios de Seguridad ENAIRE(A111b-06-PES-
001).Alternativamente, y en caso necesario, el
proveedor exterior presentará una propuesta
justificada de reasignación de SWAL en base a la
arquitectura propuesta del sistema y teniendo en
cuenta el SWAL solicitado en primera instancia. Esta
propuesta deberá ser aceptada por Enaire.
RSG 10.2 El proveedor exterior garantizará la independencia Pliego 2.6.11 Gestión de

entre elementos SW con diferente SWAL asignado o SW Assurance
bien demostrará el cumplimiento del SWAL más crítico
para todos los elementos SW relacionados entre sí.
RSG 10.3 El proveedor exterior entregará las evidencias Pliego 2.6.11 Gestión de
solicitadas por Enaire en las fases especificadas, para SW Assurance
demostrar los niveles de garantía de seguridad del SW
de acuerdo con el SSAS descrito en el Anexo A del
Procedimiento Específico de Análisis de Riesgos y
Elaborado: 14/04/16
Página: 197/201
Plataforma
Estudios de Seguridad Enaire (A111b-06-PES-001)
RSGs relativos a la instalación de equipos ATM/CNS homologados relacionados con la

seguridad o sistemas auxiliares
RSG11 Requisitos para la instalación de equipamiento ATM/CNS homologados

relacionados con la seguridad o sistemas auxiliares
RSG 11.1 El proveedor exterior deberá proporcionar una Pliego 2.6.1.5 Instalación y
descripción de las actividades a llevar a cabo para la despliegue.
instalación del equipamiento ATM/CNS homologado
relacionado con la seguridad o de sistemas auxiliares.
RSG 11.2 El proveedor exterior realizará un análisis y mitigación Pliego 2.6.10 Gestión de
de riesgos de la instalación sobre la base del plan de Safety
instalación con anterioridad al inicio de ésta. Este
análisis considerará los riesgos de las actividades de
instalación en el conjunto de los servicios ATM/CNS
RSG 11.3 El proveedor exterior implantará las medidas de Pliego 2.6.10 Gestión de
mitigación que se deriven del análisis y mitigación de Safety
riesgos de la instalación dentro de su ámbito de
competencia y proporcionará las evidencias
correspondientes.
RSGs relativos a la puesta y/o retirada de operación de equipos ATM/CNS homologados

relacionados con la seguridad o sistemas auxiliares
RSG 12 Requisitos para la puesta y/o retirada de operación de equipos ATM/CNS

homologados relacionados con la seguridad o sistemas auxiliares
RSG 12.1 El proveedor exterior deberá proporcionar una Solo aplicarán cuando la
descripción de las actividades a llevar a cabo para la responsabilidad de la
puesta en operación y/o retirada del equipamiento transición o puesta en
ATM/CNS homologado relacionado con la seguridad o servicio sea transferida a
sistemas auxiliares, incluyendo las correspondientes a la empresa adjudicataria
la fase de transición si fuera necesaria. del servicio o suministro
RSG 12.2 El proveedor exterior proporcionará el soporte técnico Pliego 2.6.1.6 Transición
necesario para que Enaire elabore el análisis y
mitigación de riesgos de la transición y/o puesta en
operación y/o retirada del equipamiento.
RSG 12.3 El proveedor exterior implantará las medidas de Solo aplicarán cuando la
mitigación que se deriven del análisis y mitigación de responsabilidad de la
riesgos de la transición y/o puesta en operación y/o transición o puesta en
retirada dentro de su ámbito de competencia, servicio sea transferida a
proporcionando las evidencias correspondientes que le la empresa adjudicataria
sean solicitadas por Enaire. del servicio o suministro
Elaborado: 14/04/16
Página: 198/201
Plataforma
REQUISITOS DE SEGURIDAD ESPECÍFICOS Y EVIDENCIAS ASOCIADAS
RSEs y evidencias relativos a la competencia del personal del En el momento de la redacción de un

proveedor exterior PPT no se dispone de requisitos
específicos relativos a la competencia
del proveedor exterior
RSEs y evidencias relativos al suministro de equipos ATN/CNS homologados relacionados con la

seguridad
Requisitos de seguridad del producto y evidencias asociadas Pliego 2.6.10 Gestión de Safety
Pliego 2.6.11 Gestión de SW

Assurance
Requisitos sobre Garantía de Seguridad del Software y En el momento de la redacción de un

evidencias asociadas PPT no se dispone de requisitos ni
objetivos de seguridad ni de
asignación de requisito de SWAL
Elaborado: 14/04/16
Página: 199/201
Plataforma
Anexo D: Política de Gestión Integrada
Elaborado: 14/04/16
Página: 200/201
Plataforma
3. Presupuesto
En los importes que figuran en dicho presupuesto NO se han incluido los gastos por persona que figuran en el
El importe límite de este expediente asciende a la cantidad de: UN MILLON NOVECIENTOS NOVENTA Y TRES MIL
DOSCIENTOS NOVENTA Y NUEVE EUROS IMPUESTOS NO INCLUIDOS
Para la ejecución de proyecto con todos los servicios exigidos en el expediente se propone el siguiente
presupuesto detallado; donde la partida 4 ntará sin baja.
Pda. Descripción Horas Tarifa Total

1 Equipamiento SW SACTA 3.Z5 918.006,00
1.1 Especificación de Requisitos 0
1.2 Diseño-Codificación-Pruebas Unitarias de SW 519.926,00
Ingenieria de Sistemas y Gestión (T1) 0 0,00
Ingeniero (T2) 9.279 51,88 481.380,00
Ingeniero Junior (T3) 0 0,00
Subcontratación Ing. por hora a empresas externas 488 78,93 38.546,00
1.3 Integración de Sw y Pruebas Internas 227.134,00
Ingeniería de Sistemas y Gestión (T1) 0 0,00
Ingeniero (T2) 4.053 51,88 210.295,00
Ingeniero Junior (T3) 0 0,00
1.4 Pruebas de Aceptación de Sistema en CED 170.946,00
Ingeniería de Sistemas y Gestión (T1) 0 0
Ingeniero (T2) 2.947 51,88 152.888,00
Ingeniero Junior (T3) 0 0
OCD´s (viajes, dietas y otros gastos) 5.816,00
2 Actividades y Servicios de Logística 400.371,00
2.1 Control de Configuración y Gestión Documentación 92.185,00
Ingeniero (T2) 1.074 51,88 55.708,00
Ingeniero Junior (T3) 1.074 33,97 36.477,00
OCD´s (viajes, dietas y otros gastos) 0
2.2 Instalación y Pruebas en Emplazamiento 126.854,00
Ingeniero (T2) 2.416 51,88 125.344,00
2.3 Formación y Manuales de Usuario 91.372,00
Ingeniería de Sistemas y Gestión (T1) 994 78,93 78.476,00
Ingeniero (T2) 249 51,88 12.896,00
2.4 Garantía 2 años 89.960,00
Elaborado: 14/04/16
Página: 201/201
Plataforma
Pda. Descripción Horas Tarifa Total

Ingeniería de Sistemas y Gestión (T1) 0 78,93 0
Ingeniero (T2) 1.587 51,88 82.324,00
3 Dirección y Oficina de Programa 493.712,00
3.1 Gestión de Proyecto 322.862,00
Ingeniería de Sistemas y Gestión (T1) 4.027 78,93 317.829,00
Ingeniero (T2) 0 0
3.2 Gestión de Calidad 85.425,00
Ingeniero (T2) 0 0
3.3 Gestión de Safety 85.425,00
Ingeniero (T2) 0 0
suma parcial de partidas 1.812.089,00
4 SOPORTE A LA IMPLANTACIÓN 181.210,00
Total, sin impuestos 1.993.299,00
El Jefe de la División de Automatización

ENAIRE

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ENAIRE

Cargado por

Copyright:

Formatos disponibles

Expediente Desarrollo e

Implantación de A-CDM fase II:

Aprobaciones del documento

Elaborado por: Revisado por: Aprobado por:

Jefa Departamento Desarrollo de Jefe Departamento Desarrollo e

Edición Fecha Páginas afectadas Cambios

Hoja de Control de Documentación Impresa

Formato empleado: A14-09-PL-001-2.1

2. PLIEGO DE PRESCRIPCIONES TÉCNICAS

 ANEXO A: CLÁUSULAS DE FORMACIÓN

 ANEXO B: NORMAS PARA LA EDICIÓN Y CODIFICACIÓN DE LA DOCUMENTACIÓN

 ANEXO C: MATRIZ TRAZABILIDAD CON GARANTÍA SEGURIDAD DE LOS SERVICIOS Y

 ANEXO D: POLÍTICA DE GESTIÓN INTEGRADA

1.2. Necesidad del servicio ........................................................................................................10

1.3. Objeto del servicio ...............................................................................................................10

1.4. Importe límite ......................................................................................................................12

1.5. Plazo de ejecución ...............................................................................................................12

2. Pliego de prescripciones técnicas ............................................................................................13

2.2. Documentación de referencia ............................................................................................15

2.2.1. Normativa aplicable .....................................................................................................17

2.3. Introducción .........................................................................................................................18

2.3.2. Necesidad del servicio .................................................................................................18

2.3.4. Estructura del documento ...........................................................................................20

2.4. Descripción general y estrategia de evolución ................................................................23

2.4.1. Situación actual ............................................................................................................23

2.4.2. Estrategia de evolución ...............................................................................................23

2.5. Requisitos técnicos .............................................................................................................24

2.5.2. Composición del proyecto ............................................................................................25

2.5.2.1. Equipamiento SW ............................................................................................................................ 25

2.5.2.2. Servicios ........................................................................................................................................... 26

2.5.3. Requisitos funcionales y operativos a nivel usuario-sistema para CDM .............28

2.5.3.1. SA#4427. CDM. Mejora en el tratamiento de condiciones adversas .......................................... 28

2.5.3.2. SA#4428. CDM. Cambios en el tratamiento de PVs con CTOT ..................................................... 41

2.5.3.3. SA#4430. Función de extensión de tiempos de taxi ..................................................................... 45

2.5.3.4. SA#4563. Cambio programado de capacidades pista .................................................................. 53

2.5.3.5. SA#4564. CDM. Función de paradas de puesta en marcha ......................................................... 56

2.5.3.6. SA#4982. Modificación al cambio programado de aerodromos para CDM ................................ 64

2.5.3.7. SA#6597. CDM. No caducidad de PV con STS ................................................................................ 67

2.5.3.8. SA#7135. CDM. No recalculo de TSAT si ASAT antes de TSAT...................................................... 67

2.5.3.9. SA#8165. Funcionalidad en TWR con configuraciones de pistas ............................................... 68

2.5.3.10. SA#8181. No actualización de EOBT por mensaje SLC ................................................................. 77

2.5.3.11. SC#11773. Implementación de la interfaz SACTA-CDM ............................................................... 77

2.6. Aseguramiento del proyecto ........................................................................................... 121

2.6.1. Metodología de desarrollo SW ................................................................................. 122

2.6.1.1. General ...........................................................................................................................................122

2.6.1.2. Fases de desarrollo e hitos ..........................................................................................................123

2.6.1.3. Planificación ...................................................................................................................................123

2.6.1.4. Entrega en el CED ..........................................................................................................................124

2.6.1.5. Instalación y despliegue ...............................................................................................................125

2.6.1.6. Transición .......................................................................................................................................126

2.6.1.7. Formación ......................................................................................................................................126

2.6.1.8. Seguimiento ...................................................................................................................................127

2.6.2. Elaborar el plan de gestión de proyecto .................................................................. 127

2.6.2.1. Control del proyecto ......................................................................................................................128

2.6.2.2. Métricas del proyecto ....................................................................................................................130

2.6.2.3. Gestión de riesgos .........................................................................................................................133

2.6.2.4. Control de subcontratistas y proveedores ..................................................................................133

2.6.3. Elaborar el Plan de Gestión de la Configuración .................................................... 133

2.6.3.1. Control de cambios ........................................................................................................................135

2.6.3.2. Resolución de problemas / incidencias ......................................................................................135

2.6.4. Elaborar el Plan de Gestión de la Documentación ................................................. 135

2.6.4.1. Revisión de documentos...............................................................................................................137

2.6.5. Elaborar el Plan de Gestión de la Calidad ............................................................... 137

2.6.5.1. Plan de gestión de la calidad ........................................................................................................137