🥇Un po' sugli standard delle comunicazioni spaziali

Satellite Meteor M1
Fonte: vladtime.ru

Introduzione

L'operazione della tecnologia spaziale è impossibile senza le comunicazioni radio, e in questo articolo cercherò di spiegare le idee principali che sono alla base degli standard sviluppati dal Comitato Consultivo per i Sistemi di Trasferimento Dati Spaziali (Consultative Committee for Space Data Systems – CCSDS. In seguito utilizzerò questa abbreviazione).

Questa pubblicazione sarà dedicata principalmente al livello di canale, tuttavia, i concetti fondamentali per altri livelli saranno anche introdotti. Questo articolo non pretende in alcun modo di fornire una descrizione completa e dettagliata degli standard. È possibile consultarli su sito CCSDS. Tuttavia, sono molto pesanti da comprendere e per capirli abbiamo impiegato molto tempo, quindi qui voglio fornire informazioni di base, possedendo le quali districarsi nel resto sarà molto più facile. Iniziamo.

Nobile missione del CCSDS

È possibile che qualcuno si chieda: perché tutti dovrebbero attenersi agli standard, se si può sviluppare il proprio stack proprietario di protocolli di comunicazione (o il proprio standard, con blackjack e nuove funzionalità), aumentando così la sicurezza del sistema?

Come dimostra la pratica, è più vantaggioso aderire agli standard CCSDS per i seguenti motivi:

Nel comitato responsabile della pubblicazione degli standard sono entrati rappresentanti di tutte le principali agenzie aerospaziali del mondo, portando la loro esperienza inestimabile acquisita nel corso degli anni di progettazione e operazione di varie missioni. Sarebbe molto sciocco ignorare questa esperienza e ripetere gli stessi errori.
Questi standard sono supportati dall'attrezzatura esistente sul mercato delle stazioni di terra.
In caso di risoluzione di eventuali malfunzionamenti, è sempre possibile chiedere aiuto ai colleghi di altre agenzie per avviare una sessione di comunicazione con il veicolo dalla loro stazione di terra. Come potete vedere, gli standard sono estremamente utili, quindi vediamo insieme i loro punti chiave.

Architettura

Gli standard sono un insieme di documenti che riflettono il modello OSI (Open System Interconnection) più comune, con l'eccezione che, a livello di canale, la generalità è limitata alla suddivisione in telemetria (canale "verso il basso" – spazio – Terra) e telecomandi (canale "verso l'alto").

Esaminiamo alcuni livelli in dettaglio, partendo da quello fisico e salendo verso l'alto. Per maggiore chiarezza, considereremo l'architettura del lato ricevente. Il lato trasmittente rappresenta il suo riflesso speculare.

Livello fisico

A questo livello avviene la trasformazione del segnale radio modulato in un flusso di bit. Gli standard qui sono principalmente di tipo raccomandato, poiché a questo livello è difficile astrarsi dall'implementazione specifica dell'hardware. Qui il ruolo chiave di CCSDS è quello di definire le modulazioni ammissibili (BPSK, QPSK, 8-QAM, ecc.) e fornire alcune raccomandazioni per l'implementazione dei meccanismi di sincronizzazione simbolica, compensazione dello spostamento Doppler, ecc.

Livello di sincronizzazione e codifica

Formalmente è un sotto-livello del livello di collegamento, ma molto spesso viene evidenziato come un livello separato per la sua importanza all'interno degli standard CCSDS. Questo livello trasforma il flusso di bit in quelle che vengono definite le 'frame' (telemetria o telecomando), di cui parleremo più tardi. A differenza della sincronizzazione simbolica al livello fisico, che consente di ottenere un flusso di bit corretto, qui si effettua la sincronizzazione a livello di frame. Consideriamo il percorso che i dati percorrono a questo livello (dal basso verso l'alto):

Tuttavia, prima di questo, è opportuno dire alcune parole sulla codifica. Questa procedura è necessaria per rilevare e/o correggere gli errori di bit, che inevitabilmente si verificano durante l'invio di dati su un canale radio. Qui non discuteremo le procedure di decodifica, ma otterremo solo le informazioni necessarie per comprendere la logica operativa del livello.

