Re: [ExoMars 2016] Suivi de l'EDL de Schiaparelli et de l'insertion orbitale de TGO.

[Space Opera]

Ça serait pas loin d'être une première si un élément aussi central de la sonde a été mal designé ou codé. Ça serait désastreux pour la réputation de ceux qui ont fait une boulette pareille, si elle était avérée.

Tu as oublié de citer TAS dans ta phrase comme à l'accoutumée, probablement un oubli dû à la fatigue ?

Comme ça a été dit juste avant, si je ne cite personne c'est parce que je ne sais pas qui avait fait le GNC ! En disant TAS parce que c'est le maître d'oeuvre, on a tout dit et on a rien dit. Apparemment, d'après MarsSurfaceWanderer, c'est donc GMV qui était en charge de cette fonction. Ils ne doivent pas se sentir tranquilles là-bas. Et ça risque de faire tâche sur leur carte de visite, puisque ça a l'air d'être une entreprise qui n'avait pas vraiment d'implication de premier plan dans les missions spatiales... jusqu'à ce crash.

[Hadéen]

Tu as oublié de citer TAS dans ta phrase comme à l'accoutumée, probablement un oubli dû à la fatigue ?

Comme ça a été dit juste avant, si je ne cite personne c'est parce que je ne sais pas qui avait fait le GNC ! En disant TAS parce que c'est le maître d'oeuvre, on a tout dit et on a rien dit. Apparemment, d'après MarsSurfaceWanderer, c'est donc GMV qui était en charge de cette fonction. Ils ne doivent pas se sentir tranquilles là-bas. Et ça risque de faire tâche sur leur carte de visite, puisque ça a l'air d'être une entreprise qui n'avait pas vraiment d'implication de premier plan dans les missions spatiales... jusqu'à ce crash.

Pour préciser je dirais que sous traiter le LN3 c'est très commun dans le spatial européen, satellites et lanceurs. Par contre la réception avec une installation de simulation fonctionnelle, c'est le job du MOE.

[Griffon]

Pour le coup ce n'est pas TAS mais GMV, une entreprise basée à Madrid.

Je sais bien.
Ca me faisait juste sourire de pas avoir un gros doigt pointé vers TAS comme certains nous y avaient habitué :)

[Space Opera]

Pour le coup ce n'est pas TAS mais GMV, une entreprise basée à Madrid.

Je sais bien.
Ca me faisait juste sourire de pas avoir un gros doigt pointé vers TAS comme certains nous y avaient habitué :)

Il faut se détendre et arrêter de voir des choses dans ce que les gens ne disent pas. C'est un peu facile comme accusation les "non-dits", surtout quand on prend soin de ne citer personne en particulier par manque d'information. Ça m'est égal que ça soit TAS, GMV, Boeing, Airbus ou Dieu le père qui soit responsable de tout ça, j'ai pas d'actions chez eux !
Comme dans le topic pour l'échec de la Falcon 9, on cherche juste à savoir qui a fait quoi et comprendre ce qui a merdé. Pas besoin de parti pris pour ça, c'est ridicule.

[Space Opera]

Pour préciser je dirais que sous traiter le LN3 c'est très commun dans le spatial européen, satellites et lanceurs. Par contre la réception avec une installation de simulation fonctionnelle, c'est le job du MOE.

Tu veux dire que la source de l'erreur est autant à chercher du côté de celui qui a codé l'algorithme que de celui qui ne l'a pas détecté ? Après, J'imagine que ça dépend si c'était justement imprévisible ou pas comme conditions d'entrée.

[Hadéen]

Pour préciser je dirais que sous traiter le LN3 c'est très commun dans le spatial européen, satellites et lanceurs. Par contre la réception avec une installation de simulation fonctionnelle, c'est le job du MOE.

Tu veux dire que la source de l'erreur est autant à chercher du côté de celui qui a codé l'algorithme que de celui qui ne l'a pas détecté ? Après, J'imagine que ça dépend si c'était justement imprévisible ou pas comme conditions d'entrée.

