skip to main | skip to sidebar
23 commenti

Cos’è successo realmente a Schiaparelli? La spiegazione dell’ESA

Quando ho scritto questo articolo nel quale riferivo le prime informazioni non ufficiali sulle cause dello schianto su Marte della sonda Schiaparelli ci sono state un po' di polemiche e di reazioni incredule nei commenti. Adesso è uscita la spiegazione ufficiale dell’ESA, che a pagina 12 del PDF EXOMARS 2016 - Schiaparelli Anomaly Inquiry (linkato in fondo alla pagina) riporta questa frase:

Because of the error in the estimated attitude that occurred at parachute inflation, the GNC Software projected the RDA range measurements with an erroneous off-vertical angle and deduced a negative altitude (cosinus of angles > 90 degrees are negative). There was no check on board of the plausibility of this altitude calculation

Che è quello che avevo scritto.

Invia un commento
I commenti non appaiono subito, devono essere tutti approvati da un moderatore. Lo so, è scomodo, ma è necessario per tenere lontani scocciatori, spammer, troll e stupidi: siate civili e verrete pubblicati qualunque sia la vostra opinione; gli incivili di qualsiasi orientamento non verranno pubblicati, se non per mostrare il loro squallore.
Inviando un commento date il vostro consenso alla sua pubblicazione, qui o altrove.
Maggiori informazioni riguardanti regole e utilizzo dei commenti sono reperibili nella sezione apposita.
NOTA BENE. L'area sottostante per l'invio dei commenti non è contenuta in questa pagina ma è un iframe, cioè una finestra su una pagina di Blogger esterna a questo blog. Ciò significa che dovete assicurarvi che non venga bloccata da estensioni del vostro browser (tipo quelle che eliminano le pubblicità) e/o da altri programmi di protezione antimalware (tipo Kaspersky). Inoltre è necessario che sia permesso accettare i cookie da terze parti (informativa sulla privacy a riguardo).
Commenti
Commenti (23)
Bene (si fa per dire). Se quella è la spiegazione ufficiale, allora chi ha scritto il software deve essere subito lapidato in una pubblica piazza!
Alle medie inferiori ci insegnano che il coseno di un angolo maggiore di 90° e minore di 270° è negativo; il tizio dell'ESA non ha previsto che in caso di inclinazione anomala della sonda sarebbe venuto fuori un coseno negativo?
Non penso di aver mai dubitato di te e del tuo "pensiero" a riguardo specifico di Schiaparelli... In ogni caso bene così.
Domanda ignorante...non hanno messo un radar altimetro per qualche motivo che non conosco immagino...si sa quale? Pura curiosità...
Lo dico sempre ai colleghi: controllate il cavolo di codice e poi fate (e fate fare anche ad altri) i test. Pensavo che almeno all'ESA fosse cosa scontata, e invece...
Questi "errori" mi ricordano sempre come si ragiona in ambiente RT con risorse limitate:

"I was once working with a
customer who was producing on-board software for a missile. In my analysis
of the code, I pointed out that they had a number of problems with storage
leaks. Imagine my surprise when the customers chief software engineer said
"Of course it leaks". He went on to point out that they had calculated the
amount of memory the application would leak in the total possible flight time
for the missile and then doubled that number. They added this much
additional memory to the hardware to "support" the leaks. Since the missile
will explode when it hits it's target or at the end of it's flight, the
ultimate in garbage collection is performed without programmer intervention"
...e se l'unica forma di vita su Marte fosse rimasta schiacciata da Schiaparelli?
A parte gli scherzi, la missione, come detto più volte, non è stato un'insuccesso. Comunque sono stati raccolti dati utili. Questi errori o imprevisti del genere ci riportano con i piedi per terra: tali missioni non sono semplici e un minimo errore può costare caro. Ammiro tali persone che lavorano sodo sempre al limite.
Pag.20
"The too long persistence of the saturation flag in the application software of the IMU, was the fundamental cause of the Schiaparelli landing mishap. This ambiguity was not identified, nor measured during acceptance of the unit and the saturation behaviour of the IMU was never tested after delivery.
The mathematical model of the IMU used for simulations was established by the prime contractor. It is the SIB opinion that such intricate model is better established by the equipment supplier and must in all cases be formally validated by the supplier."