I codici possono essere a blocchi e continui. Gli standard non obbligano a utilizzare un tipo specifico di codifica, ma essa deve comunque essere presente. Tra i codici continui troviamo i codici convoluzionali. Questi codificano un flusso di bit continuo. A differenza dei codici a blocchi, in cui i dati sono suddivisi in blocchi di codice e possono essere decodificati solo all'interno di blocchi integri. Un blocco di codice rappresenta i dati trasmessi e le informazioni ridondanti associate, necessarie per verificare la correttezza della ricezione dei dati e correggere eventuali errori. Tra i codici a blocchi ci sono i famosi codici di Reed-Solomon.

Se viene utilizzata la codifica a pacchetti, il flusso di bit iniziale viene inviato al decodificatore. Il risultato del suo lavoro (tutto ciò avviene, ovviamente, in modo continuo) sono i blocchi di dati CADU (unità di accesso ai dati del canale). Questa struttura è necessaria per la sincronizzazione dei fotogrammi. Alla fine di ogni CADU è associato un marcatore di sincronizzazione (ASM – marcatore di sincronizzazione allegato). Si tratta di 4 byte noti in anticipo, grazie ai quali il sincronizzatore trova l'inizio e la fine del CADU. Così si ottiene la sincronizzazione dei fotogrammi.

La successiva fase opzionale del lavoro del livello di sincronizzazione e codifica è legata alle peculiarità del livello fisico. Questa è la derandomizzazione. Infatti, per raggiungere la sincronizzazione simbolica sono necessari frequenti passaggi tra simboli. Quindi, se trasmettiamo, per esempio, un kilobyte di dati composto esclusivamente da uno, la sincronizzazione andrà persa. Per questo motivo, durante la trasmissione, i dati in entrata vengono mescolati con una sequenza pseudo-casuale periodica, in modo che la densità di zeri e uno sia uniforme.

Successivamente avviene la decodifica dei codici a blocchi, e ciò che rimane sarà il prodotto finale del livello di sincronizzazione e codifica: il fotogramma.

Livello di canale

Da un lato, il gestore del livello di canale riceve i fotogrammi, dall'altro lato li emette in pacchetti. Poiché formalmente la dimensione dei pacchetti non è limitata, per la loro trasmissione affidabile è necessario suddividerli in strutture più piccole: i fotogrammi. Qui considereremo due sottosezioni: separatamente per la telemetria (TM) e il telecontrol (TC).

Telemetria

In parole semplici, questi sono i dati che la stazione di terra riceve dal satellite. Tutte le informazioni trasmesse vengono suddivise in piccoli frammenti di lunghezza fissa: i fotogrammi, che contengono i dati trasmessi e i campi di servizio. Esaminiamo più dettagliatamente la struttura del fotogramma:

Iniziamo l'analisi con l'intestazione principale del fotogramma di telemetria. Poi mi permetterò di tradurre in alcune parti gli standard, dando anche alcune spiegazioni.

Il campo identificatore del canale principale (Master Channel ID) deve contenere il numero di versione del fotogramma e l'identificatore dell'apparecchio.

Ogni KA, secondo gli standard CCSDS, deve avere un identificatore unico, che consenta di determinare a quale apparecchio appartiene, avendo il fotogramma. Formalmente, è necessario presentare una richiesta di registrazione dell'apparato, e il suo nome, insieme all'identificatore, sarà pubblicato in fonti aperte. Tuttavia, spesso i produttori russi ignorano questa procedura, assegnando all'apparato un identificatore arbitrario. Il numero di versione del fotogramma aiuta a determinare quale versione degli standard viene utilizzata, per leggere correttamente il fotogramma. Qui considereremo solo lo standard più conservativo con la versione "0".

Nel campo dell'identificatore del canale virtuale (Virtual Channel ID) deve essere presente il VCID del canale da cui è stato ricevuto il pacchetto. Non ci sono limitazioni sulla scelta del VCID, in particolare i canali virtuali non devono necessariamente essere numerati in modo sequenziale.

