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

DeepThroat a écrit:
En général on n'utilise pas les mesures directement mais à travers un filtre de Kalman dont le boulot est justement, entre autre, de filtrer les mesures erronées. 1s d'erreur ne suffit pas en règle générale à envoyer un Kalman aux fraises, et de plus, si il est bien fait il indique quand l'estimée est un peu trop loin de ce que l'on attend. Par ailleurs, il est de bon ton avant de déclencher une manoeuvre décisive de vérifier la vraisemblance des mesures.

Un algorithme de filtrage type kalman ou autre permet de réduire l'influence du bruit et de gérer les incertitudes. Mais en cas de saturation d'un capteur, ce n'est plus un problème de bruit, c'est toute une partie de l'information qui disparaît.
Une seconde de saturation provoque l'accumulation d'une erreur beaucoup plus importante que quelques millisecondes.

DeepThroat a écrit:
En clair si mon GNC me dit que je suis à 1500m et la seconde d'après à -20m je peux déduire qu'il y a un bug ou une sacrée accélération que l'on aurait du voir sur les accéléromètres. Si ce n'est pas le cas, on réfléchit, c'est à dire qu'on passe sur la voie redondante et si c'est toujours incohérent on passe en boucle ouverte en mesurant le temps et en utilisant un modèle de la descente. Cela pose donc des questions sur l'architecture du soft.

Avec les gyroscopes saturés, je ne vois pas bien à quelle redondance on pourrait se fier.
Le problème est vraiment dans la prise en compte de cette saturation dans le logiciel, il n'a jamais été prévu de traiter une saturation aussi longue.

DeepThroat a écrit:
Par ailleurs les explications vaseuses du test non réalisé à cause de la proximité de la Crimée me font un peu sourire. A moins que le coin de Sebastopol n'ait une furieuse ressemblance avec Mars on ne voit pas bien en quoi il était absolument nécessaire de se trouver là pour tester.

La ressemblance avec Mars n'est certainement pas le critère de choix. Par contre l’existence et la disponibilité au bon moment d'installations de tests spécifiques peuvent expliquer qu'il n'y avait pas beaucoup d'autres choix.

Pour répondre en partie à Jeep, je peux dire suite à sa remarque : Avec les gyroscopes saturés, je ne vois pas bien à quelle redondance on pourrait se fier.

Ref Argyre, il y a un chrono, et j'ai ajouté : une vitesse d'entrée en approche finale connue, une gravité connue, et au bout de tout ça un parachute qui n'est pas très regardant sur l'attitude, ; il doit bien y avoir moyen de ne pas s'exploser une fois arrivé au sol ! Bon ce ne sera peut-être pas brillant mais au moins on peut avoir un peu d'espoir.

Il y a aussi le radar Doppler.
On peut imaginer larguer le parachute au bon moment en se basant sur ces données (chrono et/ou radar Doppler).

Mais le système de moteurs-fusées est-il suffisamment stable pour l'on puisse envisager de conduire la descente sans centrale inertielle ?
J'en doute fortement.

.

hmmm, mauvais topic ?  :scratch:

shinyblade a écrit:Ce génocide amérindien est une idée parfaitement simpliste. Ne faisons pas du révsionnisme à essayer d'attribuer les méchants et les gentils. Les amérindiens était également des tueurs chevronné. L'histoire a ses secrets et ses subtilité. Quand deux civilisation se rencontre ça fait des conflits, puis des morts et ensuite les "historiens serieux" franchouillards pimentent les choses en utilisant le terme génocide, esclavage, racisme. Moi qui a été à l'école américaine, leur version de l'histoire est beaucoup plus mesuré et détaillé et beaucoup moins caricatural que la soupe méchant blanc/ gentil indien qu'on m'a servis au lycée français.

Mauvais topic c'est certain. Je pense qu'il répondait dans la "Conquête de Mars"  :megalol:  Mauvaise réponse aussi ... Un admin pour déplacer ?

Un algorithme de filtrage type kalman ou autre permet de réduire l'influence du bruit et de gérer les incertitudes. Mais en cas de saturation
d'un capteur, ce n'est plus un problème de bruit, c'est toute une partie de l'information qui disparaît.

Une seconde de saturation provoque l'accumulation d'une erreur beaucoup plus importante que quelques millisecondes.

