O colapso do sistema de controle de tráfego aéreo do Reino Unido

• Em 28 de agosto de 2023, uma falha no FPRSA-R da operadora de controle de tráfego aéreo do Reino Unido, a NATS, causou o cancelamento de mais de 2.000 voos, com custos estimados em mais de 100 milhões de libras
• O plano de voo que desencadeou a confusão era um plano válido aceito pelo Eurocontrol IFPS, e o sistema da NATS tentou combinar dados ADEXP com a rota ICAO4444 para extrair o trecho em espaço aéreo britânico
• A causa direta foi que dois waypoints geograficamente diferentes tinham o mesmo identificador; o FPRSA-R associou por engano esse identificador duplicado como ponto de saída e não conseguiu criar um trecho britânico válido
• O sistema principal e o sistema de backup processaram o mesmo plano de voo com a mesma lógica, cada um gerando uma critical exception e entrando em maintenance mode em 20 segundos, interrompendo o processamento automático
• As aeronaves continuaram sendo controladas com segurança, mas permaneceram como problemas o modo de falha em que um único plano de voo conseguiu parar todo o sistema automático, a falta de testes e o procedimento de recuperação dependente de logs de baixo nível

---

Escala da falha da NATS em 28 de agosto de 2023

• A NATS, operadora de controle de tráfego aéreo do Reino Unido, sofreu uma falha técnica grave em 28 de agosto de 2023
• Segundo a BBC, mais de 2.000 voos foram cancelados, e o custo é estimado em mais de 100 milhões de libras
• A falha pode ter afetado centenas de milhares de pessoas
• Relatos iniciais da imprensa levantaram a possibilidade de um “plano de voo incorreto” ou de “erro de uma companhia aérea francesa”, mas o plano de voo que causou o problema era um plano em conformidade com a ICAO4444 aceito pelo Eurocontrol IFPS
• Depois, o voo que realmente desencadeou a falha foi identificado como o French Bee FBU731, que ia de LAX/KLAX para ORY/LFPO

Como o plano de voo chega à NATS

• A companhia aérea envia o plano de voo ao IFPS do Eurocontrol
  • Se o IFPS aceitar o plano de voo, a aeronave pode decolar após a aprovação do controle de tráfego aéreo do aeroporto de partida
  • Nessa etapa, não é necessária nenhuma entrada da NATS
• O IFPS encaminha o plano de voo aos provedores de serviços de navegação aérea relevantes
  • A NATS precisa receber o plano de voo pelo menos 4 horas antes de a aeronave entrar no espaço aéreo britânico
  • Essas 4 horas funcionam como margem para resolver problemas de processamento
• Nas operações En-route da NATS no Swanwick Centre, os dados são enviados ao FPRSA-R
  • O FPRSA-R converte os dados em formato ADEXP recebidos do IFPS para um formato compatível com o UK National Airspace System, ou NAS
  • O NAS é um sistema de processamento de dados de voo que inclui informações relevantes de rotas e espaço aéreo

Diferenças entre ICAO4444 e ADEXP

• O plano de voo ICAO4444 é um formato legível por máquina e, se necessário, também por humanos
  • A parte da rota inclui velocidade, altitude, waypoints, nomes de rotas e indicações de voo direto como DCT
  • Por exemplo, N0440 significa 440 nós e F310 significa Flight Level 310
• O IFPS converte o plano de voo ICAO4444 para o formato ADEXP antes de encaminhá-lo
  • O ADEXP inclui o plano de voo ICAO4444 original junto com waypoints geográficos adicionais para a rota na região europeia
  • Voos que não pousam no Reino Unido, mas cruzam o espaço aéreo britânico, também podem incluir waypoints necessários para a parte da viagem após saírem do Reino Unido
• Em RTEPTS do ADEXP, a altitude e o horário estimado de passagem de cada waypoint aparecem com mais detalhes
  • A rota ICAO pode ter 9 waypoints, mas a lista expandida do ADEXP pode conter 21 waypoints
  • Como origem e destino da rota ICAO ficam em campos separados, eles não reaparecem na lista de rota

O waypoint duplicado que causou a falha

