Você está na página 1de 98

Universidade Estadual de Londrina

Centro de Tecnologia e Urbanismo


Departamento de Engenharia Elétrica

Pedro Henrique Batista Bonifácio

Desenvolvimento de Sistema Supervisório


para Aquisição de Dados de Sensores
Embarcados Através do Protocolo TCP/IP

Londrina
2018
1

Universidade Estadual de Londrina


Centro de Tecnologia e Urbanismo
Departamento de Engenharia Elétrica

Pedro Henrique Batista Bonifácio

Desenvolvimento de Sistema Supervisório para


Aquisição de Dados de Sensores Embarcados Através
do Protocolo TCP/IP

Trabalho de Conclusão de Curso orientado pelo Prof. Dr. Aziz


Elias 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 Estadual
de Londrina, como parte dos requisitos necessários para a obtenção
do Título de Bacharel em Engenharia Elétrica.

Orientador: Prof. Dr. Aziz Elias Demian Junior

Londrina
2018
2

Ficha Catalográfica

Pedro Henrique Batista Bonifácio


Desenvolvimento de Sistema Supervisório para Aquisição de Dados de Sensores
Embarcados Através do Protocolo TCP/IP - Londrina, 2018 - 98 p., 30 cm.
Orientador: Prof. Dr. Aziz Elias Demian Junior
1. 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 Sensores
Embarcados Através do Protocolo TCP/IP.
3

Pedro Henrique Batista Bonifácio

Desenvolvimento de Sistema Supervisório


para Aquisição de Dados de Sensores
Embarcados Através do Protocolo TCP/IP

Trabalho de Conclusão de Curso apresentado ao Curso de


Engenharia Elétrica da Universidade Estadual de Londrina,
como requisito parcial para a obtenção do título de Bacharel
em Engenharia Elétrica.

Comissão Examinadora

Prof. Dr. Aziz Elias Demian Junior


Universidade Estadual de Londrina
Orientador

Prof. Dr. Ernesto Fernando Ferreyra


Ramírez
Universidade Estadual de Londrina

Prof. Dr. Leonimer Flávio de Melo


Universidade Estadual de Londrina

Londrina, 26 de janeiro de 2018


4

Dedico este trabalho à todos


que 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 escolhas


que 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 quando
tudo pareceu desabar, e também por entenderem minhas ausências. Vocês são formadores
do 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 distantes
e ainda mais por estar ao meu lado quando tudo parecia dar errado. Agradeço aos meus
amigos; os que sempre estiveram em minha vida, Augusto Henrique Salla Rosa, Daniel
Ramari, Fernanda Galo Gentilin, Gustavo Henrique Nogueira, Lucas Freire Dutra, Luiz
Henrique 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, discos
voadores e Ypiocas. Me desculpem por não ser o melhor amigo do mundo e me ausentar
muitas 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 para
a 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 passagem
de conhecimento e experiência. Agradeço à Universidade Estadual de Londrina por me
proporcionar toda a experiência vivida dentro campus, e ainda mais pelas experiências
ocorridas além dos limites do campus.
Agradecimentos 6

1 PN
B> N i=1 Xi
"Be greater than average."
Agradecimentos 7

Pedro Henrique Batista Bonifácio. Desenvolvimento de Sistema Supervisório para


Aquisiçã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 - Universidade
Estadual de Londrina, Londrina.

Resumo
A partir do início da automação industrial começaram a ser implementados os sistemas
supervisó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 de
código aberto para uso de estudantes utilizando a linguagem de programação C#. São
citados conceitos como sistemas embarcados, modelo de comunicação OSI, formatação
JSON e verificação de redundância cíclica. Foi desenvolvido um protocolo de mensagens
aberto, 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 foram
definidos com base em sensores e placas que são amplamente utilizados por estudantes
de graduação, de modo que tenham fácil acesso a estes módulos. O software inicia um
servidor 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 a
exibição dos dados recebidos de sensores. Por fim, foram executados testes para comprovar
as capacidades do sistema supervisório desenvolvido, seja para quantidade de mensagens
manipuladas, quanto para tempo máximo de execução. Outras funcionalidades incluem
possiblidade de salvar log de mensagens, criação de arquivos formatados em JSON e
criação de tabelas a partir destes dados. O desempenho demonstrado pelo software se
mostrou satisfatório, de modo que os requisitos de projeto foram atendidos.

Palavras-Chave: 1. SCADA. 2. Linguagem C#. 3. Monitoramento. 4. Sistemas


Embarcados. 5. Automação.
Agradecimentos 8

Pedro Henrique Batista Bonifácio. Development of a supervisory system for data


aquisition on embedded sensors by TCP/IP Protocol. 2018. 98 p. Monograph in
Engenharia Elétrica - Universidade Estadual de Londrina, Londrina.

Abstract
From 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 acquisition
systems started to be developed. This type of software was interesting because of its
characteristics and capabilities; so that several areas started to use it. This work aimed
to develop an open source supervisory system for student use, it was developed using
the C# programming language. Important concepts such as embedded systems, OSI
communication model, JSON format and cyclic redundancy check were mentioned. An
open messaging protocol has been developed so that it is possible to address receivers
and 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 used
by undergraduates, so that they have easy access to these modules to start using this
software. The SCADA software starts a TCP / IP server and waits for connections from
clients ready to send messages; it is also possible to send messages through serious ports
connected to the computer. Graphical interfaces have been developed, such as gauges and
time-varying graphs, to display the data received from sensors. Finally, tests were carried
out to prove the capabilities of the supervisory system developed for both the number
of messages manipulated and the maximum execution time. Other features include the
ability to save messages, create JSON-formatted files, and create tables from these data.
The performance demonstrated by the software was satisfactory, so that the requirements
were 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 Elipse


Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 2 – Interface gráfica do software Elipse. . . . . . . . . . . . . . . . . . . . . 19
Figura 3 – Interface gráfica do software SCADABR. . . . . . . . . . . . . . . . . . 20
Figura 4 – Interface gráfica do software SCADABR. . . . . . . . . . . . . . . . . . 21
Figura 5 – Escopo do sistema supervisório a ser desenvolvido.. . . . . . . . . . . . 22
Figura 6 – Tela inicial do Visual Studio. . . . . . . . . . . . . . . . . . . . . . . . 35
Figura 7 – Tela para criação de um novo projeto. . . . . . . . . . . . . . . . . . . 36
Figura 8 – Novo projeto criado no Visual Studio. . . . . . . . . . . . . . . . . . . 37
Figura 9 – Criação da interface para demonstração do uso da porta serial. . . . . . 38
Figura 10 – Demonstração de um RichTextBox selecionado. . . . . . . . . . . . . . 38
Figura 11 – Alteração da interface. . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 12 – Interface após alteração dos textos de exibição dos componentes. . . . . 40
Figura 13 – Propriedades do componente ComboBox2. . . . . . . . . . . . . . . . . 40
Figura 14 – Incluindo valores de baudrate no componente ComboBox2. . . . . . . . 41
Figura 15 – Software desenvolvido nesta seção, incluindo mensagens transmitida e
recebida. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Figura 16 – Organização da interface gráfica para o usuário para o software de
demonstração de um servidor TCP/IP. . . . . . . . . . . . . . . . . . . 44
Figura 17 – Interface gráfica para o usuário para o software de demonstração de um
servidor TCP/IP após renomear os componentes. . . . . . . . . . . . . 45
Figura 18 – Configuração do aplicativo TCP UDP Terminal como cliente TCP. . . 47
Figura 19 – Demonstração da comunicação entre cliente e servidor mostrados na
tela do aplicativo TCP UDP Terminal. . . . . . . . . . . . . . . . . . . 48
Figura 20 – Demonstração da comunicação entre servidor e cliente mostrados na
interface gráfica do software desenvolvido. . . . . . . . . . . . . . . . . 48
Figura 21 – Demonstração de como o software se comportar após a introdução do
método de análise de mensagem. . . . . . . . . . . . . . . . . . . . . . 50
Figura 22 – Abrindo o gerenciador de bibliotecas Nuget. . . . . . . . . . . . . . . . 52
Figura 23 – Gerenciador de bibliotecas Nuget. . . . . . . . . . . . . . . . . . . . . . 52
Figura 24 – Instalando a biblioteca Newtonsoft. . . . . . . . . . . . . . . . . . . . . 53
Figura 25 – Interface gráfica do usuário informando onde o arquivo será salvo. . . . 54
Figura 26 – Tela inicial do sistema supervisório. . . . . . . . . . . . . . . . . . . . . 69
Figura 27 – Configurações iniciais do sistema supervisório. . . . . . . . . . . . . . . 69
Figura 28 – Interface para exibição do log de dados. . . . . . . . . . . . . . . . . . . 70
Lista de ilustrações 11

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


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

Lista de tabelas

Tabela 1 – Configuração dos componentes. . . . . . . . . . . . . . . . . . . . . . . 39


Tabela 2 – Configuração dos componentes para o software de demonstração de um
servidor TCP/IP.. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 3 – Formato do protocolo de comunicação implementado no projeto. . . . . 55
Tabela 4 – Formato do cabeçalho da mensagem do protocolo. . . . . . . . . . . . . 56
Tabela 5 – Separação do protocolo com seus respectivos campos. . . . . . . . . . . 57
Tabela 6 – Comando de requisição de dados para o acelerômetro. . . . . . . . . . 57
Tabela 7 – Resposta do sistema monitorado para o comando de leitura do acelerô-
metro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Tabela 8 – Comando de requisição de dados para o sensor de temperatura. . . . . 59
Tabela 9 – Resposta do sistema monitorado para o comando de leitura do sensor
de temperatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Tabela 10 – Variação da resolução da saída analógica conforme o modelo do CI
ACS712. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tabela 11 – Comando de requisição de dados para o sensor de corrente. . . . . . . . 60
Tabela 12 – Resposta do sistema monitorado para o comando de leitura do sensor
de corrente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Tabela 13 – Comando de requisição de dados para o sensor de ultrassônico. . . . . 61
Tabela 14 – Resposta do sistema monitorado para o comando de leitura do sensor
ultrassônico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Tabela 15 – Comando de requisição de dados para o magnetômetro. . . . . . . . . . 62
Tabela 16 – Resposta do sistema monitorado para o comando de leitura do mag-
netômetro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Tabela 17 – Envio de comandos para o relógio de tempo real. . . . . . . . . . . . . 63
Tabela 18 – Parâmetros do RTC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Tabela 19 – Resposta do sistema monitorada para o comando de leitura dos dados
do relógio de tempo real. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Tabela 20 – Envio de comandos para as portas digitais. . . . . . . . . . . . . . . . . 66
Tabela 21 – Resposta do sistema monitorado para os comandos das portas digitais. 66
Tabela 22 – Envio de comandos para as portas analógicas. . . . . . . . . . . . . . . 67
Tabela 23 – Resposta do sistema monitorado para os comandos das portas analógicas. 68
Tabela 24 – Medições dos testes de capacidade de recebimento de mensagens atra-
vés da porta serial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Tabela 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 Interface


ARPANET Advanced Research Project Agency Network
CERN Conseil Européen pour la Recherche Nucléaire
CLI Common Intermediate Language
CLP Controladores lógicos programáveis
CLR Common Intermediate Runtime
COOL C-Like Object Oriented Language
CRC Cyclic Redundancy Check
EOF End of Frame
HMI Humam Machine Interface
ICS Industrial Control System
IDE Integrated Development Environment
IOT Internet of Things
IP Internet Protocol
ISO International Organization for Standardization
JSON JavaScript Object Notation
LINQ Language Integrated Query
LOA Levels of Automation
OSI Open System Interconnection
SOF Start od Frame
SCADA Supervisory Control and Data Aquisition
SCD Sistemas de controle distribuído
TCP Transmission Control Protocol
UCL University College London
15

Sumário

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

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

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

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1 Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.1 Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.2 Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.3 Metodologia do Trabalho . . . . . . . . . . . . . . . . . . . . . . . 23

2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . 24
2.1 Sistemas Supervisórios de Controle e Aquisição de Dados . . 24
2.2 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.3 Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Protocolo de Comunicação TCP/IP . . . . . . . . . . . . . . . . 29
2.5 Framework .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5.1 Linguagem C# . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.5.2 Compilação e Execução . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 JSON - JavaScript Object Notation . . . . . . . . . . . . . . . . 32
2.7 Verificação Cíclica de Redundância . . . . . . . . . . . . . . . . . 33

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1 Criando um novo projeto utilizando Visual Studio . . . . . . . 35
3.2 Porta serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3 Servidor TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Tratamento de mensagens . . . . . . . . . . . . . . . . . . . . . . 49
3.5 Salvar arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.6 Definição do Protocolo de Mensagens . . . . . . . . . . . . . . . 55
3.7 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.1 Acelerômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.2 Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.7.3 Corrente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.7.4 Sensor Ultrassônico . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Sumário 16

