El colapso del sistema de control de tráfico aéreo del Reino Unido

 (jameshaydon.github.io)
2 puntos por GN⁺ 2023-09-12 | 1 comentarios | Compartir por WhatsApp
  • El 28 de agosto de 2023, una falla en FPRSA-R de NATS, el operador del control de tráfico aéreo del Reino Unido, provocó la cancelación de más de 2,000 vuelos, con un costo estimado de más de 100 millones de libras
  • El plan de vuelo que desencadenó el caos era un plan válido aceptado por Eurocontrol IFPS, y el sistema de NATS intentó extraer el tramo dentro del espacio aéreo del Reino Unido haciendo coincidir los datos ADEXP con la ruta ICAO4444
  • La causa directa fue que dos waypoints geográficamente distintos tenían el mismo identificador, y FPRSA-R emparejó por error un identificador duplicado como punto de salida, por lo que no pudo construir un tramo válido del Reino Unido
  • El sistema principal y el de respaldo procesaron el mismo plan de vuelo con la misma lógica, ambos arrojaron una critical exception y entraron en maintenance mode en menos de 20 segundos, deteniendo el procesamiento automático
  • Las aeronaves siguieron siendo controladas con seguridad, pero quedaron como problemas el modo de falla que permitió que un solo plan de vuelo detuviera todo el sistema de procesamiento automático, la falta de pruebas suficientes y un procedimiento de recuperación que dependía de logs de bajo nivel

La magnitud de la falla de NATS del 28 de agosto de 2023

  • NATS, operador del control de tráfico aéreo del Reino Unido, sufrió una falla técnica grave el 28 de agosto de 2023
  • Según la BBC, se cancelaron más de 2,000 vuelos y el costo se estima en más de 100 millones de libras
  • Es posible que la falla haya afectado a cientos de miles de personas
  • Los reportes iniciales en medios hablaron de un “plan de vuelo incorrecto” o de un posible “error de una aerolínea francesa”, pero el plan de vuelo que causó el problema era un plan conforme con ICAO4444 aceptado por Eurocontrol IFPS
  • Más tarde se identificó que el vuelo que realmente desencadenó la falla fue el French Bee FBU731, que viajaba de LAX/KLAX a ORY/LFPO

Cómo llega un plan de vuelo hasta NATS

  • La aerolínea envía el plan de vuelo a IFPS de Eurocontrol
    • Si IFPS acepta el plan de vuelo, la aeronave puede despegar tras la aprobación del control del aeropuerto de salida
    • En esta etapa no se requiere ninguna entrada de NATS
  • IFPS transmite el plan de vuelo a los proveedores de servicios de navegación aérea correspondientes
    • NATS debe recibir el plan de vuelo al menos 4 horas antes de que la aeronave entre al espacio aéreo del Reino Unido
    • Esas 4 horas funcionan como margen para resolver problemas de procesamiento
  • En la operación en ruta de NATS en Swanwick Centre, los datos se envían a FPRSA-R
    • FPRSA-R convierte los datos en formato ADEXP recibidos de IFPS a un formato compatible con el UK National Airspace System, es decir, NAS
    • NAS es el sistema de procesamiento de datos de vuelo que contiene la información relevante de espacio aéreo y rutas

Diferencias entre ICAO4444 y ADEXP

  • El plan de vuelo ICAO4444 es un formato legible por máquina y, si hace falta, también por personas
    • La parte de ruta incluye velocidad, altitud, waypoints, nombres de ruta e indicadores de vuelo directo como DCT
    • Por ejemplo, N0440 significa 440 nudos y F310 significa Flight Level 310
  • IFPS convierte el plan de vuelo ICAO4444 al formato ADEXP antes de transmitirlo
    • ADEXP incluye el plan de vuelo ICAO4444 original junto con waypoints geográficos adicionales para la ruta en la región europea
    • En vuelos que no aterrizan en el Reino Unido, sino que atraviesan su espacio aéreo, también puede incluir waypoints necesarios para el tramo posterior fuera del Reino Unido
  • RTEPTS en ADEXP contiene con más detalle la altitud y la hora estimada de paso de cada waypoint
    • La ruta ICAO puede tener 9 waypoints, pero la lista ampliada en ADEXP puede incluir 21 waypoints
    • El origen y el destino de la ruta ICAO están en campos separados, por lo que no se vuelven a incluir en la lista de ruta

