Satellite Meteora M1
Fonte: vladtime.ru
Introduzione
Il funzionamento della tecnologia spaziale è impossibile senza le comunicazioni radio e in questo articolo cercherò di spiegare le idee principali che hanno costituito la base degli standard sviluppati dal Comitato consultivo internazionale per i sistemi di dati spaziali (CCSDS. Questa abbreviazione verrà utilizzata di seguito) .
Questo post si concentrerà principalmente sul livello di collegamento dati, ma verranno introdotti anche i concetti di base per altri livelli. Questo articolo non pretende in alcun modo di essere una descrizione approfondita e completa degli standard. Puoi visualizzarlo su CCSD. Tuttavia, sono molto difficili da capire e abbiamo passato molto tempo a cercare di capirli, quindi qui voglio fornire le informazioni di base, con le quali sarà molto più facile capire tutto il resto. Quindi, cominciamo.
Nobile Missione del CCSDS
Forse qualcuno ha una domanda: perché tutti dovrebbero aderire agli standard se è possibile sviluppare un proprio stack di protocolli radio proprietario (o un 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:
- Il comitato responsabile della pubblicazione degli standard comprende rappresentanti di tutte le principali agenzie aerospaziali del mondo, portando con sé la preziosa esperienza acquisita in molti anni di progettazione e funzionamento di varie missioni. Sarebbe davvero assurdo ignorare questa esperienza e calpestare nuovamente il loro rastrello.
- Questi standard sono supportati dalle apparecchiature delle stazioni di terra già presenti sul mercato.
- Durante la risoluzione di eventuali problemi, puoi sempre chiedere aiuto ai colleghi di altre agenzie in modo che possano condurre una sessione di comunicazione con il dispositivo dalla loro stazione di terra. Come puoi vedere, gli standard sono estremamente utili, quindi diamo un'occhiata ai loro punti chiave.
Architettura
Gli standard sono un insieme di documenti che riflettono il modello OSI (Open System Interconnection) più comune, salvo che a livello di collegamento dati la comunanza è limitata alla divisione in telemetria (downlink - spazio - Terra) e telecomandi (uplink).
Diamo un'occhiata ad alcuni livelli in modo più dettagliato, iniziando da quello fisico e salendo. Per maggiore chiarezza considereremo l'architettura del lato ricevente. Quello che trasmette è la sua immagine speculare.
Strato fisico
A questo livello il segnale radio modulato viene convertito in un flusso di bit. Gli standard qui sono principalmente di natura consultiva, poiché a questo livello è difficile astrarre dall'implementazione specifica dell'hardware. In questo caso, il ruolo chiave del CCSDS è quello di definire le modulazioni accettabili (BPSK, QPSK, 8-QAM, ecc.) e fornire alcune raccomandazioni sull'implementazione dei meccanismi di sincronizzazione dei simboli, compensazione Doppler, ecc.
Livello di sincronizzazione e codifica
Formalmente è un sottolivello del livello di collegamento dati, ma è spesso separato in un livello separato a causa della sua importanza all'interno degli standard CCSDS. Questo livello converte il flusso di bit nei cosiddetti frame (telemetria o telecomandi), di cui parleremo più avanti. A differenza della sincronizzazione dei simboli a livello fisico, che consente di ottenere il flusso di bit corretto, qui viene eseguita la sincronizzazione dei frame. Considera il percorso che i dati seguono a questo livello (dal basso verso l'alto):
Tuttavia, prima di ciò, vale la pena spendere qualche parola sulla codifica. Questa procedura è necessaria per trovare e/o correggere errori di bit che inevitabilmente si verificano durante l'invio di dati su un canale radio. Qui non prenderemo in considerazione le procedure di decodifica, ma otterremo solo le informazioni necessarie per comprendere l'ulteriore logica del livello.
I codici possono essere a blocchi o continui. Gli standard non obbligano all'uso di un tipo specifico di codifica, ma deve essere presente come tale. I codici continui includono codici convoluzionali. Sono utilizzati per codificare un flusso di bit continuo. Ciò è in contrasto con i codici a blocchi, dove i dati sono divisi in blocchi di codice e possono essere decodificati solo all'interno di blocchi completi. Il blocco di codice rappresenta i dati trasmessi e le allegate informazioni ridondanti necessarie per verificare la correttezza dei dati ricevuti e correggere eventuali errori. I codici blocco includono i famosi codici Reed-Solomon.
Se viene utilizzata la codifica convoluzionale, il bitstream entra nel decodificatore dall'inizio. Il risultato del suo lavoro (tutto questo, ovviamente, avviene continuamente) sono i blocchi di dati CADU (channel access data unit). Questa struttura è necessaria per la sincronizzazione dei frame. Alla fine di ogni CADU è collegato un sincronizzatore (ASM). Si tratta di 4 byte conosciuti in anticipo, con i quali il sincronizzatore trova l'inizio e la fine del CADU. Ecco come si ottiene la sincronizzazione dei frame.
La successiva fase opzionale dello strato di sincronizzazione e codifica è associata alle peculiarità dello strato fisico. Questa è derandomizzazione. Il fatto è che per ottenere la sincronizzazione dei simboli è necessario un passaggio frequente tra i simboli. Quindi, se trasmettiamo, ad esempio, un kilobyte di dati costituiti interamente da unità, la sincronizzazione andrà persa. Pertanto, durante la trasmissione, i dati in ingresso vengono mescolati con una sequenza periodica pseudo-casuale in modo che la densità di zero e uno sia uniforme.
Successivamente, i codici del blocco vengono decodificati e ciò che rimane è il prodotto finale del livello di sincronizzazione e codifica: un frame.
Livello di collegamento dati
Da un lato il processore del livello di collegamento riceve i frame e dall'altro emette i pacchetti. Poiché la dimensione dei pacchetti non è formalmente limitata, per una loro trasmissione affidabile è necessario scomporli in strutture più piccole: i frame. Qui esamineremo due sottosezioni: separatamente per telemetria (TM) e telecomandi (TC).
telemetria
In poche parole, questi sono i dati che la stazione di terra riceve dal veicolo spaziale. Tutte le informazioni trasmesse sono divise in piccoli frammenti di lunghezza fissa: frame che contengono dati trasmessi e campi di servizio. Diamo uno sguardo più da vicino alla struttura del frame:
E iniziamo la nostra considerazione con l'intestazione principale del frame di telemetria. Inoltre, mi permetterò di tradurre semplicemente gli standard in alcuni punti, fornendo alcuni chiarimenti lungo il percorso.
Il campo Master Channel ID deve contenere il numero di versione del frame e l'identificatore del dispositivo.
Ogni veicolo spaziale, secondo gli standard CCSDS, deve avere un proprio identificatore univoco, grazie al quale, avendo un frame, è possibile determinare a quale dispositivo appartiene. Formalmente è necessario presentare una domanda per registrare il dispositivo e il suo nome, insieme al suo identificatore, sarà pubblicato in fonti aperte. Tuttavia, i produttori russi spesso ignorano questa procedura, assegnando al dispositivo un identificatore arbitrario. Il numero di versione del frame aiuta a determinare quale versione degli standard viene utilizzata per leggere correttamente il frame. Qui considereremo solo lo standard più conservativo con la versione “0”.
Il campo Virtual Channel ID deve contenere il VCID del canale da cui proviene il pacchetto. Non ci sono restrizioni sulla scelta del VCID; in particolare i canali virtuali non sono necessariamente numerati in modo sequenziale.
Molto spesso è necessario eseguire il multiplexing dei dati trasmessi. A questo scopo esiste un meccanismo di canali virtuali. Ad esempio, il satellite Meteor-M2 trasmette un'immagine a colori nella gamma visibile, dividendola in tre in bianco e nero: ciascun colore viene trasmesso nel proprio canale virtuale in un pacchetto separato, sebbene vi sia qualche deviazione dagli standard nel struttura dei suoi telai.
Il campo della bandiera di controllo operativo deve essere un indicatore della presenza o dell'assenza del campo di controllo operativo nel frame di telemetria. Questi 4 byte alla fine del frame servono a fornire un feedback quando si controlla la consegna dei frame di telecomando. Ne parleremo un po' più tardi.
I contatori di frame del canale principale e virtuale sono campi che vengono incrementati di uno ogni volta che viene inviato un frame. Servire come indicatore del fatto che non è stato perso un singolo fotogramma.
Lo stato dei dati del frame di telemetria è costituito da altri due byte di flag e dati, di cui ne esamineremo solo alcuni.
Il campo flag dell'intestazione secondaria deve essere un indicatore della presenza o dell'assenza di un'intestazione secondaria nel frame di telemetria.
Se lo desideri, puoi aggiungere un'intestazione aggiuntiva a ciascun frame e inserire lì i dati a tua discrezione.
Il campo First Header Pointer, quando il flag di sincronizzazione è impostato su 1, conterrà una rappresentazione binaria della posizione del primo ottetto del primo pacchetto nel campo dati del frame di telemetria. La posizione viene conteggiata da 0 in ordine crescente dall'inizio del campo dati. Se nel campo dati del frame di telemetria non c'è l'inizio del pacchetto, il campo puntatore al primo header deve avere il valore nella rappresentazione binaria "11111111111" (questo può accadere se un pacchetto lungo è distribuito su più frame ).
Se il campo dati contiene un pacchetto vuoto (Idle Data), allora il puntatore alla prima intestazione dovrebbe avere il valore nella rappresentazione binaria “11111111110”. Utilizzando questo campo, il ricevitore deve sincronizzare lo streaming. Questo campo garantisce che la sincronizzazione venga ripristinata anche se i frame vengono eliminati.
Cioè, un pacchetto può, ad esempio, iniziare a metà del 4° frame e terminare all'inizio del 20°. Questo campo viene utilizzato per trovarne l'inizio. I pacchetti hanno anche un'intestazione che ne specifica la lunghezza, quindi quando viene trovato un puntatore alla prima intestazione, il processore del livello di collegamento deve leggerlo, determinando così dove finirà il pacchetto.
Se è presente un campo di controllo degli errori, deve essere contenuto in ogni frame di telemetria per un particolare canale fisico durante 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.
Squadre televisive
Il frame di comando TV presenta numerose differenze significative. Tra loro:
- Diversa struttura dell'intestazione
- Lunghezza dinamica. Ciò significa che la lunghezza del frame non è fissata in modo rigido, come avviene nella telemetria, ma può variare a seconda dei pacchetti trasmessi.
- Meccanismo di garanzia della consegna dei pacchetti. Cioè, la navicella spaziale deve, dopo averlo ricevuto, confermare la correttezza della ricezione del frame, oppure richiedere l'inoltro da un frame che avrebbe potuto essere ricevuto con un errore non correggibile.
Molti campi ci sono già familiari dall'intestazione del frame di telemetria. Hanno lo stesso scopo, quindi qui considereremo solo i nuovi campi.
Un bit del flag di bypass deve essere utilizzato per controllare il controllo del frame sul ricevitore. Un valore "0" per questo flag indica che il frame è un frame di tipo A e deve essere verificato secondo FARM. Un valore "1" per questo flag dovrebbe indicare al ricevitore che il frame è un frame di tipo B e dovrebbe ignorare il controllo FARM.
Questo flag informa il ricevitore se utilizzare un meccanismo di riconoscimento della consegna del frame chiamato FARM - Frame Acceptance and Reporting Mechanism.
Il flag del comando di controllo deve essere utilizzato per capire se il campo dati trasporta un comando o dei dati. Se il flag è "0", il campo dati deve contenere dati. Se il flag è "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 CCSDS abbia dei piani per il futuro e per la compatibilità con le versioni precedenti del protocollo hanno riservato questi bit già nelle versioni attuali dello standard.
Il campo della lunghezza del frame deve contenere un numero nella rappresentazione in bit uguale alla lunghezza del frame in ottetti meno uno.
Il campo dati del frame deve seguire l'intestazione senza spazi e contenere un numero intero di ottetti, che può avere una lunghezza massima di 1019 ottetti. Questo campo deve contenere informazioni sul blocco dati del frame o sul comando di controllo. Il blocco dati del frame deve contenere:
- numero intero di ottetti di dati utente
- intestazione del segmento seguita da un numero intero di ottetti di dati utente
Se è presente un'intestazione, il blocco dati deve contenere un pacchetto, un insieme di pacchetti o parte di un pacchetto. Un blocco dati senza intestazione non può contenere parti di pacchetti, ma può contenere blocchi dati in formato privato. Ne consegue che è necessaria un'intestazione quando il blocco di dati trasmesso non rientra in un frame. Un blocco di dati che ha un'intestazione è chiamato segmento
Il campo flag a 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'ultimo dato si trova nel blocco dati
- “11” - se non c'è divisione e uno o più pacchetti rientrano interamente nel blocco dati.
Il campo MAP ID deve contenere zero se i canali MAP non vengono utilizzati.
A volte 6 bit assegnati 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.
AZIENDA AGRICOLA
Diamo uno sguardo più da vicino al meccanismo di funzionamento del sistema di controllo della consegna del personale. Questo sistema prevede di lavorare solo con frame di telecomandi data la loro importanza (la telemetria può sempre essere richiesta nuovamente, e la navicella deve sentire chiaramente la stazione di terra e obbedire sempre ai suoi comandi). Quindi, supponiamo di decidere di eseguire il reflash del nostro satellite e di inviargli un file binario di 10 kilobyte. A livello di collegamento, il file è diviso in 10 fotogrammi (0, 1, ..., 9), che vengono inviati uno per uno verso l'alto. Una volta completata la trasmissione, il satellite deve confermare la correttezza della ricezione del pacchetto, oppure segnalare su quale frame si è verificato l'errore. Questa informazione viene inviata al campo di controllo operativo nel frame telemetrico più vicino (oppure il veicolo spaziale può avviare la trasmissione di un frame inattivo se non ha nulla da dire). In base alla telemetria ricevuta, ci assicuriamo che tutto vada bene oppure procediamo a inviare nuovamente il messaggio. Supponiamo che il satellite non abbia sentito il frame n.7. Ciò significa che gli inviamo i frame 7, 8, 9. Se non c'è risposta, l'intero pacchetto viene inviato nuovamente (e così via più volte finché non ci accorgiamo che i tentativi sono vani).
Di seguito la struttura del campo di controllo operativo con la descrizione di alcuni campi. I dati contenuti in questo campo sono chiamati CLCW - Communication Link Control Word.
Dato che dall'immagine si intuisce facilmente lo scopo dei campi principali, e gli altri sono noiosi da guardare, nascondo la descrizione dettagliata sotto uno spoiler
Spiegazione dei campi CLCWTipo di parola di controllo:
Per questo tipo, la parola di controllo deve contenere 0
Versione della parola di controllo (numero di versione CLCW):
Per questo tipo la parola di controllo nella rappresentazione dei bit deve essere uguale a "00".
Campo stato:
L'uso di questo campo è determinato separatamente per ciascuna missione. Può essere utilizzato per miglioramenti locali da varie agenzie spaziali.
Identificazione del canale virtuale:
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 disponibilità dello strato fisico del ricevitore. Se il livello fisico del ricevitore non è pronto a ricevere frame, il campo deve contenere "1", altrimenti "0".
Flag di errore di sincronizzazione:
Il flag potrebbe indicare che il livello fisico funziona con un livello di segnale scarso e il numero di frame rifiutati è troppo elevato. L'utilizzo di questo campo è facoltativo; se utilizzato deve contenere “0” se la sincronizzazione è disponibile e “1” in caso contrario.
Flag di blocco:
Questo bit conterrà lo stato di blocco FARM per ciascun canale virtuale. Un valore "1" in questo campo dovrebbe indicare che FARM è disabilitato e i fotogrammi verranno scartati per ogni livello virtuale, altrimenti "0".
Bandiera di attesa:
Questo bit verrà utilizzato per indicare che il ricevitore non può elaborare i dati sul canale virtuale specificato. Un valore "1" indica che tutti i fotogrammi verranno scartati su questo canale virtuale, altrimenti "0".
Bandiera in avanti:
Questo flag deve contenere un "1" se uno o più frame di tipo A sono stati scartati o sono stati trovati dei gap, quindi è necessario un nuovo invio. Il flag "0" indica che non ci sono stati fotogrammi persi o salti.
Valore di risposta:
Numero di frame non ricevuto. Determinato dal contatore nell'intestazione del frame del telecomando
livello di rete
Tocchiamo un po' questo livello. Ci sono due opzioni qui: utilizzare il protocollo del pacchetto spaziale o incapsulare qualsiasi altro protocollo nel pacchetto CCSDS.
Una panoramica del protocollo dei pacchetti spaziali sarà argomento di un articolo separato. È progettato per consentire alle cosiddette applicazioni di scambiare dati senza problemi. Ogni applicazione ha il proprio indirizzo e funzionalità di base per lo scambio di dati con altre applicazioni. Esistono anche servizi che instradano il traffico, controllano la consegna, ecc.
Con l'incapsulamento tutto è più semplice e chiaro. Gli standard consentono di incapsulare qualsiasi protocollo nei pacchetti CCSDS aggiungendo un'intestazione aggiuntiva.
Dove l'intestazione ha significati diversi a seconda della lunghezza del protocollo da incapsulare:
Qui il campo principale è la lunghezza della lunghezza. Può variare da 0 a 4 byte. Anche in questa intestazione bisogna indicare il tipo di protocollo incapsulato utilizzando la tabella .
L'incapsulamento IP utilizza un altro componente aggiuntivo per determinare il tipo di pacchetto.
Devi aggiungere un'altra intestazione, lunga un ottetto:
Dove PID è un altro identificatore di protocollo preso
conclusione
A prima vista, potrebbe sembrare che le intestazioni CCSDS siano estremamente ridondanti e alcuni campi potrebbero essere scartati. Infatti, 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 titolo ha la propria importante missione, ignorare la quale porta a una serie di ambiguità.
Se la habrasociety mostra interesse per questo argomento, sarò lieto di pubblicare tutta una serie di articoli dedicati alla teoria e alla pratica delle comunicazioni spaziali. Grazie per l'attenzione!
fonti
PS
Non colpire troppo forte se trovi imprecisioni. Segnalateli e verranno risolti :)
Fonte: habr.com