Un informe técnico de la Aeronáutica Civil sobre las fallas registradas el 4 de noviembre en el Centro de Control Aéreo de Bogotá señala que los problemas de visualización radar estuvieron acompañados de comportamientos anormales en la red de comunicaciones y que la contingencia volvió a presentarse horas después, mientras se adelantaban pruebas para incorporar servicios asociados a San Andrés a esa infraestructura.
La situación afectó varias posiciones de trabajo de los controladores aéreos, cuyas pantallas dejaron de actualizar normalmente la información del tránsito aéreo. La primera falla fue reportada a las 12:39 del mediodía y el servicio logró restablecerse parcialmente a la 1:35 pm, después de varias intervenciones sobre los servidores y componentes del sistema de vigilancia.
El informe, elaborado por las técnicas ATSEP Luisa Fernanda Vela y Kinwerly Santamaría Suárez y entregado el 6 de noviembre de 2026, registra que las primeras acciones de recuperación no consiguieron solucionar el problema. También documenta una segunda afectación, aproximadamente a las 4 pm, que coincidió con actividades técnicas sobre la infraestructura de comunicaciones del Centro de Control.
La causa raíz de la contingencia todavía está bajo investigación. Sin embargo, las verificaciones realizadas durante la atención identificaron posibles afectaciones en la distribución de información y en las comunicaciones internas del sistema ATM AIRCON/ICON, utilizado por el Centro de Control ACC Bogotá.
Las pantallas radar dejaron de actualizar la información
La primera alerta se produjo a las 12:39 pm, cuando el supervisor del Centro de Control ACC Bogotá reportó que varias posiciones operativas presentaban congelamiento de las pantallas radar.
El personal técnico de Vigilancia Radar se desplazó hasta el área para verificar las estaciones de trabajo de los controladores, conocidas como CWP. Durante la revisión encontró que algunas permitían cambiar del modo Integrado al modo BYPASS, pero la modificación no solucionaba el congelamiento ni permitía recuperar la actualización normal de la información del tránsito aéreo.
Ante la afectación simultánea de varias posiciones, los técnicos iniciaron un diagnóstico de los componentes del sistema desde la consola CMD. En esa primera revisión encontraron que los servidores de la Cadena 1 aparecían en estado MASTER y que la arquitectura redundante mantenía condiciones normales de disponibilidad.
Posteriormente, se solicitó apoyo remoto al técnico Mario Rosas para avanzar en la recuperación. Entre las primeras medidas estuvieron los reinicios controlados de los servidores SDP y la preparación del equipo de respaldo de la Cadena 2, que se encontraba en estado STANDBY.
A las 12:55 pm se ejecutó una conmutación TANDEM para transferir las funciones entre los servidores SDP. Sin embargo, la maniobra no permitió recuperar las pantallas radar, que continuaron presentando información congelada.
Las revisiones se extendieron entonces a la infraestructura de comunicaciones del Centro de Control. A la 1:05 pm, el personal técnico inspeccionó los switches, las alarmas locales, el estado de los equipos y la sincronización NTP en el piso 10 de la Torre de Control.
Aunque no se encontraron alarmas activas ni evidencias de daños físicos en los dispositivos revisados, las pruebas de conexión entre las estaciones CWP35, CWP17 y CWP18 mostraron comportamientos anormales.
Los tiempos para establecer conexiones llegaron a cerca de un minuto, se registraron latencias superiores a las habituales y no fue posible ejecutar correctamente algunos comandos remotos, incluidos los reinicios de equipos.
Estas condiciones llevaron a considerar una posible degradación o saturación de la red de comunicaciones. Paralelamente, personal del grupo TO de la Dirección de Telecomunicaciones adelantaba verificaciones sobre las redes LAN 1 y LAN 2.
Los técnicos también realizaron nuevos reinicios de los servidores SDP2 y SDP1, separados por aproximadamente 30 segundos, pero las posiciones operativas continuaron presentando dificultades.
La recuperación se produjo después de intervenir otros servidores
Ante la persistencia de la falla, a la 1:20 pm se estableció comunicación con el técnico Germán Parra, quien recomendó detener temporalmente la aplicación ICON y realizar un nuevo arranque controlado.
La intervención permitió que las pantallas comenzaran a recibir nuevamente información radar, aunque inicialmente continuaron presentando lentitud y no todos los componentes recuperaron sus funciones automáticamente.
El procedimiento consistió en detener la aplicación mediante el comando STOP y ejecutar su arranque con la instrucción STARTUP, con un intervalo aproximado de 30 segundos entre ambas acciones.
Después de esta intervención, los técnicos encontraron que los servidores SDP, DRF y SNET habían recuperado su funcionamiento, pero los componentes FDP, DLS y RDCU permanecían fuera de servicio.
Por esta razón, a la 1:29 pm el personal se desplazó al centro de datos para revisar directamente los servidores afectados mediante acceso local por KVM y realizar nuevos procedimientos de recuperación.
Durante estas actividades, el servidor RDCU1 logró iniciar correctamente y posteriormente el FDP de la Cadena 1 completó su proceso de arranque.
A la 1:35 p. m. se confirmó la recuperación de la presentación radar, la actualización del tránsito aéreo, la visualización de etiquetas en tiempo real y la respuesta de las posiciones operativas.
No obstante, después del restablecimiento se identificó una pérdida temporal de información relacionada con los planes de vuelo. Esta situación fue atendida mediante la retransmisión y recuperación de los datos asociados al FDP.
El informe también precisa que la intervención realizada a la 1:20 p. m. no correspondió a un procedimiento de Global Shutdown, como podría interpretarse en medio de las discusiones técnicas sobre la contingencia.
Según la descripción de las actividades, únicamente se detuvo y reinició la aplicación ICON, sin ejecutar las etapas características de un apagado global del sistema ni las opciones de confirmación correspondientes a las modalidades Hot o Cold.
Los responsables de la revisión señalan que no existen elementos técnicos concluyentes para atribuir automáticamente la pérdida temporal de los planes de vuelo a una ejecución incorrecta del procedimiento de recuperación. La novedad continúa bajo análisis mediante la revisión de los eventos registrados en los servicios FDP.
La falla reapareció durante pruebas relacionadas con San Andrés
Aunque las posiciones operativas habían recuperado su funcionamiento, la contingencia volvió a presentarse aproximadamente a las 4:00 p. m., cuando el supervisor Jorge Atehortúa reportó un nuevo congelamiento parcial en algunas estaciones del Centro de Control ACC Bogotá.
Durante esta segunda revisión se encontró que los servidores principales permanecían operativos y no mostraban alarmas aparentes relacionadas con los subsistemas ATM.
Sin embargo, los técnicos identificaron que personal del grupo TO estaba realizando actividades para incorporar y probar servicios asociados a San Andrés sobre la infraestructura de red del Centro de Control.
Después de solicitar la suspensión de esas actividades y desconectar los servicios que estaban siendo incorporados a la red, se observó nuevamente la estabilización de las posiciones operativas y la recuperación de su funcionamiento.
Este episodio quedó registrado como uno de los elementos relevantes para el análisis técnico, debido a la coincidencia entre las pruebas de conexión, la reaparición del congelamiento y la posterior normalización de las estaciones.
El personal de Vigilancia Radar también señaló que los trabajos adelantados sobre la infraestructura de comunicaciones no habían sido coordinados previamente con la operación ATS, la supervisión operacional ACC ni con el grupo técnico encargado de administrar y brindar soporte a la plataforma ICON.
Tampoco se tenía conocimiento de una evaluación conjunta de riesgos operacionales ni de una programación concertada para realizar las pruebas durante una ventana de baja demanda.
En el análisis preliminar, los responsables consideran poco probable que la causa principal estuviera relacionada exclusivamente con el procesamiento de vigilancia SDP. Entre los argumentos se encuentra que la conmutación de estos servidores no permitió solucionar la contingencia y que las pruebas de conectividad evidenciaron tiempos de respuesta muy superiores a los habituales.
El congelamiento simultáneo de varias pantallas, las dificultades para establecer conexiones remotas y la reaparición de la falla durante las pruebas de red son algunos de los indicios que orientan la investigación hacia una posible afectación de las comunicaciones internas.
El informe también advierte que el congelamiento de las pantallas no demuestra necesariamente que se hayan presentado fallas en los sensores radar o ADS-B. La información que reciben los controladores depende de la interacción de diferentes componentes, entre ellos los sensores de vigilancia, los procesadores RDCU y SDP, los servidores SNET, las estaciones de trabajo y la infraestructura de comunicaciones.
De hecho, durante la atención de la contingencia no se encontraron evidencias concluyentes de pérdida del servicio de los sensores de vigilancia, interrupción de los datos radar de entrada o fallas específicas en los subsistemas encargados de adquirir esa información.
A partir de las 4:15 pm se mantuvo el monitoreo permanente de los servidores, servicios y eventos registrados en la consola CMD. Las alertas generadas durante el incidente quedaron bajo revisión para determinar el origen de las afectaciones y establecer las medidas preventivas correspondientes.
Por ahora, la investigación no tiene una causa raíz concluyente, pero los registros técnicos dejan constancia de dos episodios de congelamiento de las pantallas radar y de la coincidencia de la segunda falla con las pruebas de incorporación de servicios de San Andrés a la red del Centro de Control Aéreo de Bogotá.