A quanto ho capito la causa principale è stata il fatto che la saturazione dell'IMU non è stata prevista perché il modello matematico usato non era sufficiente. Da cui tutto il resto.

Ciò è ribadito più avanti a pag.21

" it is evident from the analysis performed by the SIB members, that the prediction from the multi-body simulations did not provide a realistic behaviour of the parachute deployment phase. A robust approach with large margins should have been implemented on the basis of a Worst Case and Robustness analyses."

E quindi nelle conclusioni, a pag.28
"Insufficient uncertainty and configuration management in the modelling of the parachute
dynamics which led to expect much lower dynamics than observed in flight;
- Inadequate persistence time of the IMU saturation flag and inadequate handling of IMU saturation by the GNC;
- Insufficient approach to Failure Detection, Isolation and Recovery and design robustness (qui sta l'errore del mancato controllo dell'altitudine negativa);
- Mishap in management of subcontractors and acceptance of hardware."
"The Touch Down occurred at 14:47:28 corresponding to the crash of the surface platform on the surface of Mars at an estimated velocity of ≈150 m/s. The expected landing time was 14:48:05 (some 37s later)."

Quindi - se non erro - ≈540Km/h, una bella botta :)
"Attitude" o "altitude"? Errore dell'ESA, non tuo ;)
Rob
Perché errore? Attitude significa, in questo caso, assetto. Assetto della navicella durante la discesa.
> Domanda ignorante...non hanno messo un radar altimetro per qualche motivo che non conosco immagino...si sa quale? Pura curiosità...

Certo che c'era il radar, e ha funzionato correttamente. Solo che lui misura la distanza dal suolo rispetto al fondo del lander, e per calcolare l'altezza reale si divideva quel valore per il coseno dell'angolo altrimenti veniva una sovrastima sistematica.
Il problema assurdo è stato non gestire nessuna eccezione relativa al calcolo dell'angolo prima di arrivare a concludere con l'operazione stupidissima:
IF altitudine < 5 m THEN "spegni i retrorazzi"
-3700 < +5 VERO

Il problema non è in questo if ma nei calcoli a monte fatti coi piedi o non fatti per niente.
Analizziamo più a fondo: primo, un numero negativo sull'altezza non deve uscire in nessun modo, secondo anche se esce dovrebbe saltare fuori qualche tipo di allarme e non essere preso per buono, terzo se la capsula si fosse capovolta davvero allora il radar avrebbe puntato in cielo e quindi non avrebbe fornito nessuna misura (quindi bisognava gestire un errore diverso, ed è logico che nemmeno questo caso sia stato previsto), quarto se invece la misura del radar c'è vuol dire che non è capovolto e allora se esce un angolo maggiore di 90° ci dovrebbe essere un controllo di coerenza tra i dati e un altro allarme.
Insomma se si è arrivati al punto di fare l'operazione -3700<5 e prenderla per buona vuol dire che non si tratta di un solo bug ma che è stata tralasciata un'intera serie di controlli fondamentali.

Io di lavoro faccio il programmatore e so bene quanto sia difficile prevedere ed evitare i bug, e che anche in produzione salti sempre fuori qualche caso non emerso prima nei test, ma qui non si tratta di semplici buchi bensì di totali omissioni di un'intera serie di controlli logici e doverosi.

> Se quella è la spiegazione ufficiale, allora chi ha scritto il software deve essere subito lapidato in una pubblica piazza!

la loro pelle sarà diventata la poltrona del megadirettore, sicuro.
non necessariamente chi ha scritto il software farà parte dell'arredamento del "capo". E' possibile che in questo caso il programmatore sia stato vincolato da un "envelope" di parametri fissati da altri. Magari ha pure fatto notare la cosa, ma l'obiezione non è stata accettata. Bisogna notare infatti che il software che non c'è non può essere sbagliato. Quello che c'è introduce le sue possibilità di errore. Una cosa del genere non è una riga in più ma TANTE. Un check può causare l'overload di una variabile (vedi primo lancio di Ariane e il suo arcinoto catastrofico errore).

