Pontifications : "Le besoin d'améliorations radicales du carburant ne fera qu'augmenter avec le temps."

Apr 09, 2023

@ claes OK, donc c'est carrément dans ma timonerie. Je continue à insister sur l'importance de la compétence dans la gestion de la complexité. C'est un raccourci pour beaucoup de choses, et nous pourrions faire tout un diplôme supérieur de discussion et d'écriture sur ce sujet. C'est énorme.

La chose naturelle à faire pour les humains est de surutiliser nos dernières nouvelles technologies et de ne pas les utiliser à bon escient. Il existe de solides preuves archéologiques de ce comportement remontant à au moins 9500 ans. Que nous le fassions avec des puces informatiques et des logiciels ne devrait pas être surprenant.

Pourquoi faut-il tant de temps pour certifier les systèmes avioniques (combinaisons matérielles et logicielles - ce n'est PAS seulement des logiciels !!!!! - entendez-moi marteler la table sur ce point) ?

Du côté de la défense, nous avons un processus appelé analyse du mode de défaillance. Les commerciaux aiment appeler exactement le même processus Mode de défaillance et analyse des effets. Ce que vous faites, c'est passer par un processus de documentation exacte du fonctionnement de quelque chose et analyser chaque étape et chaque fil d'étapes pour identifier tout ce qui peut mal tourner. Cela commence par des pannes matérielles qui finissent par arrêter de fonctionner ou par les deux, ou par l'introduction de mauvaises données dans le logiciel.

Vers 1980, vos puces les moins chères typiques (nous parlons de capacité fab, pas de type de puce) auraient jusqu'à un peu moins d'un million de composants IC, dont un peu plus de 25% seraient des transistors. Ils étaient disposés dans des tableaux similaires, donc même s'il s'agit de grands nombres, il était possible pour l'EE moyen faisant une conception d'avoir une assez bonne idée du fonctionnement exact d'une puce donnée. En 1995, cette capacité avait été perdue. Le nombre de très bons EE de premier ordre qu'il a fallu pour comprendre pleinement une puce à moindre coût était probablement de trois ou quatre, mais vous pouvez toujours constituer une équipe dans une entreprise aérospatiale qui pourrait le faire. En 2000, rassembler une telle équipe était devenu impossible pour trois raisons. L'un était le nombre croissant de composants IC (souvent appelé loi de Moore). Un autre était certaines des technologies étonnantes qui ont été intégrées à certaines puces telles que l'auto-guérison et le toujours étonnant Field Programmable Gate Array (FPGA). Et le troisième était la fuite rapide des meilleurs talents hors de l'aérospatiale vers les entreprises technologiques. Et ce n'est que le matériel.

Le logiciel voyait la même chose : une complexité explosive, le franchissement du seuil de compréhensibilité par une équipe qui peut être assemblée, et la fuite des talents de l'aérospatiale vers la technologie.

Donc, la question qui était carrément sur la table au milieu des années 1990 alors que Condit menait Boeing dans une première très bonne activité de fusions et acquisitions avec North American Rockwell, puis une désastreuse avec MD, était de savoir comment gérer cette complexité explosive et le déclin des talents. problème dans l'avionique aérospatiale? Comment pouvons-nous même faire nos conceptions de telle sorte qu'une FMA compétente (alias FMEA) soit même possible ?

Il existe un moyen de le faire, mais cela nécessite un leadership en ingénierie mature et perspicace qui comprend le défi et ce qui doit être fait. Et ce leadership en ingénierie doit être pleinement soutenu par la communauté des entreprises et des investisseurs. Dans le cas de Boeing, rien de tout cela ne s'est produit, donc les nouveaux produits n'ont pas fonctionné et des gens ont été tués. C'est aussi simple que cela.

Cette prochaine partie sera une simplification excessive de VAST. Ce qu'il faut faire, c'est utiliser des usines de fabrication de circuits intégrés plus simples, dans des modules fonctionnels discrets, avec des interactions étroitement définies les unes avec les autres, afin que les gens puissent isoler et comprendre ce qu'ils sont censés faire et identifier les risques qui nécessitent une attention particulière.

Ce qui s'est toujours produit chez Boeing et dans l'avionique de mission des programmes de chasse Lockheed, c'est que la capacité des usines de fabrication de puces à héberger un nombre inimaginable de fonctions et d'outils logiciels qui peuvent tirer parti de ces grands nombres (nous sommes bien dans 9 ordres de grandeur et plus ici) ont été utilisés sans discernement. Ainsi, les équipes d'ingénierie sont presque totalement aveugles quant à ce qui se passe à l'intérieur de ce qui est censé être leur propre conception. Et c'est sans ajouter d'outils d'IA génératifs dans le mélange.

La bonne réponse est de travailler avec les entreprises technologiques, probablement sur des programmes financés par le gouvernement, et de développer un ensemble radicalement différent de puces et d'outils de développement logiciel pour les applications de système de contrôle.

Soit dit en passant, la définition Wikipédia d'un système de contrôle a mal tourné il y a quelques années, vous devez donc faire attention. Il contient beaucoup de bonnes informations, mais la définition de haut niveau est tout simplement fausse. Il parle d'un cas relativement étroit dans lequel les boucles de rétroaction sont une partie déterminante, et ce n'est vraiment qu'un pourcentage faible mais important de l'ensemble du sujet.