Un poco sobre los estándares de comunicaciones espaciales

Satellite Meteor M1
Fuente: vladtime.ru

Introduccion

El funcionamiento de la tecnología espacial es imposible sin las comunicaciones por radio, y en este artículo trataré de explicar las ideas básicas que formaron la base de los estándares desarrollados por el Comité Consultivo para Sistemas de Datos Espaciales - CCSDS. Esta abreviatura se utilizará a continuación.

Esta publicación estará dedicada principalmente al nivel del canal, sin embargo, también se introducirán conceptos básicos para otros niveles. No ser de ninguna manera reclama una descripción completa y completa de los estándares. Puede encontrarlo en el sitio web de CCSDS. Sin embargo, son muy difíciles de percibir, y para entenderlos pasamos mucho tiempo, por lo que aquí quiero dar información básica, tener que lidiar con todo lo demás será mucho más fácil. Entonces comencemos.

La noble misión de CCSDS

Quizás alguien tenía una pregunta: ¿por qué todos deberían adherirse a los estándares si puede desarrollar su propia pila de protocolos de protocolo patentada (o su propio estándar, con blackjack y nuevas funciones), aumentando así la seguridad del sistema?

Como muestra la práctica, es más rentable cumplir con los estándares CCSDS por la siguiente serie de razones:

1. El comité responsable de publicar las normas incluyó representantes de todas las principales agencias aeroespaciales del mundo, aportando su invaluable experiencia adquirida durante muchos años de diseño y operación de varias misiones. Sería muy ridículo ignorar esta experiencia y volver a pisar su rastrillo.
2. Estos estándares están respaldados por equipos de estaciones terrestres que ya están en el mercado.
3. Durante la resolución de problemas, siempre puede pedir ayuda a colegas de otras agencias para que puedan realizar una sesión de comunicación con el dispositivo desde su estación terrestre.

Arquitectura

Los estándares son un conjunto de documentos que reflejan el modelo OSI (Interconexión de sistemas abiertos) más común, excepto que a nivel de canal, la comunidad está limitada a la división en telemetría (canal "inactivo" - espacio - Tierra) y telecomandos (canal "ascendente").



Considere algunos niveles con más detalle, comenzando con el físico y subiendo. Para mayor claridad, consideraremos la arquitectura del lado del host. El transmisor es su imagen especular.

Nivel fisico

En este nivel, la señal de radio modulada se convierte en un flujo de bits. Los estándares aquí son en su mayoría de naturaleza recomendatoria, ya que a este nivel es difícil abstraerse de una implementación específica de hierro. Aquí, la función clave de CCSDS es determinar las modulaciones permitidas (BPSK, QPSK, 8-QAM, etc.) y dar algunas recomendaciones sobre la implementación de mecanismos de sincronización de símbolos, compensación de desplazamiento Doppler, etc.

Nivel de sincronización y codificación

Formalmente, es una subcapa de la capa de enlace de datos, pero muy a menudo se asigna como una capa separada debido a su importancia dentro del marco de estándares CCSDS. Este nivel convierte el flujo de bits en los llamados marcos (telemetría o telecomandos), de los que hablaremos más adelante. A diferencia de la sincronización de caracteres en el nivel físico, que le permite obtener el flujo de bits correcto, la sincronización de trama se realiza aquí. Considere la ruta que recorren los datos a este nivel (de abajo hacia arriba):



Sin embargo, antes de eso vale la pena decir algunas palabras sobre la codificación. Este procedimiento es necesario para encontrar y / o corregir errores de bits que inevitablemente ocurren al enviar datos por aire. Aquí no consideraremos los procedimientos de decodificación, sino que solo obtendremos la información necesaria para comprender la lógica adicional del nivel.

Los códigos son en bloque y continuos. Los estándares no fuerzan el uso de un tipo particular de codificación, pero debe estar presente como tal. Los continuos incluyen códigos convolucionales (colvolucionales). Al usarlos, se codifica un flujo continuo de bits. A diferencia de los códigos de bloque, donde los datos se dividen en bloques de código (codeblock), y solo se pueden decodificar como parte de bloques completos. El bloque de código son los datos transmitidos y la información redundante adjunta necesaria para verificar la exactitud de los datos y corregir posibles errores. Los códigos de bloque incluyen los famosos códigos Reed-Solomon.