Je dirais que dans ce genre d'affaire, cela retombe toujours plus ou moins sur le MOE. Soit il a mal spécifié le code à réaliser par le sous traitant. Et ensuite tout a été normal et validé mais sur la base d'une spécification erronnée ou plus vraisemblablement incomplète. Soit la spécification de codage du MOE vers le sous traitant était correcte et complète, auquel cas le sous traitant a commis une erreur et ne l'a pas détectée, mais la réception fonctionnelle par le MOE non plus...

Je dit cela car je pense au programme de vol d'Ariane. ASL sous traite son codage a une entreprise espagnole. Par contre une fois codé, il subit des dizaines et des dizaines de tests sur l'installation de simulation fonctionnelle des Mureaux afin de tester tous les cas de vol possibles. Les cas normaux et les cas aux limites les plus improbables afin de s'assurer qu'indépendamment du codage, il se comporte comme prévu avec les vrais équipements de vol. Et cela avec chaque programme de chaque vol.

PS: Après comme tu le dis, les circonstances rencontrées sur Mars étaient peut être totalement imprévisibles. Auquel cas, en effet, c'est difficilement imputable à un acteur ou à un autre... Je compléterais en disant que le MOE designe et conçoit un matériel censé fonctionner dans un environnement déterminé. C'est le Maitre d'Ouvrage ESA qui spécifie lui, les conditions d'environnement dans laquelle la mission va se dérouler.

[Aramis]

Pour préciser je dirais que sous traiter le LN3 c'est très commun dans le spatial européen, satellites et lanceurs. Par contre la réception avec une installation de simulation fonctionnelle, c'est le job du MOE.

Tu veux dire que la source de l'erreur est autant à chercher du côté de celui qui a codé l'algorithme que de celui qui ne l'a pas détecté ? Après, J'imagine que ça dépend si c'était justement imprévisible ou pas comme conditions d'entrée.

En théorie, la réception d'un logiciel d'algorithme de cette complexité ne se limite pas à des tests ayant pour objectif de détecter d'éventuelles erreurs.
En effet,  la combinatoire empêche généralement de tester toutes les combinaisons des paramètres d'entrée de l'algorithme.
Une réception en bonne et due forme du logiciel et de sa documentation est donc également sensée comporter un contrôle du respect de l'application des standards et règles qualité applicables.

[Henri]

Au fait c'est écrit en quoi ces algo ? SPARK serait bienvenu pour la prédictibilité et la fiabilité...

[Hadéen]

Tu veux dire que la source de l'erreur est autant à chercher du côté de celui qui a codé l'algorithme que de celui qui ne l'a pas détecté ? Après, J'imagine que ça dépend si c'était justement imprévisible ou pas comme conditions d'entrée.

En théorie, la réception d'un logiciel d'algorithme de cette complexité ne se limite pas à des tests ayant pour objectif de détecter d'éventuelles erreurs.
En effet,  la combinatoire empêche généralement de tester toutes les combinaisons des paramètres d'entrée de l'algorithme.
Une réception en bonne et due forme du logiciel et de sa documentation est donc également sensée comporter un contrôle du respect de l'application des standards et règles qualité applicables.

C'est d'une rare évidence. J'essayais de souligner que le codeur vérifie et valide son logiciel en pratiquant des tests unitaires. Conformité à la spécification du MOE, et qualité du codage. (Variables, overflow, exceptions logicielles...). Le MOE lui, le teste au niveau supérieur dans un contexte plus "système".

[Astro-notes]

