Serviço de rede para o Sistema de Controle e Rastreio de Satélites da Estação Multimissão de Natal (EMMN) Moisés Cirilo de B. Souto1, Helio Sousa Peres2, Manoel Jozeane M. de Carvalho3 1

2

3
Instituto Nacional de Pesquisas Espaciais, Centro Regional do Nordeste. Rua Carlos Serrano, 2073, Lagoa Nova, 59076-740 - Natal, RN – Brasil moises@crn.inpe.br,heliosp@crn.inpe.br,manoel@crn.inpe.br Abstract. This paper describes a network service to communicate between Graphical Supervisory Interface (IGS) and the Control and Supervision Software (SC) on antenna of Natal Multi-mission Station (EMMN). In this work, we change the previously monolithic architecture of the system for a new architecture in layers, based on the client/server paradigm. This new architecture is composed by a new structure where the client program (used by the operator, IGS), communicates using the Ethernet network and TCP / IP protocol with the server program. It has been developed with free software, distributed in Local Network over Server/client paradigm, using TCP/IP protocol. The server program then communicates directly to the hardware control module of the antenna using an AD / DA converter. Resumo. Este trabalho descreve um serviço de rede para comunicação entre a Interface Gráfica Supervisória (IGS) e o Software de controle (SC) da antena da Estação Multimissão de Natal (EMMN). Neste trabalho, muda-se a arquitetura monolítica existente anteriormente, para uma arquitetura em camadas, baseada no paradigma cliente/servidor. Esta arquitetura é composta de estrutura onde o programa cliente (utilizado pelo operador, que é a IGS), comunica-se via rede Ethernet, através do protocolo TCP/IP, ao programa servidor. O programa servidor comunica-se então diretamente ao hardware do módulo de controle da antena através de um conversor AD/DA, executando o comando desejado. 1. Introdução Este trabalho tem por objetivo o desenvolvimento de um software de comunicação entre uma interface gráfica supervisória e o sistema de rastreio de satélites da Estação Multimissão de Natal (EMMN), localizada no Centro Regional Nordeste (CRN) do Instituto Nacional de Pesquisas Espaciais (INPE). A Estação Multi-Missão de Natal (EMMN) é um projeto de pesquisa e desenvolvimento tecnológico, com origem no reaproveitamento de uma estação francesa destinada aos Satélites de Aplicação Científica (SACI), desenvolvida pelo INPE. A EMMN está sendo projetada para agregar as funcionalidades do centro de controle e missão, com base em computadores interconectados através de rede Ethernet. A EMMN é composta por vários subsistemas, dentre eles, o sistema de controle de sua antena para o rastreio de satélites (Subsistema de Controle e Rastreio – SCR).

Este trabalho objetiva desenvolver um sistema capaz de conectar de forma ponto-a-ponto o controle de operação da estação, simplificando e tornando robusta a interface do usuário à EMMN. Através deste sistema o servidor conectado através de rede Ethernet recebe as requisições feitas pelo cliente em rede. Validadas as requisições estas são encaminhadas ao software controlador da antena que as executa. 2. Subsistema de Controle e Rastreio (SCR) O SCR, Subsistema de Controle e Rastreio é responsável por fazer a automação da operação da antena da EMMN. Os módulos envolvidos e sua interação com a estação podem ser vistos na figura 1. O SCR é formado por quatro módulos, que embora sejam apresentados a seguir, foram desenvolvidos por [Queiroz e Carvalho 2006] e não serão discutidos em detalhes neste trabalho: o módulo posicionador (motores, engrenagens, sensores de posição, etc.), o módulo de potência (inversores, chave contactora, etc), o módulo de comando (relés, fontes, fusíveis, etc.) e o módulo de controle (computador e placa conversora AD/DA). Neste último encontra-se o Software de Controle (SC).
Figura 1. Estrutura de Hardware do Subsistema de Controle e Rastreio (SCR) da EMMN 2.1. Módulo Posicionador O módulo posicionador da antena permite que a mesma se movimente nos dois eixos, azimute e elevação, de forma independente [Queiroz e Carvalho 2006] . 2.2. Módulo de Potência O modulo de potência é responsável pelo acionamento e controle de velocidade dos motores que recebem sinais proveniente do módulo de controle [Queiroz e Carvalho 2006] . 2.3. Módulo de Comando O módulo de comando suporta todos os circuitos que controlam a alimentação dos equipamentos que atuam sobre os motores, conhecidos como inversores [Queiroz e Carvalho 2006] . Logo após as devidas configurações no módulo de controle (calibração da placa AD/DA, configuração e inicialização do sistema), a chave principal do módulo de

