Technologie militaire

Je vais me lancer dans un exercice périlleux, poster quelques sujets sur des problèmes de maths rencontrés en technologie militaire , j'essaierai de faire le moins de calculs possible mais il faudra en faire comme même un peu au bout d'un certain moment…

L’échec d’interception des missiles Patriot.


Le 25 Février 1991 durant la guerre du Golf, une batterie de Patriot basé à Dharan en Arabie Saoudite n’arrive pas à intercepter un missile Scud Irakien, causant la mort de 28 soldats et blessants 100 autres personnes.

Le rapport d’enquête du General Accounting Office titré (Patriot Missile Defense: Software Problem Led to System Failure at Dhahran, Saudi Arabia) révèle que la cause de cet échec est due à un calcul non précis depuis le lancement dû à un cumul d’erreurs arithmétiques, le temps calculé en dixièmes de secondes dans l’horloge interne du système mais convertis en secondes pour des besoins du système de traque est à l’origine du dysfonctionnement.

Cette conversion en secondes étais effectués en multipliant par 1/10, ce calcul étais réalisé en utilisant une représentation à 24 bits, la valeur 1/10 n’ayant pas de représentation exacte en binaire est remplacé par une valeur très proche.

La petite erreur multiplié par le nombre important donnant le temps en dixièmes de secondes produit une erreur importante, dans ce cas précis la batterie de missiles étais en marche depuis 100 heures.

Un petit calcul montre que l’erreur introduite au départ sur la représentation de 1/10 étais de 0.000000095
multiplié par le nombre de dixièmes de secondes dans 100 heures donne :

0.000000095×100×60×60×10=0.342000

Un missile SCUD a une vitesse de 1676 mètres/secondes et donc aura parcouru 500 mètres environ pendant ce temps, ce temps était largement suffisant pour que le SCUD soit à l’extérieur de la zone de portée minimale, paradoxalement le fait que la précision ai été améliorée dans les autres parties du code mais pas toute a contribué au problème car les erreurs ne pouvaient pas s’éliminer entre elles.

Ce petit post est tiré du rapport original du GAO = General Accounting Office disponible en anglais dans sa totalité ici

http://www.fas.org/spp/starwars/gao/im92026.htm

Merci beaucoup Trident pour ces explications.

Il est étonnant de constater que l'armée la plus puissante du monde est nulle en arithmétique et achète n'importe quoi sans vraiment se soucier de tester le matériel.

C'ets quand même fou, une conversion de ratée : 28 morts et 100 blessés
La vie ne tient qu'à un fil.

Reste à voir si il vont en inculquer la responsabilité au fabricant.

vdparter a écrit

Reste à voir si il vont en inculquer la responsabilité au fabricant.

Je ne crois pas , ce genre de problèmes surviens souvent dans l'ingénierie , c'est difficile de tout tester et de prévoir toutes les possibilités, une commission trouve le problème la question est qui paie les mises a jours et les modifications nécessaires ? le fabriquant ou l'opérateur ?

Ce type de problème arithmétique est aussi en partie a l'origine de l'explosion d'Ariane V où un software embarqué relié au Gyrolasers transmettait une information ( le degré d’inclinaison de la fusée) représenté en 64 bits à un autre (software lié au système de sécurité de la fusée ) qui lui utilisais une représentation en entiers 16 bits, la conversion échoue et le système de sécurité déclenche l’autodestruction de la fusée car il pensais que la fusée repartait vers la terre alors que ce n'étais pas le cas.

Trident a écrit

Je ne crois pas , ce genre de problèmes surviens souvent dans l'ingénierie…

C'est pas vraiment rassurant ce que tu écris là.

Raf

Malheureusement c'est bien le cas.

La concurrence entre industriels fait que les cycles de recherches développements sont de plus en plus courts, les cas présentant un risque statistiques faible ne sont pas traités au nom d'un degré de risque acceptable, la version scientifique du "collateral dammage"

Ce principe est au centre des polémiques récurrentes sur les médicaments pour parler d'un point médiatisé…

On teste le plus gros et on néglige quelques petits trucs on se disant qu'on court un faible risque mais ce risque peut s'avérer réel…

AH les erreurs d'arrondi et autres erreurs propagées!

J'ai eu un cours la dessus, le quadrimestre passé, on voyait aussi quelques exemples impressionant du phénomène "boule de neige" du a ces erreurs d'arrondi qui donnait des résultats catastrophiques a grande échelle.