Spesso sorge la necessità di multiplexare i dati trasmessi. A questo scopo esiste un meccanismo di canali virtuali. Ad esempio, il satellite Meteor-M2 trasmette un'immagine a colori nel range visibile, suddividendola in tre immagini in bianco e nero: ogni colore viene trasmesso nel proprio canale virtuale come pacchetto separato, anche se nella struttura dei suoi fotogrammi c'è qualche deviazione dagli standard.

Il campo del flag del Controllo Operativo deve essere un indicatore della presenza o dell'assenza del campo di Controllo Operativo nel fotogramma di telemetria. Questi 4 byte alla fine del fotogramma vengono utilizzati per mantenere un feedback durante il controllo della consegna dei fotogrammi di telecomando. Di questo parleremo più avanti.

I contatori dei fotogrammi del canale principale e del canale virtuale sono campi incrementati di uno ad ogni invio di fotogramma. Servono come indicatore che nessun fotogramma è andato perso.

Lo stato dei dati del fotogramma di telemetria consiste in altri due byte di flag e dati, di cui esamineremo solo alcuni.

Il campo del flag dell'intestazione secondaria (Secondary Header) deve essere un indicatore della presenza o dell'assenza dell'intestazione secondaria (Secondary Header) nel fotogramma di telemetria.

Se desiderato, è possibile aggiungere un'intestazione secondaria a ciascun fotogramma e inserire qualsiasi dato a propria discrezione.

Il campo del puntatore all'intestazione principale (First Header Pointer), quando il flag di sincronizzazione è impostato a «1», deve contenere la rappresentazione binaria della posizione del primo ottetto del primo pacchetto nel campo dati (Data Field) del frame di telemetria. La posizione è conteggiata da 0 in ordine crescente dall'inizio del campo dati. Se non c'è l'inizio del pacchetto nel campo dati del frame di telemetria, allora il campo del puntatore all'intestazione principale deve avere valore nella rappresentazione binaria «11111111111» (questo può verificarsi se un lungo pacchetto si estende su più frame).

Se nel campo dati è presente un pacchetto vuoto (Idle Data), il puntatore all'intestazione principale deve avere valore nella rappresentazione binaria «11111111110». Il ricevitore deve sincronizzare il flusso basandosi su questo campo. Questo campo garantisce il ripristino della sincronizzazione anche in caso di perdita di frame.

Cioè, il pacchetto può, per esempio, iniziare nel mezzo del 4° frame e terminare all'inizio del 20°. Questo campo serve proprio a trovare il suo inizio. Anche i pacchetti hanno un'intestazione, in cui è indicata la sua lunghezza, quindi, una volta trovato il puntatore all'intestazione principale, il gestore del livello di collegamento deve leggerlo, determinando così dove terminerà il pacchetto.
Se il campo di controllo degli errori è presente, deve essere incluso in ogni frame di telemetria per un certo canale fisico durante tutta la missione.

Questo campo viene calcolato utilizzando il metodo CRC. La procedura deve prendere n-16 bit del frame di telemetria e inserire il risultato del calcolo negli ultimi 16 bit.

Telecomandi

Il frame dei telecomandi ha diverse differenze sostanziali. Tra queste:

Altra struttura delle intestazioni
Lunghezza dinamica. Questo significa che la lunghezza del frame non è fissata rigidamente, come avviene nella telemetria, ma può variare a seconda dei pacchetti trasmessi.
Meccanismo di garanzia di consegna dei pacchetti. Cioè, il CA deve confermare dopo la ricezione la correttezza della ricezione dei frame oppure richiedere la rispedizione dal frame che potrebbe essere stato ricevuto con un errore non correggibile.

Molti campi ci sono già familiari dall'intestazione del frame di telemetria. Hanno la stessa funzione, quindi qui considereremo solo i nuovi campi.

Un bit del flag di bypass deve essere utilizzato per controllare la verifica dei frame sul ricevitore. Il valore "0" di questo flag deve indicare che il frame è di tipo A e la sua verifica deve essere effettuata secondo FARM. Il valore "1" di questo flag deve indicare al ricevitore che il frame è di tipo B e deve bypassare la verifica secondo FARM.