comando deve ser acionada, com isso, as fontes de alimentação são ligadas, e o software de rastreio poderá ser utilizado. 2.4. Módulo de Controle O software que realiza o controle da estação EMMN (SC), pertence a este módulo que é composto ainda pelo servidor em rede ethernet, escopo deste trabalho, responsável por receber e encaminhar a requisições válidas ao Software de Controle (SC) (o mecanismo de validação das requisições será explicado adiante) e pela placa conversora AD/DA [Queiroz e Carvalho 2006] . Os clientes operam o SCR e todos os seus módulos a partir do Software de Rastreio de Satélites (SRS). 3. Software de Rastreio de Satélites (SRS) A principal função do Software de Rastreio de Satélites (SRS) é servir de interface entre as requisições do usuário na execução de um dado evento (posicionar a antena, por exemplo) e repassá-las para o software de controle (SC) que é responsável por processar as requisições recebidas controlando o hardware. O Software de Rastreio de Satélites (SRS) é composto de Interface Gráfica Supervisória (IGS), módulo cliente/servidor para comunicação em rede Ethernet e Sistema de Controle (SC). O Software de Rastreio de Satélites (SRS) deve apresentar ao usuário a situação atual da estação, bem como um sinal de sucesso ou fracasso ao término de cada evento solicitado. O status da EMMN é monitorado pelo software de controle (SC) e em seguida repassado para apresentação ao operador, que tem a visualização a partir da interface gráfica supervisória(IGS). A figura 2, mostra o fluxo de comunicação e troca de informações no sistema.

Figura 2. Fluxo de comunicação O retorno de informação do Software Controle (SC) para a Interface Gráfica Supervisória (IGS) são feitos através de comunicação em rede Ethernet, usando o protocolo TCP/IP. O programa responsável pela filtragem e validação de requisições é o Servidor TCP/IP que será chamado de STP. Existem três etapas até que a requisição que o usuário fez no SRS seja entregue e executada pelo SC. Quando o usuário executa a ação no SRS (computador cliente), através da IGS (interface gráfica supervisória), um requisição é criada, a IGS usando o cliente TCP/IP tenta conectar-se através da porta TCP 4950 ao STP, programa em

