Provavelmente é falso, mas não há motivo para não estar presente e por que não poderia ser aprovado assim.
Um (The!) meio aceitável de conformidade com o FAR / CS 23 / 25.1309 é DO-178. O software Airborne é desenvolvido para atender a um Nível de Garantia de Projeto (DAL) que é derivado da Análise de Risco Funcional e da Avaliação Preliminar de Segurança do Sistema (consulte SAE ARP 4761).
Todos os FMC / FMS em que trabalhei foram DAL C, o que significa que a falha é 'Major' definida como a "falha é significativa, mas tem um impacto menor do que uma falha perigosa (por exemplo, leva a passageiro desconforto em vez de ferimentos) ou aumenta significativamente a carga de trabalho da tripulação (relacionada à segurança) ".
Para o desenvolvimento do DAL C, a independência é necessária apenas para atender ao aspecto do QA do Software. A atividade de verificação de software não precisa ser independente do desenvolvedor. No entanto, para o código DAL C, há um requisito para concluir a cobertura estrutural da declaração completa, ou seja, a estrutura deve ser testada pelo menos uma vez durante o teste de verificação formal (ou seja, uma decisão deve ser testada como verdadeira ou falsa).
Portanto, os Casos e Procedimentos de Verificação de Software (SVCP) precisariam ter um teste para o jogo pong ou então a cobertura estrutural teria mostrado que o código era 'Código Morto' e teria que ser removido.
A autoridade de certificação (FAA, EASA ou de outra forma) não costuma revisar o SVCP ou os resultados (SVR).
A unidade também provavelmente terá uma aprovação de Ordem Técnica Padrão (TSO), mas, desde que os requisitos de desempenho sejam atendidos para o TSO aplicável (por exemplo, TSO-C115c), a aprovação será concedida.