Plus exactement un Filtre de Kalman utilise les matrices de covariance de bruit et un modèle pour délivrer l'estimation la plus probable d'un vecteur d'état. Si un capteur sature on peut se trouver en présence de deux cas: ou il s'agit d'un phénomène réel et le Kalman suivra tout en introduisant une erreur et c'est alors un problème de dimensionnement, soit c'est une erreur capteur et comme il y avait deux IMU à bord une comparaison des résultats des Kalman associés permet de détecter l'erreur. La matrice de covariance d'erreur du Kalman permet ensuite de lever le doute. Dans le cas où les erreurs restantes sont trop importantes ou que le vecteur d'état présente un comportement non physique on utilise la dernière estimée valide pour initialiser un modèle boucle ouverte qui peut d'ailleurs être celui des Kalman eux mêmes. Il est de bon ton de vérifier l'aspect réaliste des mesures/estimées avant de déclencher des actions décisives.
Pour ce qui est d'une seconde sans mesure, un Kalman bien fait ne va pas jardiner immédiatement en hors piste. A l'échelle de la mécanique spatiale c'est assez court pour être gérable. A titre d'exemple un GPS à 10 balles ne perd pas les pédales sur un trou d'une seconde. Je n'ai pas dit qu'il y avait un GPS à bord, c'est juste un exemple.
Par ailleurs il y a une ambigüité entre la saturation d'un capteur et celle d'une variable. Il semble ici que ce soit une saturation de variable qui est conduit à une interprétation de valeur négative. C'est assez étonnant, le milieu étant vacciné contre ce genre de gag depuis vol A501. Que ce soit chez Airbus ou chez TAS il est de bon ton de tester l'intervalle de validité des variables.

Avec les gyroscopes saturés, je ne vois pas bien à quelle redondance on pourrait se fier.

Le problème est vraiment dans la prise en compte de cette saturation dans le logiciel, il n'a jamais été prévu de traiter une saturation aussi longue.

Voir la discussion ci-dessus. Dans le métier il est d'usage de dire 'quand la boucle fermée déconne il est temps de l'ouvrir....'
Surtout si il reste un radar Doppler on doit pouvoir faire quelques bricoles.

La ressemblance avec Mars n'est certainement pas le critère de choix. Par contre l’existence et la disponibilité au bon moment d'installations de tests spécifiques peuvent expliquer qu'il n'y avait pas beaucoup d'autres choix.

Oh? C'est vrai? Sans rire. Pour tester un soft le lieu n'a pas grande importance. Même un soft de GPS....Qui plus est le problème ici ne semble pas le test mais la conception même du logiciel. Aucun test ne corrigera une conception défaillante. Même au voisinage de la Crimée....Même en envisageant des tests largués d'un avion, les terrains de largage ne manquent pas en Europe occidentale.

Enfin, en ce qui concerne le contrôle de la descente avec des propulseurs, il est certain que sans gyro c'est assez sportif. On peut néanmoins implémenter le scénario suivant: on donne au véhicule une forme aérodynamiquement stable qui fait que sauf perturbation il
revient dans une position à peu près connue. On connait la dissymétrie de poussée max et on peut en déduire l'angle max de déviation
à partir du temps de poussée. En effectuant des séquences assez courtes espacées d'un temps suffisant pour revenir vers la position stable on peut espérer descendre à peu près droit au prix d'une certaine dérive. Ca se gère mal en chute libre mais sous parachute ça peut se jouer. 

Bons Vols

DeepThroat a écrit:

Plus exactement un Filtre de Kalman utilise [...]
Pour ce qui est d'une seconde sans mesure, un Kalman bien fait ne va pas jardiner immédiatement en hors piste. A l'échelle de la mécanique spatiale c'est assez court pour être gérable. A titre d'exemple un GPS à 10 balles ne perd pas les pédales sur un trou d'une seconde. Je n'ai pas dit qu'il y avait un GPS à bord, c'est juste un exemple.

Merci pour les précisions.

Je connais déjà le principe d'un filtre de Kalman.

Mais l'application GPS n'est pas tout à fait la même que sur du pilotage inertiel.
Pour le GPS, l'erreur est instantané et n' plus de sens pour les mesures suivantes (à t+2).

Dans le cas de la navigation inertiel, les erreurs s'accumulent et sans moyen de recalage (comme c'est le cas sur Mars) elles finissent par entraîner des dérives significatives, voir le déraillement du calculateur qui gère le guidage...

