desenvolvimentodesistemasupervisório … · 2019-03-23 · aberto, de modo que seja possível...

Universidade Estadual de LondrinaCentro de Tecnologia e UrbanismoDepartamento de Engenharia Elétrica

Pedro Henrique Batista Bonifácio

Desenvolvimento de Sistema Supervisóriopara Aquisição de Dados de Sensores

Embarcados Através do Protocolo TCP/IP

Londrina2018

1

Universidade Estadual de Londrina

Centro de Tecnologia e UrbanismoDepartamento de Engenharia Elétrica


Desenvolvimento de Sistema Supervisório paraAquisição de Dados de Sensores Embarcados Através

do Protocolo TCP/IP

Trabalho de Conclusão de Curso orientado pelo Prof. Dr. AzizElias Demian Junior intitulado “Desenvolvimento de Sistema Su-pervisório para Aquisição de Dados de Sensores Embarcados Atra-vés do Protocolo TCP/IP” e apresentada à Universidade Estadualde Londrina, como parte dos requisitos necessários para a obtençãodo Título de Bacharel em Engenharia Elétrica.

Orientador: Prof. Dr. Aziz Elias Demian Junior

Londrina2018

2

Ficha Catalográfica

Pedro Henrique Batista BonifácioDesenvolvimento de Sistema Supervisório para Aquisição de Dados de SensoresEmbarcados Através do Protocolo TCP/IP - Londrina, 2018 - 98 p., 30 cm.Orientador: Prof. Dr. Aziz Elias Demian Junior1. SCADA. 2. Linguagem C#. 3. Monitoramento. 4. Sistemas Embarcados.5. Automação.I. Universidade Estadual de Londrina. Curso de Engenharia Elétrica. II.Desenvolvimento de Sistema Supervisório para Aquisição de Dados de SensoresEmbarcados Através do Protocolo TCP/IP.

3


Desenvolvimento de Sistema Supervisóriopara Aquisição de Dados de Sensores

Embarcados Através do Protocolo TCP/IP

Trabalho de Conclusão de Curso apresentado ao Curso deEngenharia Elétrica da Universidade Estadual de Londrina,como requisito parcial para a obtenção do título de Bacharelem Engenharia Elétrica.

Comissão Examinadora

Prof. Dr. Aziz Elias Demian JuniorUniversidade Estadual de Londrina

Orientador

Prof. Dr. Ernesto Fernando FerreyraRamírez

Universidade Estadual de Londrina

Prof. Dr. Leonimer Flávio de MeloUniversidade Estadual de Londrina

Londrina, 26 de janeiro de 2018

4

Dedico este trabalho à todosque confiaram em minhas capacidades;

e ainda mais, à todos que disseram que eu não seria capaz.

5

Agradecimentos

Em primeiro lugar, agradeço à Deus por todas as bençãos, oportunidades e escolhasque me foram dadas. Agradeço à minha família, em especial meus pais, Ivan de Jesus Bo-nifácio e Marisa do Rossio Batista Bonifácio, e a minha irmã, Mariana Batista Bonifácio,por proverem tudo o que foi necessário, por oferecem um ombro amigo e suporte quandotudo pareceu desabar, e também por entenderem minhas ausências. Vocês são formadoresdo meu caráter, são exemplos do tipo de pessoa que quero ser; muito obrigado por tudo,eu seria nada sem vocês.

Agradeço à minha namorada, Rafaela, por entender meus muitos momentos distantese ainda mais por estar ao meu lado quando tudo parecia dar errado. Agradeço aos meusamigos; os que sempre estiveram em minha vida, Augusto Henrique Salla Rosa, DanielRamari, Fernanda Galo Gentilin, Gustavo Henrique Nogueira, Lucas Freire Dutra, LuizHenrique Carvalho, Vinícius de Souza Tenório; aos novos amigos que a Universidade Es-tadual de Londrina me apresentou, Alan Cardoso Barbosa, André Grazziotin Machado,Augusto Kamizake, Caroline Ambiel Gil, Deborah Hikari, Diogo dos Santos Gomes, Edu-ardo Rodrigues, Everton José Santana, Filipe Travizani Riçato, Gabriel Avanzi Ubiali,Ítalo Stresser dos Santos, Rafael Loni Martins e Rafael Sarzi. Obrigado por cada rolê,por cada madrugada de estudo, as conversas intermináveis, cada cerveja, whisky, discosvoadores e Ypiocas. Me desculpem por não ser o melhor amigo do mundo e me ausentarmuitas vezes. Que a distância não seja impeditivo da nossa amizade.

Agradeço ao Departamento de Engenharia Elétrica por toda a contribuição dada paraa minha formação acadêmica e profissional, em especial ao meu professor orientador Prof.Dr. Aziz Elias Demian Junior, tanto aos outros docentes como aos técnicos pela passagemde conhecimento e experiência. Agradeço à Universidade Estadual de Londrina por meproporcionar toda a experiência vivida dentro campus, e ainda mais pelas experiênciasocorridas além dos limites do campus.

Agradecimentos 6

B > 1N

∑Ni=1 Xi

"Be greater than average."

Agradecimentos 7

Pedro Henrique Batista Bonifácio. Desenvolvimento de Sistema Supervisório paraAquisição de Dados de Sensores Embarcados Através do Protocolo TCP/IP.2018. 98 p. Trabalho de Conclusão de Curso em Engenharia Elétrica - UniversidadeEstadual de Londrina, Londrina.

ResumoA partir do início da automação industrial começaram a ser implementados os sistemassupervisórios de controle e aquisição de dados. Este tipo de software é interessante devidoà suas características e capacidades; de modo que diversas áreas passaram a utilizá-lo. Este trabalho tem como objetivo o desenvolvimento de um sistema supervisório decódigo aberto para uso de estudantes utilizando a linguagem de programação C#. Sãocitados conceitos como sistemas embarcados, modelo de comunicação OSI, formataçãoJSON e verificação de redundância cíclica. Foi desenvolvido um protocolo de mensagensaberto, de modo que seja possível endereçar receptores e transmissores de mensagem,e também permite a inclusão de novos comandos. Os comandos deste protocolo foramdefinidos com base em sensores e placas que são amplamente utilizados por estudantesde graduação, de modo que tenham fácil acesso a estes módulos. O software inicia umservidor TCP/IP e aguarda conexões de possíveis clientes prontos para enviar mensagens;também é possível enviar mensagens através de portas seriais conectadas ao computador.Foram desenvolvidas interfaces gráficas, como gráficos variantes no tempo e gauges, para aexibição dos dados recebidos de sensores. Por fim, foram executados testes para comprovaras capacidades do sistema supervisório desenvolvido, seja para quantidade de mensagensmanipuladas, quanto para tempo máximo de execução. Outras funcionalidades incluempossiblidade de salvar log de mensagens, criação de arquivos formatados em JSON ecriação de tabelas a partir destes dados. O desempenho demonstrado pelo software semostrou satisfatório, de modo que os requisitos de projeto foram atendidos.

Palavras-Chave: 1. SCADA. 2. Linguagem C#. 3. Monitoramento. 4. SistemasEmbarcados. 5. Automação.

Agradecimentos 8

Pedro Henrique Batista Bonifácio. Development of a supervisory system for dataaquisition on embedded sensors by TCP/IP Protocol. 2018. 98 p. Monograph inEngenharia Elétrica - Universidade Estadual de Londrina, Londrina.

AbstractFrom the beginning of industrial automation, the need to monitor and control manufac-turing processes grew up; and in this way, the supervisory control and data acquisitionsystems started to be developed. This type of software was interesting because of itscharacteristics and capabilities; so that several areas started to use it. This work aimedto develop an open source supervisory system for student use, it was developed usingthe C# programming language. Important concepts such as embedded systems, OSIcommunication model, JSON format and cyclic redundancy check were mentioned. Anopen messaging protocol has been developed so that it is possible to address receiversand message transmitters, and also allows the inclusion of new commands. The com-mands of this protocol were defined based on sensors and boards that are widely usedby undergraduates, so that they have easy access to these modules to start using thissoftware. The SCADA software starts a TCP / IP server and waits for connections fromclients ready to send messages; it is also possible to send messages through serious portsconnected to the computer. Graphical interfaces have been developed, such as gauges andtime-varying graphs, to display the data received from sensors. Finally, tests were carriedout to prove the capabilities of the supervisory system developed for both the numberof messages manipulated and the maximum execution time. Other features include theability to save messages, create JSON-formatted files, and create tables from these data.The performance demonstrated by the software was satisfactory, so that the requirementswere met.

Key-words: 1. SCADA. 2. C# Language. 3. Monitoring. 4. Embedded Systems. 5.Automation.

10

Lista de ilustrações

Figura 1 – Demonstração da associação de diversos produtos da empresa ElipseSoftware. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

Figura 2 – Interface gráfica do software Elipse. . . . . . . . . . . . . . . . . . . . . 19Figura 3 – Interface gráfica do software SCADABR. . . . . . . . . . . . . . . . . . 20Figura 4 – Interface gráfica do software SCADABR. . . . . . . . . . . . . . . . . . 21Figura 5 – Escopo do sistema supervisório a ser desenvolvido.. . . . . . . . . . . . 22Figura 6 – Tela inicial do Visual Studio. . . . . . . . . . . . . . . . . . . . . . . . 35Figura 7 – Tela para criação de um novo projeto. . . . . . . . . . . . . . . . . . . 36Figura 8 – Novo projeto criado no Visual Studio. . . . . . . . . . . . . . . . . . . 37Figura 9 – Criação da interface para demonstração do uso da porta serial. . . . . . 38Figura 10 – Demonstração de um RichTextBox selecionado. . . . . . . . . . . . . . 38Figura 11 – Alteração da interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39Figura 12 – Interface após alteração dos textos de exibição dos componentes. . . . . 40Figura 13 – Propriedades do componente ComboBox2. . . . . . . . . . . . . . . . . 40Figura 14 – Incluindo valores de baudrate no componente ComboBox2. . . . . . . . 41Figura 15 – Software desenvolvido nesta seção, incluindo mensagens transmitida e

recebida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 16 – Organização da interface gráfica para o usuário para o software de

demonstração de um servidor TCP/IP. . . . . . . . . . . . . . . . . . . 44Figura 17 – Interface gráfica para o usuário para o software de demonstração de um

servidor TCP/IP após renomear os componentes. . . . . . . . . . . . . 45Figura 18 – Configuração do aplicativo TCP UDP Terminal como cliente TCP. . . 47Figura 19 – Demonstração da comunicação entre cliente e servidor mostrados na

tela do aplicativo TCP UDP Terminal. . . . . . . . . . . . . . . . . . . 48Figura 20 – Demonstração da comunicação entre servidor e cliente mostrados na

interface gráfica do software desenvolvido. . . . . . . . . . . . . . . . . 48Figura 21 – Demonstração de como o software se comportar após a introdução do

método de análise de mensagem. . . . . . . . . . . . . . . . . . . . . . 50Figura 22 – Abrindo o gerenciador de bibliotecas Nuget. . . . . . . . . . . . . . . . 52Figura 23 – Gerenciador de bibliotecas Nuget. . . . . . . . . . . . . . . . . . . . . . 52Figura 24 – Instalando a biblioteca Newtonsoft. . . . . . . . . . . . . . . . . . . . . 53Figura 25 – Interface gráfica do usuário informando onde o arquivo será salvo. . . . 54Figura 26 – Tela inicial do sistema supervisório. . . . . . . . . . . . . . . . . . . . . 69Figura 27 – Configurações iniciais do sistema supervisório. . . . . . . . . . . . . . . 69Figura 28 – Interface para exibição do log de dados. . . . . . . . . . . . . . . . . . . 70

Lista de ilustrações 11

Figura 29 – Interface gráfica para acelerômetros. . . . . . . . . . . . . . . . . . . . 71Figura 30 – Interface gráfica para sensor de temperatura. . . . . . . . . . . . . . . . 72Figura 31 – Interface gráfica para sensor de corrente. . . . . . . . . . . . . . . . . . 73Figura 32 – Interface gráfica para demais sensores. . . . . . . . . . . . . . . . . . . 74Figura 33 – Exibição do log de mensagens. . . . . . . . . . . . . . . . . . . . . . . . 76Figura 34 – Exibição dos valores recebidos para o acelerômetro. . . . . . . . . . . . 77Figura 35 – Exibição das últimas 100 amostras de temperatura recebidas. . . . . . 77Figura 36 – Exibição das últimas 100 amostras de corrente recebidas. . . . . . . . . 78Figura 37 – Exibição dos dados recebidos para demais sensores. . . . . . . . . . . . 78

12

Lista de tabelas

Tabela 1 – Configuração dos componentes. . . . . . . . . . . . . . . . . . . . . . . 39Tabela 2 – Configuração dos componentes para o software de demonstração de um

servidor TCP/IP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Tabela 3 – Formato do protocolo de comunicação implementado no projeto. . . . . 55Tabela 4 – Formato do cabeçalho da mensagem do protocolo. . . . . . . . . . . . . 56Tabela 5 – Separação do protocolo com seus respectivos campos. . . . . . . . . . . 57Tabela 6 – Comando de requisição de dados para o acelerômetro. . . . . . . . . . 57Tabela 7 – Resposta do sistema monitorado para o comando de leitura do acelerô-

metro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Tabela 8 – Comando de requisição de dados para o sensor de temperatura. . . . . 59Tabela 9 – Resposta do sistema monitorado para o comando de leitura do sensor

de temperatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Tabela 10 – Variação da resolução da saída analógica conforme o modelo do CI

ACS712. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Tabela 11 – Comando de requisição de dados para o sensor de corrente. . . . . . . . 60Tabela 12 – Resposta do sistema monitorado para o comando de leitura do sensor

de corrente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Tabela 13 – Comando de requisição de dados para o sensor de ultrassônico. . . . . 61Tabela 14 – Resposta do sistema monitorado para o comando de leitura do sensor

ultrassônico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Tabela 15 – Comando de requisição de dados para o magnetômetro. . . . . . . . . . 62Tabela 16 – Resposta do sistema monitorado para o comando de leitura do mag-

netômetro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Tabela 17 – Envio de comandos para o relógio de tempo real. . . . . . . . . . . . . 63Tabela 18 – Parâmetros do RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Tabela 19 – Resposta do sistema monitorada para o comando de leitura dos dados

do relógio de tempo real. . . . . . . . . . . . . . . . . . . . . . . . . . . 65Tabela 20 – Envio de comandos para as portas digitais. . . . . . . . . . . . . . . . . 66Tabela 21 – Resposta do sistema monitorado para os comandos das portas digitais. 66Tabela 22 – Envio de comandos para as portas analógicas. . . . . . . . . . . . . . . 67Tabela 23 – Resposta do sistema monitorado para os comandos das portas analógicas. 68Tabela 24 – Medições dos testes de capacidade de recebimento de mensagens atra-

vés da porta serial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Tabela 25 – Medições dos testes de capacidade de recebimento de mensagens atra-

vés do protocolo TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . 79

Lista de tabelas 13

Tabela 26 – Medições dos testes de capacidade de tempo de execução. . . . . . . . 80

14

Lista de Siglas e Abreviaturas

API Application Programming InterfaceARPANET Advanced Research Project Agency NetworkCERN Conseil Européen pour la Recherche NucléaireCLI Common Intermediate LanguageCLP Controladores lógicos programáveisCLR Common Intermediate RuntimeCOOL C-Like Object Oriented LanguageCRC Cyclic Redundancy CheckEOF End of FrameHMI Humam Machine InterfaceICS Industrial Control SystemIDE Integrated Development EnvironmentIOT Internet of ThingsIP Internet ProtocolISO International Organization for StandardizationJSON JavaScript Object NotationLINQ Language Integrated QueryLOA Levels of AutomationOSI Open System InterconnectionSOF Start od FrameSCADA Supervisory Control and Data AquisitionSCD Sistemas de controle distribuídoTCP Transmission Control ProtocolUCL University College London

15

Sumário

Lista de ilustrações . . . . . . . . . . . . . . . . . . . . . . . . . . 10

Lista de tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Sumário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.2.1 Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.2.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.3 Metodologia do Trabalho . . . . . . . . . . . . . . . . . . . . . . . 23

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 242.1 Sistemas Supervisórios de Controle e Aquisição de Dados . . 242.2 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . 262.3 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.4 Protocolo de Comunicação TCP/IP . . . . . . . . . . . . . . . . 292.5 Framework .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302.5.1 Linguagem C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312.5.2 Compilação e Execução . . . . . . . . . . . . . . . . . . . . . . . . 322.6 JSON - JavaScript Object Notation . . . . . . . . . . . . . . . . 322.7 Verificação Cíclica de Redundância . . . . . . . . . . . . . . . . . 33

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.1 Criando um novo projeto utilizando Visual Studio . . . . . . . 353.2 Porta serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.3 Servidor TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.4 Tratamento de mensagens . . . . . . . . . . . . . . . . . . . . . . 493.5 Salvar arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.6 Definição do Protocolo de Mensagens . . . . . . . . . . . . . . . 553.7 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.7.1 Acelerômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573.7.2 Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.7.3 Corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 603.7.4 Sensor Ultrassônico . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Sumário 16

3.7.5 Magnetômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.7.6 Relógio de Tempo Real - RTC . . . . . . . . . . . . . . . . . . . . 633.7.7 Porta Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 663.7.8 Porta Analógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 673.8 Design da interface de usuário . . . . . . . . . . . . . . . . . . . . 683.9 Hardware de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.9.1 Arduino Mega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.9.2 STM32F4DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 753.9.3 Trabalho de Conclusão de Curso . . . . . . . . . . . . . . . . . . 75

4 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . 76

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 815.1 Sugestões para projetos futuros . . . . . . . . . . . . . . . . . . . 82

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Lista de Apêndices . . . . . . . . . . . . . . . . . . . . . . . . . . 86

A EXEMPLO DA FORMATAÇÃO JSON . . . . . . . . . . . . . 87

B CÓDIGO PARA CÁLCULO DA VERIFICAÇÃO CÍCLICADE REDUNDÂNCIA . . . . . . . . . . . . . . . . . . . . . . . . 88

C CÓDIGOS UTILIZADOS NA METODOLOGIA DO TRA-BALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

C.1 Busca de Portas Seriais Conectadas ao Computador. . . . . . 89C.2 Criação de um Timer para Busca de Portas Seriais . . . . . . . 89C.3 Métodos para Manusear Eventos de Clique em Botões . . . . 90C.4 Método Utilizado para Recebimento de Dados da Porta Serial 91C.5 Busca Automática de IP . . . . . . . . . . . . . . . . . . . . . . . 91C.6 Abertura de um Servidor TCP/IP quando Ocorre Um Clique

em um Botão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92C.7 Métodos Callback Utilizados para o Servidor TCP/IP . . . . 93C.8 Implementação do Envio de Mensagens do Servidor TCP/IP 94C.9 Implementação do Método Tratar_Mensagem . . . . . . . . . 95C.10 Salvar LOG em *.txt . . . . . . . . . . . . . . . . . . . . . . . . . . 96C.11 Classe de Dados para Arquivo JSON . . . . . . . . . . . . . . . 97C.12 Criando Arquivo Formatado em JSON . . . . . . . . . . . . . . 97

17

1 Introdução

O contínuo desenvolvimento do conhecimento humano nos últimos anos tem se mos-trado singular, resultando em um crescente desenvolvimento tecnológico. Desta maneira,a implementação de sistemas autônomos em indústrias surgiu como solução para atendera constante imposição do mercado consumidor por diversidade e qualidade. O progressoda automação não altera apenas a produção fabril ao aumentar a produtividade quandomáquinas e robôs computadorizados são incluídos à cadeia produtiva, mas também leva àuma integração de tarefas distintas que podem ser realizadas como gerenciamento admi-nistrativo e da produção (MAITELLI, 2011). O conceito de automação pode ser definidocomo um arranjo de técnicas aplicadas à tornar processos industriais independentes daação direta humana, visando poupar tempo e esforço do trabalhador, bem como gerareconomia pela diminuição de operadores e desta maneira gerando uma melhora na pro-dutividade industrial.

