🥇Un po' sugli standard delle comunicazioni spaziali

Satellite Meteor M1
Fonte: vladtime.ru

Introduzione

L'operazione delle attrezzature spaziali è impossibile senza comunicazioni radio, e in questo articolo cercherò di spiegare le idee fondamentali che stanno alla base degli standard sviluppati dal Comitato Consultivo per i Sistemi di Trasmissione Dati Spaziali (Consultative Committee for Space Data Systems – CCSDS. Questa abbreviazione sarà utilizzata in seguito).

Questa pubblicazione sarà principalmente dedicata al livello di canale, tuttavia verranno introdotti anche i concetti fondamentali per altri livelli. L'articolo non pretende in alcun modo di fornire una descrizione esaustiva e completa degli standard. Potete consultarlo su sito CCSDS. Tuttavia, sono molto complessi da comprendere e ci abbiamo messo molto tempo per decifrarli, quindi qui voglio fornire informazioni di base che renderanno più facile comprendere tutto il resto. Cominciamo.

La nobile missione di CCSDS

Potrebbe sorgere la domanda: perché dovremmo seguire gli standard, se possiamo sviluppare il nostro stack di protocolli di comunicazione radio proprietario (o il nostro standard, con blackjack e nuove funzionalità), aumentando così la sicurezza del sistema?

Come dimostra la pratica, è più vantaggioso attenersi agli standard CCSDS per una serie di motivi:

Nel comitato responsabile della pubblicazione degli standard sono rappresentati tutti i principali enti spaziali del mondo, portando la propria preziosa esperienza acquisita in molti anni di progettazione e operatività di varie missioni. Ignorare questa esperienza e ripetere gli stessi errori sarebbe veramente ridicolo.
Questi standard sono supportati dalle attrezzature esistenti sul mercato delle stazioni di terra.
In caso di problemi, è sempre possibile chiedere aiuto ai colleghi di altre agenzie, affinché effettuino una sessione di comunicazione con il veicolo spaziale dalla loro stazione di terra. Come vedete, gli standard sono estremamente utili, quindi esploriamo i loro punti chiave.

Architettura

Gli standard sono un insieme di documenti che riflettono il modello OSI (Open System Interconnection) di base, ad eccezione del fatto che a livello di collegamento le interazioni si limitano alla divisione tra telemetria (canale "giù" - spazio - Terra) e telecomandi (canale "su").

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

Livello fisico

A questo livello avviene la conversione del segnale radio modulato in un flusso di bit. Gli standard qui sono perlopiù raccomandativi, poiché a questo livello è difficile astrarsi dalla specifica implementazione hardware. La CCSDS gioca un ruolo chiave nel determinare le modulazioni ammissibili (BPSK, QPSK, 8-QAM, ecc.) e nel fornire alcune raccomandazioni per l'implementazione dei meccanismi di sincronizzazione dei simboli, compensazione dello spostamento Doppler, ecc.

Livello di sincronizzazione e codifica

Formalmente è un sottolivello del livello di collegamento, ma spesso viene considerato un livello separato per la sua importanza all'interno degli standard CCSDS. Questo livello converte il flusso di bit in quelli che comunemente chiamiamo frame (telemetria o telecomandi), di cui parleremo in seguito. A differenza della sincronizzazione simbolica a livello fisico, che consente di ottenere un flusso di bit corretto, qui si svolge la sincronizzazione dei frame. Esaminiamo il percorso che i dati percorrono a questo livello (dal basso verso l'alto):

Tuttavia, prima di ciò, è importante spendere qualche parola sul codifica. Questa procedura è necessaria per rilevare e/o correggere gli errori di bit, che inevitabilmente si verificano nella trasmissione dei dati attraverso il canale radio. Non ci soffermeremo sulle procedure di decodifica, ma ci concentreremo solo sulle informazioni necessarie per comprendere la logica operativa del livello.

I codici possono essere bloccati o continui. Gli standard non obbligano all'uso di un tipo specifico di codifica, ma essa deve essere comunque presente. I codici continui includono i codici convoluzionali. Con questi si codifica un flusso di bit continuo. A differenza dei codici bloccati, dove i dati sono suddivisi in blocchi di codice (codeblock), che possono essere decodificati solo all'interno di blocchi interi. 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. I codici bloccati includono i famosi codici di Reed-Solomon.

Se viene utilizzata la codifica convoluzionale, il flusso di bit viene inviato al decodificatore fin dall'inizio. Il risultato del suo lavoro (tutto ciò avviene, naturalmente, in modo continuo) è costituito da blocchi di dati CADU (channel access data unit). Questa struttura è necessaria per la sincronizzazione dei fotogrammi. Alla fine di ogni CADU è allegato un marcatore di sincronizzazione (ASM – attached synch maker). Questi sono 4 byte noti in anticipo, in base ai quali il sincronizzatore trova l'inizio e la fine del CADU. In questo modo si raggiunge la sincronizzazione dei fotogrammi.