DeepThroat a écrit:
Par ailleurs il y a une ambigüité entre la saturation d'un capteur et celle d'une variable. Il semble ici que ce soit une saturation de variable qui est conduit à une interprétation de valeur négative.

Ce n'est pas ce que j'ai pu lire.
As tu une source plus complète que celles déjà citées ici, qui sont peu précises sur les détails ?

DeepThroat a écrit:
Voir la discussion ci-dessus. Dans le métier il est d'usage de dire 'quand la boucle fermée déconne il est temps de l'ouvrir....'
Surtout si il reste un radar Doppler on doit pouvoir faire quelques bricoles.

On tourne en rond.
Un radar Doppler ne permet pas de recaler une centrale inertielle et encore moins de la remplacer.

DeepThroat a écrit:
Oh? C'est vrai? Sans rire. Pour tester un soft le lieu n'a pas grande importance. Même un soft de GPS....Qui plus est le problème ici ne semble pas le test mais la conception même du logiciel. Aucun test ne corrigera une conception défaillante. Même au voisinage de la Crimée....Même en envisageant des tests largués d'un avion, les terrains de largage ne manquent pas en Europe occidentale.

On parle évidement ici de tests dynamiques avec installations pyrotechniques et non pas de tests logiciels (vois les liens postés plus haut).
Ça n'aurait aucun sens.

DeepThroat a écrit:
Enfin, en ce qui concerne le contrôle de la descente avec des propulseurs, il est certain que sans gyro c'est assez sportif. On peut néanmoins implémenter le scénario suivant: on donne au véhicule une forme aérodynamiquement stable qui fait que sauf perturbation il
revient dans une position à peu près connue. On connait la dissymétrie de poussée max et on peut en déduire l'angle max de déviation
à partir du temps de poussée. En effectuant des séquences assez courtes espacées d'un temps suffisant pour revenir vers la position stable on peut espérer descendre à peu près droit au prix d'une certaine dérive. Ca se gère mal en chute libre mais sous parachute ça peut se jouer.

C'est en effet possible si on conçoit le véhicule de la sorte.

Était-ce le cas de Schiaparelli ?

Dans tous les cas, le vaisseau n'a pas été conçu pour ce problème, et ce problème n'avait soit pas été envisagé, soit pas corrigé.
Puisque ça a l'air un problème assez fondamental, j'imagine qu'il y en a qui doivent commencer à se faire tirer les oreilles. Après, c'est toujours le maitre d’œuvre (ici, TAS Italie) qui est l'ultime responsable de la défaillance de son module, et il est très probable que c'est à eux directement que l'ESA demande des comptes.

DeepThroat a écrit:Il est de bon ton de vérifier l'aspect réaliste des mesures/estimées avant de déclencher des actions décisives.

C'est justement ce qui me chagrine dans cette histoire (enfin dans ce que j'ai compris des communiqués officiels): on a toute une série d'actions prises prématurément sur la base d'une altitude estimée de -2km. L'aspect réaliste m'échappe.

Ramener comme le dit mic8 à déclencher des opérations de finale d'approche prévues au départ depuis la Terre plusieurs mois plus tôt avec une altitude évaluée à -2000 mètres !   8-)

Je ne veux plus en entendre parler ; c'est dramatiquement de l'incompétence peut être pire que l'affaire Beagle-2 que certains raillaient en son temps.

Mais l'application GPS n'est pas tout à fait la même que sur du pilotage inertiel.
Pour le GPS, l'erreur est instantané et n' plus de sens pour les mesures suivantes (à t+2).

 Le GPS n'est qu'un exemple. Pour info il y a des trous dans la couverture GPS qui peuvent atteindre plusieurs seconds. L'erreur n'est pas instantanée, il y a un propagateur dans le soft GPS qui utilise la vitesse et l'accélération estimée pour prédire la position et l'intégrer dans l'estimation base sur les mesures de temps issues du signal RF. Encore une fois ce n'est qu'un EXEMPLE.

Dans le cas de la navigation inertiel, les erreurs s'accumulent et sans moyen de recalage (comme c'est le cas sur Mars) elles finissent par entraîner des dérives significatives, voir le déraillement du calculateur qui gère le guidage...

