Starlink - La costellazione di satelliti di SpaceX per i servizi Internet

Costellazioni Starlink
81

Provo a fare un esempio terrestre: se per guidare un treno ci vuole un ferroviere, quanti ferrovieri ci vogliono per guidare 1000 treni?

Uno potrebbe dire: facciamo i treni automatici così che il ferroviere può stare in una sala di controllo e guidare 10 treni per volta. Giustissimo!
Però c’è un limite. Un controllore di volo può controllare più di un satellite (come succede già nei centri multi-mission o nei centri di controllo delle costellazioni), ma più satelliti hai e più rischi che avvengano due anomalie in parallelo e il controllore non possa risolverle entrambe nei tempi richiesti. E quindi ogni controllore arriva al massimo a 10-15 satelliti, a seconda di quanto è complicato il satellite.

Poi ci devi mettere il lavoro da ops engineer. Faccio di nuovo un esempio terrestre: se per fare la revisione di un auto ci vogliono 4 ore di lavoro di 1 meccanico, quante ore di lavoro ci vogliono per fare la revisione di 1000 auto?

E qui uno può dire: progetta un sistema che ha bisogno di poca manutenzione periodica. Giustissimo!
Però anche qui c’è un limite. E veniamo a quello che ho scritto sopra riguardo alll’affidabilità: l’industria dell’auto ha raggiunto livelli incredibili, e comunque la macchina va controllata ogni due anni. Nello spazio c’è qualcosa di simile, vanno fatte manutenzioni periodiche.

E oltre alla manutenzione, ci devi mettere la flight dynamics: la terra non è rotonda e l’atmosfera non scompare del tutto fino a 2-3 mila km. Un LEO tipicamente fa una manovra ogni una o due settimane per rimanere nella control box. Questa manovra va calcolata, pianificata ed eseguita di volta in volta perché i disturbi non sono deterministici. Se per farlo per un satellite ci vogliono 2 ore di lavoro, quante ore di lavoro ci vogliono per 1000 satelliti?

E fin qui abbiamo parlato solo delle attività preventive, non di quelle correttive. Ed entrano in gioco le anomalie. Il capitolo di mission operations dello SMAD comincia così: engineers expect things to work, operations expect them NOT to work.

E torniamo all’affidabilità e a quello che ho scritto sopra rispondendo a Paolo Amoroso.

E fin qui abbiamo parlato solo della parte spazio. Se ci aggiungiamo il ground segment, il lavoro raddoppia.

Chiudo con una domanda per curiosità: quando hai fatto l’esempio della rete di telefonia, parli per esperienza diretta in prima persona o sono tue assunzioni?

Lo dico perché come ho scritto sopra io sono responsabile anche delle operazioni di un sistema di terra piuttosto simile alla rete internet, anche se molto più piccolo, e le anomalie che richiedono interventi, ricambi, etc sono tante. E usiamo equipaggiamenti standard, Cisco, Dell, HP, etc.

Purtroppo tutti quello che ho scritto sopra viene sempre sottovalutato, e non solo in ambito spaziale, perché è un lavoro intangibile: noi non “produciamo” niente. Se a fine anno mi chiedono quali sono stati i miei risultati, la mia risposta è “abbiamo tenuto tutto il sistema in piedi”. Ma se uno non l’ha mai fatto, non ha la sensibilità di quanto sforzo questo richieda.

15 Mi Piace
82

L’altitudine è stata ritoccata a 550 km in questo nuovo sottomissione al FCC, con i allegato parecchie informazioni tecniche

83

Altitudine più bassa significa più necessità di reboost o vita operativa più bassa?

84