3.7.5 Magnetômetro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.7.6 Relógio de Tempo Real - RTC . . . . . . . . . . . . . . . . . . . . 63
3.7.7 Porta Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.7.8 Porta Analógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.8 Design da interface de usuário . . . . . . . . . . . . . . . . . . . . 68
3.9 Hardware de testes . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.9.1 Arduino Mega . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.9.2 STM32F4DISCOVERY . . . . . . . . . . . . . . . . . . . . . . . . 75
3.9.3 Trabalho de Conclusão de Curso . . . . . . . . . . . . . . . . . . 75

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

5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.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ÍCLICA


DE REDUNDÂNCIA . . . . . . . . . . . . . . . . . . . . . . . . 88

C CÓDIGOS UTILIZADOS NA METODOLOGIA DO TRA-


BALHO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
C.1 Busca de Portas Seriais Conectadas ao Computador. . . . . . 89
C.2 Criação de um Timer para Busca de Portas Seriais . . . . . . . 89
C.3 Métodos para Manusear Eventos de Clique em Botões . . . . 90
C.4 Método Utilizado para Recebimento de Dados da Porta Serial 91
C.5 Busca Automática de IP . . . . . . . . . . . . . . . . . . . . . . . 91
C.6 Abertura de um Servidor TCP/IP quando Ocorre Um Clique
em um Botão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
C.7 Métodos Callback Utilizados para o Servidor TCP/IP . . . . 93
C.8 Implementação do Envio de Mensagens do Servidor TCP/IP 94
C.9 Implementação do Método Tratar_Mensagem . . . . . . . . . 95
C.10 Salvar LOG em *.txt . . . . . . . . . . . . . . . . . . . . . . . . . . 96
C.11 Classe de Dados para Arquivo JSON . . . . . . . . . . . . . . . 97
C.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 atender
a constante imposição do mercado consumidor por diversidade e qualidade. O progresso
da automação não altera apenas a produção fabril ao aumentar a produtividade quando
má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 definido
como um arranjo de técnicas aplicadas à tornar processos industriais independentes da
ação direta humana, visando poupar tempo e esforço do trabalhador, bem como gerar
economia 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 e
petróleo, farmacêutica, transportes, automotiva e aeroespacial, surge a necessidade de
realizar um controle fino destes sistemas que são responsáveis por inúmeros processos de
risco dentro de uma planta industrial (STOUFFER; FALCO; SCARFONE, 2011). A
partir disto, começa-se à empregar os sistemas de controle indutrial, do inglês Industrial
Control 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 sua
complexidade, cada vez se torna mais imprescindível a implementação de um controle
automatizado; 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 tipos
de 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 podem
ser 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 chamados
transdutores, dispositivos capazes de converter um tipo de energia em outro; podem ser
citados como exemplos de transdutores os sensores piezoelétricos, que é capaz de converter
pressã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 sistemas
mais complexos, como microcontroladores, para que seja possível analisá-los, interpretá-
los e tomar decisões baseadas nestas informações (AGARWAL; LANG, 2005). Saber lidar
com 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 Internet
das 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 tem
como base a aplicação e desenvolvimento de tecnologia, como engenharia elétrica e ciência
da 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, transdutores
ou quaisquer outros dispositivos; valores os quais normalmente são apresentados na base
hexadecimal, que é amplamente adotada em programação e arquitetura de microcon-
troladores. Além da dificuldade de muitas pessoas em interpretar os valores nesta base
numé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 para
valores específicos, para que se tornem compreensíveis.
Os sistemas supervisórios tem uma vasta aplicação; portanto, há diversos trabalhos
acadêmicos realizados que abordam este tema e também já existem sistemas open source
abertos 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 eram
utilizados principalmente em plantas industriais. O autor também apresenta argumentos
que 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 softwares
disponí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 sistema
supervisó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ência
do sistema de modo à fornecer a energia necessária para o funcionamento do veículo. Para
verificar 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 gratuitos
quanto pagos; os mais conhecidos são: Elipse, desenvolvido pela Elipse Software, e o
ScadaBR, desenvolvido em conjunto pela empresa SensorWeb, pela Fundação CERTI e a
Universidade 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ções
de energia, parques eólicos e gestão de linhas ferroviárias. A empresa fornece diversos
produtos para atender todos os requisitos dos clientes; começando pelo software Elipse
E3, que é um sistema ideal para sistemas de missão crítica, fornecendo desde uma interface
Capítulo 1. Introdução 19

homem-máquina simples até complexos centros de operação. Outros produtos que podem
ser citados são o Elipse Mobile, que fornece uma integração de plataformas móveis e
sistemas de automação; e também tem-se o Elipse Gateway que funciona como uma
ferramenta de conversão de protocolos elétricos e industriais. A integração das diversas
soluções pode formar um sistema extremamente completo e resistente conforme ilustrado
na 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 utilizando
o sistema supervisório Elipse.

Figura 2 – Interface gráfica do software Elipse.

Fonte: (ELIPSE SOFTWARE, 2018).


Capítulo 1. Introdução 20

A desvantagem de utilizar-se o software Elipse, é a limitação imposta por ser um


sistema pago (ELIPSE SOFTWARE, 2018). Grande parte das funcionalidades não esta
disponível para um usuário qualquer.
Já o ScadaBR, é um sistema livre, gratuito e de código-fonte aberto; muito utilizado
para para desenvolvimento de aplicações de Automação, Aquisição de Dados e Controle
Supervisó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 de
monitorar 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 para
a comunidade, é gozar de um vasto suporte, uma grande documentação e um fórum de
discussão amplo (SENSORWEB, 2017). As Figuras 3 e 4 ilustram exemplos da interface
gráfica que pode ser obtida ao utilizar este sistema.

Figura 3 – Interface gráfica do software SCADABR.

Fonte: (SENSORWEB, 2017).


Capítulo 1. Introdução 21

Figura 4 – Interface gráfica do software SCADABR.

Fonte: (SENSORWEB, 2017).

A desvantagem de utilizar o ScadaBR é a necessidade de se instalar o Java Runtime


Environment - JRE para que se possa executar o programa, isto aumenta a complexidade
das 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ções
ou 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 podem
ser um tanto quanto exagerados, tanto em funções oferecidas quando em complexidade
de instalação ou limitações de licenças.

1.1 Justificativa
Por serem amplamente utilizados na indústria, muitos fornecedores de equipamentos
já 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ão
permitem integração com outros equipamentos, de outras fabricantes ou protótipos de
estudantes; desta maneira, se torna inviável monitorar toda uma linha de produção ou
um projeto acadêmico em um sistema unificado.
Capítulo 1. Introdução 22

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 que
possa 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 que
este projeto seja considerado aberto, é necessário que algumas liberdades básicas sejam
fornecidas para o usuário: liberdade para executar o código, como quiser e para qualquer
propósito; de estudar e adaptar o código-fonte às suas necessidades; de redistribuir cópias
do código-fonte e de distribuir cópias das suas versões modificadas. Este sistema aberto
pode ser atingido ao utilizar-se um protocolo aberto para a comunidade, de forma que
o usuário adeque o sistema que deseja monitorar ao protocolo de comunicação utilizado
pelo 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 pois
qualquer sistema, que utilize o protocolo adequado, pode ser monitorado e possivelmente
controlado, 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 desenvolvimento
de um sistema supervisório para gerenciamento e obtenção de dados gerados por diversos
sensores em tempo real, seja em uma planta industrial, veículo controlado remotamente,
sistemas aeroespaciais, sistema eletrônico embarcado; porém com um foco em auxiliar
projetos acadêmicos, de modo que isto permita à alunos um rápido desenvolvimento e
monitoramento de seu empreendimento.
O software contará com dois canais de comunicação: através de uma porta serial e
trabalhando como um servidor TCP/IP. A Figura 5 demonstra o funcionamento básico
do sistema.

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

Fonte: Do autor.
Capítulo 1. Introdução 23

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 a


linguagem C#;

• Implementação de leitura e interpretação de dados dos sensores mais utilizados em


projetos 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 parte
integrante 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 dos
sensores. Por fim, no Capítulo 4 são apresentados os resultados do desenvolvimento do
software como interface gráfica, exibição de dados de sensores e testes de capacidade de
recebimento de mensagens e tempo máximo de execução.
24

2 Fundamentação Teórica

2.1 Sistemas Supervisórios de Controle e Aquisição


de Dados
Os Sistemas Supervisórios de Controle e Aquisição de Dados (do inglês Supervisory
Control 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. Sistemas
SCADA são amplamente utilizados na indústria para controle supervisório e aquisição de
dados 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-se
cada 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ção
de energia, como pode ser verificado em experimentos recentes da Organização Europeia
para 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ões
sobre o processo (DANEELS; SALTER, 1999).
A partir da revolução industrial, onde os processos produtivos tornaram-se cada vez
mais agéis, surgiu a necessidade de monitorar os processos industriais e intervir em algum
controle em nível de supervisão, quando necessário. Também há a necessidade de adquirir
dados 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 instalado
em 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 engenharia
elé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 apenas
utilizando operação humana. Porém é necessário que um sistema supervisório para fins
de automação tenha um sólido projeto, pois a implementação de softwares deste tipo
implicam em aumento momentâneo da carga de trabalho e necessidade de treinamento
ao usuário; portanto sistemas mal desenvolvidos tornam-se extremamente custosos e em
situaçõ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, principalmente


sobre qual nível de controle, automatização, e segurança estes sistemas devem possuir
(MILLER; PARASURAMAN, 2007). Entusiastas da tecnologia tendem à afirmar que a
execuçã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ões
como segurança e confiabilidade como futuros problemas da automação, e desta maneira
colocam-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: levels
of automation - LOAs); dentro destes níveis é possível tomar conhecimento dos riscos e
benefícios de um determinado tipo de sistema. Estes níveis são iniciados pela camada de
mais 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. Uma
parte da comunidade científica concorda que, em termos de benefícios e riscos, a melhor
escolha consiste de um sistema intermediário; ou seja, que possua certa autonomia mas que
permita aos operadores a executar tarefas e comandos. Outra parte propõem que sejam
projetados sistemas adaptativos, de modo que seja possível ajustar o nível de automação
durante a operação do sistema; porém, em aplicações reais, muitos usuários mostraram-se
pouco determinados à utilizar sistemas adaptativos pois esta característica aumenta a
imprevisibilidade do conjunto (MILLER; PARASURAMAN, 2007).
Segundo Miller e Parasuraman (2007), os níveis de automação podem ser elencados
da 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 conhecimento


pré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 o


operador dê permissão

6. O computador executa a ação preferencial de forma independente, o operador tem


a 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 este


solicitar a informação

9. O computador executa a ação preferencial e informa o operador apenas se julgar


necessário
Capítulo 2. Fundamentação Teórica 26

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 microcontrolador
ou microprocessador é encapsulado em um dispositivo para uma aplicação dedicada; na
qual 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ém
por terem requisitos específicos, diferentemente de um computador pessoal, o que permite
minimizar diversos fatores, como custos, dimensão física e consumo energético. Como
exemplo de sistemas embarcados podemos citar desde reprodutores de mídia, rastreadores
automotivos, telefones celulares até mísseis militares e aviões.
A origem dos primeiros computadores deu-se na década de 1940, apesar de serem
dispositivos grandes a ponto de ocupar diversos metros quadrados, estes realizavam ope-
rações específicas que eram programadas diretamente no sistema. O primeiro dispositivo
a ser produzido em massa foi o computador aplicado no míssil balístico intercontinental
americano LGM30-Minuteman.
No príncipio, a maior dificuldade para o desenvolvimento de sistemas embarcados era
origidado pela dimensão dos componentes empregados; porém, com o desenvolvimento de
novas tecnologias, principalmente com o surgimento dos circuitos integrados, foi possível
miniaturizar componentes e consequentemente baratear os sistemas embarcados. A partir
disto, na década de 1980, começam a surgir microcontroladores através da integração de
componentes externos junto ao encapsulamento do processador.
Atualmente, os microcontroladores são amplamente disponíveis e de baixo custo; tendo
diversas arquiteturas disponíveis como ARM, MPIS e AVR bem como uma vasta gama
de 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 e
protocolos 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ções
industriais 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.


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

• 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 captura


e 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 de
funções de comunicação para sistemas de telecomunicações ou sistemas computacionais,
desconsiderando as tecnologias e estrutura interna que serão empregados; isto gera um
grande benefício, pois permite uma interoperabilidade entre sistemas diferentes desde que
ambos respeitem o protocolo padrão de comunicação. O Modelo OSI, é identificado por
ISO/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 uma
função específica, sendo amparada pela camada que está logo abaixo e oferecendo suporte
para a camada superior. Para isto, é necessário definir a atribuição de cada camada
e sua aplicabilidade, protocolos de camada relacionados à armazenamento de dados e
comunicação interna e externa com outras camadas. Após a definição das múltiplas
camadas, ocorrerá uma partição entre o software e hardware em módulos, cada um com
uma incumbência na execução do software. O Modelo OSI utiliza uma pilha de camadas
da seguinte forma (BRISCOE, 2000):