• A lista de waypoints ADEXP problemática continha dois waypoints geograficamente diferentes com o mesmo designator
  • A ICAO e outras organizações vêm trabalhando para eliminar nomes de waypoints não únicos, mas ainda existem nomes duplicados no mundo todo
  • O padrão mais recente determina que waypoints com o mesmo identificador devem estar geograficamente bem distantes entre si
  • Os dois waypoints deste incidente estavam ambos fora do Reino Unido, um no começo da rota e outro no fim, separados por cerca de 4.000 milhas náuticas
• No plano de voo expandido do voo identificado, o FBU731, o waypoint DVL aparece duas vezes
  • Um corresponde a Devil’s Lake, em Wisconsin, nos Estados Unidos
  • O outro corresponde a Deauville, na Normandia, França
  • O segundo apareceu na parte final do voo durante a expansão da aerovia UN859

Como o FPRSA-R processa e onde falhou

• O FPRSA-R procura desde o início dos dados de waypoints ADEXP o ponto de entrada no espaço aéreo britânico
• Em seguida, busca o ponto de saída do espaço aéreo britânico e então tenta localizar o trecho correspondente na seção ICAO4444
• A rota ICAO não precisa necessariamente incluir o ponto de saída do espaço aéreo
  • O software foi projetado para, se o ponto de saída não existir na rota ICAO, procurar novamente usando o ponto seguinte mais próximo no arquivo ADEXP
• Neste incidente, o software seguiu os waypoints seguintes do ADEXP até encontrar um identificador duplicado que existia na rota ICAO
  • Mas esse identificador não era o waypoint real após a saída do espaço aéreo britânico, e sim outro waypoint geográfico no início da rota
  • Como resultado, a ordem entre os pontos de entrada e saída, ou o trecho correspondente, tornou-se inválida, e não foi possível extrair o trecho ICAO referente ao espaço aéreo britânico
• O relatório da NATS apontou esse ponto como a root cause do incidente e concluiu que contribuições relacionadas a ciberataque podiam ser descartadas

Por que o sistema principal e o de backup pararam ao mesmo tempo

• Softwares críticos para a segurança são projetados para entrar em um estado que exige intervenção manual quando não conseguem continuar de forma segura
• O sistema principal do FPRSA-R concluiu que não podia garantir a correção dos dados do plano de voo e gerou uma critical exception
  • Registrou o arquivo de log no log do sistema
  • Entrou em maintenance mode
  • O sistema C&M detectou que o sistema principal não estava mais disponível
• O sistema de backup foi projetado para assumir o processamento em caso de falha do sistema principal
  • Ele fica em hardware separado, com alimentação elétrica separada e feed de dados separado
  • Mas aplicou a mesma lógica ao mesmo plano de voo e gerou a mesma critical exception
• Do recebimento da mensagem ADEXP até o momento em que os sistemas principal e de backup entraram em maintenance mode, passaram-se menos de 20 segundos
• Às 08:32, o processamento automático de planos de voo foi interrompido, e depois disso passou a ser necessária a entrada manual de planos de voo dentro da margem de 4 horas

Procedimento de recuperação e impacto operacional

• A equipe de suporte de 1ª linha detectou a falha por meio do sistema C&M dedicado, do sistema C&M central e do feedback da equipe operacional
• A resposta inicial foi o procedimento padrão de recuperação: reiniciar os subsistemas a partir do sistema C&M central
  • Várias tentativas de recuperação falharam
  • A equipe de engenharia de 2ª linha foi acionada para apoiar o engenheiro em campo por meio de um link remoto de vídeo
• Como a 1ª e a 2ª linhas não conseguiram restaurar o serviço nem identificar com precisão a causa, foram acionados a equipe de Technical Design e o suporte do fabricante do subsistema
• O fabricante identificou, por meio da análise de logs de software de baixo nível, o plano de voo que aparentemente causou a falha
  • Depois de entender esse plano de voo, forneceu o procedimento exato para restaurar o sistema de forma controlada e segura
• Havia procedimentos de entrada manual e de coordenação manual entre setores para falhas, mas a mudança para procedimentos manuais exigia aplicar restrições de controle de tráfego aéreo para reduzir o fluxo de tráfego no Reino Unido

Frequentis AG e o FPRSA-R

• O subsistema FPRSA existe há vários anos na NATS, e em 2018 o sistema anterior foi substituído por novo hardware e software da Frequentis AG
• A Frequentis AG é uma empresa austríaca e uma das fornecedoras de sistemas de controle de tráfego aéreo
• Os produtos de ATC desse fabricante operam em cerca de 150 países e são conhecidos por ter posição global em gestão de informação aeronáutica e sistemas de processamento de mensagens
• Na página de recrutamento da Frequentis AG, aparecem Ada, C++, Java e Python em relação a sistemas de controle de tráfego aéreo, sendo Java o mais frequente

