🥇Um pouco sobre os padrões de comunicação espacial

Satélite Meteor M1
Fonte: vladtime.ru

Introdução

A operação de equipamentos espaciais é impossível sem comunicações de rádio, e neste artigo tentarei explicar as ideias principais que fundamentam os padrões desenvolvidos pelo Comitê Consultivo para Sistemas de Dados Espaciais (Consultative Committee for Space Data Systems – CCSDS. Daqui em diante, usaremos esta abreviação).

Esta publicação será dedicada principalmente ao nível de enlace, no entanto, conceitos básicos para outros níveis também serão introduzidos. O artigo não pretende ser uma descrição completa e detalhada dos padrões. Você pode se familiarizar com eles em site CCSDS. No entanto, eles são muito difíceis de compreender, e para entendê-los gastamos bastante tempo, portanto, aqui quero apresentar informações básicas, que facilitarão a compreensão de tudo o mais. Vamos lá.

A nobre missão do CCSDS

Talvez alguém se pergunte: por que todos deveriam seguir os padrões, se é possível desenvolver seu próprio conjunto proprietário de protocolos de comunicação por rádio (ou seu próprio padrão, com um toque especial e novos recursos), aumentando assim a segurança do sistema?

A prática mostra que é mais vantajoso seguir os padrões do CCSDS por uma série de razões:

O comitê responsável pela publicação dos padrões inclui representantes de todas as grandes agências aeroespaciais do mundo, trazendo sua valiosa experiência adquirida ao longo de muitos anos de projeto e operação de várias missões. Seria muito tolo ignorar essa experiência e voltar a cometer os mesmos erros.
Esses padrões são compatíveis com o equipamento de estações terrestres já disponíveis no mercado.
Ao resolver quaisquer falhas, você sempre pode pedir ajuda a colegas de outras agências para que realizem uma ligação com a sonda a partir de sua estação terrestre. Como você pode ver, os padrões são extremamente úteis, então vamos analisar seus pontos-chave.

Arquitetura

Os padrões são um conjunto de documentos que refletem o modelo OSI (Open System Interconnection) mais comum, exceto que, no nível de enlace, a generalização é limitada à divisão entre telemetria (canal "para baixo" – espaço – Terra) e telecomandos (canal "para cima").

Vamos considerar alguns níveis em mais detalhes, começando pelo físico e subindo. Para uma melhor visualização, abordaremos a arquitetura do lado receptor. O transmissor é o espelho dela.

Nível físico

Neste nível, ocorre a conversão do sinal de rádio modulada em um fluxo de bits. Os padrões aqui são principalmente orientativos, uma vez que é difícil abstrair da implementação específica do hardware. O papel fundamental 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 simbólica, compensação de Doppler, entre outros.

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

Formalmente, é um subnível do nível de enlace, mas frequentemente é destacado como um nível separado devido à sua importância dentro dos padrões CCSDS. Este nível converte o fluxo de bits nos chamados quadros (de telemetria ou telecomandos), que discutiremos mais adiante. Diferente da sincronização simbólica no nível físico, que permite obter um fluxo de bits correto, aqui ocorre a sincronização de quadros. Vamos considerar o caminho que os dados percorrem neste nível (de baixo para cima):

No entanto, antes disso, vale a pena dizer algumas palavras sobre a codificação. Este procedimento é necessário para detectar e/ou corrigir erros de bits que inevitavelmente surgem ao enviar dados por um canal de rádio. Aqui, não discutiremos os procedimentos de decodificação, mas apenas obteremos informações necessárias para compreender a lógica de funcionamento do nível.

Os códigos podem ser blocos ou contínuos. Os padrões não obrigam o uso de um tipo específico de codificação, mas esta deve estar presente. Os códigos contínuos incluem códigos convolucionais. Com eles, codifica-se um fluxo de bits contínuo. Ao contrário dos códigos em bloco, onde os dados são divididos em blocos de código e podem ser decodificados apenas dentro de blocos inteiros. Um bloco de código é composto pelos dados transmitidos e informações redundantes anexadas, necessárias para verificar a correta recepção dos dados e corrigir possíveis erros. Os códigos em bloco incluem os famosos códigos de Reed-Solomon.

Se o codificação por convolução é utilizada, o fluxo de bits é recebido pelo decodificador desde o início. O resultado do seu trabalho (tudo isso, claro, acontece continuamente) são blocos de dados CADU (unidade de dados de acesso ao canal). Esta estrutura é necessária para a sincronização das imagens. No final de cada CADU, um marcador de sincronização (ASM - marcador de sincronização anexado) é adicionado. Esses são 4 bytes conhecidos de antemão, que permitem ao sincronizador encontrar o início e o fim do CADU. Assim, a sincronização das imagens é alcançada.

A próxima etapa opcional do nível de sincronização e codificação está relacionada às características do nível físico. Isso é a derandomização. O fato é que, para alcançar a sincronização simbólica, são necessárias mudanças frequentes entre os símbolos. Portanto, se estivermos transmitindo, por exemplo, um quilobyte de dados compostos exclusivamente por uns, a sincronização será perdida. Assim, 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, ocorre a decodificação dos códigos de bloco, e o que resta será o produto final do nível de sincronização e codificação – um quadro.

Nível de canal

Por um lado, o manipulador do nível de canal recebe quadros e, por outro lado, emite pacotes. Como o tamanho dos pacotes não é formalmente limitado, para sua transmissão confiável, é necessário dividi-los em estruturas menores – quadros. Aqui, abordaremos duas subdivisões: separadamente para telemetria (TM) e telecomandos (TC).

Telemetria

Simplificando, esses são os dados que a estação terrestre recebe do satélite. Toda a informação transmitida é dividida em pequenos fragmentos de comprimento fixo – quadros, que contêm os dados transmitidos e campos de controle. Vamos examinar a estrutura do quadro mais detalhadamente:

E começaremos a análise com o cabeçalho principal do quadro de telemetria. Em seguida, permitirei-me traduzir alguns padrões, ao mesmo tempo em que forneço algumas explicações.

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

Cada KA, de acordo com os padrões CCSDS, deve ter um identificador único, com o qual, tendo um quadro, é possível determinar a qual aparelho ele pertence. Formalmente, é necessário apresentar um pedido para registrar o aparelho, e seu nome, junto com o identificador, será publicado em fontes abertas. No entanto, muitas vezes, os fabricantes russos ignoram esse procedimento, atribuindo ao aparelho um identificador arbitrário. O número da versão do quadro ajuda a determinar qual versão dos padrões está sendo utilizada, para ler corretamente o quadro. Aqui, vamos considerar apenas o padrão mais conservador com a versão "0".

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ão há restrições na escolha do VCID, em particular os canais virtuais não precisam ser numerados sequencialmente.

Muitas vezes, há a necessidade de multiplexar os dados transmitidos. Para isso, existe o mecanismo de canais virtuais. Por exemplo, o satélite Meteor-M2 transmite uma imagem colorida no espectro visível, dividindo-a em três canais preto e branco – cada cor é transmitida em seu próprio canal virtual em um pacote separado, embora na estrutura de seus quadros haja algumas divergências em relação aos padrões.

O campo do indicador Operational Control deve ser um sinalizador da presença ou ausência do campo Operational Control no quadro de telemetria. Esses 4 bytes no final do quadro servem para manter a retroalimentação durante o controle da entrega dos quadros de comandos. Sobre isso, falaremos um pouco mais adiante.

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

O status dos dados do quadro de telemetria consiste em mais dois bytes de flags e dados, dos quais analisaremos apenas alguns.

O campo do indicador de cabeçalho adicional (Secondary Header) deve ser um sinalizador da presença ou ausência de um cabeçalho adicional (Secondary Header) no quadro de telemetria.

Se desejado, pode-se adicionar um cabeçalho adicional a cada quadro e inserir quaisquer dados que julgar conveniente.

O campo do ponteiro para o primeiro cabeçalho (First Header Pointer), quando a flag de sincronização for «1», deve conter a representação binária da posição do primeiro octeto do primeiro pacote no campo de dados (Data Field) do quadro de telemetria. A posição é contada a partir de 0 em ordem crescente do início do campo de dados. Se não houver o início do pacote no campo de dados do quadro de telemetria, então o campo do ponteiro para o primeiro cabeçalho deve ter o valor na representação binária «11111111111» (isso pode ocorrer se um pacote longo se estender por mais de um quadro).

Se, no entanto, o campo de dados contiver um pacote vazio (Idle Data), então o ponteiro para o primeiro cabeçalho deve ter o valor na representação binária «11111111110». Com base neste campo, o receptor deve realizar a sincronização do fluxo. Este campo garante a recuperação da sincronização mesmo em caso de perda de quadros.

Ou seja, o pacote pode, por exemplo, começar no meio do 4º quadro e terminar no início do 20º. Para encontrar seu início, é isso que este campo serve. Os pacotes também têm um cabeçalho, onde está especificado seu comprimento, portanto, ao encontrar o ponteiro para o primeiro cabeçalho, o processador de nível de enlace deve lê-lo, determinando assim, onde o pacote terminará.
Se o campo de controle de erros estiver presente, ele deve ser incluído em cada quadro de telemetria para um determinado canal físico durante 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.

Telecomandos

O quadro de telecomandos possui algumas diferenças significativas. Entre elas:

Outra estrutura de cabeçalhos
Comprimento dinâmico. Isso significa que o comprimento do quadro não é fixo, como no caso da telemetria, e pode variar dependendo dos pacotes transmitidos.
Mecanismo de garantia de entrega de pacotes. Ou seja, a RA deve confirmar a recepção correta dos quadros após recebê-los, ou solicitar o reenvio a partir do quadro que pode ter sido recebido com um erro irrecuperável.

Muitos campos já são familiares para nós a partir do cabeçalho do quadro de telemetria. Eles têm a mesma finalidade, portanto, aqui examinaremos apenas os novos campos.

Um bit da flag de contorno deve ser utilizado para controlar a verificação de quadros no receptor. O valor "0" dessa flag deve indicar que o quadro é um quadro do tipo A e sua verificação deve ser realizada de acordo com o FARM. O valor "1" dessa flag deve indicar ao receptor que o quadro é do tipo B e deve ignorar a verificação conforme o FARM.

Essa flag informa ao receptor se deve usar o mecanismo de confirmação de entrega de quadros, chamado FARM — Mecanismo de Aceitação e Relato de Quadros.

A flag de controle deve ser utilizada para entender se o campo de dados transporta um comando ou dados. Se a flag é igual a "0", o campo de dados deve conter dados. Se a flag é igual a "1", o campo de dados deve conter informações de controle para o FARM.
O FARM é uma máquina de estados cuja configuração pode ser ajustada.

RSVD. SPARE – bits reservados.

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

O campo de comprimento dos quadros deve conter um número em representação binária que é igual ao comprimento do quadro em octetos menos um.

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

um número inteiro de octetos de dados do usuário
cabeçalho de segmento e, em seguida, um número inteiro de octetos de dados do usuário

Se o cabeçalho estiver presente, o bloco de dados deve conter um Pacote, múltiplos Pacotes ou parte dele. Um bloco de dados sem cabeçalho não pode conter partes de Pacotes, mas pode conter blocos de dados em formato privado. Isso implica que o cabeçalho é necessário quando o bloco de dados transmitido não cabe em um único quadro. Um bloco de dados com cabeçalho é chamado de segmento.

O campo de flags de dois bits deve conter:

"01" — se a primeira parte dos dados estiver no bloco de dados
"00" — se a parte média dos dados estiver no bloco de dados
"10" — se a última parte dos dados estiver no bloco de dados
«11» — se não houver divisão e em um bloco de dados estiver totalmente contido um ou mais pacotes.

O campo de identificação MAP deve conter zeros se os canais MAP não forem utilizados.
Às vezes, 6 bits alocados para canais virtuais não são suficientes. E se for necessário multiplexar dados para um maior número de canais, mais 6 bits do cabeçalho do segmento são utilizados.

FARM