Los waypoints duplicados que provocaron la falla

  • La lista de waypoints ADEXP del caso tenía dos waypoints geográficamente distintos con el mismo designator
    • ICAO y otras organizaciones han trabajado para eliminar nombres de waypoint no únicos, pero todavía existen nombres duplicados en todo el mundo
    • Los estándares más recientes establecen que los waypoints con el mismo identificador deben estar geográficamente muy separados
    • En este caso, ambos waypoints estaban fuera del Reino Unido: uno al inicio de la ruta y otro al final, separados por unas 4,000 millas náuticas
  • En el plan de vuelo ampliado del vuelo identificado, FBU731, el waypoint DVL aparecía dos veces
    • Uno correspondía a Devil’s Lake, Wisconsin, en Estados Unidos
    • El otro a Deauville, en Normandía, Francia
    • Se explica que este último apareció en la parte final del vuelo durante la expansión de la ruta UN859

El procedimiento de procesamiento de FPRSA-R y el punto donde falló

  • FPRSA-R busca desde el principio en los datos de waypoints ADEXP para encontrar el punto de entrada al espacio aéreo del Reino Unido
  • Luego busca el punto de salida del espacio aéreo del Reino Unido, y después intenta encontrar el tramo correspondiente en la sección ICAO4444
  • La ruta ICAO no tiene por qué incluir necesariamente el punto de salida del espacio aéreo
    • El software estaba diseñado para que, si el punto de salida no aparecía en la ruta ICAO, intentara de nuevo usando el siguiente punto más cercano del archivo ADEXP
  • En este caso, el software fue avanzando por los siguientes waypoints de ADEXP hasta encontrar un identificador duplicado que sí existía en la ruta ICAO
    • Pero ese identificador no correspondía al waypoint real posterior a la salida del espacio aéreo del Reino Unido, sino a otro waypoint geográfico ubicado al principio de la ruta
    • Como resultado, el orden o el tramo entre el punto de entrada y el de salida no era válido, y no pudo extraer el tramo ICAO correspondiente al espacio aéreo del Reino Unido
  • El informe de NATS señaló este punto como la root cause del incidente y concluyó que podía descartarse una contribución relacionada con ciberseguridad

Por qué se detuvieron al mismo tiempo el sistema principal y el de respaldo

  • El software crítico para la seguridad está diseñado para pasar a un estado que requiere intervención manual cuando no puede seguir operando de forma segura
  • El sistema principal de FPRSA-R determinó que no podía garantizar datos correctos del plan de vuelo y generó una critical exception
    • Registró el archivo de log en el log del sistema
    • Entró en maintenance mode
    • El sistema C&M detectó que el sistema principal ya no estaba disponible
  • El sistema de respaldo estaba diseñado para tomar el relevo cuando fallara el sistema principal
    • Estaba en hardware separado, con energía separada y feed de datos separado
    • Pero aplicó la misma lógica al mismo plan de vuelo y produjo el mismo resultado, generando también una critical exception
  • Desde la recepción del mensaje ADEXP hasta que tanto el sistema principal como el de respaldo entraron en maintenance mode pasaron menos de 20 segundos
  • A las 08:32 se detuvo el procesamiento automático de planes de vuelo, y desde ese momento fue necesario introducir planes de vuelo manualmente dentro del margen de 4 horas