Camada 7: Camada de aplicação


É a camada que o usuário pode interagir diretamente através de um software que
implemente um componente de comunicação, já é considerado uma abstração de todo o
sistema. Como funcionalidades que podem ser implementadas, pode-se citar a identifica-
ção de parceiros de comunicação, sincronização e disponibilidade de rede.
Capítulo 2. Fundamentação Teórica 28

Camada 6: Camada de apresentação


A camada de Apresentação estabalece a comunicação entre aplicações que utilizem
a camada superior, as quais podem utilizar sintaxes e semântica diferentes originadas
de linguagens de programação distintas. Esta camada torna a representação de dados
independente da aplicação utilizada e do formato da rede, ou seja, de grosso modo esta
camada 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 na
rede. Tem como funcionalidades a capacidade de iniciar, gerenciar e finalizar conexões
entre aplicações remotas e locais. As conexões gerenciadas por esta camada podem ser
do tipo full-duplex ou half-duplex, além de implementar procedimentos responsáveis por
reiniciar a comunicação em caso de falhas. Esta camada é amplamente implementada
em sistemas que fazem uso de chamadas remotas procedurais, ou seja, que executam
aplicaçõ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-se
de funcionalidades da camada inferior e de diversas redes, sempre prezando pela qualidade
de serviço. A confiabilidade da transmissão de dados é gerada nesta camada, onde tem-se
controle de fluxo e detecção de erros; desta maneira, é possível que essa camada detecte
erros 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 a
tranferência de uma sequência de dados, os chamados datagramas, entre diferentes nós
conectados à diferentes redes. O conceito de rede é definido como o meio no qual diversos
nós, cada um com um endereço especifíco, se conectam e podem transferir mensagens
contendo o endereço do nó de destino e o conteúdo da mensagem. A entrega de mensagens
não é garantida pela camada de rede, esta função deve ser implementada pela camada
superior.

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-
Capítulo 2. Fundamentação Teórica 29

rior, a camada física. Esta camada define protocolos capazes de estabelescer e terminar
comunicaçõ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 par
trançado, fibras óticas ou transmissão via rádio-frequência; também são definidos a taxa
de bit que poderá ser utilizada; os modos de transmissão implementados: half-duplex ou
full-duplex; e a tolopogia da rede: mesh, barramento, anel ou estrela para citar as mais
comuns.

2.4 Protocolo de Comunicação TCP/IP


A pilha de procotocolos TCP/IP é derivada de dois protocolos de comunicação entre
computadores: a protocolo TCP (Transmission Control Protocol - Protocolo de Controle
de Transmissão) e o protocolo IP (Internet Protocol - Protocolo de Internet). O TCP/IP
segue 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 Project
Agency Network em 1969, e dentro deste surgiu como uma funcionalidade o protocolo
TCP/IP, responsável por facilitar a comunicação entre sistemas de inúmeros computadores
e, principalmente, órgãos governamentais na época (BIDGOLI, 2004). O protocolo de
comunicação tinha como objetivo determinar a melhor rota possível, disponibilizando
transmissões de dados em alta velocidade através da permuta de pacotes; e, segundo os
desenvolvedores do protocolo, o interesse era desenvolver um sistema de comutação de
pacotes adaptativos distribuídos que fosse capaz de continuar ativo mesmo em caso de
uma 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 ideias
para a especificação do protocolo TCP/IP. Posteriormente, numa associação formada pela
University College London - (UCL) e a Universidade de Stanford, foram desenvolvidas
diversas 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
Capítulo 2. Fundamentação Teórica 30

dos Estados Unidos da América definiu, em 1982, este como o padrão que deveria ser
utilizado 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 operacionais
fizessem um grande esforço para fornecer implementações do protocolo TCP/IP em um
estado ótimo, tornando seu desempenho superior à outros protocolos. Podem ser citados
como benefícios oferecidos pelo protocolo TCP/IP:

• Fornecimento de internet: redes locais fornecem servidores de acesso a internet


e 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 um


modelo antigo de implementação ou um mais atual, se conectem à internet de forma
semelhante; além de permitir conexões em linhas dedicadas;

• Interconectividade: permite conectar diferentes sistemas, utilizando tecnologias


distintas. Por exemplo, estabelecer uma conexão entre um microcontrolador de 8
bits 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 .NET


Na 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 como
um benefício aos desenvolvedores. Ao empregar-se uma nova linguagem, era necessário
aprender 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, a
Microsoft Corporation decidiu utilizar a linguagem Java. Esta liguagem é interessante
pois já era bastante adotada pela comunidade, possuindo abundantes bibliotecas; além
de ser independente do ambiente de execução. Porém, apesar destas qualidades notadas
a priori, a comunicação entre o Java e códigos de máquina implementados pela Microsoft
Corporation não funcionava como esperado. Desta maneira, foi tomada a decisão de criar
uma nova plataforma que a empresa pudesse utilizar.
Capítulo 2. Fundamentação Teórica 31

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, compartilhado
um mesmo conjunto de bibliotecas (CAELUM, 2016). Após a criação de um ambiente de
programaçã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 que
foi possível alcançar diversos dispositivos desde celulares, extensões para navegadores de
internet, sistemas embarcados e sistemas operacionais alternativos. Também há versões
compactas, o .NET Compact Framework e .NET Micro Framework, que são capazes de
rodar 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 projetada
para 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ção
de uso de variáveis não-iniciadas, verificação automática de tamanho de vetores, forte
tipagem 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 seus
produtos sejam executados de forma independente ao ambiente. Outra característica
importante é a portabilidade de código que foi fornecida à programadores, de forma
que 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ível
encontrar aplicações rodando em pequenos sistemas embarcados, como o Raspberry Pi,
até em grandes servidores que utilizam sistemas operacionais sofisticados. A partir desta
características, pode-se concluir que esta linguagem necessite ser eficiente e econômica com
os 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, pelos
criadores da linguagem Java e da Sun Microsystems, de ser apenas uma cópia barata e
mal feita. Porém, a partir do lançamento da versão 2.0 do C# em 2005, pode-se perceber
que ambas as linguagens tomaram rumos distintos. Podemos destacar como melhorias
implementadas no C# a inclusão de métodos genéricos, geração de código em tempo de
carregamento de classe e principalmente a adição de consulta integrada à linguagem, do
inglês Language Integrated Query (LINQ) que permite a realização de buscas em diferentes
fontes e bancos de dados, além de permitir tipos anônimos e expressões lambda. Em
Agosto de 2017, foi lançada a versão 7.1 da linguagem C# e a versão 4.6.2 do Framework
Capítulo 2. Fundamentação Teórica 32

.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 para
uma plataforma específica, e desta maneira, o compilador trabalha convertendo código
fonte 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 pelo
sistema operacional ocorre sem maiores problemas; porém isto acaba gerando um código
executá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ário
a utilização de uma máquina virtual. Pode-se definir o conceito de uma máquina virtual
como um computador de mentira rodando dentro do mesmo sistema operacional e capaz
de realizar todas as funções de um computador: pilha de execução, tarefas paralelas ou
concorrentes, segurança, gerenciamento de memória e etc.
O processo de funcionamento de linguagens de programação que utilizam máquinas
virtuais 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ário
será 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#, é a
Commom 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ário
o uso da Common Intermediate Language (CLI) que é responsável por traduzir todas as
linguagens da plataforma para uma linguagem intermediária comum à todas de forma que
a 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 entre
sistemas 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 da
linguagem de programação interpretada JavaScript; e, atualmente, diversas linguagens de
programação começaram a implantar suporte à este tipo de arquivos de forma que seja
possível analisar e gerar arquivos com a extensão *.json (ECMA INTERNATIONAL,
2013).
Capítulo 2. Fundamentação Teórica 33

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 e
para 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ão
amplamente utilizados em casos onde ocorre uma grande necessidade de uma alta taxa
de 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 formam
uma coleção de pares nome/valor; e vetores que consistem em uma lista ordenada de
valores de modo a formar uma sequência. Esta estrutura é inerente à linguagem de
programação que deveará interpretar o arquivo de modo que seja possivel realizar uma
transferência de arquivos entre diferentes linguagens (BRAY, 2014). No trecho de código
descrito no Apêndice A, é possível analisar a formatação e como é organizado um arquivo
JSON; neste exempo pode-se verificar como as duas estruturas supracitadas podem ser
combinadas 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 qualidade
da comunicação, são implementadas formas de codificação que utilizam-se de detecção e
correçã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 canal
de comunicação utilizado. Existem diversas situações em que estes ruídos prejudicam a
transmissão de dados, diminuindo a qualidade da recepção de sinal, à ponto de perder ou
alterar-se bits à ponto de inutilizar a informação (SILVA et al., ). Durante transmissões de
dados podem ocorrer erros indesejáveis causados por diversas razões como: defeitos nos
componentes 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 para
comunicação de dados é uma transmissão sem erros, portanto diversos métodos devem
sem 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ência
do ruído; um destes métodos consiste em codificar o canal de comunicação. A codificação
de canal consiste em adicionar bits redundantes que tem como finalidade identificar, e
possivelmente corrigir, erros na informação transmitida gerados por ruídos no canal de
comunicação (LOYOLA-CAMORIM et al., 2010).
A codificação de canal pode ser clarificada como a divisão de um fluxo de bits em
blocos de K bits, então deve-se mapear cada bloco de mensagem com uma palavra código
Capítulo 2. Fundamentação Teórica 34

pré-determinada de M bits, fazendo M > L, de modo a criar uma proteção contra erros
de 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; se
ambos forem iguais, pode-se assumir que a mensagem está correta. Há diversas topologias
de 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 e
armazenamento de dados, de forma a encontrar mudanças inesperadas em um fluxo de
dados; 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ção
oriundos do resto de uma divisão polinomial. No momento em que recebe-se uma nova
mensagem, esta divisão é recalculada, sem considerar os bits adicionais; e caso o valor de
resto da divisão seja distinto ao enviado em conjunto à mensagem, é detectado um erro
nos 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 um
có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 linguagem
C# apresentado no Apêndice B.
Deve-se atentar que o parâmetro passado para o método CRC_Calc é um vetor de
bytes; 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 tipo
ushort 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 CRC
não é realizado em todo o vetor, e sim nas posições de 1 à N-3; contemplando apenas os
campos de dados e deixando de lado os bytes de início e fim de mensagem, bem como os
pró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 sistema


supervisório utilizando a linguagem de programação C#, o qual poderá comunicar-se
com servidores de aplicação via comunicação serial cabeada ou rodando um servidor
TCP/IP para monitoramento remoto. Para este trabalho, foi utilizado a IDE Visual
Studio Community 2015, de modo que seja possível desenvolver projetos de software sem
custos iniciais.
O propósito de cada seção deste capítulo é orientar uma sequência de passos a ser
seguida 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 com
a 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 canto
superior esquerdo seguindo a sequência: File -> New -> Project. Uma nova janela
deve surgir, mostrando os tipos de projetos que podem ser criados. A diversidade de
linguagens 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. Neste
trabalho, será empregado um projeto clássico da plataforma Windows que é o Windows
Forms 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 concluir
a criação do projeto, basta clicar em OK ; então o projeto será criado e aparecerá uma
tela conforme ilustrado na Figura 8 abaixo.
Capítulo 3. Metodologia 37

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 como
acesso à 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 pois
cada indivíduo pode direcionar o projeto para seus interesses específicos.
Para adicionar componentes visuais como botões e caixa de texto à partir da janela
Toolbox localizada no canto esquedo da imagem, e ordenar conforme os critérios de design
determinados. 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 separadamente
funcionalidades 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 funcionalidades
e 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:
Capítulo 3. Metodologia 38

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 e


amigá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 do
componente; para demonstrar isto, utiliza-se um RichTextBox como exemplo na Figura
10 abaixo:

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

Fonte: Do autor.

Ao clicar em algum destes pontos, é possível redimensionar o componente. Após


realizar o mesmo com todos os componentes na interface, a disposição destes deve estar
semelhante à ilustrada na Figura 11 abaixo:
Capítulo 3. Metodologia 39

Figura 11 – Alteração da interface.

Fonte: Do autor.

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

Tabela 1 – Configuração dos componentes.


Componente Propriedades Valor
label1 Text Porta:
label2 Text Baudrate:
label3 Text Mensagens:
label4 Text Enviar Mensagem:
button1 Text Abrir Porta
button2 Text Enviar
Fonte: Do autor.

Após alterar todos os componentes necessários a interface deve estar semelhante à


exibida na Figura 12 abaixo.
Capítulo 3. Metodologia 40

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 na
Figura 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 janela
será aberta. Nesta nova janela, cada um dos baudrates deve ser incluído em uma nova
linha. Para este projeto serão utilizados os valores mais comuns no mercado, partindo de
110 e indo até 256000. Os dados devem estar dispostos na janela conforme mostrado na
Figura 14 abaixo.
Capítulo 3. Metodologia 41

