UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FERRAMENTA DE SUPORTE A RECEPÇÃO DE DADOS TELEMÉTRICOS Área de Sistemas de Informação por Bruno Leonardo Michels Elieser Ademir de Jesus, M. Sc. Orientador Itajaí (SC), junho de 2011

2 UNIVERSIDADE DO VALE DO ITAJAÍ CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR CURSO DE CIÊNCIA DA COMPUTAÇÃO FERRAMENTA DE SUPORTE A RECEPÇÃO DE DADOS TELEMÉTRICOS Área de Sistemas de Informação por Bruno Leonardo Michels Relatório apresentado à Banca Examinadora do Trabalho de Conclusão do Curso de Ciência da Computação para análise e aprovação. Orientador: Elieser Ademir de Jesus, M. Sc. Itajaí (SC), junho de 2011

3 SUMÁRIO LISTA DE ABREVIATURAS... iv LISTA DE FIGURAS... v RESUMO... vii ABSTRACT... viii 1. INTRODUÇÃO PROBLEMATIZAÇÃO Formulação do Problema Solução Proposta OBJETIVOS Objetivo Geral Objetivos Específicos METODOLOGIA ESTRUTURA DO TRABALHO FUNDAMENTAÇÃO TEÓRICA TELEMETRIA Componentes da telemetria Comunicação do medidor com o modem Comunicação do transmissor com o receptor EXTENSIBLE MARKUP LANGUAGE (XML) Document Type Definition (DTD) Extensible Markup Language Schema TRABALHOS SIMILARES Utilizando telemetria em telescópio e controle de instrumentação Open Geospatial Consortium Comparações e conclusões DESENVOLVIMENTO ARQUIVO DE ESPECIFICAÇÃO GERADOR DE ARQUIVO DE ESPECIFICAÇÃO Requisitos Regras de negócio Casos de uso Diagrama de classes Descrição do software ii

4 3.3. SOFTWARE DE SIMULAÇÃO DE DADOS Requisitos Casos de uso Diagrama de classes Descrição do software SOFTWARES DE PARSING Requisitos Diagrama de classes Descrição dos softwares SOFTWARE DE PROCESSAMENTO E GERENCIAMENTO Requisitos Diagrama de classes Diagrama de sequência Descrição do software TESTES CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS GLOSSÁRIO ANEXOS iii

5 LISTA DE ABREVIATURAS ASCII CLP DNP3 DTD GPRS GSM IDE IEC IML J2M LRC MSSQL OGC RS TCC TCP XML American Standard Code for Information Interchange Controle Lógico Programável Distributed Network Protocol Document Type Definition General Packet Radio Service Global Service for Mobile Comunications Integrated Development Environment International Electrotechnical Commission Instrument Markup Language Java Platform, Micro Edition Longitudinal Redundancy Check Microsoft SQL Open Geospatial Consortium Recommended Standard Trabalho de Conclusão de Curso Transmission Control Protocol Extensible Markup Language iv

6 LISTA DE FIGURAS Figura 1. Processo da solução proposta Figura 2. Centralização do controle em uma indústria Figura 3. Protocolo Modbus Figura 4. Quadro de Mensagem ASCII Figura 5. Modem com porta serial RS Figura 6. Comparativo de custo entre GSM/GPRS e Dial-up Figura 7. Conexão GSM/GPRS TCP/IP Figura 8. Estrutura do XML Figura 9. Exemplo de um arquivo XML Figura 10. Exemplo de um arquivo DTD Figura 11. Referencia a um arquivo DTD padrão para desenvolvimento de websites Figura 12. Exemplo de um arquivo XML Schema Figura 13. Exemplo de um arquivo IML Figura 14. Aplicação da NASA utilizando IML para controle de telescópio Figura 15. Arquivo XML utilizando o SensorML Figura 16. Schema SensorML Figura 17. Schema para os tipos de dados Figura 18. Exemplo de arquivo de especificação Figura 19. Criação de um novo arquivo de especificação Figura 20. Edição de um arquivo de especificação Figura 21. Diagrama de classes do gerador de arquivos de especificação Figura 22. Tela principal do software de geração de arquivos de especificação Figura 23. Tela de gerenciamento de dados Figura 24. Caso de uso do simulador Figura 25. Diagrama de classes do software de simulação Figura 26. Tela do software de simulação do envio de dados Figura 27. Mensagem de erro no simulador Figura 28. Exemplo de parser Figura 29. Diagrama de classes do software de parsing Figura 30. Camada de dados Figura 31. Diagrama de classes do software de processamento de dados Figura 32. Diagrama de entidade relacionamento Figura 33. Diagrama de sequência do software de processamento I Figura 34. Diagrama de sequência do software de processamento II Figura 35. Analisador de energia Figura 36. Dados de corrente obtidos pelo software de processamento Figura 37. Gráfico dos valores de corrente no software ANAWIN Figura 38. Tabela de dados climáticos do mês de novembro de Figura 39. Tabela de dados climáticos do mês de novembro de v

7 vi

8 RESUMO MICHELS, Bruno Leonardo. Ferramenta de suporte a recepção de dados Telemétricos. Itajaí, f. Trabalho de Conclusão de Curso (Graduação em Ciência da Computação) Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, A telemetria é o processo de efetuar uma medição à distância. Existem diversas aplicações para a telemetria e por consequência existem diversos tipos de dados que podem ser obtidos, como nível da água, pressão, temperatura, tensão e outros. Trabalhar com múltiplos tipos de dados implica na construção de um software para efetuar o reconhecimento e armazenamento dos dados para cada instrumento de medição distinto. O presente trabalho apresenta um software genérico, capaz de identificar diversos tipos de dados enviados por distintos instrumentos de medição. Para cada instrumento há um arquivo de especificação escrito no formato XML (Extensible Markup Language Linguagem de Marcação Extensível) que indica como processar os dados recebidos pelo instrumento. Isto torna possível realizar medições com diferentes instrumentos de medição utilizando apenas um software, que é capaz de identificar e validar os dados recebidos e posteriormente armazená-los em uma base de dados. Os testes do software que recebe os dados telemétricos foram realizados através de simulações. Um software foi desenvolvido com o objetivo de simular dados enviados por instrumentos de medição. Para enviar dados este software lê um arquivo de texto com o nome da porta da conexão estabelecida e envia o seu conteúdo. Foram simulados dois tipos de dados de instrumentos de medição: dados de tensão, corrente e climáticos, cujos detalhes do formato dos dados são apresentados nos Anexos I, II e III deste trabalho. Um outro software foi desenvolvido para facilitar a criação de arquivos de especificação dos instrumentos de medição, possibilitando a criação e edição de arquivos. Palavras-chave: Telemetria. Instrumento de Medição. XML. vii

9 ABSTRACT Telemetry is the process of performing a distance measurement. There are several applications for telemetry and consequently there are several types of data that can be obtained, such as water level, pressure, temperature, voltage and others. The work with multiple data types involves building a software to perform the recognition and data storage for each distinct measurement instrument. This paper presents a generic software that can identify different types of data sent by different measuring instruments. For each instrument there is a specification file written in XML (Extensible Markup Language) that indicates how to process the data sent by the instrument. This makes it possible to perform measurements with different measuring devices using only one software, which is able to identify and validate the received data and then store them in a database. Tests of the software that receives the telemetric data were done through simulations. A software was developed to simulate the data sent by the measuring instruments. To send data this software reads a text file with the port number of the established connection and sends its contents. In this paper it was simulated two types of data of measuring instruments: tension, current and weather, which data format details are presented in Annexes I, II and III of this paper. Another software was developed to facilitate creation of specification files of measuring instruments, enabling the creation and editing. Keywords: Telemetry. Measurement Equipment. XML. viii