La fase opzionale successiva del lavoro di sincronizzazione e codifica è legata alle peculiarità del livello fisico. Si tratta della derandomizzazione. Infatti, per raggiungere la sincronizzazione simbolica è necessario passare frequentemente tra simboli. Quindi, se trasmettiamo, ad esempio, un kilobyte di dati composto esclusivamente da uno, la sincronizzazione verrà persa. Per questo motivo, durante la trasmissione, i dati in ingresso vengono mescolati con una sequenza pseudocasuale periodica, in modo che la densità di zeri e uno sia uniforme.

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

Livello di collegamento

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

Telemetria

In altre parole, questi sono i dati che la stazione di terra riceve dal satellite. Tutte le informazioni trasmesse sono suddivise in piccoli frammenti di lunghezza fissa – i fotogrammi, che contengono dati trasmessi e campi di controllo. Analizziamo più nel dettaglio la struttura del fotogramma:

Iniziamo l'analisi con l'intestazione principale del fotogramma di telemetria. In seguito, permettetemi di tradurre alcuni standard, fornendo al contempo alcune spiegazioni.

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

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

Nel campo dell'identificatore del canale virtuale (Virtual Channel ID) deve essere presente il VCID del canale dal quale è stato ricevuto il pacchetto. Non ci sono restrizioni nella scelta del VCID, ad esempio i canali virtuali non devono necessariamente essere numerati in modo sequenziale.

È molto comune 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 canali bianco e nero: ogni colore viene trasmesso nel proprio canale virtuale come pacchetto separato, anche se nella struttura dei suoi fotogrammi ci sono alcune deviazioni dagli standard.

Il campo del flag di Controllo Operativo deve essere un indicatore della presenza o assenza del campo di Controllo Operativo nel fotogramma di telemetria. Questi 4 byte alla fine del fotogramma servono a mantenere un feedback durante il controllo della consegna dei fotogrammi di comando. Di questo ne parleremo più avanti.

I contatori dei fotogrammi del canale principale e virtuale sono campi che vengono incrementati di uno ad ogni invio di fotogramma. Servono come indicatore del fatto che nessun fotogramma è stato 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 assenza dell'intestazione secondaria (Secondary Header) nel fotogramma di telemetria.

Se desiderato, è possibile aggiungere un titolo aggiuntivo a ciascun frame e inserire qualsiasi dato a propria discrezione.

Il campo del puntatore al primo titolo (First Header Pointer), quando il flag di sincronizzazione è impostato su «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 viene conteggiata da 0 in ordine crescente dall'inizio del campo dati. Se non c'è inizio del pacchetto nel campo dati del frame di telemetria, allora il campo del puntatore al primo titolo deve avere il valore in rappresentazione binaria «11111111111» (questo può accadere se un lungo pacchetto si estende su più di un frame).

Se nel campo dati è presente un pacchetto vuoto (Idle Data), allora il puntatore al primo titolo deve avere il valore in rappresentazione binaria «11111111110». In base a questo campo, il ricevitore deve effettuare la sincronizzazione del flusso. Questo campo garantisce il ripristino della sincronizzazione anche in caso di caduta dei frame.

Cioè, il pacchetto può, ad esempio, iniziare a metà del quarto fotogramma e terminare all'inizio del ventesimo. Questo campo serve proprio per trovare l'inizio. Anche i pacchetti hanno un'intestazione, che specifica la sua lunghezza, quindi quando si trova il puntatore alla prima intestazione, il gestore del livello del canale deve leggerla, determinando così dove il pacchetto si concluderà.
Se è presente un campo di controllo degli errori, deve essere contenuto in ogni fotogramma di telemetria per un determinato canale fisico durante tutta la missione.

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

Telecomandi

Il fotogramma dei telecomandi presenta alcune differenze sostanziali. Tra queste:

Struttura delle intestazioni diversa
Lunghezza dinamica. Questo significa che la lunghezza del fotogramma non è impostata rigidamente, come avviene nella telemetria, ma può variare a seconda dei pacchetti trasmessi.
Meccanismo di garanzia della consegna dei pacchetti. Ciò significa che il KА deve confermare la correttezza della ricezione dei frame dopo averli ricevuti, oppure richiedere un reinvio 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 tratteremo solo i nuovi campi.

Un bit del flag di bypass deve essere utilizzato per il controllo della 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 il FARM. Il valore "1" di questo flag deve indicare al ricevitore che il frame è di tipo B e deve saltare il controllo secondo il 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 della gestione del comando dovrebbe 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 è un automa a stati finiti, i cui parametri possono essere configurati.

RSVD. SPARE – bit riservati.

Sembra che CCSDS abbia piani per questi in futuro e per garantire la retrocompatibilità delle versioni del protocollo hanno già riservato questi bit nelle versioni attuali dello standard.

Il campo di lunghezza del frame dovrebbe contenere un numero in rappresentazione bit, che è uguale alla lunghezza del frame in ottetti meno uno.