Figura 14 – Incluindo valores de baudrate no componente ComboBox2.

Fonte: Do autor.

Após realizar essas configurações no componente ComboBox2, ao compilar e executar


o programa, estes valores de baudrate estarão disponíveis para seleção e irão configurar
a porta serial a ser utilizada. Agora é necessário criar os métodos que irão rodar em
segundo plano para procurar portas seriais e executar ações quando for necessário receber
ou enviar mensagens. Primeiramente, devemos acessar a página que fornece o código do
software; para isto basta pressionar F7, agora é possível escrever todo o código necessário
do software. A primeira coisa que deve ser feita é adicionar no início do código o namespace
System.IO.Ports que permite acessar classes para controle de portas seriais. Depois de
utilizar esta diretiva, pode-se adicionar um objeto do tipo SerialPort que iremos nomear
de PortaSerial, a qual nos permite criar portas e suas características. Portanto, o código
que 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 do
erro deve ocorrer dentro do catch{...} e neste caso apenas iremos exibir uma mensagem
de 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 a
execuçã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, basta
dar dois cliques com o botão direito no fundo da interface gráfica; será criado um método
Capítulo 3. Metodologia 42

chamado Form1_Load() e chamar a função Buscar_Porta_Serial() dentro dela; ficando


da seguinte forma:
1 private void Form1_Load ( object s e n d e r , EventArgs e )
2 {
3 Buscar_Porta_Serial ( ) ;
4 }

Utilizando o código acima, ocorrerá uma busca pelas portas seriais quando o programa
carregar para execução. O próximo passo é criar um timer para procurar por portas
periodicamente; para isto deve-se incluir o namespace System.Timers e adicionar no corpo
principal 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étodo
que lida com o evento do timer:
1 g e n e r a l _ t i m e r . E l a p s e d += General_timer_Handler ;
2 general_timer . Start () ;

Após incluir estes trechos de código, o método Buscar_Porta_Serial() será executado


quando 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 lidam
com os eventos de clique nos botões. O Visual Studio é muito intuitivo na criação destes
métodos, basta clicar duas vezes com o botão direito do mouse em cima do botão que se
deseja criar o método; portanto, após realizar esta ação para os componentes button1 e
button2 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 das
funcionalidades implementadas está disponível no Apêndice C.3.
Com os métodos implmentador, o software que foi desenvolvido é capaz de abrir e
fechar 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-se
verificar, 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 porta
serial; para um melhor entendimento, é possível dizer que este método é análogo à uma
interrupçã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; para
solucionar 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 delegate
que é uma referência para um método, ou seja, funciona como um ponteiro na linguagem
C; e o método Append_Text para escrever em um RichTextBox genérico. O uso desta
estrutura é necessário pois a linguagem C# não permite que um objeto criado em uma
linha 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 como
um todo, então ao utilizar delegates torna segura essa chamada de operações entre threads
distintas. É importante salientar que um delegate só pode chamar funções que tenham o
Capítulo 3. Metodologia 43

mesmo parâmetro dele, neste caso (RichTextBox textbox, string text). Na Figura 15 abaixo
pode-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. Conforme
o 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 um
novo projeto nomeado como TCP_Serve_Exemple, deve-se organizar a interface visual
do Form1 utilizando o toolbox disponível conforme ilustrado na Figura 16 abaixo.
Capítulo 3. Metodologia 44

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ões
para 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 Valor
label1 Text IP:
label2 Text Porta:
label3 Text Mensagens:
label4 Text Enviar Mensagem:
button1 Text Abrir Servidor
button2 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.
Capítulo 3. Metodologia 45

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 clientes
remotos é necessário definir o endereço de rede do servidor, ou seja um IP, e também
uma porta na qual deve ocorrer a conexão. É importante destacar que para que haja
sucesso na abertura do servidor, é necessário que a porta a ser utilizada para a conexão
esteja configurada e liberada no modem de internet; cada modem tem um procedimento
específico para configurar portas de modo que fiquem disponíveis para acesso TCP/IP
e este procedimento pode ser encontrado no manual do fabricante. Tendo estes fatores
em mente, para facilidade de uso do usuário, é necessário desenvolver um código que seja
capaz de encontrar o IP da máquina utilizada automaticamente; para tal tarefa devem ser
incluí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ção
em métodos que possam gerar possíveis exceções de código é importante para que, caso
ocorra uma exceção, a execução do software não seja interrompida. Agora é necessário
determinar em qual momento este código será executado; como só é necessário determinar
o IP uma vez, este método será executado durante o carregamento do software. Para que
o software seja executado neste momento deve-se acessar o método Form1_Load(...), o
que pode ser feito ao clicar duas vezes no fundo da janela do software; após realizar esta
ação, será criado o método Form1_Load(...) e deve-se incluir uma chamada invocando o
método Encontrar_IP() conforme mostrado abaixo.
Capítulo 3. Metodologia 46

1 private void Form1_Load ( object s e n d e r , EventArgs e )


2 {
3 Encontrar_IP ( ) ;
4 }

O próximo passo é desenvolver um método que irá abrir o servidor TCP/IP, para
isto será utilizado a classe TcpListener que fornece meios simples para ouvir e aceitar
novas conexões. Este método será executado quando ocorrer um clique no botão, então
a coerência é chamar este método do evento de clique do botão; então, conforme feito
anteriormente, deve-se clicar duas vezes no botão desejado para criar o método responsável
por 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étodo
Append_Text para seja possível adicionar texto a um RichTextBox. Também é utilizado o
método BeginAcceptTcpClient na linha 30, este é responsável por executar uma operação
assíncrona para aguardar a conexão de um cliente TCP. Os parâmetros necessários para
este método são um callback da função que realiza a aceitação do cliente e um objeto que
serve como parâmetro para o callback, que neste caso é a variável servidorTCP do tipo
TcpListener. Com este código implementado, o software ficará aguardando a conexão de
um cliente, porém não existe nenhum callback responsável por lidar com a aceitação do
cliente e nem com mensagens recebidas. Então, é necessário adicionar as duas funções de
callback conforme o Apêndice C.7.
Com o código utilizado, o software agora é capaz de aceitar a conexão remota de um
cliente e criar uma instância de TcpClient para manipular o cliente remoto. Também foi
adicionado o método BeginRead que utiliza um callback para leitura assíncrona da stream
de dados enviados pelo cliente. No callback Callback_LerCliente é analisado se o cliente
está conectado antes de abrir-se a stream de dados e após isto, utiliza-se de um laço de
repetição while para aguardar que dados sejam enviados. Quando uma mensagem for
recebida pelo servidor, esta será exibida no RichTextBox1.
Para completar as funcionalidades do servidor, é necessário implementar o envio de
mensagens para o cliente; para esta funcionalidade será utilizado o evento de clique no
button2 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 desenvolvido
pela 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 confome
ilustrado na Figura 18 abaixo.
Capítulo 3. Metodologia 47

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 do
servidor 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 momento
em que encontrar o servidor aberto; e após concluída a conexão, é possível enviar e
receber mensagens em ambos os dispositivos. As Figuras 19 e 20 mostram um exemplo
de comunicação entre o aplicativo e o servidor, respectivamente.
Capítulo 3. Metodologia 48

Figura 19 – Demonstração da comunicação entre cliente e servidor mostrados na tela do


aplicativo TCP UDP Terminal.

Fonte: Do autor.

Figura 20 – Demonstração da comunicação entre servidor e cliente mostrados na interface


gráfica do software desenvolvido.

Fonte: Do autor.
Capítulo 3. Metodologia 49

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 protocolo
utilizado, analisar cada índice da mensagem para uma determinada finalidade ou alterar a
formatação da mensagem para uma notação específica como o JSON, por exemplo. Para
abreviar 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 comunicar
com um periférico externo, seja via comunicação serial como descrito na Seção 3.2 ou
utilizando um servidor que utilize o protocolo TCP/IP como descrito na Seção 3.3. O
usuário deve sentir-se livre para escolher qual a opção que lhe seja mais cômoda, porém
para 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 é exibida
na tela sem qualquer validação ou análise de protocolo. Agora, será demonstrado como
analisar 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 na
tela, este método deve ser chamado dentro da função de evento de mensagem recebida
PortaSerial_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étodo
Tratar_Mensagem está descrito no Apêndice C.9.
O método implementado, deve ser invocado dentro da função PortaSerial_DataReceivedHandler
e 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 expresso
em forma de data e hora do dia. Esta estrutura pode ser utilizada para adquirir a hora
do 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ção
de 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ão
deve 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 de
início e fim de mensagem apenas para exemplificar como deve ser realizada a análise do
pacote de dados.
Para a conversão da mensagem recebida, foi utilizada a classe BitConverter que foi
projetada para converter vetores de bytes para vetores de outros formatos como ASCII
ou UInt64_t. O uso desta classe se faz importante para tornar a mensagem legível para
o usuário, pois de os dados fossem convertidos de forma direta para string utilizando o
Capítulo 3. Metodologia 50

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 a
mensagem 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 maneira
a 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 21
abaixo.

Figura 21 – Demonstração de como o software se comportar após a introdução do método


de 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 da
plataforma .NET : a primeira salvando a caixa de texto do LOG como um todo ao clicar-se
em um botão, e a segunda salvando as mensagens automaticamente em formato JSON
assim que estas chegarem pela porta serial. Para cada uma destas forma de salvar-se um
arquivo, será criado um método distinto para que seja possível chamar a execução destes
em qualquer ponto do código. De modo a facilitar o desenvolvimento será reutilizado o
software desenvolvido na Seção 3.4.
Capítulo 3. Metodologia 51

Primeiro será desenvolvido o método para salvar o LOG exibido na tela de forma
completa, 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ão
para Salvar LOG. Então, deve-se clicar duas vezes para que o Visual Studio crie a
função que trata o evento de clique no botão; e posteriormente deve-se adicionar o código
que se deseja executar quando o usúario clicar no botão para salvar o LOG, conforme
demonstrado no Apêndice C.10.
Através deste código, quando o usuário clicar no botão para salvar o LOG, será criada
uma nova janela que permite o usuário escolher onde o arquivo deve ser salvo. O arquivo
já terá um nome padrão no formado "AA-MM-DD", ou seja, indicando o ano, mês e dia
respectivamente, em que o arquivo está sendo salvo. Logicamente, o nome do arquivo
pode ser alterado à desejo do usuário. O arquivo terá como tipo padrão "*.txt", de forma
que seja possível abrir e analisar o arquivo em qualquer editor de texto simples, com o
Bloco de Notas nativo da plataforma Windows.
Desta forma, foi demonstrado como salvar um arquivo quando o usuário desejar e
onde ele escolher. Agora, será demonstrado uma forma distinta que, em vez de criar
um 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 novas
informações ao arquivo. As mensagens serão manipuladas para adequarem-se ao formato
JSON, de forma que, se desejado, seja possível ler este tipo de arquivo através de um
software 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 com
diversas 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, que
serão utilizadas para salvar a data e hora em que a mensagem foi recebida, e um vetor
de bytes que armazenará a mensagem recebida. A biblioteca Newtonsoft não é inclusa
por padrão no Visual Studio, portanto é necessário instalá-la através do gerenciador de
bibliotecas da plataforma .NET, o Nuget. A grande importância deste gerenciador é que
ele se encarrega de manter as bibliotecas atualizadas em conjunto com a última versão
disponibilizada 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" conforme
ilustra a Figura 22 abaixo.
Capítulo 3. Metodologia 52

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
Capítulo 3. Metodologia 53

lista de resultados ordenadas pelo número de downloads, o primeiro deve ser selecionado
e instalado conforme a Figura 24. Após clicar em Install, o próprio Visual Studio em
conjunto 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 diretiva
using. Agora, para demonstrar a criação da classe de dados desejada e para adicionar a
biblioteca 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 data
e hora no momento em que a variável é criada; e a string msg_recebida tem como conteúdo
a mensagem recebida convertida de um vetor de bytes para valores ASCII da mesma forma
que feito no método Tratar_Mensagem. Agora é necessário criar o método responsável
por 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 deve
ser 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 para
o 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 escrita
e leitura de arquivos e fluxo de dados, além de proporcionar fácil acesso e manuseio à
Capítulo 3. Metodologia 54

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; isto
após realizar a leitura dos arquivos disponíveis na pasta de execução do software. Desta
maneira, 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 se
há a necessidade de lidar com um grande fluxo de dados de um sistema supervisório. Após
chamar o método Criar_Arquivo_JSON dentro da função que manuseia novas mensagens
recebidas 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 passado


como parâmetro e este será salvo no arquivo "Exemplo Arquivo JSON"conforme mostrado
no trecho de código mostrado abaixo.
1 {
2 " Data " : " 26/12/17 " ,
3 " Hora " : " 18 : 10 : 47 " ,
4 " msg_recebida " : " 0A 0 0 0 0 0 0 AA AA AA AA A0 "
5 }

