PROTOCOLO TERRA-VANT

O protocolo terra-VANT é a sequência lógica implementada pelo módulo Comms Relay tendo em vista a garantia de entrega e a fragmentação de mensagens de maior dimensão. Este protocolo tem como intervenientes os seguintes componentes:

 Componente emissor/recetor – É o componente que inicia o processo de envio de dados para a extremidade oposta ou a quem se destina a informação recebida

 Comms Relay – É o componente que abstrai todo o modo de comunicação garantindo as propriedades já referidas anteriormente;

 Autopilot Driver – É o componente que está ligado à ETC2 (em terra) e que tem a capacidade de encapsular os dados para a API de comunicação fornecida pelo AP;

 Autopilot Comms – É o componente que está ligado ao AP (a bordo) e permite receber e traduzir dados raw para os componentes de bordo;

A interação entre estes componentes é através do Bus de ROS, com a subscrição/publicação de tópicos conforme se apresenta na Figura 24:

Figura 24: Tópicos envolvidos na comunicação entre extremidades

Na Tabela 2 são apresentados os parâmetros utilizados na configuração do módulo pois é necessário definir o tamanho máximo de cada fragmento (chunk) em bytes, quanto tempo deverá o comms relay esperar por um sinal de acknolowdge antes de reenviar o fragmento que falhou e quantas vezes este processo deverá ser repetido antes de dar a entrega da mensagem como falhada.

Tabela 2: Parâmetros do Protocolo terra-VANT

Parâmetros do protocolo

Nome Tipo Valor Default Descrição

CHUNK_MAX_SIZE uint16 255 Tamanho máximo que cada fragmento de mensagem deve ter (como o AP tem uma limitação por pacote de 255 bytes limita- se o tamanho ajustando a este valor)

ACK_TIMEOUT uint16 2 segundos Valor ao fim do qual se reenvia a mensagem por falta de ACK MAX_TX_RETRIES uint8 3 Número de vezes que deverá ser tentado o reenvio de uma

mensagem sem resposta antes de assumir falha no envio.

No envio das mensagens para a extremidade oposta os dados são encapsulados usando uma mensagem denominada ReliableMessage cuja estrutura é apresentada na Tabela 3. Esta mensagem é recebida e enviada pelo módulo Comms Relay que existe em ambas as extremidades.

Tabela 3: Estrutura da mensagem ReliableMessage

Nome Tipo Unidades Descrição

SOT uint16 N/A Conjunto de caracteres para sincronização da mensagem (0xABCD)

messageType uint8 N/A Tipo da mensagem: - (0) RequiresAck - (1) Ack

- (2) NoAck

messageId uint16 N/A Identificador único atribuído pelo CommsRelay a cada mensagem

sequence uint16 N/A Número de sequência no total da mensagem – No caso de mensagens fragmentadas, no caso de mensagens simples o valor é sempre 1

length uint32 Nº de bytes Tamanho, em bytes, da totalidade da mensagem. No caso de se tratar de uma mensagem fragmentada cada fragmento terá o tamanho máximo de CHUNK_MAX_SIZE exceto, eventualmente o último fragmento que poderá ter um valor inferior.

data uint8[] N/A Dados a enviar, delimitados em tamanho por CHUNK_MAX_SIZE

crc uint16 N/A Checksum da mensagem inclui todos os campos da mensagem (exceto CRC) pode ser usado o CRC16-IBM

4.1.1.4.1.1. Filas e estruturas de controlo

Para o funcionamento do módulo comms relay são necessárias três tipos de filas:

 Fila de receção de mensagens – Nesta fila guardam-se as mensagens recebidas, que aguardam assemblagem dos fragmentos, para poderem ser entregues ao componente destino (por exemplo, uma imagem que vai ser recebida no solo é enviada em fragmentos, como tal têm de ser assembladas)

 Fila de envio de mensagens – Nesta fila guardam-se as mensagens que aguardam resposta da outra extremidade e as mensagens que não requerem confirmação de receção, mas foram fragmentadas e requerem confirmação de envio.

 Fila de despacho – Nesta fila são postas as mensagens prontas para envio sendo a taxa de despacho tão rápida quanto possível. Pode ser mantida alguma estatística em relação ao estado da ligação ou taxas de repetições para ajustar o ritmo de envio e/ou os timeouts (pode-se usar a mensagem CommsParameters para ajustar os valores). Esta fila será implementada seguindo uma estratégia de prioridades baseada no timestamp de envio do fragmento. Esta prioridade permite evitar que um fragmento inicial seja descartado porque foi inserido no fim da fila para reenvio e nunca chega a ser enviado antes do limite de tempo.

Existe ainda uma estrutura de dados para guardar os meta-dados de gestão do envio das mensagens que fará parte da fila de envio (Tabela 4). Esta estrutura deverá permitir controlar timeouts do protocolo:

Tabela 4: Estrutura de controlo de cada fragmento (Chunk)

Nome Tipo Unidades Descrição

