🧚🏼 📐 👵🏽 Um pouco sobre os padrões de comunicação espacial 🙅🏼 👨🏼‍🤝‍👨🏻 ↔️

Meteoro Satélite M1
Fonte: vladtime.ru

1. Introdução

A operação da tecnologia espacial é impossível sem as radiocomunicações, e neste artigo tentarei explicar as idéias básicas que formaram a base dos padrões desenvolvidos pelo Comitê Consultivo para Sistemas de Dados Espaciais - CCSDS. Esta abreviação será usada abaixo.

Esta publicação será dedicada principalmente ao nível do canal; no entanto, também serão introduzidos conceitos básicos para outros níveis. Tornar-se de forma alguma reivindicar uma descrição completa e completa dos padrões. Você pode encontrá-lo no site do CCSDS. No entanto, eles são muito difíceis de perceber e, para entendê-los, passamos muito tempo, então aqui eu quero fornecer informações básicas, tendo que lidar com todo o resto será muito mais fácil. Então, vamos começar.

A nobre missão do CCSDS

Talvez alguém tenha uma pergunta: por que todos deveriam aderir aos padrões se você pode desenvolver sua própria pilha de protocolos de protocolo proprietário (ou seu próprio padrão, com blackjack e novos recursos), aumentando assim a segurança do sistema?

Como mostra a prática, é mais rentável aderir aos padrões do CCSDS pelas seguintes séries de razões:

O comitê responsável pela publicação dos padrões incluiu representantes de todas as principais agências aeroespaciais do mundo, trazendo sua experiência inestimável adquirida ao longo de muitos anos projetando e operando várias missões. Seria muito ridículo ignorar essa experiência e voltar a atacar.
Esses padrões são suportados por equipamentos de estações terrestres já existentes no mercado.
Durante a solução de problemas, você sempre pode pedir ajuda a colegas de outras agências para que eles possam realizar uma sessão de comunicação com o dispositivo a partir da estação terrestre.

Arquitetura

Os padrões são uma coleção de documentos que refletem o modelo OSI (Open System Interconnection) mais comum, exceto que, no nível do canal, a comunidade é limitada à divisão em telemetria (canal descendente - canal espaço terra) e telecomandos (canal ascendente).

Considere alguns níveis com mais detalhes, começando pelo físico e subindo. Para maior clareza, consideraremos a arquitetura do lado do host. O transmissor é sua imagem no espelho.

Nível físico

Nesse nível, o sinal de rádio modulado é convertido em um fluxo de bits. Os padrões aqui são principalmente de natureza recomendatória, pois nesse nível é difícil abstrair de uma implementação específica de ferro. Aqui, o papel principal do CCSDS é determinar as modulações permitidas (BPSK, QPSK, 8-QAM etc.) e fornecer algumas recomendações sobre a implementação de mecanismos de sincronização de símbolos, compensação de deslocamento Doppler, etc.

Nível de sincronização e codificação

Formalmente, é uma subcamada da camada de enlace de dados, mas muitas vezes é alocada como uma camada separada devido à sua importância na estrutura dos padrões do CCSDS. Esse nível converte o fluxo de bits nos chamados quadros (telemetria ou telecomando), sobre os quais falaremos mais adiante. Diferentemente da sincronização de caracteres no nível físico, que permite obter o fluxo de bits correto, a sincronização de quadros é realizada aqui. Considere o caminho que os dados percorrem nesse nível (de baixo para cima):

No entanto, antes disso, vale a pena dizer algumas palavras sobre codificação. Este procedimento é necessário para encontrar e / ou corrigir erros de bits que inevitavelmente ocorrem ao enviar dados pelo ar. Aqui não consideraremos os procedimentos de decodificação, mas apenas obteremos as informações necessárias para entender a lógica adicional do nível.

Os códigos são em bloco e contínuos. Os padrões não forçam o uso de um tipo específico de codificação, mas devem estar presentes como tal. Os contínuos incluem códigos convolucionais (colvolucionais). Utilizando-os, um fluxo de bits contínuo é codificado. Ao contrário dos códigos de bloco, em que os dados são divididos em blocos de código (codeblock) e só podem ser decodificados como parte de blocos inteiros. O bloco de código são os dados transmitidos e as informações redundantes anexadas necessárias para verificar a exatidão dos dados e corrigir possíveis erros. Os códigos de bloco incluem os famosos códigos de Reed-Solomon.