Certes, mais même une IMU assez moyenne donne un precision tout à fait correcte le temps d'une descente. Il faut plusieurs heures de nav pour accumuler une erreur de quelques nautiques. Qui plus est, ici on ne cherche pas à faire de la nav mais à poser un véhicule ce qui suppose de gérer l'altitude et la vitesse et pas la position. On peut d'ailleurs soupçonner que les IMU étaient plus utilisées en attitude  (gyromètres) qu'en position (accéléros).

Ce n'est pas ce que j'ai pu lire.
As tu une source plus complète que celles déjà citées ici, qui sont peu précises sur les détails ?

Je n'ai pas note la reference de la source. Si je la retrouve je la posterai.

On tourne en rond.
Un radar Doppler ne permet pas de recaler une centrale inertielle et encore moins de la remplacer.

Si,si. En vertical le Doppler donne la position ET la vitesse. TAS fait ça très bien sur Poseidon. L'algorithme de base utilise un corrélateur pour determiner le temps de retour de l'echo (en fait c'est ce qu'on appellee de la compression d'impulsion) et l'écart en fréquence entre signal reçu et émis (Doppler) permet d'estimer la vitesse. Anecdotiquement on fait même de la trajectographie avec des mesures Doppler d'une seule station.
En gros dans une descente on pilote en position sur le signal du radar et on se sert de l'IMU pour connaître l'attitude et pousser dans la bonne direction.
Si l'IMU a des plus des acceleros on integer la mesure Radar et la mesure inertielle  dans un Kalman pour améliorer l'estimée de position. En pratique le Doppler suffit avec un petit bout de boucle ouverte en phase terminale où le Doppler sature.

On parle évidement ici de tests dynamiques avec installations pyrotechniques et non pas de tests logiciels (vois les liens postés plus haut).
Ça n'aurait aucun sens

 Ben non, ce n'est pas si évident. Et quand bien même, les pyros explosent tout aussi bien près de la Crimée que dans le Larzac. Mais si tu en sais plus sur ces tests éclaire nous. Ceci dit, faire détonner les pyros renseigne assez peu sur la robustesse du soft.

Bons Vols

L'échange Jeep et DeepThroat a été/est intéressant à suivre.  :up8:

Je serais curieux de connaître la méthode de conception et le langage de codage du logiciel.

C'est du pur binaire, arrangé en octets, codé sur une base hexadécimale.... Non je plaisante Aramis et  :iout:

DeepThroat a écrit:

 Le GPS n'est qu'un exemple. Pour info il y a des trous dans la couverture GPS qui peuvent atteindre plusieurs seconds. L'erreur n'est pas instantanée, il y a un propagateur dans le soft GPS qui utilise la vitesse et l'accélération estimée pour prédire la position et l'intégrer dans l'estimation base sur les mesures de temps issues du signal RF. Encore une fois ce n'est qu'un EXEMPLE.

J'ai bien compris.
Je souligne simplement le fais que, dans le cas du GPS, une fois le signal récupéré, il permet de se recaler en position. Les erreurs ne s'accumulent pas dans le temps.

Dans le cas d'une centrale inertielle, on récupère des accélérations et il faut intégrer 2 fois pour en déduire la vitesse puis la position / l'attitude. En l’absence de moyen de recalage, l'erreur ne peut que s’accumuler.

L'exemple du GPS ne permet pas une analogie satisfaisante.

DeepThroat a écrit:
Certes, mais même une IMU assez moyenne donne un precision tout à fait correcte le temps d'une descente. Il faut plusieurs heures de nav pour accumuler une erreur de quelques nautiques.

Une centrale inertielle donne une précision satisfaisant dans un cas nominal, c'est à-dire-sans saturation prolongée des capteurs.
Visiblement, ce n'est pas le cas dans cette histoire. Mais attendons le rapport complet pour en être sûr.

DeepThroat a écrit:
Qui plus est, ici on ne cherche pas à faire de la nav mais à poser un véhicule ce qui suppose de gérer l'altitude et la vitesse et pas la position. On peut d'ailleurs soupçonner que les IMU étaient plus utilisées en attitude  (gyromètres) qu'en position (accéléros).

J'ai assimilé, peut-être à tord, la phase de descente propulsée à de la navigation.
Mais il est vrai que c'est l'attitude du véhicule qui est pilotée avant tout.
Cependant l'altitude et la vitesse sont bien pris en comte pour l'allumage et l'extinction des rétro-fusées.

Mais navigation ou pas, si l'on perd la référence en attitude à cause d'une mesure sur un gyro qui sature, impossible de piloter correctement le véhicule s'il n'a pas été conçu pour retrouver seul (de façon passive) une position de référence.

DeepThroat a écrit:
Si,si. En vertical le Doppler donne la position ET la vitesse. TAS fait ça très bien sur Poseidon. [...]
En gros dans une descente on pilote en position sur le signal du radar et on se sert de l'IMU pour connaître l'attitude et pousser dans la bonne direction.
Si l'IMU a des plus des acceleros on integer la mesure Radar et la mesure inertielle  dans un Kalman pour améliorer l'estimée de position. En pratique le Doppler suffit avec un petit bout de boucle ouverte en phase terminale où le Doppler sature.

Oui, mais le radar ne donne pas l'attitude,  et c'est indispensable si le véhicule n'a pas été conçu de façon suffisamment stable comme tu le suggérais précédemment.

De plus, peut-on vraiment déduire l'altitude et la vitesse du véhicule grâce au Doppler seul si on ne connaît pas  l'attitude réelle du véhicule (et donc si l'on ignore l'inclinaison des émission radar) ?
On peut imaginer des dispositifs qui en sont capable, mais est-ce que le radar de Schiaparelli a été conçu de la sorte ?

DeepThroat a écrit:
 Ben non, ce n'est pas si évident. Et quand bien même, les pyros explosent tout aussi bien près de la Crimée que dans le Larzac. Mais si tu en sais plus sur ces tests éclaire nous. Ceci dit, faire détonner les pyros renseigne assez peu sur la robustesse du soft.

Je ne sais rien de plus que ce qui était expliqués dans les liens postés à la page précédente par Nicolai39.
L’absence de ces tests n'excuse pas le manque de robustesse du logiciel.
Cependant, si des tests dynamiques avaient pu mettre en évidences des accélérations supérieures à ce qui était prévu, voir à une saturation des centrales inertielles si un hardware identique est utilisé pour les essais, ces données auraient été intégrées aux simulationx et le défaut du logiciel détecté.

Mais ce n'est que pure spéculation, et de toute façon ça n'excuse pas la faute de conception logiciel.
Seule le rapport final permettra de faire la part des choses.

nikolai39 a écrit:L'ASI accuse Arca Space, société roumaine qui était en charge des essais de l'EDL, de ne pas avoir conduit les essais comme il se devait.

http://www.romaniajournal.ro/esa-releases-preliminary-results-in-exomars-schiaparelli-crash-landing-after-italy-accused-romanian-corporation/

Arca Space rétorque que les essais devaient avoir lieu près de la frontière avec la Crimée, ce qui a généré des tensions.

Ici, on voit la petite fusée pour les essais d'ExoMars :

http://www.arcaspace.com/en/exomars.htm

Roscosmos publie un communiqué qui cite le DG de l'ESA disant que la partie russe n'a rien à se reprocher :

http://www.roscosmos.ru/22969/

Jeep a écrit:De plus, peut-on vraiment déduire l'altitude et la vitesse du véhicule grâce au Doppler seul si on ne connaît pas  l'attitude réelle du véhicule (et donc si l'on ignore l'inclinaison des émission radar) ?
On peut imaginer des dispositifs qui en sont capable, mais est-ce que le radar de Schiaparelli a été conçu de la sorte ?

Le radar était multi-faisceau, donc avec des hypothèses de sol plat on peut réussir à avoir une vague idée de l'orientation du vaisseau j'imagine.

Moi je ne l'ai pas utilisé, mais certains hélicoptères de combat disposaient expérimentalement d'un système de navigation (Thomson à l'époque) basé sur un radar a effet Doppler avec 3 faisceaux à 120° qui permettait sur un sol assez plat de fournir vitesse et direction et et par intégration la position, évidemment sans recalage comme pour les gyroscopes aux quels de ce fait je ne faisait qu'une confiance limitée en fonction du temps.

Merci Space Opera et Astro-notes pour ces précisions.

Mais navigation ou pas, si l'on perd la référence en attitude à cause d'une mesure sur un gyro qui sature, impossible de piloter correctement le véhicule s'il n'a pas été conçu pour retrouver seul (de façon passive) une position de référence. 

Dans ce cas la, il faut effectivement prévoir un senseur d'horizon ou un pendule amorti qui donne une verticale locale approximative. On peut aussi faire des petites poussées et piloter sur l'altitude donnée par le radar. Bien sur, si on est sur le dos, c'est plus compliqué....

De plus, peut-on vraiment déduire l'altitude et la vitesse du véhicule grâce au Doppler seul si on ne connaît pas  l'attitude réelle du véhicule (et donc si l'on ignore l'inclinaison des émission radar) ? 

Il y a deux façons de faire pour résoudre cette question, on peut, et c'est conseillé, faire du multi faisceaux comme déjà mentionné (on peut même dans ce cas faire de l'interférentiel entre faisceaux pour améliorer la précision) On peut aussi utiliser toute la série de mesures position/vitesse pour restituer la trajectoire mais c'est un calcul relativement lourd. Par ailleurs, sans faire très compliqué on peut aussi moyenner la mesure pour approximer la hauteur puisque une perturbation se traduit par un mouvement périodique amorti (on l'espère du moins...). En fait si on a un mouvement de rotation du porteur sur un axe non vertical on mesure en plus de l'altitude une composante périodique que l'on peut filtrer pour estimer l'altitude.

