SLX OrbitLab: software di missione satellitare con F Prime e Basilisk

Una missione di osservazione della Terra richiede coordinamento fra pianificazione orbitale, controllo d'assetto, gestione dell'energia e trasferimento dei dati. SLX OrbitLab integra queste funzioni in un sistema software su PC: il satellite simulato riceve un obiettivo, pianifica il passaggio, acquisisce il prodotto ottico e lo trasferisce durante il contatto con la stazione a terra. Comandi, telemetria ed eventi tracciano le decisioni del software e la risposta del modello fisico.

SLX OrbitLab è la piattaforma Silicon LogiX per lo sviluppo e la simulazione di software di missione satellitare, sistemi autonomi e controllori embedded. La versione 0.7.0 integra un deployment NASA F Prime eseguito su Linux, un core proprietario C++, la simulazione Basilisk, una console desktop Qt e l'ispezione 3D Godot. Un sottosistema opzionale esegue firmware RTEMS su un processore LEON3 emulato con Renode. La piattaforma esegue su PC un ciclo completo di comando, simulazione fisica e telemetria. I test di integrazione collegano decisioni operative, dinamica del satellite e comportamento del firmware.

Architettura del software di missione: comandi, simulazione e telemetria

Il percorso operativo è esplicito: comando → software di missione → simulazione fisica → telemetria → aggiornamento della console e del 3D. La GUI invia una richiesta; F Prime la riceve attraverso il proprio dizionario e dispatcher; il componente Mission richiama il core C++ per valutare condizioni e azioni. Basilisk applica i comandi agli attuatori e ai carichi, integra la dinamica e restituisce le nuove misure.

Al passo successivo il software di missione legge queste misure, aggiorna le decisioni ed emette telemetria ed eventi. La frequenza di aggiornamento della finestra grafica non fa avanzare il tempo fisico. Questo confine permette di ripetere una prova, fermarla, avanzare per passi e osservare gli stessi istanti attraverso viste differenti.

F Prime: componenti C++, comandi nativi e telemetria

F Prime organizza il flight software in componenti con porte e collegamenti dichiarati. In OrbitLab questa architettura è il percorso di esecuzione dei comandi: le definizioni FPP descrivono parametri e interfacce, il dizionario generato viene usato dal Ground Data System per codificare le richieste e decodificare i pacchetti, e il dispatcher nativo consegna i comandi al componente destinatario.

La console espone 28 comandi di dizionario e 50 canali nativi nella versione 0.7.0. La selezione di un comando mostra parametri, esempi e significato operativo. È possibile richiedere il dispiegamento dei pannelli, una rotazione relativa, un puntamento al Sole o alla Terra, l'abilitazione del payload, il downlink, il segnalatore luminoso e le manovre orbitali previste dal modello. I comandi di diagnostica verificano anche il percorso di comunicazione.

Un esempio è OrbitLab.mission.MANEUVER [3,30]: il modo 3 richiede una rotazione relativa di 30 gradi. La risposta del dispatcher conferma l'accettazione dei parametri; la telemetria mostra poi errore di puntamento, assetto e stato degli attuatori. ACK, effetto fisico e completamento operativo sono tre evidenze distinte. Una richiesta accettata può restare in attesa se il tempo della simulazione è fermo o se energia, sensori e protezioni impediscono l'azione.

Per un progetto su commissione, questa organizzazione consente di discutere contratti delle interfacce, limiti dei parametri, comportamento dei componenti, gestione degli errori e prove d'integrazione su un percorso eseguibile.

Sequenze F Prime: pianificazione, validazione ed esecuzione

OrbitLab integra il componente nativo Svc.CmdSequencer. L'operatore prepara un piano da 1 a 64 passi, assegna ritardi relativi in secondi simulati e lo valida contro il dizionario della sessione. Gli strumenti F Prime compilano il file binario; la validazione nativa controlla formato e CRC prima dell'esecuzione.