Direi che il primo fatto implica il secondo, a meno che non si usino tecnologie di motori elettrici “air breathing” che però a quanto ne so sono solo in fase sperimentale ( https://m.esa.int/Our_Activities/Space_Engineering_Technology/World-first_firing_of_air-breathing_electric_thruster ).

Questo cambiamento è un buon cambiamento per vari motivi, il più importante forse che in caso di fine vita programmata del satellite esso verrà deorbitato in 6 mesi; Se il motore a ioni smettesse di funzionare ma il satellite fosse ancora in grado di riorientarsi in una configurazione di elevato drag verrà deorbitato in non più di 3 anni; In caso di fallimento totale, verrà comunque deorbitato in non più di 5 anni.

Ad un orbita di più di 1000km i tempi di decadimento naturali non si avvicinano neanche lontanamente.

Considerato che la probabilità di fallimento in orbita per i primi satelliti sarà sicuramente non bassa, questa è decisamente una buona notizia.

Questo cambiamento permetterà anche alla SpaceX di lanciare i satelliti più velocemente ed efficientemente. Considerando che i satelliti dovrebbero pesare non più di 400kg, se ne riuscissero a lanciare 22 alla volta riuscirebbero con 72 lanci in RTLS a completare questa prima fase della costellazione. Possibilmente anche meno lanci se i satelliti fossero ancora più piccoli e leggeri.

85

Secondo me nessun reboost. L’Hubble è a 570 km, e non subisce reboost dal 2009. A quella quota credo non sia necessario, salvo manovrare per mantenere la posizione nel piano orbitale (la famosa box).

Potete dare un’occhiata alle previsioni orbitali per HST (giusto per avere un’idea) in https://asd.gsfc.nasa.gov/archive/hubble/a_pdf/news/facts/sm3b/fact_sheet_reboost.pdf

86

Ok, era per avere un’idea della situazione.

87

Altitudine piu’ bassa significa anche area illuminata piu’ ristretta.

Ipotizzo, ma eventuali esperti correggano, piu’ satelliti e/o minore interferenza/sovrapposizione tra i satelliti, maggiore capacita’ complessiva e/o minore precisione di puntamento richiesta ai phased array.

Chissa’ se il motivo e’ uno di questi.

EDIT: giusto: anche le latenze si riducono un po’.

88

Riguardo alla latenza, nella stessa file fcc, passano da 25-35ms a sotto i 15ms. screenshot del pdf dell’utente RedLineTrain

Sul numero di lanci sembra che si possa arrivare al max ad oltre 40 (parlano di pie wedge adaptor) . Calcolo fatto a 450 kg totali a satellite

Edit: Interessante podcast puntata speciale di Anthony Colangelo (Main Engine Cut Off) che analizza l’ultimo fcc filing

2 Mi Piace
89

A 550 km il drag si sente. Specialmente con il Sole che nei prossimi anni tornerà ad aumentare l attività e con il drag che nei prossimi anni aumenterà gradualmente.

90

L’orbita più bassa richiederà inoltre 16 satelliti in meno.

1 Mi Piace
91

Aggiungo uno spunto di analisi, si parla molto del numero di lanci necessari a questa ipotetica mega-costellazione, ma siamo sicuri che esista e abbia senso parlare di questo numero?
Mi spiego, ipotizzando di completarla nell’arco di alcuni anni, credo sia molto probabile che una volta arrivati al numero di 4000 e rotti satelliti immessi in orbita, sarà il momento di cominciare a rimpiazzare i primi satelliti lanciati, quelli che inevitabilmente negli anni hanno avuto problemi e successivamente sarà molto probabile che con l’evoluzione tecnologica dell’offerta e della domanda sarà necessario cominciare a lanciare satelliti di una seconda generazione, poi di una terza ecc…
Insomma, a mio avviso, l’avere una costellazione operativa di questo tipo, comporterà la necessità di avere un certo numero di lanci continuo per tutto il ciclo di vita del progetto, dal primo lancio alla dismissione.

3 Mi Piace
92

Infatti adesso mi pare di leggere tra le righe che il progetto e’ ridimensionato a “solo” 1500 satelliti, per iniziare.

Pero’ a 500 km, con ping time di 15 ms (che e’ fattore competitivo essenziale perche’ non possono competere sul prezzo con la fibra) e necessariamente una vita utile dei satelliti di pochi anni, simile a quella di uno smartphone o di un PC.

Orbit decay e obsolescenza tecnologica potrebbero andare a braccetto, imponendo un turnover veloce della flotta.

93

E’ importante soprattutto per un motivo: La FCC richiede il lancio di almeno la metà dei satelliti della costellazione finale entro i prossimi 6 anni. Se non riuscissero a lanciarne nemmeno quella quantità, il progetto sarebbe morto in partenza, in quanto andrebbero in contro a problemi legali.

2 Mi Piace
94

Non so dire nulla riguardo al tuo progetto, ma ho esperienza di 2 grossi progetti spaziali, uno che condividiamo. Dire che si utilizza equipaggiamenti standard vuol dire tutto e niente. Negli ultimi 10 anni l’approccio alla progettazione e alla manutenzione di infrastrutture informatiche è cambiato parecchio. Ora si punta a sistemi ridicolmente ridondanti, dove ogni componente software e hardware è sostanzialmente fungibile. Letteralmente piuttosto che investigare un problema software (se non ripetuto e indice di un problema più grave) si riavviano interi moduli. Se un hardware si guasta, si sostituisce l’intera macchina senza impatti (se non sulla ridondanza) sul sistema. NULLA di quanto ho visto nei ground segment sui cui ho lavorato beneficia di alcuna di queste tecnologie “recenti”.

Se mentre sul flight hardware e sulle flight operations l’inerzia al cambiamento è comprensibilmente alta, l’inflessibilità e il design anacronistico dei ground segment, nella mia esperienza, sono un collo di bottiglia straordinario che non solo impedisce di evolvere un sistema complesso come un programma spaziale, condannando dunque a gigantesche multidecennali “generazioni” destinate a ripetere gli stessi errori, ma impedisce anche il miglioramento della sicurezza (in termini di safety, non security) delle operazioni.

Ed è un problema tanto tecnologico quanto organizzativo, specialmente se si pensa alla mancanza di un sistema di feedback efficace tra le operations e il design (ed è sostanzialmente uno dei motivi per cui ho scelto di lasciare l’ambito spaziale, almeno per un po’ )

Ora, mi rendo conto che questo tipo di considerazioni sulle infrastrutture di terra non si possano mappare direttamente al segmento spaziale (cancellare una macchina virtuale che non funziona è un tantinello più semplice di deorbitare un satellite KO in uno sciame di migliaia), ma passare da amministrare 10 server ad amministrarne 10000 con lo stesso personale ha richiesto cambiamenti sia tecnologici che organizzativi. Mi aspetto che qualcosa di simile debba accadere se si scala verso la dimensione delle constellazioni come si prospetta. Tentare di immaginare le operations di una constellazione come Starlink con i modelli attuali la fa sembrare una impresa titanica. E il lavoro titanico effettivamente dovrà esserci (probabilmente sta avvenendo ora) ma in un ambito diverso, ovvero nella definizione di nuovi ops concept.

E questo non per minimizzare la difficoltà. Pochi mesi fa girava un articolo scritto da un ex ingegnere IT di Tesla che descriveva lo stato dell’infrastruttura di Tesla per la gestione della flotta (aggiornamenti delle automobili). Da mani nei capelli. Ma non si arriva con la soluzione perfetta al primo colpo. Sistemi complessi di questo genere DEVONO avere un approccio evolutivo. Il waterfall non funziona più.

9 Mi Piace
95

Conticino della serva.

La luce percorre circa 300 km in un millisecondo. Quindi nei 15 millisecondi sopra indicati c’e’ un limite fisico, non si fanno piu’ di 4500km.

Se quel dato e’ da intendere come ping time, la distanza va percorsa due volte, andata e ritorno. Quindi per le leggi della fisica in 15 ms non si fanno piu’ di 2250km. Ipotizzando che il percorso via satellite in orbita bassa approssimi quasi perfettamente la rotta great circle, che e’ la piu’ breve sulla superficie terrestre, non fai certo un LON-NYC con ping time di 15ms… se non ho sbagliato qualcosa.

Probabilmente il dato e’ da intendere “a partire da” e in una sola direzione.

Comunque basta essere anche di poco piu’ veloce del percorso terrestre per essere competitivi nei confronti di certi potenziali clienti.

1 Mi Piace
96

Per la nostra rete questo vale, non abbiamo anomalie singole che interrompono il servizio.
Ma ciò non toglie che ogni guasto richiede lavoro di logistica, service engineers e ops. E operare un sistema grande richiede tante risorse

Già… problema con cui combattiamo tutti i giorni. E la cosa assurda è che questo vale in tutti i progetti e le aziende :confused:

Ma cosa ti fa pensare che fuori dallo spazio le cose siano diverse?
Da quello che leggo e sento in giro il problema è anche in altri settori…

Il problema secondo me è che storicamente le aziende che progettano non sono mai state le stesse che operano il sistema. E anche in situazioni come Airbus, le operazioni vengono fatte da un sito ma il progetto è stato fatto da un altro sito, e purtroppo ancora oggi i siti diversi sono come aziende diverse.

Assolutamente d’accordo!
Il problema è che secondo me questo non sta avvenendo. Basta che guardi le discussioni su twitter, Facebook, forum o vari social network: hai mai visto qualcuno parlare dell’ops concept (oltre che su FA.it)?

Si parla sempre dei problemi di design, della latenza, del link budget, del numero di lanci necessario…
Per me il bottleneck sono le operazioni, ma nessuno sembra rendersene conto. Anzi, quando si pone il problema viene sempre e irrimediabilmente sottovalutato. E tuttora non ho mai visto un paper o una presentazione che descriva l’ops concept di queste costellazioni mastodontiche.
(E di nuovo non parlo solo di SpaceX, per Oneweb mi sembra sia lo stesso)

E conoscendo un pochino il settore, non mi stupirei se ci fosse qualche system engineer con zero esperienza di ops che ha pensato e presentato al management qualche conops insensato…

1 Mi Piace
97

Filiera corta.
Massimo riutilizzo di soluzioni COTS per le parti complesse e il resto sviluppato e operato da persone che lavorano vicine, senza layer e layer di subcontractors.
A ben pensarci, è una delle caratteristiche meno evidenziate di SpaceX. In larga parte, operano quello che sviluppano.

No, in effetti. Anche se seguo solo qui :slight_smile:
Ma scommetto che internamente la questione è ampiamente dibattuta.

Può darsi :smiley:
Ma essendo il system engineer probabilmente nello stesso palazzo, se non nello stesso piano, di chi è (o sarà) responsabile delle Operations, il feedback loop sarà più corto, e gli effetti di decisioni sbagliate avranno effetti più brevi nel tempo.

5 Mi Piace
98

Anche io sono nello stesso corridoio dei system engineers, ma questo non gli ha impedito l’altro giorno di dirmi di continuare a schiacciare pulsanti, che è quello che fanno le ops, e smetterla di chiedere cose…
Non è questione di distanza fisica, ma mentale :smile:

2 Mi Piace
99

Nel frattempo, Spacex ha ricevuto l’approvazione dell’FCC per il lancio di 7000 satelliti.

100

“Thankfully they’ll be in lower orbits, which makes debris less of a risk over time - but still, WOW”… ma anche no…

Un analisi dell’Orbital Debris Program Office (pagina 4) sule eventuali future Large Constellations, porta alla luce uno scenario piuttosto inquietante.

In soldoni, si riuscirà a gestire la cosa (dal punto di vista della “ecologia orbitale”) solo se si abbraccia una forte attenzione al Postimission Disposal (deorbitazione programmata a fine missione)

Secondo le simulazioni, solo preventivando un 90% di satelliti “civilmente” deorbitati dopo la missione e senza -SENZA- nessuna esplosione accidentale, si riesce a mantenere dei livelli accettabili.

Se ci mettiamo alle varianti i failures esplosivi (nelle simulazioni è stato usato un dato preso dalla statistica reale fino ad oggi, ma non dice la percentuale) in 200 anni si ha un incremento del 110% (sul totale della massa in orbita in quell dato momento, non riferito al numero di oggetti attuale, attenzione) rispetto alla previsione più rosea (vedi sopra)

Se poi a tutti sti bei discorsi ci mettiamo che lanciamo senza fare deorbiting … arriviamo a livelli di sindrome di Kessler.

Comunque vi rimando all’articolo che è molto interessante

Un saluto!

5 Mi Piace