Satélite Meteoro M1
Fuente: vladtime.ru
introducción
El funcionamiento de la tecnología espacial es imposible sin las comunicaciones por radio, y en este artículo intentaré explicar las ideas principales que formaron la base de los estándares desarrollados por el Comité Asesor Internacional para Sistemas de Datos Espaciales (CCSDS. Esta abreviatura se utilizará a continuación). .
Esta publicación se centrará principalmente en la capa de enlace de datos, pero también se introducirán conceptos básicos para otras capas. Este artículo de ninguna manera pretende ser una descripción minuciosa y completa de los estándares. Puedes verlo en CCSDS. Sin embargo, son muy difíciles de entender y pasamos mucho tiempo tratando de entenderlos, por eso aquí quiero brindar información básica, con la cual será mucho más fácil entender todo lo demás. Vamos a empezar.
Noble Misión del CCSDS
Quizás alguien tenga una pregunta: ¿por qué todos deberían cumplir con los estándares si usted puede desarrollar su propia pila de protocolos de radio (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 las siguientes razones:
- El comité responsable de publicar los estándares incluye representantes de todas las agencias aeroespaciales más importantes del mundo, lo que aporta una experiencia invaluable adquirida durante muchos años de diseño y operación de diversas misiones. Sería muy absurdo ignorar esta experiencia y volver a pisarles el rastrillo.
- Estos estándares están respaldados por equipos de estaciones terrestres que ya están en el mercado.
- Al solucionar cualquier problema, siempre puede buscar ayuda de colegas de otras agencias para que puedan realizar una sesión de comunicación con el dispositivo desde su estación terrestre. Como puede ver, los estándares son algo extremadamente útil, así que veamos 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, excepto que a nivel de enlace de datos la similitud se limita a la división en telemetría (enlace descendente - espacio - Tierra) y telecomandos (enlace ascendente).
Veamos algunos de los niveles con más detalle, comenzando por el físico y subiendo. Para mayor claridad, consideraremos la arquitectura del lado receptor. 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 principalmente de carácter consultivo, ya que en este nivel es difícil abstraerse de la implementación específica del hardware. Aquí, el papel clave del CCSDS es definir las modulaciones aceptables (BPSK, QPSK, 8-QAM, etc.) y proporcionar algunas recomendaciones para la implementación de mecanismos de sincronización de símbolos, compensación Doppler, etc.
Nivel de sincronización y codificación.
Formalmente, es una subcapa de la capa de enlace de datos, pero a menudo se separa en una capa separada debido a su importancia dentro de los estándares CCSDS. Esta capa convierte el flujo de bits en las llamadas tramas (telemetría o telecomandos), de las que hablaremos más adelante. A diferencia de la sincronización de símbolos en la capa física, que le permite obtener el flujo de bits correcto, aquí se realiza la sincronización de cuadros. Considere el camino que toman los datos en 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 a través de un canal de radio. 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 pueden ser de bloque o continuos. Los estándares no obligan al uso de un tipo específico de codificación, pero debe estar presente como tal. Los códigos continuos incluyen códigos convolucionales. Se utilizan para codificar un flujo de bits continuo. Esto contrasta con los códigos de bloque, donde los datos se dividen en bloques de código y solo se pueden decodificar dentro de bloques completos. El bloque de código representa los datos transmitidos y la información redundante adjunta necesaria para verificar la exactitud de los datos recibidos y corregir posibles errores. Los códigos de bloque incluyen los famosos códigos Reed-Solomon.
Si se utiliza codificación convolucional, el flujo de bits ingresa al decodificador desde el principio. El resultado de su trabajo (todo esto, por supuesto, ocurre continuamente) son bloques de datos CADU (unidad de datos de acceso al canal). Esta estructura es necesaria para la sincronización de cuadros. Al final de cada CADU hay un sincronizador adjunto (ASM). Se trata de 4 bytes conocidos de antemano, mediante los cuales el sincronizador encuentra el principio y el final de la CADU. Así es como se logra la sincronización de cuadros.
La siguiente etapa opcional de la capa de sincronización y codificación está asociada con las peculiaridades de la capa física. Esto es desaleatorización. El hecho es que para lograr la sincronización de símbolos, es necesario cambiar frecuentemente entre símbolos. Entonces, si transmitimos, digamos, un kilobyte de datos que consta exclusivamente de 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 para que la densidad de ceros y unos sea uniforme.
A continuación, se decodifican los códigos de bloque y lo que queda es el producto final del nivel de sincronización y codificación: un fotograma.
Capa de enlace de datos
Por un lado, el procesador de la capa de enlace recibe tramas y por el otro emite paquetes. Dado que el tamaño de los paquetes no está limitado formalmente, para su transmisión confiable es necesario dividirlos en estructuras más pequeñas: tramas. Aquí veremos 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 longitud fija: marcos que contienen datos transmitidos y campos de servicio. Echemos un vistazo más de cerca a la estructura del marco:
Y comencemos nuestra consideración con el encabezado principal del marco de telemetría. Además, me permitiré simplemente traducir los estándares en algunos lugares, dando algunas aclaraciones a lo largo del camino.
El campo ID del canal maestro debe contener el número de versión del marco y el identificador del dispositivo.
Cada nave espacial, según los estándares CCSDS, debe tener su propio identificador único, mediante el cual, teniendo un marco, se puede determinar a qué dispositivo pertenece. Formalmente, es necesario presentar una solicitud para registrar el dispositivo, y su nombre, junto con su identificador, se publicarán en fuentes abiertas. Sin embargo, los fabricantes rusos a menudo 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 utiliza para leer correctamente el marco. Aquí consideraremos sólo el estándar más conservador con la versión "0".
El campo ID del canal virtual debe contener el VCID del canal del que procede el paquete. No existen restricciones en la elección de VCID; en particular, los canales virtuales no están necesariamente numerados de forma secuencial.
Muy a menudo existe la necesidad de multiplexar los datos transmitidos. Para ello existe un mecanismo de canales virtuales. 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 en un paquete separado, aunque hay alguna desviación de los estándares en el estructura de sus marcos.
El campo de bandera de control operativo será un indicador de la presencia o ausencia del campo de control operativo en la trama de telemetría. Estos 4 bytes al final de la trama sirven para proporcionar retroalimentación al controlar la entrega de tramas de telecomando. Hablaremos de ellos un poco más tarde.
Los contadores de tramas del canal principal y virtual son campos que se incrementan en uno cada vez que se envía una trama. Sirve como indicador de que no se perdió ni un solo fotograma.
El estado de los datos del marco de telemetría son dos bytes más de indicadores y datos, de los cuales veremos solo algunos.
El campo de bandera de encabezado secundario debe ser un indicador de la presencia o ausencia de un encabezado secundario en el marco de telemetría.
Si lo desea, puede agregar un encabezado adicional a cada cuadro y colocar allí los datos que desee.
El campo Primer puntero de encabezamiento, cuando la bandera de sincronización está fijada a "1", contendrá una 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 principio del campo de datos. Si no hay un inicio del paquete en el campo de datos de la trama de telemetría, entonces el puntero al primer campo de encabezado debe tener el valor en representación binaria "11111111111" (esto puede suceder si un paquete largo se distribuye en más de una trama ).
Si el campo de datos contiene un paquete vacío (datos inactivos), entonces el puntero al primer encabezado debe tener el valor en representación binaria "11111111110". Usando este campo, el receptor debe sincronizar la transmisión. Este campo garantiza que la sincronización se restablezca incluso si se eliminan fotogramas.
Es decir, un paquete puede, digamos, comenzar en la mitad del cuarto cuadro y terminar al comienzo del vigésimo. Este campo se utiliza para encontrar su comienzo. Los paquetes también tienen un encabezado que especifica su longitud, de modo que cuando se encuentra un puntero al primer encabezado, el procesador de la capa de enlace debe leerlo, determinando así dónde terminará el paquete.
Si hay un campo de control de errores, debe estar contenido en cada trama de telemetría para un canal físico particular durante toda la misión.
Este campo se calcula utilizando el método CRC. El procedimiento debe tomar n-16 bits de la trama de telemetría e insertar el resultado del cálculo en los últimos 16 bits.
equipos de television
El marco de comando de TV tiene varias diferencias significativas. Entre ellos:
- Estructura de encabezado diferente
- Longitud dinámica. Esto significa que la longitud de la trama no se establece de forma rígida, como se hace en la telemetría, sino que puede variar dependiendo de los paquetes transmitidos.
- Mecanismo de garantía de entrega de paquetes. Es decir, la nave espacial debe, después de recibirla, confirmar la exactitud de la recepción de la trama o solicitar el reenvío de una trama que podría haberse recibido con un error incorregible.
Muchos campos ya nos resultan familiares por el encabezado del marco de telemetría. Tienen el mismo propósito, por lo que aquí consideraremos sólo los campos nuevos.
Se debe utilizar un bit del indicador de derivación para controlar la verificación de tramas en el receptor. Un valor de "0" para esta bandera indicará que la trama es de tipo A y debe verificarse de acuerdo con FARM. Un valor de "1" para esta bandera debería indicar al receptor que esta trama es una trama de tipo B y debería pasar por alto la verificación FARM.
Este indicador informa al receptor si debe utilizar un mecanismo de reconocimiento de entrega de tramas llamado FARM - Mecanismo de notificación y aceptación de tramas.
El indicador de comando de control debe usarse para comprender si el campo de datos transporta un comando o datos. Si la bandera es "0", entonces el campo de datos debe contener datos. Si el indicador es "1", entonces el campo de datos debe contener información de control para FARM.
FARM es una máquina de estados finitos cuyos parámetros se pueden configurar.
RSVD. REPUESTO: bits reservados.
Parece que CCSDS tiene planes para ellos en el futuro, y para la compatibilidad con versiones anteriores de los protocolos ya han reservado estos bits en las versiones actuales del estándar.
El campo de longitud de trama debe contener un número en representación de bits que sea igual a la longitud de trama en octetos menos uno.
El campo de datos del marco debe seguir al encabezado sin espacios y contener un número entero de octetos, que puede tener una longitud máxima de 1019 octetos. Este campo debe contener un bloque de datos de trama o información de comando de control. El bloque de datos del marco debe contener:
- número entero de octetos de datos de usuario
- encabezado de segmento seguido de un número entero de octetos de datos de usuario
Si hay un encabezado, entonces el bloque de datos debe contener un paquete, un conjunto de paquetes o parte de un paquete. Un bloque de datos sin encabezado no puede contener partes de paquetes, pero puede contener bloques de datos en formato privado. De esto se deduce que se requiere un encabezado cuando el bloque de datos transmitido no cabe en un cuadro. Un bloque de datos que tiene un 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 el último dato está en el bloque de datos
- “11” - si no hay división y uno o más paquetes caben completamente en el bloque de datos.
El campo ID de MAP debe contener ceros si no se utilizan canales MAP.
A veces, 6 bits asignados a 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.
GRANJA
Echemos un vistazo más de cerca al mecanismo de funcionamiento del sistema de control de entrega de personal. Este sistema solo permite trabajar con cuadros de telecomandos debido a su importancia (la telemetría siempre se puede volver a solicitar, y la nave espacial debe escuchar claramente la estación terrestre y obedecer siempre sus órdenes). Entonces, supongamos que decidimos actualizar nuestro satélite y enviarle un archivo binario de 10 kilobytes de tamaño. A nivel de enlace, el archivo se divide en 10 fotogramas (0, 1, ..., 9), que se envían hacia arriba uno por uno. Cuando se completa la transmisión, el satélite debe confirmar la exactitud de la recepción del paquete o informar en qué cuadro se produjo el 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 inactiva si no tiene nada que decir). En base a la telemetría recibida o nos aseguramos de que todo está bien o procedemos a reenviar el mensaje. Supongamos que el satélite no escuchó el cuadro 7. Esto significa que le enviamos las tramas 7, 8, 9. Si no hay respuesta, se vuelve a enviar el paquete completo (y así varias veces hasta que nos damos cuenta de que los intentos son en vano).
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 del enlace de comunicación.
Como puedes adivinar fácilmente en la imagen el propósito de los campos principales y los demás son aburridos de ver, ocultaré la descripción detallada debajo de un spoiler.
Explicación de los campos CLCWTipo de palabra de control:
Para este tipo, la palabra de control debe contener 0
Versión de la palabra de control (número de versión CLCW):
Para este tipo, la palabra de control debe ser igual a "00" en la representación de bits.
Campo de estado:
El uso de este campo se determina para cada misión por separado. Puede ser utilizado para mejoras locales por varias agencias espaciales.
Identificación de canal virtual:
Debe contener el identificador del canal virtual al que está asociada esta palabra de control.
Bandera de acceso al canal físico:
La bandera debe proporcionar información sobre la preparación de la capa física del receptor. Si la capa física del receptor no está lista para recibir tramas, entonces el campo debe contener "1", en caso contrario "0".
Indicador de error de sincronización:
La bandera puede indicar que la capa física está funcionando con un nivel de señal deficiente y que la cantidad de tramas rechazadas es demasiado alta. El uso de este campo es opcional; si se usa, debe contener “0” si la sincronización está disponible y “1” si no lo está.
Bandera de bloqueo:
Este bit contendrá el estado de bloqueo FARM para cada canal virtual. Un valor de "1" en este campo debe indicar que FARM está deshabilitado y las tramas se descartarán para cada capa virtual; de lo contrario, "0".
Bandera de espera:
Este bit se utilizará para indicar que el receptor no puede procesar datos en el canal virtual especificado. Un valor de "1" indica que todas las tramas se descartarán en este canal virtual; de lo contrario, "0".
Bandera delantera:
Esta bandera contendrá un "1" si una o más tramas de tipo A han sido descartadas o se han encontrado espacios, por lo que es necesario reenviar. El indicador "0" indica que no se perdieron fotogramas ni se omitieron.
Valor de respuesta:
Número de fotograma que no se recibió. Determinado por el contador en el encabezado de la trama de telecomando
Capa de red
Toquemos un poco este nivel. Aquí hay dos opciones: utilizar el protocolo de paquete espacial o encapsular cualquier otro protocolo en el paquete CCSDS.
Una descripción general del protocolo de paquetes espaciales es un tema para un artículo aparte. Está diseñado para permitir que las llamadas aplicaciones intercambien datos sin problemas. Cada aplicación tiene su propia dirección y funcionalidad básica para intercambiar datos con otras aplicaciones. También existen servicios que encaminan el tráfico, controlan la entrega, etc.
Con la encapsulación todo es más sencillo y claro. Los estándares permiten encapsular cualquier protocolo en paquetes CCSDS agregando un encabezado adicional.
Donde el encabezado tiene diferentes significados según la longitud del protocolo que se encapsula:
Aquí el campo principal es la longitud de la longitud. Puede variar de 0 a 4 bytes. También en este encabezado deberás indicar el tipo de protocolo encapsulado utilizando la tabla .
La encapsulación de IP utiliza otro complemento para determinar el tipo de paquete.
Debe agregar un encabezado más, de un octeto de longitud:
Donde PID es otro identificador de protocolo tomado
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 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 título tiene su propia misión importante, ignorarla conduce a una serie de ambigüedades.
Si la habrasociety muestra interés en este tema, estaré encantado de publicar una serie completa de artículos dedicados a la teoría y la práctica de las comunicaciones espaciales. ¡Gracias por su atención!
fuentes
PS
No golpees demasiado fuerte si encuentras alguna imprecisión. Denúncialos y se solucionarán :)
Fuente: habr.com