Com o aumento do uso de sistemas autônomos na indústria, em áreas como gás epetróleo, farmacêutica, transportes, automotiva e aeroespacial, surge a necessidade derealizar um controle fino destes sistemas que são responsáveis por inúmeros processos derisco dentro de uma planta industrial (STOUFFER; FALCO; SCARFONE, 2011). Apartir disto, começa-se à empregar os sistemas de controle indutrial, do inglês IndustrialControl System (ICS), que abrange diversos sistemas como controladores lógicos progra-máveis (CLP), sistema de aquisição de dados, sistemas de controle distribuído (SCD)e outras hardwares aplicados. E, conforme os sistemas crescem em conjunto com suacomplexidade, cada vez se torna mais imprescindível a implementação de um controleautomatizado; que através do uso de máquinas e sistemas programáveis, diminui a depen-dência de decisões tomadas por humano, tornando o conjunto mais confiável e previsível(PARASURAMAN, 2000).

Para que seja possível monitorar estes sistemas forma desenvolvidos inúmeros tiposde sensores, desde sensores de temperatura, pressão e corrente elétrica que são ampla-mente empregados na indústria em geral, também sendo possível citar acelerômetros,magnetômetros, sensores ultrassônicos de distância e relógios de tempo real, que podemser incluídos em uma vasta gama de aplicações incluindo automóveis, smartphones, wea-rables, monitores de desempenho esportivo, equipamentos médicos, aeronaves e foguetes.Sensores podem ser definidos como módulos, dispositivos ou sistemas que detectam even-tos ou mudanças de características do ambiente. Também são utilizados os chamadostransdutores, dispositivos capazes de converter um tipo de energia em outro; podem sercitados como exemplos de transdutores os sensores piezoelétricos, que é capaz de converterpressão mecânica em tensão elétrica, e vice-versa. Posteriormente, os dados fornecidos por

Capítulo 1. Introdução 18

estes dispositivos, seja na forma digital ou analógica, devem ser processados por sistemasmais complexos, como microcontroladores, para que seja possível analisá-los, interpretá-los e tomar decisões baseadas nestas informações (AGARWAL; LANG, 2005). Saber lidarcom estes tipos de dispositivo nos dias atuais, nos quais tem-se como tendência à aplica-ção de tecnologia em todos e quaisquer campos possíveis como Indústria 4.0 e Internetdas Coisas, deixa de ser uma opção e passa a ser uma obrigação para manter-se prepa-rado para o mercado de trabalho. Dado estes motivos, o conceito de sensores, atuadores,transdutores e automação passaram a se tornar constantes em diversos cursos que temcomo base a aplicação e desenvolvimento de tecnologia, como engenharia elétrica e ciênciada computação.

Por serem tão presentes em ambientes de estudo, em muitas ocasiões surge a neces-sidade de estudantes e entusiastas lidarem com os valores lidos de sensores, transdutoresou quaisquer outros dispositivos; valores os quais normalmente são apresentados na basehexadecimal, que é amplamente adotada em programação e arquitetura de microcon-troladores. Além da dificuldade de muitas pessoas em interpretar os valores nesta basenumérica, normalmente os valores puros por si só não significam nada; então, é necessá-rio interpretar estes valores, seja aplicando nas equações necessárias ou convertendo paravalores específicos, para que se tornem compreensíveis.

Os sistemas supervisórios tem uma vasta aplicação; portanto, há diversos trabalhosacadêmicos realizados que abordam este tema e também já existem sistemas open sourceabertos para acesso da comunidade. Em seu trabalho, Jurizato, Pereira et al. (2003) apre-senta interfaces de alguns dos sistemas disponíveis no mercado à época, os quais eramutilizados principalmente em plantas industriais. O autor também apresenta argumentosque desvendam a difusão deste tipo de sistema para diversas áreas; também são apre-sentadas uma arquitetura básica deste tipo de sistema e características de dois softwaresdisponíveis no mercado, Elipse Software e WinCC, como interfaces de comunicação e fun-cionalidades. Já no trabalho de Ferreira et al. (2007), é proposto o uso de um sistemasupervisório é utilizado para o gerenciar energia em veículos elétricos utilizando três dife-rentes formas de fornecimento. O software é responsável por gerenciar o fluxo de potênciado sistema de modo à fornecer a energia necessária para o funcionamento do veículo. Paraverificar a eficácia da solução de controle proposta, foi utilizado um protótipo de 3kW.

Há diversos sistemas supervisórios disponíveis no mercado, tanto programas gratuitosquanto pagos; os mais conhecidos são: Elipse, desenvolvido pela Elipse Software, e oScadaBR, desenvolvido em conjunto pela empresa SensorWeb, pela Fundação CERTI e aUniversidade Estadual de Santa Catarina. O Elipse é um software extremamente robusto,sendo muito utilizado em situações críticas como automação de usinas e subestaçõesde energia, parques eólicos e gestão de linhas ferroviárias. A empresa fornece diversosprodutos para atender todos os requisitos dos clientes; começando pelo software ElipseE3, que é um sistema ideal para sistemas de missão crítica, fornecendo desde uma interface


homem-máquina simples até complexos centros de operação. Outros produtos que podemser citados são o Elipse Mobile, que fornece uma integração de plataformas móveis esistemas de automação; e também tem-se o Elipse Gateway que funciona como umaferramenta de conversão de protocolos elétricos e industriais. A integração das diversassoluções pode formar um sistema extremamente completo e resistente conforme ilustradona Figura 1 abaixo.

Figura 1 – Demonstração da associação de diversos produtos da empresa Elipse Software.

Fonte: (ELIPSE SOFTWARE, 2018).

A Figura 2 abaixo mostra uma das interfaces gráficas que podem ser geradas utilizandoo sistema supervisório Elipse.

Figura 2 – Interface gráfica do software Elipse.

Fonte: (ELIPSE SOFTWARE, 2018).


A desvantagem de utilizar-se o software Elipse, é a limitação imposta por ser umsistema pago (ELIPSE SOFTWARE, 2018). Grande parte das funcionalidades não estadisponível para um usuário qualquer.

Já o ScadaBR, é um sistema livre, gratuito e de código-fonte aberto; muito utilizadopara para desenvolvimento de aplicações de Automação, Aquisição de Dados e ControleSupervisório. Este sistema é focado em profissionais de automação, universidades, em-presas de todos os portes; ou seja, toda e qualquer pessoa que tenha a necessidade demonitorar e controlar máquinas, motores, processos industriais e dados de ambientes pro-venientes de diversos sensores. Uma das vantagens de utilizar-se um projeto aberto paraa comunidade, é gozar de um vasto suporte, uma grande documentação e um fórum dediscussão amplo (SENSORWEB, 2017). As Figuras 3 e 4 ilustram exemplos da interfacegráfica que pode ser obtida ao utilizar este sistema.

Figura 3 – Interface gráfica do software SCADABR.

Fonte: (SENSORWEB, 2017).


Figura 4 – Interface gráfica do software SCADABR.

Fonte: (SENSORWEB, 2017).

A desvantagem de utilizar o ScadaBR é a necessidade de se instalar o Java RuntimeEnvironment - JRE para que se possa executar o programa, isto aumenta a complexidadedas configurações necessárias para o funcionamento do sistema. É interessante que o sis-tema seja intuitivo e pronto para execução, sem uma necessidade de complexas instalaçõesou configurações.

Os dois sistemas supracitados são extremamente completos, fornecendo inúmeras infor-mações e ricas interfaces gráficas; porém, em projetos acadêmicos estes softwares podemser um tanto quanto exagerados, tanto em funções oferecidas quando em complexidadede instalação ou limitações de licenças.

1.1 Justificativa

Por serem amplamente utilizados na indústria, muitos fornecedores de equipamentosjá fornecem, juntamente com seus equipamentos, os próprios sistemas supervisórios. Po-rém, muitas vezes, estes sistemas supervisórios são um sistema fechado, ou seja, eles nãopermitem integração com outros equipamentos, de outras fabricantes ou protótipos deestudantes; desta maneira, se torna inviável monitorar toda uma linha de produção ouum projeto acadêmico em um sistema unificado.


Desta maneira, torna-se interessante desenvolver um sistema aberto e de fácil uso,no qual seja possível integrar diversos equipamentos e sensores permitindo o monitora-mento em tempo real, seja de processos industriais ou projetos pessoais. Um sistema quepossa ser iniciado de forma simples e sem a necessidade de instalações de outros pacotes,torna-se interessante para acelerar o desenvolvimento de projetos e trabalhos; também énecessário que este sistema seja de leve execução para o sistema operacional. Para queeste projeto seja considerado aberto, é necessário que algumas liberdades básicas sejamfornecidas para o usuário: liberdade para executar o código, como quiser e para qualquerpropósito; de estudar e adaptar o código-fonte às suas necessidades; de redistribuir cópiasdo código-fonte e de distribuir cópias das suas versões modificadas. Este sistema abertopode ser atingido ao utilizar-se um protocolo aberto para a comunidade, de forma queo usuário adeque o sistema que deseja monitorar ao protocolo de comunicação utilizadopelo sistema supervisório; bem como possa alterar o sistema supervisório para sua con-veniência. Desenvolver um sistema supervisório baseado nestes termos é vantajoso poisqualquer sistema, que utilize o protocolo adequado, pode ser monitorado e possivelmentecontrolado, se este estiver programado para tal.

1.2 Objetivos

1.2.1 Gerais

Este trabalho de conclusão de curso tem como propósito o estudo e desenvolvimentode um sistema supervisório para gerenciamento e obtenção de dados gerados por diversossensores em tempo real, seja em uma planta industrial, veículo controlado remotamente,sistemas aeroespaciais, sistema eletrônico embarcado; porém com um foco em auxiliarprojetos acadêmicos, de modo que isto permita à alunos um rápido desenvolvimento emonitoramento de seu empreendimento.

O software contará com dois canais de comunicação: através de uma porta serial etrabalhando como um servidor TCP/IP. A Figura 5 demonstra o funcionamento básicodo sistema.

Figura 5 – Escopo do sistema supervisório a ser desenvolvido..

Fonte: Do autor.


1.2.2 Específicos

No desenvolvimento do projeto em questão,os seguintes objetivos serão buscados:

• Revisão sobre como e onde são utilizados sistemas supervisórios;

• Desenvolvimento de um sistema supervisório utilizando a IDE Visual Studio e alinguagem C#;

• Implementação de leitura e interpretação de dados dos sensores mais utilizados emprojetos de graduação;

• Teste do sistema supervisório desenvolvido ao monitorar um sistema eletrônico em-barcado.

1.3 Metodologia do Trabalho

De forma objetiva, 2ste trabalho está organizado em diferentes capítulos; primeira-mente no Capítulo 2 são desenvolvidos conceitos indispensáveis para um melhor entendi-mento da execução do trabalho. Em sequência, tem-se o Capítulo 3, onde são apresen-tadas orientações ao leitor para que este possa entender separadamente como cada parteintegrante do sistema é desenvolvida; também é especificado o protocolo de comunica-ção utilizado, desde os campos de mensagem até os campos de dados de cada um dossensores. Por fim, no Capítulo 4 são apresentados os resultados do desenvolvimento dosoftware como interface gráfica, exibição de dados de sensores e testes de capacidade derecebimento de mensagens e tempo máximo de execução.

24

2 Fundamentação Teórica

2.1 Sistemas Supervisórios de Controle e Aquisiçãode Dados