Bug de software e problemas de teste

• O FPRSA-R não conseguiu extrair, de um plano de voo válido aceito pelo IFPS, o trecho ICAO correspondente ao espaço aéreo britânico
• Identificadores de waypoints não são globalmente únicos, e isso é um problema conhecido
  • Se os waypoints duplicados estiverem muito distantes, um plano de voo normal ainda pode não ser ambíguo
  • Mas o software deveria tratar essa condição de forma robusta
• A NATS afirmou que pode considerar, por meio do governo britânico, a remoção de um pequeno número de nomes duplicados de waypoints no conjunto global de dados administrado pela ICAO e relacionado a este incidente
• O CEO da NATS, Martin Rolfe, disse à BBC que a probabilidade desse incidente era de “1 em 15 milhões”
  • Ele afirmou que o sistema foi introduzido em 2018 e que processou 15 milhões de planos de voo desde então
• Em um sistema crítico para a segurança, a etapa de processamento do plano de voo, especialmente uma etapa importante como a extração do trecho britânico, deveria ser testada
  • Testes que não considerassem nomes duplicados de waypoints podem não ter revelado esse bug
  • Fuzzing com grande volume de planos de voo aleatórios poderia ter ajudado a encontrar entradas que levassem o sistema a um modo de falha ruim

O problema do modo de falha

• Um único plano de voo parou todo o sistema de processamento automático do FPRSA-R, e com isso nenhum plano de voo pôde mais ser processado automaticamente
• Um modo de falha melhor seria enviar o plano de voo problemático para uma fila separada e mais lenta, para tratamento manual por uma pessoa
• A NATS afirmou que, como medida já em andamento ou concluída, adicionará filtros específicos de mensagem ao fluxo de dados entre o IFPS e o FPRSA-R para bloquear planos de voo que correspondam às condições que causaram o incidente
• Quando o FPRSA-R parou, o plano de voo relacionado só foi identificado nos logs de software de baixo nível
  • Se um erro no processamento de um plano de voo específico parar todo o sistema, seria mais apropriado que um alerta contendo esse plano de voo fosse enviado imediatamente à equipe de monitoramento
• A NATS afirmou que estabeleceu orientações operacionais para recuperar rapidamente o FPRSA-R caso a mesma situação volte a ocorrer, e que os operadores técnicos foram treinados para executar os novos procedimentos
  • Monitoramento reforçado e pessoal extra de engenharia também devem supervisionar as operações

Possibilidade de verificação formal

• Não há sinais claros de que verificação formal tenha sido usada nesta etapa e neste sistema do incidente, e isso também não é mencionado no relatório
• Verificação formal ou model checking poderiam ter ajudado a reduzir esse tipo de bug
• Ainda assim, a verificação formal ponta a ponta em sistemas de grande escala continua em estágio inicial, e mesmo que algum uso parcial tenha ocorrido, ainda haveria a possibilidade de código defeituoso chegar ao ambiente operacional
• Será possível saber mais sobre quais métodos de verificação foram realmente usados quando o resultado final da investigação for divulgado

Segurança e relatório público

• As aeronaves no espaço aéreo britânico permaneceram seguras durante todo o incidente
  • Controladores de tráfego aéreo experientes monitoraram as aeronaves por meio de planos de voo conhecidos, rádio, radar e observação visual
  • O resultado não foi risco à vida, e sim uma situação em que muito menos voos podiam decolar ou precisavam desviar para evitar o espaço aéreo britânico
• A NATS reduziu a quantidade de voos para manter a segurança
• O relatório publicado é consideravelmente transparente e detalhado, e esse tipo de divulgação é importante para infraestrutura crítica
• Michael O’Leary, da Ryanair, criticou o relatório, chamando-o de “rubbish” e dizendo que ele minimiza o impacto sobre o setor aéreo, mas também há a avaliação de que o escopo do relatório inicial não era analisar a extensão das falhas da NATS

Direção para uma implementação mais robusta

• O problema envolve lidar com duas sequências de waypoints
  • ADEXP: lista completa de waypoints
  • ICAO: subsequência dos waypoints do ADEXP