Procedimiento de recuperación e impacto operativo

  • El equipo de soporte de 1st Line detectó la falla mediante el sistema C&M dedicado, el sistema C&M central y la retroalimentación del equipo operativo
  • La respuesta inicial fue el procedimiento estándar de recuperación de reiniciar los subsistemas desde el sistema C&M central
    • Varios intentos de recuperación fallaron
    • Se incorporó el equipo de ingeniería de 2nd Line para asistir al ingeniero en sitio mediante enlace de video remoto
  • Cuando 1st Line y 2nd Line no lograron restaurar el servicio ni identificar con precisión la causa, se solicitó apoyo al equipo de Technical Design y al fabricante del subsistema
  • El fabricante identificó, mediante análisis de logs de software de bajo nivel, el plan de vuelo que parecía haber provocado la falla
    • Después de entender ese plan de vuelo, proporcionó el procedimiento exacto para restaurar el sistema de manera controlada y segura
  • Aunque existían procedimientos para la entrada manual y la coordinación manual entre sectores durante una falla, cambiar a procedimientos manuales obligaba a aplicar restricciones de control de tráfico aéreo para reducir el flujo del tráfico en el Reino Unido

Frequentis AG y FPRSA-R

  • El subsistema FPRSA existe en NATS desde hace años, y en 2018 el sistema anterior fue reemplazado por nuevo hardware y software de Frequentis AG
  • Frequentis AG es una empresa austríaca y uno de los proveedores de sistemas de control de tráfico aéreo
  • Se sabe que los productos ATC de este fabricante operan en unos 150 países y que tiene una posición global destacada en sistemas de gestión de información aeronáutica y procesamiento de mensajes
  • En la página de empleos de Frequentis AG aparecen Ada, C++, Java y Python en relación con sistemas de control de tráfico aéreo, y Java es el más frecuente

El bug de software y los problemas de prueba

  • FPRSA-R no pudo extraer el tramo ICAO correspondiente al espacio aéreo del Reino Unido a partir de un plan de vuelo válido aceptado por IFPS
  • Los identificadores de waypoint no son globalmente únicos, y esto es un problema conocido
    • Si los waypoints duplicados están muy lejos entre sí, un plan de vuelo normal todavía puede no ser ambiguo
    • Pero el software debía manejar esta condición de forma robusta
  • NATS indicó que podría revisar, a través del gobierno del Reino Unido, la posibilidad de eliminar del conjunto global de datos administrado por ICAO un pequeño número de nombres de waypoint duplicados relacionados con este incidente
  • El CEO de NATS, Martin Rolfe, dijo a la BBC que este incidente tenía una probabilidad de “una entre 15 millones”
    • Dijo que el sistema se introdujo en 2018 y que desde entonces había procesado 15 millones de planes de vuelo
  • En un sistema crítico para la seguridad, la etapa de procesamiento del plan de vuelo, especialmente una tan importante como la extracción del tramo del Reino Unido, debería estar probada
    • Es posible que unas pruebas que no consideraran nombres de waypoint duplicados no hubieran revelado este bug
    • El fuzzing con grandes volúmenes de planes de vuelo aleatorios podría haber ayudado a encontrar entradas que llevaran al sistema a un modo de falla inadecuado

El problema del modo de falla

  • Un solo plan de vuelo detuvo todo el sistema de procesamiento automático de FPRSA-R, y como resultado ningún plan de vuelo pudo procesarse automáticamente
  • Un mejor modo de falla habría sido enviar el plan de vuelo problemático a una cola separada y más lenta para que una persona lo procesara manualmente
  • NATS dijo que, como medida ya en marcha o completada, añadirá filtros de mensajes específicos al flujo de datos entre IFPS y FPRSA-R para bloquear planes de vuelo que cumplan con las condiciones del incidente
  • Cuando FPRSA-R se detuvo, el plan de vuelo relacionado solo pudo identificarse en logs de software de bajo nivel
    • Si un error al procesar un plan de vuelo específico en un sistema de procesamiento de planes de vuelo detiene todo el sistema, sería más adecuado que se enviara de inmediato una alerta al equipo de monitoreo incluyendo ese plan de vuelo
  • NATS señaló que ya estableció guías operativas para recuperar rápidamente FPRSA-R si vuelve a repetirse la misma situación y que los operadores técnicos fueron capacitados para ejecutar el nuevo procedimiento
    • También habrá monitoreo reforzado y personal adicional con experiencia en ingeniería para supervisar la operación