Através deste código, se torna possível registrar todas as informações recebidas de modo
que 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 oferecem
suporte para leitura e interpretação à esta formatação de arquivo, de forma que facilmente
Capítulo 3. Metodologia 55

se torna possível que estes dados sejam repassados a outros programadores para que estes
criem 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 capaz
de 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, foram
observadas algumas boas práticas para o desenvolvimento de um sistema de comunicação
embarcada. Conforme descrito na Seção 2.2, sistemas embarcados possuem poucos recur-
sos de processamento se comparados à um computador pessoal, portando é necessário que
seja estabelecido uma forma de interpretação de mensagens de modo à otimizar o uso de
recursos.
Deste modo, foi desenvolvido um protocolo que facilite a detecção de início e fim
de mensagem, para que, tanto o sistema supervisório quanto o conjunto que está sendo
monitorado, possam receber e interpretar facilmente novas mensagens. O protocolo de
comunicaçã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 formato
da 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 Fim
1 byte 3 bytes Tamanho variável 2 bytes 1 byte

Conforme determinado pela Tabela 3, é necessário que o frame de mensagem possua


bytes que indiquem o início da mensagem (do inglês: Start of Frame - SOF) e fim da nova
mensagem (do inglês: End of Frame - EOF). O cabeçalho da mensagem é responsável
pela 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 quem
são o emissor (do inglês: Sender - SND) e o destinatário da mensagem em questão (do
inglê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 para
acessar posições da memória, portanto é imprescindível que seja enviado para o sistema o
tamanho do campo de dados da mensagem, para que seja possível determinar a quantidade
de espaço que deve ser alocado para guardar a informação. Portanto, na definição do
cabeçalho foi especificado o campo tamanho de dados (do inglês: Data Size - DSZ) que
informa a quantidade de bytes enviados como informação. Desta maneira, o cabeçalho da
mensagem é composto por 3 bytes, conforme mostrado na Tabela 4.
Capítulo 3. Metodologia 56

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


SND ADR DSZ
1 byte 1 byte 1 byte

Em muitos casos é possível que, no meio de mensagens transmitidas, apareçam bytes


que 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 consistem
em incluir um byte de "aviso"de que o próximo byte enviado não é um início ou fim de
mensagem e então acrescentar um valor ao byte para diferenciá-lo; neste software o byte
de aviso será 0x10. Por exemplo, ao transmitir um byte 0x01 no meio da mensagem, ele
deve ser alterado para 0x10 0x21; outro exemplo é a mensagem: "0x01 0x02 0xFF 0x01
0x05 0x04", ela deve ser alterada para "0x01 0x02 0xFF 0x10 0x21 0x05 0x04". Os bytes
que devem ser protegidos são 0x01, 0x04 e 0x10.
Dentre os dados que são enviados como informação, primeiramente tem-se um byte
de 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 de
corrente ACS712, o magnetômetro HMC5883L, o acelerômetro MPU6050, o sensor
de 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 que
cada um tenha a sua particularidade e comandos específicos; cada tipo de comando e seus
parâ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 de
erros em mensagens transmitidas, portanto no escopo do protocolo há espaço rservado
para dois bytes reservados para transmitir o CRC calculado da mensagem. Sabendo que
será enviado um CRC de 16 bits, é possível concluir que o divisor da função de CRC
possui 17 bits. Para enviar o valor completo do CRC, é necessário realizar uma separação
do valor em duas partes de 8 bits cada; na primeira posição serão enviados os 8 bits mais
significativos (em inglês: Most Significant Byte - MSB), e na segunda posição será enviado
os 8 bits menos significativos (em inglês: Least Significant Byte - LSB).
Desta maneira, separando o cabeçalho em seus 3 respectivos bytes, incluindo o campo
de comando e seus possíveis parâmetros no campo de dados e separando o CRC em suas
duas partes; o frame do protocolo fica disposto conforme a Tabela 5 abaixo.
Capítulo 3. Metodologia 57

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


Início Cabeçalho Dados Verificação de erros Final
SOF SND ADR DSZ CMD Paramêtros CRC MSB CRC LSB EOF
1 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 implementados
no sistema supervisório. Cada comando tem seus próprios parâmetros que devem ser
respeitados 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 fabricante
InvenSense, 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 graus
de liberdade. As faixas de operação do acelerômetro são ±2g, ±4g, ±8g e ±16g. Este
mó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 Eixo
1 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 hexadecimal


de 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
Capítulo 3. Metodologia 58

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 enviar
para o sistema supervisório uma mensagem com os seguintes, parâmetros conforme a
Tabela 7 abaixo.

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


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

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 hexadecimal


de 0x00 até 0xFF.
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 referentes
aos 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 dos
dados 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 testados
utilizando o termômetro digital DS18B20, da fabricante Maxim Integrated. Este sensor
tem uma resolução programável de 9 à 12 bits. Este sensor mede temperaturas entre
−55◦ C e +125◦ C, com precisão de até ±0, 5◦ C. A comunicação com este componente é
através do protocolo 1-Wire.
Capítulo 3. Metodologia 59

Requisição de Dados

Para a requisitar dados, ou seja, realizar a leitura do sensor de temperatura; o sistema


supervisó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 ID
1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

Recebimento de Dados

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

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


peratura.
CMD ID Temperatura
1 byte 1 byte 2 bytes

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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ão
deve ser realizado nenhum tratamento pré transmissão. Ao receber o dado, o software
se encarrega de realizar o processamento dos dados realizando operações matemáticas
conforme o datasheet do fabricante.
Capítulo 3. Metodologia 60

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 utilizado
para 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 transmitir
o 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 185
ACS712ELCTR-20A-T 20 100
ACS712ELCTR-30A-T 30 66

Requisição de Dados

Para a requisitar dados, ou seja, realizar a leitura do sensor de corrente; o sistema


supervisó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 ID
1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

Recebimento de Dados

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

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


corrente.
CMD ID Corrente
1 byte 1 byte 2 bytes

Descrição de cada um dos campos:


Capítulo 3. Metodologia 61

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• Corrente: valor de 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ão
deve ser realizado nenhum tratamento pré transmissão. Ao receber o dado, o software
se encarrega de realizar o processamento dos dados realizando operações matemáticas
conforme o datasheet do fabricante.

3.7.4 Sensor Ultrassônico


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

Requisição de Dados

Para a requisitar dados, ou seja, realizar a leitura do sensor de ultrassônico; o sistema


supervisó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 ID
1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

Recebimento de Dados

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

Tabela 14 – Resposta do sistema monitorado para o comando de leitura do sensor ultras-


sônico.
CMD ID Distância
1 byte 1 byte 2 bytes
Capítulo 3. Metodologia 62

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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 Eixo
1 byte 1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 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 enviar
para o sistema supervisório uma mensagem com os seguintes, parâmetros conforme a
Tabela 16 abaixo.

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


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

Descrição de cada um dos campos:


Capítulo 3. Metodologia 63

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

• ID: número de identificação do sensor, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.
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 referentes
aos 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 dos
dados 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 circuito
integrado DS1307 da fabricante Maxim Integrated. Estte CI possui modos de operação
de baixo consumo, 56 bytes de memória SRAM, comunicação via I2C. Através de suas
funcionalidades é 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 de
12 ou 24 horas.

Envio de Comandos

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

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


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

Descrição de cada um dos campos:

• 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 hexadecimal


de 0x00 até 0xFF.
Capítulo 3. Metodologia 64

• 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âmetros
do 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 SS
1 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 de
0x00 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.
Capítulo 3. Metodologia 65

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 a
dezena do ano, tendo como valores válidos de 0x00 até 0x09; e, o byte LSB informa
a 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 a
dezena da hora, tendo como valores válidos de 0x00 até 0x02; e, o byte LSB informa
a 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 por
indicar a dezena dos minutos, tendo como valores válidos de 0x00 até 0x05; e, o byte
LSB 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 por
indicar a dezena dos segundos, tendo como valores válidos de 0x00 até 0x05; e, o
byte LSB informa a unidade dos segundos, tendo como valores válidos de 0x00 até
0x09.

Recebimento de Dados

Para transmitir os dados do conjunto de medição para o sistema supervisório, as


mensagens devem obedecer o padrão estabelecido pela Tabela 19 abaixo.

Tabela 19 – Resposta do sistema monitorada para o comando de leitura dos dados do


relógio de tempo real.
CMD ID Parâmetros do RTC
1 byte 1 byte 11 bytes

Descrição de cada um dos campos:

• 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 hexadecimal


de 0x00 até 0xFF.

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


Capítulo 3. Metodologia 66

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 mercado
possuem portas digitais disponíveis para o usuário, de modo que os comandos podem ser
implementados 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ário
implementar estes comandos no sistema embarcado para que tenha-se um funcionamento
adequado. Os comandos seguem o formato descrito na Tabela 20 abaixo.

Tabela 20 – Envio de comandos para as portas digitais.


CMD ID Tipo
1 byte 1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação da porta, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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.

Recebimento de Dados

Para ambos os comandos referentes à portas digitais, escrita e leitura, a resposta


enviada para o sistema supervisório obedece o mesmo padrão. Para transmitir a leitura
dos dados, o conjunto que está sendo monitorado deve enviar para o sistema supervisório
uma 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 Estado
1 byte 1 byte 1 byte

Descrição de cada um dos campos:


Capítulo 3. Metodologia 67

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

• ID: número de identificação da porta, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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 testados
utilizando 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 ou
digital-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 formato
descrito na Tabela 22 abaixo.

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


CMD ID Tipo Valor MSB Valor LSB
1 byte 1 byte 1 byte 1 byte 1 byte

Descrição de cada um dos campos:

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

• ID: número de identificação da porta, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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 oito
bits mais significativos do valor a ser escrito.

• Valor LSB: caso seja um comando de escrita de dados, este byte deve conter os oito
bits menos significativos do valor a ser escrito.
Capítulo 3. Metodologia 68

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

Recebimento de Dados

Para ambos os comandos referentes à portas analógicas, escrita e leitura, a resposta


enviada para o sistema supervisório obedece o mesmo padrão. Para transmitir a leitura
dos dados, o conjunto que está sendo monitorado deve enviar para o sistema supervisório
uma 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 Valor
1 byte 1 byte 2 bytes

Descrição de cada um dos campos:

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

• ID: número de identificação da porta, pode variar de 0 a 255, ou, em hexadecimal


de 0x00 até 0xFF.

• 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 quantidade
de sensores que se deseja monitorar e como os dados de cada um deve ser exibido. Como
dito 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 ferramenta
TabControl, 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, sensor
de corrente e outros sensores.
Para que seja de fácil uso, o programa desenvolvido deve ser intuitivo, de modo que o
usuário seja capaz de olhar de relance e compreender as informações na tela. Ao executar
o software, a primeira tela que o usuário irá visualizar está ilustrada na Figura 26 abaixo.
Capítulo 3. Metodologia 69

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 ou
empregando uma porta de comunicação serial. Conforme descrito na Seção 3.3, quando
o 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 a
configuraçã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-se
buscar 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 do
servidor 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


Capítulo 3. Metodologia 70

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 forem
detectadas, 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 plataforma
Microsoft Office utilizando o botão disponível nesta tela. Os aquivos formtados como json
sã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 analisadas
por exigirem poucas análises e serem mais intuitivas; porém, assim como grande parte
dos sistemas computacionais, é interessante manter um log de dados para registrar todas
as trocas de mensagens. Neste registro de comunicação, são exibidos a data e hora de
recebimento da mensagem, o tipo do sensor que enviou a informação, o ID do transmissor e
do sensor, e os dados processados pelo sistema. O registro dessas informações é importante
em situações nas quais se deseja manter um registro dos dados recebidos, além dos arquivos
formatados em json. Nesta tela também estão inclusos dois botões, um destinado à apagar
o log exibido na tela; e outro, assim como na Seção 3.5, com a finalidade de salvar o log
em 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.
Capítulo 3. Metodologia 71

Para exibir os dados do acelerômetro são utilizados três gauges, que são instrumentos
indicadores de grandezas, um exemplo é o manômetro. Cada um dos gauges representa
a aceleração medida em cada um dos eixos X, Y e Z. Dentro groupBox estão disponíveis
duas caixas de texto que mostram os IDs do último transmissor e do último sensor a enviar
uma 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 o
acelerô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, onde


podem 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 do
sensor e escolher em qual dos eixos deseja-se realizar a leitura. Ao implantar a interface
de 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 sejam
válidos; ou seja, entre 1 e 255, que são os valores possíveis de um byte assumir. Após
clicar no botão de enviar o comando, os parâmetros informados nas caixas de texto são
analisados para serem julgados válidos; e, caso estejam incorretos, uma mensagem de erro
surge para o usuário.
O passo seguinte é formatar as informações recebidas e exibi-las para usuário de forma
que os dados possam ter analisados de forma simples e coerente. Durante a graduação, os
discentes 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
Capítulo 3. Metodologia 72

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 temperatura
e 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 dados
foi escolhida de forma arbitrária, de modo que não ocorra uma sobrecarga no software
quando muitos dados forem recebidos de forma simultânea. Na Figura 30 abaixo pode-se
analisar 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-se


requisitar uma leitura de temperatura ao informar os IDs de receptor e sensor. Após a
inserção dos valores, estes são analisados para determinar a coerência dos dados. Logo
abaixo, há um segundo groupBox que é utilizado para mostrar informações em tempo real
da última mensagem exibida. São três dados exibidos ao usuário: ID de receptor, ID de
sensor e temperatura instantânea. Ocupando a maior parte da tela, tem-se uma interface
gráfica implementada utilizando a biblioteca Live Charts. Neste gráfico serão ilustrados
as 100 últimas amostras de temperatura recebidas para cada ID de sensor, de modo que
dados de diversos sensores possam ser analisados simultaneamente. Deve-se atentar para
o caso de sensores com IDs iguais, nesta situação haverá um conflito de dados de modo
que 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álise
dos dados provenientes do sensor de corrente. Assim como implementado para o sensor
de temperatura, existem três groupBox com finalidades distintas. O primeiro, no canto
Capítulo 3. Metodologia 73

superior esquerdo, é responsável pelo envio de requisição de dados; o segundo, no canto


inferior 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áfico
onde poderão ser analisadas as últimas 100 últimas amostras de corrente recebidas para
cada 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 uma
aná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 em
computadores com poucos recursos e baixo poder de processamento; de modo que foi
decidido 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ância
medida 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ções
simples sobre o nível de tensão de uma porta digital de uso geral do microcontrolador e
por 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 como
ID de receptor e sensor. O usuário deve atentar-se ao enviar comandos de escrita para
portas digitais e analógicas utilizando o sistema supervisório; para que uma porta digital
possa receber um comando de escrita, ela deve ser configurada como saída no firmware
do 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.
Capítulo 3. Metodologia 74

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 de
um sistema supervisório que seja versátil e possa atender diversos tipos de projetos, desta
maneira foram realizados testes utilizando diferentes sistemas. Foram executados dois
tipos 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 capacidade
do 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 uma
contendo um microcontrolador de arquiteturas diferentes, e a terceira unidade de testes
foi um equipamento desenvolvido por um aluno como trabalho de conclusão de curso
pela Universidade Estadual de Londrina; serão explicadas cada uma das plataformas na
sequência.

3.9.1 Arduino Mega


O primeiro sistema de testes foi montado utilizando uma placa de desenvolvimento
Arduino 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 ou
saídas de sinais digitais, e 14 destes pinos oferecem suporte à saídas com modulação por
largura de pulso ( do inglês, pulse width modulation - PWM ); também estão disponíveis 16
Capítulo 3. Metodologia 75

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ção
e um pino de reset. Foram conectados nesta placa um potenciômetro de 10kΩ em uma
das entradas analógicas, o magnetômetro HMC5883L e também um botão em modo
pull-up foi conectado em uma das entradas digitais disponíveis. Para a comunicação com
o 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 projetada
para demonstrar as capacidades do microcontrolador STM32F407VGT6, um chip ARM
Cortex-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, um
gravador ST-LINK/V2, um acelerômetro LIS3DSH com 3 eixos de medição, conversor
digital-analógico específico para tratamento de áudio e 100 pinos disponíveis para uso do
desenvolvedor. Nesta placa foram conectados para a realização dos testes um acelerômetro
MPU6050 e o sensor ultrassônico de distância HC-SR04. Foi configurada uma porta
serial 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 importantes
como corrente elétrica, temperatura e presença de fluxo de água. Neste projeto foram
utilizados os sensores de temperatura DS18B20, o sensor de corrente SC013-100 e o
relógio de tempo real DS1307. Teve-se como finalidade à análise da eficiência energética
de painéis solares para aquecimento de água residencial através da análise do perfil do
consumidor 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ório
utilizando 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 projeto
também realizou a análise da eficiência de três arquiteturas de microcontroladores de
modo à 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ção
do protocolo de comunicação definido na Seção 3.6. Foram realizados testes para analisar
se o comportamento do software seria adequado às especificações. Na primeira bateria
de testes foi analisada o desempenho da interface gráfica e a exibição das informações de
sensores.
Na Figura 33 abaixo, é exibida a interface gráfica do log de mensagens, onde pode-se
verificar a disposição das informações exibidas assim que recebe-se uma mensagem. Além
dos dados enviados pelos sensores, também são informadas a data e hora do recebimento
da 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, estes


demonstram 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, bem


como 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, bem


como o valor da última medição recebida.
Capítulo 4. Resultados e Discussões 78

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, cada
um com sua particularidade de exibição.

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

Fonte: Do autor.
Capítulo 4. Resultados e Discussões 79

Para o segundo tipo de teste, foram analisadas a capacidade de receber inúmeras


mensagens em um pequeno intervalo de tempo. As placas de desenvolvimento foram
programadas para trabalharem em suas capacidades máximas, de modo que as mensagens
enviadas tivessem o menor intervalo possível entre elas. Para a contagem da quantidade
de mensagens recebidas, foi criado uma variável de contagem de 32 bits para armazenar
a quantidade de vezes que o evento da porta serial responsável por manusear com novas
mensagens foi disparado. Os testes executados consistiram de, primeiramente, realizar
uma análise a capacidade máxima do software de lidar com um grande fluxo de mensagens
através da porta serial e do protocolo TCP/IP, e por fim determinar o tempo máximo
de execução do software, também utilizando comunicações enviadas através do protocolo
TCP/IP e da porta serial.
Para uma melhor taxa de transmissão de dados, a porta serial do microcontrolador
foi configurada com um baudrate de 115200bps, tanto para envio direto pela serial quanto
por envio de mensagens via TCP/IP. Foram estipuladas uma quantidade de mensagens
por minuto que seriam enviadas e então seria mensurado por quanto tempo o software
suportaria a sobrecarga de comunicação. Os resultados obtidos estão separados em duas
tabelas 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 da


porta serial.
Mensagens por minuto Tempo de execução em minutos
100 125,3
300 63,9
500 34,2
1000 12,6

Tabela 25 – Medições dos testes de capacidade de recebimento de mensagens através do


protocolo TCP/IP.
Mensagens por minuto Tempo de execução em minutos
100 115
300 67,5
500 24,8
1000 6,5

Ao realizar uma análise dos resultados obtidos do teste acima; pode-se concluir que
conforme o fluxo de mensagens aumenta, o tempo de execução do software diminui. Este
fato pode ser explicado da seguinte maneira, ao receber uma nova mensagem, seja por
comunicação serial ou pelo protocolo TCP/IP, é gerado um novo evento. O sistema
supervisório deve tratar estes eventos, manipulando os dados recebidos e aplicando o
devido tratamento, atualizando dados, interface gráfica e salvando arquivos em tempo
real. Quando muitas mensagens chegam em um curto período de tempo, os eventos de
Capítulo 4. Resultados e Discussões 80

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 finaliza
o software por julga que este está consumindo demasiados recursos computacionais e para
proteger os outros programas que estão rodando em paralelo, desta maneira é possível
evitar que dados não sejam corrompidos dados ou o próprio sistema operacional seja
danificado.
Para o segundo tipo de teste, também foram utilizadas portas seriais configuradas
em 115200bps para a transmissão de mensagens. Porém, diferentemente do primeiro
teste, foi configurada uma taxa de 5 mensagens transmitidas por minuto, para analisar
se 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 na
Tabela 26 abaixo.

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


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

É importante destacar que os tempos de execução máxima informados na Tabela 26


foram os períodos máximos em que o software se manteve em execução. Em nenhum
dos casos foram detectadas falhas de aplicação; porém, por motivos imprevisíveis como
problemas de conexão na internet e falha no fornecimento de energia elétrica, os testes
foram 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 o
métodos de funcionamento e tecnologias envolvidas em sistemas deste tipo; foi possível
perceber a importância dos sistema supervisórios na atual sociedade, sendo aplicados
desde 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ível
notar a contribuição agregada pelos sistemas supervisórios; aumentando a confiabilidade,
agilidade e diminuindo os custos envolvidos nos processos. Também foram citadas as
discussões da comunidade científica confrontando riscos e benefícios; chegando à definição
dos 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 de
redundância. Muitos destes assuntos frequentemente passam despercebido à maioria dos
usuários, apesar de serem tão frequentes em atividades do dia a dia; e julga-se importante
trazer estes conhecimentos à tona de modo que o grande público torne-se consciente de
toda a tecnologia que o cerca.
Após introduzir plataforma .NET e suas características; a criação de diversos projetos
foi demonstrada, de modo à fornecer conhecimento e capacitar o usuário a desenvolver
sistemas simples que abordem os conceitos gerais que foram reunidos na implementação
do sistema supervisório. A partir deste conhecimento fornecido, espera-se que o usuário
tenha condições de desenvolver o sistema supervisório por completo; desde criar interface
gráficas, salvar arquivos e manipular dados recebidos e enviados.
O desempenho demonstrado pelo software se mostrou satisfatório, de modo que os
requisitos do software foram atendidos. Foi possível analisar as mensagens recebidas
através de uma caixa de texto onde exibia-se um log de mensagens; outros resultados
incluem o acompanhamento em tempo real a variação da aceleração medida nos três eixos
de um sensor, a criação de gráficos de corrente e temperatura variantes no tempo, e
também foram apresentados dados de outros sensores de forma mais simples, revelando
os dados de forma clara em caixas de texto para o usuário. Sobre as capacidades do
sistema supervisório em lidar com eventos de novas mensagens, foi possível constatar
que o desempenho da comunicação através de uma porta serial ou utilizando o servidor
TCP/IP é semelhante; de modo a permitir que o usuário adote a tecnologia que mais se
adapte a seus recursos e necessidades.
Foi possível notar que quando há um grande fluxo de mensagens sendo enviadas para
o 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 rapidamente
do que o software é capaz de lidar com cada um destes eventos; causando, assim, a
finalização da execução por problemas de armazenamento de memória e consumo de
recursos pelo sistema operacional. Porém, também pode-se concluir, que para uma taxa
de 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 de
estudantes de engenharia elétrica.
A partir das conclusões realizadas acima, pode-se afirmar que este trabalho alcançou
o objetivo de desenvolver um sistema supervisório capaz de lidar com a necessidade de
estudantes, facilitando a interpretação de informações em projetos de graduação. E o
conhecimento agregado para o curso através deste trabalho também pode ser considerado
importante 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 alternativas
plausí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 de


mensagens 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 controle


proporcional 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 on


Communications 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 systems


interconnection - 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 Interchange


Format. 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, and


synthesis. 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 de


suprimento 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.]: Novatec