Os Sistemas Supervisórios de Controle e Aquisição de Dados (do inglês SupervisoryControl and Data Aquisition - SCADA),como o próprio nome indica é mais direcionadoà supervisão do que à um controle total do sistema. Estes sistemas podem ser entendi-dos como uma interface homem-máquina (em inglês: Humam Machine Interface - HMI),que consiste em uma camada de software que se comunica com um hardware. SistemasSCADA são amplamente utilizados na indústria para controle supervisório e aquisição dedados de processos industriais. Os sistemas supervisórios já são abundantemente utiliza-dos no controle de processos industriais na área petrolífera, química, geração de energia,alimentícia, metalúrgica. Também é possível verificar que estes sistemas estão tornando-secada vez mais presentes como controle de sistemas auxiliares em laboratórios experimen-tais; estes sistemas são aplicados para controle de ventilação, resfriamento e distribuiçãode energia, como pode ser verificado em experimentos recentes da Organização Europeiapara a Pesquisa Nuclear (em francês: Conseil Européen pour la Recherche Nucléaire -CERN. Estes sistemas tornam disponíveis ao operador ou usuário às informações do pro-cesso que está ligado; e também devem ser capazes de realizar ações e tomar decisõessobre o processo (DANEELS; SALTER, 1999).

A partir da revolução industrial, onde os processos produtivos tornaram-se cada vezmais agéis, surgiu a necessidade de monitorar os processos industriais e intervir em algumcontrole em nível de supervisão, quando necessário. Também há a necessidade de adquirirdados do processo, que podem ser obtidos em contato direto com o hardware instalado,ou, podem ser transmitidos remotamente, uma vez que o hardware pode estar instaladoem ambientes inóspitos e de difícil acesso (SOUZA, 2005). Esta grande necessidade,manifestada primeiramente na indústria, tornou-se uma das grandes áreas da engenhariaelétrica: a automação industrial.

A automação, seja ela implantada onde for, provê inúmeros benefícios como segu-rança, confiabilidade, economia e conforto; fatores que não podem ser garantidos apenasutilizando operação humana. Porém é necessário que um sistema supervisório para finsde automação tenha um sólido projeto, pois a implementação de softwares deste tipoimplicam em aumento momentâneo da carga de trabalho e necessidade de treinamentoao usuário; portanto sistemas mal desenvolvidos tornam-se extremamente custosos e emsituações extremas podem provocar acidentes com graves consequências. Este confronto,entre benefícios e riscos oriundos do uso de sistemas supervisórios em indústrias e apli-

Capítulo 2. Fundamentação Teórica 25

cações de risco, gerou inúmeros debates dentre a comunidade científica, principalmentesobre qual nível de controle, automatização, e segurança estes sistemas devem possuir(MILLER; PARASURAMAN, 2007). Entusiastas da tecnologia tendem à afirmar que aexecução de tarefas deva ser o mais independente possível de ações humanas; porém, inú-meros pesquisadores e engenheiros tendem à utilizar a lógica para atentar-se à questõescomo segurança e confiabilidade como futuros problemas da automação, e desta maneiracolocam-se contra altos níveis de automação (SHERIDAN, 1994).

Para sanar estes problemas, foram propostos os níveis de automação (do inglês: levelsof automation - LOAs); dentro destes níveis é possível tomar conhecimento dos riscos ebenefícios de um determinado tipo de sistema. Estes níveis são iniciados pela camada demais baixo nível, onde é realizado um controle puramente através de ações humanas, atéum nível extremamente alto onde a aplicação tem total autonomia sobre suas ações. Umaparte da comunidade científica concorda que, em termos de benefícios e riscos, a melhorescolha consiste de um sistema intermediário; ou seja, que possua certa autonomia mas quepermita aos operadores a executar tarefas e comandos. Outra parte propõem que sejamprojetados sistemas adaptativos, de modo que seja possível ajustar o nível de automaçãodurante a operação do sistema; porém, em aplicações reais, muitos usuários mostraram-sepouco determinados à utilizar sistemas adaptativos pois esta característica aumenta aimprevisibilidade do conjunto (MILLER; PARASURAMAN, 2007).

Segundo Miller e Parasuraman (2007), os níveis de automação podem ser elencadosda seguinte forma, do menor para o maior nível de automação:

1. Todas as decisões são tomadas por humanos

2. O computador oferece alternativas de decisões

3. O computador diminui a quantidade de alternativas baseado em um conhecimentoprévio ou ações recomendadas para a situação

4. O computador oferece uma ação preferencial

5. O computador executa a ação sozinho a partir da ação preferencial, desde que ooperador dê permissão

6. O computador executa a ação preferencial de forma independente, o operador tema opção de veto

7. O computador executa a ação preferencial e apenas informa o operador

8. O computador executa a ação preferencial, e informa o operador apenas se estesolicitar a informação

9. O computador executa a ação preferencial e informa o operador apenas se julgarnecessário


10. O computador executa todas as ações sozinho

2.2 Sistemas Embarcados

Pode-se definir um sistema embarcado como um sistema no qual um microcontroladorou microprocessador é encapsulado em um dispositivo para uma aplicação dedicada; naqual este deve executar ações de controle e monitoramento de sinais digitais e analógicos.Estes tipos de sistema são característicos por realizar operações em tempo real; e tambémpor terem requisitos específicos, diferentemente de um computador pessoal, o que permiteminimizar diversos fatores, como custos, dimensão física e consumo energético. Comoexemplo de sistemas embarcados podemos citar desde reprodutores de mídia, rastreadoresautomotivos, telefones celulares até mísseis militares e aviões.

A origem dos primeiros computadores deu-se na década de 1940, apesar de seremdispositivos grandes a ponto de ocupar diversos metros quadrados, estes realizavam ope-rações específicas que eram programadas diretamente no sistema. O primeiro dispositivoa ser produzido em massa foi o computador aplicado no míssil balístico intercontinentalamericano LGM30-Minuteman.

No príncipio, a maior dificuldade para o desenvolvimento de sistemas embarcados eraorigidado pela dimensão dos componentes empregados; porém, com o desenvolvimento denovas tecnologias, principalmente com o surgimento dos circuitos integrados, foi possívelminiaturizar componentes e consequentemente baratear os sistemas embarcados. A partirdisto, na década de 1980, começam a surgir microcontroladores através da integração decomponentes externos junto ao encapsulamento do processador.

Atualmente, os microcontroladores são amplamente disponíveis e de baixo custo; tendodiversas arquiteturas disponíveis como ARM, MPIS e AVR bem como uma vasta gamade periféricos disponíveis que podem ser empregados como interfaces seriais, converso-res analógico-digital e digital-analógico, timers internos, suporte a diversos periféricos eprotocolos de comunicação, além de fornecer estruturas básicas para acesso à internet. Po-dem ser citadas como aplicações possíveis: controle de veículos, eletrônicos direcionadosà consumidor final, sistemas de comunicação, medição remota de grandezas e automaçõesindustriais e residênciais. São aplicações nas quais as especificações mudam constante-mente e o time-to-market é imprescindível (EDWARDS et al., 1997).

Como principais tipos de periféricos podem ser citados:

• Interface de comunicação serial: RS-232, RS-422 e RS-485.

• Interface de comunicação serial síncrona: I2C, SPI, SSC e ESSI.

• Universal Serial Bus - USB

• Cartões Multimídia: cartões SD e Compact Flash.


• Redes: ethernet, WiFi, LoRa, Z-Wave, Bluetooth e ZigBee.

• Barramentos de comunicação: CAN, LIN e PROFIBUS.

• Temporizadores: PLLs, unidades de processamento de tempo e funções de capturae comparação.

• Entradas e saídas de uso geral - GPIO.

• Conversores: analógico-digital e digital-analógico.

2.3 Modelo OSI

O Modelo OSI - Open System Interconnection foi projetado pela Organização Inter-nacional de Normalização (do inglês International Organization for Standardization -ISO), e consiste em um modelo feito para padronizar e caraterizar a implementação defunções de comunicação para sistemas de telecomunicações ou sistemas computacionais,desconsiderando as tecnologias e estrutura interna que serão empregados; isto gera umgrande benefício, pois permite uma interoperabilidade entre sistemas diferentes desde queambos respeitem o protocolo padrão de comunicação. O Modelo OSI, é identificado porISO/IEC 7498-1, e tem como sua grande característica a partição do sistema de comu-nicação em camadas de abstração e a versão original do modelo consiste em 7 camadas(COMMISSION et al., 1994).

O conceito de camadas baseia-se no artifício de que cada camada desempenha umafunção específica, sendo amparada pela camada que está logo abaixo e oferecendo suportepara a camada superior. Para isto, é necessário definir a atribuição de cada camadae sua aplicabilidade, protocolos de camada relacionados à armazenamento de dados ecomunicação interna e externa com outras camadas. Após a definição das múltiplascamadas, ocorrerá uma partição entre o software e hardware em módulos, cada um comuma incumbência na execução do software. O Modelo OSI utiliza uma pilha de camadasda seguinte forma (BRISCOE, 2000):

Camada 7: Camada de aplicação

É a camada que o usuário pode interagir diretamente através de um software queimplemente um componente de comunicação, já é considerado uma abstração de todo osistema. Como funcionalidades que podem ser implementadas, pode-se citar a identifica-ção de parceiros de comunicação, sincronização e disponibilidade de rede.


Camada 6: Camada de apresentação

A camada de Apresentação estabalece a comunicação entre aplicações que utilizema camada superior, as quais podem utilizar sintaxes e semântica diferentes originadasde linguagens de programação distintas. Esta camada torna a representação de dadosindependente da aplicação utilizada e do formato da rede, ou seja, de grosso modo estacamada trabalha como um tradutor dos dados disponíveis na rede.

Camada 5: Camada de sessão

Esta seção é encarregada de gerenciar as conexões entre os dispositivos conectados narede. Tem como funcionalidades a capacidade de iniciar, gerenciar e finalizar conexõesentre aplicações remotas e locais. As conexões gerenciadas por esta camada podem serdo tipo full-duplex ou half-duplex, além de implementar procedimentos responsáveis porreiniciar a comunicação em caso de falhas. Esta camada é amplamente implementadaem sistemas que fazem uso de chamadas remotas procedurais, ou seja, que executamaplicações em dispositivos conectados à uma rede compartilhada.

Camada 4: Camada de transporte

Nesta camada é onde são fornecidos as aplicabilidades procedurais e funcionais para ex-pedir mensagens de tamanho variável de um remetente para um destinatário, servindo-sede funcionalidades da camada inferior e de diversas redes, sempre prezando pela qualidadede serviço. A confiabilidade da transmissão de dados é gerada nesta camada, onde tem-secontrole de fluxo e detecção de erros; desta maneira, é possível que essa camada detecteerros de transmissão e seja capaz de retransmitir os pacotes que estiverem erros.

Camada 3: Camada de rede

É a camada responsável por fornecer os métodos procedurais e funcionais para atranferência de uma sequência de dados, os chamados datagramas, entre diferentes nósconectados à diferentes redes. O conceito de rede é definido como o meio no qual diversosnós, cada um com um endereço especifíco, se conectam e podem transferir mensagenscontendo o endereço do nó de destino e o conteúdo da mensagem. A entrega de mensagensnão é garantida pela camada de rede, esta função deve ser implementada pela camadasuperior.

Camada 2: Camada de enlace de dados

Nesta camada é responsável pela conexão de dois nós diretamente conectados, tambémé implementada à correção de erros de comunicação que podem ocorrer na camada infe-


rior, a camada física. Esta camada define protocolos capazes de estabelescer e terminarcomunicações entre dispositivos conectados.

Camada 1: Camada física

Esta camada é onde são especificadas as necessidades elétricas e físicas para a comu-nicação de dados. São definidos o meio de comunicação, seja utilização de cabos de partrançado, fibras óticas ou transmissão via rádio-frequência; também são definidos a taxade bit que poderá ser utilizada; os modos de transmissão implementados: half-duplex oufull-duplex; e a tolopogia da rede: mesh, barramento, anel ou estrela para citar as maiscomuns.

2.4 Protocolo de Comunicação TCP/IP

A pilha de procotocolos TCP/IP é derivada de dois protocolos de comunicação entrecomputadores: a protocolo TCP (Transmission Control Protocol - Protocolo de Controlede Transmissão) e o protocolo IP (Internet Protocol - Protocolo de Internet). O TCP/IPsegue o Modelo OSI, ou seja é baseado em diversas camadas, onde cada uma destas éresponsável por tarefas específicas e fornecer funcionalidades para as camadas superiores(FERREIRA, 2008).

O Centro de Pesquisas Avançadas do Departamento de Defesa dos Estados Unidosé responsável pelo desenvolvimento do projeto ARPANET - Advanced Research ProjectAgency Network em 1969, e dentro deste surgiu como uma funcionalidade o protocoloTCP/IP, responsável por facilitar a comunicação entre sistemas de inúmeros computadorese, principalmente, órgãos governamentais na época (BIDGOLI, 2004). O protocolo decomunicação tinha como objetivo determinar a melhor rota possível, disponibilizandotransmissões de dados em alta velocidade através da permuta de pacotes; e, segundo osdesenvolvedores do protocolo, o interesse era desenvolver um sistema de comutação depacotes adaptativos distribuídos que fosse capaz de continuar ativo mesmo em caso deuma guerra nuclear (BARAN, 1964).

Dada estas características e a confiabilidade da rede já desenvolvida, o projeto ARPA-NET passou a expandir-se para a comunidade científica. Em 1973, um grupo de pesqui-sas em redes de comunicação da Universidade de Stanford começou a trabalhar em ideiaspara a especificação do protocolo TCP/IP. Posteriormente, numa associação formada pelaUniversity College London - (UCL) e a Universidade de Stanford, foram desenvolvidasdiversas versões do protocolo TCP/IP para lidar com distintas arquiteturas de hardware:TCP v1, v2 TCP, TCP v3 e v3 IP e TCP/IP v4; sendo que a última versão segue em uso.Em 1975 foi realizada um teste conectando as redes TCP/IP de ambas as universidades(REISSWITZ, 2009). Após a adoção do protocolo TCP/IP, o Departamento de Defesa


dos Estados Unidos da América definiu, em 1982, este como o padrão que deveria serutilizado em todas as redes de computadores militares (HAUBEN, 2001).

O protocolo TCP/IP, por fim, acabou tornando-se indispensável para redes de comuni-cação; e desta maneira, tornou-se rotineiro que desenvolvedores de sistemas operacionaisfizessem um grande esforço para fornecer implementações do protocolo TCP/IP em umestado ótimo, tornando seu desempenho superior à outros protocolos. Podem ser citadoscomo benefícios oferecidos pelo protocolo TCP/IP:

• Fornecimento de internet: redes locais fornecem servidores de acesso a internete clientes locais realizam uma conexão à estes servidores, através do endereço de IP;obtendo acesso a internet;

• Roteamento: permite que dispositivos utilizando quaisquer tecnologia, seja ummodelo antigo de implementação ou um mais atual, se conectem à internet de formasemelhante; além de permitir conexões em linhas dedicadas;

• Interconectividade: permite conectar diferentes sistemas, utilizando tecnologiasdistintas. Por exemplo, estabelecer uma conexão entre um microcontrolador de 8bits e um servidor de 64 bits;

• Robustez: proporciona uso em multiplataforma, estrutura cliente/servidor e esca-labilidade;

• Padronização: por ser amplamente utilizado, em todos os tipos de aplicações,diversos sistemas fornecem suporte ao protocolo TCP/IP.

2.5 Framework .NETNa década de 1990, a Microsoft Corporation possuia uma enorme variedade de lingua-

gens de programação e tecnologias, as quais eram empregadas para diversas aplicações.Porém, esta grande variedade, por vezes, apresentava-se mais como um revés do que comoum benefício aos desenvolvedores. Ao empregar-se uma nova linguagem, era necessárioaprender e familiarizar-se com um novo leque de estruturação de linguagem, conceitos,bibliotecas e APIs.

Em um primeiro momento, para solucionar o empasse desta curva de aprendizado, aMicrosoft Corporation decidiu utilizar a linguagem Java. Esta liguagem é interessantepois já era bastante adotada pela comunidade, possuindo abundantes bibliotecas; alémde ser independente do ambiente de execução. Porém, apesar destas qualidades notadasa priori, a comunicação entre o Java e códigos de máquina implementados pela MicrosoftCorporation não funcionava como esperado. Desta maneira, foi tomada a decisão de criaruma nova plataforma que a empresa pudesse utilizar.


Sendo assim, no fim dos anos 90, o framework .NET surge como um ambiente de de-senvolvimento pensado para integrar diversas linguagens de programação, compartilhadoum mesmo conjunto de bibliotecas (CAELUM, 2016). Após a criação de um ambiente deprogramação, surgiu a necessidade de desenvolver-se também uma linguagem de progra-mação propria da empresa; então, baseado em linguagens já existentes como Delphi, C,C++, e Java, em 2002 foi lançada ao mercado a linguagem C#.

O framework .NET auxiliou na expansão de toda a plataforma .NET, de forma quefoi possível alcançar diversos dispositivos desde celulares, extensões para navegadores deinternet, sistemas embarcados e sistemas operacionais alternativos. Também há versõescompactas, o .NET Compact Framework e .NET Micro Framework, que são capazes derodar em sistemas com poucos recursos disponíveis.

2.5.1 Linguagem C#

No ano de 2002, a Microsoft lançou o projeto COOL (C-Like Object Oriented Lan-guage) e desta maneira surge a versão 1.0 da linguagem C#. Esta linguagem foi projetadapara ser simples e moderna, além de ser genérica o suficiente para atender múltiplos pro-pósitos. Também foram aplicados conceitos da engenharia de software como detecçãode uso de variáveis não-iniciadas, verificação automática de tamanho de vetores, fortetipagem de variáveis e gerenciador de alocação e liberação de memória. (DIETRICH;SMACCHIA, 2017).

Seguindo os preceitos da linguagem Java, esta linguagem foi idealizada para que seusprodutos sejam executados de forma independente ao ambiente. Outra característicaimportante é a portabilidade de código que foi fornecida à programadores, de formaque seja fácil reutilizar códigos fonte de linguagens como C e C++. Desta maneira,foi possível alcançar uma grande portabilidade da linguagem, de forma que é possívelencontrar aplicações rodando em pequenos sistemas embarcados, como o Raspberry Pi,até em grandes servidores que utilizam sistemas operacionais sofisticados. A partir destacaracterísticas, pode-se concluir que esta linguagem necessite ser eficiente e econômica comos recursos utilizados, tanto em questões de memória quanto em poder de processamento.

Após tantas semelhanças com a linguagem Java, a linguagem C# foi acusada, peloscriadores da linguagem Java e da Sun Microsystems, de ser apenas uma cópia barata emal feita. Porém, a partir do lançamento da versão 2.0 do C# em 2005, pode-se perceberque ambas as linguagens tomaram rumos distintos. Podemos destacar como melhoriasimplementadas no C# a inclusão de métodos genéricos, geração de código em tempo decarregamento de classe e principalmente a adição de consulta integrada à linguagem, doinglês Language Integrated Query (LINQ) que permite a realização de buscas em diferentesfontes e bancos de dados, além de permitir tipos anônimos e expressões lambda. EmAgosto de 2017, foi lançada a versão 7.1 da linguagem C# e a versão 4.6.2 do Framework


.NET, sendo estas as mais recentes (DIETRICH; SMACCHIA, 2017).

2.5.2 Compilação e Execução

Em linguagens de programação como C, muitas vezes o código fonte é projetado parauma plataforma específica, e desta maneira, o compilador trabalha convertendo códigofonte para o código de máquina particular desta arquitetura. Após o código fonte ser com-pilado, o arquivo binário resultante será executado diretamente pelo sistema operacional.Nestes casos, por ser um projeto realizado apenas para aquela arquitetura, a execução pelosistema operacional ocorre sem maiores problemas; porém isto acaba gerando um códigoexecutável para cada arquitetura e sistema operacional diferentes (CAELUM, 2016).

Assim como na linguagem Java, para a execução de um código em C# é necessárioa utilização de uma máquina virtual. Pode-se definir o conceito de uma máquina virtualcomo um computador de mentira rodando dentro do mesmo sistema operacional e capazde realizar todas as funções de um computador: pilha de execução, tarefas paralelas ouconcorrentes, segurança, gerenciamento de memória e etc.

O processo de funcionamento de linguagens de programação que utilizam máquinasvirtuais para execução, consiste em compilar o código original em um código intermediá-rio, no chamado tempo de compilação, e, no tempo de execução, este código intermediárioserá transformado em um código nativo, ou código de máquina, específico para o proces-sador/arquitetura que está sendo utilizado (RAHMAN, 2014).

A máquina virtual de todas as linguagens do Framework .Net, incluindo o C#, é aCommom Language Runtine (CLR); e, por ser necessário lidar com uma grande quanti-dade de linguagems, para a compilação e execução do código fonte também é necessárioo uso da Common Intermediate Language (CLI) que é responsável por traduzir todas aslinguagens da plataforma para uma linguagem intermediária comum à todas de forma quea máquina virtual seja capaz de executar o código.

2.6 JSON - JavaScript Object Notation

A Notação de Objetos Javascript é uma formatação leve para troca de dados entresistemas que tem como grande vantagem a fácil legibilidade para humanos de forma queé possível tomar conhecimento de quais os dados contidos no arquivo de forma rápida.Os arquivos JSON são considerados uma formatação de dados independente derivada dalinguagem de programação interpretada JavaScript; e, atualmente, diversas linguagens deprogramação começaram a implantar suporte à este tipo de arquivos de forma que sejapossível analisar e gerar arquivos com a extensão *.json (ECMA INTERNATIONAL,2013).


O JSON surge como uma alternativa aos arquivos XML - eXtensible Markup Language,uma lingugagem de marcação muito utilizada para descrever diversos tipos de dados epara compartilhar arquivos na internet, carregando consigo como vantagem a grande faci-lidade de é preferível e muito mais simples escrever um analisador JSON em comparaçãoà um analisador XML, além de que a grande maioria dos navegadores de internet é ca-paz de interpretear arquivos JSON (CROCKFORD, 2006). Este tipo de arquivos sãoamplamente utilizados em casos onde ocorre uma grande necessidade de uma alta taxade transmissão de dados entre usuário e servidor, como em aplicações do Google Maps(NURSEITOV et al., 2009).

Dentro de um arquivo JSON, podemos encontrar duas estruturas: objetos, que formamuma coleção de pares nome/valor; e vetores que consistem em uma lista ordenada devalores de modo a formar uma sequência. Esta estrutura é inerente à linguagem deprogramação que deveará interpretar o arquivo de modo que seja possivel realizar umatransferência de arquivos entre diferentes linguagens (BRAY, 2014). No trecho de códigodescrito no Apêndice A, é possível analisar a formatação e como é organizado um arquivoJSON; neste exempo pode-se verificar como as duas estruturas supracitadas podem sercombinadas para armazenar dados conforme o desejado.

2.7 Verificação Cíclica de Redundância

Em sistemas de comunicação, para uma melhora no desempenho, eficiência e qualidadeda comunicação, são implementadas formas de codificação que utilizam-se de detecção ecorreção de erros. Sistemas de comunicação, sejam sem fio ou cabeados, estão sujeitos àinterferências recorrentes da característica ruidosa do ambiente que as permeia e do canalde comunicação utilizado. Existem diversas situações em que estes ruídos prejudicam atransmissão de dados, diminuindo a qualidade da recepção de sinal, à ponto de perder oualterar-se bits à ponto de inutilizar a informação (SILVA et al., ). Durante transmissões dedados podem ocorrer erros indesejáveis causados por diversas razões como: defeitos noscomponentes dos circuitos de recepção e transmissão, falha de sincronização entre recep-tor e transmissor ou até ruídos eletromagnéticos. Um dos requisitos fundamentais paracomunicação de dados é uma transmissão sem erros, portanto diversos métodos devemsem implementados para detectar e corrigir possíveis erros (GIOZZA et al., 1985). Hádiversos grupos de estudos focados em pesquisar métodos capazes de reduzir a influênciado ruído; um destes métodos consiste em codificar o canal de comunicação. A codificaçãode canal consiste em adicionar bits redundantes que tem como finalidade identificar, epossivelmente corrigir, erros na informação transmitida gerados por ruídos no canal decomunicação (LOYOLA-CAMORIM et al., 2010).

A codificação de canal pode ser clarificada como a divisão de um fluxo de bits emblocos de K bits, então deve-se mapear cada bloco de mensagem com uma palavra código


pré-determinada de M bits, fazendo M > L, de modo a criar uma proteção contra errosde bit. Posteriormente, para determinar se a mensagem foi recebida de maneira correta,deve-se remapear estes blocos e confrontar o valor transmitido com o valor recalculado; seambos forem iguais, pode-se assumir que a mensagem está correta. Há diversas topologiasde codificação, dentre as quais podemos citar Hamming, Linear e Cíclica.

A verificação cíclica dede redundância (do inglês Cyclic Redundancy Check - CRC)é um médodo de detecção de erros implementado em diversos tipos de comunicação earmazenamento de dados, de forma a encontrar mudanças inesperadas em um fluxo dedados; e é uma variação da codificação em blocos (TOGNERI; CHRISTOPHER, 2003).Neste tipo de codificação, nas mensagens de dados são adicionados bits de verificaçãooriundos do resto de uma divisão polinomial. No momento em que recebe-se uma novamensagem, esta divisão é recalculada, sem considerar os bits adicionais; e caso o valor deresto da divisão seja distinto ao enviado em conjunto à mensagem, é detectado um erronos dados transmitidos. Os divisores mais comuns utilizados são palavras de 17 ou 33 bits,que produzem restos de 16 ou 32 bits respectivamente. Para calcular a eficiência de umcódigo de detecção de erro, deve-se obter a porcentagem de erro que pode ser detectado;para um CRC de tamanho N, a taxa de erros não detectados é de 2−N (JACOB, 2017).

Há diversos algoritmos utilizados para o cálculo de CRCs, sendo que alguns des-tes tornaram-se padrões internacionais para tipos específicos de comunicação (TANEN-BAUM; WETHERALL, 2002). Para este trabalho será utilizado o código em linguagemC# apresentado no Apêndice B.

Deve-se atentar que o parâmetro passado para o método CRC_Calc é um vetor debytes; e conforme definido em sua classe, possui a propriedade Length que informa o ta-manho do vetor (MICROSOFT CORPORATION, 2017). E o valor retornado é do tipoushort que representa um valor inteiro sem sinal de 16 bits (MICROSOFT CORPORA-TION, 2016). Após uma inspeção do código, é possível perceber que o cálculo do CRCnão é realizado em todo o vetor, e sim nas posições de 1 à N-3; contemplando apenas oscampos de dados e deixando de lado os bytes de início e fim de mensagem, bem como ospróprios bytes de CRC como será explicado na Seção 3.6.

35

3 Metodologia

Este capítulo irá descrever a metodologia adotada para a implementação de um sistemasupervisório utilizando a linguagem de programação C#, o qual poderá comunicar-secom servidores de aplicação via comunicação serial cabeada ou rodando um servidorTCP/IP para monitoramento remoto. Para este trabalho, foi utilizado a IDE VisualStudio Community 2015, de modo que seja possível desenvolver projetos de software semcustos iniciais.

O propósito de cada seção deste capítulo é orientar uma sequência de passos a serseguida para que no fim, com o somatório de conhecimentos adquiridos, tenha-se a habi-lidade e conhecimento para desenvolver um sistema supervisório completo.

Todos os códigos utilizados neste capítulo e trabalho estarão armazenados na plata-forma de hospedagem de código GitHub através do link https://goo.gl/pJF26K, e serádistribuído sobre a licença MIT.

3.1 Criando um novo projeto utilizando Visual Stu-dio

Em um primeiro momento, ao iniciar o Visual Studio o usuário deve deparar-se coma seguinte tela inicial:

Figura 6 – Tela inicial do Visual Studio.

Fonte: Do autor.

Capítulo 3. Metodologia 36

Agora, para criar um novo projeto, é necessário utilizar os menus localizados no cantosuperior esquerdo seguindo a sequência: File -> New -> Project. Uma nova janeladeve surgir, mostrando os tipos de projetos que podem ser criados. A diversidade delinguagens de programação, tipos de projetos e plataformas que podem ser programadas,dependem de como foi realizada a instalação do software e pacotes de expansão. Nestetrabalho, será empregado um projeto clássico da plataforma Windows que é o WindowsForms Application.

Figura 7 – Tela para criação de um novo projeto.

Fonte: Do autor.

Conforme ilustrado na Figura 7, devemos selecionar no menu esquerdo a aba Templa-tes -> Visual C# e escolher o tipo de projeto, nesse caso Windows Forms Application.Na parte inferior desta janela, deve-se escolher o diretório onde o projeto será salvo tam-bém pode-se alterar o nome deste, neste caso para Sistema_Supervisorio. Para concluira criação do projeto, basta clicar em OK ; então o projeto será criado e aparecerá umatela conforme ilustrado na Figura 8 abaixo.


Figura 8 – Novo projeto criado no Visual Studio.

Fonte: Do autor.

A partir deste momento, é possível dar infinitas aplicações para o projeto criado comoacesso à banco de dados, páginas da internet, calculadoras e editores de texto. Como épossível notar, há uma grande versatilidade nas aplicações ao utilizar o Windows Forms,o que pode ser considerada um enorme benefício à toda comunidade desenvolvedora poiscada indivíduo pode direcionar o projeto para seus interesses específicos.

Para adicionar componentes visuais como botões e caixa de texto à partir da janelaToolbox localizada no canto esquedo da imagem, e ordenar conforme os critérios de designdeterminados. Esta é uma maneira simples e objetiva para iniciar aplicações com GUI,sem a necessidade de desenvolver códigos específicos para a inclusão de objetos.

Nas próximas seções serão apresentados conceitos e métodos para criar separadamentefuncionalidades necessárias para o projeto final como portas seriais, servidor TCP/IP, tra-tamento de mensagem e etc; de modo que ao final, seja possível unir estas funcionalidadese montar-se um sistema supervisório funcional.

3.2 Porta serial

Para demonstrar o funcionamento de uma porta serial será montado um simples sis-tema contendo os seguintes componentes do toolbox: Button, RichTextBox, Label e Com-boBox. Conforme citado anteriormente, para incluir componentes do toolbox na interface,basta selecionar o componente desejado no menu e arrastar para a posição em que se de-seja. Sendo assim; deve-se montrar uma interface da seguinte maneira:


Figura 9 – Criação da interface para demonstração do uso da porta serial.

Fonte: Do autor.

Conforme pode-se perceber, os elementos não estão ajustados de forma coerente eamigável ao usuário; portanto, é interessante alterar o tamanho e organização dos com-ponentes para obter-se uma melhor organização. Ao dar um clique em um componente,este é selecionado e surgem pontos que permitem arrastar e alterar a forma e tamanho docomponente; para demonstrar isto, utiliza-se um RichTextBox como exemplo na Figura10 abaixo:

Figura 10 – Demonstração de um RichTextBox selecionado.

Fonte: Do autor.

Ao clicar em algum destes pontos, é possível redimensionar o componente. Apósrealizar o mesmo com todos os componentes na interface, a disposição destes deve estarsemelhante à ilustrada na Figura 11 abaixo:


Figura 11 – Alteração da interface.

Fonte: Do autor.

Agora, é necessário alterar os textos de exibição de cada componente. Para isto, bastaclicar com o botão esquerdo em cima de um componente com o botão esquerdo do mousee selecionar Properties que uma aba no lado direito irá aparecer. Nesta janela, é possívelalterar inúmeras configurações de cada componente como: cor, nome, texto, alinhamentodo texto e etc. Para alterar o texto que é exibido em cada componente utiliza-se aconfiguração Text. As configurações devem ser alteradas conforme a Tabela 1 abaixo.

Tabela 1 – Configuração dos componentes.

Componente Propriedades Valorlabel1 Text Porta:label2 Text Baudrate:label3 Text Mensagens:label4 Text Enviar Mensagem:button1 Text Abrir Portabutton2 Text Enviar

Fonte: Do autor.

Após alterar todos os componentes necessários a interface deve estar semelhante àexibida na Figura 12 abaixo.


Figura 12 – Interface após alteração dos textos de exibição dos componentes.

Fonte: Do autor.

Agora, devemos incluir quais serão os baudrate disponíveis para uso. Então, é neces-sário abrir as propriedades do ComboBox2 e procurar por Items conforme ilustrado naFigura 13 abaixo.

Figura 13 – Propriedades do componente ComboBox2.

Fonte: Do autor.

Para poder incluir itens, deve-se clicar no botão que contém 3 pontos e uma nova janelaserá aberta. Nesta nova janela, cada um dos baudrates deve ser incluído em uma novalinha. Para este projeto serão utilizados os valores mais comuns no mercado, partindo de110 e indo até 256000. Os dados devem estar dispostos na janela conforme mostrado naFigura 14 abaixo.


Figura 14 – Incluindo valores de baudrate no componente ComboBox2.

Fonte: Do autor.

Após realizar essas configurações no componente ComboBox2, ao compilar e executaro programa, estes valores de baudrate estarão disponíveis para seleção e irão configurara porta serial a ser utilizada. Agora é necessário criar os métodos que irão rodar emsegundo plano para procurar portas seriais e executar ações quando for necessário receberou enviar mensagens. Primeiramente, devemos acessar a página que fornece o código dosoftware; para isto basta pressionar F7, agora é possível escrever todo o código necessáriodo software. A primeira coisa que deve ser feita é adicionar no início do código o namespaceSystem.IO.Ports que permite acessar classes para controle de portas seriais. Depois deutilizar esta diretiva, pode-se adicionar um objeto do tipo SerialPort que iremos nomearde PortaSerial, a qual nos permite criar portas e suas características. Portanto, o códigoque deve ser adicionado é descrito no Apêndice C.1.

Como podemos perceber, no código apresentado foi utilizada a expressão try...catch... que é utilizada para tratar exceções e erros inesperados. O tratamento doerro deve ocorrer dentro do catch... e neste caso apenas iremos exibir uma mensagemde que ocorreu um erro.

Analisando o código, percebe-se que sua execução não é requisitada em nenhum mo-mento, ou seja, ele não é executado pela aplicação. Então, deve-se determinar os mo-mentos em que este método deve ser chamado; dois instantes são interessantes para aexecução: quando o software é carregado e utilizando um timer para o método ser execu-tado periodicamente. Para adicionar um método que executa quando é carregado, bastadar dois cliques com o botão direito no fundo da interface gráfica; será criado um método


chamado Form1_Load() e chamar a função Buscar_Porta_Serial() dentro dela; ficandoda seguinte forma:

1 private void Form1_Load( object sender , EventArgs e )2 3 Buscar_Porta_Serial ( ) ;4

Utilizando o código acima, ocorrerá uma busca pelas portas seriais quando o programacarregar para execução. O próximo passo é criar um timer para procurar por portasperiodicamente; para isto deve-se incluir o namespace System.Timers e adicionar no corpoprincipal do projeto o código do Apêndice C.2.

Também é necessário incluir este código dentro da função Form1() para criar o métodoque lida com o evento do timer:

1 genera l_t imer . Elapsed += General_timer_Handler ;2 genera l_t imer . S ta r t ( ) ;

Após incluir estes trechos de código, o método Buscar_Porta_Serial() será executadoquando o programa carregar para execução e periodicamente à cada segundo enquanto àporta serial estiver fechada. O próximo passo consiste em incluir os métodos que lidamcom os eventos de clique nos botões. O Visual Studio é muito intuitivo na criação destesmétodos, basta clicar duas vezes com o botão direito do mouse em cima do botão que sedeseja criar o método; portanto, após realizar esta ação para os componentes button1 ebutton2 serão criados dois métodos distintos, então deve-se desenvolver as funcionalida-des a serem executadas quando as ações de clique nos botões ocorrerem. O código dasfuncionalidades implementadas está disponível no Apêndice C.3.

Com os métodos implmentador, o software que foi desenvolvido é capaz de abrir efechar uma porta serial à partir de parâmetros que são selecionados usando ComboBox,e também envia os dados inseridos pela porta serial em formato ASCII. Como pode-severificar, na linha 24 do método button1_Click é criado uma função do tipo SerialDa-taReceivedEventHandler que é responsável por lidar com os dados recebidos pela portaserial; para um melhor entendimento, é possível dizer que este método é análogo à umainterrupção da USART em microcontroladores. Porém, este método não foi implemen-tado, isto significa que o software não é capaz de lidar com as mensagens recebidas; parasolucionar este problema deve-se adicionar o método do Apêndice C.4.

No código, é possível perceber que foram utilizados dois métodos a mais, um delegateque é uma referência para um método, ou seja, funciona como um ponteiro na linguagemC; e o método Append_Text para escrever em um RichTextBox genérico. O uso destaestrutura é necessário pois a linguagem C# não permite que um objeto criado em umalinha de execução ( tread ) seja acessado diretamente por outra tread; tal metodologia éimplementada para evitar que códigos mal planejados não influenciem na estrutura comoum todo, então ao utilizar delegates torna segura essa chamada de operações entre threadsdistintas. É importante salientar que um delegate só pode chamar funções que tenham o


mesmo parâmetro dele, neste caso (RichTextBox textbox, string text). Na Figura 15 abaixopode-se verificar a interface final do software, bem como uma mensagem transmitida (TX)e outra recebida (RX).

Figura 15 – Software desenvolvido nesta seção, incluindo mensagens transmitida e rece-bida.

Fonte: Do autor.

3.3 Servidor TCP/IP

Assim como feito para demonstrar o uso de portas seriais, será feito um software sim-ples para envio e recebimento de mensagens através da do protocolo TCP/IP. Conformeo Capítulo 2.4

Conforme feito na Seção 3.2, antes de desenvolver qualquer linha de código, é ne-cessário definir uma interface gráfica para o usuário; desta maneira, após criar-se umnovo projeto nomeado como TCP_Serve_Exemple, deve-se organizar a interface visualdo Form1 utilizando o toolbox disponível conforme ilustrado na Figura 16 abaixo.


Figura 16 – Organização da interface gráfica para o usuário para o software de demons-tração de um servidor TCP/IP.

Fonte: Do autor.

Uma vez organizada a interface, o próximo passo deve ser renomear os labels e botõespara que seja possível entender a funcionalidade de cada parte do software. Para tal,deve-se renomear cada componente conforme a Tabela 2 abaixo.

Tabela 2 – Configuração dos componentes para o software de demonstração de um servi-dor TCP/IP..

Componente Propriedades Valorlabel1 Text IP:label2 Text Porta:label3 Text Mensagens:label4 Text Enviar Mensagem:button1 Text Abrir Servidorbutton2 Text Enviar

Fonte: Do autor.

Após realizadas estas alterações, o interface gráfica deve estar disposta conforme ilus-trado na Figura 17 abaixo.


Figura 17 – Interface gráfica para o usuário para o software de demonstração de um ser-vidor TCP/IP após renomear os componentes.

Fonte: Do autor.

Para que seja possível abrir um servidor TCP/IP apto à receber conexões de clientesremotos é necessário definir o endereço de rede do servidor, ou seja um IP, e tambémuma porta na qual deve ocorrer a conexão. É importante destacar que para que hajasucesso na abertura do servidor, é necessário que a porta a ser utilizada para a conexãoesteja configurada e liberada no modem de internet; cada modem tem um procedimentoespecífico para configurar portas de modo que fiquem disponíveis para acesso TCP/IPe este procedimento pode ser encontrado no manual do fabricante. Tendo estes fatoresem mente, para facilidade de uso do usuário, é necessário desenvolver um código que sejacapaz de encontrar o IP da máquina utilizada automaticamente; para tal tarefa devem serincluídas as bibliotecas, variáveis e métodos necessários para executar esta funcionalidade.O código desenvolvido está disponível no Apêndice C.5.

Percebe-se, novamente, o uso das instruções try.. catch...; utilizar esta instruçãoem métodos que possam gerar possíveis exceções de código é importante para que, casoocorra uma exceção, a execução do software não seja interrompida. Agora é necessáriodeterminar em qual momento este código será executado; como só é necessário determinaro IP uma vez, este método será executado durante o carregamento do software. Para queo software seja executado neste momento deve-se acessar o método Form1_Load(...), oque pode ser feito ao clicar duas vezes no fundo da janela do software; após realizar estaação, será criado o método Form1_Load(...) e deve-se incluir uma chamada invocando ométodo Encontrar_IP() conforme mostrado abaixo.


1 private void Form1_Load( object sender , EventArgs e )2 3 Encontrar_IP ( ) ;4

O próximo passo é desenvolver um método que irá abrir o servidor TCP/IP, paraisto será utilizado a classe TcpListener que fornece meios simples para ouvir e aceitarnovas conexões. Este método será executado quando ocorrer um clique no botão, entãoa coerência é chamar este método do evento de clique do botão; então, conforme feitoanteriormente, deve-se clicar duas vezes no botão desejado para criar o método responsávelpor lidar com o evento de clique e adicionar o seguinte código do Apêndice C.6.

No código descrito, pode-se notar o uso novamente de um método delegate e do métodoAppend_Text para seja possível adicionar texto a um RichTextBox. Também é utilizado ométodo BeginAcceptTcpClient na linha 30, este é responsável por executar uma operaçãoassíncrona para aguardar a conexão de um cliente TCP. Os parâmetros necessários paraeste método são um callback da função que realiza a aceitação do cliente e um objeto queserve como parâmetro para o callback, que neste caso é a variável servidorTCP do tipoTcpListener. Com este código implementado, o software ficará aguardando a conexão deum cliente, porém não existe nenhum callback responsável por lidar com a aceitação docliente e nem com mensagens recebidas. Então, é necessário adicionar as duas funções decallback conforme o Apêndice C.7.

Com o código utilizado, o software agora é capaz de aceitar a conexão remota de umcliente e criar uma instância de TcpClient para manipular o cliente remoto. Também foiadicionado o método BeginRead que utiliza um callback para leitura assíncrona da streamde dados enviados pelo cliente. No callback Callback_LerCliente é analisado se o clienteestá conectado antes de abrir-se a stream de dados e após isto, utiliza-se de um laço derepetição while para aguardar que dados sejam enviados. Quando uma mensagem forrecebida pelo servidor, esta será exibida no RichTextBox1.

Para completar as funcionalidades do servidor, é necessário implementar o envio demensagens para o cliente; para esta funcionalidade será utilizado o evento de clique nobutton2 que é gerado ao clicar duas vezes em cima do botão na aba de design, foi desen-volvido o código do Apêndice C.8.

Após a implementação de todos este métodos, o servidor está à pleno funcionamento,sendo capaz de receber e transmitir mensagens utilizando o protocolo TCP/IP. Para rea-lizar o teste de comunicação, utilizou-se o aplicativo TCP UDP Terminal desenvolvidopela empresa NEXT PROTOTYPES para smartphones android e está disponível gratui-tamente na loja de aplicativos do Google, a Play Store (NEXT PROTOTYPES, 2016).Primeiramente, o aplicativo foi configurado para trabalhar como um cliente TCP confomeilustrado na Figura 18 abaixo.


Figura 18 – Configuração do aplicativo TCP UDP Terminal como cliente TCP.

Fonte: Do autor.

No campo IP deve ser inserido o IP externo da máquina que irá executar a aplicação doservidor TCP. Após realizar esta configuração, deve-se retornar a tela inicial do aplicativo.

Por fim, deve-se executar o software desenvolvido nesta seção e abrir o servidor. Então,o aplicativo buscará se conectar como cliente automaticamente a partir do momentoem que encontrar o servidor aberto; e após concluída a conexão, é possível enviar ereceber mensagens em ambos os dispositivos. As Figuras 19 e 20 mostram um exemplode comunicação entre o aplicativo e o servidor, respectivamente.


Figura 19 – Demonstração da comunicação entre cliente e servidor mostrados na tela doaplicativo TCP UDP Terminal.

Fonte: Do autor.

Figura 20 – Demonstração da comunicação entre servidor e cliente mostrados na interfacegráfica do software desenvolvido.

Fonte: Do autor.


3.4 Tratamento de mensagens

Nesta seção será demonstrado uma das das inúmeras maneiras de tratar uma mensa-gem recebida ou enviada; isto é, determinar se uma mensagem é válida para o protocoloutilizado, analisar cada índice da mensagem para uma determinada finalidade ou alterar aformatação da mensagem para uma notação específica como o JSON, por exemplo. Paraabreviar o tempo de desenvolvimento do software desta seção, assume-se que o leitor játem o conhecimento básico para desenvolver um software que seja capaz de se comunicarcom um periférico externo, seja via comunicação serial como descrito na Seção 3.2 ouutilizando um servidor que utilize o protocolo TCP/IP como descrito na Seção 3.3. Ousuário deve sentir-se livre para escolher qual a opção que lhe seja mais cômoda, porémpara encurtar o desenvolvimento será utilizado o mesmo software da Seção 3.2.

Tomando como base o software Serial_Port_Example, no qual ao receber uma men-sagem através da prota serial é disparado um evento e a mensagem recebida é exibidana tela sem qualquer validação ou análise de protocolo. Agora, será demonstrado comoanalisar a informação recebida, adicionar a data e hora em que a mensagem foi rece-bida; para isto será criado um método que realizará estas tarefas e exibirá o resultado natela, este método deve ser chamado dentro da função de evento de mensagem recebidaPortaSerial_DataReceivedHandler. Para este exemplo, para determinar se a mensagem éválida, será analisado os bytes de início e fim de mensagem estão corretos; será conside-rado 0x0A como início de mensagem e 0xA0 como fim de mensagem. O código do métodoTratar_Mensagem está descrito no Apêndice C.9.

O método implementado, deve ser invocado dentro da função PortaSerial_DataReceivedHandlere como parâmetro deve ser utilizado o vetor ’recebido’.

No código, pode-se analisar o uso da estrutura de dados DateTime; que é implemen-tada pela Microsoft para representar o tempo de forma instantânea, usualmente expressoem forma de data e hora do dia. Esta estrutura pode ser utilizada para adquirir a horado sistema e informar ao usuário o instante em que determinados eventos ocorrem.

A partir da linha 22 do código, pode-se analisar uma das inúmeras formas de validaçãode um protocolo de comunicação. Após receber a mensagem por completo, deve-se pri-meiramente analisar se os bytes de início e fim de mensagem estão corretos e depois entãodeve ser realizada uma verificação de todos os campos definidos do protocolo como CRC,emissor de mensagem, comandos e etc. Para este exemplo, foi utilizado apenas bytes deinício e fim de mensagem apenas para exemplificar como deve ser realizada a análise dopacote de dados.

Para a conversão da mensagem recebida, foi utilizada a classe BitConverter que foiprojetada para converter vetores de bytes para vetores de outros formatos como ASCIIou UInt64_t. O uso desta classe se faz importante para tornar a mensagem legível parao usuário, pois de os dados fossem convertidos de forma direta para string utilizando o


método byte.ToString() a mensagem seria convertida diretamente para ASCII, por exem-plo o valor hexadecimal 0x30 seria convertido para ’0’, 0x41 se torna ’A’ e 0x00 se torna’NUL’ segundo a tabela de conversão ASCII. Então, para que o usuário possa analisar amensagem de forma simples, esta classe retorna a impressão direta do valor, como exem-plo 0x30 se torna 30, 0x41 é retornado como 41 e 0x00 retorna como 00. Desta maneiraa mensagem pode ser analisada sem maiores complicações.

Após a compilação do código e execução do programa, ao receber duas mensagems,uma inválida e outra correta,o software irá se comportar conforme ilustrado na Figura 21abaixo.

Figura 21 – Demonstração de como o software se comportar após a introdução do métodode análise de mensagem.

Fonte: Do autor.

3.5 Salvar arquivos

Nesta seção serão demonstrados duas diferentes formas de salvar arquivos através daplataforma .NET : a primeira salvando a caixa de texto do LOG como um todo ao clicar-seem um botão, e a segunda salvando as mensagens automaticamente em formato JSONassim que estas chegarem pela porta serial. Para cada uma destas forma de salvar-se umarquivo, será criado um método distinto para que seja possível chamar a execução destesem qualquer ponto do código. De modo a facilitar o desenvolvimento será reutilizado osoftware desenvolvido na Seção 3.4.


Primeiro será desenvolvido o método para salvar o LOG exibido na tela de formacompleta, primeiramente deve-se adicionar um novo botão utilizando a tela de design.Então, para que seja de fácil entendimento para o usuário, deve-se alterar o text do botãopara Salvar LOG. Então, deve-se clicar duas vezes para que o Visual Studio crie afunção que trata o evento de clique no botão; e posteriormente deve-se adicionar o códigoque se deseja executar quando o usúario clicar no botão para salvar o LOG, conformedemonstrado no Apêndice C.10.

Através deste código, quando o usuário clicar no botão para salvar o LOG, será criadauma nova janela que permite o usuário escolher onde o arquivo deve ser salvo. O arquivojá terá um nome padrão no formado "AA-MM-DD", ou seja, indicando o ano, mês e diarespectivamente, em que o arquivo está sendo salvo. Logicamente, o nome do arquivopode ser alterado à desejo do usuário. O arquivo terá como tipo padrão "*.txt", de formaque seja possível abrir e analisar o arquivo em qualquer editor de texto simples, com oBloco de Notas nativo da plataforma Windows.

Desta forma, foi demonstrado como salvar um arquivo quando o usuário desejar eonde ele escolher. Agora, será demonstrado uma forma distinta que, em vez de criarum novo arquivo, apenas irá adicionar mais informações à um arquivo já existente. Serácriado um método que, ao receber mensagens através da porta serial, irá adicionar novasinformações ao arquivo. As mensagens serão manipuladas para adequarem-se ao formatoJSON, de forma que, se desejado, seja possível ler este tipo de arquivo através de umsoftware específico e adquirir-se as informações de todas as mensagens já recebidas.

Para a criação de um arquivo formatado como JSON será utilizado o package New-tonsoft, uma biblioteca de código livre que é amplamente utilizada em conjunto comdiversas linguagens de programação, inclusive o C#. Para salvar as informações da ma-neira desejada será necessário criar uma nova classe de dados contendo duas strings, queserão utilizadas para salvar a data e hora em que a mensagem foi recebida, e um vetorde bytes que armazenará a mensagem recebida. A biblioteca Newtonsoft não é inclusapor padrão no Visual Studio, portanto é necessário instalá-la através do gerenciador debibliotecas da plataforma .NET, o Nuget. A grande importância deste gerenciador é queele se encarrega de manter as bibliotecas atualizadas em conjunto com a última versãodisponibilizada pelo desenvolvedor. Para abrir o Nuget é necessário acessar o menu Pro-ject na barra superior do Visual Studio e clicar em "Manage Nuget Packages" conformeilustra a Figura 22 abaixo.


Figura 22 – Abrindo o gerenciador de bibliotecas Nuget.

Fonte: Do autor.

Após clicar em "Manage Nuget Packages" a janela de exibição será alterada e ficarásemelhante à exibida na Figura 23 abaixo.

Figura 23 – Gerenciador de bibliotecas Nuget.

Fonte: Do autor.

Então, no campo de busca deve-se digitar Newtonsoft e dar OK. Será criado uma


lista de resultados ordenadas pelo número de downloads, o primeiro deve ser selecionadoe instalado conforme a Figura 24. Após clicar em Install, o próprio Visual Studio emconjunto com o Nuget se encarregam de instalar a biblioteca da forma correta.

Figura 24 – Instalando a biblioteca Newtonsoft.

Fonte: Do autor.

Uma vez tendo instalado a biblioteca, basta adicioná-la ao código utilizando a diretivausing. Agora, para demonstrar a criação da classe de dados desejada e para adicionar abiblioteca Newtonsoft, deve-se utilizar o código do Apêndice C.10.

Analisando o código, percebe-se que as strings Data e Hora são preenchidas com a datae hora no momento em que a variável é criada; e a string msg_recebida tem como conteúdoa mensagem recebida convertida de um vetor de bytes para valores ASCII da mesma formaque feito no método Tratar_Mensagem. Agora é necessário criar o método responsávelpor converter a variável do tipo Mensagem para JSON e salvar em um arquivo do tipo"*.txt"que pode ser interpretado posteriormente. O parâmetro de entrada da função deveser uma string, no qual deverá ser passado a mensagem recebida já convertida para ASCII;no Apêndice ??pode-se verificar a implementação do método Criar_Arquivo_JSON.

No desenvolvimento realizado, são utilizadas novas classes que são determinantes parao funcionamento do código como Path, Directory e StreamWriter, todas pertencentes àbiblioteca System.IO que contém classes, tipos e métodos que permitem realizar escritae leitura de arquivos e fluxo de dados, além de proporcionar fácil acesso e manuseio à


diretórios e arquivos. Sendo assim, ao utilizar as classes citadas acima, é possível deter-minar se o arquivo já é existente ou se existe a necessidade de criar um novo arquivo; istoapós realizar a leitura dos arquivos disponíveis na pasta de execução do software. Destamaneira, não é necessário que o usuário interaja com o software para salvar o arquivo; e,consequentemente, o processo se torna mais rápido, um fato que é interessante quando sehá a necessidade de lidar com um grande fluxo de dados de um sistema supervisório. Apóschamar o método Criar_Arquivo_JSON dentro da função que manuseia novas mensagensrecebidas pela porta serial, pode-se verificar o funcionamento desta na Figura 25 abaixo.

Figura 25 – Interface gráfica do usuário informando onde o arquivo será salvo.

Fonte: Do autor.

A biblioteca Newtonsoft, através do método SerializeObject, converte o objeto passadocomo parâmetro e este será salvo no arquivo "Exemplo Arquivo JSON"conforme mostradono trecho de código mostrado abaixo.

1 2 " Data " : " 26/12/17 " ,3 " Hora " : " 18 : 10 : 47 " ,4 " msg_recebida " : " 0A 00 00 00 AA AA AA AA A0 "5

Através deste código, se torna possível registrar todas as informações recebidas de modoque seja possível recuperá-las posteriormente para serem processadas a interesse do usuá-rio. A importância de se utilizar a notação JSON é que múltiplas linguagens oferecemsuporte para leitura e interpretação à esta formatação de arquivo, de forma que facilmente


se torna possível que estes dados sejam repassados a outros programadores para que estescriem suas aplicações.

3.6 Definição do Protocolo de Mensagens

Para a definição do protocolo de comunicação foi idealizado um método que fosse capazde fornecer segurança e confiabilidade nas transmissões de mensagens. Através da expe-riência prática obtida em campo no decorrer do estágio curricular de graduação, foramobservadas algumas boas práticas para o desenvolvimento de um sistema de comunicaçãoembarcada. Conforme descrito na Seção 2.2, sistemas embarcados possuem poucos recur-sos de processamento se comparados à um computador pessoal, portando é necessário queseja estabelecido uma forma de interpretação de mensagens de modo à otimizar o uso derecursos.

Deste modo, foi desenvolvido um protocolo que facilite a detecção de início e fimde mensagem, para que, tanto o sistema supervisório quanto o conjunto que está sendomonitorado, possam receber e interpretar facilmente novas mensagens. O protocolo decomunicação foi projetado para possuir os seguintes campos: início, cabeçalho, dados,verificação de erros e fim. Cada campo será descrito na sequência desta seção e o formatoda mensagem pode ser verificado na Tabela 3 abaixo.

Tabela 3 – Formato do protocolo de comunicação implementado no projeto.

Início Cabeçalho Dados Verificação de erros Fim1 byte 3 bytes Tamanho variável 2 bytes 1 byte

Conforme determinado pela Tabela 3, é necessário que o frame de mensagem possuabytes que indiquem o início da mensagem (do inglês: Start of Frame - SOF) e fim da novamensagem (do inglês: End of Frame - EOF). O cabeçalho da mensagem é responsávelpela determinação de quem é o emissor da mensagem e para quem esta mensagem estáendereçada; sendo assim, foram adicionados dois bytes que contém a informação de quemsão o emissor (do inglês: Sender - SND) e o destinatário da mensagem em questão (doinglês: Addressee - ADR). Sabendo que, além de contar com poucos recursos disponíveis,a programação de sistemas embarcados é feita normalmente em linguagem de baixo nível,como C e Assembly; é frequente a necessidade de lidar com vetores e ponteiros paraacessar posições da memória, portanto é imprescindível que seja enviado para o sistema otamanho do campo de dados da mensagem, para que seja possível determinar a quantidadede espaço que deve ser alocado para guardar a informação. Portanto, na definição docabeçalho foi especificado o campo tamanho de dados (do inglês: Data Size - DSZ) queinforma a quantidade de bytes enviados como informação. Desta maneira, o cabeçalho damensagem é composto por 3 bytes, conforme mostrado na Tabela 4.


Tabela 4 – Formato do cabeçalho da mensagem do protocolo.

SND ADR DSZ1 byte 1 byte 1 byte

Em muitos casos é possível que, no meio de mensagens transmitidas, apareçam bytesque indiquem o início e fim de mensagem, para evitar que estes bytes sejam interpreta-dos de maneira errônea é necessário utilizar bytes de proteção. Esta técnica consistemem incluir um byte de "aviso"de que o próximo byte enviado não é um início ou fim demensagem e então acrescentar um valor ao byte para diferenciá-lo; neste software o bytede aviso será 0x10. Por exemplo, ao transmitir um byte 0x01 no meio da mensagem, eledeve ser alterado para 0x10 0x21; outro exemplo é a mensagem: "0x01 0x02 0xFF 0x010x05 0x04", ela deve ser alterada para "0x01 0x02 0xFF 0x10 0x21 0x05 0x04". Os bytesque devem ser protegidos são 0x01, 0x04 e 0x10.

Dentre os dados que são enviados como informação, primeiramente tem-se um bytede comando que indica qual tipo de periférico deve ser acessado, controlado ou retor-nado alguma informação. Sabendo que é necessário enviar pelo menos um comando, épossível afirmar que, no mínimo, o valor do byte de tamanho deve ser 1, podendo au-mentar conforme a especificação de cada comando. Dentre estes sensores e periféricos,podem ser citados os tipos e modelos que o sistema já oferece suporte como o sensor decorrente ACS712, o magnetômetro HMC5883L, o acelerômetro MPU6050, o sensorde temperatura DS18B20, o módulo relógio de tempo real DS1307 e o sensor ultrassô-nico de distância HC-SR04; além de portas digitais e analógicas dos microcontroladores.Pode-se perceber que os periféricos possuem uma grande diferença entre si, de modo quecada um tenha a sua particularidade e comandos específicos; cada tipo de comando e seusparâmetros está descrito na Seção 3.7. O campo Dados tem tamanho variável que serátransmitido no campo DSZ do cabeçalho.

No Capítulo 2.7 foi descrita a necessidade de implementar métodos de detecção deerros em mensagens transmitidas, portanto no escopo do protocolo há espaço rservadopara dois bytes reservados para transmitir o CRC calculado da mensagem. Sabendo queserá enviado um CRC de 16 bits, é possível concluir que o divisor da função de CRCpossui 17 bits. Para enviar o valor completo do CRC, é necessário realizar uma separaçãodo valor em duas partes de 8 bits cada; na primeira posição serão enviados os 8 bits maissignificativos (em inglês: Most Significant Byte - MSB), e na segunda posição será enviadoos 8 bits menos significativos (em inglês: Least Significant Byte - LSB).

Desta maneira, separando o cabeçalho em seus 3 respectivos bytes, incluindo o campode comando e seus possíveis parâmetros no campo de dados e separando o CRC em suasduas partes; o frame do protocolo fica disposto conforme a Tabela 5 abaixo.


Tabela 5 – Separação do protocolo com seus respectivos campos.

Início Cabeçalho Dados Verificação de erros FinalSOF SND ADR DSZ CMD Paramêtros CRC MSB CRC LSB EOF1 byte 3 bytes Variável 2 bytes 1 byte

• SOF: início de mensagem. Valor: 0x01.

• EOF: fim de mensagem. Valor: 0x04.

3.7 Comandos

Nesta seção serão descritos os comandos para cada um dos periféricos implementadosno sistema supervisório. Cada comando tem seus próprios parâmetros que devem serrespeitados para um bom funcionamento do software.

3.7.1 Acelerômetro

Os comandos referentes para o sensor do tipo acelerômetro foram desenvolvidos e tes-tados utilizando módulo GY-521, que utiliza o circuito integrado MPU-605 da fabricanteInvenSense, que contém um acelerômetro e um giroscópio. Este CI tem 3 eixos de mo-vimento tanto para o acelerômetro quanto para o giroscópio, formando ao total 6 grausde liberdade. As faixas de operação do acelerômetro são ±2g, ±4g, ±8g e ±16g. Estemódulo utiliza comunicação via I2C.

Requisição de Dados

Para a requisitar dados, ou seja, realizar a leitura do acelerômetro; o sistema supervi-sório deve enviar os seguintes parâmetros, conforme a Tabela 6 abaixo.

Tabela 6 – Comando de requisição de dados para o acelerômetro.

CMD ID Eixo1 byte 1 byte 1 byte

Descrição de cada um dos campos:

• CMD: comando que identifica o acelerômetro. Valor hexadecimal: 0x01.

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimalde 0x00 até 0xFF.

• Eixo: eixo no qual se deseja requisitar a leitura, os seguintes valores são válidos:

0x00 - Leitura de todos os eixos


0x01 - Leitura do eixo X

0x02 - Leitura do eixo Y

0x03 - Leitura do eixo Z

Recebimento de Dados

Para transmitir a leitura dos dados, o conjunto que está sendo monitorado deve enviarpara o sistema supervisório uma mensagem com os seguintes, parâmetros conforme aTabela 7 abaixo.

Tabela 7 – Resposta do sistema monitorado para o comando de leitura do acelerômetro.

CMD ID Eixo X Eixo Y Eixo Z1 byte 1 byte 2 bytes 2 bytes 2 bytes


• CMD: comando que identifica o acelerômetro. Valor hexadecimal: 0x01.


Eixo X: último valor lido para o eixo X do acelerômetro.

Eixo Y: último valor lido para o eixo Y do acelerômetro.

Eixo Z: último valor lido para o eixo Z do acelerômetro.

Caso seja requisitada a leitura de apenas um dois eixos, os valores enviados referentesaos eixos restantes devem ser repetidos. Os valores de leitura enviados devem ser exa-tamente os mesmo recebidos do sensor, não deve ser realizado nenhum tratamento prétransmissão. Ao receber o dado, o software se encarrega de realizar o processamento dosdados realizando operações matemáticas conforme o datasheet do fabricante.

3.7.2 Temperatura

Os comandos referentes para o sensor de temperatura foram desenvolvidos e testadosutilizando o termômetro digital DS18B20, da fabricante Maxim Integrated. Este sensortem uma resolução programável de 9 à 12 bits. Este sensor mede temperaturas entre−55C e +125C, com precisão de até ±0, 5C. A comunicação com este componente éatravés do protocolo 1-Wire.



Para a requisitar dados, ou seja, realizar a leitura do sensor de temperatura; o sistemasupervisório deve enviar os seguintes parâmetros, conforme a Tabela 8 abaixo.

Tabela 8 – Comando de requisição de dados para o sensor de temperatura.

CMD ID1 byte 1 byte


• CMD: comando que identifica o sensor de temperatura. Valor hexadecimal: 0x02.




Tabela 9 – Resposta do sistema monitorado para o comando de leitura do sensor de tem-peratura.

CMD ID Temperatura1 byte 1 byte 2 bytes


• CMD: comando que identifica o sensor de temperatura. Valor hexadecimal: 0x02.


• Temperatura: valor da temperatura aferido. Este valor deve ser do tipo sinalizado,ou seja, o bit mais significativo indica se é um valor positivo ou negativo.

Os valores de leitura enviados devem ser exatamente os mesmo recebidos do sensor, nãodeve ser realizado nenhum tratamento pré transmissão. Ao receber o dado, o softwarese encarrega de realizar o processamento dos dados realizando operações matemáticasconforme o datasheet do fabricante.


3.7.3 Corrente

Os comandos referentes para o sensor de corrente foram desenvolvidos e testados utili-zando o circuito integrado ACS712, da fabricante Allegro. Este sensor pode ser utilizadopara medir correntes tanto em tensão contínua quanto em tensão alternada, tendo varia-ções que podem medir desde ±5A até ±30A, e utiliza uma saída analógica para transmitiro valor medido. A resolução da tensão de saída varia conforme o modelo do circuito in-tegrado, estas variações estão descritas na 10 abaixo.

Tabela 10 – Variação da resolução da saída analógica conforme o modelo do CI ACS712.

Modelo Corrente de Pico(A) Resolução(mV/A)ACS712ELCTR-05B-T 5 185ACS712ELCTR-20A-T 20 100ACS712ELCTR-30A-T 30 66


Para a requisitar dados, ou seja, realizar a leitura do sensor de corrente; o sistemasupervisório deve enviar os seguintes parâmetros, conforme a Tabela 11 abaixo.

Tabela 11 – Comando de requisição de dados para o sensor de corrente.

CMD ID1 byte 1 byte


• CMD: comando que identifica o sensor de corrente. Valor hexadecimal: 0x03.




Tabela 12 – Resposta do sistema monitorado para o comando de leitura do sensor decorrente.

CMD ID Corrente1 byte 1 byte 2 bytes



• CMD: comando que identifica o sensor de corrente. Valor hexadecimal: 0x03.


• Corrente: valor de temperatura aferido. Este valor deve ser do tipo sinalizado, ouseja, o bit mais significativo indica se é um valor positivo ou negativo.

Os valores de leitura enviados devem ser exatamente os mesmo recebidos do sensor, nãodeve ser realizado nenhum tratamento pré transmissão. Ao receber o dado, o softwarese encarrega de realizar o processamento dos dados realizando operações matemáticasconforme o datasheet do fabricante.

3.7.4 Sensor Ultrassônico

Os comandos referentes para o sensor ultrassônico foram desenvolvidos e testadosutilizando o módulo HC-SR04. Este sensor tem o funcionamento baseado na emissão deondas ultrassônicas e sua reflexão para detecção de obstáculos.


Para a requisitar dados, ou seja, realizar a leitura do sensor de ultrassônico; o sistemasupervisório deve enviar os seguintes parâmetros, conforme a Tabela 13 abaixo.

Tabela 13 – Comando de requisição de dados para o sensor de ultrassônico.

CMD ID1 byte 1 byte


• CMD: comando que identifica o sensor ultrassônico. Valor hexadecimal: 0x04.




Tabela 14 – Resposta do sistema monitorado para o comando de leitura do sensor ultras-sônico.

CMD ID Distância1 byte 1 byte 2 bytes



• CMD: comando que identifica o sensor ultrassônico. Valor hexadecimal: 0x04.


• Distância: valor da distância medida.

3.7.5 Magnetômetro

Para a requisitar dados, ou seja, realizar a leitura do magnetômetro; o sistema super-visório deve enviar os seguintes parâmetros, conforme a Tabela 15 abaixo.

Tabela 15 – Comando de requisição de dados para o magnetômetro.

CMD ID Eixo1 byte 1 byte 1 byte


• CMD: comando que identifica o magnetômetro. Valor hexadecimal: 0x05.


• Eixo: eixo no qual se deseja requisitar a leitura, os seguintes valores são válidos:

0x00 - Leitura de todos os eixos

0x01 - Leitura do eixo X

0x02 - Leitura do eixo Y

0x03 - Leitura do eixo Z



Tabela 16 – Resposta do sistema monitorado para o comando de leitura do magnetômetro.

CMD ID Eixo X Eixo Y Eixo Z1 byte 1 byte 2 bytes 2 bytes 2 bytes



• CMD: comando que identifica o magnetômetro. Valor hexadecimal: 0x05.


Eixo X: último valor lido para o eixo X do magnetômetro.

Eixo Y: último valor lido para o eixo Y do magnetômetro.

Eixo Z: último valor lido para o eixo Z do magnetômetro.

Caso seja requisitada a leitura de apenas um dois eixos, os valores enviados referentesaos eixos restantes devem ser repetidos. Os valores de leitura enviados devem ser exa-tamente os mesmo recebidos do sensor, não deve ser realizado nenhum tratamento prétransmissão. Ao receber o dado, o software se encarrega de realizar o processamento dosdados realizando operações matemáticas conforme o datasheet do fabricante.

3.7.6 Relógio de Tempo Real - RTC

Os comandos referentes ao RTC foram desenvolvidos e testados utilizando o circuitointegrado DS1307 da fabricante Maxim Integrated. Estte CI possui modos de operaçãode baixo consumo, 56 bytes de memória SRAM, comunicação via I2C. Através de suasfuncionalidades é possível obter informações como segundos, minutos, horas, dias, datas,meses e anos; também é possível configurá-lo para operar como relógio com formatos de12 ou 24 horas.

Envio de Comandos

São dois comandos disponíveis para o RTC: leitura do último horário e escrita deum horário desejado. É de responsabilidade do usuário implementar estes comandos nosistema embarcado para que tenha-se um funcionamento adequado. Os comandos seguemo formato descrito na Tabela 17 abaixo.

Tabela 17 – Envio de comandos para o relógio de tempo real.

CMD ID Tipo Parâmetros do RTC1 byte 1 byte 1 byte 11 bytes


• CMD: comando que identifica o RTC. Valor hexadecimal: 0x06.

• ID: número de identificação da porta, pode variar de 0 a 255, ou, em hexadecimalde 0x00 até 0xFF.


• Tipo: escolhe entre os dois comandos possíveis para o RTC.

0x00 - Leitura dos parâmetros do RTC.

0x01 - Escrita dos parâmetros do RTC.

• Parâmetros do RTC: campo composto por 11 bytes, conforme Tabela 18.

Caso seja apenas um comando de leitura, o campo "Parâmetros do RTC"não seráenviado. Porém, caso seja um comando de escrita, este os bytes do campo "Parâmetrosdo RTC"são dispostos conforme a Tabela 18 abaixo.

Tabela 18 – Parâmetros do RTC.Parâmetros do RTC

DS DD MM AA HH MM SS1 byte 1 byte 1 byte 2 bytes 2 bytes 2 bytes 2 bytes

Descrição dos parâmetros do RTC:

• DS: este byte indica o dia da semana que será enviado ao RTC, valores válidos de0x00 até 0x06.

0x00: Segunda-Feira.

0x01: Terça-Feira.

0x02: Quarta-Feira.

0x03: Quinta-Feira.

0x04: Sexta-Feira.

0x05: Sábado.

0x06: Domingo

• DD: byte que indica o número do dia.

• MM: byte que indica os meses do ano, valores válido de 0 até 11, ou em hexadecimal,de 0x00 até 0x0B.

0x00 - Janeiro.

0x01 - Fevereiro.

0x02 - Março.

0x03 - Abril.

0x04 - Maio.

0x05 - Junho.

0x06 - Julho.


0x07 - Agosto.

0x08 - Setembro.

0x09 - Outubro.

0x0A - Novembro.

0x0B - Dezembro.

• AA: estes bytes indicam os valores do ano. O byte MSB é responsável por indicar adezena do ano, tendo como valores válidos de 0x00 até 0x09; e, o byte LSB informaa unidade do ano, tendo como valores válidos de 0x00 até 0x09.

• HH: estes bytes indicam os valores da hora. O byte MSB é responsável por indicar adezena da hora, tendo como valores válidos de 0x00 até 0x02; e, o byte LSB informaa unidade do ano, tendo como valores válidos de 0x00 até 0x09.

• MM: estes bytes indicam os valores dos minutos. O byte MSB é responsável porindicar a dezena dos minutos, tendo como valores válidos de 0x00 até 0x05; e, o byteLSB informa a unidade dos minutos, tendo como valores válidos de 0x00 até 0x09.

• SS: estes bytes indicam os valores dos segundos. O byte MSB é responsável porindicar a dezena dos segundos, tendo como valores válidos de 0x00 até 0x05; e, obyte LSB informa a unidade dos segundos, tendo como valores válidos de 0x00 até0x09.


Para transmitir os dados do conjunto de medição para o sistema supervisório, asmensagens devem obedecer o padrão estabelecido pela Tabela 19 abaixo.

Tabela 19 – Resposta do sistema monitorada para o comando de leitura dos dados dorelógio de tempo real.

CMD ID Parâmetros do RTC1 byte 1 byte 11 bytes


• CMD: comando que identifica o RTC. Valor hexadecimal: 0x06.


• Parâmetros do RTC: campo composto por 9 bytes, conforme Tabela 18.


3.7.7 Porta Digital

Os comandos referentes para as portas digitais foram desenvolvidos e testados utili-zando os hardwares descritos na Seção 3.9; porém, todos os microcontroladores no mercadopossuem portas digitais disponíveis para o usuário, de modo que os comandos podem serimplementados sem maiores complicações.

Envio de Comando

Existem três tipos de comandos que podem ser enviados para portas digitais: leitura,escrita em nível lógico alto e escrita em nível lógico baixo. É de responsabilidade do usuárioimplementar estes comandos no sistema embarcado para que tenha-se um funcionamentoadequado. Os comandos seguem o formato descrito na Tabela 20 abaixo.

Tabela 20 – Envio de comandos para as portas digitais.

CMD ID Tipo1 byte 1 byte 1 byte


• CMD: comando que identifica a porta digital. Valor hexadecimal: 0x07.


• Tipo: define o tipo de comando para a porta digital.

0x00 - leitura do nível lógico da porta.

0x01 - escrita em nível lógico alto.

0x02 - escrita em nível lógico baixo.


Para ambos os comandos referentes à portas digitais, escrita e leitura, a respostaenviada para o sistema supervisório obedece o mesmo padrão. Para transmitir a leiturados dados, o conjunto que está sendo monitorado deve enviar para o sistema supervisóriouma mensagem com os seguintes, parâmetros conforme a Tabela 21 abaixo.

Tabela 21 – Resposta do sistema monitorado para os comandos das portas digitais.

CMD ID Estado1 byte 1 byte 1 byte



• CMD: comando que identifica a porta digital. Valor hexadecimal: 0x07.


• Estado: retorna o nível lógico da porta digital.

3.7.8 Porta Analógica

Os comandos referentes para as portas analógicas foram desenvolvidos e testadosutilizando os hardwares descritos na Seção 3.9, porém a grande maioria dos microcon-troladores disponíveis no mercado possuem portas com conversores analógico-digital oudigital-analógico incluídos.

Envio de Comando

Existem dois tipos de comandos que podem ser enviados para portas analógicas: lei-tura em um conversor analógico-digital, ou escrita de um valor em um conversor digital-analógico. É de responsabilidade do usuário implementar estes comandos no sistema em-barcado para que tenha-se um funcionamento adequado. Os comandos seguem o formatodescrito na Tabela 22 abaixo.

Tabela 22 – Envio de comandos para as portas analógicas.

CMD ID Tipo Valor MSB Valor LSB1 byte 1 byte 1 byte 1 byte 1 byte


• CMD: comando que identifica a porta analógica. Valor hexadecimal: 0x08.


• Tipo: define se é um comando para escrita de dados em um conversor digital-analógico ou se é uma leitura em um conversor analógico-digital.

0x00 - leitura de dados.

0x01 - escrita de dados.

• Valor MSB: caso seja um comando de escrita de dados, este byte deve conter os oitobits mais significativos do valor a ser escrito.

• Valor LSB: caso seja um comando de escrita de dados, este byte deve conter os oitobits menos significativos do valor a ser escrito.


Caso seja um comando de leitura de dados, os dois últimos bytes não serão enviados namensagem.


Para ambos os comandos referentes à portas analógicas, escrita e leitura, a respostaenviada para o sistema supervisório obedece o mesmo padrão. Para transmitir a leiturados dados, o conjunto que está sendo monitorado deve enviar para o sistema supervisóriouma mensagem com os seguintes, parâmetros conforme a Tabela 23 abaixo.

Tabela 23 – Resposta do sistema monitorado para os comandos das portas analógicas.

CMD ID Valor1 byte 1 byte 2 bytes


• CMD: comando que identifica a porta analógica. Valor hexadecimal: 0x08.


• Valor: valor escrito ou lido no conversor.

3.8 Design da interface de usuário

Para montar a interface de usuário deve-se, primeiramente, ter em mente a quantidadede sensores que se deseja monitorar e como os dados de cada um deve ser exibido. Comodito anteriormente no Capítulo 1, o foco deste projeto é simplificar o monitoramento inter-pretação dos sensores mais utilizados para estudantes e entusiastas; portanto, também éde interesse que os dados recebidos sejam exibidos de maneira simples e direta ao usuário.Para ter-se várias páginas, de sensores e configuração, é necessário utilizar a ferramentaTabControl, disponível no toolbox do Visual Studio. Foram desenvolvidas páginas espe-cíficas para configuração, log de mensagem, acelerômetro, sensor de temperatura, sensorde corrente e outros sensores.

Para que seja de fácil uso, o programa desenvolvido deve ser intuitivo, de modo que ousuário seja capaz de olhar de relance e compreender as informações na tela. Ao executaro software, a primeira tela que o usuário irá visualizar está ilustrada na Figura 26 abaixo.


Figura 26 – Tela inicial do sistema supervisório.

Fonte: Do autor.

Conforme pode-se analisar, a tela mostrada acima é basicamente utilizada para con-figuração do método de comunicação utilizado, seja através do protocolo TCP/IP ouempregando uma porta de comunicação serial. Conforme descrito na Seção 3.3, quandoo software é executado, o endereço de IP interno da máquina é automaticamente detec-tado e define-se a porta padrão de conexão com o valor 5001. Deve-se salientar que aconfiguração para abertura e e concessão da porta junto ao modem de conexão é de res-ponsabilidade do usuário; não há um método padrão para esta configuração, recomenda-sebuscar a informação dos procedimentos necessários com o provedor de internet ou o fa-bricante do equipamento. O endereço IP detectado pelo software e a configuração doservidor TCP/IP estão identificados onde está indicado por (A) na Figura 27 abaixo.

Figura 27 – Configurações iniciais do sistema supervisório.

Fonte: Do autor. c

Assim como demonstrado na Seção 3.2, no momento em que o software é carregado


e inicia sua execução, é disparado um timer que é responsável por executar buscas pe-riódicas de portas seriais conectadas ao computador. Assim que estas conexões foremdetectadas, as novas portas serão listadas para que o usuário possa escolher a desejada.A configuração da comunicação serial está indicada por (B) na Figura 27. Também épossível verificar na imagem um terceiro groupBox nomeado "Configurações", no qualé possível selecionar um checkBox que habilita a criação de arquivos json que poste-riormente podem ser convertidos em tabelas no formato "*.xlsx", padrão da plataformaMicrosoft Office utilizando o botão disponível nesta tela. Os aquivos formtados como jsonsão salvos com o nome padrão "Json ID X.txt", onde X é o ID do sistema monitorado; e,posteriormente, as tabelas do Excel são nomeadas como "Leitura de Sensores ID X.xlsx".O terceiro groupBox está indicado por (C) na Figura 27.

Em grande parte dos casos, interfaces gráficas são mais simples de serem analisadaspor exigirem poucas análises e serem mais intuitivas; porém, assim como grande partedos sistemas computacionais, é interessante manter um log de dados para registrar todasas trocas de mensagens. Neste registro de comunicação, são exibidos a data e hora derecebimento da mensagem, o tipo do sensor que enviou a informação, o ID do transmissor edo sensor, e os dados processados pelo sistema. O registro dessas informações é importanteem situações nas quais se deseja manter um registro dos dados recebidos, além dos arquivosformatados em json. Nesta tela também estão inclusos dois botões, um destinado à apagaro log exibido na tela; e outro, assim como na Seção 3.5, com a finalidade de salvar o logem formato "*.txt". Na Figura 28 pode-se verificar a interface gráfica do log de dados.

Figura 28 – Interface para exibição do log de dados.

Fonte: Do autor.


Para exibir os dados do acelerômetro são utilizados três gauges, que são instrumentosindicadores de grandezas, um exemplo é o manômetro. Cada um dos gauges representaa aceleração medida em cada um dos eixos X, Y e Z. Dentro groupBox estão disponíveisduas caixas de texto que mostram os IDs do último transmissor e do último sensor a enviaruma mensagem; e uma seleção das faixas de operação do acelerômetro (±2g, ±4g, ±8g ou±16g) para ajustar os dados da melhor forma. A interface gráfica desenvolvida para oacelerômetro está ilustrada na Figura 29 abaixo.

Figura 29 – Interface gráfica para acelerômetros.

Fonte: Do autor.

Conforme pode-se verificar, nesta tela também há um groupBox de comandos, ondepodem ser enviados mensagens pela comunicação serial requisitando leituras de acelera-ção. Para enviar os comandos são necessários três parâmetros: ID do receptor, ID dosensor e escolher em qual dos eixos deseja-se realizar a leitura. Ao implantar a interfacede comandos desta forma, gera-se uma grande versatilidade pois podem ser enviados co-mandos para quaisquer IDs de receptor e de sensor, desde que os valores passados sejamválidos; ou seja, entre 1 e 255, que são os valores possíveis de um byte assumir. Apósclicar no botão de enviar o comando, os parâmetros informados nas caixas de texto sãoanalisados para serem julgados válidos; e, caso estejam incorretos, uma mensagem de errosurge para o usuário.

O passo seguinte é formatar as informações recebidas e exibi-las para usuário de formaque os dados possam ter analisados de forma simples e coerente. Durante a graduação, osdiscentes diversas grandezas são analisadas em função do tempo, como variações de tem-peratura em corpos e fluidos, e consumo de energia elétrica. Desta maneira, é conveniente


que estas grandezas sejam exibidas de forma que seja possível analisar a variação dos valo-res em função do tempo; portanto, para os dados enviados pelos sensores de temperaturae corrente, serão construídos gráficos distintos de modo que seja possível analisar, sepa-radamente, as últimas 100 amostras de cada um dos sensores. Esta quantidade de dadosfoi escolhida de forma arbitrária, de modo que não ocorra uma sobrecarga no softwarequando muitos dados forem recebidos de forma simultânea. Na Figura 30 abaixo pode-seanalisar a construção da interface gráfica de usuário para o sensor de temperatura.

Figura 30 – Interface gráfica para sensor de temperatura.

Fonte: Do autor.

Assim como implementado para o acelerômetro, há um groupBox no qual pode-serequisitar uma leitura de temperatura ao informar os IDs de receptor e sensor. Após ainserção dos valores, estes são analisados para determinar a coerência dos dados. Logoabaixo, há um segundo groupBox que é utilizado para mostrar informações em tempo realda última mensagem exibida. São três dados exibidos ao usuário: ID de receptor, ID desensor e temperatura instantânea. Ocupando a maior parte da tela, tem-se uma interfacegráfica implementada utilizando a biblioteca Live Charts. Neste gráfico serão ilustradosas 100 últimas amostras de temperatura recebidas para cada ID de sensor, de modo quedados de diversos sensores possam ser analisados simultaneamente. Deve-se atentar parao caso de sensores com IDs iguais, nesta situação haverá um conflito de dados de modoque não será possível visualizar separadamente os dados de cada sensor.

Na Figura 31 abaixo, pode-se visualizar a interface gráfica desenvolvida para análisedos dados provenientes do sensor de corrente. Assim como implementado para o sensorde temperatura, existem três groupBox com finalidades distintas. O primeiro, no canto


superior esquerdo, é responsável pelo envio de requisição de dados; o segundo, no cantoinferior esquerdo, tem como propósito a exibição em tempo real das informações prove-nientes da última mensagem recebida. E por fim, no terceiro groupBox, tem-se o gráficoonde poderão ser analisadas as últimas 100 últimas amostras de corrente recebidas paracada ID de sensor.

Figura 31 – Interface gráfica para sensor de corrente.

Fonte: Do autor.

Para os demais sensores, não foram encontradas justificativas para realizar-se umaanálise temporal ao deparar-se com o confronto entre quantidade de informações e de-sempenho esperado do sistema. Espera-se que este sistema seja capaz de trabalhar emcomputadores com poucos recursos e baixo poder de processamento; de modo que foidecidido simplificar a interface de modo à visualizar-se apenas os os últimos dados recebi-dos para cada sensor. Na Figura 32 abaixo, são mostradas informações sobre a distânciamedida pelo sensor ultrassônico, os valores de campo magnético informados pelo magnetô-metro, os parâmetros de data e hora configurados no relógio de tempo real, informaçõessimples sobre o nível de tensão de uma porta digital de uso geral do microcontrolador epor fim, valores obtidos de um conversor analógico-digital. Nas seções de comandos é pos-sível requisitar leituras para cada um dos tipos de periférico, passando parâmetros comoID de receptor e sensor. O usuário deve atentar-se ao enviar comandos de escrita paraportas digitais e analógicas utilizando o sistema supervisório; para que uma porta digitalpossa receber um comando de escrita, ela deve ser configurada como saída no firmwaredo microcontrolador. E uma porta analógica só é capaz de receber comandos de escrita,se possuir internamente um conversor digital-analógico com saída disponível.


Figura 32 – Interface gráfica para demais sensores.

Fonte: Do autor.

3.9 Hardware de testes

Conforme descrito anteriormente, o objetivo deste trabalho é o desenvolvimento deum sistema supervisório que seja versátil e possa atender diversos tipos de projetos, destamaneira foram realizados testes utilizando diferentes sistemas. Foram executados doistipos de testes: o primeiro teste consistiu em analisar se a interface gráfica comportaria-se conforme o esperado, e o segundo teste teve como finalidade a análise da capacidadedo software, tanto em tempo de execução quanto em número de mensagens recebidas.Para a realização de testes foram utilizados duas placas de desenvolvimento, cada umacontendo um microcontrolador de arquiteturas diferentes, e a terceira unidade de testesfoi um equipamento desenvolvido por um aluno como trabalho de conclusão de cursopela Universidade Estadual de Londrina; serão explicadas cada uma das plataformas nasequência.

3.9.1 Arduino Mega

O primeiro sistema de testes foi montado utilizando uma placa de desenvolvimentoArduino Mega da empresa italiana Arduino, a qual é baseada no microcontrolador AT-mega1280. Esta placa tem pinos de uso geral que podem ser utilizados como entrada ousaídas de sinais digitais, e 14 destes pinos oferecem suporte à saídas com modulação porlargura de pulso ( do inglês, pulse width modulation - PWM ); também estão disponíveis 16


entradas analógicas, 4 comunicações seriais ( em inglês, universal asynchronous receiver-transmiter - UART ), cristal oscilador de 16MHz, conexão usb, conector de alimentaçãoe um pino de reset. Foram conectados nesta placa um potenciômetro de 10kΩ em umadas entradas analógicas, o magnetômetro HMC5883L e também um botão em modopull-up foi conectado em uma das entradas digitais disponíveis. Para a comunicação como sistema supervisório foi utilizada uma comunicação serial com baudrate de 9600bps.

3.9.2 STM32F4DISCOVERY

A placa de desenvolvimento STM32F4DISCOVERY da fabricante STM foi projetadapara demonstrar as capacidades do microcontrolador STM32F407VGT6, um chip ARMCortex-M4 de 32 bits com 1MB de memória flash e trabalhando com frequência de até164MHz. Na placa estão disponíveis 3 LEDs para uso do desenvolvedor, um botão, umgravador ST-LINK/V2, um acelerômetro LIS3DSH com 3 eixos de medição, conversordigital-analógico específico para tratamento de áudio e 100 pinos disponíveis para uso dodesenvolvedor. Nesta placa foram conectados para a realização dos testes um acelerômetroMPU6050 e o sensor ultrassônico de distância HC-SR04. Foi configurada uma portaserial com baudrate de 115200bps para a comunicação com o software serial.

3.9.3 Trabalho de Conclusão de Curso

No trabalho de título "Proposta de um Sistema de Monitoramento em Tempo Real,para Estudos de Determinação de Economia de Energia, em Aquecimento Solar de Água",Ricato (2018) desenvolveu um equipamento capaz de mensurar grandezas importantescomo corrente elétrica, temperatura e presença de fluxo de água. Neste projeto foramutilizados os sensores de temperatura DS18B20, o sensor de corrente SC013-100 e orelógio de tempo real DS1307. Teve-se como finalidade à análise da eficiência energéticade painéis solares para aquecimento de água residencial através da análise do perfil doconsumidor para o uso correto do equipamento. Esse sistema, além dos sensores já citados,utiliza um módulo GPRS que transmite dados em tempo real para o sistema supervisórioutilizando o protocolo TCP/IP. Para fornecer redundância e proteção dos dados, utiliza-se um cartão de memória como backup dos das mensagens transmitidas. Este projetotambém realizou a análise da eficiência de três arquiteturas de microcontroladores demodo à desenvolver um protótipo com uma boa relação de custo-benefício (RICATO,2018).

76

4 Resultados e Discussões

Após o desenvolvimento de toda a interface gráfica dos sensores, foi realizada a imple-mentação do código necessário para realizar as funções especificadas e para a decodificaçãodo protocolo de comunicação definido na Seção 3.6. Foram realizados testes para analisarse o comportamento do software seria adequado às especificações. Na primeira bateriade testes foi analisada o desempenho da interface gráfica e a exibição das informações desensores.

Na Figura 33 abaixo, é exibida a interface gráfica do log de mensagens, onde pode-severificar a disposição das informações exibidas assim que recebe-se uma mensagem. Alémdos dados enviados pelos sensores, também são informadas a data e hora do recebimentoda mensagem.

Figura 33 – Exibição do log de mensagens.

Fonte: Do autor.

Na Figura 34 são exibidos os gauges de cada um dos eixos do acelerômetro, estesdemonstram a aceleração medida em cada um dos eixos utilizando a escala de ±2g.

Capítulo 4. Resultados e Discussões 77

Figura 34 – Exibição dos valores recebidos para o acelerômetro.

Fonte: Do autor.

Na Figura 35 é mostrado como o gráfico da variação de temperatura é montado, bemcomo o valor da última medição recebida.

Figura 35 – Exibição das últimas 100 amostras de temperatura recebidas.

Fonte: Do autor.

Na Figura 36 é mostrado como o gráfico da variação de temperatura é montado, bemcomo o valor da última medição recebida.


Figura 36 – Exibição das últimas 100 amostras de corrente recebidas.

Fonte: Do autor.

Na Figura 37 são mostrados as dados recebidos dos diversos tipos de sensores, cadaum com sua particularidade de exibição.

Figura 37 – Exibição dos dados recebidos para demais sensores.

Fonte: Do autor.


Para o segundo tipo de teste, foram analisadas a capacidade de receber inúmerasmensagens em um pequeno intervalo de tempo. As placas de desenvolvimento foramprogramadas para trabalharem em suas capacidades máximas, de modo que as mensagensenviadas tivessem o menor intervalo possível entre elas. Para a contagem da quantidadede mensagens recebidas, foi criado uma variável de contagem de 32 bits para armazenara quantidade de vezes que o evento da porta serial responsável por manusear com novasmensagens foi disparado. Os testes executados consistiram de, primeiramente, realizaruma análise a capacidade máxima do software de lidar com um grande fluxo de mensagensatravés da porta serial e do protocolo TCP/IP, e por fim determinar o tempo máximode execução do software, também utilizando comunicações enviadas através do protocoloTCP/IP e da porta serial.

Para uma melhor taxa de transmissão de dados, a porta serial do microcontroladorfoi configurada com um baudrate de 115200bps, tanto para envio direto pela serial quantopor envio de mensagens via TCP/IP. Foram estipuladas uma quantidade de mensagenspor minuto que seriam enviadas e então seria mensurado por quanto tempo o softwaresuportaria a sobrecarga de comunicação. Os resultados obtidos estão separados em duastabelas pelo tipo de comunicação e estão dispostos nas Tabelas 24 e 25 abaixo.

Tabela 24 – Medições dos testes de capacidade de recebimento de mensagens através daporta serial.

Mensagens por minuto Tempo de execução em minutos100 125,3300 63,9500 34,21000 12,6

Tabela 25 – Medições dos testes de capacidade de recebimento de mensagens através doprotocolo TCP/IP.

Mensagens por minuto Tempo de execução em minutos100 115300 67,5500 24,81000 6,5

Ao realizar uma análise dos resultados obtidos do teste acima; pode-se concluir queconforme o fluxo de mensagens aumenta, o tempo de execução do software diminui. Estefato pode ser explicado da seguinte maneira, ao receber uma nova mensagem, seja porcomunicação serial ou pelo protocolo TCP/IP, é gerado um novo evento. O sistemasupervisório deve tratar estes eventos, manipulando os dados recebidos e aplicando odevido tratamento, atualizando dados, interface gráfica e salvando arquivos em temporeal. Quando muitas mensagens chegam em um curto período de tempo, os eventos de


mensagens recebidas são colocados na pilha de execução para serem tratados em sequência;porém, quando esta fila de execução torna-se muito grande, o sistema operacional finalizao software por julga que este está consumindo demasiados recursos computacionais e paraproteger os outros programas que estão rodando em paralelo, desta maneira é possívelevitar que dados não sejam corrompidos dados ou o próprio sistema operacional sejadanificado.

Para o segundo tipo de teste, também foram utilizadas portas seriais configuradasem 115200bps para a transmissão de mensagens. Porém, diferentemente do primeiroteste, foi configurada uma taxa de 5 mensagens transmitidas por minuto, para analisarse alguma falha na lógica de programação poderia causar falhas à longo prazo nos testes.As medições dos tempos de execução máxima do software, em horas, estão exibidos naTabela 26 abaixo.

Tabela 26 – Medições dos testes de capacidade de tempo de execução.

Tipo de Comunicação Tempo de execução em horasPorta Serial 192,7TCP/IP 119,1

É importante destacar que os tempos de execução máxima informados na Tabela 26foram os períodos máximos em que o software se manteve em execução. Em nenhumdos casos foram detectadas falhas de aplicação; porém, por motivos imprevisíveis comoproblemas de conexão na internet e falha no fornecimento de energia elétrica, os testesforam finalizados precocemente.

81

5 Conclusões

Após realizar uma revisão bibliográfica sobre sistemas supervisórios de controle e aqui-sição de dados e outros temas relacionados, a qual forneceu uma base teórica sobre ométodos de funcionamento e tecnologias envolvidas em sistemas deste tipo; foi possívelperceber a importância dos sistema supervisórios na atual sociedade, sendo aplicadosdesde controle de processos fabris, passando por pesquisas científicas no CERN e al-cançando projetos de entusiastas. Com o avanço da automação industrial, foi possívelnotar a contribuição agregada pelos sistemas supervisórios; aumentando a confiabilidade,agilidade e diminuindo os custos envolvidos nos processos. Também foram citadas asdiscussões da comunidade científica confrontando riscos e benefícios; chegando à definiçãodos dez níveis de automação.

Foram apresentados conceitos importantes como sistemas embarcados, modelo de co-municação OSI, protocolo TCP/IP, formatação de arquivos JSON e verificação cíclica deredundância. Muitos destes assuntos frequentemente passam despercebido à maioria dosusuários, apesar de serem tão frequentes em atividades do dia a dia; e julga-se importantetrazer estes conhecimentos à tona de modo que o grande público torne-se consciente detoda a tecnologia que o cerca.

Após introduzir plataforma .NET e suas características; a criação de diversos projetosfoi demonstrada, de modo à fornecer conhecimento e capacitar o usuário a desenvolversistemas simples que abordem os conceitos gerais que foram reunidos na implementaçãodo sistema supervisório. A partir deste conhecimento fornecido, espera-se que o usuáriotenha condições de desenvolver o sistema supervisório por completo; desde criar interfacegráficas, salvar arquivos e manipular dados recebidos e enviados.

O desempenho demonstrado pelo software se mostrou satisfatório, de modo que osrequisitos do software foram atendidos. Foi possível analisar as mensagens recebidasatravés de uma caixa de texto onde exibia-se um log de mensagens; outros resultadosincluem o acompanhamento em tempo real a variação da aceleração medida nos três eixosde um sensor, a criação de gráficos de corrente e temperatura variantes no tempo, etambém foram apresentados dados de outros sensores de forma mais simples, revelandoos dados de forma clara em caixas de texto para o usuário. Sobre as capacidades dosistema supervisório em lidar com eventos de novas mensagens, foi possível constatarque o desempenho da comunicação através de uma porta serial ou utilizando o servidorTCP/IP é semelhante; de modo a permitir que o usuário adote a tecnologia que mais seadapte a seus recursos e necessidades.

Foi possível notar que quando há um grande fluxo de mensagens sendo enviadas parao software, seja por qualquer um dos dois canais de comunicação disponíveis, a fila de

Capítulo 5. Conclusões 82

eventos pendentes implementada pela plataforma .NET tende a crescer mais rapidamentedo que o software é capaz de lidar com cada um destes eventos; causando, assim, afinalização da execução por problemas de armazenamento de memória e consumo derecursos pelo sistema operacional. Porém, também pode-se concluir, que para uma taxade transmissão de mensagens moderadas, o sistema comportou-se de forma satisfatória,permitido a aquisição de dados por uma quantidade considerável de tempo; desta maneira,julga-se que o sistema supervisório é capaz de atender a maioria das necessidades deestudantes de engenharia elétrica.

A partir das conclusões realizadas acima, pode-se afirmar que este trabalho alcançouo objetivo de desenvolver um sistema supervisório capaz de lidar com a necessidade deestudantes, facilitando a interpretação de informações em projetos de graduação. E oconhecimento agregado para o curso através deste trabalho também pode ser consideradoimportante uma vez que aborda conceitos, como desenvolvimento de software computaci-onal e implementação de servidores TCP/IP, pouco discutidos em aula; e desta maneira,abre um caminho para futuros interessados em agregar conhecimento de diversas áreas.

5.1 Sugestões para projetos futuros

Para dar sequência aos estudos e desenvolvimentos deste projeto, são alternativasplausíveis para continuidade deste trabalho:

• Inclusão de novos sensores e métodos capazes de lidar com seus respectivos dados;

• Aprimoramento da robustez do software, de modo à aumentar a quantidade demensagens que podem ser recebidas simultaneamente;

• Alteração do software para atender uma aplicação específica;

• Aplicação de técnicas de controle à partir dos dados recebidos, como um controleproporcional integral derivativo.

83

Referências

AGARWAL, A.; LANG, J. Foundations of analog and digital electronic circuits. [S.l.]:Morgan Kaufmann, 2005. 18

BARAN, P. On distributed communications networks. IEEE transactions onCommunications Systems, IEEE, v. 12, n. 1, p. 1–9, 1964. 29

BIDGOLI, H. The Internet Encyclopedia. [S.l.]: John Wiley & Sons, 2004. v. 3. 29

BRAY, T. The javascript object notation (json) data interchange format. 2014. 33

BRISCOE, N. Understanding the osi 7-layer model. PC Network Advisor, v. 120, n. 2,2000. 27

CAELUM. Um pouco sobre a história do C# e .Net. 2016. Disponível em:<https://www.caelum.com.br/apostila-csharp-orientacao-objetos/o-que-e-c-e-net/#2-1-um-pouco-sobre-a-historia-do-c-e-net>. Accesso em: 03/06/2017. 31, 32

COMMISSION, I. et al. Iso/iec 7498-1:1994, information technology - open systemsinterconnection - basic reference model: The basic model. ISO/IEC, 1994. 27

CROCKFORD, D. The application/json media type for javascript object notation (json).2006. 33

DANEELS, A.; SALTER, W. What is scada? 1999. 24

DIETRICH, E.; SMACCHIA, P. The history of C#. 2017. <https://blog.ndepend.com/c-versions-look-language-history/>. Accesso em: 05/06/2017. 31, 32

ECMA INTERNATIONAL. Standard ECMA-404 - The JSON Data InterchangeFormat. 2013. Disponível em: <http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf>. Accesso em: 10/12/2017. 32

EDWARDS, S. et al. Design of embedded systems: Formal models, validation, andsynthesis. Proceedings of the IEEE, IEEE, v. 85, n. 3, p. 366–390, 1997. 26

ELIPSE SOFTWARE. Elipse E3. 2018. Disponível em: <https://www.elipse.com.br/produto/elipse-e3/>. Accesso em: 24/01/2018. 19, 20

FERREIRA, A. A. et al. Sistema supervisório de gestão de múltiplas fontes desuprimento para aplicações em veículos elétricos. [sn], 2007. 18

FERREIRA, R. E. Linux Guia do Administrador do Sistema-2a Edição. [S.l.]: NovatecEditora, 2008. 29

GIOZZA, W. et al. Protocolos de enlace de dados. Relatório Técnico NCE, Brasil,n. 0685, 1985. 33

HAUBEN, R. From the arpanet to the internet. Retrieved November, v. 15, p. 2008,2001. 30

https://www.caelum.com.br/apostila-csharp-orientacao-objetos/o-que-e-c-e-net/#2-1-um-pouco-sobre-a-historia-do-c-e-net

https://www.caelum.com.br/apostila-csharp-orientacao-objetos/o-que-e-c-e-net/#2-1-um-pouco-sobre-a-historia-do-c-e-net

https://blog.ndepend.com/c-versions-look-language-history/

https://blog.ndepend.com/c-versions-look-language-history/

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

https://www.elipse.com.br/produto/elipse-e3/

https://www.elipse.com.br/produto/elipse-e3/

Referências 84

JACOB, J. L. Rede de telecomunicações: Comunicação de dados. Notas de Aula.Universidade Estadual de Londrina, 2017. 34

JURIZATO, L. A.; PEREIRA, P. S. R. et al. Sistemas supervisórios. Nova Odessa,Network Technologies, v. 1, p. 2, 2003. 18

LOYOLA-CAMORIM, R. D. et al. Codificação de canal com taxa variável. Monografia.Universidade Federal do Rio de Janeiro-UFRJ, 2010. 33

MAITELLI, A. L. Controladores Lógicos Programáveis. 2011. Disponível em:<http://www.dca.ufrn.br/~maitelli/FTP/clp/>. Accesso em: 22/05/2017. 17

MICROSOFT CORPORATION. Referência de C# - ushort. 2016. Disponível em:<https://docs.microsoft.com/pt-br/dotnet/csharp/language-reference/keywords/ushort>. Accesso em: 09/06/2017. 34

MICROSOFT CORPORATION. Referência de C# - byte. 2017. Disponível em:<https://docs.microsoft.com/pt-br/dotnet/csharp/language-reference/keywords/byte>.Accesso em: 09/06/2017. 34

MILLER, C. A.; PARASURAMAN, R. Designing for flexible interaction betweenhumans and automation: Delegation interfaces for supervisory control. Human factors,Sage Publications Sage CA: Los Angeles, CA, v. 49, n. 1, p. 57–75, 2007. 25

NEXT PROTOTYPES. TCP UDP Terminal. 2016. Disponível em: <https://play.google.com/store/apps/details?id=nextprototypes.tcpudpterminal&hl=pt_BR>.Accesso em: 15/12/2017. 46

NURSEITOV, N. et al. Comparison of json and xml data interchange formats: a casestudy. Caine, v. 2009, p. 157–162, 2009. 33

PARASURAMAN, R. Designing automation for human use: empirical studies andquantitative models. Ergonomics, Taylor & Francis, v. 43, n. 7, p. 931–951, 2000. 17

RAHMAN, M. C# Deconstructed: Discover How C# Works on the .Net Framework.[S.l.]: Apress, 2014. 32

REISSWITZ, F. Análise de sistemas V. 8. [S.l.]: Clube de Autores, 2009. 29

RICATO, F. T. Proposta de um sistema de monitoramento em tempo real, para estudosde determinação de economia de energia, em aquecimento solar de água. UniversidadeEstadual de Londrina, 2018. 75

SENSORWEB. SCADABR. 2017. Disponível em: <http://www.scadabr.com.br/>. 20,21

SHERIDAN, T. Human supervisory control. Design of work and development ofpersonnel in advanced manufacturing, Wiley-Interscience, p. 79–102, 1994. 25

SILVA, J. d. A. et al. Avaliação de desempenho de códigos de canal. 33

SOUZA, R. B. d. Uma arquitetura para sistemas supervisórios industriais e sua aplicaçãoem processos de elevação artificial de petróleo. [S.l.]: Universidade Federal do Rio Grandedo Norte, 2005. 24

http://www.dca.ufrn.br/~maitelli/FTP/clp/

https://docs.microsoft.com/pt-br/dotnet/csharp/language-reference/keywords/ushort

https://docs.microsoft.com/pt-br/dotnet/csharp/language-reference/keywords/ushort

https://docs.microsoft.com/pt-br/dotnet/csharp/language-reference/keywords/byte

https://play.google.com/store/apps/details?id=nextprototypes.tcpudpterminal&hl=pt_BR

https://play.google.com/store/apps/details?id=nextprototypes.tcpudpterminal&hl=pt_BR

http://www.scadabr.com.br/

Referências 85

STOUFFER, K.; FALCO, J.; SCARFONE, K. Guide to industrial control systems (ics)security. NIST special publication, v. 800, n. 82, p. 16–16, 2011. 17

TANENBAUM, A. S.; WETHERALL, D. Computer networks. 4. ed. [S.l.]: Prentice hall,2002. 34

TOGNERI, R.; CHRISTOPHER, J. Fundamentals of information theory and codingdesign. [S.l.]: CRC Press, 2003. 34

Apêndices

87

A Exemplo da Formatação JSON

1 2 " array " : [ 1 , 2 , 3 ] ,3 " number " : 123 ,4 " Pessoa " : [5 "Nome" : " João " , " Idade " : 17 , " Cidade " : " Londrina " ,6 "Nome" : " Lucas " , " Idade " : 30 , " Cidade " : " Cur i t iba " ,7 "Nome" : " Tiago " , " Idade " : 33 , " Cidade " : " São Paulo " 8 ] ,9 " Meses " : [

10 "Nome" : [ " Jane i ro " , " F e v e r e i r o " , " Março " , " Abr i l " , " Maio " , " Junho " , " Julho " , "Agosto " , " Setembro " , " Outubro " , " Novembro " , " Dezembro " ] ,

11 "Número" : [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12 ] 12 ]13

88

B Código para Cálculo da Verifica-ção Cíclica de Redundância

1 ulong CRC_Calc( byte [ ] msg)2 3 /∗4 ∗ c a l c u l a o CRC do frame , e re torna v a l o r de 16b5 ∗/6 ushort newchar ;7 int t e s t ;8 int crcword ;9 crcword = 0 x f f f f ;

1011 for ( int i = 1 ; i < (msg . Length − 3) ; i++)12 13 newchar = msg [ i ] ;14 for ( int j = 0 ; j < 8 ; j++)15 16 t e s t = ( ushort ) ( newchar & 0x00FF ) ;17 t e s t = ( ushort ) ( t e s t << ( j + 8) ) ;18 t e s t = ( ushort ) ( t e s t ^ crcword ) ;19 t e s t = ( ushort ) ( t e s t & 0x8000 ) ;2021 i f ( t e s t != 0)22 23 crcword = ( ushort ) ( crcword << 1) ;24 crcword = ( ushort ) ( crcword ^ 0x1021 ) ;25 26 else27 28 crcword = ( ushort ) ( crcword << 1) ;29 30 31 32 return ( ushort ) crcword ;33

89

C Códigos Utilizados na Metodolo-gia do Trabalho

C.1 Busca de Portas Seriais Conectadas ao Compu-tador.

1 public void Buscar_Porta_Serial ( )2 3 try4 5 /∗ Testa se a porta s e r i a l e s t á aber ta6 ∗ Se e s t i v e r , não é neces sár io a t u a l i z a r a l i s t a7 ∗ de por tas s e r i a i s8 ∗/9 i f ( ! P o r t a S e r i a l . IsOpen )

10 11 /∗ Procura as COMs d i s p o n í v e i s no computador ∗/12 foreach ( string s t r in S e r i a l P o r t . GetPortNames ( ) )13 14 /∗ Testa se a COM s t r já não e s t á adic ionada15 ∗ na l i s t a16 ∗/17 i f ( comboBox1 . FindStr ing ( s t r ) == −1)18 19 /∗ Adiciona a COM s t r na l i s t a ∗/20 comboBox1 . Items . Add( s t r ) ;21 22 23 24 25 catch ( Exception e )26 27 MessageBox . Show( e . ToString ( ) ) ;28 29

C.2 Criação de um Timer para Busca de Portas Se-riais

1 System . Timers . Timer genera l_t imer = new System . Timers . Timer (1000) ;2 public delegate void Delegate_void_NoPam ( ) ;34 private void General_timer_Handler ( object sender , ElapsedEventArgs e )5 6 i f ( ! P o r t a S e r i a l . IsOpen )7 8 Invoke (new Delegate_void_NoPam ( Buscar_Porta_Serial ) ) ;9

10

Apêndice C. Códigos Utilizados na Metodologia do Trabalho 90

C.3 Métodos para Manusear Eventos de Clique emBotões

1 private void button1_Click ( object sender , EventArgs e )2 3 /∗ swi t ch para determinar ação a ser tomada ∗/4 switch ( button1 . Text )5 6 case " Abrir Porta " :7 i f ( P o r t a S e r i a l . IsOpen )8 9 P o r t a S e r i a l . Close ( ) ;

10 11 i f ( ( comboBox1 . Text == " " ) | | ( comboBox2 . Text == " " ) )12 13 MessageBox . Show( "Os campos de c o n f i g u r a ç ã o não podem s e r de ixados em branco " ) ;14 break ;15 16 try17 18 /∗ Configuração da porta s e r i a l ∗/19 P o r t a S e r i a l . PortName = comboBox1 . Text ;20 P o r t a S e r i a l . BaudRate = int . Parse ( comboBox2 . Text ) ;21 P o r t a S e r i a l . Par i ty = Par i ty . None ;22 P o r t a S e r i a l . DataBits = 8 ;23 P o r t a S e r i a l . StopBits = StopBits . One ;24 P o r t a S e r i a l . DataReceived += new Ser ia lDataRece ivedEventHandler (

PortaSer ia l_DataReceivedHandler ) ;2526 P o r t a S e r i a l . Open ( ) ;2728 button1 . Text = " Fechar Porta " ;29 30 catch31 32 MessageBox . Show( " Erro ao a b r i r porta s e r i a l . " ) ;33 34 break ;3536 case " Fechar Porta " :37 try38 39 P o r t a S e r i a l . Close ( ) ;40 button1 . Text = " Abrir Porta " ;41 42 catch43 break ;44 45 4647 private void button2_Click ( object sender , EventArgs e )48 49 /∗ As mensagens só podem ser enviadas se a porta s e r i a l e s t i v e r aber ta50 ∗ e se o campo de dados não e s t i v e r vaz io51 ∗/52 i f ( P o r t a S e r i a l . IsOpen && richTextBox2 . Text != " " )53


54 /∗ Os dados i n s e r i d o s na caixa de t e x t o55 ∗ serão enviados em ASCII56 ∗/57 P o r t a S e r i a l . Write ( richTextBox2 . Text ) ;58 richTextBox1 . AppendText ( "TX: " + richTextBox2 . Text + " \ r \n " ) ;59 richTextBox2 . Clear ( ) ;60 61

C.4 Método Utilizado para Recebimento de Dadosda Porta Serial

1 private void PortaSer ia l_DataReceivedHandler ( object sender ,Ser ia lDataReceivedEventArgs e )

2 3 S e r i a l P o r t S e r i a l = ( S e r i a l P o r t ) sender ;4 int bytes = S e r i a l . BytesToRead ;5 byte [ ] r e c e b ido = new byte [ bytes ] ;6 S e r i a l . Read ( receb ido , 0 , bytes ) ;7 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 , "

RX: " + Encoding . ASCII . GetStr ing ( r e c eb i do ) + " \ r \n " ) ;8 9 public delegate void Delegate_void_String ( RichTextBox textbox , string t ex t ) ;

10 public void Append_Text ( RichTextBox textbox , string t ex t )11 12 textbox . AppendText ( t ex t ) ;13

C.5 Busca Automática de IP1 using System . Net ;2 using System . Net . Sockets ;34 string IP4_Endereco ;5 string IP4_Porta ;67 public void Encontrar_IP ( )8 9 try

10 11 /∗12 ∗ Este loop i r á procurar por endereços DNS e determinar o IP13 ∗ da máquina u t i l i z a d a14 ∗/15 foreach ( IPAddress IPA in Dns . GetHostAddresses (Dns . GetHostName ( ) ) )16 17 i f (IPA . AddressFamily == AddressFamily . InterNetwork )18 19 IP4_Endereco = IPA . ToString ( ) ;20 break ;21 22 23 textBox1 . Text = IP4_Endereco ;24 /∗25 ∗ Será u t i l i z a d o como porta padrão a porta 500126 ∗/


27 textBox2 . Text = " 5001 " ;28 29 catch 30

C.6 Abertura de um Servidor TCP/IP quando OcorreUm Clique em um Botão

1 private void button1_Click ( object sender , EventArgs e )2 3 try4 5 /∗ Neste swi tch é tomada a dec i são de a b r i r ou fechar6 o s e r v i d o r conforme o t e x t o do botão . ∗/7 switch ( button1 . Text )8 9 case " Abrir Se rv idor " :

10 /∗ Testa se a ca i xas de t e x t o não es tão v a z i a s . Se es t i verem11 ∗ não é p o s s í v e l a b r i r o s e r v i d o r . ∗/12 i f ( ( textBox1 . Text == " " ) && ( textBox2 . Text == " " ) )13 14 MessageBox . Show( "O s e r v i d o r TCP/IP não pode s e r i n i c i a d o com parâmetros em branco .

" , " Atenção " ) ;15 return ;16 17 /∗ A t r i b u i uma nova i n s t â n c i a TcpListener na v a r i á v e l servidorTCP .18 ∗ Converte os v a l o r e s das ca i xas de t e x t o para formato apropriado19 ∗ para o s e r v i d o r . ∗/20 servidorTCP = new TcpListener ( IPAddress . Parse ( textBox1 . Text ) , Int32 . Parse ( textBox2

. Text ) ) ;21 /∗ I n i c i a o s e r v i d o r TCP∗/22 servidorTCP . Sta r t ( ) ;23 /∗ Escrever na caixa de LOG que o s e r v i d o r e s t á conectado ∗/24 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,25 string . Format ( " Se rv idor conectado . IP : 0 . Porta : 1 . " , textBox1 . Text ,

textBox2 . Text ) ) ;26 /∗Dá i n i c i o a uma operação ass íncrona que i r á aguardar uma conexão27 de c l i e n t e . É neces sár io passar um c a l l b a c k que será executado quando28 ocorrer a conexão e o um o b j e t o para ser manuseado , nes te caso a v a r i a v e l29 do s e r v i d o r . ∗/30 servidorTCP . BeginAcceptTcpClient ( Cal lback_Ace i tarCl iente , servidorTCP ) ;31 /∗ Altera o t e x t o do botão para quando ocorrer um novo c l i q u e , f eche o32 s e r v i d o r . ∗/33 button1 . Text = " Fechar Serv idor " ;34 break ;3536 case " Fechar Serv idor " :37 /∗Para fechar o s e r v i d o r sem causar erros , pr imeiro é neces sár io f echar a stream