10 1. INTRODUÇÃO Os instrumentos de medição sempre foram uma necessidade da ciência. Os dados coletados a partir de uma medição são importantes para a área onde se aplicam. Na ciência a área conhecida como o estudo de medidas é chamada de Metrologia, que é a base do desenvolvimento, uso dos instrumentos de medição e do processo de medição (ABRAN e SELLAMI, 2002). Instrumentos de medição são utilizados em diversas situações, como por exemplo, em indústrias, hospitais, rios, laboratórios, carros de corrida, aviões, foguetes, satélites entre outros. Na maioria dessas situações, para efetuar a coleta de dados, são utilizados instrumentos de medição digitais. Com alguns tipos de instrumentos de medição é possível armazenar os dados adquiridos na memória do instrumento para que posteriormente se possa fazer uma coleta dos dados adquiridos. Entretanto, desta forma os dados ficam armazenados apenas no local onde o instrumento está e para que se possa fazer a leitura é necessário o deslocamento de uma pessoa até o equipamento. Este processo de aquisição de dados foi melhorado com a telemetria. A telemetria é a tecnologia que permite transmitir dados obtidos em um local para um centro de controle, onde acontece o processamento, armazenamento e análise dos dados. O uso dessa técnica se aplica em operações como abastecimento de água, medição de consumo de energia e outras. A telemetria traz relevantes contribuições, tanto na economia quanto na melhoria da qualidade de atendimento ao cidadão (NETO e CABRAL, 2003). Algumas medições teriam um custo extremamente elevado ou seriam inviáveis sem a telemetria, como por exemplo, efetuar uma medição em um satélite tendo que deslocar uma pessoa para o espaço a fim de coletar os dados obtidos. Outro caso inviável seria efetuar medições em um míssil em pleno voo, seria impossível sem o uso da telemetria. Obter dados a distância é essencial para prevenir grandes falhas e aumentar a eficiência. Através da telemetria é possível obter dados que estão sendo coletados remotamente em tempo real, possibilitando o controle em diversos pontos de medição simultaneamente. Com a utilização da telemetria diminui a necessidade de contratação de funcionários para efetuar a leitura dos dados. Com isto, é possível reduzir o custo e aumentar a qualidade de gestão das informações, como por exemplo, a 2

11 possibilidade de detectar problemas de instalação ou algum defeito nos equipamentos envolvidos no processo de medição (PREFEITURA MUNICIPAL DE PORTO ALEGRE, 2010). Desta forma pode se evitar períodos prolongados sem a aquisição de dados e com isto reduzir prejuízos por falhas físicas, uma vez que estas falhas são rastreáveis e podem ser mais rapidamente tratadas (PREFEITURA MUNICIPAL DE PORTO ALEGRE, 2010). Existem diversos instrumentos de medição e cada um tem um propósito diferente. Um termômetro e um voltímetro, por exemplo, são instrumentos de medição, porém os dados obtidos por cada um destes instrumentos possuem significados diferentes. O termômetro irá obter dados de temperatura enquanto o voltímetro irá obter dados de tensão. Para que se possa automatizar o processo de leitura a distância dos dados de um instrumento de medição é necessário um software que identifique o que os dados recebidos representam. Como existem diversos instrumentos de medição e diversas aplicações para estes, há a necessidade de desenvolver diversos softwares, um em cada situação, onde seja necessário reconhecer os valores recebidos e os converter para um formato específico. Por exemplo, o valor 05AF vem do instrumento de medição em forma hexadecimal, o software converte este valor para 1455 e armazena em uma base de dados no campo temperatura (o seu campo específico). Construir um novo software para gerenciar dados de cada instrumento de medição é um processo custoso. Neste trabalho foi desenvolvido um conjunto de softwares para gerenciar dados telemétricos. Desta forma diversos tipos de dados podem ser processados e armazenados sem a necessidade da criação de um software específico para cada instrumento de medição PROBLEMATIZAÇÃO Formulação do Problema O problema abordado neste trabalho é a falta de um software capaz de processar dados vindos de diferentes tipos de instrumentos de medição e armazená-los. 3

12 Em aplicações que utilizam telemetria os dados que são enviados do ponto de medição ao centro de controle geralmente usam o quadro de dados do Modbus, onde os dados não são convertidos para dados legíveis por seres humanos, são códigos que precisam ser convertidos para informações, por exemplo, 0F para 15ºC, e são enviados de forma compactada para otimizar a transmissão. Desta forma, os dados que chegam ao centro de controle não são facilmente interpretáveis por humanos, e para que se possa interpretá-los é necessário que sejam apresentados de forma mais amigável do que a forma que chegam originalmente (MODBUS ORGANIZATION, 1996). Geralmente a recepção dos dados no centro de controle é feita através de um software específico que identifica os dados de apenas um instrumento de medição e os converte para dados específicos que podem ser apresentados de forma amigável posteriormente. O desenvolvimento de um software para cada instrumento de medição gera um custos com mão de obra e tempo Solução Proposta Neste TCC (Trabalho de Conclusão de Curso) foi desenvolvido um software para a recepção, processamento e armazenamento de dados telemétricos. O software é executado em um centro de controle (servidor) para que possa ser utilizado na identificação de diferentes tipos de dados obtidos por diferentes instrumentos de medição. Este software obtém dados através de conexões com o protocolo TCP/IP para garantir a conexão de ponta a ponta. Para simular o envio dos dados foi desenvolvido um software de simulação, o qual é responsável por enviar dados obtidos por diferentes instrumentos de medição. Ao receber os dados, um software instalado no servidor identifica o número da porta pela qual os dados estão sendo recebidos e a partir desta informação localiza na base de dados um arquivo de especificação de um instrumento de medição. Este arquivo de especificação é um documento no formato XML, que segue uma estrutura definida em um XML Schema (explicado com maiores detalhes no Capítulo 2.2). O arquivo de especificação contém a representação textual de algumas das características de um instrumento de medição, tais como número de série, descrição, seguido de uma estrutura que liga os 4

13 dados que serão recebidos para seus campos e tipos correspondentes. Desta forma o software ao receber os dados pode identificá-los e armazená-los adequadamente em uma base de dados. Através destes arquivos de especificação se elimina a necessidade da criação de um novo software para reconhecer dados de um instrumento de medição específico, pois ao invés de softwares serão necessários apenas novos arquivos de especificação. Para a criação de um arquivo de especificação será necessário criar marcações para efetuar um mapeamento dos dados que serão transmitidos pelo instrumento de medição. Neste trabalho foi desenvolvido um software para auxiliar a criação de arquivos de especificação. Sendo assim o presente trabalho envolveu a criação dos seguintes softwares: um para o reconhecimento dos dados recebidos; outro para simular o envio de dados ao servidor; um para auxiliar a criação de arquivos de especificação; e outros dois para efetuar a adequação dos dados recebidos a um determinado formato (parsers). O escopo do trabalho envolveu o processo de aquisição dos dados por uma conexão TCP (Transmission Control Protocol Protocolo de Controle de Transmissão), onde os dados são simulados e enviados para o servidor através de um software auxiliar. Para compreender o fluxo da solução proposta foi elaborado um diagrama de atividades conforme a Figura 1, que demonstra o que ocorre quando os dados enviados por um sistema chegam ao servidor. Primeiramente os dados são recebidos através de uma porta TCP. Através do número da porta o software faz uma busca na base de dados (onde ficará o mapeamento das portas com arquivos de especificação correspondente) e abre o arquivo de especificação que corresponde a uma determinada porta. Se nenhum arquivo for encontrado o sistema irá terminar o processo informando que não há um arquivo de especificação para os dados recebidos. 5

14 Caso o arquivo seja encontrado os dados recebidos serão convertidos de sua forma compacta para os seus respectivos formatos. Ao obter os dados convertidos para seus tipos e formatos corretos o software irá salvá-los em uma base de dados onde poderão ser resgatados posteriormente. Após o armazenamento dos dados o software responde uma mensagem de OK encerrando a conexão. Figura 1. Processo da solução proposta. Neste TCC foram simulados diferentes tipos de dados de instrumentos de medição. Para cada instrumento simulado existe um arquivo de especificação correspondente. 6

