🥇Un poco sobre los estándares de comunicación espacial

Satélite Meteor M1
Fuente: vladtime.ru

Introducción

La operación de la tecnología espacial es imposible sin comunicación por radio, y en este artículo intentaré explicar las ideas fundamentales que sustentan los estándares desarrollados por el Comité Consultivo para Sistemas de Datos Espaciales (Consultative Committee for Space Data Systems – CCSDS; en adelante se utilizará esta abreviatura).

Esta publicación se centrará principalmente en la capa de enlace, aunque también se introducirán conceptos básicos para otros niveles. Este artículo no pretende ser una descripción exhaustiva y completa de los estándares. Se puede consultar en el sitio web CCSDS. Sin embargo, son bastante difíciles de entender, y para comprenderlos hemos dedicado un tiempo considerable, así que aquí quiero ofrecer información básica que facilitará la comprensión de todo lo demás. Así que, empecemos.

La noble misión del CCSDS

Puede que alguien se pregunte: ¿por qué todos deben seguir los estándares, si se puede desarrollar un propio conjunto de protocolos de comunicación por radio (o un estándar propio, con blackjack y nuevas funciones), aumentando así la seguridad del sistema?

La práctica demuestra que es más ventajoso seguir los estándares del CCSDS por las siguientes razones:

En el comité responsable de la publicación de estándares participan representantes de todas las principales agencias aeroespaciales del mundo, quienes aportan su valiosa experiencia adquirida a lo largo de muchos años en el diseño y operación de diversas misiones. Sería muy absurdo ignorar esta experiencia y volver a tropezar con las mismas piedras.
Estos estándares son compatibles con el equipo existente en el mercado de estaciones terrestres.
Durante la resolución de cualquier problema, siempre se puede acudir a compañeros de otras agencias para que realicen una sesión de comunicación con el dispositivo desde su estación terrestre. Como se puede ver, los estándares son extremadamente útiles, así que analicemos sus puntos clave.

Arquitectura

Los estándares son un conjunto de documentos que reflejan el modelo OSI (Interconexión de Sistemas Abiertos) más común, salvo que en la capa de enlace la generalidad se limita a la separación entre telemetría (canal "hacia abajo" — del espacio a la Tierra) y telecomandos (canal "hacia arriba").

Examinemos algunos niveles en detalle, comenzando con el físico y avanzando hacia arriba. Para mayor claridad, consideraremos la arquitectura del lado receptor. El lado emisor es su reflejo en espejo.

Nivel físico

En este nivel, se produce la transformación de la señal de radio modulada en un flujo de bits. Los estándares aquí son en su mayoría recomendativos, ya que es complicado abstraerse de la implementación específica del hardware. Aquí, el papel clave de CCSDS es definir las modulaciones aceptables (BPSK, QPSK, 8-QAM, etc.) y proporcionar algunas recomendaciones sobre la implementación de mecanismos de sincronización simbólica, compensación del desplazamiento Doppler, etc.

Nivel de sincronización y codificación

Formalmente es un subnivel del nivel de enlace, pero a menudo se destaca como un nivel independiente debido a su importancia en los estándares de CCSDS. Este nivel convierte el flujo de bits en los llamados tramas (de telemetría o tele comandos), de los que hablaremos más adelante. A diferencia de la sincronización simbólica en el nivel físico, que permite obtener un flujo de bits correcto, aquí se realiza la sincronización del marco. Examinemos el camino que los datos recorren en este nivel (de abajo hacia arriba):

Sin embargo, antes de esto, vale la pena mencionar un par de palabras sobre la codificación. Este procedimiento es necesario para detectar y/o corregir errores de bits, que inevitablemente surgen al enviar datos a través de un canal de radio. Aquí no discutiremos los procedimientos de decodificación, solo obtendremos la información necesaria para comprender la lógica de funcionamiento del nivel a continuación.

Los códigos pueden ser de bloque y continuos. Los estándares no obligan a utilizar un tipo específico de codificación, sin embargo, debe existir como tal. Los códigos continuos son códigos convolucionales. Con ellos, se codifica un flujo de bits continuo. A diferencia de los códigos de bloque, donde los datos se dividen en bloques de código (codeblock) y pueden ser decodificados solo en el contexto de bloques completos. Un bloque de código consiste en los datos transmitidos y la información redundante asociada, necesaria para verificar la correcta recepción de los datos y corregir posibles errores. Los códigos de bloque incluyen los famosos códigos de Reed-Solomon.