Il piano può partire automaticamente o essere avanzato manualmente. Sono disponibili cancellazione, verifica del completamento e conservazione delle risposte di ogni passo. I ritardi seguono il tempo della simulazione e iniziano dopo la risposta del comando precedente. La pausa arresta anche questo clock, mantenendo coerenti sequenza e dinamica.

Il piano di esempio a otto passi dispiega i pannelli, sospende lo strumento ottico, richiede il puntamento al Sole, abilita il segnalatore dopo 5 secondi, comanda una rotazione di 30 gradi dopo altri 45 secondi, spegne il segnalatore dopo altri 60 secondi e ripristina payload e missione automatica. Eventi e telemetria permettono di controllare sia la lista eseguita sia le conseguenze sul satellite.

Le sequenze temporizzano richieste; non attendono automaticamente la convergenza del puntamento. Le condizioni di acquisizione restano nella macchina a stati C++ della missione. La separazione tra piano operativo e controllo del comportamento fisico permette di progettare test mirati e di interpretare correttamente i risultati.

Basilisk: dinamica orbitale e controllo d'assetto

Basilisk combina moduli numerici C++ e configurazione Python per costruire simulazioni di sistemi spaziali. OrbitLab usa questa base per integrare posizione e velocità orbitale, orientamento e velocità angolare, misure dei sensori e azione delle ruote di reazione. Python coordina il banco e gli adattatori; le decisioni di missione sono nel componente C++.

Il caso di riferimento dichiara un'orbita circolare iniziale a circa 550 km, un corpo rigido da 65 kg e tre ruote di reazione. Le grandezze attraversano il confine della simulazione con unità esplicite: metri, metri al secondo, secondi, radianti, watt e joule. Assetto e misure hanno riferimenti dichiarati, così da distinguere ciò che il controllore conosce dalla verità diagnostica del simulatore.

Le manovre orbitali integrano comandi di missione, vincoli operativi e dinamica di propulsione. Un comando di delta-v nel riferimento RTN viene controllato rispetto a energia, propellente, sensori, allineamento e condizioni dell'orbita. Basilisk integra una spinta finita applicata al corpo; il rapporto conserva delta-v erogato, combustibile residuo e variazione dei parametri orbitali. Un nuovo obiettivo terrestre aggiunto durante una missione mantiene la traiettoria esistente: il sistema prevede il passaggio accessibile, mentre una manovra fisica modifica l'orbita gradualmente.

Gestione energetica e pianificazione delle attività

La batteria ha capacità finita di 180 Wh. Generazione solare, orientamento e dispiegamento dei pannelli, eclissi e carichi attivi contribuiscono al bilancio fisico. Il core confronta energia disponibile, riserva e fabbisogno dell'attività, con una previsione energetica del breve orizzonte. La base numerica comprende i modelli Basilisk di accumulo e di generazione solare.

Nel caso di energia insufficiente l'acquisizione viene rinviata, il sistema mantiene carichi ridotti e registra la motivazione. Il modello vede quindi una potenza assorbita diversa da quella necessaria per acquisire un'immagine. L'indicatore della batteria riflette un bilancio modificato dalla decisione del software. Le protezioni restano operative anche durante richieste manuali.

Due strategie confrontabili, orientata alla priorità e orientata all'energia, applicano margini di pianificazione differenti e rispettano entrambe la riserva minima. Il confronto riparte dalle stesse condizioni iniziali, dagli stessi obiettivi, dal medesimo seed e dagli stessi guasti e stimoli registrati, con processi F Prime e simulazioni Basilisk separati. I risultati comprendono osservazioni completate o rinviate, energia finale e precisione durante l'acquisizione.

Osservazione della Terra: obiettivi, acquisizione e downlink

L'utente sceglie coordinate e priorità. Il software prevede le finestre di accesso, comanda il puntamento e richiede stabilità prima dell'esposizione. La configurazione di riferimento richiede un errore misurato inferiore a 0,5 gradi, tre secondi di stabilità e dodici secondi di esposizione. Questi valori sono parametri della missione simulata.