15 1.2. OBJETIVOS Objetivo Geral O objetivo geral deste trabalho é construir um software que permita receber, identificar e processar dados telemétricos enviados por diferentes tipos de instrumentos de medição Objetivos Específicos 1. Pesquisar e documentar conceitos relacionados à telemetria; 2. Especificar e modelar os softwares utilizando técnicas de engenharia de software; 3. Definir a estrutura do arquivo de especificação dos instrumentos de medição (XML Schema); 4. Criar arquivos de especificações para os instrumentos de medição que serão simulados; 5. Programar o software de recepção, identificação e processamento dos dados; 6. Programar o software de construção de arquivos de especificação; 7. Programar o software que simulará o envio de informações para a aplicação descrita no item 5; e 8. Testar o funcionamento da aplicação descrita no item 5 utilizando a aplicação do item 7 para gerar dados METODOLOGIA A primeira etapa deste trabalho iniciou com a pesquisa dos conceitos relacionados à telemetria. Nesta pesquisa utilizaram-se livros, artigos e monografias que tratam dos temas relacionados à telemetria. Também foi consultado um profissional que lida com aplicações de telemetria em projetos para empresas como Petrobras, AES Sul e outras; Na segunda etapa deste trabalho pesquisou-se os componentes necessários para um sistema de telemetria, assim como o funcionamento da transmissão de dados até o receptor, trabalhos similares para identificar os benefícios da solução proposta e os conceitos necessários para o desenvolvimento do software proposto. Para estas pesquisas utilizaram-se artigos e documentações. Pela indisponibilidade de instrumentos de medição reais optou-se por realizar simulações do envio dos dados. 7

16 A terceira etapa deste trabalho iniciou com a especificação e modelagem dos softwares propostos, seus requisitos, regras de negocio, modelagem e diagramas. Na quarta etapa deste trabalho desenvolveu-se os softwares. Foram desenvolvidos alguns softwares auxiliares como o gerador de arquivos de especificação e um software para simular dados e enviá-los através de uma conexão TCP. Foi desenvolvido um software para receber dados, tratá-los e armazená-los, o qual utiliza um parser que traduz os dados para um formato humanamente legível. Estes softwares foram desenvolvidos em C#.NET utilizando o paradigma de orientação a objeto. Na quinta etapa deste trabalho foram feitos testes com os conceitos de caixa branca e caixa preta. Também se desenvolveu testes unitários para garantir o funcionamento dos métodos e regras de negócio ESTRUTURA DO TRABALHO No primeiro capítulo deste trabalho apresenta-se uma introdução explicando o conceito de telemetria, para que serve e como é usada e uma breve introdução ao software proposto. A seguir apresenta-se o problema existente e como a ferramenta proposta irá contribuir para chegar a uma solução. Ainda no primeiro capítulo estão definidos os objetivos e a metodologia utilizada para alcançálos. No segundo capítulo apresenta-se a história, definições, conceitos da telemetria, assim como protocolos de comunicação e a estrutura de um sistema que utiliza telemetria. Também se apresenta trabalhos similares que irão servir como base para o desenvolvimento deste Trabalho de Conclusão de Curso (TCC). Assim como os conceitos relacionados para o entendimento do desenvolvimento do software, como a linguagem XML e seus conceitos. O terceiro capítulo trata das especificações dos softwares desenvolvidos com requisitos funcionais e não-funcionais, casos de uso, diagrama de estados, diagrama de classes, diagrama de sequência e descrição do software. Ao final serão apresentadas as conclusões. 8

17 2. FUNDAMENTAÇÃO TEÓRICA A fundamentação teórica deste trabalho consiste nas definições, metodologias, aplicações, características, padrões e outros assuntos relacionados à telemetria. Também são apresentados conceitos sobre XML que são relevantes para o desenvolvimento do TCC TELEMETRIA Mattos (2004, p.6) explica a definição da palavra telemetria e como esta era usada inicialmente. A palavra telemetria é a união de duas palavras gregas. Tele significa longe e meter significa medir. Por isso telemetria (TM) significa realizar medições à distância, ou em local remoto. A telemetria começou devido a necessidade de realizar medições em locais inacessíveis, como a temperatura dentro de um forno, e evoluiu em uma ciência complexa capaz de realizar medições dentro de um míssil guiado, ou em qualquer local remoto. Segundo a Petrobras (2003), a telemetria é a técnica de transportar dados obtidos em medições a distância em função de um instrumento transmissor, ou seja, é possível, por exemplo, obter dados de dentro de um tanque fechado e visualizá-los sem precisar abrir o tanque. Em 1940 o controle e monitoramento nas indústrias começaram a ser feitos com ajuda da telemetria para que se mantivesse uma leitura precisa dos dados. A telemetria permitindo a centralização da leitura e controle de dados fez com que o número de operários fosse consideravelmente reduzido (CARDEN, et al., 2002, p ). Conforme a Figura 2 é possível notar que há um computador central que gerencia um processo industrial. O centro de controle recebe os dados de medição como também envia comandos para os instrumentos de medição. Podendo assim desligar equipamentos se apresentarem algum problema. A telemetria permite esse monitoramento em tempo real com um controle rápido e eficiente. 9

18 Figura 2. Centralização do controle em uma indústria Fonte: Adaptado de Carden, Jedlicka, et al. (2002) Para que seja possível obter dados a distância são necessários equipamentos que efetuem uma transmissão de dados para um receptor. Sendo assim um sistema de telemetria é composto por sensores (instrumentos de medição), instrumento transmissor e um receptor Componentes da telemetria Um instrumento de medição é um dos dispositivos que compõe um sistema de telemetria, este é responsável por armazenar dados que são obtidos em algum local. Alguns instrumentos de medição que podem ser utilizados em sistemas de telemetria são (NIVETEC, 1991): Nivopress D: pode ser utilizado em medição de nível em reservatórios, controle de válvulas e pressão em tubulações; Transmissor de nível ultrassônico: pode monitorar continuamente o nível de tanques e reservatórios, monitoramento em nível de rios, lagos, barragens, monitoramento de líquidos e sólidos, entre outros; 10

19 Medidor analítico (condutividade): pode ser utilizado em sistemas como o de tratamento de água, torres de resfriamento, caldeira e sistemas de dessalinização; e Thermocont Sensor (temperatura): medição de temperatura de líquidos em tanques ou tubulações, de sólidos e líquidos. Estes são exemplos de instrumentos de medição. Para se adquirir os dados remotamente estes precisam ser transmitidos, e para isso existe o dispositivo para efetuar a transmissão de dados, que é outro componente de um sistema de telemetria, este equipamento é necessário para enviar os dados obtidos previamente pelo instrumento de medição para um servidor onde os dados poderão ser lidos. Este equipamento pode ser um modem, por exemplo, que quando conectado com o instrumento de medição pode extrair os dados e posteriormente enviá-los para um servidor. Alguns modos de transmissão de dados para um servidor são, por exemplo, fibra óptica, satélite, celular, radio, entre outros. Além dos instrumentos de medição e dispositivo para o envio, outro componente para completar um sistema de telemetria é um receptor, por exemplo, um servidor. Um servidor é encarregado de receber os dados obtidos independentemente do local onde foram lidos e armazená-los, desta forma os dados são transferidos do ponto de medição para um local remoto, obtendo assim dados à distância. Para entender o fluxo dos dados, as seções a seguir explicam o processo de transmissão de dados entre os dispositivos Comunicação do medidor com o modem Um aparelho de medição pode se conectar com um modem e enviar dados, estes dados seguem um padrão que geralmente é o Modbus. Segundo a Modbus Organization (1996) o protocolo de comunicação Modbus tem sido utilizado pelas indústrias desde 1979 quando foi criado pela empresa Modicon, atualmente conhecida como Schneider Electric, que serve para a comunicação com controladores lógicos programáveis (CLPs) utilizando uma conexão cliente-servidor. Este protocolo se tornou "de facto" (padrão conhecido e amplamente utilizado, porém não oficial) nas indústrias. 11