Se a codificação convolucional for usada, o fluxo de bits do início vai para o decodificador. O resultado de seu trabalho (tudo isso, é claro, está acontecendo continuamente) são unidades de dados CADU (unidade de dados de acesso ao canal). Essa estrutura é necessária para a sincronização de quadros. No final de cada CADU, é anexado um marcador de sincronização (fabricante de sincronização conectado ao ASM). Estes são 4 bytes conhecidos antecipadamente, pelos quais o sincronizador encontra o início e o fim da CADU. É assim que a sincronização de quadros é alcançada.

O próximo estágio opcional de operação da camada de sincronização e codificação está associado aos recursos da camada física. Isso é des randomização. O fato é que, para alcançar a sincronização de símbolos, é necessário alternar frequentemente entre símbolos. Portanto, se transferirmos, digamos, um kilobyte de dados consistindo apenas de unidades, a sincronização será perdida. Portanto, durante a transmissão, os dados de entrada são misturados com uma sequência pseudo-aleatória periódica para que a densidade de zeros e uns seja uniforme.

Em seguida, os códigos de bloco são decodificados e o que resta será o produto final do quadro de nível de sincronização e codificação.

Nível do canal

Por um lado, o manipulador da camada de link recebe quadros e, por outro lado, produz pacotes. Como formalmente o tamanho dos pacotes não é limitado, para seu encaminhamento confiável, é necessário dividi-los em estruturas menores - quadros. Aqui, consideramos duas subseções: separadamente para telemetria (TM) e telecommands (TC).

Telemetria

Simplificando, esses são os dados que a estação terrestre recebe da espaçonave. Todas as informações transmitidas são divididas em pequenos fragmentos de quadros de comprimento fixo que contêm os dados transmitidos e os campos de serviço. Considere a estrutura do quadro em mais detalhes:

E começaremos nossa consideração com o título principal do quadro de telemetria. Além disso, em alguns lugares me permitirei simplesmente traduzir os padrões, dando simultaneamente alguns esclarecimentos.

O campo do identificador do canal principal (ID do canal principal) deve conter o número da versão do quadro e o identificador do dispositivo.

Cada espaçonave, de acordo com os padrões do CCSDS, deve ter seu próprio identificador único, pelo qual é possível, com uma estrutura, determinar a qual veículo pertence. Formalmente, é necessário solicitar o registro do dispositivo, e seu nome, juntamente com o identificador, será publicado em fontes abertas. No entanto, frequentemente os fabricantes russos ignoram esse procedimento, atribuindo um identificador arbitrário ao dispositivo. O número da versão do quadro ajuda a determinar qual versão dos padrões é usada para ler corretamente o quadro. Aqui consideramos apenas o padrão mais conservador com a versão "0".

O ID do canal virtual deve conter o VCID do canal de onde o pacote veio. Não há restrições na escolha do VCID, em particular, os canais virtuais não são necessariamente numerados sequencialmente.

Muitas vezes, é necessário multiplexar os dados transmitidos. Existe um mecanismo de canal virtual para isso. Por exemplo, o satélite Meteor-M2 transmite uma imagem colorida na faixa visível, dividindo-a em três preto e branco - cada cor é transmitida em seu canal virtual como um pacote separado, embora haja algum desvio em relação aos padrões na estrutura de seus quadros.

O campo do sinalizador Controle Operacional deve ser um indicador da presença ou ausência do campo Controle Operacional no quadro de telemetria. Esses 4 bytes no final do quadro servem para manter o feedback ao monitorar a entrega dos quadros de telecomando. Falaremos sobre eles um pouco mais tarde.

Os contadores de quadros dos canais principal e virtual são campos que são incrementados em um quando cada quadro é enviado. Eles servem como um indicador de que nenhum quadro foi perdido.

O status dos dados do quadro de telemetria é de mais dois bytes de sinalizadores e dados, dos quais consideraremos apenas alguns.

O campo de sinalização do cabeçalho secundário (cabeçalho secundário) deve ser um indicador da presença ou ausência do cabeçalho secundário (cabeçalho secundário) no quadro de telemetria.

Se desejar, você pode adicionar um cabeçalho adicional a cada quadro e colocar todos os dados a seu critério.

