ovvio che le comunicazioni tra lander e strumento erano gia previste, era previsto di leggere dal laser i dati di distanza e trasmetterli a terra grezzi, invece hanno dovuto usarli a bordo. Forse il computer di bordo e uno solo, lo stesso che gestisce sia navigazione che telemetrie, in una missione economica ci puo stare (come ci puo stare di non avere una checklist pre-volo…)
Credo che per inquadrare bene la situazione vada fatta una premessa, tenendo conto di due fattori.
Primo, Intuitive Machines è un’azienda a sviluppo verticale.
IM non è solo operatore di Odysseus, ma anche progettista e costruttore dell’hardware. Questo significa che in azienda c’è tutto il know how necessario non solo per utilizzare il veicolo, ma se ne conosce approfonditamente ogni capacità e limite perché lo si è progettato e costruito.
Questa è un po’ un’eccezione nel settore aerospaziale, dove normalmente progettazione e costruzione del veicolo sono affidate ad aziende terze con solida e pluriennale esperienza nel settore, mentre il committente si “limita” ad operare e in caso di bisogno fa ricorso al costruttore come consulente a supporto.
Secondo, IM è un’azienda privata e for profit, tipica del new space.
Senza dilungarsi troppo, come ormai arcinoto le aziende private, che rispondono solo ai propri investitori, possono (e probabilmente devono) prendersi rischi molto maggiori di enti pubblici come NASA o altre agenzie spaziali, che invece hanno natura totalmente diversa e di fatto devono dimostrare di aver usato correttamente il denaro dei contribuenti, a pena di sanzioni amministrative se non penali.
La combinazione di questi due fattori ci porta a capire meglio:
- come sia stato possibile sia prendere “al volo” la decisione, di fronte all’impossibilità di acquisire un dato telemetrico essenziale per l’atterraggio, di patchare al volo il software di guidance per integrare i dati del LIDAR di NASA nel loop di determinazione dell’assetto (snellezza nel processo decisionale tipico dei privati);
- perché il lato tecnico della vicenda (analizzare gli input del LIDAR, trasformarli in input per il sw di guidance, scrivere il sw per tale conversione, patchare il sw di guidance per prendere e gestire i dati del LIDAR) sia stato analizzato e risolto a tempo record (know-how approfondito dell’hardware e del software di Odysseus, dato che era stato sviluppato in casa).
Questa vicenda, pur con tutte le limitazioni di un atterraggio imperfetto e di procedure da affinare (la mancata rimozione di un inibitore hw), ci mostra come la spinta di NASA per lo sviluppo del settore aerospaziale privato in ottica new space negli USA stia cominciando davvero a fare la differenza, creando pian piano un edge che da europei stiamo subendo e che richiederà un cambio di mentalità profondo e anni di lavoro per cominciare a recuperare. Ma non voglio andare off-topic.
Bravi IM!
11 Mi Piace
Peraltro le patch software improvvisate a poche ore da un atterraggio non sono una novità nemmeno nel programma spaziale NASA, ricordiamo per esempio quella per il modulo lunare di Apollo 14.
1 Mi Piace
I “fallimenti di successo” sono una costante nell’esplorazione spaziale. Sia pubblica che privata.
A parte utilizzarli come metodologia di progetto a priori, gli esempi di anomalie che hanno dato modo di sviluppare rimedi anche piu’ interessanti della missione primaria sono tantissimi.
L’apoteosi e’ stata l’Apollo 13, che e’ molto piu’ ricordata e importante cosi’ che se avesse avuto successo. La stessa missiona per il ripristino dell’ottica di HST pur costosa ha consentito di progredire e fare cose mai fatte prima utili per il futuro. E per le missioni Vojager di fatto si sono messe a punto tecnologie e metodologie di comunicazione nuov a missione in corso… ovviamente essendo una messione pluridecennale.
Ma le missioni in cui ci si e’ ritrovati a riprogrammare al volo come gestire dei guasti e la perdita di singoli elementi/consumabili a memoria mi pare siano stati parecchi.
E bisogna dire che la gran parte erano missioni pubbliche, non e’ del tutto vero che un team pubblico si muove come un pachiderma con il paraocchi e non e’ in grado di reagire in tempi brevi, l’esperienza del passato lo dimostra (so che non si intendeva questo).
Forse il pubblico ha piu’ difficolta’ a cambiare radicalmente percorso quando non c’e’ una vera emergenza, in fase di preparazione, progetto, implementazione, suddivisione dei ruoli…ma in mezzo a una crisi quando devi trovare velocemente una soluzione per riportare vivi gli astronauti a terra la burocrazia e la governance si sciolgono come neve al sole e gli esperti pedalano e collaborano, come dimostra il passato.
1 Mi Piace
Nemmeno questo è totalmente vero.
Non è detto che il pubblico debba guardare al privato con un senso di inferiorità. Il punto chiave è che pubblico e privato fanno lavori diversi, e il primo deve diventare, da mandato (parlando di agenzie spaziali), un volano per il secondo.
Una volta le agenzie governative pubbliche erano le uniche con know-how e fondi per portare avanti certe politiche spaziali. Oggi la diffusione di conoscenze, tecnologie e capacità economiche tende a metterli (anche nella nostra testa) quasi in concorrenza, ma è una falsa concorrenza.
Dopo aver trasferito conoscenze e tecnologie abilitanti, sviluppate a costi e con tempi molto grandi, ora è il turno di passare la mano, laddove possibile, alle realtà private.
1 Mi Piace
E’ un tema interessante. Abbiamo fatto tanti esempi positivi, citerei quello che forse e’ il principale caso negativo, anche se e’ un po’ divisivo: il programma Shuttle. In quel caso nonostante le evidenze che la strada era sbagliata o migliorabile il sistema non ha cambiato direzione, e anzi continua a perseverare ad utilizzare tecnologie e componenti nati per fare cose diverse che non si sono realizzate, creando tuttora diseconomie e design subottimali. E anche questa e’ una storia pluridecennale.
1 Mi Piace
Grazie, risposta molto esaustiva.
Il punto che più mi ha lasciato dubbioso è quello citato per secondo, ovvero “analizzare gli input del LIDAR, trasformarli in input per il sw di guidance , scrivere il sw per tale conversione, patchare il sw di guidance per prendere e gestire i dati del LIDAR” mi sembra (molto) strano sia stato fatto in un’ora e mezza.
Va bene essere bravi, va bene avere il controllo completo della situazione, ma almeno la fase di analisi mi aspettavo fosse stata fatta prima, con conseguente soluzione già sviluppata, testata e pronta all’uso.
Mi chiedevo se qualcuno tra i lettori aveva partecipato attivamente a programmi simili per capire meglio come vanno le cose, il tutto a livello di curiosità personale.
Lavoro nel settore aerospaziale ma non ho mai partecipato allo sviluppo di SW o firmware per strumenti o interfacce. Ne sono solo un utente.
Credo che le interfacce e il formato dati tra LIDAR e resto dello spacecraft fossero note già a priori. Il team di sviluppatori HW e SW del computer di bordo è “in casa” IM. Immagino abbiano formato una task force di gente ben ferrata e con le mani in pasta, che sapeva dove mettere mano e come. Hanno poi sfruttato un’infrastruttura di validazione della patch probabilmente rodata in precedenti fasi di test, e infine hanno preso il coraggio a due mani e con due gonadi di acciaio hanno assunto il rischio. E’ andata bene.
Ovviamente tutte mie opinioni, si sarebbe dovuti essere mosche sulla parete della loro sala riunioni per sapere davvero come è andata. Comunque nel video della conferenza stampa qualche elemento in merito è stato dato.
3 Mi Piace
pronto a prendermi un pò di flak per quello che sto per scrivere… ma per ora il programma CLPS si sta dimostando un fallimento da “amateurs”.
228 milioni per una valvola che sparge idrazina tra terra e luna e un atterraggio alla kerbal space program. E nel frattempo si licenzia personale al JPL dove si portano avanti con successo progetti che vanno ben oltre ciò che le sonde surveyor hanno fatto nel 1966. I miei 2 cents…
6 Mi Piace
La butto lì: le missioni Surveyor, importantissime come le Lunar Orbiter, negli anni sessanta che hanno spianato gli allunaggi delle successive missioni Apollo hanno fallito solo una volta su sette l’allunaggio pur arrivando in zone molto complesso del terreno selenico. Questi ultimi viaggi come vanno valutati amici miei come un passo avanti oppure un passo indietro?
L’intento del CLPS è proprio trasferire conoscenze agli amateurs, che ovviamente al primo tentativo falliscono. Quindi al momento il programma CLPS non sta deviando molto dagli obiettivi. Dopotutto se guardi con attenzione il carico, a bordo non c’era un granché. Su Viper la NASA ci sta mettendo un po’ più di attenzione, partecipando ad alcuni test di validazione, perché è un carico un po’ più importante.
Anche le cifre sono contenute, qualche centinaio di milioni a missione. L’investimento è a lungo termine, l’obiettivo è di avere fornitori più affidabili.
Sul JPL sono d’accordo al 100%.
A mio avviso la patch e la procedura di patch erano già pronte. In un ora e mezza, anche sotto pressione, a mio avviso è davvero difficile anche solo sviluppare la procedura di patch e validarla nel simulatore o modello ingegneristico anche fosse solo per evitare typo. Va bene essere smart e agile ma ho visto tante volte fare confusione tra definizione di start address in decimali o esadecimali o SAU in Byte o Word.
L’implementazione funzionale inoltre non è banale a mio avviso , si deve dire al software di prendere un altro data pool con frequenza di campionamento magari differente senza contare evitare di cambiare il database, non è detto che le curve di calibrazione dei due strumenti fossero simili.
Da un analisi rams magari era chiaro che ci fosse un punto critico e si è preparato il piano b.
Lasciare invece un Red tag prima del volo è un errore da principianti della parte QA.
5 Mi Piace
Una interessante serie di considerazioni di Metzger su un aspetto che non conoscevo. In sostanza non abbiamo idea di come i gas dei razzi interagiscano con la regolite.
https://x.com/drphiltill/status/1761726379115045095
Manca proprio la teoria, quindi i simulatori affidabili. E per come la chiude i dati sulle missioni Apollo sono già stati consumati. Queste nuove missioni hanno una parte importante in questo ambito.
2 Mi Piace
Per una lettura più comoda
2 Mi Piace
Io ho avuto esperienza in più di un progetto in cui l’azienda ha preso la decisione di uno sviluppo verticale, in particolare proprio del SW, assumendo softwaristi in gamba ma senza avere il know-how dentro l’azienda. E le mie esperienze sono state abbastanza disastrose…
È vero che da un lato riesci a reagire più velocemente quando sei in “firefighting mode”, ma se avessi usato un’azienda specializzata che fa solo quello come core business, magari eviteresti di aver fatto quell’errore piuttosto banale che poi ti porta a dover fare una patch d’urgenza. E alla resa dei conti, il firefighting costa di più e brucia le persone.
Purtroppo IMHO si vanta sempre il pompiere come un eroe che spegne l’incendio all’ultimo minuto, mentre chi costruisce il tutto per bene secondo le regole in modo che l’incendio non scoppi neanche passa sotto silenzio (se addirittura non viene criticato come burocrate).
3 Mi Piace
Certamente, un solo “sample” non fa la regola. Non dubito che situazioni simili possano andare in tutt’altro modo se anche solo una delle cose nella catena di azioni richieste per una recovery simile va storta.
E’ un po’ il bias del sopravvissuto, in questo caso, e non si discute che se la procedura per togliere la sicura al LIDAR fosse stata seguita e controllata adeguatamente, specie per un componente cosi’ critico, non ci si sarebbe trovati in quella situazione.
Ribadisco che non sono qui a fare l’elegia del privato vs pubblico. Mi limitavo ad osservare la differenza di alcuni processi decisionali, e ai fattori che secondo me li hanno influenzati.
1 Mi Piace
Giochino ispirato alla missione 
Lunar Reconnaissance Orbiter ha fotografato Odysseus ma né il comunicato NASA di presentazione né gli scarsi dettagli visibili rivelano di più sull’assetto e le condizioni del veicolo:
5 Mi Piace
Io trovo davvero sconvolgente che in una missione tanto importante si sia fatto un errore del genere nella lista red e green tag. I payload sono pieni di red tag che inibiscono laser o alti voltaggi a terra a temperatura ambiente. Forse a volte essere formali ed avere le procedure scritte nella pietra non è così male. Il problema non è che qualcuno ha sbagliato ma che qualcuno che sbaglia mette a repentaglio tutta la missione perché non c’è un secondo controllo.
3 Mi Piace