20 A Figura 3 demonstra a estrutura do Modbus, onde a camada de aplicação é ligada com a camada de rede através do Modbus TCP/IP, e é desta forma que os instrumentos de medição podem enviar dados pela rede. Figura 3. Protocolo Modbus Fonte: MODBUS Organization (1996) O protocolo Modbus permite a comunicação entre vários dispositivos conectados na mesma rede. Por exemplo, um sistema que mede a temperatura e umidade poderia enviar os resultados para um computador. Sendo esta uma comunicação cliente-servidor é possível que haja diversos dispositivos enviando os dados simultaneamente para um mesmo servidor (computador). Segundo a Modbus Organization (1996), o quadro da mensagem no formato ASCII (American Standard Code for Information Interchange - Código Padrão Americano para Intercâmbio de Informações) está apresentado na Figura 4 e as definições dos campos são: Start: é o byte de inicio do quadro do Modbus, é sempre o caractere fixo : ; Address: se refere ao endereço do equipamento receptor; Function: identifica o tipo da mensagem enviada ou recebida, pode ser para execução de um comando ou envio de dados entre outras funções; 12

21 Data: contem os dados adquiridos pelo instrumento de medição; LRC (Longitudinal Redundancy Check - Verificação de Redundância Longitudinal): são os bytes de verificação de dados, com estes bytes é possível determinar a integridade da mensagem; e End: campo composto pelos bytes CRLF (nova linha) que determina o final da mensagem. Figura 4. Quadro de Mensagem ASCII Fonte: MODBUS Organization (1996) De acordo com a Modbus Organization (1996), os controladores que utilizam o protocolo Modbus se comunicam através de uma interface serial compatível com o RS-232C (Recommended Standard - Padrão Recomendado) que define todas as características da conexão. Os controladores se comunicam através de uma topologia de Master-Slave, onde o dispositivo (master) inicia as transações (chamadas queries) e os outros dispositivos (slaves) respondem ao sinal de acordo com o campo "Function". Nesta arquitetura o equipamento mestre é o instrumento de medição que irá enviar os dados através da porta serial no padrão RS-232 para o modem, o equipamento escravo. A Figura 5 demonstra o modem com a porta padrão RS-232 que irá receber os dados. Segundo Mobile Data Solutions (2004) este modem em específico possui uma placa que permite a programação em J2ME (Java Platform, Micro Edition) e possui uma memória flash, com estas tecnologias é possível gerenciar os dados obtidos do instrumento de medição e enviá-los para um servidor. Caso não seja possível completar o envio os dados ainda estarão salvos podendo reenviar a qualquer momento. 13

22 Figura 5. Modem com porta serial RS-232 Fonte: Adaptado de Ozeki (2010) Segundo a Modbus Organization (1996) TCP/IP é o padrão de transporte mais comum da internet e atualmente é composto por um grupo de camada de protocolos, fornecendo um ambiente confiável para transporte de dados entre máquinas. Por isso, em 1999 o Modbus passou a incorporar as especificações TCP/IP. A partir de então, o Modbus passou a fornecer suporte para transferência de dados utilizando TCP/IP para qualquer dispositivo que suporte conexões neste protocolo. Segundo Makhija (2003) existem outros protocolos que são utilizados, tais como: DNP3 (Distributed Network Protocol - Protocolo de Rede Distribuída): é utilizado em sistemas de automação, mais comumente utilizado em companhias elétricas e de água, o uso em demais locais é incomum, mas tecnicamente não é impossível. O DNP foi criado pela Westronic, Inc. em Em 1993, surgiu o DNP 3.0; e IEC (International Electrotechnical Commission - Comissão Eletrotécnica Internacional): foi desenvolvido para servir como protocolo padrão para telecontrol, teleprotection e telecommunications. Embora existam diversos protocolos, os citados anteriormente são os mais comumente encontrados em sistemas de telemetria e telecontrol. O protocolo Modbus será utilizado para o 14

23 desenvolvimento deste TCC e será a base para desenvolvimento e testes, por ser "de facto" o padrão nas indústrias Comunicação do transmissor com o receptor Em um sistema de telemetria são comumente utilizados modems TCP/IP que se conectam com o servidor através de uma conexão GSM/GPRS, pois o custo é muito menor, conforme é possível ver na Figura 6. Figura 6. Comparativo de custo entre GSM/GPRS e Dial-up. Fonte: ROZAS (2004) Além disto, segundo Rozas (2004) uma linha GSM (Global Service for Mobile Comunications Serviço Global para Comunicações Móveis) / GPRS (General Packet Radio Service Serviço de Rádio de Pacote Geral) é mais segura, pois é uma conexão fechada. Já em conexões Dial-up basta saber o número do telefone para ter acesso. 15

24 Segundo Rozas (2004) e conforme ilustrado na Figura 7, para efetuar a transmissão de dados os dispositivos ao serem ligados procuram um sinal de celular e se autenticam estabelecendo assim um canal de comunicação com o servidor. Figura 7. Conexão GSM/GPRS TCP/IP Fonte: ROZAS (2004) Com o canal de conexão estabelecido o modem pode enviar os dados obtidos para o servidor. O software do servidor ao receber os dados enviados identifica o número da porta pelo qual os dados 16

25 foram recebidos. Desta forma é possível identificar o tipo de instrumento de medição que esta enviando os dados. Pelo número da porta o software irá pesquisar na base de dados o mapeamento entre porta e arquivo de especificação. Ao obter o arquivo de especificação correspondente à porta onde os dados foram recebidos o software identifica o que cada parte do quadro de dados recebido representa. Independentemente do modo que a conexão é estabelecida, é importante que o dispositivo que irá transmitir os dados se conecte a porta relacionada ao instrumento de medição em que está ligado EXTENSIBLE MARKUP LANGUAGE (XML) XML (Extensible Markup Language), como o nome sugere é uma linguagem de marcação que pode ser estendida. A linguagem é flexível e permite a criação de elementos (HABING, 2004). Segundo Dobratz, Henneberger e Schulz (2003) a linguagem XML é definida como uma linguagem de marcação para descrever dados. A linguagem XML é totalmente extensível para dados, permite a separação entre propriedades e dados, sendo assim possível definir um conjunto de regras para a criação de um arquivo neste formato. A Figura 8 mostra a estrutura de um arquivo XML. Nesta figura "a", "b" e "c" são elementos e estão distribuídos de forma hierárquica como em uma árvore de dados. Figura 8. Estrutura do XML Fonte: Dobratz, Henneberger e Schulz (2003) A Figura 9 contém um exemplo completo de arquivo XML. O arquivo inicia com um elemento que identifica a versão do XML e qual codificação está utilizando. O primeiro elemento, root, é o 17

26 elemento raiz, dentro deste elemento pode-se definir quaisquer outros elementos. O XML ilustrado demonstra uma lista de elementos. Figura 9. Exemplo de um arquivo XML Por ser extensível, um arquivo XML pode estar inválido para a aplicação. Existem arquivos para efetuar a validação do XML, que são os arquivos XML Schema e DTD (Document Type Definition Definição de Tipo de Documento). Estes arquivos servem para que se possa manter uma consistência entre o formato do arquivo e o formato esperado pelo software Document Type Definition (DTD) Segundo Dobratz, Henneberger e Schulz (2003) os DTDs são arquivos que definem regras ou modelos para que sejam produzidos arquivos com arquiteturas similares. Um arquivo DTD descreve um modelo de classe. Na Figura 10 está representado um exemplo de arquivo DTD. São definidos diversos elementos e os atributos que serão válidos no arquivo XML, caso este siga as regras definidas. Este arquivo define que deverá haver o elemento "html" o qual deve conter os elementos head e body. A seguir é 18

27 definido que o elemento head deve existir contendo os elementos link, script, meta e title. O elemento link representado determina que o elemento deverá estar vazio, mas pode conter um ou mais atributos definidos. Figura 10. Exemplo de um arquivo DTD Com um arquivo DTD é possível determinar regras para compor um arquivo em um padrão. Este tipo de arquivo é geralmente utilizado para a composição de um website, conforme ilustrado na Figura 11. Figura 11. Referencia a um arquivo DTD padrão para desenvolvimento de websites Extensible Markup Language Schema Segundo Dobratz, Henneberger e Schulz (2003) XML Schema é uma versão diferente do DTD para definir regras. A vantagem do XML Schema sobre o DTD é a possibilidade de definir regras mais complexas, como número de ocorrências, números naturais, valores de atributos, entre outras. O XML 19