• Como o plano ICAO não precisa necessariamente incluir os pontos de entrada e saída do espaço aéreo, encontrar o menor trecho contínuo da ICAO correspondente ao espaço aéreo britânico não é uma tarefa simples
• O problema do algoritmo incorreto foi manipular ponteiros que apontavam simultaneamente para os dados ICAO e ADEXP, deixando invariantes pouco claros fora do código
• A abordagem proposta é primeiro reconciliar os dados ICAO e ADEXP em uma única estrutura de plano de voo Combined e, só depois, extrair o trecho britânico
  • Calcular todas as reconciliações possíveis para detectar casos ambíguos
  • Se houver 0 reconciliações, não é possível reconciliar ICAO e ADEXP
  • Se houver várias, o caso é ambíguo e pode ser encaminhado para processamento manual
• A implementação de exemplo em Haskell trata explicitamente os erros NonUkPlan, CannotReconcileIcaoAdexp e AmbiguousReconciliationsOfIcaoAdexp
• No exemplo, mesmo que a lista ADEXP tenha o identificador duplicado Q, se os dados ICAO e ADEXP puderem ser reconciliados sem ambiguidade, o trecho britânico correto é retornado
• O código completo está em uk-portion-of-ICAO

[GN⁺]

Opiniões no Hacker News

• Foi como esquecer de incluir uma restrição de escopo geograficamente separado na consulta do plano de voo. Eu já conhecia esse bug quando trabalhei em um sistema de navegação aérea, já o vi acontecer na prática e já segui uma especificação que mandava incluir geofences para evitá-lo

  • Se os nomes dos pontos de navegação não são globalmente únicos e rotas entre regiões são comuns, não entendo por que não colocaram GUIDs nesses pontos de navegação
  • Fico curioso para saber qual linguagem foi usada no desenvolvimento
  • O padrão da ICAO define, desde 1978, que identificadores duplicados precisam estar separados por pelo menos 600 milhas náuticas (690 milhas, 1.100 km)

• O trecho “o sistema de backup aplicou a mesma lógica ao plano de voo e chegou ao mesmo resultado” é o problema. Em software, um sistema de backup deveria usar uma lógica diferente
  Anos atrás, na Boeing, quando trabalhei no sistema de trim do estabilizador do 757, havia dois computadores de aviônicos ligados à fiação que acionava o trim, conectados por meio de um comparador. Se as duas caixas não concordassem, ambas perdiam autoridade
  As duas caixas foram projetadas com algoritmos diferentes, linguagens de programação diferentes, CPUs diferentes e código de equipes diferentes separadas por firewall, com a intenção de impedir que um bug de um lado derrubasse o outro da mesma forma

  • Isso provavelmente era um sistema 2oo2 em que o piloto servia como backup, mas 2oo2 não tem alta disponibilidade
    Um sistema de controle de tráfego aéreo deveria ser, no mínimo, 2oo3[1], isto é, uma estrutura em que 2 de 3 sistemas desenvolvidos de forma independente precisam sempre concordar. Assim, se um sistema falhar, os outros dois continuam operando e não afetam a disponibilidade da indústria da aviação
    Ter pessoas como backup é inviável por causa de pessoal e complexidade. Sistemas de controle de tráfego aéreo precisam conseguir fornecer controle de separação sob condições IFR[2] e 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...
  • Tive exatamente o mesmo pensamento ao ler. Esse sistema de failover parece ter sido projetado mais para mitigar falhas de hardware do que bugs de software
  • “Quando um sistema de salvaguarda falha, ele falha de uma forma que não é segura”
    J. Gall
  • Equipes diferentes também cometem os mesmos erros com frequência. Não é uma estrutura perfeita, mas a abordagem descrita parece fazer sentido
  • Como observação paralela, é uma pena que, no MAX, eles soubessem dessa abordagem e ainda assim não a reutilizaram