O campo do ponteiro para o primeiro cabeçalho (Primeiro cabeçalho do ponteiro), com o valor do sinalizador de sincronização “1”, deve conter a representação binária da posição do primeiro octeto do primeiro pacote no campo de dados do quadro de telemetria. A posição é contada a partir de 0 em ordem crescente desde o início do campo de dados. Se não houver início de um pacote no campo de dados do quadro de telemetria, o campo do ponteiro para o primeiro cabeçalho deverá ter um valor na representação binária "11111111111" (isso pode acontecer se um pacote longo se estender para mais de um quadro).

Se o campo de dados contiver um pacote vazio (Idle Data), o ponteiro para o primeiro cabeçalho deverá ter um valor na representação binária "11111111110". Nesse campo, o receptor deve sincronizar o fluxo. Este campo garante a restauração da sincronização, mesmo no caso de pular quadros.

Ou seja, um pacote pode, suponha, começar no meio do quarto quadro e terminar no início do dia 20. Para encontrar seu começo, esse campo serve apenas. Os pacotes também possuem um cabeçalho no qual seu comprimento é registrado; portanto, quando um ponteiro para o primeiro cabeçalho é encontrado, o manipulador no nível do link deve lê-lo, determinando onde o pacote terminará.
Se um campo de controle de erro for apresentado, ele deverá estar contido em cada quadro de telemetria para um canal físico específico em toda a missão.

Este campo é calculado usando o método CRC. O procedimento deve aceitar n-16 bits do quadro de telemetria e inserir o resultado do cálculo nos últimos 16 bits.

Telecommands

O quadro de telecomando tem várias diferenças significativas. Entre eles estão:

Estrutura de cabeçalho diferente
Comprimento dinâmico. Isso significa que o comprimento do quadro não é definido rigidamente, como é feito na telemetria, mas pode variar dependendo dos pacotes transmitidos.
Mecanismo de garantia de entrega de pacotes. Ou seja, após a recepção, a sonda deve confirmar a recepção correta dos quadros ou solicitar o encaminhamento do quadro que pode ser recebido com um erro incorrigível.

Muitos campos já nos são familiares no cabeçalho do quadro de telemetria. Eles têm o mesmo objetivo, então aqui consideramos apenas novos campos.

Um bit da bandeira de desvio deve ser usado para monitorar a verificação do quadro no receptor. O valor "0" desse sinalizador deve indicar que esse quadro é um tipo A e deve ser verificado de acordo com a FARM. O valor "1" deste sinalizador deve indicar ao receptor que esse quadro é um quadro do tipo B e deve ignorar a verificação de acordo com a FARM.

Este sinalizador informa ao destinatário se deve usar o mecanismo de confirmação de entrega de quadros chamado FARM - Mecanismo de Aceitação e Relatório de Quadros.

O sinalizador de comando de controle deve ser usado para entender se o campo de dados está transportando o comando ou os dados. Se o sinalizador for "0", o campo de dados deve conter dados. Se o sinalizador for "1", o campo de dados deve conter as informações de controle do FARM.
FARM é uma máquina de estado cujos parâmetros podem ser configurados.

RSVD. SOBRESSELENTES - bits reservados.

Parece que o CCSDS tem planos para eles no futuro e, para compatibilidade com versões anteriores de versões de protocolo, eles reservaram esses bits já nas versões atuais do padrão.

O campo de comprimento do quadro deve conter um número na representação de bits, que é igual ao comprimento do quadro em octetos menos um.

O campo de dados do quadro deve seguir o cabeçalho sem intervalos e conter um número inteiro de octetos, que pode ter no máximo 1019 octetos. Este campo deve conter um bloco de dados ou informações do quadro de um comando de controle. O bloco de dados do quadro deve conter:

octeto inteiro dados do usuário
cabeçalho do segmento seguido por um octeto inteiro de dados do usuário

Se um cabeçalho for fornecido, o bloco de dados deverá conter um pacote, muitos pacotes ou parte dele. Um bloco de dados sem cabeçalho não pode conter partes de pacotes, mas pode conter blocos de dados de formato privado. Daí resulta que o cabeçalho é necessário quando o bloco de dados transmitidos não se encaixa em um quadro. Um bloco de dados com um cabeçalho é chamado de segmento.

Um campo de sinalizador de dois bits deve conter:

"01" - se a primeira parte dos dados estiver no bloco de dados
"00" - se a parte do meio dos dados estiver no bloco de dados
"10" - se o último dado estiver no bloco de dados
"11" - se não houver divisão e um ou mais pacotes forem colocados no bloco de dados como um todo.