de dados .38 É uma boa p r á t i c a t e s t a r se os e lementos não são nulos antes de manipula los39 ∗/40 i f ( streamTCP != null )41 42 streamTCP . Close ( ) ;43 44 /∗ Agora é p o s s í v e l f echar o s e r v i d o r sem que aconteçam maiores problemas ∗/45 i f ( servidorTCP != null )


46 47 servidorTCP . Stop ( ) ;48 49 /∗ Voltamos o botão para a função de a b r i r s e r v i d o r ∗/50 button1 . Text = " Abrir Se rv idor " ;51 break ;52 53 54 /∗ Aqui r e a l i z a −se o tratamento de erros , nes te caso apenas iremos fechar a stream

de dados55 ∗ e o s e r v i d o r em caso de erro , e entao re tornar o botão para a função de a b r i r

s e r v i d o r ∗/56 catch ( Exception ex )57 58 ex . ToString ( ) ;59 MessageBox . Show( " Houve um e r r o no s e r v i d o r TCP. O s e r v i d o r f o i fechado . " , " Atenção

" ) ;60 i f ( streamTCP != null )61 62 streamTCP . Close ( ) ;63 64 i f ( servidorTCP != null )65 66 servidorTCP . Stop ( ) ;67 68 button1 . Text = " Abrir Se rv idor " ;69 70

C.7 Métodos Callback Utilizados para o Servidor TCP/IP

1 private void Cal lback_Ace i tarCl i ente ( IAsyncResult ar )2 3 /∗Faz−se uma transformação de o b j e t o para TcpListener para que o código t r a t e4 ∗ a v a r i á v e l des ta maneira ∗/5 servidorTCP = ar . AsyncState as TcpListener ;6 /∗ Testa se a v a r i á v e l não é nula . Caso se ja , f i n a l i z a o método ∗/7 i f ( servidorTCP == null )8 9 return ;

10 1112 try13 14 /∗ Termina a ace i tação do c l i e n t e TCP de forma ass incrona e adic iona o c l i e n t e na

v a r i a v e l15 ∗ clienteTCP ∗/16 clienteTCP = servidorTCP . EndAcceptTcpClient ( ar ) ;17 /∗ Retorna a stream de dados do c l i e n t e para que s e j a p o s s í v e l manipula−l a lendo

ou escrevendo18 ∗ dados ∗/19 streamTCP = clienteTCP . GetStream ( ) ;20 byte [ ] b u f f e r = new byte [ 1 0 0 ] ;21 /∗ Lei tura ass íncrona da stream de dados ∗/22 streamTCP . BeginRead ( bu f f e r , 0 , b u f f e r . Length , Cal lback_LerCl iente , cl ienteTCP ) ;23 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,24 string . Format ( " C l i e n t e conectado . " ) ) ;25