Il software migliore è il più semplice possibile. E' quel "possibile" che può risultare inadeguato.

Possiamo immaginare, insomma, che dietro a queste righe di software ci siano infiniti documenti, report, test, discussioni, meeting, telefonate, email, PDR, CDR, etc...

Non dico che non sia necessariamente colpevole ANCHE il programmatore. Dico che non lo sappiamo e che a me sembra più un'epic failure del management della sonda più che del programmatore o del team di programmatore.

Notare i forse, probabilmente, etc. che ho distribuito in questo post. Le mie sono ipotesi, sebbene derivanti da una certa esperienza in sistemi analoghi sebbene non "mission critical". L'engineering dei progetti complessi e innovativi è fatto così: a posteriori si scopre sempre l'imprevisto. Il problema di queste cose è che un test complessivo non è possibile prima di mettere in campo l'hardware.
> E' possibile che in questo caso il programmatore sia stato vincolato da un "envelope" di parametri fissati da altri. Magari ha pure fatto notare la cosa, ma l'obiezione non è stata accettata.

Può darsi ma, se fosse così, perché ci hanno messo mesi per capire la causa dell'errore e non è venuto fuori nessuno subito a dire "io avevo detto che bisognava mettere dei controlli in più sulla coerenza dei dati ma non mi hanno ascoltato, il budget non lo consentiva eccetera"?

> Bisogna notare infatti che il software che non c'è non può essere sbagliato.

Obiezione molto debole a mio modesto parere. Non si tratta di un software che non c'è, ma di una PARTE di software, per cui se manca una parte importante allora il software complessivo è sbagliato.
È vero che anche mettendo i controlli aggiuntivi puoi sempre avere dei bug, ma col tuo ragionamento per evitare un rischio potenziale fai un errore certo! ;)

Riguardiamo meglio i casi che si possono verificare:
- il radar restituisce un numero e l'IMU restituisce un angolo <90°. Verosimilmente OK
- il radar misura "infinito" e l'angolo è >90°. Probabilmente sono capovolto davvero e devo andare in allarme
- il radar misura tot km e l'angolo è > 90° oppure l'angolo è < 90° ma il radar non mi dà un numero valido.

Bene, è vero o no che nel terzo caso i dati sono incoerenti per cui è matematicamente certo che non possano essere entrambi veri e almeno uno dei due strumenti sia inceppato?

E ci sono anche altri parametri che si possono incrociare, come il tempo e la velocità: se è previsto che la discesa duri 6 minuti, dopo 4 minuti sono a 3 km di altezza, e fino a lì pare tutto regolare, se dopo due secondi viene fuori un numero per cui sembra che sia improvvisamente atterrato, come si fa a prendere anche quel dato per buono?
Magari c'era lo stesso poco da fare e precipitava comunque, ma non provare nemmeno a gestire *nessuna* di queste eccezioni mi sembra una grande mancanza difficile da giustificare.
Mars4ever,

perché ci hanno messo mesi per capire la causa dell'errore

Ehm... a dire il vero l'errore è stato capito praticamente subito, tant'è vero che ho scritto l'articolo originale che riportava le prime informazioni non ufficiali pochi giorni dopo l'incidente.

Ma comunque un'indagine approfondita, in campi come questi, richiede mesi perché bisogna esaminare anche altre piste e cercare anche eventuali altri problemi che possono essere stati mascherati dall'errore più grande.
Hai ragione, non ricordavo la data di quando avevi dato l'anteprima ufficiosa.

> bisogna esaminare anche altre piste e cercare anche eventuali altri problemi che possono essere stati mascherati dall'errore più grande