Si se usa codificación convolucional, el flujo de bits desde el principio va al decodificador. El resultado de su trabajo (todo esto, por supuesto, está sucediendo continuamente) son unidades de datos CADU (unidad de datos de acceso al canal). Esta estructura es necesaria para la sincronización de trama. Al final de cada CADU se adjunta un marcador de sincronización (ASM - fabricante de sincronización adjunto). Estos son 4 bytes conocidos de antemano, por los cuales el sincronizador encuentra el principio y el final de la CADU. Así es como se logra la sincronización de trama.

La siguiente etapa opcional de operación de la capa de sincronización y codificación está asociada con las características de la capa física. Esto es desrandomización. El hecho es que para lograr la sincronización de símbolos, es necesario cambiar frecuentemente entre símbolos. Entonces, si transferimos, digamos, un kilobyte de datos que consta únicamente de unidades, la sincronización se perderá. Por lo tanto, durante la transmisión, los datos de entrada se mezclan con una secuencia pseudoaleatoria periódica para que la densidad de ceros y unos sea uniforme.

A continuación, los códigos de bloque se decodifican, y lo que queda será el producto final del marco de nivel de sincronización y codificación.

Nivel de canal

Por un lado, el controlador de capa de enlace recibe tramas y, por otro lado, produce paquetes. Dado que formalmente el tamaño de los paquetes no está limitado, para su reenvío confiable es necesario dividirlos en estructuras más pequeñas: marcos. Aquí consideramos dos subsecciones: por separado para telemetría (TM) y telecomandos (TC).

Telemetría

En pocas palabras, estos son los datos que la estación terrestre recibe de la nave espacial. Toda la información transmitida se divide en pequeños fragmentos de una longitud fija: tramas que contienen los datos transmitidos y los campos de servicio. Considere la estructura del marco con más detalle:



Y comenzaremos nuestra consideración con el encabezado principal del marco de telemetría. Además, me permitiré en algunos lugares simplemente traducir los estándares, simultáneamente dando algunas aclaraciones.



El campo del identificador del canal principal (ID del canal maestro) debe contener el número de versión de la trama y el identificador del dispositivo.

Cada nave espacial, de acuerdo con los estándares CCSDS, debe tener su propio identificador único, por el cual es posible, con un marco, determinar a qué vehículo pertenece. Formalmente, es necesario solicitar el registro del dispositivo, y su nombre, junto con el identificador, se publicará en fuentes abiertas. Sin embargo, a menudo los fabricantes rusos ignoran este procedimiento y asignan un identificador arbitrario al dispositivo. El número de versión del marco ayuda a determinar qué versión de los estándares se usa para leer correctamente el marco. Aquí consideramos solo el estándar más conservador con la versión "0".

La ID del canal virtual debe contener el VCID del canal del que proviene el paquete. No hay restricciones en la elección de VCID, en particular, los canales virtuales no están necesariamente numerados secuencialmente.

Muy a menudo existe la necesidad de multiplexar los datos transmitidos. Hay un mecanismo de canal virtual para esto. Por ejemplo, el satélite Meteor-M2 transmite una imagen en color en el rango visible, dividiéndola en tres en blanco y negro: cada color se transmite en su propio canal virtual como un paquete separado, aunque hay una desviación de los estándares en la estructura de sus marcos.

El campo indicador de Control operativo debe ser un indicador de la presencia o ausencia del campo Control operativo en el marco de telemetría. Estos 4 bytes al final de la trama sirven para mantener la retroalimentación al monitorear la entrega de tramas de telemando. Hablaremos de ellos un poco más tarde.

Los contadores de trama de los canales principal y virtual son campos que se incrementan en uno cuando se envía cada trama. Sirven como un indicador de que no se ha perdido ningún marco.

El estado de los datos de la trama de telemetría son dos bytes más de indicadores y datos, de los cuales consideraremos solo unos pocos.



El campo de marca del encabezado secundario (encabezado secundario) debe ser un indicador de la presencia o ausencia del encabezado secundario (encabezado secundario) en el marco de telemetría.

Si lo desea, puede agregar un encabezado adicional a cada marco y colocar los datos allí a su discreción.