Ce genre d'erreurs est tout de même de plus en plus pris en compte, c'est d'ailleurs pour ça que la norme IEEE-754 est sorti en 1985. Il y a encore beaucoup de travaux à ce sujet, pour prédire justement quelles sont les erreurs commises et pour savoir comment les prendre en compte afin de les corriger. Contrairement à ce qu'on pourrait croire, on n'a absolument pas besoin de tester toutes les possibilités pour calculer les erreurs. Enfin, tant que les processeurs calculent correctement, pas comme le fameux bug du Pentium I

d9pouces a écrit

Ce genre d'erreurs est tout de même de plus en plus pris en compte

Ce genre d'erreurs étaient connus à l'époque aussi, 91 c'est pas si loin et Ariane V non plus, le problème est que plusieurs composants conçus de manière quasi autonomes sont reliés ensuite, si les deux processeurs communiquant dans le Patriot utilisait la même norme même de très mauvaise qualité ce problème ne serai jamais arrivé, idem pour Ariane V.

d9pouces a écrit

tant que les processeurs calculent correctement, pas comme le fameux bug du Pentium I

Le cumul d'erreurs d'arrondis n'est pas un problème lié à la précision du processeur, mais a l'existence d'une erreur au départ du calcul, ce genre d'erreurs existe du fait même de la conception des processeurs, des machines a états finis qui font du calcul sur un ensemble infini, ce qui fait que quelque soit le type de matériel une erreur existe au départ du fait qu'un processeur ne peut pas représenter tout les nombres mais une partie seulement.

La question importante est : étant donné l'existence d'une erreur au départ d'un calcul ou d'une suite d'opérations , est ce que cette erreur va s'amplifier au fur et a mesure des opérations ou restera t-elle dans des mesures acceptables ?

Dans le cas traité ici les processeurs n'ont fait aucune erreur de calcul, l'augmentation de la précision du processeur retarde le phénomène mais ne l'empêche pas , ça se serai produit plus tard.

d9pouces a écrit

Contrairement à ce qu'on pourrait croire, on n'a absolument pas besoin de tester toutes les possibilités pour calculer les erreurs.

Je pense que je me suis mal exprimé plus haut et donc je vais préciser ce que j'entend par toutes les possibilités, dans la RD de nos jours on pense aussi économie, il existe des tests qu'on peut faire pour avoir plus d'assurances sur le produit final, or dans la pratique le jeux de la concurrence fait que les industriels veulent sortir leurs produits de plus en plus vite et que des tests qu'il était possible de faire avant la sortie du produit ne sont pas réalisés.

Des fois des tests jugés couteux tout simplement par rapport au risque ne sont pas fait dans le même soucis, on préfère lancer le produit et courir le risque que le prévenir au départ.

Ici je signale un problème global dans la RD qui est d'ordre éthique quand on pense a l'industrie du médicament ou les recherches sur l'agroalimentaire par exemple.

Techniquement je suis d'accord avec toi on est pas obligé de tester toutes les possibilités, même que les maths ça sert à ça.

d9pouces a écrit

tant que les processeurs calculent correctement, pas comme le fameux bug du Pentium I

Le cumul d'erreurs d'arrondis n'est pas un problème lié à la précision du processeur, mais a l'existence d'une erreur au départ du calcul, ce genre d'erreurs existe du fait même de la conception des processeurs, des machines a états finis qui font du calcul sur un ensemble infini, ce qui fait que quelque soit le type de matériel une erreur existe au départ du fait qu'un processeur ne peut pas représenter tout les nombres mais une partie seulement.
Oui, ça me paraît évident, je voulais juste dire que ce n'était pas évident que le processeur soit fiable (en fait, tous les processeurs ont des bugs, mais tous ne sont pas graves).

La question importante est : étant donné l'existence d'une erreur au départ d'un calcul ou d'une suite d'opérations , est ce que cette erreur va s'amplifier au fur et a mesure des opérations ou restera t-elle dans des mesures acceptables ?

Dans le cas traité ici les processeurs n'ont fait aucune erreur de calcul, l'augmentation de la précision du processeur retarde le phénomène mais ne l'empêche pas , ça se serai produit plus tard.