Posibilidad de verificación formal

  • No hay señales claras de que se haya usado verificación formal en esa etapa y ese sistema del incidente, y el informe tampoco la menciona
  • La verificación formal o el model checking podrían haber ayudado a reducir bugs de este tipo
  • Aun así, la verificación formal end-to-end de sistemas a gran escala sigue en una etapa temprana, y aunque se hubiera usado parcialmente, seguiría existiendo la posibilidad de que código defectuoso llegara al entorno operativo
  • Será necesario esperar el resultado final de la investigación para saber mejor qué métodos de verificación se utilizaron realmente

Seguridad y reporte público

  • Las aeronaves en el espacio aéreo del Reino Unido se mantuvieron seguras durante todo el incidente
    • Controladores de tráfico aéreo con experiencia monitorearon las aeronaves mediante planes de vuelo conocidos, radio, radar y observación visual
    • El resultado no fue un riesgo para la vida, sino una situación en la que podían despegar muchos menos vuelos o había que desviar rutas para evitar el espacio aéreo del Reino Unido
  • NATS aplicó medidas para reducir el número de vuelos y así mantener la seguridad
  • El informe publicado es bastante transparente y detallado, y este tipo de reportes es importante para la infraestructura crítica
  • Michael O’Leary, de Ryanair, criticó el informe calificándolo de “rubbish” y dijo que minimiza el impacto sobre la industria aérea, aunque también se considera que el alcance del informe inicial no estaba orientado a analizar el grado de falla de NATS