Corretto, infatti l'analisi è interessante perché il tilt a livello hardware dell'IMU era difficile da prevedere e simulare, ma il risultato finale è frutto combinato dell'errore madre di non avere previsto il caso in cui la sonda si capovolgesse sul serio. Gestendo quello, il sensore avrebbe fornito dati sbagliati ugualmente ma non sarebbe mai uscita l'altitudine negativa. Non ho letto tutto e non so se abbiano dato importanza a questo nesso.

Ora forza rover 2020! :)
Paolo "richiede mesi perché bisogna esaminare anche altre piste e cercare anche eventuali altri problemi che possono essere stati mascherati dall'errore più grande."

Per esempio un RUD a T=T0 maschererà tutti gli errori a T>T0...
La prudente (per ovvie ragioni) spiegazione ufficiale non è affatto quella pubblicata in questo articolo.

Tutti possono leggerla scaricandola da qui:

http://exploration.esa.int/mars/59176-exomars-2016-schiaparelli-anomaly-inquiry/#

Ovviamente non mi resta che confermare quanto già ampiamente esposto in passato, con buona pace di chi non ha "orecchi" per intendere (oppure fa finta di non intendere, da buon adulatore).

Len R.,

La prudente (per ovvie ragioni) spiegazione ufficiale non è affatto quella pubblicata in questo articolo.

Tutti possono leggerla scaricandola da qui:


Ehm, il tuo link è esattamente uguale al link che ho pubblicato io qui. Forse non ti sei capito.
Caro Attivissimo,

per "questo articolo" intendevo il tuo.

Chi ha interesse - oltre che capacità di comprensione - può leggersi la fonte che tu stesso hai riportato e che io, volutamente, ho di nuovo evidenziato senza estrapolare quelle poche righe da te citate e che, sempre nel tuo articolo, sembrano quasi essere il fulcro (o meglio, un riassunto) dell'intera relazione.

L'estratto che tu hai inserito, in altre parole, non descrive la causa del fallimento di Schiaparelli.

Non è tuttavia mia intenzione infierire. Chi ha interesse può semplicemente leggere e, se dotato, capire.
Len R.,

Complimenti.

Davvero.

Una cantonata colossale. Difficile fare di meglio.

Firmato: un tuo grande adulatore e ammiratore. Quasi fan, direi.
@Len R.
La prudente (per ovvie ragioni) spiegazione ufficiale non è affatto quella pubblicata in questo articolo.

Ti riferisci all'ipotesi sulla densità dell'aria di Marte molto maggiore di quanto previsto?

A me sembra che nel rapporto si parli di forze in gioco dovute alla meccanica dei fluidi: quando si supera la velocità del suono è facile incorrere in sorprese perché l'aria (meglio, ogni fluido) si comporta in modo completamente diverso.

Ma anche se fosse come pensi tu non capisco perché dovrebbero tenere nascosta una scoperta del genere.

Aggiungo che ci sono stati anche atterraggi che hanno avuto successo.
Se si trattasse davvero di differenze di pressione a livello di ordini di grandezza, nessun oggetto avrebbe potuto atterrare restando intero
@ Stupidocane:

"Estrema temerità mi è parsa sempre quella di coloro che voglion far la capacità umana misura di quanto possa e sappia operar la natura, dove che, all’incontro, e’ non è effetto alcuno in natura, per minimo che e’ sia, all’intera cognizion del quale possano arrivare i piú specolativi ingegni. Questa cosí vana prosunzione d’intendere il tutto non può aver principio da altro che dal non avere inteso mai nulla, perché, quando altri avesse esperimentato una volta sola a intender perfettamente una sola cosa ed avesse gustato veramente come è fatto il sapere, conoscerebbe come dell’infinità dell’altre conclusioni niuna ne intende".

---------------

Ecco, tu "niuna ne intendi", Stupidocane.

PS: ti ho già fatto i complimenti per il nick, vero?
Len R.,

Ecco, tu "niuna ne intendi", Stupidocane.

Chiedo a te, invece, di intenderne una: piantala di cercare il battibecco e non cercare di fare il figo facendo citazioni tanto chilometriche quanto pallose. Grazie.