Il prodotto ottico sintetico deriva dall'orientamento effettivo del satellite, dall'intersezione dei raggi della camera con la Terra sferica e dalla texture geografica. Il dato grezzo è un'immagine monocromatica PGM da 256 × 256 pixel. Una preview PNG mette in relazione obiettivo, impronta del sensore e contesto cartografico, rendendo leggibile il contenuto della prova.

I byte vengono salvati nella memoria di bordo modellata e trasferiti durante una finestra di contatto geometrico con la stazione a terra, se l'energia consente il downlink. Capacità di storage, coda dei prodotti e disponibilità del collegamento possono cambiare il piano. La consegna è confermata quando il file ricevuto supera la verifica SHA-256. Il modello di collegamento serve a verificare gestione del dato e vincoli di missione; non calcola un bilancio RF o una modulazione radio.

Console Qt e visualizzazione 3D con Godot e Blender

Qt Quick e QML compongono la console operativa: missione, comandi F Prime, editor delle sequenze, canali, obiettivi e dati, orbita e passaggi, test e registrazioni. Il modello di telemetria aggiorna i valori conservando la posizione di consultazione. Parametri e descrizioni collegano un comando alla sua funzione e alla risposta operativa e alla telemetria. Un singolo operatore mantiene il controllo della sessione; i visualizzatori ricevono lo stato.

Godot 4.5 mostra il satellite ravvicinato, l'interno, la vista esplosa, l'orbita e la stazione a terra. La selezione dei componenti collega la geometria al sottosistema e ai comandi disponibili. Assetto, snodi dei pannelli, segnalatore e antenna seguono la telemetria confermata dal backend.

Gli asset Blender e le esportazioni GLB mantengono nomi, gerarchie e pivot dei componenti. La scala illustrativa della Terra e gli spostamenti della vista esplosa appartengono alla presentazione; non entrano nella dinamica. Anche la conversione degli assi Blender/glTF è esplicita e applicata una sola volta. È una scelta d'integrazione che permette di usare il 3D come strumento di osservazione senza confonderlo con il modello fisico.

RTEMS e Renode: firmware embedded su hardware emulato

RTEMS fornisce kernel e servizi per applicazioni real-time embedded. In OrbitLab esegue il firmware di un controllore energetico indipendente. F Prime resta un processo Linux; il nodo RTEMS è un sottosistema distinto. Le interfacce fra software di missione, modello energetico e firmware gestiscono richieste di potenza, risposte del controllore e stato dei carichi.

Renode emula il target LEON3/SPARC, incluse periferiche necessarie a timer e UART. L'esempio pubblico RTEMS/LEON3 di Antmicro documenta la sovrapposizione di piattaforme; l'integrazione OrbitLab è stata verificata con il proprio firmware. La compatibilità richiede coerenza tra ELF, BSP, mappa di memoria, clock e timer, seguita da prove di avvio ed esecuzione.

L'adattatore invia energia della batteria, capacità, potenza richiesta e tempo di missione attraverso messaggi UART correlati da numero di sequenza e protetti da CRC. Il firmware risponde con potenza ammessa, flag e heartbeat del task. Quel permesso limita i carichi applicati al modello Basilisk. Le prove includono avvio, interrupt del timer, task periodico, riduzione dei carichi con energia bassa o critica, rifiuto di un CRC errato e recupero dopo il messaggio invalido.

Il tempo emulato avanza in intervalli controllati. Un firmware che non risponde interrompe la prova: il banco non sostituisce silenziosamente il nodo RTEMS con una logica sul PC. I test di compatibilità e integrazione coprono questa specifica combinazione di firmware, BSP ed emulatore. La qualifica di un'elettronica o di un processore di volo richiede un'attività dedicata.

Scenari di missione, replay sincronizzato e analisi dei risultati