Si se utiliza codificación por tramos, el flujo de bits llega al decodificador desde el principio. El resultado de su trabajo (todo esto, por supuesto, ocurre de manera continua) son bloques de datos CADU (unidad de acceso a datos de canal). Esta estructura es necesaria para la sincronización de cuadros. Al final de cada CADU se une un marcador de sincronización (ASM - marcador de sincronización adjunto). Estos son cuatro bytes conocidos de antemano, por los que el sincronizador encuentra el inicio y el final del CADU. Así se logra la sincronización de cuadros.

El siguiente paso opcional en el trabajo del nivel de sincronización y codificación está relacionado con las características del nivel físico. Esto es la desrandomización. La cuestión es que, para lograr la sincronización simbólica, se necesitan rápidos cambios entre símbolos. Así, si, por ejemplo, transmitimos un kilobyte de datos compuesto exclusivamente por unos, se perderá la sincronización. Por lo tanto, durante la transmisión, los datos de entrada se mezclan con una secuencia pseudoaleatoria periódica, de manera que la densidad de ceros y unos sea uniforme.

A continuación, se lleva a cabo la decodificación de códigos en bloques, y lo que queda será el producto final del nivel de sincronización y codificación: un cuadro.

Nivel de canal

Por un lado, el procesador del nivel de canal recibe cuadros, y por el otro lado, emite paquetes. Dado que formalmente no hay un límite en el tamaño de los paquetes, para su transmisión confiable es necesario dividirlos en estructuras más pequeñas: cuadros. Aquí consideraremos dos subdivisiones: una para telemetría (TM) y otra para telecontrol (TC).

Telemetría

En pocas palabras, estos son los datos que la estación terrestre recibe del satélite. Toda la información transmitida se divide en fragmentos pequeños de longitud fija: cuadros, que contienen los datos transmitidos y campos de control. Analicemos la estructura del cuadro en detalle:

Y comenzaremos el análisis con el encabezado principal del cuadro de telemetría. A continuación, me permitiré traducir algunas normas, proporcionando aclaraciones cuando sea necesario.

El campo del identificador del canal maestro (Master Channel ID) debe contener el número de versión del cuadro y el identificador de la unidad.

Cada KA, según los estándares CCSDS, debe tener un identificador único, con el que se puede determinar a qué aparato pertenece el paquete dado. Formalmente, es necesario presentar una solicitud de registro del aparato, y su nombre, junto con el identificador, será publicado en fuentes abiertas. Sin embargo, a menudo los fabricantes rusos ignoran este procedimiento y asignan un identificador arbitrario al aparato. El número de versión del paquete ayuda a determinar qué versión de los estándares se utiliza para leer correctamente el paquete. Aquí solo examinaremos el estándar más conservador con versión "0".

En el campo del identificador del canal virtual (Virtual Channel ID) debe contener el VCID del canal del cual se ha recibido el paquete. No hay restricciones en la elección del VCID, en particular los canales virtuales no tienen por qué estar numerados de manera secuencial.

A menudo surge la necesidad de multiplexar los datos transmitidos. Para ello existe un mecanismo de canales virtuales. Por ejemplo, el satélite Meteor-M2 transmite imágenes en color en el rango visible, separándolas en tres imágenes en blanco y negro: cada color se transmite en su propio canal virtual en paquetes separados, aunque en la estructura de sus paquetes hay cierta desviación de los estándares.

El campo de bandera de Control Operativo debe ser un indicador de la presencia o ausencia del campo de Control Operativo en el paquete de telemetría. Estos 4 bytes al final del paquete se utilizan para mantener la retroalimentación al controlar la entrega de paquetes de comandos. Hablaremos de ello un poco más adelante.

Los contadores de paquetes del canal principal y el canal virtual son campos que se incrementan en uno con el envío de cada paquete. Sirven como indicadores de que no se ha perdido ningún paquete.

El estado de los datos del paquete de telemetría son otros dos bytes de banderas y datos, de los cuales solo examinaremos algunos.

El campo de bandera de encabezado adicional (Secondary Header) debe ser un indicador de la presencia o ausencia de un encabezado adicional (Secondary Header) en el paquete de telemetría.

Si se desea, se puede añadir un encabezado adicional a cada paquete y colocar allí cualquier dato a discreción.