Editora, 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
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 between


humans 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 case
study. Caine, v. 2009, p. 157–162, 2009. 33

PARASURAMAN, R. Designing automation for human use: empirical studies and


quantitative 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 estudos


de determinação de economia de energia, em aquecimento solar de água. Universidade
Estadual 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 of


personnel 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ção


em processos de elevação artificial de petróleo. [S.l.]: Universidade Federal do Rio Grande
do Norte, 2005. 24
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 coding


design. [S.l.]: CRC Press, 2003. 34
Apêndices
87

A Exemplo da Formatação JSON

1 {
2 " array " : [ 1 , 2 , 3 ] ,
3 " number " : 1 2 3 ,
4 " Pessoa " : [
5 { "Nome" : " João " , " I d a d e " : 1 7 , " Cidade " : " L ond rina " } ,
6 { "Nome" : " Lucas " , " I d a d e " : 3 0 , " Cidade " : " C u r i t i b a " } ,
7 { "Nome" : " Tiago " , " I d a d e " : 3 3 , " Cidade " : " São Paulo " }
8 ],
9 " Meses " : [
10 { "Nome" : [ " J a n e i r o " , " F e v e r e i r o " , " Março " , " A b r i l " , " Maio " , " Junho " , " J u l h o " , "
Agosto " , " Setembro " , " Outubro " , " Novembro " , " Dezembro " ] } ,
11 { " Número " : [ 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 1 0 , 1 1 , 1 2 ] }
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 r e t o r n a v a l o r de 16 b
5 ∗/
6 ushort newchar ;
7 int t e s t ;
8 int crcword ;
9 crcword = 0 x f f f f ;
10
11 f o r ( i n t i = 1 ; i < ( msg . Length − 3 ) ; i ++)
12 {
13 newchar = msg [ i ] ;
14 f o r ( i n t 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 ^ c r c w o r d ) ;
19 t e s t = ( ushort ) ( t e s t & 0 x8000 ) ;
20
21 i f ( t e s t != 0 )
22 {
23 c r c w o r d = ( ushort ) ( c r c w o r d << 1 ) ;
24 c r c w o r d = ( ushort ) ( c r c w o r d ^ 0 x1021 ) ;
25 }
26 else
27 {
28 c r c w o r d = ( ushort ) ( c r c w o r d << 1 ) ;
29 }
30 }
31 }
32 return ( ushort ) c r c w o r d ;
33 }
89

C Códigos Utilizados na Metodolo-


gia do Trabalho

C.1 Busca de Portas Seriais Conectadas ao Compu-


tador.
1 public void B u s c a r _ P o r t a _ S e r i a l ( )
2 {
3 try
4 {
5 /∗ Testa s e a p o r t a s e r i a l e s t á a b e r t a
6 ∗ Se e s t i v e r , não é n e c e s s á r i o a t u a l i z a r a l i s t a
7 ∗ de p o r t a s s e r i a i s
8 ∗/
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 ( s t r i n g s t r in S e r i a l P o r t . GetPortNames ( ) )
13 {
14 /∗ Testa s e a COM s t r j á não e s t á a d i c i o n a d a
15 ∗ na l i s t a
16 ∗/
17 i f ( comboBox1 . F i n d S t r i n g ( s t r ) == −1)
18 {
19 /∗ A d i c i o n a a COM s t r na l i s t a ∗/
20 comboBox1 . I t e m s . Add( s t r ) ;
21 }
22 }
23 }
24 }
25 catch ( E x c e p t i o n e )
26 {
27 MessageBox . Show ( e . T o S t r i n g ( ) ) ;
28 }
29 }

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


riais
1 System . Timers . Timer g e n e r a l _ t i m e r = new System . Timers . Timer ( 1 0 0 0 ) ;
2 public delegate void Delegate_void_NoPam ( ) ;
3
4 private void General_timer_Handler ( object s e n d e r , ElapsedEventArgs e )
5 {
6 i f ( ! P o r t a S e r i a l . IsOpen )
7 {
8 I n v o k e (new Delegate_void_NoPam ( B u s c a r _ P o r t a _ S e r i a l ) ) ;
9 }
10 }
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 90

C.3 Métodos para Manusear Eventos de Clique em


Botões
1 private void b u t t o n 1 _ C l i c k ( object s e n d e r , EventArgs e )
2 {
3 /∗ s w i t c h para d e t e r m i n a r ação a s e r tomada ∗/
4 switch ( b u t t o n 1 . Text )
5 {
6 case " A b r i r Porta " :
7 i f ( P o r t a S e r i a l . IsOpen )
8 {
9 PortaSerial . 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 d e i x a d o s em bra nco " ) ;
14 break ;
15 }
16 try
17 {
18 /∗ C o n f i g u r a ç ã o da p o r t a 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 = i n t . P a r s e ( comboBox2 . Text ) ;
21 P o r t a S e r i a l . P a r i t y = P a r i t y . 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 . S t o p B i t s = S t o p B i t s . One ;
24 P o r t a S e r i a l . DataReceived += new S e r i a l D a t a R e c e i v e d E v e n t H a n d l e r (
PortaSerial_DataReceivedHandler ) ;
25
26 P o r t a S e r i a l . Open ( ) ;
27
28 b u t t on 1 . Text = " Fechar Porta " ;
29 }
30 catch
31 {
32 MessageBox . Show ( " Erro ao a b r i r p o r t a s e r i a l . " ) ;
33 }
34 break ;
35
36 case " Fechar Porta " :
37 try
38 {
39 PortaSerial . Close () ;
40 b u t t on 1 . Text = " A b r i r Porta " ;
41 }
42 catch {}
43 break ;
44 }
45 }
46
47 private void b u t t o n 2 _ C l i c k ( object s e n d e r , EventArgs e )
48 {
49 /∗ As mensagens só podem s e r e n v i a d a s s e a p o r t a s e r i a l e s t i v e r a b e r t a
50 ∗ e s e o campo de dados não e s t i v e r v a z i o
51 ∗/
52 i f ( P o r t a S e r i a l . IsOpen && ric hText Box2 . Text != " " )
53 {
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 91

54 /∗ Os dados i n s e r i d o s na c a i x a de t e x t o
55 ∗ s e r ã o e n v i a d o s em ASCII
56 ∗/
57 P o r t a S e r i a l . Write ( richT extBo x2 . Text ) ;
58 ric hText Box1 . AppendText ( "TX: " + ric hText Box2 . Text + " \ r \n " ) ;
59 ric hText Box2 . C l e a r ( ) ;
60 }
61 }

C.4 Método Utilizado para Recebimento de Dados


da Porta Serial
1 private void P o r t a S e r i a l _ D a t a R e c e i v e d H a n d l e r ( object s e n d e r ,
SerialDataReceivedEventArgs e )
2 {
3 SerialPort S e r i a l = ( SerialPort ) sender ;
4 i n t b y t e s = S e r i a l . BytesToRead ;
5 byte [ ] r e c e b i d o = new byte [ b y t e s ] ;
6 S e r i a l . Read ( r e c e b i d o , 0 , b y t e s ) ;
7 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 , "
RX: " + Encoding . ASCII . G e t S t r i n g ( r e c e b i d o ) + " \ r \n " } ) ;
8 }
9 public delegate void D e l e g a t e _ v o i d _ S t r i n g ( RichTextBox t e x t b o x , s t r i n g t e x t ) ;
10 public void Append_Text ( RichTextBox t e x t b o x , s t r i n g t e x t )
11 {
12 t e x t b o x . AppendText ( t e x t ) ;
13 }

C.5 Busca Automática de IP


1 using System . Net ;
2 using System . Net . S o c k e t s ;
3
4 s t r i n g IP4_Endereco ;
5 s t r i n g IP4_Porta ;
6
7 public void Encontrar_IP ( )
8 {
9 try
10 {
11 /∗
12 ∗ E s t e l o o p i r á p r o c u r a r por e n d e r e ç o s DNS e d e t e r m i n a r o IP
13 ∗ da máquina u t i l i z a d a
14 ∗/
15 foreach ( IPAddress IPA in Dns . G e t H o s t A d d r e s s e s ( Dns . GetHostName ( ) ) )
16 {
17 i f ( IPA . AddressFamily == AddressFamily . I n t e r N e t w o r k )
18 {
19 IP4_Endereco = IPA . T o S t r i n g ( ) ;
20 break ;
21 }
22 }
23 textBox1 . Text = IP4_Endereco ;
24 /∗
25 ∗ Será u t i l i z a d o como p o r t a padrão a p o r t a 5001
26 ∗/
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 92

27 textBox2 . Text = " 5001 " ;


28 }
29 catch { }
30 }

C.6 Abertura de um Servidor TCP/IP quando Ocorre


Um Clique em um Botão
1 private void b u t t o n 1 _ C l i c k ( object s e n d e r , EventArgs e )
2 {
3 try
4 {
5 /∗ N e s t e s w i t c h é tomada a d e c i s ã o de a b r i r ou f e c h a r
6 o s e r v i d o r conforme o t e x t o do b o t ã o . ∗/
7 switch ( b u t t o n 1 . Text )
8 {
9 case " A b r i r S e r v i d o r " :
10 /∗ Testa s e a c a i x a s de t e x t o não e s t ã o v a z i a s . Se e s t i v e r e m
11 ∗ 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 p a r â m e t r o s em b ran co .
" , " Atenção " ) ;
15 return ;
16 }
17 /∗ A t r i b u i uma nova i n s t â n c i a T c p L i s t e n e r na v a r i á v e l servidorTCP .
18 ∗ Converte os v a l o r e s das c a i x a s de t e x t o para f o r m a t o a p r o p r i a d o
19 ∗ para o s e r v i d o r . ∗/
20 servidorTCP = new T c p L i s t e n e r ( IPAddress . P a r s e ( textBox1 . Text ) , I n t 3 2 . P a r s e ( textBox2
. Text ) ) ;
21 /∗ I n i c i a o s e r v i d o r TCP∗/
22 servidorTCP . S t a r t ( ) ;
23 /∗ E s c r e v e r na c a i x a de LOG que o s e r v i d o r e s t á c o n e c t a d o ∗/
24 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
25 s t r i n g . Format ( " S e r v i d o r c o n e c t a d o . IP : {0} . Porta : {1} . " , textBox1 . Text ,
textBox2 . Text ) } ) ;
26 /∗Dá i n i c i o a uma o p e r a ç ã o a s s í n c r o n a que i r á a g u a r d a r uma conexão
27 de c l i e n t e . É n e c e s s á r i o p a s s a r um c a l l b a c k que s e r á e x e c u t a d o quando
28 o c o r r e r a conexão e o um o b j e t o para s e r manuseado , n e s t e c a s o a v a r i a v e l
29 do s e r v i d o r . ∗/
30 servidorTCP . B e g i n A c c e p t T c p C l i e n t ( C a l l b a c k _ A c e i t a r C l i e n t e , servidorTCP ) ;
31 /∗ A l t e r a o t e x t o do b o t ã o para quando o c o r r e r um novo c l i q u e , f e c h e o
32 s e r v i d o r . ∗/
33 b u t t on 1 . Text = " Fechar S e r v i d o r " ;
34 break ;
35
36 case " Fechar S e r v i d o r " :
37 /∗ Para f e c h a r o s e r v i d o r sem c a u s a r e r r o s , p r i m e i r o é n e c e s s á r i o f e c h a r a stream
de dados .
38 É uma boa p r á t i c a t e s t a r s e os e l e m e n t o s não são n u l o s a n t e s de m a n i p u l a l o s
39 ∗/
40 i f ( streamTCP != n u l l )
41 {
42 streamTCP . C l o s e ( ) ;
43 }
44 /∗ Agora é p o s s í v e l f e c h a r o s e r v i d o r sem que aconteçam maiores p r o b l e m a s ∗/
45 i f ( servidorTCP != n u l l )
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 93

46 {
47 servidorTCP . Stop ( ) ;
48 }
49 /∗ Voltamos o b o t ã o para a f u n ç ã o de a b r i r s e r v i d o r ∗/
50 b u t t on 1 . Text = " A b r i r S e r v i d o r " ;
51 break ;
52 }
53 }
54 /∗ Aqui r e a l i z a −s e o t r a t a m e n t o de e r r o s , n e s t e c a s o apenas iremos f e c h a r a stream
de dados
55 ∗ e o s e r v i d o r em c a s o de e r r o , e e n t a o r e t o r n a r o b o t ã o para a f u n ç ã o de a b r i r
s e r v i d o r ∗/
56 catch ( E x c e p t i o n ex )
57 {
58 ex . T o S t r i n g ( ) ;
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 f e c h a d o . " , " Atenção
");
60 i f ( streamTCP != n u l l )
61 {
62 streamTCP . C l o s e ( ) ;
63 }
64 i f ( servidorTCP != n u l l )
65 {
66 servidorTCP . Stop ( ) ;
67 }
68 b u t t on 1 . Text = " A b r i r S e r v i d o r " ;
69 }
70 }

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