• Lembro que houve outro problema na NATS que produziu o mesmo efeito. O sistema primário caiu e houve a troca para o secundário, mas o secundário caiu exatamente pelo mesmo motivo
  Parece que failover só deveria ser feito quando se sabe que o problema está no próprio sistema primário, e não no software em si. O método de simplesmente alternar só reforça a sensação de que não havia informação suficiente exposta para decidir o que realmente deveria ser feito
  A parte ainda mais incômoda é que não parecia haver um método como “ValidateFlightPlan”; se algo não pudesse ser analisado por qualquer motivo, lançava-se um erro, e não havia um caminho muito simples para tratar esse erro. Será que existe programador que olhe para um processador de entrada externa e não pense “o que faço se chegar uma entrada inválida que quebra tudo?”

  • Se se sabe que o sistema primário não está em um estado saudável, dá para tentar alternar esperando que tenha sido algo como um disco queimado ou um bit flip causado por raios cósmicos
    O verdadeiro recurso de segurança é a folga de 4 horas antes de ser necessário processamento manual
    Na aviação, o controle de segurança essencial é menos “como impedir que isso quebre para começo de conversa” e mais “o que faremos se isso quebrar por qualquer motivo”
  • Além da ausência de validação, este trecho do texto me chamou a atenção
    O estilo de programação parece muito imperativo e, pela descrição, soa como se o procedimento lidasse diretamente com a representação textual do plano de voo, não com uma estrutura de dados parseada a partir de um arquivo de texto. Se for realmente assim, é bastante preocupante, embora possa ser apenas o modo como foi descrito
    Pela descrição, eu não ficaria surpreso se estivessem simplesmente aplicando regex ou correspondência de substrings no texto, sem classes, objetos ou estruturas de dados. Também é preciso considerar a possibilidade de ser código C de décadas atrás, do qual toda a aviação britânica depende e que não pode ser reescrito nem substituído
  • Como não havia como determinar que a causa não era hardware, o failover em si estava correto. Mas a resposta quando ocorreu a segunda falha deveria ter sido melhor projetada para evitar o efeito em cadeia
  • Em termos elétricos, foi como trocar um fusível e vê-lo queimar de novo. A loja não tem mais fusíveis. Isso é progresso?
  • A falha no lançamento do Ariane 5[1] foi um problema parecido, e o resultado foi muito mais espetacular
    O sistema primário falhou por estouro de inteiro, e o sistema secundário idêntico também sofreu o mesmo overflow. O ângulo de ataque aumentou, os boosters se separaram e o foguete explodiu
    [1] https://en.wikipedia.org/wiki/Ariane_flight_V88

• Não entendo por que apenas o plano de voo que falhou foi colocado em uma fila de revisão humana e os demais voos não puderam continuar sendo processados. O mais difícil de entender é justamente que esse “recurso” não existia

  • O código classificou aquele erro como “isso jamais deve acontecer!”, e foi exatamente isso que aconteceu. Ele não o classificou como “dados do plano de voo inválidos” nem como “os dados estão corretos, mas ainda não são compatíveis”
    Quando ocorre um erro do tipo “jamais deve acontecer”, não dá para saber o que há de errado no sistema nem quão grande e amplo é o impacto. Talvez, como neste caso, fosse seguro continuar, mas também poderia haver um novo bug fatal no software que corrompesse silenciosamente todos os outros planos de voo e matasse pessoas. Se você não sabe se é seguro continuar, precisa parar
  • Para ser justo, no início do texto é dito que esses planos de voo às vezes são processados para aeronaves que já estão em voo. Embora, no mínimo, ainda estivessem a mais de 4 horas do Reino Unido
    Se fosse possível impedir a decolagem do avião específico com problema, tudo bem manter o sistema rodando; mas, se ele já está no ar, a conversa muda
    A decisão de “há uma aeronave em rota que entrará no espaço aéreo do Reino Unido, mas não sabemos quando nem por onde; vamos suspender planos de voo adicionais até sabermos a posição dessa aeronave” não é totalmente irracional
    Se realmente não for possível processar o plano de voo, uma solução razoável poderia ser desviar a aeronave e fazê-la pousar antes de chegar ao Reino Unido, mas isso, no fim, é algo que precisa esperar intervenção manual
  • Tanto o texto quanto a análise pós-incidente apontaram o modo de falha ruim do sistema FPRSA-R como o principal problema, e acho que essa é a parte mais importante
    Todo sistema pode falhar; o importante é que falhe de uma forma adequada e que os responsáveis estejam preparados para essa situação
    Um único plano de voo causou o problema, todo o sistema FPRSA-R caiu e nenhum plano de voo foi processado. Quando um plano de voo tem um problema, ele deveria ser movido para uma fila lenta separada, para processamento manual por uma pessoa. A própria NATS reconhece, em “ações já executadas ou em andamento”, que vai adicionar um filtro de mensagens no fluxo de dados entre IFPS e FPRSA-R para bloquear planos de voo com essa condição
  • Em um sistema crítico para a segurança, ao encontrar um “erro desconhecido”, é preciso assumir que todas as invariantes foram quebradas e que se entrou em comportamento indefinido, então não há escolha a não ser parar
    É válido dizer que isso deveria ter sido tratado como um erro conhecido, mas, em termos amplos, isso se parece com dizer que “deveriam ter escrito código sem bugs”. Mesmo que tivesse sido parseado em uma struct, poderia ser como um KeyError surgindo de repente em um código que assumia a existência de uma chave opcional
    A análise pós-incidente e as melhorias para esse tipo de caso precisam partir da premissa de que, em algum momento, ocorrerá um erro desconhecido, imprevisível e não tratado, e então discutir como lidar melhor com ele. A solução para o bug é corrigir o bug, mas a causa da grande interrupção foi um plano de recuperação de desastre que não podia ser executado em um tempo razoável. Qualquer que seja a prática, estilo, linguagem ou ferramenta de programação usada, um incidente de magnitude semelhante voltará a acontecer algum dia, com probabilidade 1, mesmo com os melhores desenvolvedores
  • O algoritmo descrito no texto provavelmente não é um código procedural simples que percorre, em ordem, os waypoints do plano de voo de entrada. Alguma abstração pode ter ocultado o fato de que isso era um erro de entrada
    Se, do ponto de vista do código, aquilo parecia uma falha de integridade no banco de dados subjacente de waypoints de navegação, a decisão de interromper o processamento de planos de voo fica muito mais compreensível
    Por exemplo, se o código pergunta ao repositório de waypoints e rotas “encontre para mim o waypoint em que esta rota sai do espaço aéreo do Reino Unido”, depois encontra o trecho de rota que contém esse waypoint e, em seguida, afirma que esse trecho passa pelo espaço aéreo do Reino Unido, mas essa afirmação falha, isso pode parecer não um problema no plano de voo, e sim uma quebra de uma premissa embutida nos dados de rotas
    Em certo sentido, talvez realmente fosse um bug fatal. Este incidente mostra que as premissas que o algoritmo fazia sobre os dados estavam erradas e que ele poderia potencialmente retornar respostas incorretas

