Ideas erróneas sobre la aviación que los programadores suelen creer
(flightaware.engineering)- Los datos de aviación tienen muchas características complejas y no estandarizadas
- Los desarrolladores suelen hacer suposiciones equivocadas sobre vuelos, aeropuertos, navegación e información de transpondedores
- Los sistemas reales de seguimiento de vuelos deben responder con flexibilidad a diversas situaciones excepcionales y anomalías en los datos
- Muchos malentendidos provocan errores inesperados en el software o en los sistemas de los clientes
- Al diseñar datos, se necesita una perspectiva que refleje de cerca la complejidad del mundo real
Resumen
FlightAware es una empresa que desarrolla software para procesar y distribuir datos de aviación de todo el mundo. Sin embargo, los datos reales de aviación, a diferencia de lo que sugiere la intuición, no son estructurados y están llenos de excepciones y anomalías. Muchos desarrolladores asumen diversas premisas sobre la estructura de los datos, los flujos y los sistemas de identificación, pero en la práctica estas suposiciones resultan erróneas y causan errores e inconsistencias en los sistemas. Este artículo, como continuación de la serie sobre ideas erróneas, organiza los malentendidos que se cometen con frecuencia en el software de la industria aeronáutica y los casos que generan.
Flights (información de vuelos)
- Existe la idea equivocada de que los vuelos siempre salen desde una puerta, pero en realidad pueden cambiar de puerta varias veces o salir mucho más tarde o más temprano de lo previsto
- Es fácil pensar que el itinerario de un vuelo o los aeropuertos de salida y llegada son claros, pero existen casos como helicópteros o aeronaves militares que despegan y aterrizan en lugares que no son aeropuertos
- Puede parecer que la duración o el horario de los vuelos siguen patrones regulares, pero también son frecuentes los vuelos de larga duración que se extienden por varios días y las operaciones irregulares
- Es común asumir que el número identificador de un vuelo (por ejemplo, UAL1234) es único, pero en la práctica a una misma aeronave se le pueden asignar varios identificadores o números, y el mismo número puede usarse en distintas situaciones
- Incluso cuando el número parece el mismo en la notación, pueden mezclarse identificadores de vuelo, matrículas y otras marcas, lo que genera confusión, y la información de identificación usada en boletos, control de tráfico aéreo y por los pilotos puede ser distinta
Airports (información de aeropuertos)
- Puede pensarse que la ubicación de los aeropuertos y sus códigos de identificación son fijos, pero en la realidad los aeropuertos pueden cerrarse, trasladarse o fusionarse, por lo que su ubicación o código cambia
- Los sistemas de nombres para terminales, puertas y pistas tampoco son consistentes y tienen muchas reglas excepcionales
- Incluso en los sistemas de códigos ICAO/IATA existen muchos casos que no coinciden con lo que se esperaría en la práctica, como duplicaciones, asignación de múltiples códigos y malentendidos sobre códigos de ubicación
- Tener cierta información de identificación (por ejemplo, un código IATA) no garantiza necesariamente que se trate de un aeropuerto real; también hay casos de códigos IATA asignados a estaciones de tren o terminales de autobús
- Incluso hay códigos ICAO asignados a lugares que no están en la Tierra (por ejemplo, cráteres extraterrestres)
Airlines (información de aerolíneas)
- Se omite porque no se mencionan ideas erróneas concretas en una línea separada
Navigation (información de navegación y rutas)
- Existe la idea equivocada de que los nombres de los waypoints son únicos, pero en realidad hay duplicados
- La definición de altitud usada en aviación no está unificada en un solo criterio y puede interpretarse de manera distinta según la referencia
- Puede pensarse que los datos del control de tráfico aéreo son perfectamente precisos, pero en realidad los errores o cambios ocurren con frecuencia
- La cancelación de planes de vuelo, los cambios de plan y otros ajustes pueden no reflejarse en el vuelo real, y un mismo vuelo puede cambiar de destino varias veces
- También existen inconsistencias de datos entre radares y organismos de control aéreo, así como discrepancias de ubicación durante observaciones simultáneas
Transponders and ADS-B (información sobre transpondedores y ADS-B)
- Se suele asumir que la señal ADS-B solo la transmiten los aviones, pero también puede ser emitida por vehículos aeroportuarios u otros dispositivos
- También es un error confiar en exceso en la precisión de las coordenadas GPS o en la confiabilidad de la señal
- Por errores, duplicaciones, falta de mantenimiento o problemas de formato en la información registrada del transpondedor (números de identificación, direcciones Mode S, etc.), son frecuentes las inconsistencias entre los datos en tiempo real y la información real
- Es fácil pensar que la información ADS-B se recibe y almacena tal cual, pero pueden surgir diversos problemas, como errores de transmisión o falsificación de señales
- Las fallas de equipos, la mala gestión y factores externos (por ejemplo, cables dañados por ratones) también son variables reales
Cierre
Esta lista muestra la complejidad de la confiabilidad de los datos de aviación, construida a partir de la experiencia y los conocimientos obtenidos por FlightAware y el equipo de desarrollo de Hyperfeed a lo largo de muchos casos reales durante años. Subraya la importancia del modelado y la operación de datos considerando a fondo las excepciones que existen en la realidad, para reducir distintos errores y malentendidos.
4 comentarios
Por eso la estandarización de datos es... importante.. jaja
El texto realmente es muy conciso, pero la emoción implícita...;;
Con solo leerlo ya me sube la presión jajaja
Comentarios de Hacker News
Explicación de por qué los aviones no tienen un único identificador inmutable a lo largo del tiempo. Se comparte la experiencia real de que a cada aeronave se le asigna un número de serie, pero eso por sí solo no garantiza unicidad. La combinación de “fabricante, modelo, número de serie” es lo más cercano a un identificador único durante toda su vida útil, pero incluso eso puede cambiar si la aeronave modifica su tipo por cambios estructurales. También se añade la impresión personal de que resulta sorprendente que en un sistema tan grande y complejo como la aviación no exista un identificador inmutable. La matrícula de la aeronave (tail number) cambia como la placa de un auto, y el identificador ICAO de 24 bits está vinculado al equipo ADS-B, por lo que puede moverse o cambiarse libremente
Se expresa curiosidad por el hecho de que la combinación “fabricante, modelo, número de serie” haya sido objeto de patente. Se plantea la duda de cómo algo así pudo considerarse novedoso al punto de volverse patentable
Se conecta esta historia con la paradoja del “barco de Teseo”, como una asociación filosófica sobre la identidad de una aeronave y los cambios en sus identificadores enlace de Wikipedia sobre Ship of Theseus
Se comparte el trasfondo histórico de que la industria aeronáutica se desarrolló por países de forma aislada, como silos, y por eso la estandarización tardó en llegar. Se plantea la visión de que ya es sorprendente que hayan logrado consolidarse estándares globales. También se analiza que hoy eso apenas es posible porque los grandes fabricantes se han consolidado en unos pocos actores
Se comparte experiencia de campo sobre cómo los identificadores “verdaderamente” únicos aparecen como problema importante con frecuencia en entornos reales. La solución casi siempre es la combinación de “modelo, fabricante, número de serie”, y si hace falta también se agrega el año de producción. Incluso se menciona un caso de intento de deduplicación de datos humanos usando criterios como el idioma o lengua materna
Se comparte como ejemplo que incluso los números de pista cambian con el tiempo, con un artículo de Wikipedia enlace de Wikipedia sobre Runway
Opinión de que estas listas siempre serían mucho más útiles si incluyeran explicaciones más detalladas. Aun así, entre las fuentes enlazadas hay varias cosas interesantes, por ejemplo el caso de un código ICAO de aeropuerto asignado a un cráter en Marte (JZRO) enlace de Wikipedia sobre el cráter Jezero, ejemplo de un vuelo que sale normal pero termina aterrizando con 40 horas de retraso
Se cuestiona cómo una combinación tan obvia como fabricante-modelo-número de serie pudo patentarse y si actualmente alguien está obteniendo beneficios de esa patente
Desde la experiencia de desarrollar software de análisis de datos de vuelo, se comparten las dificultades reales de un desarrollador que pasa la mayor parte del tiempo entre “todo tipo de mentiras sobre aviación”, porque helicópteros y aviones despegan y aterrizan en toda clase de lugares: hospitales, azoteas, estacionamientos, canchas deportivas, aeropuertos, campos de golf, etc.
Se plantea que cada vez que aparece un artículo de la serie “Falsehoods...”, resulta interesante ver cómo muchos desarrolladores caen en la ilusión de que los sistemas centrados en humanos obedecerán reglas estrictas
Se reconoce que a los desarrolladores les gusta reducirlo todo a sistemas de reglas estrictas, pero el mundo real no funciona así
Se analiza que la profesión de programar consiste precisamente en actuar como interfaz entre sistemas humanos flexibles y máquinas basadas en reglas estrictas
Se comparte el dilema y la confusión que enfrenta un programador al modelar el mundo en software, asumiendo como obvias ciertas premisas que en la práctica no se cumplen en absoluto. Por ejemplo, asumir que un vuelo necesariamente tiene aeropuerto de salida y de llegada
Se sostiene que, por la propia naturaleza del software, el modelado del dominio necesariamente debe convertirse en un conjunto de reglas, porque sin reglas no se puede ofrecer ninguna funcionalidad. Dado que al explicarle a una persona común excepciones como el
leap secondpodría pensar que estás diciendo tonterías, se argumenta que en realidad los desarrolladores suelen ser muy conscientes de las excepciones y la complejidad del mundoSe propone tratar cada punto de la serie “Falsehoods Programmers Believe...” como un caso de prueba. Eso puede extenderse a pruebas unitarias o de integración para validar las suposiciones erróneas que el programa tenga incorporadas
Se menciona que la premisa “los vuelos despegan/aterrizan en aeropuertos” estaba codificada sin excepción en antiguos sistemas aeronáuticos de Brasil, y se comenta un caso en que eso se resolvió con un parche temporal. También se critica que se asume demasiado a menudo que “los aeropuertos/pistas no cambian de ubicación ni orientación”. Incluso se propone que habría que añadir la premisa “las aeronaves solo aterrizan en pistas o helipuertos” a la lista
Se comparte un video de CGP Grey que resume muy bien lo caótico del proceso de los códigos aeroportuarios y las particularidades del sistema enlace de YouTube
También se presenta una discusión relacionada en el foro de FlightAware sobre el mismo tema enlace al foro de FlightAware
Desde la perspectiva de un programador, se comparte la sensación de que al principio todas las premisas de esta lista parecían razonables, pero que luego llega un doloroso despertar a la realidad que te hace sentir que te explota la cabeza. Se elogia el texto como un excelente resumen