Il punto sulle indagini su SpaceShipTwo

Il rapporto del NTSB sarà pubblico?

Cosa fa esattamente il comando di sblocco eseguito dal copilota? Si limita a togliere una sicura o lascia direttamente libero di muoversi il sistema di feathering?

Sì, verrà pubblicato sulla pagina usata fino ora per gli aggiornamenti ufficiali.

Penso proprio che stabilire il comportamento del meccanismo (previsto ed effettivo) sarà proprio uno dei punti su cui si soffermerà l’indagine.

Non riesco ad immaginare che sia giusta la seconda, in un funzionamento nominale (come dite voi ingegneri… :nerd:)

Premetto che non so come funzioni la “sicurezza” di SpaceShipTwo, parlo solo per analogie con i sistemi spaziali che conosco.
Quando un’azione è particolarmente pericolosa (ne abbiamo parlato un po’ all’Astronauticon), si deve garantire che quella cosa non succeda con un certo numero di “inhibit”, in modo che il sistema sia tollerante a un certo numero di anomalie. E con anomalie si intendono problemi tecnici ma anche errori umani.
E se il design è fatto bene, gli inhibit devono essere totalmente indipendenti uno dall’altro. Ovvero devono essere fatti in modo che nessuna singola azione o nessun singolo problema tecnico o di progettazione possa eliminare due inhibit in un colpo solo.

In questo caso ad esempio, se l’evento pericoloso è l’assetto a bandiera, io immagino un comando che aziona l’assetto e un altro comando che fisicamente chiude il circuito attraverso cui passa il segnale del primo comando. In modo che se il comando di sblocco non viene dato, mandare l’altro comando è inutile perchè il circuito elettrico e fisicamente interrotto.

Detto questo, quello che mi suona strano è che il co-pilota abbia deciso di mandare il comando di sblocco mentre erano sotto Mach 1 (come sembra sia evidente dal video interno) se le procedure chiedono di farlo dopo che si passa Mach 1.4. Mi sembra davvero strano come “errore umano”.
Perché il co-pilota dovrebbe decidere di accelerare i tempi se non è previsto dalle procedure? Perché dovrebbe anticipare uno step di una procedura? E non ha mai fatto la stessa cosa durante una simulazione a terra o durante la validazione delle procedure (che presumo facciano prima di ogni volo)?
Mi viene da pensare che abbiano fatto la stessa cosa senza avere problemi in qualche simulazione o validazione e quindi abbiano consciamente deciso di rifarlo anche in volo…

da quello che ho capito, farlo al momento in cui lo SS2 viaggiava intorno Mach 1.0 era un rischio enorme, le forze che si scatenano sulle superfici alari in quel regime di moto sono grandissime e imprevedibili e, “probabilmente” (marco non mi cazziare, è vero che un ingegnere deve fornire le proprie valutazioni su dati certi ma speculare su cose anche conosciute parzialmente fa parte della natura umana), sono state anche la causa dell’incidente.

continuando con le speculazioni e detto che mi sembra anche strano che venga tolto lo sblocco a Mach 1,4 (lo SS2 continua ad accelerare fino a circa Mach 3,5 prima di spegnere i motori nel profilo di volo standard) può essere stato qualsiasi cosa, una checklist sbagliata, una indicazione della strumentazione errata, una comunicazione inviata da terra errata, o la cattiva interpretazione della checklist o della strumentazione o di una eventuale comunicazione da terra da parte dell’equipaggio.

l’unica spiegazione che mi sono dato, per lo sblocco in notevole anticipo rispetto al comando di attuazione del feather, è che in caso di abort della missione il meccanismo sarebbe così subito attuabile

Oppure avevano una lettura errata della velocità e pensavano di essere già a Mach 1.4?

Già me lo sono chiesto anch’io. E forse la tua spiegazione è anche plausibile.
Infatti, quello che non viene sottolineato nei vari commenti e spiegazioni che si leggono in giro è proprio questo: la cosiddetta “sicura” viene sbloccata a Mach 1.4, praticamente all’inizio dell’accelerazione, ma oltre la fase “rischiosa” dal punto di vista aerodinamico. Come dice Giuseppe SS2 continua poi ad accelerare per un bel po’, dopo di che spenge i motori e, solo qualche minuto dopo quando arriva all’apice della traiettoria balistica (quindi quando la velocità, almeno quella verticale, è 0) viene azionato il comando di estensione delle ali “a foglia”. Quindi stiamo parlando di diversi minuti tra un comando e l’altro…

