Discussion:Vol 501 d'Ariane 5
Tout ou partie de cet article est issu de la traduction de l'article sous licence CC-BY-SA « (en) Cluster (spacecraft) » dans sa version du 5 juin 2008.
Consultez l'historique de la page originale pour connaître la liste de ses auteurs.
Cet article est indexé par les projets Astronautique et Informatique.
Les projets ont pour but d’enrichir le contenu de Wikipédia en aidant à la coordination du travail des contributeurs. Vous pouvez modifier directement cet article ou visiter les pages de projets pour prendre conseil ou consulter la liste des tâches et des objectifs.
| Avancement | Importance | pour le projet | |
|---|---|---|---|
| Bon début | Faible |  | Astronautique (discussion • critères • liste • stats • hist. • comité • stats vues) |
 | Informatique (discussion • critères • liste • stats • hist. • comité • stats vues) | ||
Cet article comporte une liste de tâches suggérées :
D'après http://www.ima.umn.edu/~arnold/disasters/sleipner.html le coût de l'erreur dans le logiciel NASTRAN dans les calculs qui ont conduit à la destruction de la plateforme pétrolière Sleipner A est de 700 millions de dollars en 1991. L'affirmation selon laquelle le bug d'Ariane 5 est le plus cher de l'histoire est à revoir il me semble.
8 bits ou 16 bits ?
modifierL'article présente l'erreur comme un dépassement de mémoire dans un stockage 8 bits depuis la version du 10 mars 2013 à 23:41 et modifiée en dernier par 81.250.54.201 (sans commentaires). Avant cette contribution, l'article ne mentionnait pas la taille de l'espace mémoire. Toutes les références que je trouve décrivent un problème de conversion entre 32 et 16 bits (et non pas 8 bits). Excepté le site http://cyberzoide.developpez.com/pourquoi/index.php3?page=ariane5 qui ne me semble pas fiable.
D'après la présentation de Jean-Jacques Lévy, le code source à l'origine du bug est :
L_M_BV_32 := TBD.T_ENTIER_32S ((1.0/C_M_LSB_BV) * G_M_INFO_DERIVE(T_ALG.E_BV));
if L_M_BV_32 > 32767 then
P_M_DERIVE(T_ALG.E_BV) := 16#7FFF#;
elsif L_M_BV_32 < -32768 then
P_M_DERIVE(T_ALG.E_BV) := 16#8000#;
else
P_M_DERIVE(T_ALG.E_BV) := UC_16S_EN_16NS(TDB.T_ENTIER_16S(L_M_BV_32));
end if;
P_M_DERIVE(T_ALG.E_BH) := UC_16S_EN_16NS (TDB.T_ENTIER_16S ((1.0/C_M_LSB_BH) * G_M_INFO_DERIVE(T_ALG.E_BH)));
OK pour changer 8 bits par 16 bits ? Et documenter l'article avec ce code source ? --Oliver H (discuter) 16 octobre 2016 à 16:35 (CEST)
- Le rapport de la commission mentionne explicitement une conversion "flottant 64 bits vers entier 16 bits". Le code issus de la présentation de Jean-Jacques Lévy montre la même chose (TDB.T_ENTIER_16S() effectue cette conversion), et le patch pour corriger fait une première conversion vers entier 32bits puis une conversion vers 16 bits qui gère ces dépassements.
- Ce n'est donc pas un problème de débordement vers un entier 8 bits et l'explication impliquant une vitesse de "300" (sans unité) ne correspond à rien. Je supprime le paragraphe. 82.65.235.81 (discuter) 19 juillet 2022 à 17:22 (CEST)