Questo flag informa il ricevitore se è necessario utilizzare il meccanismo di conferma della consegna dei frame, noto come FARM - Frame Acceptance and Reporting Mechanism.

Il flag del comando di controllo deve essere utilizzato per comprendere se il campo dati trasporta un comando o dei dati. Se il flag è uguale a "0", il campo dati deve contenere dati. Se il flag è uguale a "1", il campo dati deve contenere informazioni di controllo per FARM.
FARM è una macchina a stati finiti, i cui parametri possono essere configurati.

RSVD. SPARE – bit riservati.

Sembra che la CCSDS abbia piani per loro in futuro, e per la compatibilità con le versioni del protocollo hanno già riservato questi bit nelle versioni attuali dello standard.

Il campo di lunghezza dei frame deve contenere un numero in rappresentazione binaria, pari alla lunghezza del frame in ottetti meno uno.

Il campo dati del frame deve seguire immediatamente dopo l'intestazione senza spazi e contenere un intero numero di ottetti, che può avere una lunghezza massima di 1019 ottetti. Questo campo deve contenere o un blocco di dati del frame, o le informazioni del comando di controllo. Il blocco di dati del frame deve contenere:

un intero numero di ottetti di dati utente
l'intestazione del segmento seguita da un intero numero di ottetti di dati utente

Se l'intestazione è presente, il blocco dati deve contenere un Pacchetto, un insieme di Pacchetti o una sua parte. Un blocco dati senza intestazione non può contenere parti di Pacchetti, ma può contenere blocchi di dati di formato privato. Da ciò si deduce che l'intestazione è necessaria quando il blocco dati trasmesso non può essere contenuto in un singolo frame. Un blocco dati con intestazione è chiamato segmento.

Il campo dei flag di dimensione due bit deve contenere:

"01" — se la prima parte dei dati è contenuta nel blocco dati
"00" — se la parte centrale dei dati è contenuta nel blocco dati
"10" — se l'ultima parte dei dati è contenuta nel blocco dati
«11» – se non c’è divisione e nel blocco dati viene inserito un pacchetto intero o più pacchetti.

Il campo identificativo MAP deve contenere zeri se i canali MAP non vengono utilizzati.
A volte 6 bit riservati ai canali virtuali non sono sufficienti. E se è necessario multiplexare i dati su un numero maggiore di canali, si utilizzano altri 6 bit dall'intestazione del segmento.

FARM

