{"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\/pt\/blog\/administrirovanie\/nemnogo-o-standartah-kosmicheskoj-svyazi","title":{"rendered":"Um pouco sobre os padr\u00f5es de comunica\u00e7\u00e3o espacial","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

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

Introdu\u00e7\u00e3o<\/h2>\n

\nA opera\u00e7\u00e3o de equipamentos espaciais \u00e9 imposs\u00edvel sem comunica\u00e7\u00f5es de r\u00e1dio, e neste artigo tentarei explicar as ideias principais que fundamentam os padr\u00f5es desenvolvidos pelo Comit\u00ea Consultivo para Sistemas de Dados Espaciais (Consultative Committee for Space Data Systems \u2013 CCSDS. Daqui em diante, usaremos esta abrevia\u00e7\u00e3o).<\/p>\n

Esta publica\u00e7\u00e3o ser\u00e1 dedicada principalmente ao n\u00edvel de enlace, no entanto, conceitos b\u00e1sicos para outros n\u00edveis tamb\u00e9m ser\u00e3o introduzidos. O artigo n\u00e3o pretende ser uma descri\u00e7\u00e3o completa e detalhada dos padr\u00f5es. Voc\u00ea pode se familiarizar com eles em site<\/a><\/noindex> CCSDS. No entanto, eles s\u00e3o muito dif\u00edceis de compreender, e para entend\u00ea-los gastamos bastante tempo, portanto, aqui quero apresentar informa\u00e7\u00f5es b\u00e1sicas, que facilitar\u00e3o a compreens\u00e3o de tudo o mais. Vamos l\u00e1.
\n<\/a><\/noindex><\/p>\n

A nobre miss\u00e3o do CCSDS<\/h2>\n

\nTalvez algu\u00e9m se pergunte: por que todos deveriam seguir os padr\u00f5es, se \u00e9 poss\u00edvel desenvolver seu pr\u00f3prio conjunto propriet\u00e1rio de protocolos de comunica\u00e7\u00e3o por r\u00e1dio (ou seu pr\u00f3prio padr\u00e3o, com um toque especial e novos recursos), aumentando assim a seguran\u00e7a do sistema?<\/p>\n

A pr\u00e1tica mostra que \u00e9 mais vantajoso seguir os padr\u00f5es do CCSDS por uma s\u00e9rie de raz\u00f5es:<\/p>\n

    \n
  1. O comit\u00ea respons\u00e1vel pela publica\u00e7\u00e3o dos padr\u00f5es inclui representantes de todas as grandes ag\u00eancias aeroespaciais do mundo, trazendo sua valiosa experi\u00eancia adquirida ao longo de muitos anos de projeto e opera\u00e7\u00e3o de v\u00e1rias miss\u00f5es. Seria muito tolo ignorar essa experi\u00eancia e voltar a cometer os mesmos erros.<\/li>\n
  2. Esses padr\u00f5es s\u00e3o compat\u00edveis com o equipamento de esta\u00e7\u00f5es terrestres j\u00e1 dispon\u00edveis no mercado.<\/li>\n
  3. Ao resolver quaisquer falhas, voc\u00ea sempre pode pedir ajuda a colegas de outras ag\u00eancias para que realizem uma liga\u00e7\u00e3o com a sonda a partir de sua esta\u00e7\u00e3o terrestre. Como voc\u00ea pode ver, os padr\u00f5es s\u00e3o extremamente \u00fateis, ent\u00e3o vamos analisar seus pontos-chave.<\/li>\n<\/ol>\n

    <\/p>\n

    Arquitetura<\/h2>\n

    \nOs padr\u00f5es s\u00e3o um conjunto de documentos que refletem o modelo OSI (Open System Interconnection) mais comum, exceto que, no n\u00edvel de enlace, a generaliza\u00e7\u00e3o \u00e9 limitada \u00e0 divis\u00e3o entre telemetria (canal \"para baixo\" \u2013 espa\u00e7o \u2013 Terra) e telecomandos (canal \"para cima\").<\/p>\n

    \"Um
    \n
    \nVamos considerar alguns n\u00edveis em mais detalhes, come\u00e7ando pelo f\u00edsico e subindo. Para uma melhor visualiza\u00e7\u00e3o, abordaremos a arquitetura do lado receptor. O transmissor \u00e9 o espelho dela.<\/p>\n

    N\u00edvel f\u00edsico<\/h2>\n

    \nNeste n\u00edvel, ocorre a convers\u00e3o do sinal de r\u00e1dio modulada em um fluxo de bits. Os padr\u00f5es aqui s\u00e3o principalmente orientativos, uma vez que \u00e9 dif\u00edcil abstrair da implementa\u00e7\u00e3o espec\u00edfica do hardware. O papel fundamental do CCSDS \u00e9 determinar as modula\u00e7\u00f5es permitidas (BPSK, QPSK, 8-QAM, etc.) e fornecer algumas recomenda\u00e7\u00f5es sobre a implementa\u00e7\u00e3o de mecanismos de sincroniza\u00e7\u00e3o simb\u00f3lica, compensa\u00e7\u00e3o de Doppler, entre outros.<\/p>\n

    N\u00edvel de sincroniza\u00e7\u00e3o e codifica\u00e7\u00e3o<\/h2>\n

    \nFormalmente, \u00e9 um subn\u00edvel do n\u00edvel de enlace, mas frequentemente \u00e9 destacado como um n\u00edvel separado devido \u00e0 sua import\u00e2ncia dentro dos padr\u00f5es CCSDS. Este n\u00edvel converte o fluxo de bits nos chamados quadros (de telemetria ou telecomandos), que discutiremos mais adiante. Diferente da sincroniza\u00e7\u00e3o simb\u00f3lica no n\u00edvel f\u00edsico, que permite obter um fluxo de bits correto, aqui ocorre a sincroniza\u00e7\u00e3o de quadros. Vamos considerar o caminho que os dados percorrem neste n\u00edvel (de baixo para cima):<\/p>\n

    \"Um
    \n
    \nNo entanto, antes disso, vale a pena dizer algumas palavras sobre a codifica\u00e7\u00e3o. Este procedimento \u00e9 necess\u00e1rio para detectar e\/ou corrigir erros de bits que inevitavelmente surgem ao enviar dados por um canal de r\u00e1dio. Aqui, n\u00e3o discutiremos os procedimentos de decodifica\u00e7\u00e3o, mas apenas obteremos informa\u00e7\u00f5es necess\u00e1rias para compreender a l\u00f3gica de funcionamento do n\u00edvel. <\/p>\n

    Os c\u00f3digos podem ser blocos ou cont\u00ednuos. Os padr\u00f5es n\u00e3o obrigam o uso de um tipo espec\u00edfico de codifica\u00e7\u00e3o, mas esta deve estar presente. Os c\u00f3digos cont\u00ednuos incluem c\u00f3digos convolucionais. Com eles, codifica-se um fluxo de bits cont\u00ednuo. Ao contr\u00e1rio dos c\u00f3digos em bloco, onde os dados s\u00e3o divididos em blocos de c\u00f3digo e podem ser decodificados apenas dentro de blocos inteiros. Um bloco de c\u00f3digo \u00e9 composto pelos dados transmitidos e informa\u00e7\u00f5es redundantes anexadas, necess\u00e1rias para verificar a correta recep\u00e7\u00e3o dos dados e corrigir poss\u00edveis erros. Os c\u00f3digos em bloco incluem os famosos c\u00f3digos de Reed-Solomon.<\/p>\n

    Se o codifica\u00e7\u00e3o por convolu\u00e7\u00e3o \u00e9 utilizada, o fluxo de bits \u00e9 recebido pelo decodificador desde o in\u00edcio. O resultado do seu trabalho (tudo isso, claro, acontece continuamente) s\u00e3o blocos de dados CADU (unidade de dados de acesso ao canal). Esta estrutura \u00e9 necess\u00e1ria para a sincroniza\u00e7\u00e3o das imagens. No final de cada CADU, um marcador de sincroniza\u00e7\u00e3o (ASM - marcador de sincroniza\u00e7\u00e3o anexado) \u00e9 adicionado. Esses s\u00e3o 4 bytes conhecidos de antem\u00e3o, que permitem ao sincronizador encontrar o in\u00edcio e o fim do CADU. Assim, a sincroniza\u00e7\u00e3o das imagens \u00e9 alcan\u00e7ada.<\/p>\n

    A pr\u00f3xima etapa opcional do n\u00edvel de sincroniza\u00e7\u00e3o e codifica\u00e7\u00e3o est\u00e1 relacionada \u00e0s caracter\u00edsticas do n\u00edvel f\u00edsico. Isso \u00e9 a derandomiza\u00e7\u00e3o. O fato \u00e9 que, para alcan\u00e7ar a sincroniza\u00e7\u00e3o simb\u00f3lica, s\u00e3o necess\u00e1rias mudan\u00e7as frequentes entre os s\u00edmbolos. Portanto, se estivermos transmitindo, por exemplo, um quilobyte de dados compostos exclusivamente por uns, a sincroniza\u00e7\u00e3o ser\u00e1 perdida. Assim, durante a transmiss\u00e3o, os dados de entrada s\u00e3o misturados com uma sequ\u00eancia pseudo-aleat\u00f3ria peri\u00f3dica, para que a densidade de zeros e uns seja uniforme.<\/p>\n

    Em seguida, ocorre a decodifica\u00e7\u00e3o dos c\u00f3digos de bloco, e o que resta ser\u00e1 o produto final do n\u00edvel de sincroniza\u00e7\u00e3o e codifica\u00e7\u00e3o \u2013 um quadro.<\/p>\n

    N\u00edvel de canal<\/h2>\n

    \nPor um lado, o manipulador do n\u00edvel de canal recebe quadros e, por outro lado, emite pacotes. Como o tamanho dos pacotes n\u00e3o \u00e9 formalmente limitado, para sua transmiss\u00e3o confi\u00e1vel, \u00e9 necess\u00e1rio dividi-los em estruturas menores \u2013 quadros. Aqui, abordaremos duas subdivis\u00f5es: separadamente para telemetria (TM) e telecomandos (TC).<\/p>\n

    Telemetria<\/h3>\n

    \nSimplificando, esses s\u00e3o os dados que a esta\u00e7\u00e3o terrestre recebe do sat\u00e9lite. Toda a informa\u00e7\u00e3o transmitida \u00e9 dividida em pequenos fragmentos de comprimento fixo \u2013 quadros, que cont\u00eam os dados transmitidos e campos de controle. Vamos examinar a estrutura do quadro mais detalhadamente:<\/p>\n

    \"Um
    \n
    \nE come\u00e7aremos a an\u00e1lise com o cabe\u00e7alho principal do quadro de telemetria. Em seguida, permitirei-me traduzir alguns padr\u00f5es, ao mesmo tempo em que forne\u00e7o algumas explica\u00e7\u00f5es.<\/p>\n

    \"Um
    \n
    \nO campo do identificador do canal principal (Master Channel ID) deve conter o n\u00famero da vers\u00e3o do quadro e o identificador do aparelho.<\/p>\n

    Cada KA, de acordo com os padr\u00f5es CCSDS, deve ter um identificador \u00fanico, com o qual, tendo um quadro, \u00e9 poss\u00edvel determinar a qual aparelho ele pertence. Formalmente, \u00e9 necess\u00e1rio apresentar um pedido para registrar o aparelho, e seu nome, junto com o identificador, ser\u00e1 publicado em fontes abertas. No entanto, muitas vezes, os fabricantes russos ignoram esse procedimento, atribuindo ao aparelho um identificador arbitr\u00e1rio. O n\u00famero da vers\u00e3o do quadro ajuda a determinar qual vers\u00e3o dos padr\u00f5es est\u00e1 sendo utilizada, para ler corretamente o quadro. Aqui, vamos considerar apenas o padr\u00e3o mais conservador com a vers\u00e3o \"0\".<\/i><\/p>\n

    O campo do identificador do canal virtual (Virtual Channel ID) deve conter o VCID do canal a partir do qual o pacote foi recebido. N\u00e3o h\u00e1 restri\u00e7\u00f5es na escolha do VCID, em particular os canais virtuais n\u00e3o precisam ser numerados sequencialmente.<\/p>\n

    Muitas vezes, h\u00e1 a necessidade de multiplexar os dados transmitidos. Para isso, existe o mecanismo de canais virtuais. Por exemplo, o sat\u00e9lite Meteor-M2 transmite uma imagem colorida no espectro vis\u00edvel, dividindo-a em tr\u00eas canais preto e branco \u2013 cada cor \u00e9 transmitida em seu pr\u00f3prio canal virtual em um pacote separado, embora na estrutura de seus quadros haja algumas diverg\u00eancias em rela\u00e7\u00e3o aos padr\u00f5es.<\/i><\/p>\n

    O campo do indicador Operational Control deve ser um sinalizador da presen\u00e7a ou aus\u00eancia do campo Operational Control no quadro de telemetria. Esses 4 bytes no final do quadro servem para manter a retroalimenta\u00e7\u00e3o durante o controle da entrega dos quadros de comandos. Sobre isso, falaremos um pouco mais adiante.<\/p>\n

    Os contadores de quadros do canal principal e do canal virtual s\u00e3o campos que aumentam em um quando cada quadro \u00e9 enviado. Eles servem como indicador de que nenhum quadro foi perdido.<\/i><\/p>\n

    O status dos dados do quadro de telemetria consiste em mais dois bytes de flags e dados, dos quais analisaremos apenas alguns.<\/p>\n

    \"Um
    \n
    \nO campo do indicador de cabe\u00e7alho adicional (Secondary Header) deve ser um sinalizador da presen\u00e7a ou aus\u00eancia de um cabe\u00e7alho adicional (Secondary Header) no quadro de telemetria.<\/p>\n

    Se desejado, pode-se adicionar um cabe\u00e7alho adicional a cada quadro e inserir quaisquer dados que julgar conveniente.<\/i><\/p>\n

    O campo do ponteiro para o primeiro cabe\u00e7alho (First Header Pointer), quando a flag de sincroniza\u00e7\u00e3o for \u00ab1\u00bb, deve conter a representa\u00e7\u00e3o bin\u00e1ria da posi\u00e7\u00e3o do primeiro octeto do primeiro pacote no campo de dados (Data Field) do quadro de telemetria. A posi\u00e7\u00e3o \u00e9 contada a partir de 0 em ordem crescente do in\u00edcio do campo de dados. Se n\u00e3o houver o in\u00edcio do pacote no campo de dados do quadro de telemetria, ent\u00e3o o campo do ponteiro para o primeiro cabe\u00e7alho deve ter o valor na representa\u00e7\u00e3o bin\u00e1ria \u00ab11111111111\u00bb (isso pode ocorrer se um pacote longo se estender por mais de um quadro). <\/p>\n

    Se, no entanto, o campo de dados contiver um pacote vazio (Idle Data), ent\u00e3o o ponteiro para o primeiro cabe\u00e7alho deve ter o valor na representa\u00e7\u00e3o bin\u00e1ria \u00ab11111111110\u00bb. Com base neste campo, o receptor deve realizar a sincroniza\u00e7\u00e3o do fluxo. Este campo garante a recupera\u00e7\u00e3o da sincroniza\u00e7\u00e3o mesmo em caso de perda de quadros.<\/p>\n

    Ou seja, o pacote pode, por exemplo, come\u00e7ar no meio do 4\u00ba quadro e terminar no in\u00edcio do 20\u00ba. Para encontrar seu in\u00edcio, \u00e9 isso que este campo serve. Os pacotes tamb\u00e9m t\u00eam um cabe\u00e7alho, onde est\u00e1 especificado seu comprimento, portanto, ao encontrar o ponteiro para o primeiro cabe\u00e7alho, o processador de n\u00edvel de enlace deve l\u00ea-lo, determinando assim, onde o pacote terminar\u00e1.<\/i>
    \nSe o campo de controle de erros estiver presente, ele deve ser inclu\u00eddo em cada quadro de telemetria para um determinado canal f\u00edsico durante toda a miss\u00e3o.<\/p>\n

    Este campo \u00e9 calculado usando o m\u00e9todo CRC. O procedimento deve aceitar n-16 bits do quadro de telemetria e inserir o resultado do c\u00e1lculo nos \u00faltimos 16 bits.<\/p>\n

    Telecomandos<\/h4>\n

    \nO quadro de telecomandos possui algumas diferen\u00e7as significativas. Entre elas:<\/p>\n

      \n
    1. Outra estrutura de cabe\u00e7alhos<\/li>\n
    2. Comprimento din\u00e2mico. Isso significa que o comprimento do quadro n\u00e3o \u00e9 fixo, como no caso da telemetria, e pode variar dependendo dos pacotes transmitidos.<\/li>\n
    3. Mecanismo de garantia de entrega de pacotes. Ou seja, a RA deve confirmar a recep\u00e7\u00e3o correta dos quadros ap\u00f3s receb\u00ea-los, ou solicitar o reenvio a partir do quadro que pode ter sido recebido com um erro irrecuper\u00e1vel.<\/li>\n<\/ol>\n

      \n\"Um
      \n
      \n\"Um
      \n
      \nMuitos campos j\u00e1 s\u00e3o familiares para n\u00f3s a partir do cabe\u00e7alho do quadro de telemetria. Eles t\u00eam a mesma finalidade, portanto, aqui examinaremos apenas os novos campos.<\/p>\n

      Um bit da flag de contorno deve ser utilizado para controlar a verifica\u00e7\u00e3o de quadros no receptor. O valor \"0\" dessa flag deve indicar que o quadro \u00e9 um quadro do tipo A e sua verifica\u00e7\u00e3o deve ser realizada de acordo com o FARM. O valor \"1\" dessa flag deve indicar ao receptor que o quadro \u00e9 do tipo B e deve ignorar a verifica\u00e7\u00e3o conforme o FARM.<\/p>\n

      Essa flag informa ao receptor se deve usar o mecanismo de confirma\u00e7\u00e3o de entrega de quadros, chamado FARM \u2014 Mecanismo de Aceita\u00e7\u00e3o e Relato de Quadros.<\/i><\/p>\n

      A flag de controle deve ser utilizada para entender se o campo de dados transporta um comando ou dados. Se a flag \u00e9 igual a \"0\", o campo de dados deve conter dados. Se a flag \u00e9 igual a \"1\", o campo de dados deve conter informa\u00e7\u00f5es de controle para o FARM.
      \nO FARM \u00e9 uma m\u00e1quina de estados cuja configura\u00e7\u00e3o pode ser ajustada.<\/i><\/p>\n

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

      Parece que a CCSDS tem planos para eles no futuro, e para compatibilidade retroativa das vers\u00f5es do protocolo, eles j\u00e1 reservaram esses bits nas vers\u00f5es atuais do padr\u00e3o.<\/i><\/p>\n

      O campo de comprimento dos quadros deve conter um n\u00famero em representa\u00e7\u00e3o bin\u00e1ria que \u00e9 igual ao comprimento do quadro em octetos menos um.<\/p>\n

      O campo de dados do quadro deve seguir ap\u00f3s o cabe\u00e7alho sem lacunas e conter um n\u00famero inteiro de octetos, que pode ter um comprimento m\u00e1ximo de 1019 octetos. Este campo deve conter ou um bloco de dados do quadro ou informa\u00e7\u00f5es de controle. O bloco de dados do quadro deve conter:<\/p>\n