Je suis d'un œil de plus en plus atterré cette enquête sur le crash de Schiaparelli. L'avantage d'avoir des collègues qui trempent ou ont trempé dans le milieu qui va bien dans ces affaires spatiales me rempli certes de satisfaction de savoir qu'au FCS il y a du beau monde qui peut traiter de tous les sujets, mais si on en est pas, on est vite largué. Dans cette affaire, écarté depuis longtemps le terrible transistor soviétique dont la détestable réputation qui résolvait toutes les pannes n'est plus à utiliser, nous voilà en train de coder en SPARK (ou pas), appliquer les standards (ou mal), puis on s'enfonce, on s'enfonce nous voilà évoquant la combinatoire (voire la logique linéaire), puis plus loin encore plus loin les variables (orthographe), overflow (binaire), exceptions logicielles (fait pas ci, fait pas ça), j'attends l'arrivée de Karnaugh et ses épouvantables tableaux (autant de variable autant de tableaux) ! Et bien, je peux dire que pour le moins le "tournis" me gagne. Fini le temps où la cause était un bouchon de graisse, un morceau de chiffon qui étaient la cause du désastre, maintenant grâce au numérique on fait dans le super sophistiqué, les enquêtes s'en ressente et moi aussi.  :roll:

[Aramis]

Au fait c'est écrit en quoi ces algo ? SPARK serait bienvenu pour la prédictibilité et la fiabilité...

SPARK convient plutôt à des logiciels écrits en langage interprété comme Java ou Python, il parait donc douteux que SPARK soit mis en oeuvre pour le logiciel d'un algorithme de GNC d'une sonde spatiale.

En théorie, la réception d'un logiciel d'algorithme de cette complexité ne se limite pas à des tests ayant pour objectif de détecter d'éventuelles erreurs.
En effet,  la combinatoire empêche généralement de tester toutes les combinaisons des paramètres d'entrée de l'algorithme.
Une réception en bonne et due forme du logiciel et de sa documentation est donc également sensée comporter un contrôle du respect de l'application des standards et règles qualité applicables.

C'est d'une rare évidence. J'essayais de souligner que le codeur vérifie et valide son logiciel en pratiquant des tests unitaires. Conformité à la spécification du MOE, et qualité du codage. (Variables, overflow, exceptions logicielles...). Le MOE lui, le teste au niveau supérieur dans un contexte plus "système".

Cependant la validation complète, ou bien à 100 %, du code source du logiciel par des tests unitaires peut se révéler délicate.
Apporter la preuve de cette de cette validation par des tests unitaires peut se montrer également assez difficile.
La difficulté de cette validation du code logiciel par des tests unitaires dépend notamment du langage de codage du logiciel de l'algorithme.

En outre le site Web de GMV, http://www.gmv.com/, semble hors service : 
"Service Temporarily Unavailable"

[Invité]

En outre le site Web de GMV, http://www.gmv.com/, semble hors service : 
"Service Temporarily Unavailable"

Pas du tout, il y a juste une virgule en trop sur ton lien.

[Invité]

Je suis d'un œil de plus en plus atterré cette enquête sur le crash de Schiaparelli. L'avantage d'avoir des collègues qui trempent ou ont trempé dans le milieu qui va bien dans ces affaires spatiales me rempli certes de satisfaction de savoir qu'au FCS il y a du beau monde qui peut traiter de tous les sujets, mais si on en est pas, on est vite largué. Dans cette affaire, écarté depuis longtemps le terrible transistor soviétique dont la détestable réputation qui résolvait toutes les pannes n'est plus à utiliser, nous voilà en train de coder en SPARK (ou pas), appliquer les standards (ou mal), puis on s'enfonce, on s'enfonce nous voilà évoquant la combinatoire (voire la logique linéaire), puis plus loin encore plus loin les variables (orthographe), overflow (binaire), exceptions logicielles (fait pas ci, fait pas ça), j'attends l'arrivée de Karnaugh et ses épouvantables tableaux (autant de variable autant de tableaux) ! Et bien, je peux dire que pour le moins le "tournis" me gagne. Fini le temps où la cause était un bouchon de graisse, un morceau de chiffon qui étaient la cause du désastre, maintenant grâce au numérique on fait dans le super sophistiqué, les enquêtes s'en ressente et moi aussi.  :roll:

:megalol:

Cette lamentation argumentée est une bonne rétrospective.

[Giwa]

