{"id":35921,"date":"2019-10-31T22:07:35","date_gmt":"2019-10-31T19:07:35","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nemnogo-o-standartah-kosmicheskoj-svyazi\/"},"modified":"2019-10-31T22:07:35","modified_gmt":"2019-10-31T19:07:35","slug":"nemnogo-o-standartah-kosmicheskoj-svyazi","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Un poco sobre los est\u00e1ndares de comunicaci\u00f3n espacial","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Un
\nSat\u00e9lite Meteor M1
\nFuente: vladtime.ru<\/i><\/p>\n

Introducci\u00f3n<\/h2>\n

\nLa operaci\u00f3n de la tecnolog\u00eda espacial es imposible sin comunicaci\u00f3n por radio, y en este art\u00edculo intentar\u00e9 explicar las ideas fundamentales que sustentan los est\u00e1ndares desarrollados por el Comit\u00e9 Consultivo para Sistemas de Datos Espaciales (Consultative Committee for Space Data Systems \u2013 CCSDS; en adelante se utilizar\u00e1 esta abreviatura).<\/p>\n

Esta publicaci\u00f3n se centrar\u00e1 principalmente en la capa de enlace, aunque tambi\u00e9n se introducir\u00e1n conceptos b\u00e1sicos para otros niveles. Este art\u00edculo no pretende ser una descripci\u00f3n exhaustiva y completa de los est\u00e1ndares. Se puede consultar en el sitio web<\/a><\/noindex> CCSDS. Sin embargo, son bastante dif\u00edciles de entender, y para comprenderlos hemos dedicado un tiempo considerable, as\u00ed que aqu\u00ed quiero ofrecer informaci\u00f3n b\u00e1sica que facilitar\u00e1 la comprensi\u00f3n de todo lo dem\u00e1s. As\u00ed que, empecemos.
\n<\/a><\/noindex><\/p>\n

La noble misi\u00f3n del CCSDS<\/h2>\n

\nPuede que alguien se pregunte: \u00bfpor qu\u00e9 todos deben seguir los est\u00e1ndares, si se puede desarrollar un propio conjunto de protocolos de comunicaci\u00f3n por radio (o un est\u00e1ndar propio, con blackjack y nuevas funciones), aumentando as\u00ed la seguridad del sistema?<\/p>\n

