Satélite Meteor M1
Fonte: vladtime.ru
Introdución
O funcionamento da tecnoloxía espacial é imposible sen comunicacións por radio, e neste artigo intentarei explicar as ideas principais que formaron a base dos estándares desenvolvidos polo Comité Asesor Internacional de Sistemas de Datos Espaciais (CCSDS. Esta abreviatura empregarase a continuación) .
Esta publicación centrarase principalmente na capa de enlace de datos, pero tamén se introducirán conceptos básicos para outras capas. Este artigo de ningún xeito pretende ser unha descrición completa e completa dos estándares. Podes velo en CCSDS. Non obstante, son moi difíciles de entender, e levamos moito tempo intentando entendelos, polo que aquí quero achegar información básica, tendo a cal será moito máis fácil entender todo o demais. Entón, imos comezar.
Nobre Misión do CCSDS
Quizais alguén teña unha pregunta: por que todos deberían unirse aos estándares se pode desenvolver a súa propia pila de protocolos de radio propietario (ou o seu propio estándar, con blackjack e novas funcións), aumentando así a seguridade do sistema?
Como mostra a práctica, é máis rendible adherirse aos estándares CCSDS polas seguintes razóns:
- O comité responsable de publicar os estándares inclúe representantes de todas as principais axencias aeroespaciais do mundo, que aportan unha valiosa experiencia adquirida durante moitos anos de deseño e operación de varias misións. Sería moi absurdo ignorar esta experiencia e volver a pisar o seu anciño.
- Estes estándares son compatibles con equipos de estación terrestre que xa están no mercado.
- Ao solucionar calquera problema, sempre pode buscar axuda de compañeiros doutras axencias para que poidan realizar unha sesión de comunicación co dispositivo desde a súa estación terrestre. Como podes ver, os estándares son algo moi útil, así que vexamos os seus puntos clave.
Arquitectura
Os estándares son un conxunto de documentos que reflicten o modelo OSI (Open System Interconnection) máis común, agás que a nivel de enlace de datos o común limítase á división en telemetría (enlace descendente - espazo - Terra) e telecomandos (enlace ascendente).
Vexamos algúns dos niveis con máis detalle, comezando polo físico e subindo. Para unha maior claridade, consideraremos a arquitectura do lado receptor. O transmisor é a súa imaxe especular.
Capa física
Neste nivel, o sinal de radio modulado convértese nun fluxo de bits. Os estándares aquí son principalmente de natureza consultiva, xa que neste nivel é difícil abstraerse da implementación específica do hardware. Aquí, o papel fundamental do CCSDS é definir as modulacións aceptables (BPSK, QPSK, 8-QAM, etc.) e dar algunhas recomendacións sobre a implementación de mecanismos de sincronización de símbolos, compensación Doppler, etc.
Nivel de sincronización e codificación
Formalmente, é unha subcapa da capa de enlace de datos, pero a miúdo está separada nunha capa separada debido á súa importancia dentro dos estándares CCSDS. Esta capa converte o fluxo de bits nas chamadas tramas (telemetría ou telecomandos), das que falaremos máis adiante. A diferenza da sincronización de símbolos na capa física, que lle permite obter o fluxo de bits correcto, a sincronización de cadros realízase aquí. Considere o camiño que percorren os datos neste nivel (de abaixo a arriba):
Non obstante, antes diso, paga a pena dicir algunhas palabras sobre a codificación. Este procedemento é necesario para atopar e/ou corrixir os erros de bits que inevitablemente se producen ao enviar datos a través dunha canle de radio. Aquí non consideraremos procedementos de decodificación, senón que só obteremos a información necesaria para comprender a lóxica adicional do nivel.
Os códigos poden ser en bloque ou continuos. Os estándares non obrigan a utilizar un tipo específico de codificación, pero debe estar presente como tal. Os códigos continuos inclúen códigos convolucionais. Utilízanse para codificar un fluxo de bits continuo. Isto contrasta cos códigos de bloque, onde os datos se dividen en bloques de código e só se poden decodificar dentro de bloques completos. O bloque de códigos representa os datos transmitidos e a información redundante anexa necesaria para verificar a corrección dos datos recibidos e corrixir posibles erros. Os códigos de bloque inclúen os famosos códigos Reed-Solomon.
Se se usa codificación convolucional, o fluxo de bits entra no decodificador desde o principio. O resultado do seu traballo (todo isto, por suposto, ocorre continuamente) son os bloques de datos CADU (unidade de datos de acceso á canle). Esta estrutura é necesaria para a sincronización de cadros. Ao final de cada CADU hai un creador de sincronización (ASM) anexo. Estes son 4 bytes coñecidos de antemán, polos que o sincronizador atopa o inicio e o final do CADU. Así é como se consegue a sincronización de cadros.
A seguinte etapa opcional da capa de sincronización e codificación está asociada ás peculiaridades da capa física. Isto é a desaleatorización. O feito é que para conseguir a sincronización de símbolos é necesario un cambio frecuente entre os símbolos. Entón, se transmitimos, digamos, un kilobyte de datos composto enteiramente por uns, perderase a sincronización. Polo tanto, durante a transmisión, os datos de entrada mestúranse cunha secuencia pseudoaleatoria periódica para que a densidade de ceros e uns sexa uniforme.
A continuación, os códigos de bloque son decodificados e o que queda é o produto final do nivel de sincronización e codificación: un cadro.
Capa de enlace de datos
Por un lado, o procesador da capa de enlace recibe tramas e, por outro, emite paquetes. Dado que o tamaño dos paquetes non está limitado formalmente, para a súa transmisión fiable é necesario dividilos en estruturas máis pequenas: cadros. Aquí veremos dúas subseccións: por separado para telemetría (TM) e telecomandos (TC).
Telemetría
En pocas palabras, estes son os datos que recibe a estación terrestre da nave espacial. Toda a información transmitida divídese en pequenos fragmentos dunha lonxitude fixa: cadros que conteñen datos transmitidos e campos de servizo. Vexamos máis de cerca a estrutura do cadro:
E imos comezar a nosa consideración coa cabeceira principal do marco de telemetría. Ademais, permitireime simplemente traducir os estándares nalgúns lugares, dando algunhas aclaracións ao longo do camiño.
O campo Master Channel ID debe conter o número de versión do cadro e o identificador do dispositivo.
Cada nave espacial, segundo os estándares CCSDS, debe ter o seu propio identificador único, polo cal, tendo un marco, pódese determinar a que dispositivo pertence. Formalmente, é necesario presentar unha solicitude para rexistrar o dispositivo, e o seu nome, xunto co seu identificador, publicarase en fontes abertas. Non obstante, os fabricantes rusos adoitan ignorar este procedemento, asignando un identificador arbitrario ao dispositivo. O número de versión do cadro axuda a determinar que versión dos estándares se utiliza para ler correctamente o cadro. Aquí consideraremos só o estándar máis conservador coa versión "0".
O campo Virtual Channel ID debe conter o VCID da canle da que procedeu o paquete. Non hai restricións á elección do VCID; en particular, as canles virtuais non están necesariamente numeradas secuencialmente.
Moitas veces é necesario multiplexar os datos transmitidos. Para este fin, existe un mecanismo de canles virtuais. Por exemplo, o satélite Meteor-M2 transmite unha imaxe en cor no rango visible, dividíndoa en tres en branco e negro; cada cor transmítese na súa propia canle virtual nun paquete separado, aínda que hai algunha desviación dos estándares no estrutura dos seus cadros.
O campo de bandeira de control operativo será un indicador da presenza ou ausencia do campo de control operativo no marco de telemetría. Estes 4 bytes ao final da trama serven para proporcionar retroalimentación cando se controla a entrega de tramas de telecomando. Delas falaremos un pouco máis adiante.
Os contadores de fotogramas da canle principal e virtual son campos que se incrementan un cada vez que se envía un fotograma. Sirva como un indicador de que non se perdeu nin un só cadro.
O estado dos datos do marco de telemetría é de dous bytes máis de bandeiras e datos, dos que veremos só algúns.
O campo da marca de cabeceira secundaria debe ser un indicador da presenza ou ausencia dunha cabeceira secundaria no marco de telemetría.
Se o desexa, pode engadir un encabezado adicional a cada marco e colocar alí os datos ao seu criterio.
O campo First Header Pointer, cando o indicador de sincronización está configurado en "1", conterá unha representación binaria da posición do primeiro octeto do primeiro paquete no campo de datos da trama de telemetría. A posición cóntase desde 0 en orde ascendente desde o inicio do campo de datos. Se non hai un inicio do paquete no campo de datos da trama de telemetría, entón o punteiro ó primeiro campo de cabeceira debe ter o valor en representación binaria "11111111111" (isto pode ocorrer se un paquete longo está repartido por máis dunha trama). ).
Se o campo de datos contén un paquete baleiro (Datos inactivos), entón o punteiro á primeira cabeceira debería ter o valor en representación binaria "11111111110". Usando este campo, o receptor debe sincronizar o fluxo. Este campo garante que se restableza a sincronización aínda que se descarten fotogramas.
É dicir, un paquete pode, por exemplo, comezar no medio do 4º cadro e rematar a principios do 20º. Este campo úsase para atopar o seu inicio. Os paquetes tamén teñen un encabezado que especifica a súa lonxitude, polo que cando se atopa un punteiro ao primeiro encabezado, o procesador da capa de ligazón debe lelo, determinando así onde rematará o paquete.
Se hai un campo de control de erros, debe estar contido en cada marco de telemetría para unha canle física determinada ao longo da misión.
Este campo calcúlase mediante o método CRC. O procedemento debe tomar n-16 bits da trama de telemetría e inserir o resultado do cálculo nos últimos 16 bits.
equipos de televisión
O marco de mando da TV ten varias diferenzas significativas. Entre eles:
- Estrutura de títulos diferentes
- Lonxitude dinámica. Isto significa que a lonxitude da trama non se establece de forma ríxida, como se fai na telemetría, senón que pode variar dependendo dos paquetes transmitidos.
- Mecanismo de garantía de entrega de paquetes. É dicir, a nave espacial debe, despois de recibila, confirmar a corrección da recepción da fotograma ou solicitar o reenvío dunha fotograma que se puido recibir cun erro non corrixible.
Moitos campos xa nos son familiares desde a cabeceira do marco de telemetría. Teñen a mesma finalidade, polo que aquí consideraremos só os novos campos.
Un bit da marca de derivación debe usarse para controlar a comprobación de cadros no receptor. Un valor de "0" para esta bandeira indicará que a trama é unha trama de tipo A e debe verificarse segundo FARM. Un valor de "1" para esta bandeira debería indicarlle ao receptor que a trama é unha trama de tipo B e que non debería pasar a verificación FARM.
Esta marca infórmalle ao receptor se debe utilizar un mecanismo de recoñecemento de entrega de tramas chamado FARM - Mecanismo de aceptación e informes de tramas.
O indicador de comando de control debe usarse para entender se o campo de datos transporta un comando ou datos. Se a bandeira é "0", entón o campo de datos debe conter datos. Se a marca é "1", entón o campo de datos debe conter información de control para FARM.
FARM é unha máquina de estados finitos cuxos parámetros se poden configurar.
RSVD. REPUESTO - bits reservados.
Parece que CCSDS ten plans para eles no futuro, e para a compatibilidade con versións do protocolo xa reservaron estes bits nas versións actuais do estándar.
O campo de lonxitude da trama debe conter un número en representación de bits que sexa igual á lonxitude da trama en octetos menos un.
O campo de datos da trama debe seguir a cabeceira sen espazos e conter un número enteiro de octetos, que pode ter un máximo de 1019 octetos de lonxitude. Este campo debe conter información de bloque de datos de trama ou de comando de control. O bloque de datos do marco debe conter:
- número enteiro de octetos de datos de usuario
- cabeceira de segmento seguida dun número enteiro de octetos de datos de usuario
Se hai unha cabeceira, entón o bloque de datos debe conter un paquete, un conxunto de paquetes ou parte dun paquete. Un bloque de datos sen cabeceira non pode conter partes de paquetes, pero pode conter bloques de datos de formato privado. Diso dedúcese que se require unha cabeceira cando o bloque de datos transmitido non encaixa nun marco. Un bloque de datos que ten unha cabeceira chámase segmento
O campo de marcas de dous bits debe conter:
- "01" - se a primeira parte dos datos está no bloque de datos
- "00" - se a parte central dos datos está no bloque de datos
- "10" - se o último dato está no bloque de datos
- "11" - se non hai división e un ou máis paquetes caben totalmente no bloque de datos.
O campo ID MAP debe conter ceros se non se usan canles MAP.
Ás veces, 6 bits asignados a canles virtuais non son suficientes. E se é necesario multiplexar datos a un número maior de canles, utilízanse outros 6 bits da cabeceira do segmento.
FARM
Vexamos máis de cerca o mecanismo de funcionamento do sistema de control de entrega de persoal. Este sistema só prevé traballar con cadros de telecomandos pola súa importancia (a telemetría sempre se pode solicitar de novo, e a nave espacial debe escoitar con claridade a estación terrestre e obedecer sempre as súas ordes). Entón, supoñamos que decidimos actualizar o noso satélite e enviarlle un ficheiro binario de 10 kilobytes de tamaño. No nivel de ligazón, o ficheiro divídese en 10 cadros (0, 1, ..., 9), que se envían cara arriba un por un. Cando se complete a transmisión, o satélite debe confirmar a corrección da recepción do paquete ou informar en que fotograma se produciu o erro. Esta información envíase ao campo de control operativo no marco de telemetría máis próximo (ou a nave espacial pode iniciar a transmisión dun cadro inactivo se non ten nada que dicir). En función da telemetría recibida, asegurámonos de que todo estea ben ou procedemos a reenviar a mensaxe. Supoñamos que o satélite non escoitou o cadro número 7. Isto significa que lle enviamos os fotogramas 7, 8, 9. Se non hai resposta, envíase de novo todo o paquete (e así varias veces ata que nos demos conta de que os intentos son en balde).
A continuación móstrase a estrutura do campo de control operativo cunha descrición dalgúns campos. Os datos contidos neste campo chámanse CLCW - Communication Link Control Word.
Como podes adiviñar facilmente a partir da imaxe o propósito dos campos principais e os outros son aburridos de mirar, estou ocultando a descrición detallada baixo un spoiler
Explicación dos campos CLCWTipo de palabra de control:
Para este tipo, a palabra de control debe conter 0
Versión da palabra de control (número de versión CLCW):
Para este tipo, a palabra de control debe ser igual a "00" na representación de bits.
Campo de estado:
O uso deste campo determínase para cada misión por separado. Pódese utilizar para melloras locais por parte de varias axencias espaciais.
Identificación da canle virtual:
Debe conter o identificador da canle virtual á que está asociada esta palabra de control.
Marcador de acceso á canle física:
A bandeira debe proporcionar información sobre a preparación da capa física do receptor. Se a capa física do receptor non está lista para recibir fotogramas, entón o campo debe conter "1", se non, "0".
Marcador de fallo de sincronización:
A bandeira pode indicar que a capa física está a funcionar cun nivel de sinal deficiente e que o número de fotogramas rexeitados é demasiado alto. O uso deste campo é opcional; se se usa, debe conter "0" se a sincronización está dispoñible e "1" se non está.
Bandeira de bloqueo:
Este bit conterá o estado de bloqueo FARM para cada canle virtual. Un valor de "1" neste campo debe indicar que FARM está desactivado e descartaranse marcos para cada capa virtual, en caso contrario, "0".
Bandeira de espera:
Este bit debe utilizarse para indicar que o receptor non pode procesar datos na canle virtual especificada. Un valor de "1" indica que todos os fotogramas serán descartados nesta canle virtual, en caso contrario, "0".
Bandeira adiante:
Esta bandeira deberá conter un "1" se se descartaron un ou máis fotogramas de tipo A ou se atoparon ocos, polo que é necesario reenviar. A bandeira "0" indica que non houbo fotogramas eliminados nin saltos.
Valor de resposta:
Número de fotograma que non se recibiu. Determinado polo contador na cabeceira do marco de telecomando
capa de rede
Tocamos un pouco este nivel. Aquí hai dúas opcións: usar o protocolo de paquetes espaciais ou encapsular calquera outro protocolo no paquete CCSDS.
Unha visión xeral do protocolo de paquetes espaciais é un tema para un artigo separado. Está deseñado para permitir que as chamadas aplicacións intercambien datos sen problemas. Cada aplicación ten o seu propio enderezo e funcionalidade básica para intercambiar datos con outras aplicacións. Tamén hai servizos que enrutan o tráfico, controlan a entrega, etc.
Coa encapsulación todo é máis sinxelo e claro. Os estándares permiten encapsular calquera protocolo en paquetes CCSDS engadindo unha cabeceira adicional.
Onde a cabeceira ten significados diferentes dependendo da lonxitude do protocolo que se encapsula:
Aquí o campo principal é a lonxitude da lonxitude. Pode variar de 0 a 4 bytes. Tamén nesta cabeceira debe indicar o tipo de protocolo encapsulado mediante a táboa .
A encapsulación IP usa outro complemento para determinar o tipo de paquete.
Debes engadir un encabezado máis, dun octeto de lonxitude:
Onde PID é outro identificador de protocolo tomado
Conclusión
A primeira vista, pode parecer que as cabeceiras CCSDS son extremadamente redundantes e que algúns campos poden ser descartados. De feito, a eficiencia da canle resultante (ata o nivel de rede) é dun 40%. Porén, tan pronto como xorde a necesidade de implementar estes estándares, faise evidente que cada campo, cada epígrafe ten a súa propia misión importante, ignorando o que leva a unha serie de ambigüidades.
Se a habrasociety amosa interese por este tema, estarei encantado de publicar toda unha serie de artigos dedicados á teoría e á práctica das comunicacións espaciais. Grazas pola súa atención!
Fontes
PS
Non golpees demasiado se atopas algunha imprecisión. Denuncialos e arranxaranse :)
Fonte: www.habr.com