Quoi qu'il en soit, si on revient aux fondamentaux, la bonne stratégie après une mesure incohérente n'est pas de tout faire péter à l'arrache mais de de prendre la dernière mesure valide et piloter sur les infos qui restent voire en boucle ouverte pure (au chrono).

Moi j'appelle ça de la prédiction linéaire, comme le dit DeepThroat, si cela devient incohérent du point de vue mesure, dans le cas d'espèce il est peu probable qu'une perturbation renvoie la sonde vers l'espace, donc on peu, hors mesure, jouer du chrono et de la gravité pour prédire la une hauteur, c'est le moindre des maux et si cela ne sauve pas la sonde qu'est-ce qui aurait pu le faire ?

DeepThroat a écrit:

Quoi qu'il en soit, si on revient aux fondamentaux, la bonne stratégie après une mesure incohérente n'est pas de tout faire péter à l'arrache mais de de prendre la dernière mesure valide et piloter sur les infos qui restent voire en boucle ouverte pure (au chrono).

J'aimerais bien savoir quels étaient les modes dégradés prévu sur Schiaparelli en fonction des divers défaillances possibles.
C'est toujours rageant de voir un échec à cause d'un problème de conception logiciel.

Attendons avant de crier à l'erreur de conception. La conception (technique) est issue d'une spécification (fonctionnelle) qui est elle même rédigée pour répondre à un cahier des charges. Il y a donc un paquet d'étapes qui ont pu être traitées un peu légèrement avant la conception.