execução no Servidor do SC, que serve pra filtrar as requisições, como foi explicado anteriormente. Caso a conexão seja estabelecida a requisição é enviada a partir do SRS ao STP. Quando recebida no STP este submete a mensagem ao analisador léxico para verificar se a requisição recebida é válida e se deve ser repassado ao SC para execução. Sendo a requisição validada pelo analisador léxico contido no STP, a requisição pode então ser tratada pelo SC. Esta separação de tratamento em etapas torna o processo de adaptação e recompilação do sistema mais rápida e simples. facilitando a distribuição deste sistema para outras estações do INPE. 3.1. A Interface (IGS) do Software de Rastreio de Satélites (SRS) A Interface Gráfica Supervisória do SRS (IGS) tem como objetivo promover uma camada de abstração entre o SC e os usuários da EMMN, permitindo a realização de tarefas de operação, manutenção, rastreio e posicionamento da antena, sem atuar diretamente no Hardware (HW) da estação. Toda a operação era feita a partir de uma interface em modo texto, usando a biblioteca ncurses. O operador necessariamente deve possuir familiaridade com o GNU/Linux, já que toda a aplicação de supervisão é executada sobre um terminal interpretador de comandos. A EMMN agregará diversas funcionalidades e servirá principalmente como centro de controle para as diversas missões que serão realizadas para o Sistema Brasileiro de Coleta de Dados. Muitos operadores, com diferentes graus de conhecimento sobre o GNU/Linux, devem atuar sobre a mesma, portanto, é requisito que o sistema seja de fácil utilização e de rápido aprendizado. Definiu-se então o modelo de comunicação baseado em rede (o escopo deste trabalho) com interface gráfica. Para tanto foi desenvolvida uma interface gráfica atendendo a tais requisitos, em [Peres e Carvalho 2007]. A interface gráfica foi criada utilizando a biblioteca de classes, sob licença GPL (General Public License), para C++ e conjunto de ferramentas para construção de aplicações gráficas [Blanchette e Summerfield 2004] QT 3, como framework para a parte gráfica da aplicação. O modelo de comunicação em rede foi adicionado a partir deste trabalho, tendo sido utilizado BSD Sockets na criação dos sockets clientes e o GNU/Linux é o sistema operacional usado para desenvolver e executar a aplicação; 3.2. Programa Servidor TCP/IP O principal componente do STP é um analisador léxico que tem como função determinar a estrutura léxica de um código fonte a partir dos tokens (marcas) produzidas pela varredura e construir, explícita ou implicitamente, uma árvore sintática, que represente essa estrtuura [Louden, Kenneth C. 2004]. Neste trabalho o analisador léxico analisará não código fonte de um programa, mas sim requisições recebidas em formato de string ASCII enviadas através da rede utilizando sockets TCP/IP. Para validar o comando o analisador léxico, localizado no STP, verifica nas expressões regulares que descrevem o protocolo desenvolvido para comunicação entre IGS e SC, se a requisição feita atende os requisitos previstos. Pode-se fazer analogia as regras gramaticais de uma gramática livre de contexto, estrutura a partir do qual o analisador fará a construção sintática supracitada. Uma mostra de alguns comandos deste protocolo podem ser vistos na tabela 1.

Tabela 1. Tabela com algumas das requisições válidas do protocolo as quais o STP deve permitir a execução. Comando Parâmetro Descrição Valor de Retorno ao socket Retorno ao IGS MV <valueAZ>:<valueEL> Move a antena manualmente até a posição escolhida. Se um eixo não deve ser movido, usar ”.” no lugar do valor. Ex. MV .:120 0: OK 20: Erro 255: Erro $MSGBOX:<type>,'message' RC Cancela o rastreio em execução. 0: OK 20: Erro 255: Erro $MSGBOX:<type>,'message' Evitando que por exemplo alguém através da rede requisite que o conteúdo do disco rígido do servidor seja deletado, Isso porque o analisador léxico contido no STP irá descartar a requisição. A comunicação com o hardware é feita através do SC, que utilizando-se do comedi, oferece drivers para uma variedade de dispositivos de aquisição de dados e da biblioteca open source comedlib que oferece facilidade para manipulação do dispositivo interfaceado [Scleef, Hess Mori e Abbott 2009]. Essas bibliotecas tem como função principal permitir a comunicação com o hardware através da placa conversora AD/DA, PCI 6025E da National Instruments. 4. Resultados Para que a comunicação através de rede do sistema de controle e rastreio da antena da EMMN seja possível sem ocasionar falhas, o atraso inferido pela comunicação em rede acrescido do tempo de execução do posicionamento da antena não pode ser maior que 1 segundo. Já que este é o tempo de amostragem e processamento quando um rastreio está em execução. Esta é a métrica de tempo mais importante a ser garantida, uma vez que seria a única que poderia interferir (caso esse sistema fosse de tempo real) diretamente no correto funcionamento do sistema de controle, embora existam outras restrições não relevantes a este trabalho, tais como: atrasos induzidos por falhas nos inversores, desgaste nas engrenagens do módulo posicionador etc. Em medições realizadas na execução de uma instrução de escrita no eixo de azimute e elevação, afim de posicionar a antena durante um rastreio, contatou-se que a referida instrução contabiliza, em média, 16ns, quando executada de dentro do SSC, usando a interface em ncurses e conectado diretamente ao hardware, através do conversor AD/DA. Inicialmente, este sistema funcionará em rede ponto-a-ponto do tipo Ethernet, com conectores RJ-45, cabo par trançado CAT-5e, a conexão ponto-a-ponto de 100mbps, portanto, o tempo de atraso induzido pela rede será praticamente irrelevante, em torno de 1ms. Nos testes, a execução do socket com a filtragem do analisador léxico rendeu um tempo de execução, em media, de 800 ns. A passagem de parâmetros em um vetor através da execução (ARGC e ARGV) do STP para o SSC incrementou em 100ns a execução.

