{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Un po' sugli standard delle comunicazioni spaziali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Un
\nSatellite Meteor M1
\nFonte: vladtime.ru<\/i><\/p>\n

Introduzione<\/h2>\n

\nL'operazione della tecnologia spaziale \u00e8 impossibile senza le comunicazioni radio, e in questo articolo cercher\u00f2 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 \u2013 CCSDS. In seguito utilizzer\u00f2 questa abbreviazione).<\/p>\n

Questa pubblicazione sar\u00e0 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. \u00c8 possibile consultarli su sito<\/a><\/noindex> 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\u00e0 molto pi\u00f9 facile. Iniziamo.
\n<\/a><\/noindex><\/p>\n

Nobile missione del CCSDS<\/h2>\n

\n\u00c8 possibile che qualcuno si chieda: perch\u00e9 tutti dovrebbero attenersi agli standard, se si pu\u00f2 sviluppare il proprio stack proprietario di protocolli di comunicazione (o il proprio standard, con blackjack e nuove funzionalit\u00e0), aumentando cos\u00ec la sicurezza del sistema?<\/p>\n

Come dimostra la pratica, \u00e8 pi\u00f9 vantaggioso aderire agli standard CCSDS per i seguenti motivi:<\/p>\n

    \n
  1. 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.<\/li>\n
  2. Questi standard sono supportati dall'attrezzatura esistente sul mercato delle stazioni di terra.<\/li>\n
  3. In caso di risoluzione di eventuali malfunzionamenti, \u00e8 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.<\/li>\n<\/ol>\n

    <\/p>\n

    Architettura<\/h2>\n

    \nGli standard sono un insieme di documenti che riflettono il modello OSI (Open System Interconnection) pi\u00f9 comune, con l'eccezione che, a livello di canale, la generalit\u00e0 \u00e8 limitata alla suddivisione in telemetria (canale \"verso il basso\" \u2013 spazio \u2013 Terra) e telecomandi (canale \"verso l'alto\").<\/p>\n

    \"Un
    \n
    \nEsaminiamo 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.<\/p>\n

    Livello fisico<\/h2>\n

    \nA questo livello avviene la trasformazione del segnale radio modulato in un flusso di bit. Gli standard qui sono principalmente di tipo raccomandato, poich\u00e9 a questo livello \u00e8 difficile astrarsi dall'implementazione specifica dell'hardware. Qui il ruolo chiave di CCSDS \u00e8 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.<\/p>\n

    Livello di sincronizzazione e codifica<\/h2>\n

    \nFormalmente \u00e8 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\u00f9 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):<\/p>\n

    \"Un
    \n
    \nTuttavia, prima di questo, \u00e8 opportuno dire alcune parole sulla codifica. Questa procedura \u00e8 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. <\/p>\n

    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.<\/p>\n

    Se viene utilizzata la codifica a pacchetti, il flusso di bit iniziale viene inviato al decodificatore. Il risultato del suo lavoro (tutto ci\u00f2 avviene, ovviamente, in modo continuo) sono i blocchi di dati CADU (unit\u00e0 di accesso ai dati del canale). Questa struttura \u00e8 necessaria per la sincronizzazione dei fotogrammi. Alla fine di ogni CADU \u00e8 associato un marcatore di sincronizzazione (ASM \u2013 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\u00ec si ottiene la sincronizzazione dei fotogrammi.<\/p>\n

    La successiva fase opzionale del lavoro del livello di sincronizzazione e codifica \u00e8 legata alle peculiarit\u00e0 del livello fisico. Questa \u00e8 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\u00e0 persa. Per questo motivo, durante la trasmissione, i dati in entrata vengono mescolati con una sequenza pseudo-casuale periodica, in modo che la densit\u00e0 di zeri e uno sia uniforme.<\/p>\n

    Successivamente avviene la decodifica dei codici a blocchi, e ci\u00f2 che rimane sar\u00e0 il prodotto finale del livello di sincronizzazione e codifica: il fotogramma.<\/p>\n

    Livello di canale<\/h2>\n

    \nDa un lato, il gestore del livello di canale riceve i fotogrammi, dall'altro lato li emette in pacchetti. Poich\u00e9 formalmente la dimensione dei pacchetti non \u00e8 limitata, per la loro trasmissione affidabile \u00e8 necessario suddividerli in strutture pi\u00f9 piccole: i fotogrammi. Qui considereremo due sottosezioni: separatamente per la telemetria (TM) e il telecontrol (TC).<\/p>\n

    Telemetria<\/h3>\n

    \nIn 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\u00f9 dettagliatamente la struttura del fotogramma:<\/p>\n

    \"Un
    \n
    \nIniziamo l'analisi con l'intestazione principale del fotogramma di telemetria. Poi mi permetter\u00f2 di tradurre in alcune parti gli standard, dando anche alcune spiegazioni.<\/p>\n

    \"Un
    \n
    \nIl campo identificatore del canale principale (Master Channel ID) deve contenere il numero di versione del fotogramma e l'identificatore dell'apparecchio.<\/p>\n

    Ogni KA, secondo gli standard CCSDS, deve avere un identificatore unico, che consenta di determinare a quale apparecchio appartiene, avendo il fotogramma. Formalmente, \u00e8 necessario presentare una richiesta di registrazione dell'apparato, e il suo nome, insieme all'identificatore, sar\u00e0 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\u00f9 conservativo con la versione \"0\".<\/i><\/p>\n

    Nel campo dell'identificatore del canale virtuale (Virtual Channel ID) deve essere presente il VCID del canale da cui \u00e8 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.<\/p>\n

    Spesso sorge la necessit\u00e0 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'\u00e8 qualche deviazione dagli standard.<\/i><\/p>\n

    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\u00f9 avanti.<\/p>\n

    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 \u00e8 andato perso.<\/i><\/p>\n

    Lo stato dei dati del fotogramma di telemetria consiste in altri due byte di flag e dati, di cui esamineremo solo alcuni.<\/p>\n

    \"Un
    \n
    \nIl 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.<\/p>\n

    Se desiderato, \u00e8 possibile aggiungere un'intestazione secondaria a ciascun fotogramma e inserire qualsiasi dato a propria discrezione.<\/i><\/p>\n

    Il campo del puntatore all'intestazione principale (First Header Pointer), quando il flag di sincronizzazione \u00e8 impostato a \u00ab1\u00bb, deve contenere la rappresentazione binaria della posizione del primo ottetto del primo pacchetto nel campo dati (Data Field) del frame di telemetria. La posizione \u00e8 conteggiata da 0 in ordine crescente dall'inizio del campo dati. Se non c'\u00e8 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 \u00ab11111111111\u00bb (questo pu\u00f2 verificarsi se un lungo pacchetto si estende su pi\u00f9 frame). <\/p>\n

    Se nel campo dati \u00e8 presente un pacchetto vuoto (Idle Data), il puntatore all'intestazione principale deve avere valore nella rappresentazione binaria \u00ab11111111110\u00bb. Il ricevitore deve sincronizzare il flusso basandosi su questo campo. Questo campo garantisce il ripristino della sincronizzazione anche in caso di perdita di frame.<\/p>\n

    Cio\u00e8, il pacchetto pu\u00f2, per esempio, iniziare nel mezzo del 4\u00b0 frame e terminare all'inizio del 20\u00b0. Questo campo serve proprio a trovare il suo inizio. Anche i pacchetti hanno un'intestazione, in cui \u00e8 indicata la sua lunghezza, quindi, una volta trovato il puntatore all'intestazione principale, il gestore del livello di collegamento deve leggerlo, determinando cos\u00ec dove terminer\u00e0 il pacchetto.<\/i>
    \nSe il campo di controllo degli errori \u00e8 presente, deve essere incluso in ogni frame di telemetria per un certo canale fisico durante tutta la missione.<\/p>\n

    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.<\/p>\n

    Telecomandi<\/h4>\n

    \nIl frame dei telecomandi ha diverse differenze sostanziali. Tra queste:<\/p>\n

      \n
    1. Altra struttura delle intestazioni<\/li>\n
    2. Lunghezza dinamica. Questo significa che la lunghezza del frame non \u00e8 fissata rigidamente, come avviene nella telemetria, ma pu\u00f2 variare a seconda dei pacchetti trasmessi.<\/li>\n
    3. Meccanismo di garanzia di consegna dei pacchetti. Cio\u00e8, 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.<\/li>\n<\/ol>\n

      \n\"Un
      \n
      \n\"Un
      \n
      \nMolti campi ci sono gi\u00e0 familiari dall'intestazione del frame di telemetria. Hanno la stessa funzione, quindi qui considereremo solo i nuovi campi.<\/p>\n

      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 \u00e8 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 \u00e8 di tipo B e deve bypassare la verifica secondo FARM.<\/p>\n

      Questo flag informa il ricevitore se \u00e8 necessario utilizzare il meccanismo di conferma della consegna dei frame, noto come FARM - Frame Acceptance and Reporting Mechanism.<\/i><\/p>\n

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

      RSVD. SPARE \u2013 bit riservati.<\/p>\n

      Sembra che la CCSDS abbia piani per loro in futuro, e per la compatibilit\u00e0 con le versioni del protocollo hanno gi\u00e0 riservato questi bit nelle versioni attuali dello standard.<\/i><\/p>\n

      Il campo di lunghezza dei frame deve contenere un numero in rappresentazione binaria, pari alla lunghezza del frame in ottetti meno uno.<\/p>\n

      Il campo dati del frame deve seguire immediatamente dopo l'intestazione senza spazi e contenere un intero numero di ottetti, che pu\u00f2 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:<\/p>\n