El campo del puntero al primer encabezado (primer puntero del encabezado), con el valor del indicador de sincronización "1", debe contener la representación binaria de la posición del primer octeto del primer paquete en el campo de datos de la trama de telemetría. La posición se cuenta desde 0 en orden ascendente desde el comienzo del campo de datos. Si no hay un comienzo de un paquete en el campo de datos de la trama de telemetría, entonces el campo del puntero al primer encabezado debe tener un valor en la representación binaria "11111111111" (esto puede suceder si un paquete largo se extiende a más de una trama).

Si el campo de datos contiene un paquete vacío (Datos inactivos), el puntero al primer encabezado debe tener un valor en la representación binaria "11111111110". En este campo, el receptor debe sincronizar la secuencia. Este campo garantiza la restauración de la sincronización incluso en caso de omitir cuadros.

Es decir, un paquete puede, supongamos, comenzar a mediados del cuarto cuadro y terminar a principios del 20. Para encontrar su comienzo, este campo solo sirve. Los paquetes también tienen un encabezado en el que se registra su longitud, por lo que cuando se encuentra un puntero al primer encabezado, el controlador de nivel de enlace debe leerlo, determinando así dónde terminará el paquete.
Si se presenta un campo de control de errores, debe estar contenido en cada trama de telemetría para un canal físico particular a lo largo de la misión.

Este campo se calcula utilizando el método CRC. El procedimiento debe aceptar n-16 bits de la trama de telemetría e insertar el resultado del cálculo en los últimos 16 bits.

Telecomandos

El marco de telemando tiene varias diferencias significativas. Entre ellos están:

1. Estructura de encabezado diferente
2. Longitud dinámica. Esto significa que la longitud de la trama no se establece rígidamente, como se hace en telemetría, pero puede variar según los paquetes transmitidos.
3. Mecanismo de garantía de entrega del paquete. Es decir, la nave espacial debe, después de la recepción, confirmar la recepción correcta de las tramas, o solicitar el reenvío de la trama que podría recibirse con un error no corregible.

Muchos campos ya nos son familiares desde el encabezado del marco de telemetría. Tienen el mismo propósito, así que aquí consideramos solo nuevos campos.

Se debe usar un bit de la bandera de derivación para monitorear la verificación de trama en el receptor. El valor "0" de este indicador debe indicar que este marco es un marco tipo A y debe verificarse de acuerdo con FARM. El valor "1" de esta bandera debe indicar al receptor que esta trama es una trama tipo B y debe omitir la verificación de acuerdo con FARM.

Esta bandera informa al receptor si debe usar el mecanismo de confirmación de entrega de trama denominado FARM - Mecanismo de aceptación e informe de trama.

El indicador de comando de control debe usarse para comprender si el campo de datos está transportando el comando o los datos. Si el indicador es "0", el campo de datos debe contener datos. Si la bandera es "1", el campo de datos debe contener la información de control para la GRANJA.
FARM es una máquina de estado cuyos parámetros se pueden configurar.

RSVD. RECAMBIO - bits reservados.

Parece que CCSDS tiene planes para ellos en el futuro, y para la compatibilidad con versiones anteriores del protocolo, reservaron estos bits ya en las versiones actuales del estándar.

El campo de longitud de trama debe contener un número en la representación de bits, que es igual a la longitud de trama en octetos menos uno.

El campo de datos de trama debe seguir el encabezado sin espacios y contener un número entero de octetos, que puede ser un máximo de 1019 octetos. Este campo debe contener un bloque de datos de trama o información de un comando de control. El bloque de datos del marco debe contener:

• octeto entero datos de usuario
• encabezado de segmento seguido de un octeto entero de datos de usuario

Si se proporciona un encabezado, el bloque de datos debe contener un paquete, muchos paquetes o parte de él. Un bloque de datos sin encabezado no puede contener partes de paquetes, pero puede contener bloques de datos de formato privado. De esto se deduce que se requiere el encabezado cuando el bloque de datos transmitidos no cabe en un cuadro. Un bloque de datos que tiene un encabezado se llama segmento.



Un campo de bandera de dos bits debe contener:

• "01" - si la primera parte de los datos está en el bloque de datos
• "00" - si la parte media de los datos está en el bloque de datos
• "10" - si el último dato está en el bloque de datos
• "11": si no hay división y se colocan uno o más paquetes en el bloque de datos como un todo.

El campo identificador MAP debe contener ceros si no se utilizan canales MAP.
A veces, 6 bits asignados a canales virtuales no son suficientes. Y si necesita multiplexar datos en un mayor número de canales, se utilizan otros 6 bits del encabezado del segmento.