Portanto, mesmo somados os tempos de comunicação entre IGS e STP, com a filtragem por parte do analisador léxico (800ns), a passagem via parâmetro do comando recebido pelo STP e que será repassado ao SSC por ARGC e ARGV (100ns) somados ao tempo de execução pelo SSC (16ns) sequer chegam perto do patamar crítico de 1 segundo. Ademais, mesmo que o atraso da rede somado com execução superasse o patamar critico de 1 segundo, não haveria perdas para o sistema, já que a antena não é controlada manualmente durante um rastreio. Um arquivo contendo as efemérides é previamente enviando através da IGS para o SC. Assim, quando este arquivo é transferido para o SSC o sistema não depende mais da rede. O único prejuízo aconteceria se de fato o operador fosse apontar manualmente a antena, o que é ineficiente, pois o tempo de digitar os ângulos de posicionamento já faria o satélite passar do ponto e um efeito cascata. 5. Conclusões O objetivo deste trabalho foi realizar o desenvolvimento de um serviço de rede para a EMMN. Realizadas simulações e avaliações de métricas, pode-se afirmar que a comunicação em rede do Sistema de Controle e Rastreio de satélites da EMMN é possível. Além disso, que os impactos negativos como atrasos, são mínimos e que certamente estes são superados rapidamente pela quantidade de benefícios introduzidos pela proposta de arquitetura defendida neste trabalho Uma das metas do projeto é que todo o desenvolvimento seja de baixo custo e utilize exclusivamente software livre. Essa meta é justificada pela necessidade de não haver dependência de fabricantes com padrões proprietários, seja de software ou hardware. Dessa forma garante-se uma estação facilmente intercambiável, de fácil manutenção e que não ficará obsoleta por um padrão de software ou hardware ser descontinuado pelo fabricante. Ademais, o código escrito utilizando-se de software livre e integrado a hardware genérico, facilita o processo de portabilidade de arquitetura, permitindo a qualquer momento substituir um componente de hardware ou software sem a necessidade de reescrever toda a aplicação, sendo feito apenas ajustes. Referências QUEIROZ, Kurios Iuri Pinheiro de Melo e CARVALHO, Manoel Jozeane Mafra de (2006). Descrição Funcional do Subsistema de Controle e Rastreio da Estação Multimissão de Natal (EMMN). PERES, Hélio Sousa e CARVALHO, Manoel Jozeane Mafra de. (2007). Desenvolvimento de aplicação para Linux utilizando Kdevelop e Qt. Blanchette, Jasmin e Summerfield, Mark (2004) C++ GUI Programming with Qt 3, Prentice Hall ,1a edição. Scleef, David, Hess Mori, Frank e Abbott, Ian (2009) “Comedi: linux control and measurement device interface”, http://www.comedi.org/ Acesso em: Abril de 2010. Alves, Maicon Melo (2008) Sockets Linux, Brasport ,1a edição. Louden, Kenneth C. (2004) Compiladores: Princípios e práticas, Pioneira Thomson Learning, 1a edição.