28 Schema força o XML a seguir totalmente suas regras, podendo especificar o nome de atributos, ordem em que aparecem, onde podem aparecer, etc. A Figura 12 apresenta um exemplo de um arquivo XML Schema, o qual define que o arquivo XML deverá conter um elemento Chapter com uma sequência de elementos Sentence dentro. O elemento Sentence deverá aparecer pelo menos uma vez na sequência, definido em minoccurs=1. O elemento Chapter obrigatoriamente deverá conter um atributo chamado title, definido na tag xs:atribute. Figura 12. Exemplo de um arquivo XML Schema 2.3. TRABALHOS SIMILARES Na busca por trabalhos similares dois trabalhos foram encontrados. Um sistema da NASA que utiliza uma linguagem de marcação especifica para reconhecer o instrumento de medição e salvar os dados, e uma organização que tem por objetivo definir padrões para serviços geográficos. 20

29 Utilizando telemetria em telescópio e controle de instrumentação Segundo Ames, et al (2000), a NASA desenvolveu o IML (Instrument Markup Language Linguagem de Marcação de Instrumentos). O IML é baseado no padrão W3C e utiliza o arquivo XML seguindo padrões definidos em DTDs (Document Type Definition Definição de Tipo de Documento). A Figura 13 demonstra um exemplo de arquivo IML. Neste arquivo são definidos diversos instrumentos de medição com seu nome, tipo de dados, porta e outros dados necessários para o software. Figura 13. Exemplo de um arquivo IML Fonte: Ames, et al. (2000) A Figura 14 apresenta um sistema de telemetria utilizado para um telescópio da NASA. Todos os dados recebidos passam pelo Instrument Proxy. O Command Formatter transforma os comandos genéricos definidos no IML para instruções que são enviados para o instrumento. O Telemetry Parser converte os dados recebidos em Data Objects que podem ser armazenados e visualizados posteriormente. 21

30 Figura 14. Aplicação da NASA utilizando IML para controle de telescópio Fonte: Ames, et al (2000) Open Geospatial Consortium A OGC (Open Geospatial Consortium) é uma organização que tem como objetivo levar o desenvolvimento de serviços geográficos para um padrão. Esta definiu padrões que estão sob o Sensor Web Enablement (SWE), que segundo o Open Geospatial Consortium (2010) são definidos como: Observations & Measurements; Sensor Model Language; Transducer Model Language; Sensor Observations Service; Sensor Planning Service; Sensor Alert Service; e Web Notification Services. Segundo o Open Geospatial Consortium (2004) um sensor é feito para medir uma propriedade particular em um determinado espaço, esta propriedade é imediatamente utilizada ou armazenada. 22

31 O Sensor Model Language é um XML Schema que define um conjunto de regras, este possibilita descrever qualquer nível de medição que será exposto, como por exemplo, nível de tensão ou temperaturas. O SensorML descreve quais as propriedades medidas por um sensor, e a Figura 15 demonstra um arquivo XML utilizando o XML Schema "SensorML", onde são definidos os dicionários para cada tipo. Figura 15. Arquivo XML utilizando o SensorML Fonte: OPEN GEOSPATIAL CONSORTIUM (2007) 23

32 Segundo Botts (2008), para identificar dados é utilizado um arquivo XML com Schema do SensorML apresentado na Figura 16. O Schema define diversos tipos de dados, como por exemplo, tipos observáveis (temperatura, luminosidade, terremotos, ângulos e etc), capacidades, características e interfaces (altura, largura, material de composição, resolução, bitsize, baud rate e etc), sensores e termos, identificadores, tipos de hierarquia e eventos. Figura 16. Schema SensorML Fonte: Open Geospatial Consortium (2007) 24

33 Comparações e conclusões Os trabalhos similares apresentam características muito semelhantes ao software de reconhecimento de dados proposto. Como por exemplo, no arquivo IML da NASA é especificado o instrumento bem como seu tipo e número da porta por onde os dados relativos irão ser recebidos. E na OGC são referenciados dicionários para a tradução dos dados. Entretanto o foco dos trabalhos similares não é um modo genérico de identificar dados recebidos de quaisquer instrumentos de medição. Não é possível criar dados arbitrários e um arquivo de especificação para estes dados utilizando os meios apresentados anteriormente. Pretende-se desenvolver um software para que seja possível reconhecer dados em diferentes codificações e com diferentes métodos de verificações de integridade dos dados. Sendo assim os trabalhos similares não servem para o desenvolvimento de arquivos de especificação, mas serviram como uma base para o desenvolvimento de um formato de arquivo de especificação. 25

34 3. DESENVOLVIMENTO Nesta seção são descritos os diagramas de caso de uso, diagramas de estado, diagramas de atividades, diagramas de classes, requisitos e regras de negócio para cada um dos softwares desenvolvidos neste trabalho. Os diagramas apresentados foram gerados a partir do Visual Studio Para o desenvolvimento dos softwares propostos foi utilizada a linguagem C# sobre a plataforma.net sendo que um dos parsers foi desenvolvido em C++ para ilustrar o funcionamento do sistema com softwares desenvolvidos em diferentes linguagens de programação. O desenvolvimento em C# foi feito com a IDE (Integrated Development Environment Ambiente de Desenvolvimento Integrado) da Microsoft, Visual Studio 2010 e o desenvolvimento em C++ foi feito com a IDE Code::Blocks ARQUIVO DE ESPECIFICAÇÃO O arquivo de especificação deve seguir um formato padrão para que o software possa carregá-lo e utilizá-lo. Para garantir que o arquivo esteja no formato correto foi desenvolvido um XML Schema que os arquivos de especificação devem seguir. Os arquivos de especificação que não seguirem estas regras não poderão ser carregados pelo software de processamento. A Figura 17 demonstra o Schema desenvolvido e que é utilizado pelos arquivos de especificação. O arquivo Schema especifica que o arquivo XML deverá possuir uma serie de elementos os quais são: ManagedCode : determina se o arquivo de especificação deve agir com as informações de parsing para.net ou outro; Series : o nome completo de serie do instrumento de medição, para fins informativos; Description : informações gerais sobre o instrumento de medição, para fins informativos; Parser : encapsula os dados correspondentes ao método de parsing de dados utilizado globalmente; 26

35 Assembly : representa o nome da DLL desenvolvida em.net para que possa ser carregado no processo de transformação de dados; Type : representa o nome completo da classe do parser; Method : representa o nome do método que deve ser chamado para efetuar o parsing; DataEncryption : define o tipo de codificação de dados, por exemplo, hex caso os dados estiverem em hexadecimal; Validation : encapsula os dados relativos à verificação de dados, composto pelos dados de parsing e posição do dado de validação; StartPosition : representa a posição dos dados utilizados para validar os dados recebidos; DataLength : é o tamanho dos dados relativos a verificação dos dados; Values : encapsula uma serie de elementos Value que contem informações para realizar o parsing dos dados e retorná-los no formato humanamente legível; e Value : é composto pelos campos de parsing, pela posição e tamanho do dado. Também contem o nome do dado correspondente. 27

36 Figura 17. Schema para os tipos de dados A Figura 18 representa uma parte de um arquivo de especificação. Este arquivo contém as informações necessárias para fazer o parsing dos dados que serão recebidos pelo software que irá processar os dados. No inicio do arquivo é especificado o tipo de código do parser. O tipo de código Managed significa que o parser foi feito em.net, desta forma os elementos Assembly, Type e Method 28

37 são tradados de uma forma especifica, caso contrario o parser deve retornar o valor no standard output do programa. Os elementos Series e Description são utilizados apenas para descrever o arquivo. O bloco Parser define os dados do parser. O elemento Assembly que define Parser.dll é o arquivo compilado em.net que contem classes e métodos que fazem o parsing dos dados. O elemento Type que define Parser.Generic é o nome completo da classe que contem o método que será utilizado. O elemento Method que contem Parse define o nome do método que será chamado para efetuar o parsing dos dados. O elemento DataEncryption define o tipo de conversão que o parser deve fazer. Os demais elementos do arquivo de especificação seguem o mesmo padrão do bloco do parser, porém estes contem dois campos a adicionais, o StartPosition e DataLength. Estes campos definem a posição e tamanho de cada um dos elementos. Desta forma é possível mapear os dados e definir como estes serão convertidos. Figura 18. Exemplo de arquivo de especificação 29