La pr\u00e1ctica demuestra que es m\u00e1s ventajoso seguir los est\u00e1ndares del CCSDS por las siguientes razones:<\/p>\n

    \n
  1. En el comit\u00e9 responsable de la publicaci\u00f3n de est\u00e1ndares participan representantes de todas las principales agencias aeroespaciales del mundo, quienes aportan su valiosa experiencia adquirida a lo largo de muchos a\u00f1os en el dise\u00f1o y operaci\u00f3n de diversas misiones. Ser\u00eda muy absurdo ignorar esta experiencia y volver a tropezar con las mismas piedras.<\/li>\n
  2. Estos est\u00e1ndares son compatibles con el equipo existente en el mercado de estaciones terrestres.<\/li>\n
  3. Durante la resoluci\u00f3n de cualquier problema, siempre se puede acudir a compa\u00f1eros de otras agencias para que realicen una sesi\u00f3n de comunicaci\u00f3n con el dispositivo desde su estaci\u00f3n terrestre. Como se puede ver, los est\u00e1ndares son extremadamente \u00fatiles, as\u00ed que analicemos sus puntos clave.<\/li>\n<\/ol>\n

    <\/p>\n

    Arquitectura<\/h2>\n

    \nLos est\u00e1ndares son un conjunto de documentos que reflejan el modelo OSI (Interconexi\u00f3n de Sistemas Abiertos) m\u00e1s com\u00fan, salvo que en la capa de enlace la generalidad se limita a la separaci\u00f3n entre telemetr\u00eda (canal \"hacia abajo\" \u2014 del espacio a la Tierra) y telecomandos (canal \"hacia arriba\").<\/p>\n

    \"Un
    \n
    \nExaminemos algunos niveles en detalle, comenzando con el f\u00edsico y avanzando hacia arriba. Para mayor claridad, consideraremos la arquitectura del lado receptor. El lado emisor es su reflejo en espejo.<\/p>\n

    Nivel f\u00edsico<\/h2>\n

    \nEn este nivel, se produce la transformaci\u00f3n de la se\u00f1al de radio modulada en un flujo de bits. Los est\u00e1ndares aqu\u00ed son en su mayor\u00eda recomendativos, ya que es complicado abstraerse de la implementaci\u00f3n espec\u00edfica del hardware. Aqu\u00ed, el papel clave de CCSDS es definir las modulaciones aceptables (BPSK, QPSK, 8-QAM, etc.) y proporcionar algunas recomendaciones sobre la implementaci\u00f3n de mecanismos de sincronizaci\u00f3n simb\u00f3lica, compensaci\u00f3n del desplazamiento Doppler, etc.<\/p>\n

    Nivel de sincronizaci\u00f3n y codificaci\u00f3n<\/h2>\n

    \nFormalmente es un subnivel del nivel de enlace, pero a menudo se destaca como un nivel independiente debido a su importancia en los est\u00e1ndares de CCSDS. Este nivel convierte el flujo de bits en los llamados tramas (de telemetr\u00eda o tele comandos), de los que hablaremos m\u00e1s adelante. A diferencia de la sincronizaci\u00f3n simb\u00f3lica en el nivel f\u00edsico, que permite obtener un flujo de bits correcto, aqu\u00ed se realiza la sincronizaci\u00f3n del marco. Examinemos el camino que los datos recorren en este nivel (de abajo hacia arriba):<\/p>\n

    \"Un
    \n
    \nSin embargo, antes de esto, vale la pena mencionar un par de palabras sobre la codificaci\u00f3n. Este procedimiento es necesario para detectar y\/o corregir errores de bits, que inevitablemente surgen al enviar datos a trav\u00e9s de un canal de radio. Aqu\u00ed no discutiremos los procedimientos de decodificaci\u00f3n, solo obtendremos la informaci\u00f3n necesaria para comprender la l\u00f3gica de funcionamiento del nivel a continuaci\u00f3n. <\/p>\n

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

    Si se utiliza codificaci\u00f3n 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\u00f3n de cuadros. Al final de cada CADU se une un marcador de sincronizaci\u00f3n (ASM - marcador de sincronizaci\u00f3n adjunto). Estos son cuatro bytes conocidos de antemano, por los que el sincronizador encuentra el inicio y el final del CADU. As\u00ed se logra la sincronizaci\u00f3n de cuadros.<\/p>\n

    El siguiente paso opcional en el trabajo del nivel de sincronizaci\u00f3n y codificaci\u00f3n est\u00e1 relacionado con las caracter\u00edsticas del nivel f\u00edsico. Esto es la desrandomizaci\u00f3n. La cuesti\u00f3n es que, para lograr la sincronizaci\u00f3n simb\u00f3lica, se necesitan r\u00e1pidos cambios entre s\u00edmbolos. As\u00ed, si, por ejemplo, transmitimos un kilobyte de datos compuesto exclusivamente por unos, se perder\u00e1 la sincronizaci\u00f3n. Por lo tanto, durante la transmisi\u00f3n, los datos de entrada se mezclan con una secuencia pseudoaleatoria peri\u00f3dica, de manera que la densidad de ceros y unos sea uniforme.<\/p>\n

    A continuaci\u00f3n, se lleva a cabo la decodificaci\u00f3n de c\u00f3digos en bloques, y lo que queda ser\u00e1 el producto final del nivel de sincronizaci\u00f3n y codificaci\u00f3n: un cuadro.<\/p>\n

    Nivel de canal<\/h2>\n

    \nPor un lado, el procesador del nivel de canal recibe cuadros, y por el otro lado, emite paquetes. Dado que formalmente no hay un l\u00edmite en el tama\u00f1o de los paquetes, para su transmisi\u00f3n confiable es necesario dividirlos en estructuras m\u00e1s peque\u00f1as: cuadros. Aqu\u00ed consideraremos dos subdivisiones: una para telemetr\u00eda (TM) y otra para telecontrol (TC).<\/p>\n

    Telemetr\u00eda<\/h3>\n

    \nEn pocas palabras, estos son los datos que la estaci\u00f3n terrestre recibe del sat\u00e9lite. Toda la informaci\u00f3n transmitida se divide en fragmentos peque\u00f1os de longitud fija: cuadros, que contienen los datos transmitidos y campos de control. Analicemos la estructura del cuadro en detalle:<\/p>\n

    \"Un
    \n
    \nY comenzaremos el an\u00e1lisis con el encabezado principal del cuadro de telemetr\u00eda. A continuaci\u00f3n, me permitir\u00e9 traducir algunas normas, proporcionando aclaraciones cuando sea necesario.<\/p>\n

    \"Un
    \n
    \nEl campo del identificador del canal maestro (Master Channel ID) debe contener el n\u00famero de versi\u00f3n del cuadro y el identificador de la unidad.<\/p>\n

    Cada KA, seg\u00fan los est\u00e1ndares CCSDS, debe tener un identificador \u00fanico, con el que se puede determinar a qu\u00e9 aparato pertenece el paquete dado. Formalmente, es necesario presentar una solicitud de registro del aparato, y su nombre, junto con el identificador, ser\u00e1 publicado en fuentes abiertas. Sin embargo, a menudo los fabricantes rusos ignoran este procedimiento y asignan un identificador arbitrario al aparato. El n\u00famero de versi\u00f3n del paquete ayuda a determinar qu\u00e9 versi\u00f3n de los est\u00e1ndares se utiliza para leer correctamente el paquete. Aqu\u00ed solo examinaremos el est\u00e1ndar m\u00e1s conservador con versi\u00f3n \"0\".<\/i><\/p>\n

    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\u00f3n del VCID, en particular los canales virtuales no tienen por qu\u00e9 estar numerados de manera secuencial.<\/p>\n

    A menudo surge la necesidad de multiplexar los datos transmitidos. Para ello existe un mecanismo de canales virtuales. Por ejemplo, el sat\u00e9lite Meteor-M2 transmite im\u00e1genes en color en el rango visible, separ\u00e1ndolas en tres im\u00e1genes 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\u00f3n de los est\u00e1ndares.<\/i><\/p>\n

    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\u00eda. Estos 4 bytes al final del paquete se utilizan para mantener la retroalimentaci\u00f3n al controlar la entrega de paquetes de comandos. Hablaremos de ello un poco m\u00e1s adelante.<\/p>\n

    Los contadores de paquetes del canal principal y el canal virtual son campos que se incrementan en uno con el env\u00edo de cada paquete. Sirven como indicadores de que no se ha perdido ning\u00fan paquete.<\/i><\/p>\n

    El estado de los datos del paquete de telemetr\u00eda son otros dos bytes de banderas y datos, de los cuales solo examinaremos algunos.<\/p>\n

    \"Un
    \n
    \nEl 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\u00eda.<\/p>\n

    Si se desea, se puede a\u00f1adir un encabezado adicional a cada paquete y colocar all\u00ed cualquier dato a discreci\u00f3n.<\/i><\/p>\n

    El campo del puntero al primer encabezado (First Header Pointer), con un valor del indicador de sincronizaci\u00f3n \u00ab1\u00bb, debe contener la representaci\u00f3n binaria de la posici\u00f3n del primer octeto del primer paquete en el campo de datos (Data Field) del marco de telemetr\u00eda. La posici\u00f3n 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\u00eda, entonces el campo del puntero al primer encabezado debe tener un valor en representaci\u00f3n binaria \u00ab11111111111\u00bb (esto puede ocurrir si un paquete largo se extiende m\u00e1s de un marco). <\/p>\n

    Si en el campo de datos se contiene un paquete vac\u00edo (Idle Data), entonces el puntero al primer encabezado debe tener un valor en representaci\u00f3n binaria \u00ab11111111110\u00bb. Basado en este campo, el receptor debe sincronizar el flujo. Este campo garantiza la recuperaci\u00f3n de la sincronizaci\u00f3n incluso en caso de p\u00e9rdida de fotogramas.<\/p>\n

    Es decir, el paquete puede, supongamos, comenzar a mitad del cuarto fotograma y terminar al inicio del vig\u00e9simo. Para encontrar su inicio, este campo es precisamente el que se utiliza. Los paquetes tambi\u00e9n 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\u00ed d\u00f3nde terminar\u00e1 el paquete.<\/i>
    \nSi el campo de control de errores est\u00e1 presente, debe estar contenido en cada marco de telemetr\u00eda para un canal f\u00edsico espec\u00edfico durante toda la misi\u00f3n.<\/p>\n

    Este campo se calcula utilizando el m\u00e9todo CRC. El procedimiento debe tomar n-16 bits del marco de telemetr\u00eda e insertar el resultado del c\u00e1lculo en los \u00faltimos 16 bits.<\/p>\n

    Telecargas<\/h4>\n

    \nEl marco de telecargas tiene varias diferencias significativas. Entre ellas:<\/p>\n

      \n
    1. Estructura de encabezados diferente<\/li>\n
    2. Longitud din\u00e1mica. Esto significa que la longitud del marco no est\u00e1 fijada r\u00edgidamente, como se hace en la telemetr\u00eda, sino que puede variar en funci\u00f3n de los paquetes transmitidos.<\/li>\n
    3. Mecanismo de garant\u00eda de entrega de paquetes. Es decir, la aeronave debe confirmar la recepci\u00f3n correcta de los marcos despu\u00e9s de recibirlos, o solicitar reenv\u00edo desde el marco que pudo haber sido recibido con un error no corregible.<\/li>\n<\/ol>\n

      \n\"Un
      \n
      \n\"Un
      \n
      \nMuchos campos ya nos son familiares del encabezado del marco de telemetr\u00eda. Tienen el mismo prop\u00f3sito, por lo que aqu\u00ed solo se considerar\u00e1n los nuevos campos.<\/p>\n

      Un bit de la bandera de bypass debe ser utilizado para controlar la verificaci\u00f3n de tramas en el receptor. Un valor de \u00ab0\u00bb en esta bandera debe indicar que esta trama es de tipo A y su verificaci\u00f3n debe llevarse a cabo de acuerdo con FARM. Un valor de \u00ab1\u00bb en esta bandera debe indicar al receptor que esta trama es de tipo B y debe omitir la verificaci\u00f3n de acuerdo con FARM.<\/p>\n

      Esta bandera informa al receptor si se debe utilizar el mecanismo de confirmaci\u00f3n de entrega de tramas, denominado FARM \u2014 Mecanismo de Aceptaci\u00f3n y Reporte de Tramas.<\/i><\/p>\n

      La bandera de control de comando debe utilizarse para entender si el campo de datos transporta un comando o datos. Si la bandera es \u00ab0\u00bb, el campo de datos debe contener datos. Si la bandera es \u00ab1\u00bb, el campo de datos debe contener informaci\u00f3n de control para FARM.
      \nFARM constituye una m\u00e1quina de estados finita cuyos par\u00e1metros son ajustables.<\/i><\/p>\n

      RSVD. SPARE \u2013 bits reservados.<\/p>\n

      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\u00e1ndar.<\/i><\/p>\n

      El campo de longitud de la trama debe contener un n\u00famero en representaci\u00f3n de bits que sea igual a la longitud de la trama en octetos menos uno.<\/p>\n

      El campo de datos de la trama debe seguir al encabezado sin interrupciones y contener un n\u00famero entero de octetos, cuya longitud puede ser de un m\u00e1ximo de 1019 octetos. Este campo debe contener ya sea un bloque de datos de la trama o informaci\u00f3n de control de comando. El bloque de datos de la trama debe contener:<\/p>\n