Pontificações: “A necessidade de melhorias radicais no combustível só aumentará com o tempo.”

Apr 09, 2023

@ claes OK, então isso está dentro da minha casa do leme. Continuo insistindo na importância da competência no gerenciamento da complexidade. Isso é uma abreviação para muitas coisas, e poderíamos fazer um grau avançado de discussão e escrever sobre esse tópico. É enorme.

A coisa natural para os humanos fazerem é abusar de nossas tecnologias mais recentes e quentes e não usá-las com sabedoria. Há evidências arqueológicas sólidas para esse comportamento que remontam a pelo menos 9.500 anos. O fato de estarmos fazendo isso com chips de computador e software não deveria ser surpreendente.

Por que demora tanto para certificar sistemas aviônicos (combinações de hardware e software – NÃO é apenas software!!!!! – ouçam-me batendo na mesa nesse ponto)?

Do lado da defesa, temos um processo chamado Análise do Modo de Falha. O pessoal comercial gosta de chamar exatamente o mesmo processo de Modo de Falha e Análise de Efeitos. O que você faz é passar por um processo de documentar exatamente como algo funciona e analisar cada etapa e sequência de etapas para identificar tudo o que pode dar errado. Isso começa com falhas de hardware que terminam em um ou ambos parando de funcionar ou alimentando dados incorretos no software.

Por volta de 1980, seus chips típicos de menor custo (estamos falando de capacidade fabulosa, não do tipo de chip) teriam até pouco menos de um milhão de componentes IC, um pouco mais de 25% dos quais seriam transistores. Eles foram organizados em matrizes semelhantes, portanto, mesmo que sejam números grandes, era possível para o EE médio fazer um projeto para obter um bom controle sobre exatamente como um determinado chip funcionava. Em 1995, essa habilidade havia sido perdida. O número de EEs de primeira linha realmente bons necessários para entender completamente um chip de menor custo provavelmente era três ou quatro, mas você ainda poderia montar uma equipe em uma empresa aeroespacial que pudesse fazer isso. Em 2000, montar uma equipe como essa havia se tornado impossível por três motivos. Um deles foi o número vertiginoso de componentes do IC (muitas vezes referido como a Lei de Moore). Outra foram algumas das incríveis tecnologias que foram incorporadas a alguns chips, como a autocorreção e o ainda incrível Field Programmable Gate Array (FPGA). E a terceira foi a rápida fuga de talentos de primeira linha do setor aeroespacial para empresas de tecnologia. E este é apenas o hardware.

O software estava vendo a mesma coisa - complexidade explosiva, cruzando o limiar da compreensão por uma equipe que pode ser montada e o talento sendo drenado do setor aeroespacial para a tecnologia.

Portanto, a questão que estava diretamente sobre a mesa em meados da década de 1990, quando Condit liderava a Boeing em uma primeira atividade realmente boa de fusões e aquisições com a North American Rockwell e depois desastrosa com a MD, era como administrar essa complexidade explosiva e talento em declínio problema em aviônicos aeroespaciais? Como fazemos nossos projetos de forma que um FMA competente (também conhecido como FMEA) seja possível?

Existe uma maneira de fazer isso, mas requer uma liderança de engenharia madura e perspicaz que entenda o desafio e o que precisa ser feito. E essa liderança de engenharia precisa ser totalmente apoiada pela comunidade corporativa e de investimentos. No caso da Boeing, nada disso aconteceu, então novos produtos não funcionaram e pessoas morreram. É simples assim.

Esta próxima parte será uma simplificação VAST. O que precisa ser feito é usar IC fabs mais simples, em módulos funcionais discretos, com interações bem definidas entre si, para que as pessoas possam isolar e entender o que devem fazer e identificar os riscos que precisam de atenção especial.

O que tem acontecido consistentemente na Boeing e nos aviônicos de missão nos programas de caça da Lockheed é que a capacidade dos fabricantes de chips de hospedar um número inimaginavelmente grande de funções e ferramentas de software que podem tirar proveito desses grandes números (estamos bem 9 ordens de grandeza e mais aqui) foram usados ​​sem discrição. Assim, as equipes de engenharia são quase totalmente cegas quanto ao que está acontecendo dentro do que supostamente são seus próprios projetos. E isso sem adicionar ferramentas de IA generativas à mistura.