26 catch 27 2829 private void Cal lback_LerCl iente ( IAsyncResult ar )30 31 /∗Faz−se uma transformação de o b j e t o para TcpClient para que o código t r a t e32 ∗ a v a r i á v e l des ta maneira ∗/33 clienteTCP = ar . AsyncState as TcpClient ;34 /∗ Cria o b u f f e r onde será armazenada a l e i t u r a ∗/35 byte [ ] bytes = new byte [ 1 0 2 4 ] ;36 int i ;37 /∗ Apenas deve−se a b r i r a stream de dados se o c l i e n t e e s t i v e r conectado ∗/38 i f ( cl ienteTCP . Connected )39 40 streamTCP = clienteTCP . GetStream ( ) ;41 42 /∗ Testa se a stream pode ser l i d a e se o c l i e n t e e s t á conectado , enquanto i s t o

f o r verdade i ro43 ∗ deve−se checar se há dados d i s p o n í v e i s para serem l i d o s ∗/44 while ( cl ienteTCP . Connected && streamTCP . CanRead)45 46 i f ( streamTCP . DataAvai lable )47 48 i = streamTCP . Read ( bytes , 0 , bytes . Length ) ;49 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,50 string . Format ( " Mensagem rece b id a : 0 " , Encoding .UTF8. GetStr ing ( bytes , 0 , i ) ) ) ;51 52 5354 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,55 "O c l i e n t e se desconectou " ) ;56

