Satèl·lit Meteor M1
Font: vladtime.ru
Introducció
El funcionament de la tecnologia espacial és impossible sense les comunicacions per ràdio, i en aquest article intentaré explicar les idees principals que van formar la base dels estàndards desenvolupats pel Comitè Assessor Internacional per a Sistemes de Dades Espacials (CCSDS. Aquesta abreviatura s'utilitzarà a continuació) .
Aquesta publicació se centrarà principalment en la capa d'enllaç de dades, però també s'introduiran conceptes bàsics per a altres capes. Aquest article de cap manera pretén ser una descripció exhaustiva i completa dels estàndards. El podeu veure a CCSDS. No obstant això, són molt difícils d'entendre, i hem dedicat molt de temps intentant-los entendre, així que aquí vull aportar informació bàsica, tenint en compte que serà molt més fàcil d'entendre tota la resta. Així doncs, comencem.
Noble Missió del CCSDS
Potser algú té una pregunta: per què tothom hauria d'adherir-se als estàndards si podeu desenvolupar la vostra pròpia pila de protocols de ràdio propietari (o el vostre propi estàndard, amb blackjack i noves funcions), augmentant així la seguretat del sistema?
Com mostra la pràctica, és més rendible adherir-se als estàndards CCSDS per les següents raons:
- El comitè responsable de publicar els estàndards inclou representants de totes les agències aeroespacials importants del món, que aporten una experiència inestimable adquirida durant molts anys de disseny i operació de diverses missions. Seria molt absurd ignorar aquesta experiència i tornar a trepitjar el seu rastell.
- Aquests estàndards són compatibles amb equips d'estacions terrestres que ja estan al mercat.
- Quan solucioneu qualsevol problema, sempre podeu demanar ajuda a col·legues d'altres agències perquè puguin realitzar una sessió de comunicació amb el dispositiu des de la seva estació terrestre. Com podeu veure, els estàndards són una cosa molt útil, així que mirem els seus punts clau.
arquitectura
Els estàndards són un conjunt de documents que reflecteixen el model OSI (Open System Interconnection) més comú, excepte que a nivell d'enllaç de dades la comuna es limita a la divisió en telemetria (enllaç descendent - espai - Terra) i telecomandaments (enllaç ascendent).
Vegem alguns dels nivells amb més detall, començant pel físic i pujant. Per a una major claredat, tindrem en compte l'arquitectura del costat receptor. El transmissor és la seva imatge mirall.
Capa física
En aquest nivell, el senyal de ràdio modulat es converteix en un flux de bits. Els estàndards aquí són principalment de caràcter consultiu, ja que en aquest nivell és difícil abstraure's de la implementació específica del maquinari. Aquí, el paper clau de CCSDS és definir les modulacions acceptables (BPSK, QPSK, 8-QAM, etc.) i donar algunes recomanacions sobre la implementació de mecanismes de sincronització de símbols, compensació Doppler, etc.
Nivell de sincronització i codificació
Formalment, és una subcapa de la capa d'enllaç de dades, però sovint es separa en una capa separada a causa de la seva importància dins dels estàndards CCSDS. Aquesta capa converteix el flux de bits en els anomenats frames (telemetria o teleordres), dels quals parlarem més endavant. A diferència de la sincronització de símbols a la capa física, que us permet obtenir el flux de bits correcte, aquí es realitza la sincronització de fotogrames. Considereu el camí que prenen les dades en aquest nivell (de baix a dalt):
Tanmateix, abans d'això, val la pena dir algunes paraules sobre la codificació. Aquest procediment és necessari per trobar i/o corregir errors de bits que es produeixen inevitablement quan s'envien dades a través d'un canal de ràdio. Aquí no considerarem els procediments de descodificació, sinó que només obtindrem la informació necessària per entendre la lògica posterior del nivell.
Els codis poden ser blocs o continus. Els estàndards no obliguen a utilitzar un tipus concret de codificació, però ha d'estar present com a tal. Els codis continus inclouen codis convolucionals. S'utilitzen per codificar un flux de bits continu. Això contrasta amb els codis de bloc, on les dades es divideixen en blocs de codi i només es poden descodificar dins de blocs complets. El bloc de codi representa les dades transmeses i la informació redundant adjunta necessària per verificar la correcció de les dades rebudes i corregir possibles errors. Els codis de bloc inclouen els famosos codis Reed-Solomon.
Si s'utilitza la codificació convolucional, el flux de bits entra al descodificador des del principi. El resultat del seu treball (tot això, per descomptat, passa contínuament) són blocs de dades CADU (unitat de dades d'accés al canal). Aquesta estructura és necessària per a la sincronització de fotogrames. Al final de cada CADU hi ha un fabricant de sincronització adjunt (ASM). Són 4 bytes coneguts per endavant, pels quals el sincronitzador troba l'inici i el final de la CADU. Així és com s'aconsegueix la sincronització de fotogrames.
La següent etapa opcional de la capa de sincronització i codificació està associada a les peculiaritats de la capa física. Això és desaleatorització. El fet és que per aconseguir la sincronització de símbols, és necessari un canvi freqüent entre símbols. Per tant, si transmetem, per exemple, un kilobyte de dades formats completament per uns, es perdrà la sincronització. Per tant, durant la transmissió, les dades d'entrada es barregen amb una seqüència pseudoaleatoria periòdica de manera que la densitat de zeros i uns sigui uniforme.
A continuació, es descodifiquen els codis de bloc i el que queda és el producte final del nivell de sincronització i codificació: un marc.
Capa d'enllaç de dades
D'una banda, el processador de la capa d'enllaç rep trames i, de l'altra, emet paquets. Com que la mida dels paquets no està limitada formalment, per a la seva transmissió fiable cal descompondre'ls en estructures més petites: marcs. Aquí veurem dues subseccions: per separat per a telemetria (TM) i telecomandaments (TC).
Telemetria
En poques paraules, aquestes són les dades que l'estació terrestre rep de la nau espacial. Tota la informació transmesa es divideix en petits fragments de longitud fixa: trames que contenen dades transmeses i camps de servei. Fem una ullada més de prop a l'estructura del marc:
I comencem la nostra consideració amb la capçalera principal del marc de telemetria. A més, em permetré simplement traduir els estàndards en alguns llocs, donant alguns aclariments al llarg del camí.
El camp Master Channel ID ha de contenir el número de versió de la trama i l'identificador del dispositiu.
Cada nau espacial, segons els estàndards CCSDS, ha de tenir el seu propi identificador únic, pel qual, tenint un marc, es pot determinar a quin dispositiu pertany. Formalment, cal presentar una sol·licitud per registrar el dispositiu, i el seu nom, juntament amb el seu identificador, es publicarà en fonts obertes. Tanmateix, els fabricants russos sovint ignoren aquest procediment, assignant un identificador arbitrari al dispositiu. El número de versió del marc ajuda a determinar quina versió dels estàndards s'utilitza per llegir correctament el marc. Aquí considerarem només l'estàndard més conservador amb la versió "0".
El camp ID del canal virtual ha de contenir el VCID del canal del qual prové el paquet. No hi ha restriccions en l'elecció de VCID; en particular, els canals virtuals no estan necessàriament numerats seqüencialment.
Molt sovint hi ha la necessitat de multiplexar les dades transmeses. Per a això, hi ha un mecanisme de canals virtuals. Per exemple, el satèl·lit Meteor-M2 transmet una imatge en color en el rang visible, dividint-la en tres en blanc i negre; cada color es transmet en el seu propi canal virtual en un paquet separat, tot i que hi ha alguna desviació dels estàndards en el estructura dels seus marcs.
El camp de la bandera de control operacional ha de ser un indicador de la presència o absència del camp de control operacional a la trama de telemetria. Aquests 4 bytes al final de la trama serveixen per proporcionar retroalimentació quan es controla el lliurament de trames de telecomandament. En parlarem una mica més endavant.
Els comptadors de trames del canal principal i virtual són camps que s'incrementen en un cada vegada que s'envia una trama. Serviu com a indicador que no s'ha perdut cap fotograma.
L'estat de les dades del marc de telemetria és de dos bytes més de banderes i dades, dels quals només en veurem alguns.
El camp de senyalització de la capçalera secundària ha de ser un indicador de la presència o absència d'una capçalera secundària al marc de telemetria.
Si ho desitgeu, podeu afegir una capçalera addicional a cada fotograma i col·locar-hi les dades segons el vostre criteri.
El camp First Header Pointer, quan el indicador de sincronització s'estableix en 1, ha de contenir una representació binària de la posició del primer octet del primer paquet al camp de dades de la trama de telemetria. La posició es compta des de 0 en ordre ascendent des de l'inici del camp de dades. Si no hi ha cap inici del paquet al camp de dades de la trama de telemetria, aleshores el camp del punter a la primera capçalera ha de tenir el valor en representació binària "11111111111" (això pot passar si un paquet llarg s'estén per més d'una trama). ).
Si el camp de dades conté un paquet buit (Dades inactius), el punter a la primera capçalera hauria de tenir el valor en representació binària "11111111110". Amb aquest camp, el receptor ha de sincronitzar el flux. Aquest camp garanteix que la sincronització es restableixi encara que s'eliminin fotogrames.
És a dir, un paquet pot, per exemple, començar a la meitat del quart fotograma i acabar a principis del 4. Aquest camp s'utilitza per trobar el seu inici. Els paquets també tenen una capçalera que especifica la seva longitud, de manera que quan es troba un punter a la primera capçalera, el processador de la capa d'enllaç l'ha de llegir, determinant així on acabarà el paquet.
Si hi ha un camp de control d'errors, s'ha d'incloure a cada trama de telemetria per a un canal físic concret durant tota la missió.
Aquest camp es calcula mitjançant el mètode CRC. El procediment ha de prendre n-16 bits de la trama de telemetria i inserir el resultat del càlcul als darrers 16 bits.
equips de televisió
El marc de comandament de TV té diverses diferències significatives. Entre ells:
- Estructura de capçaleres diferent
- Longitud dinàmica. Això vol dir que la longitud de la trama no s'estableix de manera rígida, com es fa en telemetria, sinó que pot variar en funció dels paquets transmesos.
- Mecanisme de garantia de lliurament de paquets. És a dir, la nau espacial ha de, després de rebre-la, confirmar la correcció de la recepció de la trama, o sol·licitar l'enviament d'una trama que s'hauria pogut rebre amb un error incorregible.
Molts camps ja ens són familiars des de la capçalera del marc de telemetria. Tenen el mateix propòsit, així que aquí considerarem només els nous camps.
S'ha d'utilitzar un bit de la bandera de bypass per controlar la comprovació de trama al receptor. Un valor de "0" per a aquesta bandera indicarà que la trama és una trama de tipus A i s'ha de verificar segons FARM. Un valor de "1" per a aquesta bandera hauria d'indicar al receptor que la trama és una trama de tipus B i hauria d'evitar la comprovació FARM.
Aquest indicador informa al receptor si ha d'utilitzar un mecanisme de reconeixement de lliurament de trames anomenat FARM - Mecanisme d'acceptació i notificació de trames.
El senyal d'ordre de control s'ha d'utilitzar per entendre si el camp de dades transporta una ordre o dades. Si el senyalador és "0", el camp de dades ha de contenir dades. Si el senyalador és "1", el camp de dades ha de contenir informació de control per a FARM.
FARM és una màquina d'estats finits els paràmetres de la qual es poden configurar.
RSVD. RECANVI: bits reservats.
Sembla que CCSDS té plans per a ells en el futur, i per a la compatibilitat enrere de les versions del protocol, ja han reservat aquests bits a les versions actuals de l'estàndard.
El camp de longitud de trama ha de contenir un número en representació de bits que sigui igual a la longitud de trama en octets menys un.
El camp de dades de trama ha de seguir la capçalera sense espais i contenir un nombre enter d'octets, que pot tenir un màxim de 1019 octets de longitud. Aquest camp ha de contenir informació del bloc de dades de trama o de l'ordre de control. El bloc de dades de trama ha de contenir:
- nombre enter d'octets de dades d'usuari
- capçalera del segment seguida d'un nombre enter d'octets de dades d'usuari
Si hi ha una capçalera, el bloc de dades ha de contenir un paquet, un conjunt de paquets o part d'un paquet. Un bloc de dades sense capçalera no pot contenir parts de paquets, però pot contenir blocs de dades de format privat. D'això es dedueix que es requereix una capçalera quan el bloc de dades transmès no encaixa en una trama. Un bloc de dades que té una capçalera s'anomena segment
El camp de senyals de dos bits ha de contenir:
- "01" - si la primera part de les dades es troba al bloc de dades
- "00" - si la part central de les dades es troba al bloc de dades
- "10" - si l'última peça de dades es troba al bloc de dades
- "11" - si no hi ha divisió i un o més paquets encaixen completament al bloc de dades.
El camp ID MAP ha de contenir zeros si no s'utilitzen canals MAP.
De vegades, 6 bits assignats als canals virtuals no són suficients. I si és necessari multiplexar dades a un nombre més gran de canals, s'utilitzen 6 bits més de la capçalera del segment.
FARM
Mirem més de prop el mecanisme de funcionament del sistema de control de lliurament de personal. Aquest sistema només preveu treballar amb trames de telecomandaments per la seva importància (la telemetria sempre es pot sol·licitar de nou, i la nau espacial ha d'escoltar clarament l'estació terrestre i obeir sempre les seves ordres). Per tant, suposem que decidim refrescar el nostre satèl·lit i enviar-li un fitxer binari de 10 kilobytes de mida. A nivell d'enllaç, el fitxer es divideix en 10 fotogrames (0, 1, ..., 9), que s'envien cap amunt un per un. Quan s'hagi completat la transmissió, el satèl·lit ha de confirmar la correcció de la recepció del paquet, o informar de quina trama s'ha produït l'error. Aquesta informació s'envia al camp de control operacional en la trama de telemetria més propera (o la nau espacial pot iniciar la transmissió d'una trama inactiva si no té res a dir). En funció de la telemetria rebuda, ens assegurem que tot està bé o procedim a tornar a enviar el missatge. Suposem que el satèl·lit no ha sentit el fotograma #7. Això vol dir que li enviem les trames 7, 8, 9. Si no hi ha resposta, es torna a enviar tot el paquet (i així diverses vegades fins que ens adonem que els intents són en va).
A continuació es mostra l'estructura del camp de control operacional amb una descripció d'alguns camps. Les dades contingudes en aquest camp s'anomenen CLCW - Communication Link Control Word.
Com que a la imatge podeu endevinar fàcilment el propòsit dels camps principals, i els altres són avorrits de mirar, amago la descripció detallada sota un spoiler.
Explicació dels camps CLCWTipus de paraula de control:
Per a aquest tipus, la paraula de control ha de contenir 0
Versió de la paraula de control (número de versió CLCW):
Per a aquest tipus, la paraula de control ha de ser igual a "00" a la representació de bits.
Camp d'estat:
L'ús d'aquest camp es determina per a cada missió per separat. Es pot utilitzar per a millores locals per part de diverses agències espacials.
Identificació del canal virtual:
Ha de contenir l'identificador del canal virtual al qual està associada aquesta paraula de control.
Marcador d'accés al canal físic:
La bandera ha de proporcionar informació sobre la preparació de la capa física del receptor. Si la capa física del receptor no està preparada per rebre trames, el camp ha de contenir "1", en cas contrari, "0".
Marcador d'error de sincronització:
La bandera pot indicar que la capa física està funcionant a un nivell de senyal deficient i que el nombre de trames rebutjades és massa alt. L'ús d'aquest camp és opcional; si s'utilitza, ha de contenir "0" si la sincronització està disponible i "1" si no.
Bandera de bloqueig:
Aquest bit ha de contenir l'estat de bloqueig FARM per a cada canal virtual. Un valor d'"1" en aquest camp hauria d'indicar que FARM està desactivat i que els fotogrames es descartaran per a cada capa virtual, en cas contrari, "0".
Bandera d'espera:
Aquest bit s'utilitzarà per indicar que el receptor no pot processar dades al canal virtual especificat. Un valor "1" indica que es descartaran tots els fotogrames en aquest canal virtual, en cas contrari "0".
Bandera endavant:
Aquesta bandera ha de contenir un "1" si s'han descartat un o més fotogrames de tipus A o s'han trobat buits, de manera que cal tornar-los a enviar. El senyalador "0" indica que no hi ha hagut cap fotograma perdut ni saltat.
Valor de resposta:
Número de fotograma que no s'ha rebut. Determinat pel comptador de la capçalera del marc de teleordre
capa de xarxa
Toquem una mica aquest nivell. Aquí hi ha dues opcions: utilitzar el protocol de paquets espacials o encapsular qualsevol altre protocol al paquet CCSDS.
Una visió general del protocol de paquets espacials és un tema per a un article separat. Està dissenyat per permetre que les anomenades aplicacions intercanviïn dades sense problemes. Cada aplicació té la seva pròpia adreça i una funcionalitat bàsica per intercanviar dades amb altres aplicacions. També hi ha serveis que encaminen el trànsit, controlen el lliurament, etc.
Amb l'encapsulació tot és més senzill i clar. Els estàndards permeten encapsular qualsevol protocol en paquets CCSDS afegint una capçalera addicional.
On la capçalera té significats diferents segons la longitud del protocol que s'encapsula:
Aquí el camp principal és la longitud de la longitud. Pot variar de 0 a 4 bytes. També en aquesta capçalera cal indicar el tipus de protocol encapsulat mitjançant la taula .
L'encapsulació IP utilitza un altre complement per determinar el tipus de paquet.
Heu d'afegir una capçalera més, d'un octet de llargada:
On PID és un altre identificador de protocol pres
Conclusió
A primera vista, pot semblar que les capçaleres CCSDS són extremadament redundants i alguns camps es podrien descartar. De fet, l'eficiència del canal resultant (fins al nivell de xarxa) és d'un 40%. No obstant això, tan bon punt sorgeix la necessitat d'implementar aquests estàndards, es fa evident que cada camp, cada encapçalament té la seva missió important, ignorant-la que comporta una sèrie d'ambigüitats.
Si l'habrasociety mostra interès per aquest tema, estaré encantat de publicar tota una sèrie d'articles dedicats a la teoria i pràctica de les comunicacions espacials. Gràcies per la vostra atenció!
Fonts
PS
No pegueu massa fort si trobeu alguna inexactitud. Informa'ls i s'arreglaran :)
Font: www.habr.com