El campo del puntero al primer encabezado (First Header Pointer), con un 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 (Data Field) del marco de telemetría. La posición se cuenta desde 0 en orden ascendente desde el inicio del campo de datos. Si no hay inicio de paquete en el campo de datos del marco de telemetría, entonces el campo del puntero al primer encabezado debe tener un valor en representación binaria «11111111111» (esto puede ocurrir si un paquete largo se extiende más de un marco).

Si en el campo de datos se contiene un paquete vacío (Idle Data), entonces el puntero al primer encabezado debe tener un valor en representación binaria «11111111110». Basado en este campo, el receptor debe sincronizar el flujo. Este campo garantiza la recuperación de la sincronización incluso en caso de pérdida de fotogramas.

Es decir, el paquete puede, supongamos, comenzar a mitad del cuarto fotograma y terminar al inicio del vigésimo. Para encontrar su inicio, este campo es precisamente el que se utiliza. Los paquetes también tienen un encabezado, en el que se especifica su longitud, por lo que al encontrar el puntero al primer encabezado, el procesador de nivel de enlace debe leerlo, determinando así dónde terminará el paquete.
Si el campo de control de errores está presente, debe estar contenido en cada marco de telemetría para un canal físico específico durante toda la misión.

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

Telecargas

El marco de telecargas tiene varias diferencias significativas. Entre ellas:

Estructura de encabezados diferente
Longitud dinámica. Esto significa que la longitud del marco no está fijada rígidamente, como se hace en la telemetría, sino que puede variar en función de los paquetes transmitidos.
Mecanismo de garantía de entrega de paquetes. Es decir, la aeronave debe confirmar la recepción correcta de los marcos después de recibirlos, o solicitar reenvío desde el marco que pudo haber sido recibido con un error no corregible.

Muchos campos ya nos son familiares del encabezado del marco de telemetría. Tienen el mismo propósito, por lo que aquí solo se considerarán los nuevos campos.

Un bit de la bandera de bypass debe ser utilizado para controlar la verificación de tramas en el receptor. Un valor de «0» en esta bandera debe indicar que esta trama es de tipo A y su verificación debe llevarse a cabo de acuerdo con FARM. Un valor de «1» en esta bandera debe indicar al receptor que esta trama es de tipo B y debe omitir la verificación de acuerdo con FARM.

Esta bandera informa al receptor si se debe utilizar el mecanismo de confirmación de entrega de tramas, denominado FARM — Mecanismo de Aceptación y Reporte de Tramas.

La bandera de control de comando debe utilizarse para entender si el campo de datos transporta un comando o datos. Si la bandera es «0», el campo de datos debe contener datos. Si la bandera es «1», el campo de datos debe contener información de control para FARM.
FARM constituye una máquina de estados finita cuyos parámetros son ajustables.

RSVD. SPARE – bits reservados.

Parece que CCSDS tiene planes para ellos en el futuro, y para la retrocompatibilidad de las versiones del protocolo, ya han reservado estos bits en las versiones actuales del estándar.

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

El campo de datos de la trama debe seguir al encabezado sin interrupciones y contener un número entero de octetos, cuya longitud puede ser de un máximo de 1019 octetos. Este campo debe contener ya sea un bloque de datos de la trama o información de control de comando. El bloque de datos de la trama debe contener:

un número entero de octetos de datos del usuario
el encabezado del segmento y un número entero de octetos de datos del usuario que lo siguen

Si el encabezado está presente, el bloque de datos debe contener un Paquete, múltiples Paquetes o parte de estos. Un bloque de datos sin encabezado no puede contener partes de Paquetes, pero puede contener bloques de datos de formato privado. Esto implica que el encabezado es necesario cuando el bloque de datos transmitido no cabe en un único trama. Un bloque de datos que tiene encabezado se llama segmento.

El campo de banderas 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 la última parte de los datos está en el bloque de datos
«11» — si no hay división y un paquete o varios se colocan completamente en el bloque de datos.

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

FARM