C.8 Implementação do Envio de Mensagens do Ser-vidor TCP/IP

1 private void button2_Click ( object sender , EventArgs e )2 3 try4 5 /∗ Testa de o campo de dados não e s t á vaz io ∗/6 i f ( richTextBox2 . Text == " " )7 8 MessageBox . Show( "Não há mensagem a s e r enviada " , " Atenção " ) ;9 return ;

10 11 /∗ Testa se o s e r v i d o r e a stream de dados es tão f u n c i o n a i s ∗/12 i f ( ( servidorTCP == null ) | | ( streamTCP == null ) | | ( streamTCP . CanWrite == fa l se ) )13 14 MessageBox . Show( "Não f o i p o s s í v e l env ia r a mensagem . Problema com o s e r v i d o r ou

com a stream de dados " , " Atenção " ) ;15 return ;16 17 /∗ Converte o t e x t o da richTextBox2 para um v e to r de b y t e s ∗/18 byte [ ] t exto = Encoding . ASCII . GetBytes ( richTextBox2 . Text ) ;19 /∗ Envia o ve t or t e x t o pe la stream de dados para o c l i e n t e ∗/20 streamTCP . Write ( texto , 0 , t exto . Length ) ;


21 /∗ Escreve em richTextBox1 a mensagem enviada ∗/22 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,23 string . Format ( " Mensagem enviada : 0 " , richTextBox2 . Text ) ) ;24 richTextBox2 . Clear ( ) ;25 26 catch 27