En ce qui me concerne, je ne suis (suivre) pas comme Astro-notes d'un œil de plus en plus atterré cette enquête  vu mes compétences proches du zéro absolu dans le langage informatique Spark qui fait des étincelles ... même si je suis quand même content de repérer une virgule en trop qui traîne à la fin de l'écriture d'un site  ! Je suis ( être) seulement atterré !
 Mais bon, positivons et je suis sûr que les enquêteurs détermineront la ou les causes et y apporteront les remèdes

[montmein69]

Le logiciel qui pilotera la plate-forme supportant le rover en 2020, sera-t'il une adaptation de celui qui a servi pour Schiaparelli, ou bien ce sera un nouveau développé par les russes ?

[Astro-notes]

juste un court HS :

/HS deb

Ah Giwa que j'aime ta candide attitude face au problème qui occupe ce fil. Quoique, vu ton age je devrais dire ta sage attitude  :sage:


/HS fin

[DeepThroat]

 Ceci expliquerait aussi l'échec de Beagle

Pour autant que l'on ait bien interprété les images de Beagle, il semble que le lander à trois sous se soit posé correctement. D'après les analyses finales c'est la phase de déploiement après atterrissage qui aurait posée soucis... Paradoxalement, Beagle est peut être moins un échec que Schiaparelli. Par contre Beagle n'envoyait aucune TM durant la descente.

[Henri]

Au fait c'est écrit en quoi ces algo ? SPARK serait bienvenu pour la prédictibilité et la fiabilité...

SPARK convient plutôt à des logiciels écrits en langage interprété comme Java ou Python, il parait donc douteux que SPARK soit mis en oeuvre pour le logiciel d'un algorithme de GNC d'une sonde spatiale.

SPARK n'est pas une simple méthodologie, c'est un sous-ensemble de Ada certifié déterministe avec introduction de contrats pour chaque élément de code.
https://en.wikipedia.org/wiki/SPARK_(programming_language)
https://www.youtube.com/watch?v=2qyAksCfdSA
http://libre.adacore.com/tools/spark-gpl-edition/

Edit : il y avait confusion avec Apache Spark qui est autre chose, d'où la différence de casse du mot SPARCK.

[yoann]

schiaparelli était-il trop léger ?

https://www.aerospatium.info/schiaparelli-etait-leger/

article réservés au abonnés, on en connait meme pas les grandes lignes... :|

[Space Opera]

Sinon les nouvelles sont (très) rares depuis une semaine. Dommage, parce qu'il est certain que l'enquête progresse. J'espère que tous les détails seront donnés, et pas juste les grandes conclusions générales.
Les conclusions devraient être rendues le 8 novembre. C'est bientôt !

[Wakka]

Images couleur obtenues par MRO du parachute et du bouclier thermique.





Et du site du crash.





http://www.esa.int/Our_Activities/Space_Science/ExoMars/Schiaparelli_crash_site_in_colour

[aRes]

Sacré feu d'artifice ça a dû être. Oh ! la belle rouge ! :D

[Blink / Pamplemousse]

Est-ce que la zone plus claire en forme d'arc de cercle dans le cratère d'impact peut être une partie de la structure de l'atterrisseur, ou c'est juste un effet d'optique ?

[yoann]

a voir tout les petites taches blanches autour (debris ?) , ça a du faire un joli boom :|

[Invité]

Entre le 25 octobre et le 1e novembre, le parachute a pas mal bougé.

[Invité]

D'après cet article de la BBC,

"The onboard computer had some problems taking data from different sources, and defining correctly the altitude; and because of that the engines were started for only three seconds which was not enough," explained Prof Jan Woerner

"When the parachute was deployed, it worked. But then some acceleration happened that we do not understand. Was it that the parachute did not deploy fully? We do not know."

Si c'est à cela auquel on aura droit demain, "on ne sait pas", on n'aura pas beaucoup fait avancer le schmilblick. :D  En tout cas il confirme que la phase parachutée n'a pas été aussi performante que prévu.

http://www.bbc.com/news/science-environment-37898565