• Textos relacionados
  Sistema de controle de tráfego aéreo do Reino Unido foi enganado por nomes de waypoints coincidentemente iguais - https://news.ycombinator.com/item?id=37430384 - setembro de 2023, 64 comentários
  Dados ruins de plano de voo causaram pane no controle de tráfego aéreo do Reino Unido - https://news.ycombinator.com/item?id=37402766 - setembro de 2023, 20 comentários
  Relatório de incidente da NATS sobre controle de tráfego aéreo detalha a causa-raiz e as soluções - https://news.ycombinator.com/item?id=37401864 - setembro de 2023, 19 comentários
  Falha na rede de controle de tráfego aéreo do Reino Unido - https://news.ycombinator.com/item?id=37292406 - agosto de 2023, 23 comentários

  • Depois de ouvir o episódio recente do The Daily sobre a indústria aérea dos EUA, fiquei convencido de que veremos uma manchete catastrófica em breve. Não dá para continuar assim
  • Pelo título deste texto, achei que fosse uma pane nova acontecendo agora

• O fato de terem culpado um plano de voo francês que a Eurocontrol já havia aceitado é prova de que eles não entendiam direito como o software funcionava. E a empresa austríaca também deve assumir parte da responsabilidade pela falta de testes intensivos

  • Eles só culparam a França porque é o Reino Unido. Maus hábitos são difíceis de abandonar