C.9 Implementação do Método Tratar_Mensagem1 private void Tratar_Mensagem ( byte [ ] mensagem )2 3 /∗4 ∗ Cria uma s t r i n g contendo a data e hora a t u a l a p a r t i r do r e l ó g i o in terno do

computador .5 ∗ O formato da data será do t i p o : [ dd/mm/aa − hh :mm: ss ]6 ∗/7 string timestamp = string . Format ( " [0/1/2 − 3 : 4 : 5 ] " , DateTime .Now.

ToString ( " dd " ) , DateTime .Now. ToString ( "MM" ) ,8 DateTime .Now. ToString ( " yy " ) , DateTime .Now. ToString ( "HH" ) , DateTime .Now. ToString ( "

mm" ) , DateTime .Now. ToString ( " s s " ) ) ;9 i f ( mensagem == null )

10 11 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,12 string . Format ( " 0 − A mensagem rec eb i da e s t á vaz ia . \ r \n" , timestamp ) ) ;13 return ;14 1516 /∗17 ∗ Agora é r e a l i z a d o o t e s t e se a mensagem é vá l ida , ou se ja , se tem os v a l o r e s

esperados como18 ∗ i n í c i o e fim de mensagem .19 ∗ I n í c i o de mensagem == 0x0A20 ∗ Fim de mensagem == 0xA0 .21 ∗/22 i f ( ( mensagem [ 0 ] != 0x0A) | | ( mensagem [ mensagem . Length − 1 ] != 0xA0) )23 24 /∗25 ∗ Se a mensagem f o r i n v á l i d a , apenas aparecerá o a l e r t a na t e l a e f i n a l i z a o

método .26 ∗/27 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,28 string . Format ( " 0 − A mensagem rec eb i da é i n v á l i d a . \ r \n" , timestamp ) ) ;29 return ;30 31 else32 33 /∗34 ∗ Se a mensagem f o r vá l ida , também é e s c r i t a a mensagem na t e l a .35 ∗/36 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,37 string . Format ( " 0 − A mensagem rec eb i da é v á l i d a . \ r \n Mensagem re ceb i da : 1 .\ r \

n " , timestamp , BitConverter . ToString ( mensagem ) . Replace ( ’ − ’ , ’ ’ ) ) ) ;38 return ;39 40


C.10 Salvar LOG em *.txt

1 private void button3_Click ( object sender , EventArgs e )2 3 /∗4 ∗ Para nomear o arquivo será u t i l i z a d a a data a t u a l5 ∗ Para i s t o u t i l i z a −se a e s t r u t u r a DateTime .6 ∗/7 string str_aux = string . Format ( " 0−1−2 LOG" , DateTime .Now. ToString ( " yy " ) ,8 DateTime .Now. ToString ( "MM" ) , DateTime .Now. ToString ( " dd " ) ) ;9 /∗

10 ∗ U t i l i z a a c l a s s e SaveFi leDia log , que h a b i l i t a o usuár io e s c o l h e r11 ∗ onde dese ja s a l v a r o arquivo .12 ∗/13 SaveFi l eDia log s a v e F i l e D i a l o g 1 = new SaveFi l eDia log ( ) ;14 /∗15 ∗ Define que arqu ivos de t e x t o ( ∗ . t x t ) será o t i p o padrão do arquivo16 ∗/17 s a v e F i l e D i a l o g 1 . DefaultExt = " ∗ . tx t " ;18 s a v e F i l e D i a l o g 1 . F i l t e r = " txt f i l e s | ∗ . tx t " ;19 /∗20 ∗ Já i n c l u i o nome automaticamente no arquivo21 ∗/22 s a v e F i l e D i a l o g 1 . FileName = str_aux ;23 /∗24 ∗ aguarda o usuário d e c i d i r onde s a l v a r á o arquivo25 ∗/26 try27 28 /∗29 ∗ Abre a j a n e l a para que o usuário s a l v e o arquivo .30 ∗ Se não houver f a l h a s no processo , será e x i b i d o um pop−up indicando i s t o ;31 ∗ ou , caso ocorra uma f a l h a ou o usuário cance l e a operação de s a l v a r o arquivo32 ∗ também será e x i b i d o um pop−up .33 ∗/34 i f ( s a v e F i l e D i a l o g 1 . ShowDialog ( ) == Dia logResu l t .OK)35 36 // s a l v a o arquivo37 richTextBox2 . SaveFi l e ( s a v e F i l e D i a l o g 1 . FileName , RichTextBoxStreamType .

UnicodePlainText ) ;38 MessageBox . Show( " Arquivo Salvo " ) ;39 40 else41 42 MessageBox . Show( " Arquivo não f o i s a l v o " ) ;43 44 45 catch46 47 /∗48 ∗ av i sa caso ocorra alguma exceção de so f tware49 ∗/50 MessageBox . Show( " Falha " ) ;51 52