Granja

Consideremos con más detalle el mecanismo de funcionamiento del sistema de control de entrega de personal. Este sistema solo permite trabajar con personal de telecomunicaciones en vista de su importancia (la telemetría siempre se puede solicitar nuevamente, y la nave espacial debe escuchar la estación terrestre con claridad y siempre obedecer sus comandos). Entonces, supongamos que decidimos actualizar nuestro satélite y enviar un archivo binario de 10 kilobytes a bordo. A nivel de canal, el archivo se divide en 10 cuadros (0, 1, ..., 9), que se envían uno a la vez a la parte superior. Cuando se completa la transmisión, la nave espacial debe confirmar la recepción correcta del paquete o informar en qué cuadro se produjo un error. Esta información se envía al campo de control operativo en la trama de telemetría más cercana (o la nave espacial puede iniciar la transmisión de una trama vacía (trama inactiva) si no tiene nada que decir). Según la telemetría recibida, nos aseguramos de que todo esté bien o reenviamos el mensaje. Supongamos que el satélite no oyó la trama n. ° 7. Entonces, enviamos los cuadros 7, 8, 9. Si no hay respuesta, el paquete se envía nuevamente por completo (y así sucesivamente varias veces hasta que nos demos cuenta de que los intentos son inútiles).

A continuación se muestra la estructura del campo de control operativo con una descripción de algunos campos. Los datos contenidos en este campo se denominan CLCW - Palabra de control de enlace de comunicación.



Como es bastante posible adivinar en la imagen el propósito de los campos principales, mientras que mirar los otros es aburrido, oculto la descripción detallada debajo del spoiler

Capa de red

Un pequeño toque en este nivel. Aquí son posibles dos opciones: usar el protocolo de paquete espacial o encapsular cualquier otro protocolo en el paquete CCSDS.

Una revisión del protocolo de paquetes espaciales es un tema para un artículo separado. Fue creado para que las llamadas aplicaciones puedan intercambiar datos sin problemas. Cada aplicación tiene su propia dirección y funcionalidad básica para intercambiar datos con otras aplicaciones. También hay servicios que enrutan el tráfico, realizan el control de entrega, etc.

Con la encapsulación, todo es más simple y más comprensible. Los estándares permiten encapsular cualquier protocolo en paquetes CCSDS agregando un encabezado adicional.



Donde el encabezado tiene diferentes significados dependiendo de la longitud del protocolo encapsulado:



Aquí, el campo principal es la longitud de la longitud. Puede variar de 0 a 4 bytes. También en este encabezado debe especificar el tipo de protocolo encapsulado, utilizando la tabla de aquí .

Al encapsular IP, se usa otro complemento para determinar el tipo de paquete.
Debe agregar otro encabezado, comenzando desde un octeto de longitud:



donde PID es otro identificador de protocolo tomado de aquí

Conclusión

A primera vista, puede parecer que los encabezados CCSDS son extremadamente redundantes y algunos campos podrían descartarse. De hecho, la eficiencia del canal resultante (hasta el nivel de rojo) es de aproximadamente el 40%. Sin embargo, tan pronto como sea necesario implementar estos controles, queda claro que cada campo, cada encabezado tiene su propia misión importante, ignorar lo que conduce a una serie de ambigüedades.

Si la comunidad habitacional muestra interés en este tema, publicará una serie completa de artículos dedicados a la teoría y la práctica de las comunicaciones espaciales. Gracias por su atencion!

Fuentes

CCSDS 130.0-G-3 - Descripción general de los protocolos de comunicaciones espaciales
CCSDS 131.0-B-2 - Sincronización TM y codificación de canales
CCSDS 132.0-B-2 - Protocolo de enlace de datos espaciales TM
CCSDS 133.0-B-1 - Protocolo de paquetes espaciales
CCSDS 133.1- B-2 - Servicio de encapsulación
CCSDS 231.0-B-3 - Sincronización TC y codificación de canales
CCSDS 232.1-B-2 Procedimiento de operación de comunicaciones-1
CCSDS 401.0-B-28 Sistemas de radiofrecuencia y modulación - Parte 1 (Estaciones terrestres y naves espaciales)
CCSDS 702.1-B-1 - IP sobre enlaces espaciales CCSDS

PS
No golpee con fuerza si encuentra imprecisiones. Denúncielos y serán reparados :)