Ideias erradas sobre aviação em que programadores acreditam

• Os dados de aviação têm muitas características complexas e não padronizadas
• Desenvolvedores frequentemente fazem suposições erradas sobre voos, aeroportos, navegação e informações de transponder
• Um sistema real de rastreamento de voos precisa responder com flexibilidade a várias situações excepcionais e anomalias de dados
• Muitos mal-entendidos causam erros inesperados em softwares ou sistemas de clientes
• Ao projetar dados, é necessário adotar uma perspectiva que reflita cuidadosamente a complexidade do mundo real

---

Visão geral

A FlightAware é uma empresa que desenvolve software para processar e distribuir dados de aviação no mundo todo. No entanto, ao contrário do que a intuição sugere, os dados reais de aviação não são estruturados de forma rígida e contêm muitas exceções e irregularidades. Muitos desenvolvedores partem de várias premissas sobre estrutura de dados, fluxo e sistemas de identificação, mas na prática isso se transforma em suposições incorretas que causam erros e inconsistências. Este texto, como continuação da série sobre ideias erradas, organiza os equívocos frequentemente cometidos em softwares da indústria da aviação e os casos que surgem por causa deles.

Flights (informações de voo)

• Existe a ideia errada de que um voo sempre parte do portão, mas na prática ele pode mudar de portão várias vezes ou partir muito mais cedo ou mais tarde do que o previsto
• É fácil supor que o horário do voo ou os aeroportos de partida e chegada sejam claros, mas há casos em que helicópteros e aeronaves militares decolam e pousam em locais que não são aeroportos
• O tempo de voo ou a programação podem parecer regulares, mas voos longos que se estendem por vários dias e operações irregulares também são frequentes
• É comum assumir que o número identificador do voo (ex.: UAL1234) seja único, mas na realidade uma mesma aeronave pode receber vários identificadores ou números, e o mesmo número pode ser usado em diferentes situações
• Mesmo quando o número parece o mesmo na escrita, identificadores de voo, matrícula e outros marcadores podem se misturar e causar confusão, e as informações de identificação usadas por bilhete, controle de tráfego aéreo e piloto podem ser diferentes

Airports (informações de aeroporto)

• Pode parecer que a localização do aeroporto e os códigos de identificação são fixos, mas na prática aeroportos podem ser fechados, transferidos ou incorporados, fazendo com que localização ou código mudem
• Os sistemas de nomenclatura de terminais/portões, pistas e outros elementos também não são consistentes e têm muitas regras excepcionais
• Mesmo nos sistemas de códigos ICAO/IATA, há muitos casos que não correspondem à expectativa, como duplicações, atribuição de múltiplos códigos e mal-entendidos sobre códigos de localização
• Ter alguma informação de identificação (por exemplo, um código IATA) não garante necessariamente que se trate de um aeroporto real; há casos em que códigos IATA foram atribuídos a estações ferroviárias e terminais rodoviários
• Alguns códigos ICAO chegam a ser atribuídos a lugares fora da Terra (por exemplo, crateras extraterrestres)

Airlines (informações de companhias aéreas)

• Como não foram mencionadas ideias erradas específicas em uma linha separada, esta parte foi omitida

Navigation (navegação e rotas)

• Há a ideia errada de que nomes de waypoints sejam únicos, mas na realidade existem duplicações
• A definição de altitude usada na aviação não é unificada em um único padrão e pode ser interpretada de maneiras diferentes conforme o critério adotado
• Pode-se achar que os dados de controle de tráfego aéreo são perfeitamente precisos, mas na prática erros ou mudanças acontecem com frequência
• Cancelamentos de planos de voo e alterações de plano podem não se refletir no voo real, e um mesmo voo pode mudar de destino várias vezes
• Também existem inconsistências entre radar e dados de diferentes órgãos de controle de tráfego aéreo, além de divergências de posição em observações simultâneas

Transponders and ADS-B (informações sobre transponder e ADS-B)

• Assume-se que o sinal ADS-B seja transmitido apenas por aviões, mas ele também pode ser emitido por veículos de aeroporto e outros dispositivos
• A confiança excessiva na precisão das coordenadas de GPS e na confiabilidade do sinal também é um equívoco
• Erros e duplicações em informações de registro de transponder (número identificador, endereço Mode S etc.), falhas de manutenção e erros de formato fazem com que inconsistências entre dados em tempo real e informações reais sejam frequentes
• É fácil pensar que as informações de ADS-B são simplesmente recebidas/armazenadas como estão, mas vários problemas podem ocorrer, como erros de transmissão e falsificação de sinal
• Falhas de equipamento, descuido na administração e fatores externos (por exemplo, cabos roídos por ratos) também são variáveis reais

Encerramento

Esta lista mostra a complexidade da confiabilidade dos dados de aviação com base na experiência e nos insights acumulados ao longo de muitos anos pela FlightAware e pela equipe de desenvolvimento do Hyperfeed em inúmeros casos reais. O texto enfatiza a importância de modelagem e operação de dados que considerem minuciosamente as exceções que de fato existem, para reduzir diversos erros e mal-entendidos.

[ifmkl]

É por isso que a padronização dos dados é... importante.. haha

[ryj0902]

O texto é realmente bem conciso, mas a emoção implícita...;;

[aliveornot]

Só de ler já dá até pressão alta kkk

[GN⁺]

Opiniões no Hacker News