Sure, mais même si on n'augmente pas la précision, on peut très bien prendre l'erreur en compte, de façon mathématique. Du coup, on peut répondre à cette question, de plusieurs manières, même (genre arithmétique par intervalles, calcul d'erreur inverse ou directe). Par contre, c'est vrai que ce genre de calculs est assez … embêtant à mener, pour rester poli. Mais pour des applications critiques comme Ariane, ça vaut le coup, normalement. Du coup, on peut très bien empêcher complètement ce phénomène, en fait : il suffit d'utiliser des bibliothèques de calcul à précision variable, et réfléchir correctement avant de faire les calculs (par exemple, une simple somme a + b + c + d peut donner des résultats différents suivant l'ordre dans lequel elle est calculée, même si tous les termes sont positifs, je pense)

Ce qui pose problème n'est pas qu'on ne sait pas -quoique- mais qu'on ne se permet de prendre le temps de le faire justement, dans le deux cas le problème est survenue par la communication de données entre deux processeurs ne calculant pas à la même précision.

Dans le cas d'Ariane, la fusée embarquait une quantité de capteurs et de processeurs tel que la procédure de vérification deviens très ardue.

Une solution simple a ce problème aurais été que tout les processeurs de calculs embarqués soient aux même standard, là ce qui rend la tache dure c'est qu'on peut pas se permettre de reconstruire une fusée avec des composants à 100 % nouveau ce qui serait extrêmement long et couteux , Ariane partageais avec ses précédentes versions certains composants en commun qui indépendamment pris fonctionnaient bien jusque là.

Mais voilà une fois combinés avec les éléments nouveau ça a crée un problème, bien que le problèmes des erreurs arithmétique est bien connu maintenant mais il réussit comme même a surprendre…

Juste un dernier truc dans le cas d'Ariane V les causes de l'accident sont un peu plus compliqués que l'erreur d'arrondi mais c'est un élément important, dans ce post j'ai tenté de simplifier les choses et un œil averti dira que c'est très incomplet.

une simple somme a + b + c + d peut donner des résultats différents suivant l'ordre dans lequel elle est calculée, même si tous les termes sont positifs, je pense

Oui un tas d'exemples comme ça existent pour souligner les fautes de calculs en précision fini.

Sympa de nous faire partager ce domaine Trident

Par contre je trouve le parallèle avec l'industrie pharma un peu rapide…les effets secondaires des médicaments inclus énorméments de variables et, ces symptomes ne sont que très rarement du aux R&D

Je trouve aussi le parallèle rapide ..

Les délais court de développements sont dénoncés dans toutes les industries y compris pharmaceutiques…

En fin a ce que je sait …
D'après les quelques éléments glanés ça et là..
Qui sont plutôt confus dans ma mémoire a présent…
Je n'arrive plus a me rappeler exactement d'aucun d'eux …
Je ne m'en rappelle même pas si je les ai eu un jours …
Je me souviens que j'ai pensé ça à un certain moment…
EN fait j'en sait rien du tout…

Que toutes les possibilités d'erreurs ne puissent être testées, c'est certain. Mais dans le cas d'armes complexes comme le Patriot, le problème est typiquement américain; ils ne font pas d'évaluations opérationnelles de leurs matèriels avant de lancer la construction en série. La plupart du temps celle ci commence avant que les essais soient terminés, du moment que le marché est signé, on fabrique. Cela a valu des incidents célèbres avec le système Phalanx et aussi leur jamer-pod soit disant universel (j'ai oublié son nom) qui ne brouillait pas grand chose. Dans le cas du Patriot si un tir réel avait été fait en simulant les conditions de guerre avec la batterie en veille depuis 100 heures, le problème aurait été vu. Pour Ariane le problème est différent, c'est celui du développement et de la fabrication en coopération: voir Airbus 380.

Trident a écrit

Je trouve aussi le parallèle rapide ..

Les délais court de développements sont dénoncés dans toutes les industries y compris pharmaceutiques…

En fin a ce que je sait …
D'après les quelques éléments glanés ça et là..
Qui sont plutôt confus dans ma mémoire a présent…
Je n'arrive plus a me rappeler exactement d'aucun d'eux …
Je ne m'en rappelle même pas si je les ai eu un jours …
Je me souviens que j'ai pensé ça à un certain moment…
EN fait j'en sait rien du tout…

Les délais de "protections" des brevets refroidissent aussi un peu les secteurs R&D…je crois que c'est 10 ans désormais avant de passer domaine public