La NASA analizza a fondo le anomalie del primo volo cargo di Dragon

expedition-33-34

#1

#2

Questa notizia sull’elettronica commerciale é molto interessante.
Se ho capito bene, al posto di utilizzare dell’elettronica custom resistente alle radiazioni, dal costo elevatissimo e dalle prestazioni basse, SpaceX ha scelto di utilizzare un’elettronica commerciale dove il singolo componente in avaria viene immediatamente resettato e riavviato senza creare problemi perché é ridondante; e poiché l’avaria simultanea di tutti i circuiti paralleli é molto improbabile, il sistema risulta affidabile.

La scelta potrebbe non essere tecnicamente sbagliata.


#3

Tutti piccoli malfunzionamenti, ma tutti meritevoli di approfondimento. L’infiltrazione di acqua marina che potrebbe aver compromesso i sistemi elettrici di GLACIER mi sembra una cosa che vada compresa e risolta, mentre per quanto riguarda l’approccio tecnico alle componenti elettroniche, l’impiego di componenti “standard” può anche considerarsi una via accettabile, seppur non molto elegante.

Bisogna capire fino a che punto la ridondanza può supplire agli inevitabili failure…mi viene anche da pensare se forse proprio questa scelta tecnica possa aver causato i problemi legati al software che avevano ritardato il lancio dimostrativo di Dragon verso la ISS…se non sbaglio si parlava di migliorare l’efficienza dei sistemi ridondanti, ma francamente non ricordo esattamente.

Sta di fatto che l’idea di non usare hardware radiation-proof mi sembra un po’ strana soprattutto in virtù della arcinota volontà di SpaceX di sviluppare la capsula manned sulla falsariga della cargo attuale: dubito che per la manned saranno tollerate elettroniche potenzialmente poco affidabili, e mi chiedo se non sarebbe stato più comodo iniziare da subito con sistemi a prova di radiazione così da sfruttare, anche in questo caso, la Dragon Cargo come “banco di prova”.

D’altronde non escludo che SpaceX, per ragioni puramente economiche, non intenda posticipare l’introduzione di elettroniche più costose fino al momento in cui non saranno certi di poter riutilizzare le capsule…se devo essere sincero comunque sono sorpreso che sia sufficiente abbondare con la ridondanza per poter utilizzare tranquillamente elettroniche commerciali anche nello spazio


#4

Come è costituite l’elettronica resistente alle radiazioni? Ha qualche protezione, schermatura o altro?


#5

Può essere interessante dove il consumo di energia non è un problema, come su un lanciatore, e se la possibilità di un triple event è piccola, dato il limitato tempo di utilizzo. Su un satellite la cosa diventa ben più problematica.

@topopesto: si usano particolari geometrie di celle nel silicio, e si fanno circuiti ridondanti e a votazione di maggioranza su piccola scala (a livello di gate). Questo complica paurosamente il progetto. Le schermature servono a poco, perchè una particella energetica non solo passa lo schermo, ma se impatta nello schermo crea sciami di particelle secondarie altrettando dannose, amplificando il problema. Gli schermi efficaci sarebbero di metri d’acqua o decine di cm di piombo, vedi problema di spedire qualcuno su Marte.


#6

Credo che il fallimento di Phobos-Grunt sia stato dovuto proprio a questo diverso approccio… E’ ovvio che l’idea di utilizzare elettronica commerciale in campo aerospaziale sta girando da tempo e a vari livelli, forse si tratta solo di affinare il tutto con un adeguato software, e (ipotizzo) con reset automatici e rapidi. Mi viene in mente anche il protocollo TCP-IP: non tutti i pacchetti-dati arrivano a destinazione, però c’é un algoritmo di controllo e ripetizione così la rete funziona ed é anche a prova di bomba nucleare.


#7

Fobos-Grunt è fallita per mancanza di testing, non per problemi di HW, almeno così pare dalle simulazioni. Il calcolatore di F-G era space-rated, ma sottodimensionato per la complessità della sonda. Vedi http://www.forumastronautico.it/index.php?topic=17122.0


#8

Grazie per la spiegazione!


#9

Già. Inoltre la bassa durata riduce la probabilità di essere in orbita durante un SPE…

Per far un paragone, anche i computer vitali di Destiny sono doppiamente ridondati (e Destiny puo funzionare fully nominal con uno solo dei tre), e nonostante ciò sono costruiti con elettronica resistente alle radiazioni. Poi ovviamente la scelta non dipende solo dalla durata della missione, ma anche dall’importanza del modulo, o meglio, dall’effetto che avrebbe su tutta la ISS un crash di tutti e 3 i computers contemporaneamente.

Grazie mille per la spiegazione, sei una risorsa infinita :slight_smile:
Per dare un’idea della frequenza delle anomalie, i lapotps sulla ISS (che credo siano hardware commerciale) si piantano circa una volta ogni 3 settimane per colpa delle radiazioni


#10

Ma figurati! E’ solo che queste cose mi piacciono :wink:

E mi sembra un tempo molto lungo. C’è da dire che in un PC molte parti (memoria, periferici) normalmente “dormono” o comunque fanno poco; e che non tutti i SEU (Single Event Upset, cioè un bit che cambia stato e poi ritorna spontaneamente dov’era a causa di una particella passata di lì che ha depositato una carica) causano un system crash. Per fortuna. Il caso peggiore sono i latchup, cioè gli eventi dove tutti e due i transistor di uscita di una porta vanno in conduzione simultaneamente, cosa che può portare alla distruzione della porta logica stessa. Ma per fortuna sono più rari. Quando al Polito abbiamo progettato l’elettronica per il nanosatellite modulare Aramis, una delle preoccupazioni è stata lo sviluppo di un sistema HW/SW resistente ai SEU ed un sistema di protezione automatica che toglie alimentazione ai chip colpiti da un latchup. Tutte cose relativamente semplici da fare, se si progetta un HW ad hoc. In quel progetto ho acquisito un sacco di know-how, molto interessante.


#11

Uhm sicuro che 2 su 3 volte non sia per windows? :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye: :stuck_out_tongue_winking_eye:


#12

Basta che la cosa si verifichi non con un singolo evento ma due eventi successivi. E questo sarebbe il motivo percui il crash avviene “solo” ogni 2-4 settimane, perchè è il tempo che ci vuole per cui i vari single event upset, che da soli fanno poco, sommati uno all’altro facciano un danno tale da crashare il sistema.

Per molti laptops il sistema operativo è unix :wink: