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

Satélite Meteoro M1
Fonte: vladtime.ru

Introdução

A operação da tecnologia espacial é impossível sem comunicações de rádio, e neste artigo tentarei explicar as principais ideias que formaram a base dos padrões desenvolvidos pelo Comitê Consultivo Internacional para Sistemas de Dados Espaciais (CCSDS. Esta abreviatura será usada abaixo) .

Esta postagem se concentrará principalmente na camada de enlace de dados, mas também serão introduzidos conceitos básicos para outras camadas. Este artigo não pretende de forma alguma ser uma descrição completa e completa dos padrões. Você pode visualizá-lo em On-line CCSDS. Porém, eles são muito difíceis de entender e passamos muito tempo tentando entendê-los, então aqui quero fornecer informações básicas, com as quais será muito mais fácil entender todo o resto. Então, vamos começar.

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 rádio proprietários (ou seu próprio padrão, com blackjack e novos recursos), aumentando assim a segurança do sistema?

Como mostra a prática, é mais lucrativo aderir aos padrões CCSDS pelos seguintes motivos:

O comitê responsável pela publicação dos padrões inclui representantes de todas as principais agências aeroespaciais do mundo, trazendo uma experiência inestimável adquirida ao longo de muitos anos de projeto e operação de diversas missões. Seria muito absurdo ignorar esta experiência e pisar novamente no seu ancinho.
Estas normas são apoiadas por equipamentos de estações terrestres já existentes no mercado.
Ao solucionar qualquer problema, você sempre pode buscar ajuda de colegas de outras agências para que possam conduzir uma sessão de comunicação com o dispositivo a partir de sua estação terrestre. Como você pode ver, os padrões são extremamente úteis, então vamos examinar seus pontos principais.

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 do enlace de dados a semelhança é limitada à divisão em telemetria (downlink - espaço - Terra) e telecomandos (uplink).

Vejamos alguns dos níveis com mais detalhes, começando pelo físico e subindo. Para maior clareza, consideraremos a arquitetura do lado receptor. O transmissor é sua imagem espelhada.

Camada física

Neste nível, o sinal de rádio modulado é convertido em um fluxo de bits. Os padrões aqui são principalmente de natureza consultiva, uma vez que neste nível é difícil abstrair da implementação específica do hardware. Aqui, o papel fundamental do CCSDS é definir as modulações aceitáveis (BPSK, QPSK, 8-QAM, etc.) e dar algumas recomendações sobre a implementação de mecanismos de sincronização de símbolos, compensação Doppler, etc.

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

Formalmente, é uma subcamada da camada de enlace de dados, mas é frequentemente separada em uma camada separada devido à sua importância nos padrões CCSDS. Esta camada converte o fluxo de bits nos chamados frames (telemetria ou telecomandos), dos quais falaremos mais tarde. Ao contrário da sincronização de símbolos na camada física, que permite obter o fluxo de bits correto, a sincronização de quadros é realizada aqui. Considere o caminho que os dados percorrem neste nível (de baixo para cima):

Porém, 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 através de um canal de rádio. Aqui não consideraremos procedimentos de decodificação, mas apenas obteremos as informações necessárias para compreender a lógica posterior do nível.

Os códigos podem ser em bloco ou contínuos. Os padrões não obrigam o uso de um tipo específico de codificação, mas ela deve estar presente como tal. Os códigos contínuos incluem códigos convolucionais. Eles são usados para codificar um fluxo de bits contínuo. Isto contrasta com os códigos de bloco, onde os dados são divididos em blocos de código e só podem ser decodificados em blocos completos. O bloco de código representa os dados transmitidos e as informações redundantes anexadas necessárias para verificar a exatidão dos dados recebidos e corrigir possíveis erros. Os códigos de bloco incluem os famosos códigos Reed-Solomon.

Se a codificação convolucional for usada, o fluxo de bits entra no decodificador desde o início. O resultado do seu trabalho (tudo isso, claro, acontece continuamente) são os blocos de dados CADU (unidade de dados de acesso ao canal). Esta estrutura é necessária para a sincronização de quadros. No final de cada CADU há um sincronizador anexado (ASM). São 4 bytes conhecidos antecipadamente, pelos quais o sincronizador encontra o início e o fim do CADU. É assim que a sincronização de quadros é alcançada.

A próxima etapa opcional da camada de sincronização e codificação está associada às peculiaridades da camada física. Isso é desrandomização. O fato é que para conseguir a sincronização de símbolos, é necessária a alternância frequente entre símbolos. Portanto, se transmitirmos, digamos, um quilobyte de dados constituído inteiramente por 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 é o produto final do nível de sincronização e codificação - um quadro.

Camada de link de dados

De um lado, o processador da camada de enlace recebe quadros e, do 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 - frames. Aqui veremos duas subseções: separadamente para telemetria (TM) e telecomandos (TC).

Telemetria

Simplificando, estes 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 comprimento fixo - quadros que contêm dados transmitidos e campos de serviço. Vamos dar uma olhada mais de perto na estrutura do quadro:

E vamos começar nossa consideração com o cabeçalho principal do quadro de telemetria. Além disso, permitir-me-ei simplesmente traduzir as normas em alguns lugares, dando alguns esclarecimentos ao longo do caminho.

O campo Master Channel ID deve conter o número da versão do quadro e o identificador do dispositivo.

Cada espaçonave, de acordo com os padrões CCSDS, deve ter seu próprio identificador único, pelo qual, possuindo um quadro, é possível determinar a qual dispositivo ela pertence. Formalmente, é necessário apresentar um pedido de registro do dispositivo, e seu nome, juntamente com seu identificador, serão publicados em fontes abertas. No entanto, os fabricantes russos muitas vezes ignoram este 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 consideraremos apenas o padrão mais conservador com versão “0”.

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

Muitas vezes há necessidade de multiplexar os dados transmitidos. Para tanto, existe um mecanismo de canais virtuais. 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 próprio canal virtual em um pacote separado, embora haja algum desvio dos padrões no estrutura de seus quadros.

O campo flag 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 fornecer feedback ao controlar a entrega dos quadros de telecomando. Falaremos sobre eles um pouco mais tarde.

Os contadores de quadros do canal principal e virtual são campos que são incrementados em um cada vez que um quadro é enviado. Servir como um indicador de que nem um único quadro foi perdido.

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

O campo sinalizador do Cabeçalho Secundário deve ser um indicador da presença ou ausência de um Cabeçalho Secundário no quadro de telemetria.

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

O campo First Header Pointer, quando o sinalizador de sincronização estiver definido como "1", deverá conter uma 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 do pacote no campo de dados do quadro de telemetria, então o campo ponteiro para o primeiro cabeçalho deverá ter o valor na representação binária "11111111111" (isso pode acontecer se um pacote longo estiver espalhado por mais de um quadro ).

Se o campo de dados contiver um pacote vazio (Idle Data), então o ponteiro para o primeiro cabeçalho deverá ter o valor em representação binária “11111111110”. Usando este campo, o receptor deve sincronizar o fluxo. Este campo garante que a sincronização seja restaurada mesmo se os quadros forem eliminados.

Ou seja, um pacote pode, digamos, começar no meio do 4º quadro e terminar no início do 20º. Este campo é usado para encontrar seu início. Os pacotes também possuem um cabeçalho que especifica seu comprimento; portanto, quando um ponteiro para o primeiro cabeçalho for encontrado, o processador da camada de enlace deverá lê-lo, determinando assim onde o pacote terminará.
Se um campo de controle de erro estiver presente, ele deverá estar contido em cada quadro de telemetria de um canal físico específico durante toda a missão.

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

Equipes de TV

O quadro de comando da TV possui diversas diferenças significativas. Entre eles:

Estrutura de título diferente
Comprimento dinâmico. Isso significa que o comprimento do quadro não é definido de forma rígida, como é feito na telemetria, mas pode variar dependendo dos pacotes transmitidos.
Mecanismo de garantia de entrega de pacotes. Ou seja, a espaçonave deve, após recebê-lo, confirmar a correção da recepção do quadro, ou solicitar o encaminhamento de um quadro que poderia ter sido recebido com erro incorrigível.

Muitos campos já nos são familiares no cabeçalho do quadro de telemetria. Eles têm a mesma finalidade, portanto aqui consideraremos apenas os novos campos.

Um bit do sinalizador de bypass deve ser usado para controlar a verificação do quadro no receptor. Um valor “0” para este sinalizador deve indicar que o quadro é um quadro Tipo A e deve ser verificado de acordo com FARM. Um valor “1” para este sinalizador deve indicar ao receptor que este quadro é um quadro Tipo B e deve ignorar a verificação FARM.

Este sinalizador informa ao receptor se deve usar um mecanismo de confirmação de entrega de quadros chamado FARM - Frame Acceptance and Reporting Mechanism.

O sinalizador de comando de controle deve ser usado para entender se o campo de dados transporta um comando ou dados. Se o sinalizador for "0", o campo de dados deverá conter dados. Se a flag for “1”, então o campo de dados deverá conter informações de controle para FARM.
FARM é uma máquina de estados finitos cujos parâmetros podem ser configurados.

RSVD. SPARE – bits reservados.

Parece que o CCSDS tem planos para eles no futuro e, para compatibilidade retroativa das versões do 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 seja igual ao comprimento do quadro em octetos menos um.

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

número inteiro de octetos de dados do usuário
cabeçalho do segmento seguido por um número inteiro de octetos de dados do usuário

Se um cabeçalho estiver presente, o bloco de dados deverá conter um pacote, um conjunto de pacotes ou parte de um pacote. Um bloco de dados sem cabeçalho não pode conter partes de pacotes, mas pode conter blocos de dados de formato privado. Conclui-se que um cabeçalho é necessário quando o bloco de dados transmitido não cabe em um quadro. Um bloco de dados que possui um cabeçalho é chamado de segmento

O campo de sinalizadores de dois bits deve conter:

"01" - se a primeira parte dos dados estiver no bloco de dados
“00” - se a parte central 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 couberem inteiramente no bloco de dados.

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

FAZENDA

Vejamos mais de perto o mecanismo de funcionamento do sistema de controle de entrega de pessoal. Este sistema prevê apenas o trabalho com frames de telecomandos devido à sua importância (a telemetria sempre pode ser solicitada novamente, devendo a espaçonave ouvir claramente a estação terrestre e obedecer sempre aos seus comandos). Então, suponha que decidamos fazer o reflash do nosso satélite e enviar para ele um arquivo binário de 10 kilobytes. No nível do link, o arquivo é dividido em 10 quadros (0, 1, ..., 9), que são enviados para cima um por um. Quando a transmissão for concluída, o satélite deve confirmar a exatidão da recepção do pacote, ou informar em qual quadro ocorreu o erro. Esta informação é enviada para o campo de controle operacional no quadro de telemetria mais próximo (ou a espaçonave pode iniciar a transmissão de um quadro ocioso se não tiver nada a dizer). Com base na telemetria recebida, ou nos certificamos de que está tudo bem, ou procedemos ao reenvio da mensagem. Vamos supor que o satélite não ouviu o quadro #7. Isso significa que lhe enviamos os frames 7, 8, 9. Se não houver resposta, o pacote inteiro é enviado novamente (e assim por diante várias vezes até percebermos que as tentativas foram em vão).

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

Como você pode facilmente adivinhar pela imagem a finalidade dos campos principais, e os outros são enfadonhos de se olhar, estou escondendo a descrição detalhada sob um spoiler

Explicação dos campos CLCWTipo de palavra de controle:
Para este tipo, a palavra de controle deve conter 0

Versão da palavra de controle (número da versão CLCW):
Para este tipo a palavra de controle deve ser igual a “00” na representação do bit.

Campo de status:
O uso deste campo é determinado para cada missão separadamente. Pode ser usado para melhorias locais por diversas 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 a camada física do receptor não estiver pronta para receber quadros, então 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 com um nível de sinal fraco e que o número de quadros rejeitados é muito alto. O uso deste campo é opcional; se utilizado, deverá conter “0” se a sincronização estiver disponível e “1” se não estiver.

Sinalizador de bloqueio:
Este bit deve conter o status do bloqueio FARM para cada canal virtual. Um valor “1” neste campo deve indicar que o FARM está desabilitado e os frames serão descartados para cada camada virtual, caso contrário “0”.

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

Bandeira de avanço:
Este sinalizador deverá conter um “1” se um ou mais quadros do tipo A tiverem sido descartados ou lacunas forem encontradas, sendo necessário o reenvio. O sinalizador "0" indica que não houve perda de quadros ou saltos.

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

camada de rede

Vamos tocar um pouco neste nível. Existem duas opções aqui: usar o protocolo de pacote espacial ou encapsular qualquer outro protocolo no pacote CCSDS.

Uma visão geral do protocolo de pacotes espaciais é um tópico para um artigo separado. Ele foi projetado para permitir que os chamados aplicativos troquem dados perfeitamente. Cada aplicativo possui seu próprio endereço e funcionalidades básicas para troca de dados com outros aplicativos. Existem também serviços que direcionam o tráfego, controlam a entrega, etc.

Com o encapsulamento tudo fica mais simples e claro. Os padrões tornam possível encapsular qualquer protocolo em pacotes CCSDS adicionando um cabeçalho adicional.

Onde o cabeçalho tem significados diferentes dependendo do comprimento do protocolo que está sendo encapsulado:

Aqui o campo principal é o comprimento do comprimento. Pode variar de 0 a 4 bytes. Também neste cabeçalho você deve indicar o tipo de protocolo encapsulado utilizando a tabela por isso.

O encapsulamento IP usa outro complemento para determinar o tipo de pacote.
Você precisa adicionar mais um cabeçalho, com um octeto de comprimento:

Onde PID é outro identificador de protocolo obtido por isso

Conclusão

À primeira vista, pode parecer que os cabeçalhos CCSDS são extremamente redundantes e alguns campos poderiam ser descartados. Na verdade, a eficiência do canal resultante (até ao nível da rede) é de cerca de 40%. No entanto, assim que surge a necessidade de implementar estas normas, torna-se claro que cada domínio, cada rubrica tem a sua missão importante, ignorando o que conduz a uma série de ambiguidades.

Se a Habrasociety demonstrar interesse neste tópico, terei prazer em publicar toda uma série de artigos dedicados à teoria e prática das comunicações espaciais. Obrigado pela sua atenção!