sentTimestamp uint64 Unix timestamp Estampilha temporal do momento de inserção na fila de despacho

ackRetries uint8 N/A Número de tentativas para reenvio

Chunk ReliableMessage N/A Fragmento preparado para envio com formato ReliableMessage

4.1.1.4.1.2. Envio de mensagens

Nesta secção é detalhado o processo de fragmentação e envio de uma mensagem com destino a terra do ponto de vista do comms relay. Devido ao facto de que se trata de um processo assíncrono, o envio de mensagens por parte do comms relay é constituído por três passos importantes:

Envio –

Este passo, descrito na Figura 25, inicia-se de cada vez que uma mensagem for

enviada com destino à outra extremidade (e.g. SEP envia uma mensagem com destino a terra). Assim sendo começa por atribuir um número identificador a cada mensagem recebida e verifica se esta necessita de garantia de entrega e quantos fragmentos (chunks) ocupa, tendo em conta que o tamanho máximo por fragmento é de 255 bytes. Os chunks são então colocados na fila de envio e na fila de despacho, sendo que na fila de despacho serão enviados imediatamente e removidos da fila, um após o outro, já na fila de envio permanecerão lá até que seja recebida a confirmação da sua receção em terra ou o seu envio seja dado como falhado.

Loop –

O loop, como o próprio nome indica, consite numa thread a correr infinitamente com uma frequência de 10 Hz, cuja função consiste em ir buscar o primeiro elemento da fila de despacho e publicar o mesmo no tópico “to_autopilot”, com destino ao módulo de comunicação com o AP (Autopilot Comms a bordo e Autopilot Driver em terra). No caso de o fragmento não necessitar de garantia de entrega é imediatamente marcado como “entregue” para que possa ser removido da fila de envio.

Figura 26: Diagrama de envio de mensagem (Comms Relay Loop)

Watchdog de envio – Este watchdog monitoriza a fila de envio com uma frequência

de 0.5Hz de forma a verificar quais as mensagens que podem ser removidos da fila de envio. Assim sendo analisa primeiro a mensagem e verifica se esta necessita de garantia de entrega e caso não necessite remove a mensagem da fila e passa para a mensagem seguinte caso a fila não esteja vazia. No caso de a mensagem necessitar de garantia de entrega terão de ser analisados todos os fragmentos da mesma de forma a confirmar que todos foram entregues. No caso de o acknowledge do fragmento ainda não ter sido recebido há que levar em conta o seguinte paradigma, quando um fragmento é enviado é inicializado um contador para detetar o timeout (ACK_TIMEOUT) da resposta. Quando este timeout é ultrapassado o fragmento que falhou é reintroduzido no início da fila de despacho de forma a garantir que será reenviado imediatamente. Ao fim de um certo número de tentativas de reenvio (MAX_TX_RETRIES) sem receber uma resposta a um fragmento a mensagem à qual pertence deverá ser dada como

falhada e, como tal, removida da fila de envio. Note-se que o timeout entre cada tentativa vai crescendo numa relação de dobro face ao anterior o que quer dizer que o tempo total máximo que um fragmento pode permanecer na fila de envio, antes da mensagem ser dada como falhada, é dado por:

∑ (2𝑛_{∗ 𝐴𝐶𝐾_𝑇𝐼𝑀𝐸𝑂𝑈𝑇)} (𝑀𝐴𝑋_𝑇𝑋_𝑅𝐸𝑇𝑅𝐼𝐸𝑆 − 1)

𝑛=0

Equação 1: Tempo máximo de espera, sem resposta, para envio de mensagem

O diagrama apresentado na Figura 27 é então uma representação gráfica do acima descrito.

4.1.1.4.1.3. Receção de mensagens

Na secção anterior foi apresentado o processo de fragmentação e envio de mensagens para a extremidade oposta, por parte do comms relay, pelo que nesta secção será descrito o processo complementar, ou seja, a receção e assemblagem das mensagens recebidas (Figura 28). O processo de receção de mensagens por parte do comms relay, tal como o processo de envio, é também baseado numa fila de receção. As mensagens recebidas são colocadas nesta fila e é iniciada a análise da mensagem recebida. Após verificar que o parsing da mensagem é corretamente efetuado, é importante dividir as mensagens entre acknowledges e mensagens de dados, sendo que no caso de ser um acknowledge o fragmento respetivo é marcado com essa informação, na fila de envio e, caso o número de fragmentos acknowledged seja igual ao número total de fragmentos essa mensagem é removida dessa fila. No caso de ser uma mensagem de dados é necessário enviar o acknowledge correspondente (caso esta necessite) e, no caso de ser o último fragmento da mensagem, assemblar a mensagem em formato SeagullPayload e publicar a mesma no tópico “to_comms_relay”.

Também à semelhança do processo de envio, é necessário remover as mensagens já assembladas, e publicadas pelo comms relay, da fila de receção. Este passo é representado na Figura 29.

Figura 29: Diagrama de monitorização da fila de receção

No documento Sistema de monitorização para veículos aéreos não tripulados (páginas 91-98)