1 private void C a l l b a c k _ A c e i t a r C l i e n t e ( I A s y n c R e s u l t a r )
2 {
3 /∗ Faz−s e uma t r a n s f o r m a ç ã o de o b j e t o para T c p L i s t e n e r para que o c ó d i g o t r a t e
4 ∗ a v a r i á v e l d e s t a maneira ∗/
5 servidorTCP = a r . A s y n c S t a t e as T c p L i s t e n e r ;
6 /∗ Testa s e a v a r i á v e l não é n u l a . Caso s e j a , f i n a l i z a o método ∗/
7 i f ( servidorTCP == n u l l )
8 {
9 return ;
10 }
11
12 try
13 {
14 /∗ Termina a a c e i t a ç ã o do c l i e n t e TCP de forma a s s i n c r o n a e a d i c i o n a o c l i e n t e na
variavel
15 ∗ clienteTCP ∗/
16 c l i e n t e T C P = servidorTCP . EndAcceptTcpClient ( a r ) ;
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 l e n d o
ou e s c r e v e n d o
18 ∗ dados ∗/
19 streamTCP = c l i e n t e T C P . GetStream ( ) ;
20 byte [ ] b u f f e r = new byte [ 1 0 0 ] ;
21 /∗ L e i t u r a a s s í n c r o n a da stream de dados ∗/
22 streamTCP . BeginRead ( b u f f e r , 0 , b u f f e r . Length , C a l l b a c k _ L e r C l i e n t e , c l i e n t e T C P ) ;
23 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
24 s t r i n g . Format ( " C l i e n t e c o n e c t a d o . " ) } ) ;
25 }
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 94