C.11 Classe de Dados para Arquivo JSON

1 using Newtonsoft . Json ;23 public class Mensagem4 5 public string Data = string . Format ( " 0/1/2 " , DateTime .Now. ToString ( " dd " ) ,

DateTime .Now. ToString ( "MM" ) ,6 DateTime .Now. ToString ( " yy " ) ) ;7 public string Hora = string . Format ( " 0 :1 :2 " , DateTime .Now. ToString ( "HH" ) ,

DateTime .Now. ToString ( "mm" ) ,8 DateTime .Now. ToString ( " s s " ) ) ;9 public string msg_recebida ;

10 public Mensagem( string msg)11 12 msg_recebida = msg ;13 14

C.12 Criando Arquivo Formatado em JSON

1 private void Criar_Arquivo_JSON ( string msg)2 3 /∗4 ∗ Cria uma nova v a r i á v e l do t i p o ’Mensagem ’ conforme cr iado anteriormente5 ∗/6 Mensagem MSG_Save = new Mensagem(msg) ;7 /∗8 ∗ U t i l i z a a b i b l i o t e c a Newtonsoft para conver ter a s t r u c t para o formatato9 ∗ j son .

10 ∗/11 string j s o n _s t r i n g = JsonConvert . S e r i a l i z e O b j e c t (MSG_Save) ;12 try13 14 /∗15 ∗ Determina automaticamente a pasta ( f o l d e r ) onde o arquivo será sa lvo ,16 ∗ será s a l v o na pasta onde e s t á sendo executado o so f tware .17 ∗/18 S t r i n g FolderPath = Path . Combine ( Path . GetDirectoryName ( System . R e f l e c t i o n . Assembly .

GetExecutingAssembly ( ) . Locat ion ) ) ;19 /∗20 ∗ Li s ta todos os arqu ivos cont idos na pasta para determinar se é neces sár io c r i a r

um novo arquivo21 ∗ ou se já e x i s t e um arquivo com o nome dese jado22 ∗/23 string [ ] ArquivosnaPasta = Direc tory . GetF i l e s ( FolderPath ) ;24 /∗25 ∗ Testa se e x i s t e um arquivo com o nome dese jado ; caso não e x i s t a , será cr iado um

novo arquivo26 ∗ e será informado na i n t e r f a c e do usuário onde o arquivo será s a l v o27 ∗/28 i f ( ! ArquivosnaPasta . Contains ( FolderPath + string . Format ( " \\Exemplo Arquivo JSON.

txt " ) ) )29 30 /∗31 ∗ Cria o arquivo com o nome : Exemplo Arquivo JSON. t x t32 ∗/


33 using ( StreamWriter sw = F i l e . CreateText ( FolderPath + string . Format ( " \\ExemploArquivo JSON. txt " ) ) )

34 35 /∗36 ∗ Informa ao usuário onde o novo arquivo será s a l v o37 ∗/38 BeginInvoke (new Delegate_void_String ( Append_Text ) , new object [ ] richTextBox1 ,39 string . Format ( " Arquivo JSON s a l v o em : 0\ r \n " , FolderPath ) ) ;40 /∗41 ∗ Escreve a s t r i n g formatada em JSON e pula uma l i n h a42 ∗/43 sw . Write ( j s o n_ s t r i n g + " \ r \n " ) ;44 45 46 else47 48 using ( StreamWriter sw = F i l e . AppendText ( FolderPath + string . Format ( " \\Exemplo

Arquivo JSON. txt " ) ) )49 50 /∗51 ∗ Escreve a s t r i n g formatada em JSON e pula uma l i n h a52 ∗/53 sw . Write ( j s o n_ s t r i n g + " \ r \n " ) ;54 55 56 57 catch ( Exception )58 59 throw ;60 61

desenvolvimentodesistemasupervisório … · 2019-03-23 · aberto, de modo que seja possível...

Documents