Vamos considerar mais detalhadamente o mecanismo de funcionamento do sistema de controle de entrega de quadros. Este sistema prevê apenas a operação com quadros de telecomandos devido à sua importância (os dados de telemetria podem ser solicitados novamente, enquanto o satélite deve ouvir a estação terrestre claramente e sempre obedecer aos seus comandos). Assim, suponha que decidimos reprogramar nosso satélite e enviamos a bordo um arquivo binário de 10 kilobytes. No nível de canal, o arquivo é dividido em 10 quadros (0, 1, …, 9), que são enviados sequencialmente. Quando a transmissão termina, o satélite deve confirmar a recepção correta do pacote ou informar em qual quadro ocorreu o erro. Essas informações são enviadas para o campo de controle operacional no próximo quadro de telemetria (ou o satélite pode iniciar a transmissão de um quadro vazio (idle frame) se não tiver nada a dizer). Com a telemetria recebida, ou confirmamos que está tudo bem ou iniciamos o reenvio da mensagem. Suponha que o satélite não ouviu o quadro nº 7. Isso significa que devemos enviar os quadros 7, 8, 9. Se nenhuma resposta for recebida, o pacote é enviado novamente por completo (e assim várias vezes, até entendermos que as tentativas foram em vão).

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

Como é possível deduzir a partir da imagem o propósito dos campos principais, e olhar para os outros é monótono, escondo a descrição detalhada sob um spoiler.

Descodificação dos campos CLCWTipo de palavra de controle (Control Word Type):
Para este tipo de palavra de controle deve conter 0

Versão da palavra de controle (CLCW Version Number):
Para este tipo de palavra de controle deve ser igual a «00» na representação binária.

Campo de status (Status Field):
A utilização deste campo é determinada para cada missão separadamente. Pode ser usado para melhorias locais por diferentes agências espaciais.

Identificador do canal virtual (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:
O sinalizador deve fornecer informações sobre a prontidão do nível físico do receptor. Se o nível físico do receptor não estiver pronto para receber quadros, então o campo deve conter '1', caso contrário, '0'.

Sinalizador de falha de sincronização:
O sinalizador pode indicar que o nível físico está operando em condições de sinal fraco e a quantidade de quadros rejeitados é muito alta. O uso deste campo é opcional; se utilizado, 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'.

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

Sinalizador de reenvio:
Este sinalizador deve conter '1' se um ou mais quadros do tipo A foram descartados ou se foram identificadas falhas, portanto, um reenvio é necessário. O sinalizador '0' indica que não houve quadros descartados ou falhas.

Valor da resposta:
Número do quadro que não foi aceito. Determinado pelo contador no cabeçalho do quadro de telemetria.

Camada de rede

Vamos abordar este nível também. Aqui há duas opções: usar o protocolo de pacote espacial ou encapsular qualquer outro protocolo em um pacote CCSDS.

Uma visão geral do protocolo de pacote espacial é um tópico para um artigo separado. Ele foi criado para que aplicativos possam trocar dados de forma contínua. Cada aplicativo tem seu próprio endereço e a funcionalidade básica para troca de dados com outros aplicativos. Também existem serviços que realizam a roteabilidade do tráfego, controle de entrega, etc.

Com a encapsulação, tudo é mais simples e claro. Os padrões possibilitam encapsular qualquer protocolo em pacotes CCSDS, adicionando um cabeçalho adicional.

Onde o cabeçalho tem significados diferentes dependendo do comprimento do protocolo encapsulado:

Aqui, o campo principal é o comprimento do comprimento. Ele pode variar de 0 a 4 bytes. Também é necessário indicar o tipo de protocolo encapsulado, usando a tabela daqui.

Ao encapsular IP, é utilizada uma outra camada para determinar o tipo de pacote.
É necessário adicionar mais um cabeçalho, com comprimento de um octeto:

Onde PID é mais um identificador de protocolo, retirado daqui

Conclusão

À primeira vista, pode parecer que os cabeçalhos da CCSDS são extremamente redundantes e alguns campos poderiam ser descartados. De fato, a eficiência do canal resultante (até o nível de rede) é de cerca de 40%. No entanto, assim que surge a necessidade de implementar esses padrões, torna-se claro que cada campo, cada cabeçalho tem uma missão importante, cuja ignorância leva a uma série de ambiguidades.

Se a comunidade Habr mostrar interesse por este assunto, ficarei feliz em publicar uma série de artigos dedicados à teoria e prática das comunicações espaciais. Obrigado pela atenção!