• Excelente texto. Lendo, acho que o ponto principal é este:
  Os nomes de waypoints usados no mundo todo não são únicos e, como uma espécie de remendo para evitar confusão, o padrão mais recente diz para manter identificadores iguais geograficamente afastados o suficiente. Mesmo assim, em uma mesma rota, o mesmo nome de waypoint pode significar locais diferentes.
  O software não levou essa possibilidade em conta, o cálculo da rota falhou, lançou uma “exceção fatal” e entrou em “modo de manutenção”. Ou seja, morreu.
  O sistema de backup assumiu, mas encontrou o mesmo bug com os mesmos dados e também morreu, e a equipe de suporte sofreu. No fim, só depois de contatar o fornecedor do software é que encontraram logs de baixo nível que revelavam a causa.

  • Não consigo entender por que, em um sistema crítico para a missão desse nível, não havia alguém familiarizado com o código de sobreaviso 24 horas por dia, 7 dias por semana.
  • O ponto central é que faltava um namespace adequado. Quem diria que engenheiros aeroespaciais precisariam estudar sistemas operacionais?
    Um amigo meu, piloto aposentado da Força Aérea, se formou na Cranfield University, que é uma das principais instituições de pós-graduação em engenharia aeroespacial do Reino Unido e tem até seu próprio aeroporto para ensino e pesquisa[1]. Esse amigo disse que aprendeu sistemas operacionais em Cranfield, e agora entendo o motivo.
    Pelos outros comentários, parece que já existe um padrão de namespace, mas que a NATS/ATC não o usa. Espero que este caso faça com que finalmente comecem a usar. O comentário no topo falava de um bug de geofencing, mas, se a NATS/ATC estivesse usando o namespace correto, é bem provável que o geofencing nem fosse necessário.
    [1] Cranfield University:
    https://en.wikipedia.org/wiki/Cranfield_University

• “Pela explicação, parece que o procedimento manipula diretamente a representação textual do plano de voo, em vez de uma estrutura de dados parseada a partir de um arquivo de texto. Se for mesmo assim, é bem preocupante, embora possa ser só a forma como foi explicado.”
  Em trabalhos na indústria da aviação, esse tipo de abordagem é comum. Se você perguntar a programadores sobre modelo de domínio ou parsing, eles costumam ficar com cara de paisagem. Eles gostam de código de validação e, se a validação falha, gostam simplesmente de desistir. É tudo um pipeline de dados burro, sem nenhum código que modele as atividades que acontecem no mundo real.
  Em sistema nenhum existe algo como um tipo “plano de voo” com comportamento, ou um conjunto de tipos para waypoints. Mesmo quando há tipos, são structs de string no estilo C, e cada vez que um membro dessa struct é acessado, ele é parseado de novo — não uma vez, mas todas as vezes. Como o texto diz, “o estilo de programação parece muito imperativo” mesmo.

  • Desistir quando a validação falha é, sim, uma prática padrão para evitar propagar dados mal interpretados e gerar bugs muito mais complexos. Valide cedo, valide com rigor, informe o erro e não tente interpretar à força o que há de estranho na entrada. No momento em que você tenta ser “inteligente”, abre uma brecha de segurança.
    Morrer com entrada ruim é errado, mas tentar interpretar dados não validados sem especificação tende a gerar divergências de entendimento posteriores, problemas de compatibilidade e condições de contorno inesperadas. Ninguém quer pagar por um sistema que trate todos os casos completamente testados, por ferramentas de simulação de entradas inválidas e por verificação formal do parser e de todo o código que usa seus resultados.
    Já há problemas de sobra com transmissores de dados não conformes, legados e com bugs, além da complexidade semântica e de timing das interfaces. Tentar responder de forma inteligente a dados com formato ou codificação incorretos torna tudo mais perigoso.
    Só construir um sistema que funcione conforme a especificação já é difícil e caro. Variações sutis que aceitam com mais tolerância comportamentos não especificados são ou um convite a bugs, ou a construção de um sistema mais caro que não passa nos critérios de preço de compra.
  • Muito interessante e também um pouco assustador. É curioso como setores diferentes desenvolveram culturas de desenvolvimento distintas, por motivos que nem sempre são claros.

• “Controle de tráfego aéreo do Reino Unido: investigação apura se erro francês causou a falha”
  Claro que não. É um sistema britânico; como isso poderia ser culpa de uma companhia aérea francesa? Um sistema desses deveria ter uma arquitetura à prova de falhas com redundância.
  Talvez tivesse bastado rejeitar um item ruim e continuar.

  • Se for para discutir em termos nacionalistas, o software era austríaco.

• Foi um dia que eu não quero lembrar. Um destino que normalmente levaria 2 horas acabou levando 15 horas.
  Peguei trem, ônibus e depois trem de novo; 30 minutos depois de eu comprar a passagem, os bilhetes dos dois dias seguintes já tinham esgotado.

  • Fiquei 6 horas esperando no aeroporto até descobrir que o voo tinha sido cancelado, e tive que remarcar. Eu estava indo para New York ver a família, então também não havia exatamente outro meio de transporte viável.