O campo identificador MAP deve conter zeros se os canais MAP não forem utilizados.
Às vezes, 6 bits alocados aos canais virtuais não são suficientes. E se você precisar multiplexar dados em um número maior de canais, outros 6 bits do cabeçalho do segmento serão usados.

Fazenda

Vamos considerar em mais detalhes o mecanismo de funcionamento do sistema de controle de entrega de pessoal. Esse sistema apenas trabalha com o pessoal de telecomunicações em vista de sua importância (a telemetria sempre pode ser solicitada novamente, e a espaçonave deve ouvir a estação terrestre claramente e sempre obedecer seus comandos). Então, suponha que tenhamos decidido atualizar nosso satélite e enviar um arquivo binário de 10 kilobytes a bordo. No nível do canal, o arquivo é dividido em 10 quadros (0, 1, ..., 9), que são enviados um de cada vez para o topo. Quando a transmissão estiver concluída, a espaçonave deve confirmar a recepção correta do pacote ou relatar em qual quadro ocorreu um erro. Essas informações são enviadas para o campo de controle operacional no quadro de telemetria mais próximo (ou a sonda pode iniciar a transmissão de um quadro vazio (quadro inativo) se não tiver nada a dizer). Com base na telemetria recebida, garantimos que está tudo bem ou continuamos a reenviar a mensagem. Suponha que o satélite não tenha ouvido o quadro número 7. Então, enviamos os quadros 7, 8, 9. Se não houver resposta, o pacote é enviado novamente completamente (e assim por diante várias vezes até entendermos que as tentativas são inúteis).

Abaixo está a estrutura do campo de controle operacional com uma descrição de alguns campos. Os dados contidos neste campo são chamados CLCW - Communication Link Control Word.

Como é possível adivinhar pela imagem o objetivo dos campos principais, enquanto olhar para os outros é chato, oculto a descrição detalhada sob o spoiler

Decodificando campos CLCW

Tipo de Palavra de Controle (Tipo de Palavra de Controle):
Para esse tipo de controle, a palavra deve conter 0

Versão da Palavra de Controle (Número da Versão CLCW):
Para esse tipo de palavra de controle, deve ser igual a "00" na representação de bits.

Campo Status:
O uso desse campo é determinado para cada missão separadamente. Pode ser usado para melhorias locais por diferentes agências espaciais.

Identificação do canal virtual:
Deve conter o identificador do canal virtual ao qual esta palavra de controle está associada.

Sinalizador de acesso ao canal físico:
A bandeira deve fornecer informações sobre a prontidão da camada física do receptor. Se o nível físico do receptor não estiver pronto para receber quadros, o campo deverá conter "1", caso contrário "0".

Sinalizador de falha de sincronização:
O sinalizador pode indicar que a camada física está operando em um nível de sinal ruim e o número de quadros rejeitados é muito alto. O uso deste campo é opcional, se usado, deve conter "0" na presença de sincronização e "1" na sua ausência.

Sinalizador de bloqueio:
Este bit deve conter o status de bloqueio do FARM para cada canal virtual. O valor "1" neste campo deve indicar que o FARM está bloqueado e os quadros serão descartados para cada nível virtual, caso contrário, "0".

Bandeira de espera:
Este bit deve ser usado para indicar que o receptor não pode processar o dado no canal virtual especificado. Um valor "1" indica que todos os quadros serão descartados neste canal virtual, caso contrário "0".

Bandeira da remessa:
Esse sinalizador deve conter "1" se um ou mais quadros do tipo A forem descartados ou forem encontradas lacunas, portanto, é necessário reenviar. A bandeira "0" indica que não houve quadros e omissões descartados.

Valor da resposta:
O número do quadro que não foi recebido. É determinado pelo contador no cabeçalho do quadro de telecomunicações.

Camada de rede

Um pequeno toque neste nível. Duas opções são possíveis aqui: use o protocolo de pacote espacial ou encapsule qualquer outro protocolo no pacote CCSDS.

Uma revisão do protocolo de pacotes espaciais é um tópico para um artigo separado. Foi criado para que os chamados aplicativos possam trocar dados sem problemas. Cada aplicativo possui seu próprio endereço e funcionalidade básica para a troca de dados com outros aplicativos. Também existem serviços que direcionam o tráfego, realizam o controle de entrega, etc.

Com o encapsulamento, tudo é mais simples e mais compreensível. Os padrões tornam possível encapsular qualquer protocolo nos pacotes CCSDS adicionando um cabeçalho adicional.