La campagna estesa comprende anche guasti degli attuatori, perdita di generazione solare o collegamento, più prodotti, memoria piena e funzionamento continuo. Gli intervalli di fault injection e i comandi operatore entrano nelle evidenze della prova.

La registrazione SQLite conserva configurazione, comandi e pacchetti nativi, eventi, campioni fisici e prodotti. Il replay ripresenta lo stato registrato senza reinviare comandi agli attuatori. Timeline, telemetria, immagini e 3D seguono gli stessi istanti. HTML, JSON, CSV e manifest SHA-256 permettono di discutere un'anomalia a partire da una traccia condivisa e di confrontare strategie con metriche esplicite.

Le evidenze di accettazione della release 0.7.0 riportano 26 test d'integrazione Linux, tre verifiche CTest Windows, otto regressioni del confine di pubblicazione e prove della GUI con comandi, sequenze e manovre native. L'esecuzione con SDK binario, senza i sorgenti del core proprietario, è stata verificata separatamente.

Nel caso documentato con SDK, la missione consegna un prodotto con RMS di puntamento durante l'acquisizione di circa 0,0586 gradi; una manovra eroga 2 m/s e aggiorna il propellente residuo. Questi sono risultati della configurazione e delle condizioni di prova indicate, non una precisione universale promessa per qualsiasi satellite.

Core C++ proprietario, API binarie e modelli di simulazione

Il motore proprietario Silicon LogiX espone una C ABI versionata con strutture a dimensione fissa, unità dichiarate e handle opaco. L'interfaccia non dipende dai tipi di Qt, Godot, Python o F Prime. Il core può essere distribuito come libreria condivisa e integrato o aggiornato rispettando il contratto binario, mantenendo separati presentazione e adattatori.

La parte pubblica su GitHub contiene GUI, integrazioni, API, firmware di esempio, scenari, asset approvati, documentazione e test. L'implementazione proprietaria del core è esclusa; per compilare ed eseguire OrbitLab dai sorgenti pubblici serve il corrispondente SDK binario di valutazione. Distribuzione e sviluppo commerciale sono regolati dalle condizioni del progetto.

Il modello dichiara i propri limiti: Terra sferica, riferimenti semplificati, assenza di perturbazione J2, atmosfera, terreno e termica, batteria ideale, massa dinamica costante e strumento ottico sintetico. Non rappresenta la chimica delle celle, l'elettronica analogica di potenza o un collegamento RF completo. La ripetibilità viene verificata nell'ambiente Linux fissato e con lo stesso seed; non è promessa un'identità binaria fra piattaforme differenti. La descrizione del modello rende consultabili parametri, criteri e semplificazioni.

Sviluppo su commissione per aziende ed enti

L'architettura di OrbitLab integra competenze applicabili allo sviluppo di software di missione, controllori embedded, banchi di simulazione e console operative. Per un'azienda o un ente, il progetto può partire dai requisiti operativi, dalle misure disponibili, dai vincoli energetici, dalle condizioni anomale e dai criteri di accettazione del sistema.

• Componenti F Prime: definizioni FPP, topologie, comandi, telemetria, eventi, integrazione dei servizi e prove native.
• Simulazione e autonomia: modelli Basilisk, controlli C++, pianificazione, gestione delle risorse e scenari di guasto.
• Firmware embedded: integrazione RTOS/BSP, protocolli, periferiche e verifica del target emulato prima delle prove hardware.
• Console e strumenti: applicazioni Qt/QML, ispezione 3D, acquisizione e presentazione delle evidenze.
• Verifica e consegna: campagne ripetibili, metriche concordate, rapporti, documentazione e interfacce distribuibili.

Puoi consultare il repository OrbitLab e la documentazione tecnica, oppure contattare Silicon LogiX per una presentazione tecnica, un SDK di valutazione o un progetto su misura. Il punto di partenza è definire cosa il sistema deve fare, come deve reagire alle condizioni limite e quali test ne devono documentare la conformità ai requisiti.