Il campo dati del frame deve seguire dopo l'intestazione senza interruzioni e deve contenere un intero numero di ottetti, con una lunghezza massima di 1019 ottetti. Questo campo deve contenere o un blocco di dati del frame, o informazioni sul comando. Il blocco di dati del frame deve contenere:

un intero numero di ottetti di dati utente
l'intestazione del segmento e l'intero numero di ottetti di dati utente che seguono

Se è presente un'intestazione, il blocco dati deve contenere un Pacchetto, più Pacchetti o una loro parte. Un blocco dati senza intestazione non può contenere parti di Pacchetti, ma può contenere blocchi dati di formato privato. Ne consegue che l'intestazione è necessaria quando il blocco dati trasmesso non può essere contenuto in un unico frame. Un blocco dati con intestazione è chiamato segmento.

Il campo flag di due bit deve contenere:

«01» — se la prima parte dei dati si trova nel blocco dati
«00» — se la parte centrale dei dati si trova nel blocco dati
«10» — se l'ultima parte dei dati si trova nel blocco dati
«11» — se non c'è suddivisione e nel blocco dati è contenuto interamente uno o più pacchetti.

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

FARM

Esaminiamo più da vicino il meccanismo di funzionamento del sistema di controllo della consegna dei fotogrammi. Questo sistema prevede esclusivamente l'uso dei fotogrammi dei telecomandi data la loro importanza (le telemetrie possono sempre essere richieste di nuovo, ma il veicolo spaziale deve sentire chiaramente la stazione a terra e deve sempre obbedire ai suoi comandi). Supponiamo di voler riprogrammare il nostro satellite e di inviare a bordo un file binario di 10 kilobyte. A livello di canale, il file viene suddiviso in 10 fotogrammi (0, 1, …, 9), che vengono inviati uno dopo l'altro. Quando il trasferimento è completato, il veicolo spaziale deve confermare la correttezza della ricezione del pacchetto o segnalare in quale fotogramma si è verificato l'errore. Queste informazioni vengono inviate nel campo di controllo operativo nel fotogramma di telemetria successivo (oppure il veicolo spaziale può iniziare la trasmissione di un fotogramma vuoto (idle frame) se non ha nulla da comunicare). Dalla telemetria ricevuta possiamo assicurarci che tutto sia a posto oppure procedere a ritrasmettere il messaggio. Supponiamo che il satellite non abbia ricevuto il fotogramma n. 7. Quindi, inviamo i fotogrammi 7, 8, 9. In caso di mancata risposta, il pacchetto viene inviato nuovamente per intero (e così via per diverse volte, finché non comprendiamo che i tentativi sono vani).

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

Poiché dall'immagine è possibile intuire a cosa servono i campi principali, mentre per gli altri è noioso guardare, nascondo la descrizione dettagliata sotto spoiler.

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

Versione della parola di controllo (CLCW Version Number):
Questo tipo di parola di controllo deve essere uguale a «00» in rappresentazione binaria.

Campo di stato (Status Field):
L'uso di questo campo è determinato 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 a cui è associata 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 funziona con un segnale scarso e che il numero di fotogrammi scartati è troppo elevato. L'uso di questo campo è facoltativo; se viene utilizzato, deve contenere «0» in caso di sincronizzazione, e «1» in assenza di essa.

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

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

Flag di rinvio:
Questo flag deve contenere «1» se uno o più fotogrammi di tipo A sono stati scartati o si sono riscontrate perdite, quindi è necessario un rinvio. Un flag di «0» indica che non ci sono stati fotogrammi scartati o perdite.

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

Livello di rete

Tratteremo brevemente anche questo livello. Qui sono possibili due opzioni: utilizzare il protocollo del pacchetto spaziale oppure incapsulare qualsiasi altro protocollo in un pacchetto CCSDS.

Una panoramica del protocollo del pacchetto spaziale è un argomento per un articolo a parte. È progettato affinché le cosiddette applicazioni possano scambiare dati senza soluzione di continuità. Ogni applicazione ha il proprio indirizzo ed una funzionalità di base per lo scambio di dati con altre applicazioni. Ci sono anche servizi che si occupano della routing del traffico, controllo della consegna, ecc.

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

Qui 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 del protocollo incapsulato, utilizzando una tabella. da qui.

Nell'incapsulazione IP viene utilizzato un ulteriore strato per definire il tipo di pacchetto.
È necessario aggiungere un'altra intestazione, della lunghezza di un ottetto:

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

Conclusione

A prima vista, potrebbe sembrare che le intestazioni CCSDS siano estremamente ridondanti e che alcuni campi possano essere eliminati. Effettivamente, l'efficienza del canale risultante (fino al livello di rete) è di circa il 40%. Tuttavia, non appena 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 Habr mostra interesse per questo argomento, sarò felice di pubblicare una serie di articoli dedicati alla teoria e alla pratica delle comunicazioni spaziali. Grazie per l'attenzione!