Quanto è possibile che dei piloti colaudatori esperti non si siano accorti di non aver ancora infranto la barriera del suono?

Se ho letto bene erano fra 0.94 e 1.02 Mach, probabilmente avrebbero passato 1.4 in una manciata di secondi (10? 15? sono passati da 0,94 a 1,02 in 2 s, l’accelerazione è decisamente notevole). Per me è plausibile che il secondo pilota si sia “portato avanti” sbloccando una sicura che, per l’appunto, doveva essere solo una sicura, non un comando.

Sì ma questo sarebbe davvero “errore umano”, perché va contro ogni concetto operazionale immaginabile. La sicura è appunto una sicura, perché qualcuno durante la progettazione ha individuato un possibile evento catastrofico e quindi ha pensato che per quel caso bisognava essere super sicuri e quindi essere 2-failure tolerant.
Decidere di ignorare questa cosa eliminando un inhibit volontariamente sarebbe un comportamento totalmente sbagliato per un operatore, a meno che qualcuno a monte non gli abbia detto “abbiamo rifatto le analisi, basta un solo inhibit, puoi togliere quello aggiuntivo qualche secondo prima così risparmiamo tempo”. Che senso ha fare i sistemi ridondanti, con aggiunta di costi, massa e complicazione, se poi si decide volontariamente di eliminare la ridondanza per “portarsi avanti”?

EDIT: l’errore non è mai dell’operatore finale, se è successo davvero così non basta dire “errore umano”. Se l’operatore fa un errore del genere è colpa di un addestramento sbagliato o non completo

Mah… Buzz, da specialista di gestione di sistemi complessi qual sei hai sicuramente ragione, ma in un ambiente sperimentale come questo non mi convinci del tutto. Certo, può essere un errore di overconfidence. Vedremo i risultati dell’inchiesta, e poi discuteremo su quelli.

Concordo totalmente… anche io sono dell’idea e condivido l’analisi fatta da Buzz, se si accertasse che questa azione non ha impedito che avvenisse l’incidente, le cause sarebbero da analizzare profondamente…
Si tratta di speculazioni, come quelle che spesso nascono e muoio dopo eventi di questo tipo, ma a leggere questo durissimo articolo di Doug Messier qualche dubbio potrebbe sorgere…
http://www.parabolicarc.com/2014/11/04/safety-obsessed-virgin-galactics-vice-president-safety-retired-ten-months/

Non mi fraintendere, è vero che durante la fase sperimentale si è molto più flessibili e si sperimentano molte più possibili configurazioni per vedere che succede, però questo si fa in maniera pianificata. È una flessibilità studiata a tavolino, si fanno procedure di test in cui si decide cosa fare, non è che chi esegue il test decide di essere più flessibile per i fatti suoi e nel bel mezzo dell’esperimento (forse mi son fatto troppo influenzare dalla safety :stuck_out_tongue: )

No no, è assolutamente corretto, a me è capitato di lavorare con test pilot e (anche se non direttamente) a contatto con un ambiente “sperimentale”, ma c’è davvero molto poco lasciato al caso anche sperimentando… l’idea comune del pilota sperimentatore, anche fra gli addetti ai lavori, è un po’ quella del cowboy dei cieli (con pregi e difetti), posso garantire che non è proprio così, in ogni fase del volo. :wink:

forse l’articolo a cui ti riferivi è questo

http://www.parabolicarc.com/2014/11/04/making-safety-decision-virgin-galactic/

Pare che NTSB punterà il dito principalmente su un addestramento lacunoso del personale coinvolto nel progetto.

Stasera alle 18:30 (ora italiana) ci sarà una conferenza stampa in merito.

Correzione. La conferenza stampa era alle 15:30.

OK
Dopo due volte che riscrivo tutto e mi viene cancellato per dei glitch al server:

speriamo ora che la Virgin inizi a volare presto.

scrivilo con wordpad poi copia/incolla sul forum, così se non funziona un’altra volta non lo devi riscrivere

Dall’indagine esce con le ossa rotte anche la FAA.