Hacia una implementación más robusta

  • El problema consiste en manejar dos secuencias de waypoints
    • ADEXP: la lista completa de waypoints
    • ICAO: una subsecuencia de los waypoints de ADEXP
  • Como el plan ICAO no tiene por qué incluir necesariamente los puntos de entrada y salida del espacio aéreo, encontrar el tramo continuo más pequeño de ICAO que corresponda al espacio aéreo del Reino Unido no es algo trivial
  • El problema del algoritmo incorrecto es que manipula punteros que apuntan simultáneamente a datos ICAO y ADEXP, mientras deja fuera del código invariantes que no están claramente definidos
  • El enfoque propuesto consiste primero en alinear los datos ICAO y ADEXP en una sola estructura de plan de vuelo Combined, y luego extraer el tramo del Reino Unido
    • Calcula todas las reconciliaciones posibles para detectar casos ambiguos
    • Si hay 0 reconciliaciones, no se pueden alinear ICAO y ADEXP
    • Si hay varias, el caso es ambiguo y puede pasar a procesamiento manual
  • La implementación de ejemplo en Haskell maneja explícitamente los errores NonUkPlan, CannotReconcileIcaoAdexp y AmbiguousReconciliationsOfIcaoAdexp
  • En el ejemplo, aunque la lista ADEXP tenga un identificador duplicado Q, si los datos ICAO y ADEXP pueden alinearse sin ambigüedad, devuelve correctamente el tramo del Reino Unido
  • Todo el código está en uk-portion-of-ICAO

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-09-12
Opiniones de Hacker News

  • Básicamente omitieron una restricción de alcance geográficamente separado en la consulta del plan de vuelo. Hace tiempo, cuando estaba desarrollando sistemas de navegación aérea, conocía este bug, lo vi en la práctica y seguí una especificación que pedía agregar geocercas para evitarlo.

    • Si los nombres de los puntos de navegación no son únicos a nivel global y las rutas entre regiones son comunes, no entiendo por qué no les pusieron GUID a esos puntos de navegación.
    • Me da curiosidad saber qué lenguaje usaron para el desarrollo.
    • El estándar ICAO establece desde 1978 que, para duplicar identificadores, deben estar separados por al menos 600 millas náuticas (690 millas, 1,100 km).

  • El problema es la parte que dice: “el sistema de respaldo aplicó la misma lógica al plan de vuelo y obtuvo el mismo resultado”. En software, un sistema de respaldo debe usar una lógica distinta.
    Hace tiempo, en Boeing, cuando trabajaba con el sistema de trim del estabilizador del 757, había dos computadoras de aviónica conectadas al cableado que accionaba el trim, enlazadas mediante un comparador. Si las dos cajas no estaban de acuerdo, ambas perdían autoridad.
    Las dos cajas estaban diseñadas con algoritmos distintos, lenguajes de programación distintos, CPU distintas y código de equipos distintos separados por firewall, con la intención de que un bug en una no rompiera la otra de la misma manera.

    • Este habría sido un sistema 2oo2 en el que el piloto actuaba como respaldo, pero 2oo2 no tiene alta disponibilidad.
      Un sistema de control de tráfico aéreo debería ser al menos 2oo3[1], es decir, una estructura en la que siempre deban coincidir 2 de 3 sistemas desarrollados de forma independiente. Así, aunque un sistema falle, los otros dos siguen operando y no afectan la disponibilidad de la industria aérea.
      Tener personas como respaldo es inviable por personal y complejidad. Un sistema de control de tráfico aéreo debe poder proporcionar separación bajo condiciones IFR[2] y CVFR[3].
      [1] https://en.wikipedia.org/wiki/Triple_modular_redundancy
      [2] https://en.wikipedia.org/wiki/Instrument_flight_rules#Separa...
      [3] https://en.wikipedia.org/wiki/Visual_flight_rules#Controlled...
    • Al leerlo, eso fue lo primero que pensé. Este sistema de conmutación por error parece haber sido diseñado más para mitigar fallas de hardware que bugs de software.
    • “Cuando un sistema de seguridad falla, falla de una forma que no es segura”.
      J. Gall
    • Equipos distintos también suelen cometer los mismos errores. No es una arquitectura perfecta, pero el enfoque descrito parece razonable.
    • Como comentario al margen, es una lástima que en el MAX conocieran ese enfoque y aun así no lo reutilizaran.

  • Recuerdo que en NATS también hubo otro problema con el mismo efecto. El sistema primario se cayó y conmutaron al secundario, pero el secundario se cayó exactamente por la misma razón.
    Parece que la conmutación por error solo debería hacerse cuando se sabe que el problema está en el sistema primario en sí y no en el software. La forma de simplemente conmutar solo refuerza la sensación de que no se expuso suficiente información como para decidir qué había que hacer realmente.
    Lo que resulta más inquietante es que no hubiera un método tipo “ValidateFlightPlan”, de modo que si por cualquier motivo no se podía parsear, lanzaba un error, y no existía una ruta para manejar ese error de manera muy simple. Me pregunto qué programador mira un manejador de entradas externas y no piensa: “¿qué hacemos si llega una entrada mala que rompe todo?”.

    • Si se sabe que el sistema primario no está en buen estado, se puede intentar conmutar esperando que haya sido algo como un disco quemado o un bit volteado por un rayo cósmico.
      La verdadera función de seguridad son las 4 horas de margen antes de que sea necesario el procesamiento manual.
      En aviación, el control de seguridad clave se parece menos a “cómo evitamos que esto falle desde el principio” y más a “qué hacemos si esto falla por cualquier motivo”.
    • Además de la falta de validación, esta parte del artículo me llamó la atención.
      El estilo de programación parece muy imperativo y, por la descripción, suena como si el procedimiento manipulara directamente la representación textual del plan de vuelo, no una estructura de datos parseada desde un archivo de texto. Si realmente es así, es bastante preocupante, aunque también podría deberse a la forma en que está explicado.
      Según esa descripción, no me sorprendería que simplemente aplicaran expresiones regulares o búsquedas de subcadenas sobre el texto, sin clases, objetos ni estructuras de datos. También hay que considerar la posibilidad de que sea código C de varias décadas, del que depende toda la aviación del Reino Unido y que no se puede reescribir ni reemplazar.
    • Como no hay forma de determinar que la causa no fue el hardware, la conmutación por error en sí fue correcta. Pero deberían haber diseñado mejor la respuesta ante la segunda falla para evitar efectos en cadena.
    • Desde el punto de vista eléctrico, fue como cambiar un fusible y quedarse mirando cómo vuelve a quemarse. En la tienda ya no quedan fusibles. ¿Eso es un avance?
    • El fallo del lanzamiento de Ariane 5[1] fue un problema parecido, y el resultado fue mucho más espectacular.
      El sistema primario falló por un desbordamiento de enteros, y el sistema secundario idéntico también se desbordó. Aumentó el ángulo de ataque, se separaron los propulsores y el cohete explotó.
      [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

  • No entiendo por qué solo pusieron los planes de vuelo fallidos en una cola de revisión humana y no pudieron seguir procesando el resto de los vuelos. Que no existiera esa “funcionalidad” es lo más difícil de entender.

    • El código clasificó ese error como “¡esto no debería ocurrir nunca!”, y efectivamente ocurrió. No lo clasificó como “datos de plan de vuelo incorrectos” ni como “los datos son correctos, pero aún no están soportados”.
      Cuando ocurre un error de “nunca debería ocurrir”, el sistema no puede saber qué está mal ni cuán grande y amplio es el impacto. Tal vez, como en este caso, se podía seguir adelante, pero también podía haber aparecido un nuevo bug crítico en el software que contaminara silenciosamente todos los demás planes de vuelo y matara gente. Si no sabes si es seguro continuar, tienes que detenerte.
    • Para ser justos, al principio del texto se dice que estos planes de vuelo a veces se procesan para aeronaves que ya están en vuelo. Aunque, al menos, estaban a más de 4 horas del Reino Unido.
      Si puedes impedir que despegue el avión específico con problemas, puede estar bien mantener el sistema funcionando, pero si ya está en el aire la cosa cambia.
      La decisión de “hay una aeronave en ruta que entrará al espacio aéreo británico, pero no sabemos cuándo ni por dónde; detenemos los planes de vuelo adicionales hasta saber dónde está esa aeronave” no es completamente irracional.
      Si realmente no se puede procesar el plan de vuelo, una solución razonable podría ser desviar esa aeronave y hacerla aterrizar antes de que llegue al Reino Unido, pero eso, al final, es algo que tiene que esperar intervención manual.
    • Tanto el texto como el análisis posterior señalaron el mal modo de falla del sistema FPRSA-R como el problema principal, y creo que esa es la parte más importante.
      Todos los sistemas pueden fallar, así que lo importante es que fallen de una buena manera y que los responsables estén preparados para esa situación.
      Un solo plan de vuelo causó un problema y todo el sistema FPRSA-R murió, por lo que no se procesó ningún plan de vuelo. Si un plan de vuelo tiene un problema, debería moverse a una cola separada y más lenta para que una persona lo procese manualmente. NATS también reconoció, dentro de las “medidas ya realizadas o en curso”, que agregará un filtro de mensajes en el flujo de datos entre IFPS y FPRSA-R para filtrar los planes de vuelo con esa condición.
    • En un sistema crítico para la seguridad, cuando te topas con un “error desconocido”, hay que asumir que todas las invariantes se rompieron y que entraste en comportamiento indefinido, así que no queda más que detenerse.
      Es válido decir que esto debería haberse manejado como un error conocido, pero visto en términos amplios, es parecido a decir “deberían haber escrito código sin bugs”. Incluso si se hubiera parseado en una estructura, podría ser como que de pronto aparece un KeyError en código que asumía que existía una clave opcional.
      El análisis posterior y las mejoras para algo así deben partir de la premisa de que algún día ocurrirá un error desconocido, no manejado e impredecible, y abordar cómo manejarlo mejor cuando pase. La solución a un bug es corregir el bug, pero la causa del incidente mayor fue un plan de recuperación ante desastres que no podía ejecutarse en un tiempo razonable. Sin importar qué prácticas de programación, estilo, lenguaje o herramientas se usen, un incidente de escala similar volverá a ocurrir algún día con probabilidad 1, incluso con los mejores desarrolladores.
    • Es muy probable que el algoritmo descrito en el texto no sea simple código procedural que recorre en orden los puntos de ruta del plan de vuelo de entrada. Alguna abstracción pudo haber ocultado el hecho de que esto era un error de entrada.
      Si desde el punto de vista del código parecía una falla de integridad en la base de datos subyacente de waypoints de navegación, entonces la decisión de detener el procesamiento de planes de vuelo se entiende mucho más.
      Por ejemplo, si el código le pregunta al repositorio de waypoints y rutas “encuéntrame el waypoint por el que esta ruta sale del espacio aéreo británico”, luego encuentra el tramo de ruta que contiene ese waypoint, y después afirma que ese tramo pasa por el espacio aéreo británico, pero esa aserción falla, eso puede parecer no un problema del plan de vuelo, sino que se rompió una suposición incorporada en los datos de rutas.
      En cierto sentido, podría ser realmente un bug crítico. Este incidente muestra que la suposición que el algoritmo hacía sobre los datos era incorrecta y que potencialmente podía devolver respuestas equivocadas.

  • Artículos relacionados
    El sistema de control aéreo británico fue engañado por nombres de waypoints que coincidían por casualidad - https://news.ycombinator.com/item?id=37430384 - septiembre de 2023, 64 comentarios
    Datos incorrectos de planes de vuelo causaron una falla en el control aéreo británico - https://news.ycombinator.com/item?id=37402766 - septiembre de 2023, 20 comentarios
    El informe del incidente de control aéreo de NATS detalla la causa raíz y la solución - https://news.ycombinator.com/item?id=37401864 - septiembre de 2023, 19 comentarios
    Falla en la red de control aéreo del Reino Unido - https://news.ycombinator.com/item?id=37292406 - agosto de 2023, 23 comentarios

    • Después de escuchar el episodio reciente de The Daily sobre la industria aérea estadounidense, quedé convencido de que pronto veremos titulares catastróficos. No se puede seguir así.
    • Al ver el título de este artículo pensé que era una falla nueva que acababa de ocurrir.

  • El hecho de que culparan a un plan de vuelo francés que Eurocontrol ya había aceptado demuestra que no entendían bien cómo funcionaba el software. Y la empresa austriaca también debe asumir parte de la responsabilidad por la falta de pruebas exhaustivas.

    • Solo culparon a Francia porque son británicos. Los malos hábitos son difíciles de abandonar.

  • Excelente artículo. Al leerlo, diría que el punto central es este:
    Los nombres de los waypoints usados en todo el mundo no son únicos y, como una especie de parche para evitar confusiones, el estándar más reciente dice que los mismos identificadores deben estar separados geográficamente por suficiente distancia. Aun así, en una misma ruta aérea, el mismo nombre de waypoint puede referirse a ubicaciones distintas.
    El software no contempló esa posibilidad, falló el cálculo de la ruta, lanzó una “excepción fatal” y entró en “modo de mantenimiento”. Es decir, murió.
    El sistema de respaldo tomó el control, pero con los mismos datos se topó con el mismo bug y también murió, y el personal de soporte la pasó mal. Al final, solo después de contactar al proveedor del software encontraron logs de bajo nivel que revelaban la causa.

    • No entiendo por qué en un sistema crítico para la misión de este nivel no hay alguien familiarizado con el código en guardia 24/7.
    • El punto clave es que no había un espacio de nombres adecuado. Quién iba a decir que los ingenieros aeroespaciales tenían que estudiar sistemas operativos.
      Un amigo mío, piloto retirado de la fuerza aérea, se graduó de Cranfield University, una de las principales instituciones de posgrado en ingeniería aeroespacial del Reino Unido, que incluso tiene su propio aeropuerto para docencia e investigación[1]. Ese amigo me dijo que en Cranfield había estudiado sistemas operativos, y recién ahora entiendo por qué.
      Por otros comentarios, parece que el estándar de espacios de nombres ya existe, pero que NATS/ATC no lo usa. Ojalá este incidente haga que por fin empiecen a usarlo. El comentario principal hablaba de un bug de geofencing, pero si NATS/ATC hubiera estado usando el espacio de nombres correcto, probablemente el geofencing ni siquiera habría sido necesario desde el principio.
      [1] Cranfield University:
      https://en.wikipedia.org/wiki/Cranfield_University

  • “Por la explicación, suena como si el procedimiento no trabajara con una estructura de datos parseada desde un archivo de texto, sino directamente con la representación textual del plan de vuelo. Si realmente es así, es bastante preocupante, aunque quizá sea solo por la forma en que está explicado”.
    En trabajos de la industria aeronáutica, este enfoque es común. Si le preguntas a un programador por modelos de dominio o parsing, suele quedarse con la mirada perdida. Les gusta el código de validación y, si algo no valida, les gusta simplemente rendirse. Todo son pipelines de datos tontos, sin ningún código que modele las actividades que ocurren en el mundo real.
    En ningún sistema existe algo como un tipo “plan de vuelo” con comportamiento, ni un conjunto de tipos de waypoints. Incluso cuando hay tipos, son estructuras de strings al estilo C, y cada vez que se accede a un miembro de esa estructura se parsea, no una vez, sino todas las veces. Como dice el artículo, “el estilo de programación parece muy imperativo”.

    • Rendirse ante una falla de validación es, de hecho, una práctica estándar para evitar propagar datos mal interpretados y generar bugs mucho más complejos. Hay que validar temprano, validar de forma estricta, reportar el error y no intentar interpretar a la fuerza qué parte de la entrada está rara. En cuanto intentas ser “inteligente”, abres un agujero de seguridad.
      Morir ante una entrada incorrecta está mal, pero intentar interpretar datos no validados sin especificación suele traer desacuerdos de interpretación posteriores, problemas de compatibilidad y condiciones de borde inesperadas. Nadie quiere pagar por un sistema que cubra todos los casos completamente probados, herramientas de simulación de entradas incorrectas y verificación formal del parser y de todo el código que usa sus resultados.
      Ya hay muchos problemas por transmisores de datos no conformes, legados o con bugs, y por la semántica de las interfaces y la complejidad de los timings. Intentar responder de forma inteligente a datos con formato o codificación incorrectos lo vuelve más peligroso.
      Construir un sistema que funcione según la especificación ya es difícil y caro. Una variante sutil que acepte con más tolerancia comportamientos no especificados es pedir bugs, o bien construir un sistema más caro que no supera el criterio de precio de compra.
    • Muy interesante y también un poco aterrador. Es curioso cómo distintas industrias han desarrollado culturas de desarrollo diferentes por razones que no son especialmente claras.

  • “Control aéreo del Reino Unido: investigan si un error francés causó la falla”.
    Claro que no. Es un sistema británico; ¿cómo va a ser culpa de una aerolínea francesa? Un sistema así debería tener una arquitectura a prueba de errores con redundancia.
    Si un elemento estaba mal, quizá habría bastado con rechazarlo y seguir adelante.

    • Si vamos a ponernos nacionalistas, el software era austríaco.

  • Fue un día que preferiría no recordar. Llegar a un destino que normalmente toma 2 horas me tomó 15 horas.
    Tomé tren, autobús y luego tren otra vez, y 30 minutos después de reservar el boleto ya se habían agotado todos los pasajes para dos días.

    • Esperé 6 horas en el aeropuerto antes de enterarme de que el vuelo había sido cancelado, y tuve que volver a reservar. Iba a New York a ver a mi familia, así que tampoco había muchas alternativas de transporte.