• Explicação de que aeronaves não têm um único identificador imutável ao longo do tempo. Cada aeronave recebe um número de série, mas, na prática, isso por si só não garante unicidade. Relato de experiência real de que a combinação “fabricante, modelo e número de série” é o que mais se aproxima de um identificador único durante toda a vida útil, embora até isso possa mudar se a aeronave tiver alterações estruturais que mudem seu tipo. Comentário pessoal de que é surpreendente que um sistema tão grande e complexo quanto a aviação não tenha um identificador imutável. Também explica que o número de registro da aeronave (prefixo de cauda) muda como a placa de um carro, e que o identificador ICAO de 24 bits está vinculado ao equipamento ADS-B, podendo ser transferido ou alterado livremente

  • Expressa curiosidade pelo fato de a combinação “fabricante, modelo e número de série” ter sido objeto de patente. Questiona como algo assim pôde ser considerado novo o bastante para virar patente

  • Liga essa história ao paradoxo do 'Navio de Teseu', apresentando uma associação filosófica sobre a identidade da aeronave e a mudança de identificadores link da Wikipédia sobre Ship of Theseus

  • Compartilha o contexto histórico de que a indústria da aviação evoluiu em silos separados por país, o que atrasou a padronização. Defende a visão de que é surpreendente que padrões globais tenham realmente se consolidado. Analisa que isso só é possível hoje porque os grandes fabricantes se consolidaram em um grupo pequeno

  • Compartilha experiência prática de que o problema de um identificador único “verdadeiro” aparece com frequência no mundo real. A solução quase sempre é a combinação “modelo, fabricante e número de série”, acrescentando o ano de produção se necessário. Menciona até um caso em que se tentou fazer deduplicação de dados humanos com base em critérios como idioma (língua materna)

  • Compartilha um exemplo de que até números de pista mudam com o tempo, com referência ao artigo da Wikipédia Runway na Wikipédia

• Opinião de que essas listas sempre seriam muito mais úteis se viessem acompanhadas de explicações mais detalhadas. Ainda assim, há muito material útil nas fontes citadas, como o caso de uma cratera em Marte ter recebido um código de aeroporto ICAO (JZRO) artigo da Wikipédia sobre a cratera Jezero, exemplo de voo que decolou normalmente, mas pousou com 40 horas de atraso

  • Aponta que os casos da lista muitas vezes têm motivos banais. Por exemplo, o voo de duas semanas era um Google Balloon, o atraso de 40 horas foi simplesmente mau tempo, e o valor ADS-B é inserido pelo piloto, que às vezes comete erros

• Questiona como a combinação fabricante-modelo-número de série, que parece tão óbvia, pôde virar patente, e se alguém hoje ainda lucra com essa patente

• Relato de experiência desenvolvendo software de análise de dados de voo: helicópteros e aviões decolam e pousam em todo tipo de lugar — hospitais, telhados, estacionamentos, campos esportivos, aeroportos, campos de golfe etc. — e por isso o desenvolvedor passa a maior parte do tempo cercado por “todo tipo de mentira sobre aviação”

• Visão de que, sempre que lê a série "Falsehoods...", acha interessante como muitos desenvolvedores caem na ilusão de que sistemas centrados em humanos seguem apenas regras rígidas

  • Reconhece que desenvolvedores gostam de reduzir tudo a sistemas estritos de regras, mas o mundo real não funciona assim

  • Analisa que a própria profissão de programador tem como essência servir de interface entre sistemas humanos flexíveis e máquinas baseadas em regras rígidas

  • Compartilha o dilema e a confusão de modelar o mundo em software a partir de pressupostos que parecem óbvios para programadores, mas que na prática não se sustentam. Por exemplo, assumir que todo voo necessariamente tem aeroporto de origem e de destino, quando a realidade pode ser diferente

  • Defende que, pela própria natureza do software, a modelagem de domínio precisa necessariamente virar um conjunto de regras, porque sem isso não é possível oferecer nenhuma funcionalidade. Argumenta que, se você explicar exceções como leap second para o público geral, é fácil acharem que é bobagem; por isso, muitas vezes os desenvolvedores acabam sendo justamente os que mais percebem as exceções e a complexidade do mundo

• Sugere tratar cada item da série "Falsehoods Programmers Believe..." como caso de teste. Isso pode ser expandido para testes unitários e de integração que validem pressupostos errados embutidos no programa

  • Relato de que, na prática, foram criados testes para cada item, e que no trabalho havia mais de mil testes cobrindo desde situações cotidianas até casos extremos. Lembra que era um time que valorizava muito qualidade e engenharia

• Menciona que o pressuposto “voos decolam e pousam em aeroportos” já existiu de forma obrigatória em sistemas antigos da aviação no Brasil, e cita um caso em que isso foi resolvido de forma improvisada. Também critica o pressuposto de que “aeroportos/pistas não mudam de localização ou direção”, por ser errado com frequência demais. Sugere acrescentar ainda a premissa de que “aeronaves só pousam em pistas ou heliportos”

  • Pergunta se alguém pode explicar com mais detalhes como os sistemas antigos da aviação no Brasil faziam esse tratamento improvisado

• Compartilha um vídeo do CGP Grey que resume bem o caos dos códigos de aeroporto link no YouTube. O vídeo também explica as peculiaridades do sistema

• Apresenta também uma discussão relacionada no fórum do FlightAware sobre o mesmo tema link do fórum do FlightAware

• Compartilha a sensação, como programador, de ter considerado razoáveis todos os pressupostos dessa lista e depois descobrir a realidade de forma dolorosa, como se a cabeça explodisse. Elogia o texto como um ótimo resumo