26 catch { }
27 }
28
29 private void C a l l b a c k _ L e r C l i e n t e ( I A s y n c R e s u l t a r )
30 {
31 /∗ Faz−s e uma t r a n s f o r m a ç ã o de o b j e t o para T c p C l i e n t para que o c ó d i g o t r a t e
32 ∗ a v a r i á v e l d e s t a maneira ∗/
33 c l i e n t e T C P = a r . A s y n c S t a t e as T c p C l i e n t ;
34 /∗ Cria o b u f f e r onde s e r á armazenada a l e i t u r a ∗/
35 byte [ ] b y t e s = new byte [ 1 0 2 4 ] ;
36 int i ;
37 /∗ Apenas deve−s e a b r i r a stream de dados s e o c l i e n t e e s t i v e r c o n e c t a d o ∗/
38 i f ( c l i e n t e T C P . Connected )
39 {
40 streamTCP = c l i e n t e T C P . GetStream ( ) ;
41 }
42 /∗ Testa s e a stream pode s e r l i d a e s e o c l i e n t e e s t á c o n e c t a d o , enquanto i s t o
for verdadeiro
43 ∗ deve−s e c h e c a r s e há dados d i s p o n í v e i s para serem l i d o s ∗/
44 while ( c l i e n t e T C P . Connected && streamTCP . CanRead )
45 {
46 i f ( streamTCP . D a t a A v a i l a b l e )
47 {
48 i = streamTCP . Read ( b y t e s , 0 , b y t e s . Length ) ;
49 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
50 s t r i n g . Format ( " Mensagem r e c e b i d a : {0} " , Encoding . UTF8 . G e t S t r i n g ( b y t e s , 0 , i ) ) } ) ;
51 }
52 }
53
54 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
55 "O c l i e n t e s e d e s c o n e c t o u " } ) ;
56 }

C.8 Implementação do Envio de Mensagens do Ser-


vidor TCP/IP
1 private void b u t t o n 2 _ C l i c k ( object s e n d e r , EventArgs e )
2 {
3 try
4 {
5 /∗ Testa de o campo de dados não e s t á v a z i o ∗/
6 i f ( r ichTe xtBox 2 . Text == " " )
7 {
8 MessageBox . Show ( " Não há mensagem a s e r e n v i a d a " , " Atenção " ) ;
9 return ;
10 }
11 /∗ Testa s e o s e r v i d o r e a stream de dados e s t ã o f u n c i o n a i s ∗/
12 i f ( ( servidorTCP == n u l l ) | | ( streamTCP == n u l l ) | | ( streamTCP . CanWrite == f a l s e ) )
13 {
14 MessageBox . Show ( " Não f o i p o s s í v e l e n v i a 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 r i c h T e x t B o x 2 para um v e t o r de b y t e s ∗/
18 byte [ ] t e x t o = Encoding . ASCII . GetBytes ( richT extB ox2 . Text ) ;
19 /∗ Envia o v e t o r t e x t o p e l a stream de dados para o c l i e n t e ∗/
20 streamTCP . Write ( t e x t o , 0 , t e x t o . Length ) ;
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 95

21 /∗ E s c r e v e em r i c h T e x t B o x 1 a mensagem e n v i a d a ∗/
22 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
23 s t r i n g . Format ( " Mensagem e n v i a d a : {0} " , rich TextB ox2 . Text ) } ) ;
24 ric hText Box2 . C l e a r ( ) ;
25 }
26 catch { }
27 }

C.9 Implementação do Método Tratar_Mensagem


1 private void Tratar_Mensagem ( byte [ ] mensagem )
2 {
3 /∗
4 ∗ Cria uma s t r i n g c o n t e n d o a d a t a e hora a t u a l a p a r t i r do r e l ó g i o i n t e r n o do
computador .
5 ∗ O f o r m a t o da d a t a s e r á do t i p o : [ dd /mm/ aa − hh :mm: s s ]
6 ∗/
7 s t r i n g timestamp = s t r i n g . Format ( " [ { 0 } / { 1 } / { 2 } − { 3 } : { 4 } : { 5 } ] " , DateTime . Now .
T o S t r i n g ( " dd " ) , DateTime . Now . T o S t r i n g ( "MM" ) ,
8 DateTime . Now . T o S t r i n g ( " yy " ) , DateTime . Now . T o S t r i n g ( "HH" ) , DateTime . Now . T o S t r i n g ( "
mm" ) , DateTime . Now . T o S t r i n g ( " s s " ) ) ;
9 i f ( mensagem == n u l l )
10 {
11 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
12 s t r i n g . Format ( " {0} − A mensagem r e c e b i d a e s t á v a z i a . \ r \n " , timestamp ) } ) ;
13 return ;
14 }
15
16 /∗
17 ∗ Agora é r e a l i z a d o o t e s t e s e a mensagem é v á l i d a , ou s e j a , s e tem os v a l o r e s
e s p e r a d o s como
18 ∗ i n í c i o e fim de mensagem .
19 ∗ I n í c i o de mensagem == 0x0A
20 ∗ 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 a p a r e c e r á 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 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
28 s t r i n g . Format ( " {0} − A mensagem r e c e b i d a é i n v á l i d a . \ r \n " , timestamp ) } ) ;
29 return ;
30 }
31 e l s e
32 {
33 /∗
34 ∗ Se a mensagem f o r v á l i d a , também é e s c r i t a a mensagem na t e l a .
35 ∗/
36 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
37 s t r i n g . Format ( " {0} − A mensagem r e c e b i d a é v á l i d a . \ r \n Mensagem r e c e b i d a : { 1 } . \ r \
n " , timestamp , B i t C o n v e r t e r . T o S t r i n g ( mensagem ) . R e p l a c e ( ’ − ’ , ’ ’ ) ) } ) ;
38 return ;
39 }
40 }
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 96

C.10 Salvar LOG em *.txt


1 private void b u t t o n 3 _ C l i c k ( object s e n d e r , EventArgs e )
2 {
3 /∗
4 ∗ Para nomear o a r q u i v o s e r á u t i l i z a d a a d a t a a t u a l
5 ∗ Para i s t o u t i l i z a −s e a e s t r u t u r a DateTime .
6 ∗/
7 s t r i n g str_aux = s t r i n g . Format ( " {0}−{1}−{2} LOG" , DateTime . Now . T o S t r i n g ( " yy " ) ,
8 DateTime . Now . T o S t r i n g ( "MM" ) , DateTime . Now . T o S t r i n g ( " dd " ) ) ;
9 /∗
10 ∗ U t i l i z a a c l a s s e S a v e F i l e D i a l o g , que h a b i l i t a o u s u á r i o e s c o l h e r
11 ∗ onde d e s e j a s a l v a r o a r q u i v o .
12 ∗/
13 S a v e F i l e D i a l o g s a v e F i l e D i a l o g 1 = new S a v e F i l e D i a l o g ( ) ;
14 /∗
15 ∗ D e f i n e que a r q u i v o s de t e x t o ( ∗ . t x t ) s e r á o t i p o padrão do a r q u i v o
16 ∗/
17 saveFileDialog1 . DefaultExt = " ∗ . txt " ;
18 saveFileDialog1 . F i l t e r = " txt f i l e s | ∗. txt " ;
19 /∗
20 ∗ Já i n c l u i o nome automaticamente no a r q u i v o
21 ∗/
22 s a v e F i l e D i a l o g 1 . FileName = str_aux ;
23 /∗
24 ∗ aguarda o u s u á r i o d e c i d i r onde s a l v a r á o a r q u i v o
25 ∗/
26 try
27 {
28 /∗
29 ∗ Abre a j a n e l a para que o u s u á r i o s a l v e o a r q u i v o .
30 ∗ Se não h o u v e r f a l h a s no p r o c e s s o , s e r á e x i b i d o um pop−up i n d i c a n d o i s t o ;
31 ∗ ou , c a s o o c o r r a uma f a l h a ou o u s u á r i o c a n c e l e a o p e r a ç ã o de s a l v a r o a r q u i v o
32 ∗ também s e r á 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 ( ) == D i a l o g R e s u l t .OK)
35 {
36 // s a l v a o a r q u i v o
37 richT extBox 2 . S a v e F i l e ( s a v e F i l e D i a l o g 1 . FileName , RichTextBoxStreamType .
UnicodePlainText ) ;
38 MessageBox . Show ( " Arquivo S a l v o " ) ;
39 }
40 else
41 {
42 MessageBox . Show ( " Arquivo não f o i s a l v o " ) ;
43 }
44 }
45 catch
46 {
47 /∗
48 ∗ a v i s a c a s o o c o r r a alguma e x c e ç ã o de s o f t w a r e
49 ∗/
50 MessageBox . Show ( " Falha " ) ;
51 }
52 }
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 97

C.11 Classe de Dados para Arquivo JSON


1 using N e w t o n s o f t . Json ;
2
3 public c l a s s Mensagem
4 {
5 public s t r i n g Data = s t r i n g . Format ( " {0}/{1}/{2} " , DateTime . Now . T o S t r i n g ( " dd " ) ,
DateTime . Now . T o S t r i n g ( "MM" ) ,
6 DateTime . Now . T o S t r i n g ( " yy " ) ) ;
7 public s t r i n g Hora = s t r i n g . Format ( " { 0 } : { 1 } : { 2 } " , DateTime . Now . T o S t r i n g ( "HH" ) ,
DateTime . Now . T o S t r i n g ( "mm" ) ,
8 DateTime . Now . T o S t r i n g ( " s s " ) ) ;
9 public s t r i n g msg_recebida ;
10 public Mensagem ( s t r i n g msg )
11 {
12 msg_recebida = msg ;
13 }
14 }

C.12 Criando Arquivo Formatado em JSON


1 private void Criar_Arquivo_JSON ( s t r i n g msg )
2 {
3 /∗
4 ∗ Cria uma nova v a r i á v e l do t i p o ’ Mensagem ’ conforme c r i a d o a n t e r i o r m e n t e
5 ∗/
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 N e w t o n s o f t para c o n v e r t e r a s t r u c t para o f o r m a t a t o
9 ∗ json .
10 ∗/
11 s t r i n g 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 try
13 {
14 /∗
15 ∗ Determina automaticamente a p a s t a ( f o l d e r ) onde o a r q u i v o s e r á s a l v o ,
16 ∗ s e r á s a l v o na p a s t a onde e s t á sendo e x e c u t a d o o s o f t w a r e .
17 ∗/
18 S t r i n g F o l d e r P a t h = Path . Combine ( Path . GetDirectoryName ( System . R e f l e c t i o n . Assembly .
GetExecutingAssembly ( ) . L o c a t i o n ) ) ;
19 /∗
20 ∗ L i s t a t o d o s os a r q u i v o s c o n t i d o s na p a s t a para d e t e r m i n a r s e é n e c e s s á r i o c r i a r
um novo a r q u i v o
21 ∗ ou s e j á e x i s t e um a r q u i v o com o nome d e s e j a d o
22 ∗/
23 string [ ] ArquivosnaPasta = D i r e c t o r y . G e t F i l e s ( FolderPath ) ;
24 /∗
25 ∗ Testa s e e x i s t e um a r q u i v o com o nome d e s e j a d o ; c a s o não e x i s t a , s e r á c r i a d o um
novo a r q u i v o
26 ∗ e s e r á informado na i n t e r f a c e do u s u á r i o onde o a r q u i v o s e r á s a l v o
27 ∗/
28 i f ( ! A r q u i v o s n a P a s t a . C o n t a i n s ( F o l d e r P a t h + s t r i n g . Format ( " \\ Exemplo Arquivo JSON .
txt " ) ) )
29 {
30 /∗
31 ∗ Cria o a r q u i v o com o nome : Exemplo Arquivo JSON . t x t
32 ∗/
Apêndice C. Códigos Utilizados na Metodologia do Trabalho 98

33 using ( StreamWriter sw = F i l e . Cr eateT ext ( F o l d e r P a t h + s t r i n g . Format ( " \\ Exemplo


Arquivo JSON . t x t " ) ) )
34 {
35 /∗
36 ∗ Informa ao u s u á r i o onde o novo a r q u i v o s e r á s a l v o
37 ∗/
38 B e g i n I n v o k e (new D e l e g a t e _ v o i d _ S t r i n g ( Append_Text ) , new object [ ] { richTextBox1 ,
39 s t r i n g . Format ( " Arquivo JSON s a l v o em : {0}\ r \n " , F o l d e r P a t h ) } ) ;
40 /∗
41 ∗ E s c r e v e a s t r i n g formatada em JSON e p u l a uma l i n h a
42 ∗/
43 sw . Write ( j s o n _ s t r i n g + " \ r \n " ) ;
44 }
45 }
46 e l s e
47 {
48 using ( StreamWriter sw = F i l e . AppendText ( F o l d e r P a t h + s t r i n g . Format ( " \\ Exemplo
Arquivo JSON . t x t " ) ) )
49 {
50 /∗
51 ∗ E s c r e v e a s t r i n g formatada em JSON e p u l a uma l i n h a
52 ∗/
53 sw . Write ( j s o n _ s t r i n g + " \ r \n " ) ;
54 }
55 }
56 }
57 catch ( E x c e p t i o n )
58 {
59 throw ;
60 }
61 }