Autant nous pouvons être satisfait de l'insertion de TGO en orbite martienne, et ravis de savoir un des instruments donner de bonnes informations : CaSSIS, et donc espérer un bon service de cette partie de la sonde et autant pour ma part, je comprends que l'on analyse l'échec de l'EDL, mais que l'on en soit à diluer les responsabilités comme si certain voulaient dédouaner l'ESA, mais à mon avis c'est un échec de l'ESA ; après, savoir si c'est la faute des Russes qui ont repris à l'Ukraine la Crimée c'est AMHA de la diversion. Je ne sais d'ailleurs pas si l'ESA est idéologiquement assez souple a reconnaître son incompétence dans ce segment du programme, mais en tous cas c'est comme ça que je la vois. Je vous rappelle que le mot incompétence s'emploie par exemple en justice lorsqu'un tribunal n'arrive pas à démêler une affaire et que la Cour se déclare incompétente et passe l'affaire à l'échelon supérieur ; ici on attend une communication intelligente dans cette affaire et on entend tout et le contraire de tout.  :lolnasa:

Des tests, des tests, encore des tests. Il n'y a qu'en simulant toutes les situations possibles et imaginables que le problème logiciel aurait pu être détecté.
Lorsqu'on voit les cosmonautes répéter pendant des centaines d'heures tous les scénarios possible, ça paie, le transport humain est très sûr.
Simuler un descente avec à chaque fois un ou plusieurs capteur qui tombent en panne ou bug, c'était au logiciel de détecter l'incohérence et de passer sur un mode alternatif.

Manque de temps ? de budget ? erreur humaine ? problème de communication entre les équipes ?

Ce n'est pas l'ESA qui est garante du succès de la mission, c'est le maître d'oeuvre, TAS Italie. S'il y a une seule entité responsable légalement et contractuellement, c'est eux.