Analicemos más a fondo el mecanismo de funcionamiento del sistema de control de entrega de tramas. Este sistema está diseñado para trabajar únicamente con tramas de comandos debido a su importancia (siempre se puede solicitar la telemetría nuevamente, pero la nave espacial debe escuchar claramente a la estación terrestre y siempre obedecer sus órdenes). Supongamos que decidimos reprogramar nuestro satélite y enviamos a bordo un archivo binario de 10 kilobytes. A nivel de enlace, el archivo se divide en 10 tramas (0, 1, …, 9), que se envían secuencialmente. Cuando la transmisión se ha completado, la nave espacial debe confirmar la correcta recepción del paquete o informar en qué trama ocurrió un error. Esta información se envía en el 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 en blanco (idle frame) si no tiene nada que decir). Según la telemetría recibida, nos aseguramos de que todo esté bien o comenzamos a retransmitir el mensaje. Supongamos que el satélite no escuchó la trama nº 7. Significa que le enviamos las tramas 7, 8, 9. Si no se recibe respuesta, el paquete se envía nuevamente en su totalidad (y así varias veces, hasta que entendamos que los intentos han sido en vano).

A continuación se muestra la estructura del campo de control operativo con la descripción de algunos campos. Los datos contenidos en este campo se denominan CLCW – Comunicación de Palabra de Control de Enlace.

Dado que a partir de la imagen se puede adivinar la función de los campos principales, y mirar los otros es aburrido, escondo la descripción detallada bajo un spoiler.

Desglose de los campos CLCWTipo de palabra de control (Control Word Type):
Para este tipo de palabra de control debe contener 0.

Número de versión de la palabra de control (CLCW Version Number):
Para este tipo de palabra de control debe ser igual a «00» en representación binaria.

Campo de estado (Status Field):
El uso de este campo se define para cada misión por separado. Puede utilizarse para mejoras locales por diferentes agencias espaciales.

Identificador del canal virtual (Identificación del Canal Virtual):
Debe contener el identificador del canal virtual asociado a esta palabra de control.

Bandera de acceso al canal físico:
La bandera debe proporcionar información sobre la disponibilidad del nivel físico del receptor. Si el nivel físico del receptor no está listo para recibir fotogramas, el campo debe contener «1», de lo contrario, «0».

Bandera de fallo de sincronización:
La bandera puede indicar que el nivel físico está funcionando con una señal débil y que la cantidad de fotogramas rechazados es demasiado alta. El uso de este campo es opcional, y si se usa, debe contener «0» en presencia de sincronización, y «1» en ausencia de la misma.

Bandera de bloqueo:
Este bit debe contener el estado de bloqueo del FARM para cada canal virtual. Un valor de «1» en este campo debe indicar que el FARM está bloqueado y que los fotogramas serán descartados para cada nivel virtual, de lo contrario, «0».

Bandera de espera:
Este bit debe utilizarse para indicar que el receptor no puede procesar la información en el canal virtual especificado. Un valor de «1» indica que todos los fotogramas serán descartados en este canal virtual, de lo contrario, «0».

Bandera de reenvío:
Esta bandera debe contener «1» si uno o más fotogramas de tipo A han sido descartados o se han encontrado omisiones, por lo que se requiere un reenvío. La bandera «0» indica que no hubo fotogramas descartados ni omisiones.

Valor de respuesta:
Número de fotograma que no fue aceptado. Se determina según el contador en el encabezado del fotograma de comando.

Nivel de red

Hablemos un poco sobre este nivel. Aquí hay dos opciones posibles: usar el protocolo de paquete espacial o encapsular cualquier otro protocolo en un paquete CCSDS.

Una visión general del protocolo de paquete espacial es un tema para otro artículo. Está diseñado 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 realizan la gestión del tráfico, controlan la entrega, etc.

La encapsulación es más simple y clara. Los estándares permiten encapsular en paquetes CCSDS cualquier protocolo, añadiendo un encabezado adicional.

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

Aquí el campo principal es la longitud del dato. Puede variar de 0 a 4 bytes. Además, en este encabezado es necesario indicar el tipo de protocolo encapsulado, utilizando la tabla desde aquí.

Al encapsular IP, se utiliza otra capa para determinar el tipo de paquete.
Es necesario añadir otro encabezado, con una longitud de al menos un octeto:

Donde PID es otro identificador de protocolo tomado desde aquí

Conclusión

A primera vista, puede parecer que los encabezados CCSDS son extremadamente redundantes y algunos campos podrían ser eliminados. De hecho, la eficiencia del canal resultante (hasta el nivel de red) es de aproximadamente el 40%. Sin embargo, tan pronto como surge la necesidad de implementar estos estándares, queda claro que cada campo, cada encabezado tiene su misión importante, cuya ignorancia lleva a una serie de ambigüedades.

Si la comunidad de Habr muestra interés en este tema, estaré feliz de publicar una serie de artículos dedicados a la teoría y práctica de las comunicaciones espaciales. ¡Gracias por su atención!