38 3.2. GERADOR DE ARQUIVO DE ESPECIFICAÇÃO Esta seção descreve o software desenvolvido para auxiliar a criação de arquivos de especificação. A partir destes arquivos o software que processa os dados pode reconhecer os dados capturados por um instrumento de medição e processá-los adequadamente Requisitos Nesta seção são descritos os requisitos do software para geração de arquivos de especificação. Os requisitos são importantes para definir os elementos necessários para o arquivo de especificação mantendo dados válidos. Requisitos funcionais são os requisitos que definem a função de software ou seu componente. Estes requisitos são funções especificas que definem o objetivo do software, como cálculos, detalhes técnicos, manipulação de dados, processamento de dados ou outra função especifica. Os requisitos funcionais definem o que o software deve fazer (SOMMERVILLE, 2007); Requisitos não funcionais são requisitos que definem critérios a serem utilizados no desenvolvimento do sistema. A implementação destes requisitos ajudam a definir a arquitetura do software. Os requisitos não funcionais definem como o software deve ser (SOMMERVILLE, 2007); Os requisitos funcionais são: O sistema deve permitir alterações de dados descritivos; O sistema deve permitir alterações dos dados de validação; Deve exibir mensagens informativas em caso de erro; O sistema deve permitir alterações dos dados de parsing genérico; e O sistema deve permitir alterar as informações relativas ao reconhecimento de dados telemétricos. 30

39 Os requisitos não funcionais são: O software deve ser desenvolvido em C#.NET; A base de dados deverá ser MSSQL Express (Microsoft SQL Express); O arquivo de especificação deverá seguir as regras definidas no Schema; e A entrada dos dados deve ser validada Regras de negócio Regras de negócio são definições que caracterizam o negócio. Estas regras tendem a definir a estrutura do negócio e para isto devem ser claras e especificas (BUSINESS RULES GROUP, 2001). A soma do tamanho dos dados deve ser compatível com o limite de dados suportados pelo Modbus Casos de uso Segundo Booch, Rumbaugh e Jacobson (2000) casos de uso são especificações do sistema ou parte dele. É um conjunto de ações sequenciais que demonstram o comportamento do sistema. 31

40 A Figura 19 apresenta o caso de uso de criação de um novo arquivo de especificação. O usuário irá abrir o software e preencher os dados descritivos (nome e descrição). Após preencher os dados descritivos o usuário irá preencher os dados relativos ao parsing. Os dados de parsing são: nome do assembly ou programa, nome da classe e método ou função. Em seguida o usuário poderá preencher os dados de validação, que é composto por dados de parsing, posição e tamanho dos bytes de validação. Após isto o usuário irá definir os dados de parsing para cada valor contido no quadro de dados. Os dados de parsing padrão são utilizados para todos os elementos sem definição de parsing. Figura 19. Criação de um novo arquivo de especificação A Figura 20 apresenta o caso de uso onde o usuário irá modificar um arquivo de especificação já existente. O software carrega o arquivo e automaticamente preenche os campos com os valores presentes no arquivo de especificação. Caso o arquivo seja invalido o software apresenta uma mensagem de erro. Após alterar os dados o usuário pode ver como o arquivo ficou utilizando o preview e após confirmar os dados pode salvar a nova versão do arquivo de especificação. Figura 20. Edição de um arquivo de especificação 32

41 Diagrama de classes Diagramas de classes descrevem a estrutura do sistema mostrando suas classes, atributos, operações, métodos e relações entre as classes (OBJECT MANAGEMENT GROUP, 2005). A Figura 21 apresenta o diagrama de classe desenvolvido. As classes Specification, Value e Validator são as que representam o arquivo de especificação. A classe Program inicia as configurações do software e exibe a tela principal, representada pela classe Main. A classe Main contém componentes visuais para a inclusão ou alteração dos dados de um arquivo de especificação. A classe Main é responsável pela manipulação de arquivos, o método Save é responsável por salvar os dados no formato do arquivo de especificação, este método contem informações do arquivo, se ainda não existe o software pergunta se deseja salvar um novo arquivo, caso contrário o arquivo é salvo substituindo o existente. O método Preview inicia um novo formulário contendo o XML, com coloração de sintaxe, que será gerado a partir dos dados informados no software. O método Open abre um arquivo de especificação e carrega todos os valores para os componentes do formulário. A classe InvokerTypePanel é um controle de interface que permite a entrada de dados de parsing. O parser padrão e os dados de parse de validação utilizam este controle para gerenciar a configuração destes dados. A classe Preview é um formulário responsável pela exibição do arquivo de especificação no formato XML. O método Highlight faz com que a saída do XML seja marcada com cores para identificar os elementos e atributos. A classe ManagedValues representa o formulário que contem a tabela de valores. Cada valor tem os dados nome, posição e tamanho, e dados de parsing. 33

42 Este formulário possui métodos auxiliares que ajudam a manipulação dos dados: incluir próximo na sequência, ordenar por posição, salvar e fechar. Figura 21. Diagrama de classes do gerador de arquivos de especificação O software depende das classes relativas ao arquivo de especificação, que são Specification, AssemblyInvoker, Value e Validator. Estas classes refletem o arquivo de especificação e são utilizadas para gerenciar os dados desta aplicação Descrição do software O software de criação de arquivos de especificação apresenta uma interface onde o usuário pode preencher os dados necessários para efetuar o reconhecimento de dados telemétricos e em seguida salvá-los no formato de um arquivo de especificação para que posteriormente possa ser utilizado por um parser. 34

43 A Figura 22 apresenta a tela principal do software. Nesta tela é possível configurar as opções gerais do arquivo de especificação que são essenciais para que se possa carregar os programas de parsing. O campo Framework rotulado pelo número 1 determina o tipo do parser, se ele foi feito em um managed code (em.net), ou utilizando outra linguagem de programação. Esta informação é necessária para que o software de processamento consiga determinar o tipo do parser e carregá-lo. Uma vez que o software de parsing é carregado o software de processamento pode chamar os métodos especificados para validar e obter os dados. O campo Series rotulado pelo número 2 indica qual o instrumento de medição este arquivo está gerenciando e juntamente com o campo Description rotulado no número 3 fornecem uma descrição clara do instrumento para o reconhecimento humano. Figura 22. Tela principal do software de geração de arquivos de especificação O campo Data encryption rotulado pelo número 4 indica se os dados estão com algum tipo de criptografia. Esta informação é enviada para o parser no momento em que os métodos são chamados. O software de parsing é unicamente responsável por converter os dados de acordo com a codificação. 35

44 O bloco rotulado pelo número 5 contém os campos Assembly, Type, Method quando o framework DotNet está selecionado e Program, Method quando o framework é outro. Este bloco representa as informações do parser padrão. O parser global representado neste bloco é utilizado em todos os campos que necessitam de informações de parsing caso não contenham informações especificas, ou seja, este parser é utilizado por todos os campos de dados e o campo de validação caso nenhum seja especificado para estes. O bloco rotulado pelo número 6 apresenta informações de parsing específicos para a validação dos dados telemétricos. Caso os valores não sejam especificados, o software de processamento irá considerar que este utiliza o parser global. Neste bloco há dois campos a mais, que representam a posição dos dados relativos a validação. Start position representa a posição do dado de validação e Data length representa a quantidade de caracteres que este dado possui. O botão rotulado pelo número 7 ao ser clicado apresenta uma nova tela onde é possível gerenciar os tipos de dados. As linhas da tabela apresentada representam os dados da aplicação. Cada dado pode conter um parser diferente e contem informações da posição e do tamanho para que o software de processamento saiba de onde extrair os dados e como converte-los. O botão rotulado pelo número 8 ao ser clicado apresenta uma nova tela onde são exibidas as informações do arquivo de especificação no formato XML (formato em que o arquivo será salvo). O arquivo gerado segue as regras do XML Schema definido para os arquivos de especificação. O botão rotulado pelo número 9 exibe uma caixa de dialogo para salvar o arquivo caso o arquivo seja novo. Caso o arquivo já exista e estiver sendo modificado o botão irá salvar diretamente sobrescrevendo o arquivo existente. Após a configuração dos dados gerais do arquivo de especificação pode-se configurar as informações relativas ao processamento dos dados. A Figura 23representa a tela de gerenciamento de dados onde é possível configurar o valor, sua posição, seu tamanho e os dados relativos ao parser. Os botões no topo da tela rotulados pelos números 1, 2 e 3 são funções auxiliares. O botão rotulado pelo número 1 ordena os elementos da tabela de acordo com o StartPosition, a 36