Esaminiamo più in dettaglio il meccanismo di funzionamento del sistema di controllo della consegna dei pacchetti. Questo sistema prevede solo l'interazione con i pacchetti dei telecomandi a causa della loro importanza (i dati telemetrici possono sempre essere richiesti nuovamente, mentre il satellite deve ricevere chiaramente le istruzioni dalla stazione terrestre e obbedire sempre ai suoi comandi). Dunque, supponiamo di voler riprogrammare il nostro satellite e di inviare a bordo un file binario di 10 kilobyte. A livello di collegamento, il file viene suddiviso in 10 pacchetti (0, 1, …, 9) che vengono inviati uno dopo l'altro. Quando la trasmissione è completata, il satellite deve confermare la corretta ricezione del pacchetto o comunicare in quale pacchetto si è verificato un errore. Questa informazione viene inviata nel campo di controllo operativo nel pacchetto di telemetria successivo (oppure il satellite può iniziare l'invio di un pacchetto vuoto (idle frame), se non ha nulla da comunicare). In base ai dati telemetrici ricevuti, possiamo assicurarci che tutto sia a posto, altrimenti procediamo alla ritrasmissione del messaggio. Supponiamo che il satellite non abbia ricevuto il pacchetto n. 7. In tal caso, inviamo i pacchetti 7, 8, 9. Se non riceviamo risposta, il pacchetto viene inviato di nuovo interamente (e così via, finché non ci rendiamo conto che i tentativi sono vani).

Di seguito è riportata la struttura del campo di controllo operativo con la descrizione di alcuni campi. I dati contenuti in questo campo sono denominati CLCW – Communication Link Control Word.

Poiché dall'immagine si può facilmente intuire la funzione dei campi principali, e non è interessante guardare gli altri, nascondo la descrizione dettagliata sotto un spoiler.

Decodifica dei campi CLCWTipo di parola di controllo (Control Word Type):
Per questo tipo di parola di controllo deve contenere 0

Versione della parola di controllo (CLCW Version Number):
Per questo tipo di parola di controllo deve essere «00» nella rappresentazione in bit.

Campo di stato (Status Field):
L'uso di questo campo è definito per ciascuna missione separatamente. Può essere utilizzato per miglioramenti locali da diverse agenzie spaziali.

Identificatore del canale virtuale (Virtual Channel Identification):
Deve contenere l'identificatore del canale virtuale associato a questa parola di controllo.

Flag di accesso al canale fisico:
Il flag deve fornire informazioni sulla prontezza del livello fisico del ricevitore. Se il livello fisico del ricevitore non è pronto a ricevere i frame, il campo deve contenere «1», altrimenti «0».

Flag di errore di sincronizzazione:
Il flag può segnalare che il livello fisico sta operando con un livello di segnale insufficiente e il numero di frame rifiutati è troppo alto. L'uso di questo campo è facoltativo; se utilizzato, deve contenere «0» in presenza di sincronizzazione e «1» in assenza di essa.

Flag di blocco:
Questo bit deve contenere lo stato di blocco del FARM per ogni canale virtuale. Un valore di «1» in questo campo indica che il FARM è bloccato e i frame verranno scartati per ciascun livello virtuale, altrimenti «0».

Flag di attesa:
Questo bit deve essere utilizzato per indicare che il ricevitore non può elaborare i dati sul canale virtuale specificato. Un valore di «1» indica che tutti i frame verranno scartati su questo canale virtuale, altrimenti «0».

Flag di ritrasmissione:
Questo flag deve contenere «1» se uno o più frame di tipo A sono stati scartati o si sono verificate omissioni, quindi è necessaria una ritrasmissione. Il flag «0» indica che non ci sono stati frame scartati né omissioni.

Valore di risposta:
Numero del frame che non è stato accettato. Determinato dal contatore nell'intestazione del frame di comando.

Livello di rete

Affrontiamo brevemente anche questo livello. Qui ci sono due opzioni: utilizzare il protocollo di pacchetto spaziale oppure incapsulare qualsiasi altro protocollo in un pacchetto CCSDS.

Una panoramica del protocollo di pacchetto spaziale è un argomento per un articolo a parte. È stato creato affinché le cosiddette applicazioni possano scambiare dati in modo fluido. Ogni applicazione ha il proprio indirizzo e una funzionalità di base per lo scambio di dati con altre applicazioni. Ci sono anche servizi che effettuano il routing del traffico, monitorando la consegna e così via.

Con l'incapsulamento è tutto più semplice e chiaro. Gli standard consentono di incapsulare nei pacchetti CCSDS qualsiasi protocollo, aggiungendo un'intestazione aggiuntiva.

Dove l'intestazione ha diversi significati a seconda della lunghezza del protocollo incapsulato:

Qui il campo principale è la lunghezza. Può variare da 0 a 4 byte. Inoltre, in questa intestazione è necessario specificare il tipo di protocollo incapsulato, utilizzando la tabella da qui.

Durante l'incapsulamento IP viene utilizzato un ulteriore strato per determinare il tipo di pacchetto.
È necessario aggiungere un'altra intestazione, della lunghezza di un ottetto:

Dove PID è un altro identificatore di protocollo, prelevato da qui

Conclusione

A prima vista potrebbe sembrare che le intestazioni CCSDS siano estremamente ridondanti e che alcuni campi possano essere trascurati. In effetti, l'efficienza del canale risultante (fino al livello di rete) è circa del 40%. Tuttavia, una volta che si presenta la necessità di implementare questi standard, diventa chiaro che ogni campo, ogni intestazione ha la sua importante missione, la cui ignoranza porta a una serie di ambiguità.

Se la comunità di Habra mostra interesse per questo argomento, sarei felice di pubblicare un'altra serie di articoli dedicati alla teoria e alla pratica della comunicazione spaziale. Grazie per l'attenzione!