45 posição dos dados. O botão rotulado pelo número 2 adiciona uma nova linha na tabela com a próxima posição da sequência, facilitando a inserção de valores. O botão rotulado pelo número 3 salva as alterações e retorna a tela principal. A tabela no número "4" representa o mapeamento dos dados. A coluna Name é o nome de um dado, a coluna StartPosition indica a posição de um dado, a coluna DataLength indica o número de bytes deste dado. Os campos Assembly, Type e Method são as informações do parser, que se omitidas adquirem os valores do parser global. Figura 23. Tela de gerenciamento de dados 3.3. SOFTWARE DE SIMULAÇÃO DE DADOS A função deste software é estabelecer uma conexão com o servidor, enviar dados e exibir o resultado retornado. Neste TCC este software foi utilizado para enviar dados ao servidor, simulando assim dados que seriam recebidos pelo servidor. Desta forma é possível testar o software de processamento de dados. 37

46 Requisitos Requisitos funcionais do software de simulação são: O software deve enviar dados nos formatos determinados para a simulação; O software deve enviar dados através de uma conexão TCP; e O software deve receber resposta do servidor e exibir na tela. Os requisitos não funcionais do software de simulação são: O software deve ser desenvolvido em C#.NET; A base de dados deverá ser MSSQL Express (Microsoft SQL Express); A conexão deverá ser através do protocolo TCP; e Caso o software receba a mensagem de dados inválidos deve gerar um arquivo físico com os dados que foram transmitidos. 38

47 Casos de uso Para simular um envio de dados o usuário deve abrir o software de simulação, selecionar a porta para efetuar a conexão e clicar em enviar dados. O software irá alterar entre os estados apresentando o resultado na tela onde o usuário poderá verificar a situação. A Figura 24 apresenta o modo de uso do software. Inicialmente o usuário deve criar arquivo de texto com os dados que serão enviados. Estes arquivos devem conter o nome equivalente a porta de conexão, por exemplo 6800.txt. Em seguida o usuário poderá selecionar a porta de conexão e clicar em enviar dados. Os dados serão enviados para o servidor que irá validar, processar e armazenar os dados. Dados inválidos são retornados ao software de simulação e exibidos. Figura 24. Caso de uso do simulador 39

48 Diagrama de classes O diagrama de classe deste software se restringe ao próprio escopo de classes, pois não tem dependências. A Figura 25 apresenta o diagrama de classes onde o método send_click realiza o processo de envio dos dados que são obtidos de um arquivo de texto com o nome da porta selecionada para a conexão. A classe Main representa o formulário do software onde é possível selecionar a porta e observar a execução do software. Figura 25. Diagrama de classes do software de simulação Descrição do software A Figura 26 apresenta a tela do software, onde há três elementos. O elemento rotulado pelo número 1 exibe o estado do software e as respostas do servidor. Em caso de falha no envio ou no processamento no servidor o software apresenta uma mensagem de erro informando que os dados não 40

49 foram salvos no servidor. O campo rotulado pelo número 2 é um campo para a seleção da porta TCP pela qual o simulador irá enviar os dados. O campo rotulado pelo número 3 é o botão que inicia o processo de conexão e envio dos dados. Figura 26. Tela do software de simulação do envio de dados Neste exemplo o software iniciou a conexão, escreveu os dados e recebeu a resposta de OK do servidor. Os dados enviados pelo software dependem da seleção da porta TCP. De acordo com a porta selecionada o software irá enviar dados que serão lidos de um arquivo de texto que tem o nome igual ao número da porta. 41

50 A Figura 27 apresenta a tela do software de simulação quando não consegue realizar a conexão. Neste caso os dados não são enviados, para que os dados sejam enviados o servidor deve estar ativo e possuir um arquivo de especificação valido na porta da conexão. Figura 27. Mensagem de erro no simulador SOFTWARES DE PARSING Esta seção descreve as especificações do software de parsing de dados. Este software foi desenvolvido para traduzir dados recebidos em dados humanamente legíveis. Os parsers podem ser desenvolvidos em qualquer linguagem de programação que gere um programa que possa ser executado e retorne um valor no standard output. Parsers desenvolvidos em managed code devem apenas retornar um valor em um método. Foi desenvolvido um parser em C# e um parser em C++ para demonstrar o funcionamento dos software em diferentes linguagens de programação. 42

51 A Figura 28 apresenta um software de parsing. Este software é composto por métodos que aceitam os parâmetros data, encryption e de acordo com os parâmetros retornam um valor. A classe Generic a apresenta o método Parse que converte a string data para um inteiro. O valor é convertido de acordo com sua codificação. Figura 28. Exemplo de parser Para cada valor é possível ter um método associado para realizar a conversão dos dados de acordo com os parâmetros. 43

52 Requisitos Requisitos funcionais dos softwares de parsing são: Deve possuir métodos ou funções que retornam valores de acordo com os parâmetros enviados; Os métodos ou funções devem aceitar os parâmetros data e encoding"; O software deve tratar exceções; e O software deve retornar o valor convertido. Requisitos não funcionais dos softwares de parsing são: Caso o software apresente algum problema deve retornar null ou uma string vazia Diagrama de classes O diagrama de classe do parser desenvolvido em C# está representado na Figura 29. Este software possui uma única classe a qual possui métodos para efetuar a verificação dos dados e métodos para converter os dados. Figura 29. Diagrama de classes do software de parsing Este parser contem apenas uma classe a qual possui todos os métodos utilizados para a conversão e validação dos dados. 44

53 Descrição dos softwares Os softwares desenvolvidos contém uma classe com métodos que recebem os parâmetros de encoding e dados. Ao receber os dados o software faz o parsing dos dados recebidos de acordo com o encoding e retorna o valor final. Os parsers podem ser desenvolvidos em qualquer linguagem de programação que seja capaz de enviar um valor para o standard output e que funcione no Windows. O servidor irá identificar o seu tipo através do arquivo de especificação e iniciar seus métodos ou funções de acordo com o que for informado. Os parsers são essenciais para realizar a conversão dos dados recebidos, pois podem realizar diversas operações sobre os dados para converte-los no formato esperado. Parsers desenvolvidos sobre o.net Framework tem um ganho considerável em desempenho por executar diretamente sobre a mesma plataforma e por manter o assembly em cache. Estes parsers também têm a vantagem de retornar os dados diretamente no tipo correto, por exemplo, double. Os parsers desenvolvidos em outras aplicações não tem vantagens de performance, o software é iniciado sempre que um valor precisa ser convertido. 45

54 3.5. SOFTWARE DE PROCESSAMENTO E GERENCIAMENTO Esta seção descreve as especificações do software de processamento de dados. Este é o software proposto para solucionar o problema mencionado no capitulo de problematização o qual foi desenvolvido para receber, traduzir e armazenar os dados recebidos. Este software utiliza os parsers para efetuar a tradução dos dados recebidos Requisitos Requisitos funcionais do software de processamento são: O software deve possuir métodos ou funções que retornam valores de acordo com os parâmetros enviados; e Os métodos ou funções do software devem aceitar os parâmetros data e encoding". Os requisitos não funcionais do software de processamento são: O software será desenvolvido em C#.NET; e A base de dados deverá ser MSSQL Express (Microsoft SQL Express). 46

55 Diagrama de classes A Figura 30 apresenta as classes que estão ligadas às tabelas da base de dados. A classe Entities é uma classe gerada automaticamente pelo Entity Framework que é um framework da Microsoft para manipulação de uma base de dados. As classes Data e Mapping são classes ligadas a base de dados. Mapping armazena o número da porta da conexão e o caminho do arquivo físico de especificação. Figura 30. Camada de dados. A Figura 31 apresenta as classes do software. Inicialmente a classe Program é executada configurando a aplicação. Esta classe inicia o formulário principal da aplicação, o formulário Main. O formulário Main ao ser iniciado utiliza a classe Mapping para obter os mapeamentos configurados na base de dados. São lidos os valores Port e Spec, e através destas informações são iniciados um Listener para cada porta. Uma vez que o Listener inicia o arquivo de especificação fica armazenado na memória não precisando efetuar a leitura do arquivo novamente. Os listeners são iniciados em diferentes threads, logo cada porta tem uma linha de processamento separada. A classe Listener é a classe responsável por receber conexões, exibir status da aplicação e retornar dados. Ao receber dados a aplicação lê os dados enviados e os valida. A validação é feita 47

56 através do parser, para isto a aplicação utiliza as informações do arquivo de especificação para saber a quem deve chamar para validar os dados. Logo a aplicação utiliza as classes de especificação para obter os valores necessários e através dos valores StartPosition, DataLength, Assembly, Type e Method que compõe a classe Validator. A aplicação envia uma instancia da classe Validator para o método Invoke da classe estática Invoker. A classe Invoker tem como função executar o método ou programa que é solicitado retornando os dados recebidos pela saída do programa. Figura 31. Diagrama de classes do software de processamento de dados O parser irá indicar se os dados estão validos, em caso positivo a aplicação irá continuar o processo chamando o método Invoke para converter o restante dos dados. Em caso negativo a aplicação irá retornar uma mensagem para o software que enviou os dados informando os dados inválidos. Após converter os dados, a aplicação os armazena na tabela Data, podendo assim utilizar os valores em aplicações para visualização e analise de dados. 48

57 A Figura 32 apresenta as tabelas da base de dados. Nesta aplicação só são necessários armazenar dados de mapeamento entre porta de conexão e arquivo de especificação, e armazenar os dados recebidos pelo software. Figura 32. Diagrama de entidade relacionamento A tabela Mapping possui um relacionamento entre porta e arquivo de especificação. De acordo com a porta da conexão o arquivo de especificação correspondente é carregado. A tabela Data armazena os valores recebidos depois de serem convertidos pelo parser Diagrama de sequência Diagramas de sequência são diagramas que se focam em fornecer uma visão sequencial da execução de um software. Um diagrama de sequência demonstra a interação entre diferentes lifelines, que podem ser diferentes softwares ou componentes (OBJECT MANAGEMENT GROUP, 2005). A Figura 33 e Figura 34 representam o diagrama de sequência do software de processamento se comunicando com o software de simulação. A sequência de execução do software se inicia a partir do estabelecimento de uma conexão ao encerramento da conexão com o retorno de uma mensagem. 49

58 Após a conexão ser estabelecida o software de simulação envia dados para o software de processamento. Ao receber os dados o software de processamento inicia seu processo. Figura 33. Diagrama de sequência do software de processamento I No inicio do processamento, o software verifica se os dados recebidos são validos através do método de validação do parser. Para isto o software utiliza o arquivo de especificação para saber como deve validar os dados. 50

59 Após a validação, em caso de sucesso, o software inicia a conversão dos dados. Após converter, estes dados são armazenados na base de dados e o software encerra a conexão retornando uma mensagem de OK. Figura 34. Diagrama de sequência do software de processamento II Descrição do software Este software apresenta um campo que exibe um log das ações do software. O software, ao ser iniciado procura em uma base de dados quais as portas devem ser iniciadas para receber dados. Caso o arquivo de especificação esteja invalido ou não exista o software não inicia a conexão da porta correspondente. O software inicia uma thread que espera por dados em cada uma das portas registradas, caso o software encontre o arquivo de especificação. Ao receber uma conexão o software utiliza o arquivo de especificação carregado e inicia o processamento dos dados. 51

60 Primeiramente o software irá verificar se os dados foram recebidos corretamente utilizando o software de parsing para isto. As informações StartPosition, DataLength, Assembly, Type e Method são utilizadas para carregar o assembly ou programa e chamar o método ou função que converte os bytes na posição indicada em um valor boleano. Caso a validação falhe o software informa através da conexão aberta que os dados são inválidos. Caso os dados sejam validos o software carrega as informações de parsing para os dados e invoca o método ou função que converte os dados. Após converter os dados o software os armazena na base de dados para serem consumidos posteriormente TESTES Para efetuar os testes foi desenvolvido um software que envia dados para o servidor através de uma conexão TCP/IP. Este software adquire os dados em um arquivo de texto correspondente a porta de conexão selecionada e envia os dados contidos no arquivo. Desta forma foi possível realizar o teste do software do servidor sem a necessidade de aparelhos reais. O primeiro teste foi feito com dados obtidos por um analisador de tensão que foi desenvolvido por uma empresa de hardware em Porto Alegre, este instrumento registrava a tensão ao longo do tempo para identificar picos ou quedas de tensão. Os dados foram enviados para o servidor que recebeu, validou e armazenou. Para efetuar a validação e a conversão dos dados foi utilizado um parser desenvolvido em C#. O segundo teste foi feito com os mesmos dados do primeiro teste, porém o parser utilizado pelo servidor foi desenvolvido em C++. O terceiro teste foi feito com dados obtidos por um analisador de energia da Embrasul. Este instrumento registrava tensão, corrente, frequência, potencia ativa, potencia reativa, potencia aparente, fator de potencia, distorção harmônica, energia ativa, energia reativa e energia aparente (EMBRASUL, 2011). 52

61 A Figura 35 apresenta uma imagem ilustrativa de um analisador de energia da Embrasul. Figura 35. Analisador de energia Fonte: Adaptado de EMBRASUL (2011) O quarto teste foi feito com dados obtidos no site Weather Underground sobre as condições do tempo em novembro de Este site registra dados climáticos obtidos em estações meteorológicas, os dados utilizados foram obtidos na estação de Balneário Camboriu (WEATHER UNDERGROUND, 2008). Após obter dados de diferentes aplicações foi possível realizar os testes. Primeiramente foram feitos testes de caixa branca, onde foram observados os passos do programa desde sua inicialização até a conclusão de seu processo que é o recebimento, validação, processamento e armazenamento. A segunda fase de testes foi realizada com o conceito de caixa preta onde dado certos dados de entrada se espera certos dados de saída. Após o envio e armazenamento dos dados foi feita uma comparação dos dados obtidos com os dados originais. Para os dados do analisador de energia utilizaram-se gráficos para fazer uma analise dos dados e compará-los aos gráficos do software ANAWIN da Embrasul. E para os dados obtidos na estação meteorológica foram feitas comparações com os gráficos gerados no site Weather Underground. 53

62 A Figura 36 apresenta o gráfico gerado a partir dos dados obtidos pelo software de processamento. A grandeza medida é a corrente, obtida a cada hora. Figura 36. Dados de corrente obtidos pelo software de processamento A Figura 37 apresenta o gráfico gerado pelo software ANAWIN da Embrasul. As linhas inferiores representam os valores de corrente. Figura 37. Gráfico dos valores de corrente no software ANAWIN. É possível observar que os dados têm um mesmo padrão em ambos os gráficos. De tempos em tempos há uma atividade na corrente que dura alguns minutos e termina. 54

63 A Figura 38 apresenta uma tabela com dados obtidos pelo software desenvolvido. Os dados são relativos às condições climáticas do mês de novembro de Figura 38. Tabela de dados climáticos do mês de novembro de A Figura 39 apresenta parte da tabela de dados disponibilizada pelo website Weather Underground (o site para a tabela completa se encontra no Anexo III). Figura 39. Tabela de dados climáticos do mês de novembro de É possível observar que os dados obtidos no servidor são idênticos aos dados que foram utilizados para a simulação. Os resultados obtidos comprovaram que é possível ter um único software que processa diferentes tipos de dados e os armazena. 55