Édipo Carneiro2022

Édipo Alexandre Pereira Carneiro
Desenvolvimento de um datalogger configurável

e de baixo custo para aplicação em pesquisas
ambientais
Cascavel-PR
2022
Desenvolvimento de um datalogger configurável e de

baixo custo para aplicação em pesquisas ambientais
Dissertação apresentada como requisito par-

cial para a obtenção do grau de Mestre pelo
Programa de Pós-Graduação em Ciência da
Computação (PPGComp) da Universidade
Estadual do Oeste do Paraná – Unioeste, cam-
pus de Cascavel.
Universidade Estadual do Oeste do Paraná – Unioeste – Cascavel

Centro de Ciências Exatas e Tecnológicas – CCET
Programa de Pós-Graduação em Ciência da Computação – PPGComp
Orientador: Dr. Rogério Luis Rizzi

Coorientadora: Dra. Claudia Brandelero Rizzi
Cascavel-PR
2022
Desenvolvimento de um datalogger configurável e de baixo custo para aplicação em pesquisas
ambientais/ Édipo Alexandre Pereira Carneiro. – Cascavel-PR, 2022-
236p. : il. (algumas color.) ; 30 cm.
Orientador: Dr. Rogério Luis Rizzi
Dissertação (Mestrado) – Universidade Estadual do Oeste do Paraná – Unioeste – Cascavel

Centro de Ciências Exatas e Tecnológicas – CCET
Programa de Pós-Graduação em Ciência da Computação – PPGComp, 2022.
1. Datalogger 2. Metodologia Ágil. 3. Dados Ambientais. I. Rizzi, Rogério. II. Universidade
Estadual do Oeste do Paraná. III. Centro de Ciências Exatas e Tecnológicas – CCET. IV. Desenvol-
vimento de um datalogger configurável e de baixo custo para aplicação em pesquisas ambientais
Desenvolvimento de um datalogger configurável e de

baixo custo para aplicação em pesquisas ambientais
Dissertação apresentada como requisito par-

cial para a obtenção do grau de Mestre pelo
Programa de Pós-Graduação em Ciência da
Computação (PPGComp) da Universidade
Estadual do Oeste do Paraná – Unioeste, cam-
pus de Cascavel.
Dr. Rogério Luis Rizzi

Orientador
Dra. Claudia Brandelero Rizzi

Coorientadora
Dr. Marcio Seiji Oyamada

UNIOESTE - Cascavel
Dr. Ivonei Freitas da Silva

UNIOESTE - Cascavel
Dr. Fernando de Lima Alves

IFPR - Cascavel
Cascavel-PR
2022
Dedico esse trabalho ao meu pai Aurelino, que pavimentou meu caminho e à Regina, luz
dos meus olhos, eternamente.
Agradecimentos
Primeiramente, não posso deixar de agradecer ao meu Pai, que nunca deixou de,
mesmo que com alguns sacrifícios, prover condições para que eu pudesse alçar voos mais
longos. Sem seu esforço, não teria chegado aqui. A minha esposa, Regina, por tornar, dia
a dia, meu caminho menos árduo. Sem seu apoio, certamente essas palavras não estariam
sendo escritas (e revisadas).
Agradeço imensamente ao meu orientador Rogério Luis Rizzi. Direto, focado,
incansável. De uma dedicação ímpar, é de longe o Professor mais comprometido e atento
que pude conhecer. Você é um exemplo de servidor e foi um prazer compartilhar do seu
tempo e saber. Agradeço também a minha coorientadora Claudia Brandelero Rizzi, que
com seu conhecimento, paciência e sutileza nos apontamentos, foi de suma importância
para construção e finalização deste trabalho.
Agradeço aos meus colegas de trabalho, Lucas Rafael Castanhetti e Leonardo
Contini, por todo o apoio e suporte.
Agradeço aos Professores que participaram da banca de qualificação, cujas con-
tribuições enriqueceram esse trabalho de pesquisa. Agradeço ainda a todos os demais
professores do programa, que se desdobraram em tempos de pandemia para adequar suas
aulas ao ambiente virtual, para garantir que nossa formação não fosse afetada. Por fim,
mas não menos importante, agradeço também aos meus colegas de mestrado, que foram
uma grata surpresa encontrada ao longo desta caminhada.
"Quanto ao futuro, não se trata de prevê-lo, mas de torná-lo possível"
(Saint-Exupéry)
Resumo
Pesquisas que envolvem a avaliação de parâmetros ambientais necessitam da aquisição de
uma grande massa de dados em intervalos e grandezas diferentes. Tais dados necessitam
ser precisos e confiáveis e sua observação, devido a necessidade do registro de eventos
que ocorrem em um intervalo de tempo muito curto ou muito longo, extrapola os limites
da capacidade humana. Visando atender a essa demanda, o objetivo principal deste
trabalho foi a criação de um datalogger que pudesse ser utilizado em diversas pesquisas,
que fosse viável economicamente e de fácil operação. Para tanto, foram primeiramente
avaliadas algumas soluções acadêmicas e comerciais existentes e também aspectos técnicos
e metodológicos empregados nessas construções. Na sequência, foram aplicados conceitos
de metodologias ágeis de desenvolvimento de software para criação do projeto e elaboração
das camadas de hardware, firmware e software que compõe o datalogger. Uma vez concluída
a construção do protótipo, foram realizados testes piloto a fim de avaliar se o protótipo
atendia a todos os requisitos elicitados e em seguida foi realizado um estudo de caso,
com a aplicação do datalogger para automatização da coleta de dados de um simulador
de chuva construído na Universidade do Oeste do Paraná (UNIOESTE), campus de
Cascavel/PR, que tem por objetivo o desenvolvimento e validação de modelos de perda
de água e do solo por escoamento superficial em função da taxa de cobertura vegetal.
Para tanto, a automatização envolveu a utilização de nove sensores analógicos de umidade
de solo, um sensor digital de vazão de água e um sensor digital ultrassônico. Todo o
processo de calibração e coleta dos dados dessa aplicação é detalhado passo a passo e os
dados coletados são apresentados, analisados estatisticamente e na sequência comparados
em relação a um datalogger comercial, com a finalidade de atestar aspectos como o de
precisão e estabilidade da solução. Considerando-se todas as análises realizadas, foi possível
concluir que o datalogger acadêmico se mostrou estável e com boa precisão, possibilitando
a realização da coleta de dados sem incidência de falha e sem dificuldade de operação pelos
pesquisadores envolvidos. O custo total para construção de uma unidade do datalogger foi
de US$ 192,35, atendendo o principal objetivo: a criação de uma solução de baixo custo e
de fácil operação para aplicação em pesquisas ambientais.
Palavras-chave Datalogger, Metodologia Ágil, Arduino, Raspberry, Dados ambientais.

Abstract
Research involving the evaluation of environmental parameters requires the acquisition of
a large mass of data in different intervals and quantities. Such data must be accurate and
reliable, and its observation can exceed the limits of human capacity because of the need
to record events that happens in a very short or very long time span. To meet this need,
the main objective of this work was to develop a data logger that can be used in different
research areas, is economically viable and easy to use. To this end, some existing academic
and commercial solutions and the technical and methodological aspects used in these
designs were first evaluated. Then, concepts of agile software development methodology
were applied to create the project and prepare the layers of hardware, firmware and
software that make up the data logger. Once the prototype design was completed, a pilot
test was conducted to evaluate whether the prototype met all identified requirements.
Subsequently, a case study was conducted in which the data logger was used to automate
the data acquisition of a rainfall simulator built at the Universidade do Oeste do Paraná
(UNIOESTE), campus of Cascavel/ PR, to develop and validate models of water and soil
loss by runoff as a function of vegetation cover. For this purpose, nine analog soil moisture
sensors, one digital water flow sensor, and one digital ultrasonic sensor were used. The
whole process of calibration and data collection of this application is described step by
step and the collected data are presented, statistically analyzed and then compared with
a commercial data logger to confirm aspects such as the accuracy and stability of the
solution. Taking into account all the analyzes performed, it was found that the academic
data logger proved to be stable and precise, allowing the data collection to be performed
by the researchers involved without any failures or operational difficulties. The total cost
of building a data logger was $192.35. Thus, the main goal was achieved: to create a
cost-effective and easy to use solution for use in environmental research.
Keywords: Datalogger, Agile methodology, Arduino, Raspberry, Environmental data.

Lista de ilustrações
Figura 1 – Camadas de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 30

Figura 2 – Arquitetura de hardware proposta . . . . . . . . . . . . . . . . . . . . 38
Figura 3 – Diagrama da estação meteorológica . . . . . . . . . . . . . . . . . . . . 39
Figura 4 – Diagrama do datalogger Zoiologger proposto por Pereira (2013) . . . . 41
Figura 5 – Diagrama do datalogger proposto pelos autores López-Vargas et al. (2018) 43
Figura 6 – Diagrama de atividade do firmware do Zoiologger . . . . . . . . . . . . 46
Figura 7 – Diagrama das rotinas executadas por cada interação . . . . . . . . . . 47
Figura 8 – Diagrama de funcionamento do LaMALogger . . . . . . . . . . . . . . 48
Figura 9 – Tela do software BlueTerm . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 10 – Datalogger NESA Evolution . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 11 – Telas do software de configuração e exibição do equipamento Evolution 51
Figura 12 – Datalogger CAMPBELL CR1000 . . . . . . . . . . . . . . . . . . . . . 52
Figura 13 – Tela do software PC200W . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 14 – Datalogger STEVENS DLight Logger . . . . . . . . . . . . . . . . . . . 53
Figura 15 – Tela do software LoggerSet . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 16 – Visão geral da arquitetura do protótipo . . . . . . . . . . . . . . . . . . 58
Figura 17 – Visão da camada física da arquitetura do protótipo . . . . . . . . . . . 60
Figura 18 – Diagrama do circuito parte 1 . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 19 – Diagrama do circuito parte 2 . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 20 – Layout da placa de circuito impresso . . . . . . . . . . . . . . . . . . . 65
Figura 21 – Visão da camada lógica (firmware) da arquitetura do protótipo . . . . 66
Figura 22 – Diagrama de atividades do funcionamento do firmware . . . . . . . . . 69
Figura 23 – Esquematização da camada de software da arquitetura do protótipo . . 69
Figura 24 – Diagrama de casos de uso do datalogger . . . . . . . . . . . . . . . . . 72
Figura 25 – Projeto elaborado para uma das abas do sistema de configuração . . . 72
Figura 26 – Projeto de interface de exibição . . . . . . . . . . . . . . . . . . . . . . 74
Figura 27 – Placa de circuito impresso . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figura 28 – Datalogger com seus componentes e módulos adicionados. A imagem
destacada por (a) é a parte superior da PCB, a imagem destacada por
(b) é a parte inferior da PCB a imagem destacada por (c) ilustra o
datalogger instalado. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figura 29 – Tela inicial do configurador com informações sobre o projeto . . . . . . 81
Figura 30 – Tela de configurações do datalogger e dos sensores existentes . . . . . . 82
Figura 31 – Exemplo da mensagem de confirmação das configurações . . . . . . . . 82
Figura 32 – Tela de envio de aplicações ao datalogger . . . . . . . . . . . . . . . . . 83
Figura 33 – Guia de acompanhamento dos dados . . . . . . . . . . . . . . . . . . . 83
Figura 34 – Tela principal do software de exibição dos dados . . . . . . . . . . . . . 84
Figura 35 – Simulador de chuva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figura 36 – Sensor de umidade de solo do tipo capacitivo . . . . . . . . . . . . . . 88
Figura 37 – Processo de preparação do sensor de umidade do solo . . . . . . . . . . 89
Figura 38 – Sensor imerso em água . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 39 – Sensor de fluxo de água . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 40 – Sensor ultrassônico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figura 41 – Instalação do sensor de fluxo de água (destacado em pontilhado) . . . . 93
Figura 42 – Gráfico de correlação vazão x frequência . . . . . . . . . . . . . . . . . 93
Figura 43 – Regressão linear dos dados experimentais da vazão de água com a leitura
do sensor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Figura 44 – Balde graduado e sensor instalado . . . . . . . . . . . . . . . . . . . . . 97
Figura 45 – Regressão linear do sensor ultrassônico . . . . . . . . . . . . . . . . . . 98
Figura 46 – Pote com solo e pote sendo saturado de água . . . . . . . . . . . . . . 104
Figura 47 – Esquema da calibração dos sensores de umidade sobre o processo cíclico
e a forma de como foi colocado os sensores nos potes. . . . . . . . . . . 106
Figura 48 – Sensores inseridos nas amostras de solo . . . . . . . . . . . . . . . . . . 106
Figura 49 – Ajustes lineares da umidade do solo em função da leitura dos sensores . 108
Figura 50 – Lâmpadas infravermelhas para a secagem do solo entre um experimento
do outro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figura 51 – Incremento de umidade para 3 camadas de solo durante e depois da
aplicação da chuva simulada em diferentes níveis de cobertura de palha
de soja. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figura 52 – Média das leituras do datalogger acadêmico e comercial para os sensores
de umidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figura 53 – Teste em ambiente de campo . . . . . . . . . . . . . . . . . . . . . . . 222
Figura 54 – Dados coletados pelo teste realizado em 06/02/2021 . . . . . . . . . . . 222
Figura 55 – Teste em ambiente de laboratório . . . . . . . . . . . . . . . . . . . . . 223
Figura 56 – Interface de coleta e módulo de armazenamento . . . . . . . . . . . . . 233
Figura 57 – Datalogger desenvolvido pelo autor, com destaque ao módulo RTC e ao
módulo SD-Card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Figura 58 – Datalogger criado por Netto e Arigony-Neto (2019) . . . . . . . . . . . 234
Figura 59 – PCB criada por Pereira (2013) utilizando microcontrolador ATMEL, e
Shield do cartão SD, respectivamente . . . . . . . . . . . . . . . . . . . 234
Figura 60 – Visualização renderizada da placa de circuito impresso (PCB) criada
por Reges (2017) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Figura 61 – Montagem do protótipo de datalogger proposto por López-Vargas et al.
(2018) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Lista de quadros
Quadro 1 – Comparativo entre projetos acadêmicos pesquisados . . . . . . . . . . 56

Quadro 2 – Comparativo entre dataloggers comerciais . . . . . . . . . . . . . . . . 56
Quadro 3 – Custo dos componentes utilizados para elaboração do datalogger . . . 79
Quadro 4 – Correlação vazão x frequência disponibilizado na documentação do
sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Quadro 5 – Correlação entre vazão e frequência para cálculo da razão em mL por
pulso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Quadro 6 – Média (L h−1 ) de acordo com as pressões de entrada de água do simulador 95
Quadro 7 – Razão volume/pulso de acordo com as pressões . . . . . . . . . . . . . 96
Quadro 8 – Média de distância lida pelo sensor de acordo com volume adicionado 98
Quadro 9 – Resultados do processo de pré-calibração . . . . . . . . . . . . . . . . 99
Quadro 10 – Teste de Tukey para a comparação das médias entre as leituras dos
nove sensores de umidade. . . . . . . . . . . . . . . . . . . . . . . . . 102
Quadro 11 – Resultado das pesagens das amostras . . . . . . . . . . . . . . . . . . 104
Quadro 12 – Percentual de umidade esperado conforme volume de água existente . 105
Quadro 13 – Média dos valores obtidos no processo descrito na etapa 11 . . . . . . 107
Lista de tabelas
Tabela 1 – Sensores utilizados no projeto de Abdalla (2015) . . . . . . . . . . . . 36

Tabela 2 – Sensores utilizados no projeto de Galdino et al. (2019) . . . . . . . . . 37
Tabela 3 – Sensores utilizados no projeto de Karami, Mcmorrow e Wang (2018) . 38
Tabela 4 – Sensores utilizados no projeto de Netto e Arigony-Neto (2019) . . . . . 40
Tabela 5 – Sensores utilizados no projeto de Pereira (2013) . . . . . . . . . . . . . 41
Tabela 6 – Sensores utilizados no projeto de Reges (2017) . . . . . . . . . . . . . . 42
Tabela 7 – Sensores utilizados no projeto de López-Vargas et al. (2018) . . . . . . 43
Tabela 8 – Principais características de Hardware do equipamento NESA - Evolution. 50
Tabela 9 – Principais características de Firmware do equipamento NESA - Evolution. 51
Tabela 10 – Principais características de Software do equipamento NESA - Evolution. 51
Tabela 11 – Principais características de Hardware do equipamento Campbell -
CR1000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 12 – Principais características de Firmware do equipamento Campbell -
CR1000. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 13 – Principais características de Software do equipamento Campbell - CR1000. 53
Tabela 14 – Principais características de Hardware do equipamento Stevens - DLight
Logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 15 – Principais características de Firmware do equipamento Stevens - DLight
Logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 16 – Principais características de Software do equipamento Stevens - DLight
Logger. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Tabela 17 – Requisitos da camada de hardware . . . . . . . . . . . . . . . . . . . . 60
Tabela 18 – Requisitos da camada de firmware . . . . . . . . . . . . . . . . . . . . 66
Tabela 19 – Requisitos da camada de software . . . . . . . . . . . . . . . . . . . . . 70
Tabela 20 – Requisitos da camada do software de exibição . . . . . . . . . . . . . . 73
Tabela 21 – Estrutura da tabela "dado"do banco de dados . . . . . . . . . . . . . . 74
Tabela 22 – Cenários de teste da camada de firmware . . . . . . . . . . . . . . . . . 76
Tabela 23 – Cenários de teste da camada do software de configuração . . . . . . . . 76
Tabela 24 – Lista de componentes da PCB . . . . . . . . . . . . . . . . . . . . . . . 78
Tabela 25 – Testes realizados e resultados obtidos . . . . . . . . . . . . . . . . . . . 85
Tabela 26 – Composição granulométrica1 do solo nas camadas de 0 ⊢ 0, 1; 0, 1 ⊢ 0, 2
e 0, 2 ⊢ 0, 3 m da área experimental do IAPAR/Santa Tereza (valores
médios de 3 repetições) . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Tabela 27 – Especificações do sensor de umidade do solo de acordo com o fornecedor 88
Tabela 28 – Especificações do sensor de vazão de acordo com o fornecedor . . . . . 90
Tabela 29 – Especificações do sensor ultrassônico . . . . . . . . . . . . . . . . . . . 92
Tabela 30 – Coeficientes e métricas do ajuste linear da vazão (V ) em função da
frequência (F ) com dados existentes na documentação do sensor . . . . 94
Tabela 31 – Coeficientes e métricas do ajuste linear da vazão (V ) em função da
frequência (F ) com dados experimentais . . . . . . . . . . . . . . . . . 97
Tabela 32 – Coeficientes e métricas do ajuste linear do volume de água (V ) em
função da leitura do sensor (S) . . . . . . . . . . . . . . . . . . . . . . 98
Tabela 33 – Tabela de análise de variância (ANOVA) para Delineamento Inteira-
mente ao Acaso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Tabela 34 – ANOVA dos sensores de umidade na fase seca . . . . . . . . . . . . . . 100
Tabela 35 – ANOVA dos sensores de umidade na fase úmida . . . . . . . . . . . . . 101
Tabela 36 – Coeficientes e métricas dos modelos ajustados aos 9 sensores de umidade
do solo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Tabela 37 – ANOVA para comparação entre o datalogger acadêmico e comercial a
5% de significância . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Lista de abreviaturas e siglas
AC Alternating Current
ANOVA Análise de Variância
ARM Advanced RISC Machine
CEMADEM Centro Nacional de Monitoramento e Alertas de Desastres Naturais
CI Circuito Integrado
DBC Delineamento em Blocos Casualizados
DC Direct Current
DIC Delineamento Inteiramente Casualizado
FTP File Transfer Protocol
GPS Global Positioning System
ha Hectare
HTTP Hypertext Transfer Protocol
I2C Inter-Integrated Circuit
IEC Comissão Eletrotécnica Internacional
IEQ Qualidade Ambiental em Ambientes Internos
ISR Interrupt Service Routine
LED Light-Emitting Diode
NTP Network Time Protocol
mca Metros de Coluna D’Agua
PCB Printed Circuit Board
PCI Placa de Circuito Impresso
PHP Hypertext Preprocessor
PWM Pulse Width Modulation

ROM Read-only Memory
RS232 Recommended Standard 232
RS485 Recommended Standard 485
RTC Real Time Clock
SD Secure Digital
SMTP Simple Mail Transfer Protocol
t Tonelada
TTL Transistor-Transistor Logic
UFMT Universidade Federal do Mato Grosso
VDC Volts Direct Current
VOC Volatile organic compound
XP Extreme Programming
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2 Objetivos, Geral e Específicos . . . . . . . . . . . . . . . . . . . . . . 28
1.3 Justificativa e relevância do trabalho . . . . . . . . . . . . . . . . . . 29
1.4 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.5 Questão de pesquisa e sua contribuição . . . . . . . . . . . . . . . . . 31
2 REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . 33
2.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4 Dataloggers Comerciais . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.5 Comparativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3 MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . . . 57
3.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.1.2 Componentes e módulos utilizados . . . . . . . . . . . . . . . . . . . . . . 62
3.1.2.1 Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.2.2 Módulos RS485 e RS232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.2.3 Módulo de relógio (RTC) . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1.2.4 Raspberry Pi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.1.3 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.2.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.1 Software de configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.3.1.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.3.2 Software de exibição dos dados . . . . . . . . . . . . . . . . . . . . . . . . 73
3.3.2.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.3.2.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4 Validação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.4.1 Cenários de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1 Datalogger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.2 Firmware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.3 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.3.1 Software de Configuração . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
4.1.3.2 Software de Exibição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.1.4 Testes Piloto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.2 Aplicação em um simulador de chuva . . . . . . . . . . . . . . . . . . 86
4.2.1 Sensor de umidade de solo . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2.2 Sensor de fluxo de água . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2.3 Sensor ultrassônico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.4 Calibração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2.4.1 Sensor de fluxo de água . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.2.4.2 Sensor ultrassônico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.2.4.3 Sensores de umidade de solo . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.3 Avaliação de desempenho e análise de dados . . . . . . . . . . . . . 108
5 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
6 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . 115
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
APÊNDICES 121
APÊNDICE A – DOCUMENTO DE REQUISITOS . . . . . . . . . 123
APÊNDICE B – MANUAL DE INSTALAÇÃO DO AMBIENTE DE

VISUALIZAÇÃO DO DATALOGGER . . . . . . . 161
APÊNDICE C – CÓDIGO FONTE DO FIRMWARE DO DATA-

LOGGER . . . . . . . . . . . . . . . . . . . . . . . 171
APÊNDICE D – ROTEIRO EM R DAS ANÁLISES DE DADOS . . 203
ANEXOS 225
ANEXO A – DATASHEET DO SENSOR DE VAZÃO DE ÁGUA . 227
ANEXO B – DATASHEET DO SENSOR ULTRASSÔNICO . . . . 229

ANEXO C – FIGURAS REVISÃO BIBLIOGRÁFICA . . . . . . . . 233
27
1 Introdução
1.1 Motivação
A principal motivação para o desenvolvimento dessa dissertação de mestrado foi

contribuir à solução da coleta e do registro automático de dados, que são gerados por
meio de trabalhos ou pesquisas laboratoriais ou em campo, especificamente àqueles que
envolvem parâmetros ambientais.
Pesquisas que envolvem parâmetros ambientais costumam necessitar da aquisição
de uma grande massa de dados em intervalos e grandezas diferentes. Tais dados necessitam
ter precisão e confiabilidade e, muitas vezes, extrapolam os limites da capacidade humana
de observação por necessitarem de períodos de observação muito curtos, a exemplo da
velocidade e duração de uma rajada de vento, ou muito longos, como níveis de radiação
solar em um ou mais horários durante todo o ano.
Esse tipo de solução torna-se cada vez mais relevante em diversos tipos de aplicação,
que vão desde a coleta e registro automático de dados de sensores e verificação do
funcionamento esperado de um dispositivo até o uso dos dados para alimentar sistemas
de inteligência artificial e aprendizagem de máquina, que necessitam de grande volume
de dados para treinamento, teste, validação e aplicação de seus modelos. Atualmente, em
parte devido ao alto custo das soluções disponíveis, o uso se torna mais restrito a algumas
áreas, tais como: meteorologia, sismologia, estudos para construção de parques eólicos ou
usinas solares, monitoramento de barragens, indústria aeroespacial, dentre outros (ONSET,
2021).
Um exemplo dessa aplicação é a pesquisa realizada por Cunha et al. (2018), do
Centro Nacional de Monitoramento e Alertas de Desastres Naturais (CEMADEN), que
utilizou dados de 86 estações pluviométricas localizadas na região Nordeste do Brasil,
coletados entre 1982 e 2016 e comparou com dados de temperatura da superfície dos
oceanos Pacífico e Atlântico. Com a análise foi possível o desenvolvimento de um método
que viabiliza mapear a intensidade da seca com resolução espacial de quatro quilômetros.
Assim, para esses tipos de pesquisas, que envolvem o registro de observações,
medidas ou eventos sistematicamente durante um longo período de tempo, torna-se im-
prescindível o uso de um sistema automatizado que contemple o emprego de sensores que
gerem grandezas físicas passíveis de serem capturadas ou monitoradas por um sistema de
hardware e software. Esse sistema, que é usualmente designado de coletor de dados ou
datalogger, consiste em um equipamento eletrônico constituído basicamente por micropro-
cessadores, memória interna, conexões para sensores e conexões de entrada e ou saída de
28 Capítulo 1. Introdução
dados.
A proposta da criação de um datalogger de baixo custo visa propiciar seu acesso
a uma parcela maior de pesquisadores, facilitando o desenvolvimento de seus estudos ou
ampliando a captura de dados a mais de uma localidade. Igualmente importante é o uso de
dataloggers por empresas na criação de novos serviços ou produtos em áreas que necessitem
da coleta de dados.
Durante a fase de levantamento bibliográfico, buscando-se por artigos e trabalhos
científicos relacionados, notou-se nas soluções acadêmicas existentes a ausência de detalha-
mento metodológico, escassez na justificativa das escolhas técnicas empregadas em suas
construções e também não apresentam análise comparativa ou estatística. De tal modo,
este trabalho visou também elaborar uma significativa fundamentação metodológica, bem
como análises comparativas de algumas das funcionalidades do datalogger proposto em
relação a um datalogger comercial.
1.2 Objetivos, Geral e Específicos

O objetivo geral deste trabalho foi descrever o desenvolvimento e aplicação de um
datalogger completo, considerando suas camadas de hardware, firmware e software. Este
sistema atendeu aos seguintes principais requisitos não-funcionais: baixo custo, facilidade
de operação e aplicabilidade na coleta e registro de dados ambientais.
Para alcançar tal objetivo, foi necessária a realização de atividades que incluíram:
1. Levantamento bibliográfico para avaliação de aspectos técnicos e metodológicos das

soluções existentes.
2. A criação de um protótipo de hardware de baixo custo para leitura e registro dos

dados.
3. O projeto e desenvolvimento, fazendo uso de metodologias ágeis, de um firmware

configurável, de um software para configuração e de um software para exibição dos
dados coletados para o datalogger.
4. Fundamentação detalhada da metodologia adotada para o desenvolvimento das

camadas do datalogger.
5. A realização de atividades específicas para a calibração do protótipo e a análise de

dados.
1.3. Justificativa e relevância do trabalho 29
1.3 Justificativa e relevância do trabalho

Para a tecnologia da informação, um dado é por definição uma representação
simbólica de atributos qualitativos ou quantitativos relacionados a observações de eventos,
fenômenos ou estados de qualquer natureza.
Dados ambientais são considerados indispensáveis para o estudo e monitoramento
de recursos hídricos, eólicos, solares, na prevenção de desastres naturais, entre outras
aplicações. A coleta de tais dados pode requerer observações contínuas ou durante longo
período de tempo e se realizadas manualmente costumam ter um alto custo de recursos
humanos e um alto risco de falha. A automatização da atividade de coleta de dados visa
eliminar esses problemas e, para tanto, foram criados dispositivos coletores de dados, que
também são chamados de dataloggers.
Pesquisas e o levantamento bibliográfico realizados mostraram que existem diversas
empresas, em sua maioria internacionais, das quais destacam-se Stevens Water, Campbell
Scientific e NESA SRL, que possuem dataloggers em suas linhas de produtos. Os equipa-
mentos fornecidos por empresas deste ramo possuem alta confiabilidade e precisão. As
características de operação (como alimentação, consumo de energia, entre outros fatores),
de precisão e quantidade das portas disponíveis, de recursos e funcionalidades (GPS
integrado, barômetro integrado, expansores, etc), variam de acordo com os modelos e as
empresas fabricantes. Um comparativo entre um modelo de datalogger de cada uma das
empresas supracitadas foi elaborado no Quadro 2, do capítulo 2.
No entanto, estes produtos disponíveis no mercado possuem um alto custo. De
acordo com levantamento realizado em Julho de 2021, os valores encontrados foram em
torno de US$ 2.500,00 para o CR1000 da Campbell Scientific, de US$ 2.000,00 para o
Evolution da NESA e de US$ 1.200,00 para o Dlight Logger da Stevens Water, que devido
a taxas de importação, transporte e conversão de moeda, partem de 10 mil e podem chegar
a 30 mil reais, dificultando ou inviabilizando a aquisição desse tipo de equipamento.
Além disso, a experiência profissional na utilização de tais equipamentos comerciais
mostrou que embora eles tenham grande número de recursos e funcionalidades, são de
operação complexa para o usuário comum, o que costuma demandar treinamento e tempo
significativo para seu efetivo aprendizado e operação. Devido a isso, buscou-se com o
datalogger desenvolvido que sua configuração e operação fossem simplificadas, facilitando
o seu uso mesmo por usuários leigos.
1.4 Organização do trabalho

Para criação de um datalogger são necessários, invariavelmente, o Projeto e Desen-
volvimento nas áreas de hardware, firmware e software. A Figura 1 apresenta cada uma
30 Capítulo 1. Introdução
das camadas, suas ordens de criação e suas respectivas proporções, considerando-se como
métrica a complexidade e o tempo envolvido para planejamento e criação.
A construção desse tipo de dispositivo se inicia pelo planejamento, especificação e
montagem do hardware. O planejamento deve considerar o atendimento às demandas gerais
de um datalogger e também alternativas para atendimento a demandas mais específicas,
seja pela existência de interruptores ou conexões para ligação de outros hardwares. Em
sequência, é necessário projetar e desenvolver a camada de firmware, que é responsável por
operar todas as rotinas requisitadas. Essa camada deve ser capaz de considerar as mais
diversas configurações possíveis, reagindo e adequando seu funcionamento aos parâmetros
indicados. Posteriormente, projeta-se o software que irá possibilitar a configuração dos
parâmetros de funcionamento do equipamento e também exibir de forma gráfica os dados
que foram coletados.
Figura 1 – Camadas de desenvolvimento
Fonte: Autor
A Figura 1 ilustra as etapas do projeto e do desenvolvimento das camadas do

sistema de aquisição e registro automático de dados, este trabalho foi organizado para
apresentar inicialmente a revisão bibliográfica realizada enfocando aspectos técnicos e
metodológicos de trabalhos relacionados com o projeto, desenvolvimento e aplicação de
dataloggers, tanto aqueles acadêmicos quantos os comerciais. São apresentadas as discussões
e comparações quanto às funcionalidades, operações e outros aspectos de interesse. Na
sequência, no Capítulo 3, são detalhadas as camadas de desenvolvimento e as metodologias
adotadas para construção do protótipo proposto. Por fim, no Capítulo 4, apresentam-se
os resultados obtidos, bem como a análise dos dados gerados, visando verificar aspectos
de precisão, sensibilidade e confiabilidade do protótipo, quando comparado com outros
dispositivos.
1.5. Questão de pesquisa e sua contribuição 31
1.5 Questão de pesquisa e sua contribuição

Este trabalho buscou avaliar a viabilidade do desenvolvimento de um datalogger
de baixo custo, considerando as camadas de hardware, firmware e software, voltado ao
registro de parâmetros ambientais.
A relevância para o desenvolvimento tecnológico na Ciência da Computação se
deu pela realização de discussões detalhadas e esclarecedoras ao processo de especificação,
projeto e desenvolvimento desse tipo de equipamento, com ênfase ao uso de hardware de
baixo custo e ao desenvolvimento de software por meio de metodologias ágeis, com foco
na usabilidade (user-friendly), facilitando assim o uso do equipamento por usuários não
especializados.
O protótipo elaborado nesse trabalho, devido aos atributos de baixo custo e
funcionalidades disponíveis, contribui com o emprego da coleta e registro de dados de
aspectos relevantes ou de potencial interesse na gestão de dados ambientais, seja por
pesquisadores, usuários não especializados ou empresas que atuem em áreas correlatas.
Todos os diagramas e códigos-fonte desenvolvidos no trabalho foram compartilhados em
um repositório público.
33
2 Revisão Bibliográfica
O objetivo deste capítulo é apresentar e discutir alguns dos principais trabalhos

que foram identificados no levantamento bibliográfico, realizado por palavras-chave, em
que se buscou identificar quais foram os materiais e métodos utilizados pelos autores no
desenvolvimento e aplicação de dataloggers. As palavras-chave utilizadas foram datalogger,
Arduino, sistema de aquisição de dados de baixo custo e sensores de baixo custo. As
buscas foram realizadas na plataforma do Google Acadêmico (GOOGLE, 2022), na
base de periódicos da Capes (CAPES, 2022) e também na rede social Researchgate
(RESEARCHGATE, 2022).
A organização do texto, assim como a consequente discussão das temáticas tratadas
segue a escolha declarada no primeiro capítulo, que é a de estruturar sua apresentação
aglutinando as contribuições dos diferentes autores em seções que contemplem separada-
mente os aspectos técnicos e metodológicos relacionados ao projeto e ao desenvolvimento
das camadas de hardware, de firmware e de software.
Inicialmente é relevante notar que a leitura dos textos analisados mostrou que cada
autor ou desenvolvedor dos dataloggers não comerciais, buscou uma solução específica
para automatizar a coleta e registro dos dados relevantes à sua pesquisa. De modo geral,
não se observou qualquer preocupação em que seu equipamento servisse a outro propósito
ou que pudesse ser utilizado por outros investigadores na realização de outras pesquisas.
Outro aspecto importante foi falta de embasamento ou discussão sistemática a respeito
dos aspectos técnicos e metodológicos no desenvolvimento das 3 camadas do datalogger.
Neste contexto, é apresentado um panorama do que foi desenvolvido por cada autor e
quais foram os principais aspectos identificados do ponto de vista técnico e metodológico.
O principal objetivo do trabalho de Abdalla (2015) foi a construção de um sistema
de baixo custo, sem fio, para coleta de dados microclimáticos. No trabalho são apresentados
os módulos e sensores utilizados e também como foi o processo de ligação e montagem do
equipamento desenvolvido. As grandezas registradas no trabalho são temperatura, umidade
e dados de localização. Nos anexos do referido estudo, o autor adicionou os códigos fonte do
firmware e do software criados para inserção dos dados no banco de dados. Um estudo de
caso foi apresentado para a validação do funcionamento do equipamento criado. Do ponto
de vista técnico, observa-se que o autor descreveu de forma simples, porém satisfatória,
quais os procedimentos necessários para montagem e funcionamento do equipamento. Do
ponto de vista metodológico, faltaram informações a respeito de como foram feitas as
escolhas dos módulos utilizados e quais requisitos visavam ser atendidos como um todo,
haja vista que o objetivo principal era a criação de um datalogger.
34 Capítulo 2. Revisão Bibliográfica
O trabalho de Galdino et al. (2019) apresentou de forma superficial a criação de um

datalogger para registro de dados pluviométricos. Não houve menção a como as camadas
de hardware e firmware foram criadas e também não foi elaborado nenhum software para
exibição dos dados. Apesar de o objetivo descrito pelo autor ter sido o desenvolvimento de
dataloggers de baixo custo, o trabalho teve mais ênfase na apresentação de um comparativo
entre dataloggers comerciais e o datalogger criado do que na apresentação dos aspectos
técnicos e metodológicos envolvidos.
Os autores Karami, Mcmorrow e Wang (2018) tiveram por objetivo a criação de
uma solução de baixo custo e facilmente extensível, visando a coleta de dados de qualidade
de ambientes internos. As grandezas registradas pelo datalogger criado foram velocidade
de vento, temperatura do ar, umidade relativa do ar, iluminância vertical e horizontal,
C02, composto orgânico volátil (VOC) e presença. Os autores apresentam os aspectos
técnicos envolvidos na montagem do hardware desenvolvido. Não se observa na pesquisa
uma discussão a respeito do requisitos do firmware ou de como foram realizados seus
processos. Os autores optaram pelo uso de uma plataforma open-source de software para
exibição dos dados coletados, a qual tem seu funcionamento exibido no trabalho, porém
os autores não citam como se deu a integração. Do ponto de vista metodológico não
são justificadas as escolhas que foram tomadas. Ainda, nota-se que o trabalho apresenta
como foi feita a calibração dos sensores utilizados e um estudo de caso para mostrar o
funcionamento do equipamento. Apesar de o objetivo descrito pelo autor ter sido a criação
de um equipamento de baixo custo utilizando tecnologias open-source, não foram dadas
condições a outros pesquisadores para que a criação do equipamento fosse reproduzida.
Os autores Netto e Arigony-Neto (2019) apresentaram a criação de um datalogger
para uma estação meteorológica automática (Automatic Weather Station - AWS). Os
dados registrados pela estação foram velocidade e direção de vento, luminosidade, acúmulo
de neve, temperatura do ar, umidade relativa do ar, temperatura da água e pressão
atmosférica. Os aspectos técnicos foram bem descritos pelo autor, sendo possível reproduzir
a criação do equipamento tanto na camada de hardware quanto de firmware. Quanto
aos aspectos metodológicos, não foi apresentado o levantamento de requisitos indicando
quais as funcionalidades deveriam ser atendidas em cada camada. Ainda que ausente o
levantamento supracitado, vale destacar que as escolhas tomadas pelos autores na camada
de hardware foram bem justificadas.
No estudo de Pereira (2013) realizou-se a implementação de um datalogger parame-
trizável para coleta de dados microclimáticos georreferenciados. As grandezas registradas
foram temperatura do ar, umidade relativa do ar e dados de localização. Tanto os aspec-
tos técnicos quanto metodológicos foram apresentados pelo autor de modo satisfatório.
Tecnicamente são justificadas cada uma das escolhas dos módulos utilizados e é possível
reproduzir a criação do equipamento. Metodologicamente o trabalho também foi bem
2.1. Hardware 35
elaborado. O autor realizou levantamentos de requisitos para as camadas de hardware

e software. Na camada de software o autor também teve o cuidado de apresentar os
diagramas de caso de uso e sequência para fundamentar ainda mais as escolhas tomadas e
qual o funcionamento esperado do equipamento desenvolvido.
O autor Reges (2017) realizou o desenvolvimento de um sistema de aquisição de
dados para sistemas fotovoltaicos. As grandezas lidas pelo datalogger foram temperatura,
corrente e tensão elétricas. Os aspectos técnicos da camada de hardware do projeto foram
bem apresentados, sendo possível a reprodução da criação do equipamento. Os aspectos
para criação do firmware não foram citados no trabalho. Do ponto de vista metodológico,
o autor não apresentou levantamento de quais requisitos deveriam ser atendidos e também
não justificou as escolhas tomadas na adoção dos módulos de hardware utilizados para
criação do equipamento.
A pesquisa de López-Vargas et al. (2018) realizou o desenvolvimento de um da-
talogger para coleta de dados de sistemas fotovoltaicos. As grandezas registradas foram
irradiação solar, temperatura do ar, umidade relativa do ar, velocidade de vento e quanti-
dade de chuva. Os aspectos técnicos da camada de hardware estão descritos e ilustrados
em um diagrama, porém não foram detalhados de forma suficiente à reprodução de sua
criação. Os procedimentos executados pelo firmware criado são apresentados e ilustrados
em um diagrama, porém seu código fonte não foi divulgado. Quanto aos aspectos metodo-
lógicos, os autores procuraram justificar suas escolhas de hardware, porém não apresentam
levantamento de requisitos que delimitem quais eram os objetivos a serem atingidos em
cada camada do desenvolvimento.
Considerando a discussão acima e a abordagem indicada, neste capítulo são apresen-
tadas detalhadamente as soluções propostas por esses autores, agrupando a discussão em
seções para hardware, firmware e software. Em cada uma delas os trabalhos são minuciosa-
mente avaliados, destacando-se as suas principais características técnicas e funcionalidades,
visando identificar qual foi a abordagem técnica e metodológica adotada e quais aspectos
poderiam ser incorporados ou não na elaboração do protótipo proposto. Para completar a
discussão também são analisadas algumas soluções comerciais existentes, que então são
comparadas entre si, assim como ante a solução proposta neste trabalho de mestrado.
2.1 Hardware
Hardware é o conjunto de componentes (resistores, capacitores, microcontroladores)
que formam um equipamento (NIST-GLOSSARY, 2021). O projeto de um hardware
sempre envolve a elaboração de um diagrama elétrico e posteriormente de uma placa
de circuito impresso (PCB). As placas mães dos computadores são o principal exemplo
desta abordagem. No caso de um datalogger é a camada em que ficam os conectores de
entrada dos sensores e respectivas proteções contra surto e estabilização de ruídos, os

microprocessadores responsáveis pela aquisição e processamento da informação e demais
componentes necessários a operação, como chips para controle de relógio, manipulação de
memória, entre outros.
Na sequência são avaliadas as características técnicas e metodológicas adotadas
por cada um dos autores em relação à camada de hardware.
O trabalho de Abdalla (2015) teve por objetivo realizar medições de temperatura e
umidade relativa do ar do Parque Mãe Bonifácia na cidade de Cuiabá-MT. Para isso, o
autor desenvolveu um datalogger que designou de LaMALogger. Este datalogger contém
duas estruturas principais, compostas de interface de coleta e módulo de armazenamento.
A interface de coleta, ilustrada na Figura 56, possui um sensor de temperatura e umidade
DTH22, um módulo de GPS SKM53, e um Arduino Uno com Shield wi-fi. O módulo de
armazenamento utilizou um Raspberry PI 2 Model B, um Dongle wi-fi e um invólucro de
abrigo, conforme também ilustrado na Figura 56, contida no Anexo C deste trabalho. A
Tabela 1 detalha os sensores utilizados pelo autor.
Tabela 1 – Sensores utilizados no projeto de Abdalla (2015)
Sensor Modelo Intervalo Sinal Precisão Alimentação
Digital via +- 0,5ºC

Temperatura AM2302 -40ºC a 80ºC 3-5 VDC
single-bus (10-30ºC)
Umidade Digital via +- 2%RH
AM2302 0-100% 3-5 VDC
Relativa single-bus (0-90%RH)
Fonte: Adaptado de Abdalla (2015)
O datalogger, devido a opção pela plataforma Arduino Uno, apresenta limitações

quanto ao número de portas disponíveis, o que não impacta diretamente no projeto proposto
pelo autor, mas restringe uma possível aplicação e adição de outras medidas. Outro ponto a
ser observado foi o uso de comunicação wi-fi, o que se torna um limitante para operação em
áreas remotas. A escolha do wi-fi também acarreta um maior dimensionamento de bateria
e painel solar para carregamento do sistema, haja vista que os módulos wi-fi possuem
um alto consumo de energia. Também não foi apresentada possibilidade de expansão, de
modo a torná-lo abrangente a outros tipos de pesquisa e não foram desenvolvidos softwares
que permitissem realizar de forma gráfica a sua configuração ou visualização dos dados
aquisitados.
Outro ponto a ser ressaltado é a opção do autor pela utilização de um Arduino
apenas para coleta dos dados dos sensores e transmissão dos dados por wi-fi adicionando a
plataforma Raspberry para recepção dos dados enviados por uma ou mais interfaces de
coleta e pelo armazenamento dos dados em estrutura de banco de dados. O pesquisador
poderia ter optado por excluir o uso do Raspberry no projeto, fazendo com que as interfaces
de coleta registrassem o dado localmente e enviassem os dados diretamente para a internet,
2.1. Hardware 37
sem a necessidade de passar pelo concentrador. Para tanto, seria necessária a adição de uma
shield wi-fi ao Arduino, mas ainda assim o valor e o consumo de energia da solução seriam
menores. Utilizando esse arranjo, seria possível em caso de falha ou indisponibilidade de
envio, a criação de uma fila de envio em arquivo para que, ao ser restabelecida a conexão,
essa massa de dados pudesse ser sincronizada.
O trabalho de Galdino et al. (2019) visou o desenvolvimento de um datalogger de
baixo custo utilizando a plataforma Arduino, com a motivação de propiciar a coleta de
dados de precipitação em escala subhorária. Os autores criaram seu datalogger utilizando
um Arduino Uno, um módulo de relógio de tempo real RTC DS3231, um módulo para
leitura e escrita de cartão SD, uma placa com fenolite cobreado e alguns componentes
eletrônicos adicionais (LEDs, resistores e conectores) conforme ilustrado no Anexo C,
Figura 57. Os sensores utilizados pelos autores estão descritos na Tabela 2.
Tabela 2 – Sensores utilizados no projeto de Galdino et al. (2019)
Sensor Marca Modelo Intervalo Sinal Precisão Calibração
0-
Pluviômetro Campbell TB-04 Pulso +- 2% 0,254mm
200mm/h
Pluviômetro Rainwise - - Pulso -% 0,206mm
Pluviômetro Rainwise - - Pulso -% 0,206mm
Fonte: Adaptado de Galdino et al. (2019)
Os pesquisadores não detalharam o desenvolvimento do hardware, mas é possível

notar que foi feito o uso de apenas 1 porta digital para captura das interrupções provenientes
do pluviômetro. Devido a existência de mais portas digitais disponíveis no Arduino
Uno, o pesquisador poderia ter optado pela disponibilização do uso das demais portas,
possibilitando em uma futura pesquisa a utilização de mais de um pluviômetro, podendo
assim serem comparados em um mesmo ponto coletas de diferentes modelos de pluviômetro,
ou mesmo a adição de outros tipos de sensores.
O trabalho realizado por Karami, Mcmorrow e Wang (2018) teve por objetivo
desenvolver um datalogger baseado em Arduino, com comunicação por meio de módulos
ZigBee, para monitorar e analisar parâmetros de Qualidade Ambiental em Ambientes
Internos (IEQ). Os autores fizeram o uso de dois Arduino Uno, dois módulos XBee
transmissores, um módulo XBee coordenador e diversos sensores comerciais, apresentados
na Tabela 3. Os autores não descreveram qual foi o processo realizado para efetuar leitura
dos sensores que trabalham em faixas de 0-10V e 0-12V, haja vista que o Arduino Uno,
utilizado no projeto, tem por limitação a entrada de 5V em suas portas analógicas.
A arquitetura elaborada pelos autores para o datalogger está ilustrada na Figura 2.
Por meio dela, assim como das informações disponíveis na Tabela 3, percebe-se o emprego
de sensores de alta precisão, de marcas renomadas no mercado, tendo valores mais elevados.
Apesar do intuito dos autores ter sido a criação de uma solução de baixo custo, a escolha
dos sensores não foi condizente com essa proposta.
Tabela 3 – Sensores utilizados no projeto de Karami, Mcmorrow e Wang (2018)
Sensor Marca Modelo Intervalo Sinal Precisão Alimentação
+- 0.5ºC
Temperatura Vaisala HMP60 -40-60ºC 0-2.5 V 5-28 VDC
(10-30ºC)
Umidade
Vaisala HMP60 0-100% 0-2.5 V +- 3%RH 5-28 VDC
Relativa
Velocidade 0.05-2.54
TSI TSI 8475 0-5 V +- 3% 11-30 VDC
do Ar m/s
Temperatura
ONSET type K thermocouple 0-285ºC - 0.0075 -
Global
0 - 10.000 4.5-14
CO2 CO2Meter K-30 0-4 V +- 3%
ppm VDC
0 - 46.168 3.8-28
Iluminância Licor LI-210SA 0-5 V +- 5%
klux VDC
Sensor de 10-2000
Sensky PIR sensor 0-5 V - 12 VDC
Presença lux
0-0.5
PM 2.5 Sharp GP2Y1010AU0F 0-3.4 V - 5-7 VDC
mg/m3
350-2000
VOCs CO2 Meter IAQ-2000 0-5 V - 5 VDC
ppm
Fonte: Adaptado de Karami, Mcmorrow e Wang (2018)
Figura 2 – Arquitetura de hardware proposta
Fonte: Adaptado de Karami, Mcmorrow e Wang (2018)
Como principal diferencial, Karami, Mcmorrow e Wang (2018) utilizaram a tecnolo-

gia ZigBee para transmissão dos dados coletados por diversos dataloggers a um concentrador
ZigBee, que por sua vez envia os dados ao software de recepção, tornando possível a cober-
tura de áreas de tamanho variável, à medida que pode segmentar a escolha dos sensores de
2.1. Hardware 39
acordo com a necessidade e adicionar quantos dataloggers se fizerem necessários. Por outro
lado, a escolha de uma tecnologia sem-fio, como o XBee, pode aumentar a incidência de
erros e indisponibilidade nos dados, haja vista que diversos fatores podem influenciar no
alcance do sinal.
Na pesquisa de Netto e Arigony-Neto (2019) foi desenvolvido um datalogger de baixo
custo utilizando a plataforma Arduino, para criação de estação meteorológica automática.
Via de regra, dataloggers disponíveis para esse tipo de aplicação possuem um alto custo e
complexidade. Os autores utilizaram um Arduino Uno, um leitor de cartão micro SD e um
módulo de relógio RTC DS1307 para desenvolver o datalogger, e a Figura 58, contida no
Anexo C, ilustra o datalogger elaborado. A escolha do Arduino Uno limita a quantidade
de sensores que podem ser lidos devido à quantidade de portas e memória disponíveis.
Para validação do hardware criado, os autores utilizaram o datalogger para realiza-
ção da leitura de vários sensores ambientais, tais como sensores de temperatura, umidade,
pressão atmosférica, luminosidade, velocidade do vento e direção do vento. A Figura 3
apresenta o diagrama de ligação da estação montada pelos pesquisadores e a Tabela 4
detalha os sensores utilizados.
Figura 3 – Diagrama da estação meteorológica
Fonte: Adaptado de Netto e Arigony-Neto (2019)

Como diferenciais, o projeto mostra a capacidade de hardwares de baixo custo

resistirem a condições climáticas extremas e apresenta a comparação entre os dados obtidos
no estudo de caso pelo datalogger proposto em relação aos dados obtidos por uma estação
com datalogger e sensores profissionais da marca Campbell. O datalogger Campbell será
discutido na Seção 2.4, que apresenta alguns dos dataloggers comerciais existentes no
mercado.
Tabela 4 – Sensores utilizados no projeto de Netto e Arigony-Neto (2019)
Sensor Modelo Intervalo Sinal Precisão Calibração
Pluviômetro Weather Meter Kit - Pulso - 0,279mm

Velocidade
Weather Meter Kit - Pulso - 2,4km/h
de vento
Pluviômetro - - Pulso 5% 0,206mm
Temperatura Digital via +- 0,5ºC
AM2302 -40ºC a 80ºC -
do ar single-bus (10-30ºC)
Umidade
Digital via
Relativa AM2302 0-100% +- 2%RH -
single-bus
do ar
Temperatura Digital via
DS18B20 -40ºC a 80ºC +- 0,5ºC -
da água single-bus
Luminosidade LDR - Analógico - -
Acumulo
HC-SR04 - I2C +- 3mm -
de neve
Pressão At-
BMP280 300 - 1100hPa I2C e SPI +-0.12hPa -
mosférica
Fonte: Adaptado de Netto e Arigony-Neto (2019)
Não foi apresentada no trabalho a possibilidade de expansão da quantidade de

sensores a serem registrados, de modo a torná-lo abrangente a outros tipos de pesquisa
e não foram desenvolvidos softwares que permitissem realizar de forma gráfica a sua
configuração ou a visualização, por meio de uma interface, dos dados aquisitados.
No trabalho de Pereira (2013) foi desenvolvido um datalogger de baixo custo e baixo
consumo de energia, para aplicação em um levantamento de dados microclimáticos no
campus da UFMT. O datalogger é composto por uma placa desenvolvida pelo pesquisador,
que utiliza um Arduino Uno, um módulo RTC DS1307, uma shield para leitura do cartão
SD e um módulo para comunicação Bluetooth, conforme ilustrado na Figura 4. Os sensores
utilizados pelo autor estão detalhados na Tabela 5.
2.1. Hardware 41
Figura 4 – Diagrama do datalogger Zoiologger proposto por Pereira (2013)
Fonte: Adaptado de Pereira (2013)
Tabela 5 – Sensores utilizados no projeto de Pereira (2013)
Tipo de Tipo de
Modelo Intervalo Precisão Alimentação
Sensor Sinal

AM2302 0-100% 3-5 VDC
As placas de circuito impresso (PCBs) desenvolvidas para o módulo principal e

para a shield de leitura do cartão SD estão ilustradas na Figura 59 do Anexo C.
Nota-se, com a elaboração das PCBs, uma preocupação com a estabilidade e dura-
bilidade da solução proposta pelo autor. Muitos dos projetos acadêmicos, inclusive alguns
abordados anteriormente, realizam apenas as ligações diretamente, sem projetar/executar
uma placa de circuito impresso.
Não foi apresentada possibilidade de expansão da quantidade de sensores a serem
registrados, de modo a torná-lo abrangente a outros tipos de pesquisa e não foram
desenvolvidos softwares que permitissem realizar de forma gráfica a sua configuração ou a

visualização, por meio de uma interface, dos dados aquisitados.
A pesquisa de Reges (2017) visou o desenvolvimento de datalogger para aquisição
de dados de sistemas fotovoltaicos. Seu hardware foi composto por um Arduino Pro Mini,
um display, um sensor de corrente e tensão ACS712, um módulo RTC DS 1302 e um
módulo de cartão SD. O pesquisador produziu placas de circuito impresso, ilustradas pela
Figura 60 do Anexo C, para conexão dos componentes e interfaceamento com os sensores
utilizados.
É possível notar que houve uma preocupação do autor na disposição das conexões
e dos componentes, facilitando a sua utilização. A escolha dos bornes de ligação, do tipo
KRE, também evitam problemas ao realizar as conexões dos sensores e da alimentação. A
Tabela 6 detalha os sensores utilizados pelo autor.
Tabela 6 – Sensores utilizados no projeto de Reges (2017)
Corrente ACS712 0-5V Analógico +- 1,5% 5 VDC

Tensão Divisor de Tensão 0-5V Analógico - -
Temperatura LM35 -55ºC a 150ºC Analógico +- 0,5ºC 4-30 VDC
Fonte: Adaptado de Reges (2017)
O datalogger apresenta limitações quanto ao número de portas disponíveis para

a aquisição de dados, pois o hardware utilizado pelo pesquisador, Arduino Pro Mini,
limita-se a 6 portas, as quais não foram utilizadas em sua totalidade. Não foi apresentada
possibilidade de expansão da quantidade de sensores a serem registrados, de modo a
torná-lo abrangente a outros tipos de pesquisa.
No trabalho de López-Vargas et al. (2018) foi realizado o desenvolvimento de data-
logger de baixo custo utilizando um Arduino Uno, para aquisição de dados meteorológicos
e de grandeza elétrica em sistemas fotovoltaicos. O autor projetou seu datalogger de forma
com que os dados coletados cumprissem os parâmetros de precisão estabelecidos pela
Comissão Eletrotécnica Internacional (IEC).
O diagrama apresentado na Figura 5 detalha a arquitetura do datalogger criado,
que é composto por um Arduino Uno, um módulo RTC DS1307, dois conversores ADCs
MCP3424, um módulo de cartão SD, um visor e um módulo de monitoramento do consumo
elétrico do datalogger. Os sensores utilizados são detalhados na Tabela 7.
2.1. Hardware 43
Figura 5 – Diagrama do datalogger proposto pelos autores López-Vargas et al. (2018)
Fonte: Adaptado de López-Vargas et al. (2018)
Tabela 7 – Sensores utilizados no projeto de López-Vargas et al. (2018)

AM2302 0-100% 3-5 VDC
Velocidade
Thies 0.9 to 40 m/s Analogico +- 0,5 m/s -
de vento
Pulso
Quantidade
Rain-O-Matic Small Sensor 0-200mm/h (reed- +- 5% -
de chuva
switch)
O datalogger tem como principal diferencial a melhora na precisão dos dados

adquiridos por ele, que ao invés de utilizar o conversor analógico/digital do Arduino,
utilizou um componente externo da Microchip, modelo MCP3424, com 18-bits de resolução.
A Figura 61 do Anexo C exibe como ficou o protótipo proposto pelo autor após
ter sido montado em seu estudo de caso.
O autor não apresentou o diagrama das ligações realizadas na montagem exibida

na Figura 61, dificultando o entendimento de quais as capturas estão sendo realizadas e
como elas estão conectadas ao datalogger.
Não foi apresentada possibilidade de expansão da quantidade de sensores a serem
registrados, de modo a torná-lo abrangente a outros tipos de pesquisa.
Seguindo-se a organização proposta para este capítulo, a próxima seção apresenta
os aspectos que foram adotados por cada um dos trabalhos analisados em relação ao
desenvolvimento do firmware.
2.2 Firmware
Firmware é uma categoria de software que é programada diretamente na memória
de um dispositivo de hardware (NIST-GLOSSARY, 2021). Ele possui todas as informações
para a inicialização das rotinas de funcionamento de um equipamento. O código do
firmware possui todas as informações necessárias para que o equipamento funcione de
forma autônoma e exerça a função para a qual foi projetado. No caso dos dataloggers é o
firmware que irá conter todas as rotinas de operação e validação durante a aquisição dos
dados. Esse código é responsável, com base nas configurações pré-definidas, por avaliar
quais sensores serão lidos, em qual periodicidade, quais cálculos deverão ser realizados
para correta aquisição, se esse dado deve ser enviado a alguma porta de comunicação e
demais condicionais.
Na sequência é descrito como cada autor realizou sua criação da camada de firmware
e quais aspectos foram considerados ou desconsiderados no processo.
No trabalho realizado por Abdalla (2015) a funcionalidade do firmware é centrada
na realização da conexão e autenticação com o módulo de armazenamento por meio de
conexão sem fio; na coleta dos dados de temperatura e umidade; na coleta das coordenadas
de localização; no envio dos dados por meio de um método HTTP GET e no envio
das informações ao módulo de armazenamento. O pesquisador não projetou meio para
configuração das rotinas ou alteração em seu comportamento, limitando seu funcionamento
apenas à rotina descrita.
O firmware desenvolvido por Galdino et al. (2019) para a plataforma Arduino teve
como objetivo registrar em arquivo de texto a ocorrência de precipitação, com data, hora,
minuto e segundo do evento, bem como a quantidade de chuva coletada. E assim como
Abdalla (2015), os pesquisadores não projetaram um meio para configuração das rotinas
ou alteração em seu comportamento.
No trabalho de Karami, Mcmorrow e Wang (2018) não é descrito o processo de
criação do firmware, o mesmo ocorrendo em Reges (2017). Ambos os autores focaram mais
2.2. Firmware 45
na apresentação e avaliação dos dados coletados do que no detalhamento do funcionamento

dos equipamentos criados.
Em Netto e Arigony-Neto (2019) é relatado o desenvolvimento de um firmware para
a plataforma Arduino, que foi o responsável pelo controle do recebimento e do registro
dos dados dos sensores em arquivo de texto em cartão SD que acompanha a estação. Os
autores adicionaram o código completo criado para rotina interna como um anexo de seu
trabalho. O código apresenta os cálculos envolvidos na interpretação dos dados coletados
dos sensores de umidade, velocidade e direção do vento. A divisão dos processos e a ordem
com que as leituras foram realizadas foi de grande valia a título de comparação para a
elaboração do firmware do protótipo proposto.
No trabalho de Pereira (2013) é descrito o funcionamento da rotina interna do
firmware por meio de um diagrama de atividade ilustrado pela Figura 6. O firmware
elaborado pelo autor controla a realização da leitura de um arquivo de configuração para
definir alguns aspectos de seu comportamento, como sons de alerta, taxa de amostragem
em segundos e também quais sensores e portas serão lidos.
O diagrama de atividade ilustrado na Figura 6 mostra que as rotinas estão bem
determinadas e que seu comportamento, como a realização dos testes iniciais e leitura
do arquivo de configurações para balizar o funcionamento, se assemelha a dataloggers
comerciais, tais como NESA SRL (2020) e Stevens Water (2013).
Em López-Vargas et al. (2018) é descrita a criação do firmware, considerando
rotinas para que as configurações pudessem ser realizadas presencialmente por meio de
botões físicos e informações exibidas no display do datalogger. Na Figura 7 os autores
apresentaram o diagrama das rotinas executadas pelas interações previstas pelo firmware.
O diagrama apresenta que o modo de configuração escolhido pelos autores, por
meio de botões, acaba por limitar suas funcionalidades apenas ao sensores previamente
escolhidos para a realização da sua pesquisa. Outra limitação é quanto a interação com o
usuário, haja vista que as mensagens de erro acabam por trazer poucas informações no
visor LCD existente.
Figura 6 – Diagrama de atividade do firmware do Zoiologger

2.2. Firmware 47
Figura 7 – Diagrama das rotinas executadas por cada interação
A próxima seção apresenta a avaliação dos aspectos de projeto e desenvolvimento

adotados pelos autores analisados em relação à camada de software.
2.3 Software
Uma característica importante em um datalogger é possibilitar que funcionalidades
possam ser configuradas e adaptadas às necessidades do usuário. Dataloggers comerciais
comumente dispõe de uma interface gráfica que possibilita sincronização de horário, fuso
horário, configuração dos sensores existentes, periodicidade de registro, periodicidade de
envio, leitura momentânea dos valores adquiridos pelos sensores, entre outros. As marcas
mais conceituadas preocupam-se pouco com a interface e com a usabilidade, sendo muitas
vezes necessário, inclusive, realizar a compra de horas de suporte para que seja possível
compreender como realizar o processo desejado.
Na sequência está descrito se e como cada autor implementou sua camada de
software.
No trabalho realizado por Abdalla (2015), os softwares foram elaborados para o
módulo de armazenamento, sendo utilizado um Raspberry Pi para recepção e concentração
dos dados capturados pela interface de coleta. No Raspberry Pi foram instalados um
Servidor Apache, o Banco de Dados MySQL e o PHP. A informação é recebida por uma
página WEB hospedada no servidor Apache, escrita em PHP, que trata os dados e os insere
no banco de dados criado, conforme exemplificado pelo diagrama da Figura 8. O processo
de instalação e configuração dos recursos envolvidos foi adicionado pelo pesquisador como
um anexo em seu trabalho.
Figura 8 – Diagrama de funcionamento do LaMALogger
Fonte: Adaptado de Abdalla (2015)
O autor não desenvolveu softwares que permitissem realizar de forma gráfica a sua
configuração ou a visualização de modo gráfico dos dados aquisitados.
2.4. Dataloggers Comerciais 49
No trabalho de Galdino et al. (2019), não foi realizado o desenvolvimento de um

software para configuração dos dados coletados, que eram manualmente recuperados do
datalogger por meio da extração do cartão SD e da abertura do arquivo de texto gerado
internamente. Igualmente, os autores Netto e Arigony-Neto (2019), Reges (2017) e (LóPEZ-
VARGAS et al., 2018) não realizaram o desenvolvimento de software para configuração do
datalogger ou para exibição dos dados coletados, fazendo-se também necessária a remoção
do cartão SD para ter acesso aos dados coletados.
Já no trabalho de Karami, Mcmorrow e Wang (2018) a opção foi por não desenvolver
um software próprio, fazendo-se o emprego de uma plataforma open-source chamada
VOLTTRON (2021), que viabiliza a coleta e o controle de dados em sistemas distribuídos.
Analogamente, o autor Pereira (2013) optou por não criar um software para a configuração
do datalogger ou para a exibição dos dados coletados. Para monitoramento dos dados
coletados Pereira (2013) utilizou o software BlueTerm (2021). A ilustração da Figura 9
exibe o recebimento dos dados no software. Nota-se na imagem que foi possível estabelecer
a conexão e receber os dados corretamente.
Figura 9 – Tela do software BlueTerm
Respeitando-se a organização proposta neste capítulo, a próxima seção apresenta

os dataloggers comerciais NESA Evolution, Campbell CR1000 e Stevens DLight Logger.
2.4 Dataloggers Comerciais

Para efeito de comparação com os projetos acadêmicos discutidos detalhadamente
nas seções anteriores, foram também pesquisados dataloggers que são amplamente utilizados
em soluções comerciais de monitoramento ambiental. São descritas suas características

gerais, de hardware, firmware e software.
O fabricante NESA SRL (2020) descreve o produto como sendo um datalogger
modular de alta acurácia, com sistema operacional Linux, servidor Web Apache e interpre-
tador PHP. É completamente configurável via browser e pode ser personalizado com scripts
criados pelo próprio usuário. É projetado para ser utilizado em áreas como meteorologia,
hidrologia, agrometeorologia, geotecnia, monitoramento de florestas, monitoramento de
estradas, monitoramento de encostas, indústria, usinas eólicas e solares. O equipamento
está ilustrado na Figura 10.
Figura 10 – Datalogger NESA Evolution
Fonte: NESA SRL (2020)
Na Tabela 8, na Tabela 9 e na Tabela 10 são apresentadas as características de

cada uma das camadas de desenvolvimento do equipamento, sendo elas hardware, firmware
e software respectivamente.
Tabela 8 – Principais características de Hardware do equipamento NESA - Evolution.
Característica Descrição
Processador ARM Cortex A8 – 500MHz 32bit

Memória externa Pendrive de 8GB a 64GB
Portas de comunicação 2 RS232, 1 RS485, 3 USBs, 1 RJ45 (Ethernet), SDI-12, I2C e WiFi
Relógio Precisão de +-3 minutos por ano. Possibilidade de sincronização
por NTP ou por GPS
Alimentação 24V, 110V ou 220V por fonte externa;
10,5V a 24V por painel solar;
10,8V a 15V por bateria
Portas analógicas 8 a 32 portas
Resolução conversor AD 24 bits
Portas digitais 5 portas (máximo de 5000Hz)
Fonte: Adaptado de NESA SRL (2020)
Tabela 9 – Principais características de Firmware do equipamento NESA - Evolution.
Características de Firmware
Rotinas internas controladas pelo sistema operacional Linux embarcado
Suporta os protocolos Modbus RTU & Tcp, TCP-IP, HTTP, FTP, SFTP, NTP, Telnet,
SMTP, Socket, I2CBus, SDI-12, RS232/485, SNMP e SSH
Algoritmos embarcados: cálculo de ponto de orvalho, pressão de vapor, intensidade de

chuva, precipitação horária/diária, evapotranspiração, duração da luz do sol e índice de
resfriamento.
Tabela 10 – Principais características de Software do equipamento NESA - Evolution.
Características de Software
Configurações realizadas via browser por meio de interface WEB, sem necessidade da
instalação de nenhum software
Criação de múltiplos usuários, cada um com sua rotina de coleta e envio de dados
Exibição de gráficos em tempo real das coletas realizadas
Possibilidade de exportação dos dados em diversos formatos
Na Figura 11 são apresentadas a título de ilustração as telas de configuração dos

sensores e de visualização dos gráficos com atualização dos dados em tempo real. É notável
a preocupação da empresa com a usabilidade do software, apostando na estilização das
telas de modo a tornar o uso o mais intuitivo possível.
Figura 11 – Telas do software de configuração e exibição do equipamento Evolution

(a) Configuração dos sensores. (b) Visualização dos dados coletados em gráficos.

O fabricante Campbell Scientific (2013) descreve o produto como o datalogger

comercial mais utilizado no mundo, sendo empregado na realização de uma vasta varie-
dade de medições e controle. Segundo o material elaborado pela fabricante o produto é
robusto para funcionamento em condições extremas e confiável para funcionamento em
áreas remotas. Foi projetado para ser utilizado em áreas como meteorologia, hidrologia,
agricultura, monitoramento de solo, previsão de avalanches, teste de veículos, qualidade
de água, entre outros. O equipamento está ilustrado na Figura 12.
Figura 12 – Datalogger CAMPBELL CR1000
Fonte: Adaptado de Campbell Scientific (2013)

cada uma das camadas de desenvolvimento do datalogger, como no caso do NESA SRL
(2020).
Tabela 11 – Principais características de Hardware do equipamento Campbell - CR1000.
Processador Renesas H8S 2322 (16-bit CPU com 32-bit de core interno);
Memória externa Módulos adicionais podem ser comprados
Portas de comunicação 4 RS232, 4 SDI-12, 1 I/O port exclusiva para equipamentos
da Campbell e uma porta periférica para conexão de módulo
CompactFlash ou Ethernet
Alimentação 9,6 Vdc a 16 Vdc
Portas analógicas 8 diferenciais ou 16 single-ended
Resolução do conversor AD 24 bits
Portas digitais 8 portas
Tabela 12 – Principais características de Firmware do equipamento Campbell - CR1000.
Rotinas internas controladas pelo firmware proprietário

Tabela 13 – Principais características de Software do equipamento Campbell - CR1000.
Configurações realizadas por meio do software proprietário PC200W (disponível apenas

para Windows)
Possibilita o envio de aplicações e a busca de dados de ou para um CR1000

Na Figura 13 é apresentada a título de ilustração a tela do software proprietário

PC200W, utilizado para envio das aplicações ao equipamento.
Figura 13 – Tela do software PC200W
Já o fabricante Stevens Water (2013) descreve o produto como um datalogger

estável, flexível e versátil, idealizado para aplicações que não exijam muitas portas de
entrada. Ele está ilustrando na Figura 14.
Figura 14 – Datalogger STEVENS DLight Logger
Fonte: Adaptado de Stevens Water (2013)


cada uma das camadas de desenvolvimento do datalogger, como nos casos anteriores.
Tabela 14 – Principais características de Hardware do equipamento Stevens - DLight

Logger.
Processador 16-bit TI MSP430

Memória externa cartão SD 2GB
Portas de comunicação 1 RS232, 1 USB
Alimentação 9,6 Vdc a 16 Vdc
Portas analógicas 4 single-ended
Resolução do conversor AD 12 bits
Portas digitais 1 porta
Tabela 15 – Principais características de Firmware do equipamento Stevens - DLight

Logger.
Rotinas internas controladas pelo firmware proprietário

Tabela 16 – Principais características de Software do equipamento Stevens - DLight Logger.
Configurações realizadas por meio do software proprietário LoggerSet (disponível apenas

para Windows)
Possibilita a escolha de periodicidade de gravação e envio dos dados coletados

Na Figura 15 é apresentada a título de ilustração a tela do software proprietário

Logger Set, utilizado para configurar as características operacionais do equipamento. A
interface é simples e intuitiva, não havendo muita complexidade em seu funcionamento.
2.5. Comparativos 55
Figura 15 – Tela do software LoggerSet
Para encerrar este capítulo, na seção seguinte são apresentados comparativos entre
os equipamentos caracterizados anteriormente, tanto acadêmicos quanto comerciais.
2.5 Comparativos
Nesta seção são apresentados dois quadros comparativos, o primeiro entre os
projetos acadêmicos e o segundo entre os dataloggers comerciais supracitados.
O comparativo exposto no Quadro 1 mostra de forma clara que os equipamentos
desenvolvidos nas pesquisas analisadas não buscaram avaliar ou se aproximar das caracte-
rísticas de equipamentos comerciais. Não houve preocupação dos pesquisadores em relação
à precisão do relógio, com saída de comunicação para interação com outros equipamentos
ou com desenvolvimento de softwares para facilitar a configuração do equipamento criado.
O comparativo apresentado no Quadro 2 mostra algumas características comuns
entre as soluções comerciais, como é o caso de uma alta precisão do relógio, saída de
comunicação em protocolo serial padrão RS232, um grande número de portas analógicas e
digitais para leitura de sensores e a existência de softwares para configuração do equipa-
mento. Destaca-se também a possibilidade de ser programável, ou seja, a inclusão funções
ou cálculos e a alteração nos formatos da mensagem de saída.
Quadro 1 – Comparativo entre projetos acadêmicos pesquisados
56
HARDWARE SOFTWARE
Exibição
Portas Precisão Saída de Precisão do Software de
Portas Digitais dos dados
Analógicas (em bits) Comunicação Relógio Configuração
coletados
ABDALLA 2 10 0 Ethernet e Wifi +- 3min/ano Não Não
GALDINO 1 10 1 Inexistente +- 30min/ano Não Não
KARAMI 6 (por nó) 10 1 Wifi Inexistente Não Não
NETTO 6 10 1 Inexistente +- 30min/ano Sim Não
PEREIRA 6 10 1 Bluetooth +- 30min/ano Sim Não
REGES 6 10 1 Inexistente +- 3min/ano Não Não
LOPEZ-
24 18 0 Inexistente +- 3min/ano Não Não
VARGAS
Fonte: Autor
Quadro 2 – Comparativo entre dataloggers comerciais

Memória Precisão do Portas Resolução Portas Software de
Comunicações Alimentação Programável
Externa Relógio Analógicas A/D Digitais Configuração
RS232, RS485, 24V, 110V ou
USB, RJ45, 220V / 10,5V a
Evolution 8GB a 64GB +- 3 min/ano 8 a 32 24 bits 5 Sim - WEB Sim
SDI-12, I2C, 24V / 10,8V a
WiFi 15V
RS232, SDI-12,
8 diferenciais Sim - Software
Módulos a I/O exclusiva,
CR1000 +- 3 min/ano 9,6Vdc a 16Vdc ou 16 single 24 bits 8 Windows ou Sim
Capítulo 2. Revisão Bibliográfica

parte porta de
ended Linux
periféricos
Sim - Software
DLight 2GB RS232, USB +- 1 min/ano 9,6Vdc a 16Vdc 4 single ended 12 bits 1 Não
Windows
Fonte: Autor.
57
3 Materiais e Métodos
O protótipo proposto foi idealizado para abarcar dois tipos diferentes de cenário,
uso em campo ou uso em laboratório.
O ambiente de campo exige o uso de equipamentos com menor consumo energético,
pois a maior parte dos locais onde se faz necessária a coleta deste tipo de dados, em
geral, não possuem rede elétrica, como por exemplo encostas de rio, montanhas, fazendas,
etc. Esta característica torna necessário o uso de energia proveniente de um conjunto de
baterias e/ou painéis solares. Com o objetivo de atender aos requisitos desse cenário, o
protótipo deve fazer uso apenas do Arduino Mega (ARDUINO, 2021b) para realização do
processo de coleta dos dados.
Já para uso em ambiente de laboratório, foi prevista e realizada a adição/conexão
de um módulo Raspberry PI para que os dados possam ser visualizados em tempo real
à medida em que são coletados, seja em um monitor, seja por meio da rede interna
(acessando-se ao endereço do equipamento). Essa configuração do equipamento possui
maior consumo de energia e deve ser alimentada diretamente na rede elétrica do local.
A Figura 16 ilustra a arquitetura geral do protótipo. Seu objetivo é apresentar um
modelo completo do sistema com seus diferentes componentes, suas interfaces e conexões,
envolvendo ambas as diferentes operações, em campo ou em laboratório.
58 Capítulo 3. Materiais e Métodos
Figura 16 – Visão geral da arquitetura do protótipo
Fonte: Autor
Na sequência é detalhada a metodologia adotada para projetar o protótipo do

datalogger proposto, seguindo a mesma disposição utilizada nos capítulos precedentes,
que é a segmentação por camadas de hardware, firmware e software. Em cada uma delas
foram aplicados conceitos e princípios do manifesto ágil, tais como planejamento, entregas
frequentes, projeto simples e testes. O relatório de reuniões realizadas, que foram parte
fundamental na adoção dos princípios, segue como apêndice deste trabalho.
Com feedback constante, é possível adaptar rapidamente eventuais mudanças nos
requisitos. Estas alterações nos requisitos são muitas vezes críticas nas metodologias
tradicionais, que não apresentam meios para que tais mudanças sejam feitas rapidamente.
Os stakeholders que contribuíram com a coleta, análise e validação dos requisitos
do sistema foram o Prof. Dr. Deonir Secco, o Prof. Dr. Rogério Luis Rizzi, o doutorando
Pablo Chang e o engenheiro de produção Leonardo Contini. O Prof. Dr. Deonir Secco,
do Programa de Pós Graduação em Engenharia de Energia na Agricultura, PPGEA-
UNIOESTE, atuou como idealizador e patrocinador do projeto do simulador de regimes
de chuva. O Pablo Chang, doutorando do Programa de Pós Graduação em Engenharia
de Energia na Agricultura, PPGEA-UNIOESTE, atuou como idealizador e principal
envolvido no levantamento de requisitos para o projeto do simulador de regimes de
chuva. O Prof. Dr. Rogerio Luis Rizzi, do Programa de Pós Graduação em Ciência da
Computação, PPGCOMP-UNIOESTE, atuou como orientador desse projeto, participando
3.1. Hardware 59
ativamente no levantamento de requisitos no que tange a dados científicos. Prof. Dra.

Claudia Brandelero Rizzi, do Programa de Pós-Graduação em Ciência da Computação,
PPGCOMP-UNIOESTE, atuou como coorientadora desse projeto, participando ativamente
na elaboração do documento de requisitos e demais aspectos relativos à Engenharia de
Software. O Leonardo Contini, técnico em mecatrônica, formado em Engenharia de
Produção pela PUC-PR e aluno de Tecnologia em Sistemas para Internet – UTFPR,
atuou como revisor do circuito impresso criado neste projeto e como principal envolvido
no levantamento de requisitos para o projeto de coleta de dados meteorológicos.
A apresentação de cada uma das camadas contém subseções de requisitos e de
projeto. A subseção de requisitos apresenta um recorte dos resultados obtidos no documento
de requisitos (Apêndice A), que foi elaborado para nortear o projeto da construção do
datalogger, mediante a compreensão e identificação das características que o equipamento
deveria possuir para atender as necessidades dos principais interessados. Já a subseção
de projeto apresenta os diagramas pertencentes à respectiva camada, como o esquema
elétrico para a camada de hardware, o diagrama de atividades para a camada de firmware
e o diagrama de caso de uso para a camada de software. A camada de hardware possui
ainda uma seção adicional, que é a camada de componentes e módulos utilizados, em que
são detalhadas e justificadas as decisões tomadas na construção do hardware. O processo
de elaboração da camada de hardware está descrito na seção a seguir.
3.1 Hardware
A camada de hardware do protótipo foi elaborada para proporcionar a conexão
entre os diversos componentes e módulos que foram utilizados. A Figura 17 mostra uma
visão geral da arquitetura proposta, que contempla os ambientes de campo e de laboratório.
No ambiente de campo, destaca-se o uso do Arduino, do firmware desenvolvido e do arquivo
gerado com os dados coletados. O ambiente de laboratório, além de contemplar todas as
funcionalidades e componentes existentes para o ambiente de campo, possui também um
Raspberry Pi, um software para exibição dos dados de forma gráfica e um banco de dados
para armazenamento dos dados.
Na sequência são apresentados os requisitos que foram identificados durante a fase
de elicitação, posteriomente analisados e avaliados, e que balizaram o desenvolvimento do
hardware.
3.1.1 Requisitos
A Tabela 17 apresenta um recorte com os principais requisitos identificados para a
camada de hardware. Os demais requisitos elicitados, bem como seu detalhamento estão
disponíveis no Apêndice A.
Figura 17 – Visão da camada física da arquitetura do protótipo
Fonte: Autor
Tabela 17 – Requisitos da camada de hardware
Priori- Depen-
Requisito Descrição Tipo dade dência
RFH-01: O equipamento deve possuir um hardware com conectores Funcional Alta Inexistente
Hardware de ligação para acoplamento de um Arduino Mega 2560,
principal um Raspberry Pi 3B+, um módulo de relógio, um módulo
conversor TTL-RS485 e demais componentes necessários
ao seu funcionamento.
RFH-02: O equipamento deve possuir um módulo relógio de tempo Funcional Alta RFH-01
Sistema de real (RTC - Real Time Clock) para controle de data e hora.
obtenção de Esse relógio servirá de base tanto para o intervalo e período
data e hora de coleta, quanto para marcação no arquivo de registro dos
dados.
3.1. Hardware 61
RFH-03: O equipamento deve possuir em seu hardware principal os Funcional Alta RFH-01
Sistema de componentes necessários para que seja possível realizar o
Armazena- armazenamento de dados em um dispositivo de memória
mento de não volátil (pen drive ou cartão SD), de forma que possam
dados ser recuperados a qualquer momento pelo usuário.
RFH-04: Por- O equipamento deve possuir a capacidade de capturar Funcional Alta RFH-01
tas analógicas leituras de até 16 sensores analógicos com sinais de 4-
de leitura 20mA ou 0-5V. As leituras podem ser capturadas de forma
individual ou sequencial.
RFH-05: Por- O equipamento deve possuir a capacidade de capturar leitu- Funcional Alta RFH-01
tas digitais ras de até 2 sensores de efeito hall, realizando a contagem
para conta- dos pulsos. As leituras podem ser capturadas de forma
gem de pulso individual ou sequencial.
RFH-09: O equipamento deve possuir saídas de comunicação em Funcional Média RFH-01
Saídas de padrão RS232 e RS485, para intercomunicação com outros
comunicação equipamentos.
RS232 ou
RS485
RFH-11: O equipamento deve possuir a capacidade de suportar a Funcional Baixa RFH-01
Microcompu- adição de um microcomputador Raspberry PI 3 B+, para
tador para prover ambiente Web para receber e exibir informações em
exibição dos tempo real.
dados
RNFH-01: O equipamento deve apresentar conectores/bornes devida- Não Alta Inexistente
Facilidade de mente identificados e posicionados de forma a facilitar as Funcio-
uso ligações, sejam elas de alimentação, sensores ou saída de nal
dados.
RNFH-03: O equipamento deve possuir módulo de relógio (RTC) de Não Alta Inexistente
Precisão de alta precisão, com variação de no máximo +- 3 minutos Funcio-
data por ano. nal
RNFH-05: O equipamento deve ser capaz de identificar as configu- Não Alta Inexistente
Desempenho rações pré-definidas e realizar sua inicialização de forma Funcio-
automática, sem qualquer tipo de intervenção. Após a inici- nal
alização, deve realizar todas as leituras necessárias e então
entrar em estado de stand-by até o próximo intervalo espe-
rado.
RNFH-07: O equipamento deve ser de baixo custo, não excedendo os Não Alta Inexistente
Custo R$ 1.100,00. Funcio-
nal
RNFH-08: O equipamento, quando em ambiente de campo, deve pos- Não Média Inexistente
Consumo de suir baixo consumo de energia, sendo de no máximo de Funcio-
energia 75mA/h. nal
Fonte: Autor
Para dar sequência à apresentação do processo de elaboração do hardware, na

próxima seção são apresentados os componentes e módulos selecionados para o desenvolvi-
mento do datalogger.
3.1.2 Componentes e módulos utilizados

Nessa seção são apresentados os módulos utilizados e as justificativas técnicas que
motivaram a decisão pelas suas escolhas.
3.1.2.1 Arduino
Arduino é uma plataforma eletrônica de código aberto baseada em hardware e

software fáceis de usar (ARDUINO, 2021a). A plataforma conta com vários modelos
disponíveis, dentre eles o Mega 2560, que possui 16 entradas analógicas com 10 bits de
precisão, 54 digitais, memória flash de 256KB e clock de 16MHz.
O modelo Arduino Mega 2560 foi escolhido para integrar a solução por apresentar
as características necessárias ao atendimento dos requisitos levantados, a exemplo do
requisito funcional de hardware RFH-04 que prevê a possibilidade da leitura de até 16
sensores. Outro fator que influenciou a escolha do módulo foi a quantidade de memória
disponível, que se faz necessária para execução das rotinas internas que precisam ser
realizadas.
3.1.2.2 Módulos RS485 e RS232
O Arduino trabalha em suas portas de seriais nativas com o padrão TTL, que é
a sigla para Transistor–Transistor Logic (Lógica transistor-transistor), que consiste em
uma classe de circuitos digitais construídos a partir de transistores bipolares de junção
e resistores (SPARKFUN, 2021). Conforme previsto no requisito RFH-07 e RFH-08,
o equipamento deve ser capaz de se comunicar com sensores ou outros equipamentos
utilizando os padrões RS232 e RS485. O padrão TTL trabalha em uma tensão diferente
dos padrões RS232 e RS485, sendo necessária a adição de Circuitos Integrados (CIs)
ou módulos para possibilitar a comunicação com dispositivos que usem esses protocolos.
Para tanto, foi utilizado um módulo que contém o chip MAX485CSA para conversão
3.1. Hardware 63
bi-direcional TTL-RS485/RS485-TTL e circuito integrado MAX232 para conversão bi-

direcional TTL-R232/RS232-TTL.
A escolha de tais módulos se deu pelo baixo custo, estabilidade de funcionamento
e disponibilidade de mercado, sendo facilmente encontrados em lojas de componentes
eletrônicos físicas ou virtuais.
3.1.2.3 Módulo de relógio (RTC)
Um relógio de tempo real (Real Time Clock - RTC) é um circuito integrado (CI)
que mede a passagem do tempo. Existem vários fabricantes e modelos disponíveis, que
apresentam características distintas de estrutura, consumo de energia e precisão. Para
a escolha do módulo RTC utilizado no protótipo, foram avaliados os datasheets dos
módulos mais comumente encontrados no mercado, que são o DS1307, DS3231, PCF8563
e o MCP79400. Além das características descritas pelos fabricantes em seus datasheets,
considerou-se um comparativo realizado pelo site SwitchDoc (2014) que avalia os módulos
citados anteriormente. Dadas características técnicas de consumo e precisão, como também
o resultado apurado no comparativo supracitado, o módulo DS3231 foi o escolhido para
utilização no protótipo.
3.1.2.4 Raspberry Pi
Raspberry Pi é um computador de baixo custo do tamanho de um cartão de crédito.

Possui a capacidade de executar distribuições Linux embarcadas, o que facilita a utilização
de diversos softwares e sua aplicação nos mais diversos tipos de solução. A versão adotada
para esse projeto foi o Rapsberry Pi 3 B+, que possui como principais características
técnicas um processador ARM Cortex-A53 de 1.4GHz, 1GB de memória RAM, placa de
rede, wifi, 4 portas USB, saída HDMI e 40 pinos GPIO (General Purpose Input Output)
que permitem interagir ou coordenar uma série de componentes eletrônicos (RASPBERRY,
2021).
No protótipo proposto, o Raspberry Pi foi utilizado para fornecer a estrutura
necessária para a execução de um ambiente de exibição dos dados coletados de forma
independente, sem a necessidade da utilização de um computador ou servidor externos ao
datalogger. Para criação de tal ambiente foi necessária a instalação do Raspberry PI OS,
distribuição linux específica para plataforma Raspberry, de um servidor web Apache, do
Java, do banco de dados MySQL/MariaDB e do PHP. O processo detalhado de instalação
e configuração do ambiente está descrito no Apêndice B.
Na sequência, são apresentados os diagramas e esquemas elaborados na fase de
projeto do protótipo.
3.1.3 Projeto
Considerando as características que deveriam ser atendidas e também as escolhas
previamente apresentadas, foi elaborado o projeto do circuito com suas respectivas conexões
e módulos, originando o diagrama do circuito, que para ser devidamente representado, foi
dividido na Figura 18 e Figura 19. Na Figura 20 mostra-se o layout da placa de circuito
impresso, que foi construído a partir do diagrama. Tanto o diagrama do circuito quanto o
layout da PCB foram elaborados utilizando a ferramenta AutoDesk (2021).
Finalizado o projeto da camada de hardware, iniciaram-se os processos que envolvem
a criação do firmware, os quais são apresentados na próxima seção.
Figura 18 – Diagrama do circuito parte 1
Fonte: Autor
3.2 Firmware
Como já mencionado, firmware, por definição, é um software ou conjunto de
instruções programado na ROM (ready-only memory) de um dispositivo de hardware
(NIST-GLOSSARY, 2021). Ele fornece as instruções necessárias para a inicialização das
rotinas de funcionamento de um equipamento.
Em relação ao protótipo proposto, é nessa camada que estão inseridas as rotinas
de operação e validação durante a aquisição dos dados. O firmware criado decide, com
base nas configurações pré-definidas, quais sensores irá ler, como irá realizar essa leitura,
quais cálculos deverão ser realizados para correta aquisição, além de decidir se esse dado
3.2. Firmware 65
Fonte: Autor
Figura 20 – Layout da placa de circuito impresso
Fonte: Autor
deve ser registrado, em qual periodicidade, se será enviado a alguma porta, dentre outras
operações.
A Figura 21 mostra uma perspectiva lógica da camada de firmware, que contempla as
principais funcionalidades e validações projetadas, tais como a inicialização da comunicação

serial, armazenamento dos dados coletados, leitura do arquivo de configurações, inicialização
e sincronismo do relógio de tempo real (RTC) e ativação do watchdog, que é um mecanismo
interno que atua para reiniciar o equipamento em caso de travamento.
Figura 21 – Visão da camada lógica (firmware) da arquitetura do protótipo
Fonte: Autor
Assim como no processo de elaboração do hardware, a elaboração do firmware

iniciou-se pelo levantamento de requisitos, que estão descritos na subseção a seguir.
3.2.1 Requisitos
Seguindo a metodologia proposta, a Tabela 18 apresenta um recorte com os princi-
pais requisitos identificados para a camada de firmware. Os demais requisitos existentes
bem como seu detalhamento estão disponíveis no Apêndice A.
Tabela 18 – Requisitos da camada de firmware
Priori- Depen-
RFF-01: Co- O firmware deve ser capaz de iniciar as portas de comuni- Funcional Alta Inexistente
municação Se- cação serial existentes no hardware.
rial
RFF-02: Reló- O firmware deve ser capaz de iniciar o módulo RTC exis- Funcional Alta RFF-01
gio de tempo tente no hardware, buscando data e hora atual com base
real (RTC) na sua última sincronização. Caso algum problema ocorra
nesse processo, uma mensagem de erro deve ser lançada na
interface serial RS232 e o processo deve ser interrompido.
3.2. Firmware 67
RFF-03: Car- O firmware deve ser capaz de iniciar o cartão de memória. Funcional Alta RFF-01
tão de memó- Caso algum problema ocorra nesse processo, uma mensa-
ria gem de erro deve ser lançada na interface serial RS232 e o
processo deve ser interrompido.
RFF-04: Ar- O firmware deve ser capaz de localizar o arquivo de confi- Funcional Alta RFF-01
quivo de con- guração e extrair todos os parâmetros necessários ao seu
figuração funcionamento. Caso algum problema ocorra nesse pro-
cesso, uma mensagem de erro deve ser lançada na interface
serial RS232 e o processo deve ser interrompido.
RFF-07: Co- O firmware deve ser capaz de coletar as informações dos Funcional Alta RFF-03
leta diversos sensores configurados, tanto analógicos quanto di- e RFF-
gitais, em seu intervalo previamente determinado e acionar 04
o processo de armazenamento. Durante o processo de coleta,
serão realizados também os cálculos necessários, conforme
configuração, para tornar o dado coletado interpretável ao
usuário final.
RFF-08: O firmware deve ser capaz de armazenar as informações Funcional Alta RFF-02,
Armazena- coletadas em arquivos no cartão de memória. RFF-03
mento e RFF-
04
RFF-09: En- O firmware deve ser capaz de enviar os dados coletados, se Funcional Média RFF-01,
vio dos da- assim configurado, para as portas de comunicação RS232 RFF-02,
dos em tempo e/ou RS485. O dado será enviado conforme padrão de RFF-03
real armazenamento, sendo: data e hora da coleta, identificação e RFF-
do sensor, valor bruto, valor interpretável pelo usuário. 04.
Essa funcionalidade permite a visualização em tempo real
dos dados coletados, evitando assim a retirada frequente do
cartão SD e facilitando o acesso às informações pelo usuário,
seja por interface gráfica ou por visualização textual em
um software de Terminal RS232.
RNFF-02: Ta- O firmware deve possuir tamanho máximo de 253.932 bytes, Não Alta Inexistente
manho limite da plataforma do Arduino Mega 2560, considerando Funcio-
todas suas linhas de código e bibliotecas necessárias ao seu nal
funcionamento.
RNFF-03: O processo de armazenamento deverá registrar dois ar- Não Alta RFF-08
Tipos de quivos com dados em formatos distintos, o primeiro em Funcio-
arquivo formato “.RAW” e o segundo em formato “.CSV”. O pri- nal
meiro, registrará a data e hora, a identificação do sensor e
seus respectivos valores, tanto brutos (leitura sem aplicação
de cálculo), quanto em formato interpretável ao usuário
(após aplicação dos cálculos previamente configurados).
Deve ser criado um arquivo por dia e seu nome deve ser
composto pela data em formato “ddmmaaaa”. Esse arquivo
deverá estar dentro de uma pasta com a identificação do
equipamento. O segundo arquivo, registrará a data, a hora
e os valores dos sensores (após a aplicação dos cálculos
previamente configurados). Deve ser criado um arquivo por
dia e seu nome deve ser composto pela data em formato
“ddmmaaaa”. Esse arquivo deverá estar dentro de uma
pasta com a identificação do equipamento e deve conter
um cabeçalho identificando a ordem dos dados coletados.
No firmware padrão, os dados provenientes da porta RS485
serão gravados em um arquivo adicional, com extensão
“.RS485”, dentro de uma pasta gerada com o nome do da-
talogger.
Fonte: Autor
Uma vez realizado o levantamento de quais os requisitos necessários para atendi-

mento das demandas previstas, foi elaborado o projeto do firmware, que é apresentado na
subseção a seguir.
3.2.2 Projeto
O projeto constitui-se da elaboração de um diagrama de atividades a fim de elencar
as funções internas, organizar o fluxo de suas execuções e guiar o desenvolvimento do
código fonte.
A Figura 22 mostra o diagrama de atividades elaborado, que apresenta a sequência
de validações e funções que devem ser realizadas pelo firmware.
Concluído o projeto do firmware, iniciou-se com o planejamento da camada de
software, que é apresentada na próxima seção.
3.3. Software 69
Figura 22 – Diagrama de atividades do funcionamento do firmware
Fonte: Autor
3.3 Software
O diagrama Figura 23 mostra que o desenvolvimento dessa camada foi subdividido

em duas partes, um software para configuração do equipamento, que impacta diretamente
o funcionamento do firmware, e outro para exibição e armazenamento dos dados em banco
de dados, os quais serão descritos nas duas subseções seguintes.
Figura 23 – Esquematização da camada de software da arquitetura do protótipo
Fonte: Autor
3.3.1 Software de configuração

Um fator muito importante para facilitar o uso de um datalogger é a possibilidade de
realizar a configuração de suas funcionalidades de maneira simples. Dataloggers comerciais
comumente dispõem de uma interface gráfica que possibilita sincronização de horário,
configuração dos sensores existentes, periodicidade de registro, periodicidade de envio,
leitura momentânea dos valores adquiridos pelos sensores, entre outras funcionalidades.
Porém, até mesmo pela abrangência de soluções e territórios, essas interfaces não costumam
possuir fácil usabilidade, sendo muitas vezes necessária a compra de horas de suporte
técnico para compreender como realizar o processo desejado. As soluções acadêmicas,
conforme abordado no Capítulo 2, de revisão bibliográfica, tampouco se preocupam em
prover um software para facilitar ou possibilitar a configuração de maneira rápida e fácil.
Nas próximas duas subseções, detalha-se o processo de criação do software desen-
volvido para configuração do protótipo proposto.
3.3.1.1 Requisitos
Seguindo a metodologia proposta, a Tabela 19 apresenta um recorte com os

principais requisitos identificados para a camada do software de configuração. Estes e os
demais requisitos identificados e avaliados, bem como seu detalhamento, estão disponíveis
no Apêndice A.
Tabela 19 – Requisitos da camada de software
Priori- Depen-
RFSC-01: In- O sistema deve possuir campos para configuração de todas Funcional Média Inexistente
terface para as suas funcionalidades, sendo: nome da estação (limitado a
configuração 8 caracteres, sem acentos ou caracteres especiais), intervalo
de coleta, intervalo de transmissão, 16 portas analógicas
(com seus respectivos parâmetros para cálculo, necessários
para se chegar à grandeza desejada) e 2 portas digitais
contadoras de pulso.
RFSC-02: O sistema deve disponibilizar uma função para ajustar Funcional Alta Inexistente
Sincronizar o horário do equipamento de acordo com o horário do
RTC computador. Essa funcionalidade deverá ser executada no
primeiro uso ou caso permaneça por longo período fora de
operação.
3.3. Software 71
RFSC-03: O sistema deve estar apto a criar um arquivo em formato Funcional Média Inexistente
Criar arquivo “.TXT”, contendo todas as configurações realizadas na in-
de configura- terface gráfica. Esse arquivo deverá ser copiado para cartão
ção SD que será utilizado pelo equipamento.
RFSC-04: En- O sistema deve estar apto a realizar o envio de aplicações Funcional Alta Inexistente
vio de aplica- (firmwares) ao equipamento. O envio será feito por meio
ções (firmwa- de uma porta de comunicação que deve ser selecionada
res) antes do envio. As aplicações disponíveis devem ser: teste
de funcionamento (que exibirá os dados de segundo em
segundo), aplicação de produção (que realizará a coleta
e envio de acordo com o configurado) e atualização de
horário (que deverá ser utilizada na primeira utilização
do equipamento ou após ter ficado sem utilização durante
períodos maiores que uma semana).
RNFSC-01: O sistema deve dispor de uma tela de informação, onde Não- Baixa Inexistente
Tela de infor- são descritas a motivações do projeto. Funcional
mação
RNFSC-03: O sistema deve dispor de um manual de instalação, que irá Não- Baixa Inexistente
Manual de abrir um arquivo PDF para auxiliar o usuário a instalar o Funcional
instalação do ambiente de visualização do datalogger.
ambiente
RNFSC-04: O sistema de configuração deve estar apto a executar em Não- Média Inexistente
Multiplata- plataformas Linux e Windows. Funcional
forma
Fonte: Autor
3.3.1.2 Projeto
O diagrama de caso de uso da Figura 24 foi elaborado para identificar as interações

entre os atores do projeto e as funcionalidades existentes.
Na sequência foram elaborados os projetos das telas do sistema, buscando atender
aos requisitos e tornar a interface intuitiva, de modo a reduzir a dificuldade para o usuário
final.
A Figura 25 mostra o projeto elaborado para uma das abas que compõe o software
abordado nessa subseção, que foi construído utilizando a ferramenta gratuita NinjaMock
(2021).
Figura 24 – Diagrama de casos de uso do datalogger
Fonte: Autor
Figura 25 – Projeto elaborado para uma das abas do sistema de configuração
Fonte: Autor
3.3. Software 73
3.3.2 Software de exibição dos dados

Um aspecto importante que foi levado em consideração na criação do protótipo
proposto foi possibilitar a visualização dos dados coletados de forma gráfica ao usuário da
solução, sem a necessidade de um equipamento adicional. A alternativa para atendimento
a essa demanda foi a criação de um software embarcado no datalogger, que é detalhada
nas próximas duas seções.
3.3.2.1 Requisitos
A Tabela 20 apresenta um recorte com os principais requisitos identificados para a

camada do software de exibição. Estes e os demais requisitos existentes, assim como seu
detalhamento, estão disponíveis no Apêndice A.
Tabela 20 – Requisitos da camada do software de exibição
Priori- Depen-
Requisito Descrição Tipo
dade dência
O sistema deve possibilitar a visualização dos dados

RFSE-01:
dos sensores em um determinado intervalo de tempo.
Consulta de Funcional Alta Inexistente
Os dados devem ser exibidos por meio de gráfico e
dados
por meio de uma tabela.
RFSE-02: O sistema deve possibilitar a exportação dos dados em
Exportação formato .CSV para utilização em outras plataformas, Funcional Média Inexistente
dos dados como Excel e R.
O sistema deve rodar sob plataforma Apache + PHP,
RNFSE-02: embarcada num Raspberry PI que possua Linux em- Não Fun-
Alta Inexistente
Ambiente barcado, preferencialmente rodando a distribuição cional
Raspbian.
Optou-se por não realizar controle de acesso (usuá-
RNFSE-05: rio/senha) ou criptografia dos dados, visto que se Não Fun-
Baixa Inexistente
Acesso entendeu que os dados coletados não requerem cuida- cional
dos quanto ao sigilo.
Fonte: Autor
3.3.2.2 Projeto
O diagrama de caso de uso da Figura 24 mostra, dentre todas as possíveis interações,

a relação entre o ator “Pesquisador em Laboratório” e a funcionalidade “Visualizar dados
em interface WEB”. Para atendimento a essa funcionalidade foi projetada uma página web
visando atender todos os requisitos levantados e apresentados na seção anterior.
A Figura 26 mostra o projeto de interface que foi criado, contendo os componentes
necessários para exibição dos dados e também a sua disposição em tela, com o objetivo de
que a informação seja exibida de forma amigável.
Figura 26 – Projeto de interface de exibição
Fonte: Autor
A exibição dos dados coletados só se torna possível se estes estiverem devidamente

salvos em um banco de dados. A Tabela 21 mostra a estrutura da tabela "dado", projetada
para armazenamento dos dados coletados.
Tabela 21 – Estrutura da tabela "dado"do banco de dados
Nome do campo Tipo de dados
id INTEGER
data TIMESTAMP
sensorNome VARCHAR
valor DOUBLE
Fonte: Autor
Concluídas as etapas de elaboração das camadas de hardware, firmware e software,

realizou-se o processo de validação da solução proposta, o qual é abordado na sequência.
3.4 Validação
Considerando que a validação de requisitos é o processo pelo qual se verifica se
os requisitos identificados para o sistema realmente o definem quanto às necessidades e
expectativas dos stakeholders (SOMMERVILLE, 2011), nesta seção, comenta-se sobre
como este processo foi conduzido para o projeto do datalogger.
3.4. Validação 75
Os seguintes tipos de verificações foram considerados: 1) Validade; 2) Consistência;

3) Completude; 4) Realismo e 5) Verificabilidade. Este último tipo envolve ainda questões
de revisão, prototipação e geração de casos de testes.
As verificações de validade, consistência e completude foram realizadas junto aos
stakeholders. As demandas propostas foram avaliadas e, em ambos os casos, atendidas
satisfatoriamente.
A verificação de consistência foi realizada a fim de identificar se algum requisito
apresentava restrição contraditória ou funções iguais descritas de formas distintas. Não
foram encontradas falhas de consistência durante a verificação, até mesmo por se tratar de
um sistema pequeno e com poucos stakeholders envolvidos no processo.
Na verificação de completude, que visa garantir que todos os serviços requeridos
pelo usuário sejam definidos, foi realizada revisão de todos os requisitos a fim de identificar
se alguma funcionalidade havia sido esquecida ou ignorada. Constatou-se que todas as
funcionalidades apontadas pelos stakeholders foram listadas e descritas corretamente.
A checagem de realismo foi a última a ser realizada. Ocorreu após validações junto
aos stakeholders a fim de identificar se todos os requisitos poderiam ser implementados
dadas as restrições de tempo e orçamento previstos. Concluiu-se que os requisitos apurados
eram possíveis de serem implementados, considerando o orçamento e prazo existentes.
Com relação à verificabilidade, o sistema passou por processos de revisão, prototi-
pação e, por fim, casos de testes. A revisão dos requisitos foi sendo realizada incremental e
recursivamente conforme foram sendo coletados. O processo de prototipação também se
deu da mesma maneira, sendo revisado e incrementado conforme as reuniões de validação
eram realizadas. Os casos de testes estão descritos na sequência, na subseção 3.4.1. A versão
apresentada corresponde ao produto de todas as validações realizadas. No documento de
requisitos, que se encontra no Apêndice A, estão listadas as discussões e contribuições
efetivadas em cada um dos encontros citados acima.
3.4.1 Cenários de teste

Para validação do funcionamento do Sistema como um todo, tendo como foco o
datalogger, foram elaborados alguns cenários de teste, prevendo situações que pudessem
gerar algum tipo de erro ou interrupção na execução do mesmo. Cenários de testes são
situações típicas de uso do sistema que direcionam testes que serão realizados. Em geral,
eles contribuem para testar vários requisitos dentro do mesmo cenário, sejam individuais
ou combinações de requisitos (SOMMERVILLE, 2011).
Os cenários foram elaborados para as camadas de firmware e de software de
configuração. Cenários de testes para a camada de hardware não foram realizados, pois
envolvem questões físicas, como checagem da natureza de cada componente ou grupo de
componentes eletrônicos. A camada de software de exibição também não foi contemplada,

pois não há interação direta com o usuário, haja vista que é realizada apenas a exibição
dos dados de forma gráfica para a data selecionda.
A Tabela 22 detalha os cenários de testes previstos para a camada de firmware,
considerando seus possíveis resultados e percentuais aproximados de código executado. A
Tabela 23 apresenta o mesmo detalhamento para a camada do software de configuração.
Tabela 22 – Cenários de teste da camada de firmware
Porcentagem
Cenário Resultado
de código
Iniciar o datalogger sem sincroni- Dados gravados ficarão com a data da compilação do
100%
zar relógio sistema, não reproduzindo a data/hora reais.
Iniciar o datalogger sem cartão Será gerado um erro informando ao usuário que o
7%
SD cartão não foi encontrado
Iniciar o datalogger com cartão O datalogger será iniciado com configuração padrão,
SD, mas sem arquivo de configu- sem nenhum sensor habilitado e irá ficar funcionando, 9%
ração porém sem executar nenhuma função
O datalogger será iniciado com configuração padrão,
Iniciar o datalogger com arquivo
sem nenhum sensor habilitado e irá ficar funcionando 9%
de configuração fora do padrão
porém sem executar nenhuma função
Iniciar o datalogger com arquivo
O datalogger irá realizar os processos previstos 100%
de configuração correto
Travamento por falha de proces- Caso fique por 8 segundos ou mais sem resposta, irá
-
samento reiniciar automaticamente
Fonte: Autor
Tabela 23 – Cenários de teste da camada do software de configuração
Porcentagem
Cenário Resultado
de código
Iniciar sem bibliotecas de comu-

Não será possível se comunicar com o logger 95%
nicação serial instaladas
Gerar arquivo sem preenchimento Uma mensagem será exibida informando sobre o não
40%
dos campos obrigatórios preenchimento
Tentar enviar o firmware do log- Não será possível o envio e uma mensagem será exi-
80%
ger sem conexão bida
Fonte: Autor
No cenário de travamento por falha de processamento não é possível precisar o

percentual de código executado, haja vista que o erro pode ocorrer a qualquer momento
por falha do microcontrolador ou algum componente correlato que possa ocasionar um
mal funcionamento.
77
4 Resultados
Este capítulo apresenta os resultados obtidos após as atividades de concepção,

projeto e desenvolvimento do datalogger. Tais resultados estão subdivididos em três seções
que apresentam, respectivamente, o resultado final de cada uma das camadas do datalogger
criado, a aplicação deste datalogger em um simulador de chuva e a avaliação de desempenho
e análises estatísticas dos dados coletados.
O diagrama de ligação e layout da PCB do hardware, bem como os códigos-fontes
do firmware e softwares criados, foram disponibilizados em um repositório do GitHub
(https://github.com/edipocarneiro/projetoMestrado).
4.1 Datalogger
4.1.1 Hardware
Após elaborados e revisados os projetos descritos na Subseção 3.1.3, foi necessário
realizar a confecção da placa de circuito impresso (PCB), de 200mm x 140mm, que se
encontra ilustrada na Figura 27 e foi executada pela empresa JLCPCB (2020).
Figura 27 – Placa de circuito impresso
Fonte: Autor
Também foi necessária a compra e soldagem dos componentes necessários ao

funcionamento do hardware, os quais são listados na Tabela 24.
78 Capítulo 4. Resultados
Tabela 24 – Lista de componentes da PCB
Quantidade Componente Código
3 Barra de Pinos Simples - 1x40 Macho (Metaltex) BPSC-40

1 Barra de Pinos Dupla - 1x20 Macho (Metaltex) BPDC-20
20 Capacitor Cerâmico 0.1uF
5 Capacitor Eletrolítico 1uF
1 Capacitor Eletrolítico 10uF
2 Capacitor Poliéster 4.7nF
16 Capacitor Poliéster 0.001uF
1 CI MAX232
1 CI ULN2003AN
2 Conector DB9 DBPN2F-09
1 Conector IDC Macho (Metaltex) IDCSN-10
1 Conector IDC Macho (Metaltex) IDCCC-16
2 Conector Latch p/ cabo 10 vias L-10
2 Conector Latch p/ cabo 16 vias L-16
1 Conector Mini Header Fileira Dupla PCI (Metaltex) MCD-40
16 Diodo TVS P6KE6.8A-G
2 Led Led
5 Resistor 1/4 W 10k
1 Resistor 1/4 W 240
1 Resistor 1/4 W 2k2
1 Soquete SD Card DM1AA-SF-PEJ
2 Transistor BC548B
2 Chaves DIP (Metaltex) DS-08
5 Borne para PCI - 2 vias BR1102V
1 Borne para PCI - 3 vias BR1103V
16 Borne para PCI 2 Níveis - 3 vias BR1203V
1 Módulo RTC DS3231 - Arduino DS3231
5 Cabo Plano (Flat Cable) 26 vias (Metaltex) 3011-26
1 Módulo conversor DC-DC Step Down - Arduino LM2596
Fonte: Autor
4.1. Datalogger 79
Os componentes listados na Tabela 24 foram utilizados na confecção da placa

com diferentes finalidades. Por exemplo, as barras de pinos possibilitam a conexão do
Arduino e Raspberry Pi, o CI Max232 faz a conversão de sinais TTL para padrão de
comunicação RS232, os bornes e conectores possibilitam a conexão dos sensores e das
saídas de comunicação, os capacitores e resistores atendem aos requisitos de funcionamento
dos CIs e os leds indicam a operação do equipamento.
Um dos objetivos desse projeto foi atender ao requisito de que a solução apresentasse
um baixo custo em relação às soluções comerciais. O custo total para construção de uma
unidade atingiu objetivo proposto, sendo de aproximadamente R$ 1.037,30 ou US$ 192,35,
considerando-se a taxa de conversão da época, R$ 5,39 por dólar. O Quadro 3 apresenta
um detalhamento dos itens, quantidades, custos e empresas fornecedoras. Os valores
apresentados estão em reais e em dólares americanos e refletem a realidade do mês de
Abril de 2020, época em que foram adquiridos.
Quadro 3 – Custo dos componentes utilizados para elaboração do datalogger

Descrição Quantidade Valor Empresa
R$ 89,90 | US$
Arduino Mega 2560 1 FilipeFlop (2020)
16,65
R$ 489,90 | US$
Raspberry PI 3B+ 1 FilipeFlop (2020)
91,00
R$ 157,50 | US$
Placa PCB 5 JLCPCB (2020)
29,15
Componentes da R$ 300,00 | US$ Proesi (2020) e
-
Tabela 24 55,55 FilipeFlop (2020)
Fonte: Autor
A Figura 28 mostra o datalogger com todos os seus módulos e componentes

devidamente conectados.
A subseção seguinte apresenta os detalhes da versão final da camada de firmware.
4.1.2 Firmware
Seguindo um dos conceitos chave das Metodologias Ágeis de desenvolvimento que
é o de software em funcionamento ao invés de documentação completa (MANIFESTO,
2004), logo após a extração dos requisitos necessários para atendimento a solução proposta
e a elaboração do diagrama de atividades apresentado no Capítulo 3, foi realizada a criação
do código de programação contido no Apêndice C, que controla o datalogger. O código foi
desenvolvido na linguagem C++ (C++, 2021), que é a padrão da plataforma Arduino.
Para seu desenvolvimento, compilação e testes foi utilizada a interface de desenvolvimento
Arduino IDE, que também é disponibilizada pela Arduino (ARDUINO, 2021a).
Figura 28 – Datalogger com seus componentes e módulos adicionados. A imagem destacada

por (a) é a parte superior da PCB, a imagem destacada por (b) é a parte
inferior da PCB a imagem destacada por (c) ilustra o datalogger instalado.
(a) (b)
(c)
Na sequência são detalhadas, respectivamente, as versões finais dos softwares

desenvolvidos para configuração do datalogger e para exibição dos dados coletados.
4.1.3 Software
4.1.3.1 Software de Configuração
O software de configuração foi desenvolvido na linguagem de programação Java

e foi dividido em quatro seções (abas) distintas: “Sobre”, “Configurações”, “Aplicações”
e “Dados em Tempo Real”. A Figura 29 mostra a tela inicial, que possui as informações
4.1. Datalogger 81
gerais sobre o sistema criado.
Figura 29 – Tela inicial do configurador com informações sobre o projeto
Fonte: Autor
A Figura 30, identificando a opção “Configurações” viabiliza a realização das

configurações do datalogger. O campo “Nome da Estação” é para identificar o datalogger, o
campo “Intervalo de Coleta e Transmissão” para informar em qual intervalo de tempo, em
minutos, o datalogger realiza a gravação dos dados em memória interna, o campo “Porta
de saída de dados” determina para quais portas de saída os dados deverão ser enviados. As
caixas de seleção “Porta Digital 1”, “Porta Digital 2” e “Porta RS485” habilitam ou não o
registro das informações dos sensores conectados às respectivas portas físicas do datalogger.
As abas de A1 a A16, possibilitam que sejam configuradas as portas analógicas existentes
no datalogger. As configurações possíveis são habilitação ou não da coleta, o cadastro
de um identificador específico para o sensor, quais os valores do intervalo inicial/final
da leitura realizada pelo sensor (o range) e o valor a ser somado ou subtraído da leitura
realizada pelo sensor (o offset).
A Figura 31 ilustra um exemplo da tela de confirmação que é exibida ao clicar no
botão “Gerar arquivo de configuração”. Essa tela apresenta um resumo dos campos que
foram preenchidos anteriormente.
Figura 30 – Tela de configurações do datalogger e dos sensores existentes
Fonte: Autor
Figura 31 – Exemplo da mensagem de confirmação das configurações
Fonte: Autor
A Figura 32 identifica a opção “Aplicações”, que possibilita o envio das três opções
de aplicação existentes ao equipamento. O botão “Testar funcionamento” realiza a coleta
de informações de segundo em segundo, conforme configurações previamente realizadas, e
disponibiliza essas informações coletadas na aba “Dados em Tempo Real” para que possam
ser avaliadas e eventualmente corrigidas. Já o botão “Enviar aplicação de produção” faz
com que o equipamento entre em modo de “produção”, o que significa que passa a realizar
as coletas e envios de acordo com as configurações previamente determinadas. Por último,
a opção “Sincronizar horário” atualiza o relógio interno do equipamento. É necessária a
execução de tal processo na primeira utilização do equipamento ou após períodos maiores
do que 7 dias sem utilização (desligado).
4.1. Datalogger 83
Figura 32 – Tela de envio de aplicações ao datalogger
Fonte: Autor
A Figura 33 exibe a opção “Dados em Tempo Real”, que possibilita a visualização

de forma gráfica dos dados que estão sendo coletados e registrados pelo datalogger. O
campo “Console” apresenta toda a troca de informação que ocorrer por meio da porta
USB do equipamento.
Figura 33 – Guia de acompanhamento dos dados
Fonte: Autor
4.1.3.2 Software de Exibição
O projeto de criação dessa funcionalidade aplicou os conceitos da Programação Ágil

para identificação dos requisitos necessários. A construção do software foi realizada fazendo
uso da linguagem de programação PHP (PHP, 2021) e do banco de dados MySQL/MariaDB
(MARIADB, 2021), que são plataformas livres, já consolidadas e com grande conteúdo de
apoio disponível para o desenvolvimento.
A Figura 34, mostra a tela principal do software de exibição dos dados provenientes
do datalogger. Esse software, que pode ser acessado por meio do navegador, possibilita
a seleção da data para exibição dos dados coletados de todos os sensores. Os dados
selecionados são exibidos por meio de um gráfico de linhas e também em formato de tabela,
possibilitando, assim, a sua exportação.
Figura 34 – Tela principal do software de exibição dos dados
Fonte: Autor
As informações sobre a instalação dos componentes necessários para o funciona-

mento deste ambiente, como do Raspberry PI OS, do Apache HTTP Server (APACHE,
2021), do PHP, do MySQL/MariaDB, o Java (JAVA, 2021) e demais configurações neces-
sárias, estão contidas no manual adicionado no Apêndice B, que detalha passo a passo o
procedimento a ser realizado. Um link para este mesmo manual também está disponível
na tela inicial do software, por meio do botão “Manual de Instalação”, conforme mostrado
na Figura 29.
A subseção seguinte apresenta os testes iniciais feitos no datalogger desenvolvido.
4.1. Datalogger 85
4.1.4 Testes Piloto

Finalizadas as fases de projeto e desenvolvimento do protótipo, seguiu-se a aborda-
gem das Metodologias Ágeis e foram realizados três testes piloto para avaliar o compor-
tamento de diferentes aspectos do datalogger. O primeiro teste teve por objetivo avaliar
aspectos de usabilidade, sendo, para tanto, realizadas as verificações descritas na Tabela 25.
O resultado desejado para cada um dos testes foi atingido, sendo respeitadas e atendidas
as especificações previstas no levantamento de requisitos.
Tabela 25 – Testes realizados e resultados obtidos
Teste Resultado
Executar no Windows e no Linux Teste em ambas as plataformas não apresentou problema.

Testar interface para configuração Interface funcionando conforme especificação.
Exibir tela de informação do projeto e ajuda Exibição ocorrendo conforme projeto.
Sincronizar relógio de tempo real Sincronismo realizado entre computador e equipamento.
Criar o arquivo de configuração; Criação do arquivo ocorrendo sem erros.
Enviar aplicações Envio das aplicações/firmwares realizado com sucesso.
Fonte: Autor
O segundo teste teve por objetivo avaliar o funcionamento do datalogger em ambi-

ente de campo. Para tanto, o datalogger foi deixado por 3 dias, entre 06 e 08/02/2021, no
telhado do Edifício João Baptista Cunha, situado em Cascavel/PR, coletando e armaze-
nando os dados do sensor multiparamétrico MSO da empresa MetOne Instruments (MET
ONE INSTRUMENTS, INC., 2021), que realiza a captura dos parâmetros de velocidade e
direção de vento, umidade relativa, temperatura e pressão atmosférica e que tem como
saída de comunicação o protocolo RS485. A Figura 53 do Apêndice C, mostra a instalação
do sensor utilizado no local de realização do teste e respectivas ligações com o datalogger.
O teste obteve como resultado o atendimento aos seguintes requisitos funcionais
do hardware: RFH-01, RFH-02, RFH-03, RFH-07 e RFH-09. Também foram atendidos
todos os requisitos funcionais de firmware, do RFF-01 ao RFF-09. A Figura 54, contida
no Apêndice C, exibe os dados coletados e armazenados pelo datalogger durante o dia
06/02/2021.
O terceiro e último teste da fase preliminar, mostrado na Figura 55 do Apêndice C,
consistiu na utilização de dois sensores capacitivos de umidade de solo, em ambiente de
laboratório, a fim de acompanhar o comportamento de uma amostra de solo que teve 50%
de sua área molhada. O resultado do teste atendeu aos requisitos funcionais do hardware:
RFH-01, RFH-02, RFH-03, RFH-04, RFH-09 e RFH-11. Também foram atendidos todos
os requisitos funcionais de firmware, do RFF-01 ao RFF-09.
Uma vez que os resultados da construção do datalogger e da execução dos testes
pilotos foram positivos, optou-se pela aplicação do equipamento em uma pesquisa que
estava em curso na Universidade Estadual do Oeste do Paraná (UNIOESTE), que envolvia

a construção de um simulador de chuva. Os detalhes sobre a pesquisa e sobre como o
equipamento desenvolvido foi aplicado estão descritos na seção seguinte.
4.2 Aplicação em um simulador de chuva
Simuladores de chuva são equipamentos que utilizam aspersores para lançar quan-
tidades controladas de água sob uma amostra de solo. Tais equipamentos visam simular
condições de velocidade de distribuição e impacto das gotas de chuva, de intensidade de
precipitação, do ângulo de impacto das gotas e duração de chuvas intensas (BRANDÃO,
2006). Para análise dos resultados de experimentos realizados por meio desse tipo de
simulador, é imprescindível o uso de dataloggers, pois é necessário registrar, ao longo
de períodos de tempo pré-definidos, diversas amostras de dados dos múltiplos sensores
envolvidos.
O simulador de chuva construído por Chang (2021) na sua tese de doutorado (em
andamento) em Engenharia de Energia na Agricultura, vinculado ao Centro de Ciências
Exatas e Tecnológicas da UNIOESTE, tem como principal objetivo, por meio dos dados
adquiridos, realizar o desenvolvimento e validação de modelos de perda de água e do solo
por escoamento superficial em função da taxa de cobertura vegetal. A Figura 35 mostra o
projeto do simulador proposto pelo pesquisador, indicando suas partes e características.
A amostra de solo utilizada foi proveniente do Instituto Agronômico do Paraná -
IAPAR - polo regional de Santa Tereza do Oeste – PR, que é classificado como Latossolo
Vermelho Distroférrico típico, com textura argilosa a muito argilosa (SANTOS et al., 2018).
Na Tabela 26 são mostradas as proporções de silte, argila e areia do solo utilizado no
experimento realizado.
4.2. Aplicação em um simulador de chuva 87
Figura 35 – Simulador de chuva
Fonte: Disponibilizado por Chang (2021)
Tabela 26 – Composição granulométrica1 do solo nas camadas de 0 ⊢ 0, 1; 0, 1 ⊢ 0, 2 e

0, 2 ⊢ 0, 3 m da área experimental do IAPAR/Santa Tereza (valores médios de
3 repetições)
Camada (m) Granulometria

Areia Argila Silte
−1
g kg
0, 0 ⊢ 0, 1 44,9 561,1 394,1

0, 1 ⊢ 0, 2 38,7 641,9 319,4
0, 2 ⊢ 0, 3 24,7 706,2 269,1
Média 36,1 636,4 327,5
1
Método da pipeta, conforme USDA-Soil Conservation Service. Soil Survey Investigations
Report n.1. Whashington, 1972. 63 p.
Fonte: Disponibilizado por Chang (2021)
O sistema de sensoriamento instalado no simulador contou com 9 sensores de

umidade do solo do tipo capacitivo, 1 sensor de fluxo de água com saída digital e 1 sensor
ultrassônico para medição do volume de água percolado, todos conectados ao datalogger
desenvolvido. As especificações e características dos sensores utilizados estão descritas nas

subseções seguintes.
4.2.1 Sensor de umidade de solo

O sensor de umidade do solo, mostrado na Figura 36 e adotado para aplicação no
projeto, realiza a medição com base na alteração da capacitância a partir da umidade do
solo. A escolha deste sensor em detrimento do tipo resistivo, mais barato e comum no
mercado, deu-se principalmente devido à diferença em seu tempo de vida útil, que é maior
nos sensores do tipo capacitivo. A Tabela 27 mostra as principais características técnicas
do sensor.
Figura 36 – Sensor de umidade de solo do tipo capacitivo
Fonte: Disponibilizado por FilipeFlop (2020)
Tabela 27 – Especificações do sensor de umidade

do solo de acordo com o fornecedor
Descrição Valor
Tipo de sensor Capacitivo.

Tensão de operação 3,3V a 5,5V.
Saída (output) 0 a 3V.
Dimensões 22 mm × 102 mm x 7 mm.
Comprimento do Cabo 20cm.
Fonte: Adaptado de FilipeFlop (2020)
No sistema de monitoramento elaborado para o projeto de Chang (2021) esse sensor

foi utilizado para realizar medição da umidade dos vários pontos e camadas distribuídos na
amostra de solo. Como o sensor possui um conector e alguns componentes eletrônicos na
parte superior do seu corpo, para que ele pudesse ser aplicado e enterrado no solo foram
necessárias algumas alterações. Primeiramente, foi preciso realizar a remoção do conector
padrão e soldar diretamente os cabos para alimentação e comunicação. Na sequência, foi
realizado o isolamento dos componentes expostos de seu circuito eletrônico, testando-se
dois métodos distintos: aplicação de resina e aplicação de fita isolante líquida. No caso
da resina, foi utilizada uma capa plástica que serviu de suporte para o preenchimento e,
posteriormente, como acabamento. Já no uso de fita isolante líquida, foi aplicada uma
camada sobre os componentes expostos e, em seguida, usou-se fita auto fusão para reforçar
o isolamento e aumentar a sustentação dos fios. Na Figura 37 apresenta-se um mosaico de

imagens que ilustram os processos realizados.
Figura 37 – Processo de preparação do sensor de umidade do solo
Fonte: Autor
Para avaliar o desempenho dos métodos de isolamento propostos, os sensores foram

mergulhados inteiramente em um recipiente com água, conforme exibido na Figura 38,
e conectados ao datalogger para realização de leitura. Os dados capturados acusaram
o funcionamento padrão do sensor, sendo possível concluir inicialmente que ambas as
formas utilizadas para o isolamento foram eficientes. Entretanto, à medida que os testes
seguiram, notou-se que um dos sensores no qual a resina foi aplicada, devido a baixa
aderência ao material, apresentou corrosão em seu corpo e falhas no funcionamento. Assim
sendo, a alternativa da fita isolante líquida se mostrou mais interessante para ser adotada
em futuras preparações, devido à facilidade para compra dos materiais necessários, pela
eficiência no isolamento da umidade e também pela facilidade de aplicação.
4.2.2 Sensor de fluxo de água
O sensor de fluxo de água escolhido para utilização no projeto, mostrado na

Figura 39, realiza sua leitura por meio de uma válvula em formato de catavento com
um imã acoplado, que trabalha em conjunto com um sensor hall para enviar um sinal
PWM. Por meio destes pulsos, que correspondem a aproximadamente 2,08 mL, foi possível
mensurar a vazão que está passando na linha de alimentação do simulador feito por Chang
(2021). A Tabela 28 mostra as principais características técnicas do sensor. A especificação
técnica completa do sensor foi adicionada no Anexo A.
Figura 38 – Sensor imerso em água
Fonte: Autor
Figura 39 – Sensor de fluxo de água
Fonte: Disponibilizado por Mantech (2021)
Tabela 28 – Especificações do sensor de vazão de

acordo com o fornecedor
Descrição Valor
Tipo de sensor Efeito Hall.

Saída (output) Pulso.
Tensão de operação 5-24V.
Faixa de fluxo 1-30L/min.
Pulsos por litro 404.
Dimensão da conexão 1/2".
Fonte: Adaptado de Mantech (2021)
4.2.3 Sensor ultrassônico
O sensor utilizado para mensurar o volume de água percolado foi o HC-SR04,

conforme mostrado na Figura 40.
Figura 40 – Sensor ultrassônico
O firmware do datalogger teve de ser adaptado para realizar a leitura do sensor, uma
vez que a especificação padrão do projeto não contempla a leitura de sensores de operação
específica. A implementação da adaptação se deu de forma rápida, pois o funcionamento
do sensor é simples e existem diversos exemplos de sua utilização na internet. É importante
ressaltar que o tempo envolvido entre o envio e o retorno dos pulsos (jitter) variou, nos
testes realizados, entre 80 ms e 120 ms e não impactou nas demais rotinas realizadas pelo
datalogger.
O funcionamento do sensor se baseia no envio e retorno (echo) de sinais ultrassônicos.
Com base no tempo entre envio e retorno, é possível calcular a distância entre o sensor e o
objeto detectado. Primeiramente é enviado um pulso de 10 microssegundos, indicando o
início da transmissão de dados. Depois disso, são enviados 8 pulsos de 40 KHz. O sensor
aguarda o retorno (em nível alto) para determinar a distância entre o sensor e o objeto,
utilizando a Equação 4.1 (FILIPEFLOP, 2020), em que D é a distância, T é o tempo do
echo em nível alto e Vs é a velocidade do som.
D = (T.V s)/2 (4.1)
Na aplicação realizada no projeto de Chang (2021) esse sensor foi utilizado para
realizar medição da distância entre a borda e o fundo de um recipiente de dimensões
conhecidas, sendo possível, dessa forma, calcular o volume de água existente.
A Tabela 29 mostra as características técnicas do sensor de acordo com o fornecedor.
A especificação técnica completa do sensor foi adicionada no Anexo B.
Tabela 29 – Especificações do sensor ultrassônico
Descrição Valor
Tensão de operação 5V.

Saída (output) Digital (high/low).
Alcance 2cm a 4m.
Precisão 3mm.
4.2.4 Calibração
Após a escolha dos sensores para atender a automação do simulador de chuva,
foi necessário avaliar se as características de funcionamento e precisão descritas nas
especificações disponibilizadas pelos fabricantes estavam condizentes com a realidade. Para
tanto, cada um dos sensores passou por um processo de calibração, comparando-se os dados
coletados com medições empíricas, para validar se os valores lidos refletiam a realidade.
Foram aplicados modelos estatísticos com o intuito de avaliar a aquisição de dados
de cada sensor por meio da leitura computada pelo datalogger. Após estimar os valores dos
parâmetros nos modelos usando ajuste por Regressão Linear Simples, três métricas foram
utilizadas para medir a qualidade dos ajustes, sendo elas o coeficiente de determinação
(r2 ), os resíduos quadráticos (θ2 ) e o erro quadrático médio (RMSE). Suas equações são
apresentadas, respectivamente, em (4.2), (4.3) e (4.4).
i=1 (Xex − Xadj )

Pn 2
n
r =1−
2
(4.2)
i=1 (Xex − ( i=1 Xex )
Pn 2
P n 2
n
n
θ2 = (Xex − Xadj )2 (4.3)
X
i=1
sP
i=1 (Xex − Xadj )2
n
RM SE = (4.4)
n
Em que Xex representa os valores experimentais, Xadj os valores ajustados e n o tamanho
amostral. Para avaliação do teste de significância dos modelos construídos foi utilizado o
P-valor, sendo que, se P-valor < 0.05, então o modelo é significativo a 5%.
Nas subseções seguintes são detalhados os processos realizados para cada um dos
sensores.
4.2.4.1 Sensor de fluxo de água
Para realização do processo de calibração, o primeiro passo foi adicionar o sensor

de fluxo de água na linha de alimentação de água do simulador, conforme mostrado na
Figura 41.
Figura 41 – Instalação do sensor de fluxo de água (destacado em pontilhado)
Fonte: Autor
Conforme informações obtidas na documentação do sensor, exibidas no Quadro 4 e

na Figura 42, a relação entre a frequência (Hz) gerada pelo sensor e a vazão por hora se
comporta basicamente de forma linear, havendo um pequeno desvio conforme o fluxo se
intensifica. A Tabela 30 mostrou que o ajuste linear foi significativo (P-valor < 0.05) e que
o coeficiente r2 ficou em 0,992, mostrando uma alta qualidade, o que significa que o valor
ajustado é muito próximo do observado.
Figura 42 – Gráfico de correlação vazão x frequência
600
Vazão(L h-1)
400
200
25 50 75
Frequência (Hz)

Quadro 4 – Correlação vazão x frequência disponibilizado na documentação do sensor

Vazão (L h−1 ) Frequência (Hz)
120 16
240 32,5
360 49,3
480 65,5
600 82
720 90,2
Tabela 30 – Coeficientes e métricas do ajuste linear da vazão (V ) em função da frequência

(F ) com dados existentes na documentação do sensor
V = aF + b
a b r2 θ2 RMSE P-valor
7,777 -14,861 0,992 2033,612 18,410 2,45E-05
Fonte: Autor
Considerando que os experimentos realizados no simulador, do ponto de vista

agronômico, têm o volume de água injetado no sistema como variável de interesse, foi
necessário encontrar a razão entre a quantidade de pulsos e a vazão (L h−1 ). Isso porque o
datalogger registra a quantidade de pulsos gerados pelo sensor e não a vazão diretamente.
Para tanto, calculou-se, para cada uma das faixas de vazão indicadas no Quadro 4, quantos
mililitros são necessários para o registro de um pulso. O cálculo foi realizado em mililitros,
pois cada pulso representa uma pequena fração de um litro. O Quadro 5 apresenta a razão
mililitros por pulso esperada, considerando que 1 Hertz equivale a um ciclo por segundo e
tomando-se por base os dados disponibilizados pela especificação do fabricante Mantech
(2021).
Quadro 5 – Correlação entre vazão e frequência para cálculo da razão em mL por pulso
Vazão Frequência Vazão Pulsos por Razão
(L h−1 ) (Hz) (L/min) minuto (mL/pulso)
120 16 2 960 2,08
240 32,5 4 1950 2,05
360 49,3 6 2958 2,03
480 65,5 8 3930 2,04
600 82 10 4920 2,03
720 90,2 12 5412 2,22
Fonte: Autor
Antes de iniciar a coleta dos dados provenientes do sensor, foi necessário apurar
também qual a vazão (L h−1 ) encontrada para as diferentes pressões de entrada disponíveis
no simulador, que são de 5, 10, 20, 30, 40, 50 e 60 mca. Assim sendo, o simulador foi
colocado em funcionamento durante 1 minuto e foi utilizado um balde graduado para
apurar qual o volume de água seria acumulado. Foram realizadas 3 repetições do teste
para então ser calculada a média dos valores (L h−1 ) registrados. O Quadro 6 apresenta os
dados encontrados.
Quadro 6 – Média (L h−1 ) de acordo com as pressões de entrada de água do simulador

Pressão Volume Litros por Vazão Média
(mca) (L) Hora (L h−1 )
5 0,31 18,60
5 0,31 18,60 18,30
5 0,30 17,70
10 0,57 34,20
10 0,58 34,80 34,60
10 0,58 34,80
20 0,83 49,74
20 0,85 50,70 50,28
20 0,84 50,40
30 1,05 63,00
30 1,09 65,40 63,00
30 1,01 60,60
40 1,19 71,40
40 1,23 73,50 72,90
40 1,23 73,80
50 1,28 76,80
50 1,29 77,40 77,20
50 1,29 77,40
60 1,39 83,40
60 1,39 83,40 83,40
60 1,39 83,40
Fonte: Autor
Após estabelecer as correlações apresentadas, iniciou-se a coleta dos dados. No teste

realizado, o sensor foi conectado ao datalogger e foram variadas as pressões de entrada de
água do simulador. Para possibilitar a comparação entre os valores registrados pelo sensor
e quantidade real de água, utilizou-se um recipiente graduado colocado logo abaixo do
bico de aspersão, de modo a coletar todo o volume de água que estivesse sendo inserido no
simulador e, por consequência, sendo capturado pelo sensor. Os resultados encontrados
estão apresentados no Quadro 7.
Levando em consideração que todas as pressões de teste se enquadraram dentro
da primeira faixa de operação do sensor, de até 120 litros por hora, os dados coletados
indicaram que as leituras do sensor apresentaram uma variação da razão entre 1,98 mL a
2,11 mL por pulso.
A razão prevista pelo fabricante do sensor, conforme apresentado na Quadro 5, é

de 2,08 mL na faixa de até 120 L h−1 . Logo, foi possível concluir que houve uma pequena
variação na razão, dadas as pressões de entrada testadas, porém o resultado foi satisfatório,
haja vista que os valores indicam que as leituras ficaram dentro da margem de erro prevista,
que é de +-5%, segundo especificações técnicas do fabricante contidas no Anexo A.
Foi realizado ainda o processo de regressão linear dos dados experimentais da vazão
de água com a leitura obtida por meio do sensor. O gráfico de ajuste apresentado na
Figura 43 mostrou visualmente um alto desempenho no ajuste de dados, o que pode ser
validado pelo r2 de 0,99 e o P-valor < 0,05, como apresentado na Tabela 31.
Quadro 7 – Razão volume/pulso de acordo com as pressões

Pressão Volume Razão
Pulsos
(mca) (mL) (mL/pulso)
20 930 470 1,98
20 940 475 1,98
30 930 447 2,08
30 980 464 2,11
50 1000 485 2,06
50 1081 528 2,05
Fonte: Autor
Figura 43 – Regressão linear dos dados experimentais da vazão de água com a leitura do
sensor.
80
70
Vazão(L h-1)
60
50
40
30
20
150 200 250 300 350 400 450 500 550 600 650 700
Leitura do sensor (pulsos)
Fonte: Autor
Tabela 31 – Coeficientes e métricas do ajuste linear da vazão (V ) em função da frequência

(F ) com dados experimentais
V = aF + b
a b r 2
θ2 RMSE P-valor
0,123 0,920 0,990 111,517 2,304 9,52E-20
Fonte: Autor
4.2.4.2 Sensor ultrassônico
Para atestar se a operação do sensor ultrassônico escolhido para uso no projeto

estava condizente com o especificado pelo fabricante e descrito na Tabela 29, o sensor foi
fixado na parte superior de um balde graduado a fim de que se pudesse medir a distância
entre o topo (volume máximo) e a linha-d’água, conforme mostrado na Figura 44.
Figura 44 – Balde graduado e sensor instalado
Fonte: Autor
O teste consistiu na adição de quantidades conhecidas de água, medidas com o

auxílio de uma proveta graduada marca SATELIT, modelo HS375, e na captura da leitura
da distância em centímetros realizada pelo sensor. Este processo foi repetido por três vezes,
R1, R2 e R3, e os resultados encontrados estão apresentados no Quadro 8.
Nota-se que os valores lidos pelo sensor se comportaram de maneira esperada,
reduzindo conforme a adição de água ocorria, haja vista que a lâmina d’água se aproximava
do sensor. Com base nos dados coletados, foi possível realizar o processo de regressão, que
resultou na elaboração da equação, do coeficiente de determinação, r2 (Tabela 32) e do
gráfico de ajuste (Figura 45). Os modelos são significativos a 5% e bem ajustados aos
dados, mostrando a qualidade da leitura do sensor ultrassônico.
Quadro 8 – Média de distância lida pelo sensor de acordo com volume adicionado
Média
Volume Medida R1 do Medida R2 do Medida R3 do
distância lida
(L) sensor (cm) sensor (cm) sensor (cm)
(cm)
0 25,72 25,7 25,7 25,71
1 23,1 23,1 23,62 23,27
2 21,25 20,94 20,92 21,04
3 19,17 19,22 19,28 19,22
4 16,46 16,62 16,67 16,58
5 14,9 15,02 14,52 14,81
6 12,42 13 12,49 12,64
7 10,91 10,52 10,52 10,65
Fonte: Autor
Figura 45 – Regressão linear do sensor ultrassônico
6
Volume de água (L)
10 15 20 25
Leitura do sensor ultrassônico (cm)
Fonte: Autor
Tabela 32 – Coeficientes e métricas do ajuste linear do volume de água (V ) em função da

leitura do sensor (S)
V = aS + b
a b r2 θ2 RMSE P-valor
-0,466 11,890 0,999 0,161 0,082 2,45E-33
Fonte: Autor
4.2.4.3 Sensores de umidade de solo
Primeiramente, foi realizado um processo de pré-calibração. Foram feitas 3 repe-

tições de leitura, R1, R2 e R3, para visualização dos valores capturados pelos sensores
em uma condição totalmente seca (seco), sem contato com solo, e, na sequência, em uma
condição de completa umidade, em que foram totalmente imersos em um recipiente com
água (molhado), conforme mostrado na Figura 38. Os valores registrados, dispostos no
Quadro 9, estão em formato bruto, que é a representação de um valor referenciado à
tensão lida na porta analógica, com base na resolução do conversor analógico/digital do
datalogger, que é de 10 bits (1023). O intervalo de medição indicado no Quadro 9 é a média
dos valores encontrados nas 3 repetições da condição seco, subtraído da média dos valores
encontrados para condição molhado.
Quadro 9 – Resultados do processo de pré-calibração

Molhado R1, Seco R1, R2 e Intervalo de
Sensor
R2 e R3 R3 Medição
1 255 | 255 | 255 449 | 450 | 450 194,66
2 274 | 274 | 274 477 | 476 | 476 202,33
3 262 | 262 | 262 468 | 468 | 468 206
4 267 | 267 | 267 468 | 468 | 468 201
5 274 | 274 | 274 473 | 472 | 472 198,33
6 263 | 263 | 263 470 | 468 | 468 205,66
7 262 | 262 | 262 461 | 460 | 461 198,66
8 278 | 278 | 278 483 | 483 | 483 205
9 270 | 270 | 270 481 | 480 | 480 210,33
Fonte: Autor
Com dados obtidos nesse teste, é possível notar que os sensores apresentam estabili-
dade na leitura dos dados entre as repetições (colunas). Porém, houve maior variabilidade
nos valores lidos quando comparadas às leituras realizadas por sensores diferentes (linhas).
Para confirmar tal inferência, foi realizada uma análise de variância (ANOVA) em
Delineamento Inteiramente ao Acaso para testar as hipóteses para verificar sua consistência
com os dados. Tais hipóteses estatísticas, que são complementares, são:
H0 : É a hipótese que está sendo testada, e nela admite-se que a diferença entre os
tratamentos não seja significativa, ou seja, que todos os tratamentos sejam iguais.
H1 : Admite-se que a diferença entre os tratamentos seja significativa, ou seja, que
a umidade em pelo menos um dos sensores seja diferente dos demais.
Na análise de variância, a regra de decisão é dada por: aceita-se H0 quando Fcal
≤ Ftab , em que Ftab corresponde ao valor da distribuição F para k − 1 e n − k graus de
liberdade das estimativas entre os tratamentos e dentro dos tratamentos a um nível de
significância de 5%. Caso contrário, rejeita-se tal hipótese.
A Tabela 33 mostra a análise de variância genérica, ilustrando os termos de graus

de liberdade e soma dos quadros dos tratamentos e resíduos, que são necessários para
calcular efetivamente a ANOVA.
Tabela 33 – Tabela de análise de variância (ANOVA) para

Delineamento Inteiramente ao Acaso.
GL SQ SQM Valor Fcal

QM T r
Tratamentos k-1 SQTr QMTr QM R
Resíduos n-k SQR QMR
GL: graus de liberdade; SQ: soma dos quadrados; SQM:

soma dos quadrados médios; k: quantidade de tratamentos;
n: tamanho amostral; SQTr: soma dos quadrados dos tra-
tamentos; SQR: soma dos quadrados dos resíduos; QMTr:
média dos quadrados dos tratamentos e QMR: média dos
quadrados dos resíduos.
Fonte: Autor
Observa-se, porém, que esta forma de apresentar o resultado pode não fornecer a
noção de quanto a variável calculada por meio do teste está distante da região crítica, e
qual é o risco que está se assumindo quando se aceita ou rejeita a hipótese nula. Uma
solução é realizar uma análise da Probabilidade de Significância, ou P-valor, que fornece
informações adicionais à decisão tomada, já que P-valor é a probabilidade de se obter um
valor da estatística de teste tão ou mais extremo que o valor observado, supondo-se H0
verdadeira. Como o P-valor é o menor nível de significância que leva à rejeição de H0 , se o
P-valor < α, rejeita-se H0 .
Foi utilizado o software R (RPROJECT, 2021) para realização do teste e os
resultados obtidos estão apresentados na Tabela 34 e Tabela 35, para a comparação dos
sensores na fase seca e úmida, respectivamente.
Tabela 34 – ANOVA dos sensores de umidade na fase seca
GL SQ SQM Valor F P-valor
Tratamentos 8 3279,389 409,9236 1341,568 4,81E-33

Resíduos 27 8,25 0,305556
GL: graus de liberdade; SQ: soma dos quadrados; SQM: soma dos
quadrados médios.
Fonte: Autor
Tabela 35 – ANOVA dos sensores de umidade na fase úmida
Tratamentos 8 1312,667 164,083 4,94E+28 1,85E-253

Resíduos 18 5,98E-26 3,32E-27
GL: graus de liberdade; SQ: soma dos quadrados; SQM: soma dos quadrados
médios.
Fonte: Autor
Como o valor encontrado para P-valor foi menor do que 0,05, rejeita-se a hipótese
nula, ou seja, sabe-se que os tratamentos possuem diferença significativa.
Embora a análise de variância viabilize estudar que as médias das amostras no
problema em análise não são estatisticamente equivalentes, tal metodologia não propicia
detectar quais são as médias diferentes das demais, sendo usual complementar o método
ANOVA com testes de comparação múltiplas de médias, como os de Tukey, Ducan e
Scott-Knott, que localizam as diferenças entre as médias dos tratamentos. O Teste de
Tukey, por ser bastante rigoroso e de fácil aplicação, é amplamente utilizado na análise de
experimentos agrícolas para determinar quais médias diferem entre si quando a ANOVA
indica pela rejeição da hipótese de igualdade entre as médias.
O teste de Tukey consiste no cálculo da Diferença Mínima Significativa (DMS),
apresentado por (4.5):
√
qα QM R
∆α = (4.5)
r
Em que ∆ é a diferença mínima significativa, que é a amplitude mínima para que as
médias sejam estatisticamente diferentes entre si; QM R o quadrado médio dos resíduos e
r o número de repetições em cada tratamento. O teste de hipótese considerado são:
H0 : A comparação entre duas médias são iguais;
H1 : As médias são estatisticamente diferentes.
Dessa forma, se a amplitude entre duas médias for maior que ∆, então rejeita-se a
hipótese nula em favor de hipótese alternativa.
Por conseguinte, e considerando os resultados dos P-valores apresentados nas
Tabela 34 e Tabela 35, indicando respectivamente pela rejeição das hipóteses nulas para
as igualdades entre as médias dos resultados dos sensores de umidade nas fases seca e
úmida, deve-se realizar um teste de comparação múltiplas de médias para verificar quais
resultados são estatisticamente iguais (diferentes). O Quadro 10 mostra os resultados
obtidos por meio do Teste de Tukey para as leituras nos sensores de umidade nas fases
seca e úmida, quando realizada a análise por coluna no referido quadro. As letras latinas
minúsculas iguais apresentadas nas linhas deste quadro indicam que são estatisticamente
iguais as médias, enquanto as letras diferentes indicam que são estatisticamente distintas
as médias analisadas. Assim, na fase Seco nota-se que são estatisticamente iguais as médias
das leituras dos sensores 3, 4 e 6, sendo distintas as demais médias. Na fase Úmida nota-se
que são estatisticamente iguais as médias das leituras dos sensores 2 e 5 e 3 e 7, também
sendo distintas as demais médias.
Quadro 10 – Teste de Tukey para a comparação das médias entre as leituras dos nove
sensores de umidade.
Sensor Seco Úmida

1 g g
2 c b
3 e f
4 e d
5 d b
6 e e
7 f f
8 a a
9 b c
Médias seguidas de mesma letra na coluna não diferem estatisticamente entre si pelo teste
de Tukey a 5% de probabilidade.
Fonte: Autor
Foi possível concluir que a maioria dos sensores é estatisticamente diferente, mesmo
para fase seca e molhada, sendo necessário realizar uma calibração específica para cada
sensor por meio de regressão. Assim sendo, estabeleceu-se uma metodologia para realização
da calibração, que consiste na execução de uma sequência de procedimentos, que seguem
representados no Algoritmo 1 e que são detalhados individualmente na sequência do texto.
Algoritmo 1 Procedimento de calibração

1: Selecionar 9 potes vazios
2: for pote = 1 . . .9 do
3: Pesar vazio
4: Numerar
5: end for
6: Estabelecer valor de pote = 9 (solo saturado):
7: Em um pote cheio de solo, encher de água até saturação
8: Tampar o pote com tecido tule e deixar de cabeça para baixo até parar de pingar
água
9: Retirar solo e água do pote, pesar e levar até estufa a uma temperatura de 105
°C, conforme CLAESSEN (1997)
10: Secar solo na estufa a 105 °C, com quantidade suficiente para preencher 9 potes
11: Medir a massa do solo seco e a massa de água do pote = 9
12: QA = quantidade de água necessária para cada pote por meio da Equação 4.7
13: for pote = 1 . . . 9 do
14: Adicionar solo seco com a mesma massa de pote = 9
15: if QApote > 0 then
16: Molhar o solo com a quantidade QApote , usando bacia e luvas
17: end if
18: Colocar o sensor dentro do pote
19: Tampar com papel alumínio e elástico
20: end for
21: for pote = 1 . . .9 do
22: for sensor = 1 . . .9 do
23: Coletar leitura dos sensores
24: end for
25: end for
26: amostra = amostras de solo de cada pote (mínimo 50% do conteúdo)
27: for pote = 1 . . .9 do
28: for amostra = 1 . . .3 do
29: Pesar na balança
30: Secar na estufa a 105°C e pesar, para calcular a porcentagem de umidade do
solo
31: end for
32: Fazer regressão e determinar a equação do cálculo da umidade do solo
33: end for
O primeiro passo, linhas de 1 a 5, foi adotar 9 potes iguais, de mesmo formato

e peso, que são apresentados na Figura 48. Após esse processo, linhas 6 a 9, um destes
potes recebeu 500,05g de solo e, em seguida, foi saturado de água, conforme exposto na
Figura 46.
Na sequência, 3 amostras deste solo foram retiradas e colocadas em latas para que
fosse possível realizar o processo de secagem na estufa a 105ºC (linha 10). Estas amostras
foram pesadas antes e depois do processo de secagem, a fim de apurar a quantidade de
água existente (linha 11). Os resultados encontrados nesse processo estão descritos na
tabela Quadro 11.
Figura 46 – Pote com solo e pote sendo saturado de água
Fonte: Autor
Quadro 11 – Resultado das pesagens das amostras

Massa
Massa lata (g) Massa
Massa lata (g) + Quantidade
Amostra + Solo solo seco
lata (g) Solo seco de água (g)
Saturado (g) (g)
(g)
1 34,13 304,95 204,74 170,61 100,21
2 37,95 301,63 203,53 165,58 98,1
3 35,29 294,26 199,15 163,86 95,11
Totais 107,37 900,84 607,42 500,05 293,42
Fonte: Autor
Com o resultado obtido, assumiu-se que o solo totalmente seco possui o peso de
500,05g e umidade de 0%. O solo totalmente úmido possui o peso de 793,47g, como
mostrado no Quadro 12. A Equação 4.6 foi utilizada para encontrar o percentual de
umidade, em que U é a umidade do solo, MSU a massa do solo úmido e MSS a massa do
solo seco.
(M SU − M SS)
U= (4.6)
(M SS)
Na sequência, foram separadas amostras de solo em 9 potes, com a mesma massa

de P9 (linha 13). Foi então feita uma distribuição de classes de acordo com os intervalos
de umidade calculados e cada um dos potes recebeu uma quantidade específica água (linha
15), conforme exibido no Quadro 12.
A quantidade de água adicionada em cada uma das amostras foi definida por
meio da Equação 4.7, em que QA é a quantidade de água, SA é o peso do solo saturado
Quadro 12 – Percentual de umidade esperado conforme volume de água existente

Pote Água (g) Solo seco (g) Solo com água (g) Umidade (%)
1 0,00 500,05 500,05 0
2 36,68 500,05 536,73 7
3 73,36 500,05 573,41 15
4 110,03 500,05 610,08 22
5 146,71 500,05 646,76 29
6 183,39 500,05 683,44 37
7 220,07 500,05 720,12 44
8 256,74 500,05 756,79 51
9 293,42 500,05 793,47 59
Fonte: Autor
(completamente cheio de água), SS é o peso do solo seco, N A é o número de amostras

existentes e pote a identificação da umidade de solo em ordem de seco ao saturado. O
número de amostras é decrescido de 1, pois a primeira amostra da distribuição não terá
adição de água (0% de umidade).
(SA − SS)
QApote = (pote − 1) (4.7)
NA − 1
Uma vez que todos os potes estavam preparados com uma amostra de solo de
umidade conhecida, os sensores foram colocados no solo, em ordem de 1 a 9 (linha 16). Os
potes foram tampados com papel alumínio e elásticos para evitar a perda de umidade (linha
17). Uma vez que todas as amostras estavam devidamente preparadas e com seus respectivos
sensores, iniciou-se o registro dos dados, conforme exibido na Figura 48. Realizou-se a
partir deste ponto um processo de permutação cíclica dos sensores nas amostras de solo
(linhas 19 a 23), a fim de que se obtivesse a leitura de cada um dos 9 sensores em cada uma
das 9 amostras disponíveis. Para cada etapa da permutação, foram realizadas 3 repetições
de coleta de dados. Um esquema gráfico da metodologia é apresentado na Figura 47.
A média dos resultados brutos obtidos por meio das leituras dos sensores está
descrita no Quadro 13. O valor bruto trata-se de um valor referenciado à tensão lida na
porta analógica, com base na resolução do conversor analógico/digital do datalogger, que
é de 10 bits (1023), conforme abordado na Subseção 3.1.2. Com esse valor de referência
torna-se possível, após o processo de calibração e regressão, chegar a uma estimativa
confiável do valor de umidade do solo.
Figura 47 – Esquema da calibração dos sensores de umidade sobre o processo cíclico e a

forma de como foi colocado os sensores nos potes.
Sensor
1 2 3 4 5 6 7 8 9
Dry Saturated
Sensor
Soil
Figura 48 – Sensores inseridos nas amostras de solo
Fonte: Autor
Uma vez finalizada a permutação, foram coletadas e pesadas três amostras de solo
de cada um dos potes (linhas 26 a 29). Essas amostras passaram por processo de secagem
na estufa a 105ºC e foram então pesadas novamente, a fim de possibilitar o cálculo da
umidade do solo.
Com a apuração da umidade realizada na linha 30 e com a massa de dados capturada
na linha 27, foi realizado o processo de regressão. Os resultados da análise de regressão são
apresentados na Tabela 36 e evidenciaram que todos os coeficientes foram significativos a
5%, com coeficientes de determinação (r2 ) todos acima de 0,85, o que representa um bom
desempenho dos sensores em relação à estabilidade das coletas. Foi adotada a hipótese
de que o tipo de solo e a temperatura causam pouca influênicia nas leituras, conforme
Quadro 13 – Média dos valores obtidos no processo descrito na etapa 11

Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor Sensor
Pote
1 2 3 4 5 6 7 8 9
1 445 473 454,5 465 468 467 454,5 478 474
2 418,5 448 423 429 429 431 422 448 436
3 386 432 405 421 420 410 408,5 429,5 421
4 304 350 326 352 400,5 366 371 374,5 341
5 312 338,5 294 324 302 317,5 310 374,5 387,5
6 273 326 278 305 304 282,5 291 332,5 303,5
7 264 299 264 297,5 283 272 265 302 279,5
8 251 273 252 259 269 259,5 261 274 263
9 250 269 254 261 269,5 259 255 273 266
Fonte: Autor
identificado por Radi et al. (2018). A visualização dos dados observados e ajustados por
meio desses coeficientes é apresentada na Figura 49. Vale destacar que os sensores 8 e
9, que apresentaram melhor desempenho nas métricas tendo menores índices de RMSE,
foram os que receberam o isolamento do circuito por meio da fita isolante líquida, padrão
que passou a ser adotado conforme descrito na Seção 4.2.1.
Tabela 36 – Coeficientes e métricas dos modelos ajustados aos 9 sensores de umidade do

solo.
Sensor U = aL + b
a b r 2
θ2 RMSE P-valor
1 -0,23 105,19 0,85 1914,85 7,29 1,23E-15
2 -0,26 120,32 0,95 701,14 4,41 4,46E-23
3 -0,24 108,50 0,90 1240,91 5,87 7,48E-19
4 -0,26 118,28 0,94 724,21 4,49 7,75E-23
5 -0,24 114,23 0,92 1172,06 5,71 2,83E-19
6 -0,24 112,78 0,94 777,04 4,65 2,57E-22
7 -0,25 114,51 0,95 679,68 4,35 2,63E-23
8 -0,26 125,31 0,99 281,18 2,79 7,89E-30
9 -0,28 102,64 0,97 389,21 3,29 1,93E-27
Os resultados encontrados por meio do processo de regressão comprovam que

os dados obtidos pelos sensores se comportaram linearmente e que o experimento e
metodologia adotados foram conduzidos de forma satisfatória.
Na seção seguinte são detalhadas quais foram as métricas adotadas para a avaliação
de desempenho e quais foram as análises de dados realizadas.
Figura 49 – Ajustes lineares da umidade do solo em função da leitura dos sensores

1 2 3
60
40
20
4 5 6
Umidade do solo (%)
60
40
20
7 8 9
60
40
20
200 300 400 500 200 300 400 500 200 300 400 500
Leitura dos sensores de umidade (V)
Observado Ajustado
Fonte: Autor
4.3 Avaliação de desempenho e análise de dados

De acordo com Leal (2020), a avaliação de desempenho de um sistema requer
métricas, técnicas e ambiente de medição. A seleção destes quesitos são passos essenciais
para todos os projetos de avaliação de desempenho.
As técnicas de avaliação de desempenho de um Sistema de Computação são
simulação, modelagem analítica e medição. A questão fundamental para decidir a técnica
de avaliação a ser utilizada é a fase do ciclo de vida do sistema. A execução de medições
só é possível se algo semelhante ao sistema proposto já existisse, como na concepção de
uma versão melhorada de um produto (LEAL, 2020).
Como o proposto nesse projeto foi a criação de um datalogger e apresentam-se
no Capítulo 2 alternativas similares já existentes, adotaram-se as técnicas previstas para
sistemas reais, que foram a elaboração de um protótipo (descrito na seção 4.1), a realização
de comparativos ou benchmarks e a coleta de dados.
O principal objetivo da análise de dados realizada foi estudar estatisticamente
a precisão da leitura de dados obtida pelo datalogger acadêmico desenvolvido, quando
comparado com um datalogger comercial. Para tanto, utilizando-se do simulador de Chang
(2021) e da estrutura de automação descrita na seção 4.2, os sensores nº 2, 4, 5 e 6 foram
conectados simultaneamente ao datalogger acadêmico e ao datalogger comercial DLight
4.3. Avaliação de desempenho e análise de dados 109
Logger, apresentado na seção 2.4. O DLight Logger foi escolhido para realização dos testes
pois foi o único que pôde ser disponibilizado em caráter de empréstimo. A escolha de
apenas 4 sensores para essa comparação se deu pela limitação da quantidade de portas
existentes no datalogger comercial.
O experimento realizado fez uso de 3 coberturas de resíduos da cultura de soja, de
0, 5 e 10 t ha−1 de massa seca sobre a amostra de solo e a 3% de declive. O objetivo foi
verificar a influência da cobertura no umedecimento do solo em 3 camadas de profundidade
(0-10 cm, 10-20 cm, e 20-30 cm), visto que a umidade no perfil representa o conteúdo de
água disponível para as plantas.
A coleta foi realizada em 3 períodos com o uso do simulador de chuvas, uma para
cada nível de cobertura e com duração de 20 minutos de aplicação do jato de água a
50 mca. Entre esses períodos, houve um intervalo de repouso de uma semana em que
foram utilizadas lâmpadas infravermelhas para acelerar a secagem do solo até que as
umidades inciais estivessem aproximadamente iguais. O esquema de secagem visualizado
na Figura 50 mostra o ângulo de visão da caixa de solo e o local em que estão embutidos
os sensores de umidade (??). A secagem foi monitorada diariamente via acesso remoto,
por meio do software anydesk, ao netbook conectado aos dataloggers.
Figura 50 – Lâmpadas infravermelhas para a secagem do solo entre um experimento do

outro.
Após as coletas, os arquivos de dados foram extraídos dos cartões SD de ambos os

dataloggers (acadêmico e comercial). Na sequência, foi escrito um roteiro em linguagem R
(contido no Apêndice D) para a manipulação desses dados. O intervalo de dados avaliado
foi o coletado durante o processo de simulação de chuva (20 minutos) e após a finalização
do processo (100 minutos), totalizando 120 minutos.
Para fins de comparação entre os 3 períodos de coleta, levando em consideração
o fato de ser metodologicamente complexo padronizar a umidade inicial para todos os
sensores, foi considerado o seu valor de incremento durante a chuva simulada, ou seja, o
quanto a umidade aumentou após iniciar a chuva. Para isso, toda a variável resposta foi
subtraída da umidade inicial observada, fazendo com que a umidade inicial seja igualada
a zero para todos os tratamentos.

Na Figura 51 são apresentados os valores lidos pelo sensor 4 na camada de 0-10
cm, a média das leituras dos sensores 2 e 5 na camada de 10-20 cm e os valores lidos pelo
sensor 6 na camada de 20-30 cm.
Figura 51 – Incremento de umidade para 3 camadas de solo durante e depois da aplicação
da chuva simulada em diferentes níveis de cobertura de palha de soja.
0-10 cm 10-20 cm 20-30 cm
15
Incremento de umidade (%)
10
0 25 50 75 100 125 0 25 50 75 100 125 0 25 50 75 100 125

Tempo (min)
Cobertura de palha (t ha−1) 0 5 10
Fonte: Autor
Para a comparação entre as leituras realizadas nos dataloggers acadêmico e comercial

(DLight Logger), foi calculada a média geral dos valores brutos, de 0 a 1023 (10 bits)
referenciados à tensão registrada na porta analógica, coletados no período avaliado. O
comparativo é apresentado na Figura 52.
Para este estudo foi utilizado o coeficiente de correlação linear de Pearson para a
comparação dos dataloggers. Esta ferramenta tem por objetivo medir o grau de correlação
entre duas variáveis, como utilizado também por Shicheng et al. (2021). O coeficiente pode
assumir valores de -1 a 1, sendo 1 a representação da correlação perfeita e positiva entre
duas variáveis e -1 a correção perfeita negativa, portanto, quanto mais próximo de 1 for
o valor de r, maior é a correlação. O cálculo da correlação entre duas variáveis X e Y é
mostrado na Equação 4.8:
XY −
P P P
n Y X
r=q P q P (4.8)
n X 2 − ( X)2 n Y 2 − ( Y )2
P P
Em que r é a correlação linear de Pearson, X e Y as variáveis a serem comparadas e n o

número de observações.
4.3. Avaliação de desempenho e análise de dados 111
O coeficiente de correlação de Pearson r resultou em 0,973, cuja ilustração está na

Figura 52, o que indica uma correlação muito forte entre as leituras dos dois dataloggers.
Figura 52 – Média das leituras do datalogger acadêmico e comercial para os sensores de

umidade.
245
Datalogger
Acadêmico
Profissional
240
Leitura do sensor
235
230
225 r = 0.973
0 25 50 75 100 125
Tempo (min)
Fonte: Autor
Também é possível notar visualmente na Figura 52 que o datalogger acadêmico

apresentou uma menor estabilidade em relação ao comercial. Pode-se atribuir como
possíveis causas dessa instabilidade a precisão dos componentes utilizados na conversão
analógico/digital e o algoritmo de filtragem dos dados.
Para a análise de variância desses resultados foi utilizado o delineamento inteira-
mente casualizado (DIC) e os tratamentos considerados foram as leituras entre os dois
tipos de dataloggers. A Tabela 37 apresenta os valores encontrados. Nota-se que o P-valor
foi acima de 0,05, comprovando que as leituras foram significativamente iguais.
Tabela 37 – ANOVA para comparação entre o datalogger acadêmico e comercial a 5% de

significância
Tratamentos 1 0,0191 0,0191 1,285877 0,271686

Resíduos 18 0,267361 0,014853
GL: graus de liberdade; SQ: soma dos quadrados; SQM: soma dos quadrados médios.
Fonte: Autor
Considerando-se todas as análises realizadas, foi possível concluir que o datalogger

acadêmico atendeu ao seu principal objetivo: a criação de uma solução de baixo custo para
aplicação em pesquisas ambientais. A solução se mostrou estável e confiável, possibilitando
a realização de toda a coleta de dados e análises descritas na Seção 4.2 sem a incidência
de falha e sem dificuldade de operação pelos pesquisadores envolvidos.
113
5 Conclusão
Neste trabalho foram avaliados os aspectos metodológicos e técnicos envolvidos no

projeto, construção, testes e avaliação de desempenho de um datalogger, contemplando
as camadas de hardware, firmware e software. Foi possível, por meio do levantamento
bibliográfico realizado, identificar a falta de embasamento metodológico das soluções
acadêmicas existentes, bem como o alto custo e a complexidade de operação envolvidos
nas soluções profissionais.
Utilizando conceitos da engenharia de software e do manifesto ágil, foi possível
realizar o levantamento de requisitos para cada uma das camadas de desenvolvimento —
hardware, firmware e softwares — que estão descritos no Capítulo 3, e que, após diversas
revisões junto aos stakeholders, resultaram em um documento detalhado, que balizou
o processo de desenvolvimento e que integra esse trabalho no Apêndice A. Finalizada
a fase de projeto, seguiu-se para a fase de execução, onde foi realizada a criação do
protótipo, cujas fases foram detalhadas no Capítulo 4. O custo final da solução foi de
aproximadamente US$ 192,35, atendendo a um dos principais objetivos do trabalho.
Para assegurar que as funcionalidades encontradas no levantamento de requisitos
haviam sido devidamente atendidas, foram elaborados e aplicados cenários de testes piloto,
que foram descritos na subseção 4.1.4. A partir da obtenção de resultados satisfatórios
nesses testes, foi realizado um estudo de caso utilizando o datalogger para a automatização
da coleta dos dados de um simulador de chuva construído por Chang (2021), que envolveu
nove sensores analógicos de umidade de solo, um sensor digital de vazão de água e um
sensor digital ultrassônico, utilizando diferentes recursos disponíveis no datalogger. Os
dados coletados durante esse estudo viabilizaram a realização de análises estatísticas, que
comprovaram o bom desempenho do protótipo criado, quando comparados às medições
empíricas e quando comparado a um datalogger comercial.
Na avaliação geral, é possível concluir que todos os objetivos propostos foram
atendidos, com destaque para a criteriosidade do detalhamento metodológico, o custo final
da solução e a precisão dos dados capturados, conforme detalhamento apresentado na
seção 4.3.
115
6 Trabalhos futuros
Durante os processos de desenvolvimento, validações, testes e aplicação do datalogger

desenvolvido, foi possível identificar alguns pontos de melhoramento para futuras versões.
O primeiro deles foi em relação ao invólucro e tamanho da PCB. Soluções de caixas
disponíveis no mercado, que comportem a quantidade de conectores existentes, poderiam
servir de base para adequação do tamanho da PCB, ou ainda, poderia ser realizada a
elaboração de um projeto de invólucro específico, com os respectivos suportes para fixação
internos (PCB) e externos (gabinete ou trilho).
Outro ponto relevante pode ser a substituição do módulo Arduino Mega 2560,
embutindo apenas seu microcontrolador (ATMEL ATMega2560) e demais componentes
diretamente no circuito da PCB. Essa troca possibilitaria a redução nos custos e ganho
de escala em produção industrial, como também facilitaria o processo de redução nas
dimensões e conexões do datalogger. Nesse mesmo quesito, é possível ainda avaliar outros
microcontroladores existentes, como o ESP8266 ou ESP32, que possuem mais recursos,
como módulo wifi integrado e memória interna.
Em relação ao firmware, o algoritmo de estabilização das leituras dos sensores
analógicos pode ser melhorado, a fim de evitar os desvios observados na Figura 52 da
seção 4.3.
Por fim, outros aspectos identificados estão relacionados aos softwares de configu-
ração e exibição dos dados. O software de configuração poderia ser embutido na solução,
em interface WEB, evitando eventuais dificuldades relacionadas à instalação ou mesmo à
operação nos diversos sistemas operacionais existentes. Já para o software de exibição, a
adição da possibilidade de filtrar períodos mais longos e de realizar análises estatísticas
mais aprofundadas facilitaria a interpretação dos dados.
117
Referências
ABDALLA, B. S. Desenvolvimento de Datalogger e Servidor de Banco de Dados via

Embarcados: um estudo de coleta de dados de transectos móveis georeferenciados. 56 p.
Dissertação (Mestrado) — Mestrado em Ciências Ambientais, 2015. Citado 6 vezes nas
páginas 19, 33, 36, 44, 48 e 233.
APACHE. The Apache HTTP Server Project. 2021. <https://httpd.apache.org/>.

(Accessed on 04/15/2021). Citado na página 84.
ARDUINO. Introduction. 2021. Disponível em: <https://www.arduino.cc/en/Guide/

Introduction>. Citado 2 vezes nas páginas 62 e 79.
ARDUINO. Mega 2560 Rev3. 2021. Disponível em: <https://store.arduino.cc/usa/

mega-2560-r3>. Citado na página 57.
AUTODESK. Eagle PCB Design. 2021. Disponível em: <https://www.autodesk.

com/products/eagle/overview?plc=F360&term=1-YEAR&support=ADVANCED&
quantity=1>. Citado na página 64.
BLUETERM. BlueTerm – Apps no Google Play. 2021. <https://play.google.com/store/

apps/details?id=es.pymasde.blueterm&hl=pt_BR&gl=US>. (Accessed on 05/21/2021).
Citado na página 49.
BRANDÃO, V. Infiltração da água no solo. [S.l.]: Viçosa: Editora UFV, 2006. Citado na
página 86.
C++. Documentação do C++ – introdução, tutoriais, referência. | Microsoft Docs.

2021. <https://docs.microsoft.com/pt-br/cpp/cpp/?view=msvc-160>. (Accessed on
04/15/2021). Citado na página 79.
CAMPBELL SCIENTIFIC. CR1000 Datalogger. [S.l.], 2013. Rev. 2/18. Citado 2 vezes
nas páginas 52 e 53.
CAPES. Portal .periodicos. CAPES - Portal .periodicos. CAPES. 2022. <https:

//www-periodicos-capes-gov-br.ezl.periodicos.capes.gov.br/index.php?> (Accessed on
02/20/2022). Citado na página 33.
CHANG, P. Modelagem matemática do escoamento superficial sob efeito da cobertura

vegetal. 110 p. Tese (Doutorado) — Programa de Pós Graduação em Engenharia de
Energia na Agricultura- Doutorado - UNIOESTE, 2021. Citado 7 vezes nas páginas 86,
87, 88, 89, 91, 108 e 113.
CLAESSEN, M. E. C. Manual de métodos de análise de solo. Embrapa Solos-Documentos

(INFOTECA-E), Rio de Janeiro: EMBRAPA-CNPS, 1997., 1997. Citado na página 103.
CUNHA, A. P. M. A. et al. Changes in the spatial–temporal patterns of droughts in the

brazilian northeast. Atmospheric Science Letters, v. 19, n. 10, p. e855, 2018. Disponível
em: <https://rmets.onlinelibrary.wiley.com/doi/abs/10.1002/asl.855>. Citado na página
27.
118 Referências
FILIPEFLOP. 2020. <https://www.filipeflop.com/>. (Accessed on 04/28/2020). Citado

4 vezes nas páginas 79, 88, 91 e 92.
GALDINO, D. R. d. O. et al. Uso do arduino para desenvolvimento de dataloggers de
baixo custo para monitoramento da precipitação em escala sub-horária. XXII Simpósio
Brasileiro de Recursos Hídricos, p. 1–9, 2019. Citado 6 vezes nas páginas 19, 34, 37, 44,
49 e 233.
GOOGLE. Google Acadêmico. 2022. <https://scholar.google.com.br/?hl=pt>. (Accessed
on 02/20/2022). Citado na página 33.
JAVA. O que é o Java? 2021. <https://www.java.com/pt-BR/about/whatis_java.jsp>.
JLCPCB. JLCPCB. 2020. Disponível em: <https://jlcpcb.com/>. Citado 2 vezes nas
páginas 77 e 79.
KARAMI, M.; MCMORROW, G. V.; WANG, L. Continuous monitoring of indoor
environmental quality using an arduinobased data acquisition system. Journal of Building
Engineering, v. 19, p. 412–419, 2018. Citado 6 vezes nas páginas 19, 34, 37, 38, 44 e 49.
LEAL, B. G. Avaliação de Desempenho de Sistemas. [S.l.]: Brauliro Gonçalves Leal, 2020.
LóPEZ-VARGAS, A. et al. Low-cost datalogger intended for remote monitoring of solar
photovoltaic standalone systems based on arduino™. IEEE Sensors Journal, v. 19, p.
4308–4320, 2018. Citado 10 vezes nas páginas 15, 16, 19, 35, 42, 43, 45, 47, 49 e 236.
MANIFESTO, A. Agile Manifesto. 2004. Disponível em: <http://agilemanifesto.org/>.
MANTECH. Mantech Electronics | YF-S201. 2021. <http://www.mantech.co.za/
datasheets/products/yf-s201_sea.pdf>. (Accessed on 08/09/2021). Citado 3 vezes nas
páginas 90, 93 e 94.
MARIADB. MariaDB. 2021. Disponível em: <https://mariadb.org/>. Citado na página
84.
MET ONE INSTRUMENTS, INC. MSO Weather Sensor. [S.l.], 2021. Rev. B. Citado na
página 85.
NESA SRL. Evolution Brochure. [S.l.], 2020. Citado 4 vezes nas páginas 45, 50, 51 e 52.
NETTO, G. T.; ARIGONY-NETO, J. Open-source automatic weather station and
electronic ablation station for measuring the impacts of climate change on glaciers.
HardwareX, v. 5, 2019. Citado 8 vezes nas páginas 16, 19, 34, 39, 40, 45, 49 e 234.
NINJAMOCK. NinjaMock online wireframe and mockup tool. 2021. <https:
//ninjamock.com/>. (Accessed on 04/17/2021). Citado na página 71.
NIST-GLOSSARY. firmware - Glossary | CSRC. 2021. <https://csrc.nist.gov/glossary/
term/firmware>. (Accessed on 05/24/2021). Citado 3 vezes nas páginas 35, 44 e 64.
ONSET. Data Logger Basics - Onset Computer. 2021. <http://https://www.onsetcomp.
com/files/data-logger-basics.pdf>. (Accessed on 05/24/2021). Citado na página 27.
Referências 119
PEREIRA, R. B. d. O. Implementação por sistemas embarcados de protótipo parametrizável

para coleta de dados microclimáticos georreferenciados. 157 p. Tese (Doutorado) —
Programa de Pós-Graduação em Física Ambiental da Universidade Federal de Mato
Grosso, 2013. Citado 10 vezes nas páginas 15, 16, 19, 34, 40, 41, 45, 46, 49 e 234.
PHP. PHP. 2021. Disponível em: <https://www.php.net/manual/pt_BR/intro-whatis.

php>. Citado na página 84.
PROESI. Proesi. 2020. <https://proesi.com.br/>. (Accessed on 06/04/2020). Citado na

página 79.
RADI et al. Calibration of capacitive soil moisture sensor (sku:sen0193). In: 2018 4th
International Conference on Science and Technology (ICST). [S.l.: s.n.], 2018. p. 1–6.
RASPBERRY. Raspberry Pi 3B+. 2021. Disponível em: <https://www.raspberrypi.org/

products/raspberry-pi-3-model-b-plus/>. Citado na página 63.
REGES, J. P. Desenvolvimento de um sistema de aquisição de dados para sistemas

fotovoltaicos. 118 p. Dissertação (Mestrado) — Mestrado em Energias Renováveis, 2017.
Citado 7 vezes nas páginas 16, 19, 35, 42, 44, 49 e 235.
RESEARCHGATE. Home Feed | ResearchGate. 2022. <https://www.researchgate.net/>.

RPROJECT. R: The R Project for Statistical Computing. 2021. <https://www.r-project.

org/>. (Accessed on 08/30/2021). Citado na página 100.
SANTOS, H. G. dos et al. Sistema brasileiro de classificação de solos. [S.l.]: Brasília, DF:
Embrapa, 2018., 2018. Citado na página 86.
SHICHENG, Q. et al. Nondestructive detection of decayed blueberry based on information

fusion of hyperspectral imaging (hsi) and low-field nuclear magnetic resonance (lf-nmr).
Computers and Electronics in Agriculture, Elsevier, v. 184, p. 106100, 2021. Citado na
página 110.
SOMMERVILLE, I. Engenharia de Software. [S.l.]: Pearson Prentice Hall, 2011. Citado 2

vezes nas páginas 74 e 75.
SPARKFUN. LogicLevels. 2021. Disponível em: <https://learn.sparkfun.com/tutorials/

logic-levels/all>. Citado na página 62.
STEVENS WATER. Manual for DLight Data Logger. [S.l.], 2013. Rev. 1. Citado 4 vezes
nas páginas 45, 53, 54 e 55.
SWITCHDOC. Benchmarks: RealTime Clocks – DS3231 / PCF8563 / MCP79400

/ DS1307. 2014. Disponível em: <https://www.switchdoc.com/2014/12/
benchmarks-realtime-clocks-ds3231-pcf8563-mcp79400-ds1307/>. Citado na
página 63.
VOLTTRON. About VOLTTRON™ | Volttron. 2021. <https://volttron.org/

about-volttron>. (Accessed on 05/21/2021). Citado na página 49.
Apêndices
123
APÊNDICE A – Documento de Requisitos

Documento de Requisitos
Título: Desenvolvimento de um datalogger configurável e de baixo custo para aplicação em
pesquisas ambientais
Equipe: Édipo Carneiro, Claudia Brandelero Rizzi, Rogério Luis Rizzi
Sumário
1. Introdução ..................................................................................................................................................... 1
2. O datalogger ................................................................................................................................................. 2
3. Stakeholders.................................................................................................................................................. 6
4. Conceitos ....................................................................................................................................................... 7
5. Caracterização dos Requisitos ...................................................................................................................... 9
6. Hardware....................................................................................................................................................... 9
6.1 Requisitos Funcionais de Hardware (RFH) ............................................................................................. 9
6.2. Diagramas de Hardware ...................................................................................................................... 12
6.3. Requisitos Não-Funcionais de Hardware (RNFH) ............................................................................... 15
7. Firmware ..................................................................................................................................................... 16
7.1 Requisitos Funcionais de Firmware (RFF) ............................................................................................ 16
7.2. Diagramas de Firmware....................................................................................................................... 18
7.3. Requisitos Não-Funcionais de Firmware (RNFF)................................................................................. 18
8. Software de configuração ........................................................................................................................... 20
8.1 Requisitos Funcionais de Software de Configuração (RFSC) ............................................................... 20
8.2. Requisitos Não-Funcionais de Software de Configuração (RNFSC) ................................................... 20
8.3 Protótipo não funcional do software de configuração........................................................................ 21
9. Software de exibição .................................................................................................................................. 25
9.1 Requisitos Funcionais de Software de Exibição (RFSE) ....................................................................... 25
9.2. Estrutura de Banco de Dados .............................................................................................................. 26
9.3. Protótipo não funcional do software de exibição .............................................................................. 26
9.4. Requisitos Não-Funcionais de Software de Exibição (RNFSE) ............................................................ 27
10. Casos de uso .............................................................................................................................................. 27
11. Validação dos Requisitos .......................................................................................................................... 31
12. Referências ................................................................................................................................................ 39
1. Introdução
Para a Tecnologia da Informação, dado é uma representação simbólica de atributos qualitativos ou
quantitativos relacionados com observações de eventos, fenômenos, sistemas, processos ou
estados de qualquer natureza. A Informação é a resultante do processamento dos dados que pode
empregar uma abordagem sistemática em que são realizadas sua coleta, armazenamento,
tratamento e análise. O processamento de dados providos de relevância e propósito é a base da
transformação digital que afeta os atuais paradigmas de geração de conhecimentos, produtos,
1
processos e negócios com impacto direto em aplicações que requerem integração e análise dos
dados coletados.
Essa situação se repete no caso específico de dados ambientais, indispensáveis para o
monitoramento de recursos hídricos, eólicos e solares, e na prevenção ou mitigação de desastres
naturais, entre outras aplicações. Essas ações dependem da coleta de dados, que podem requerer
observações contínuas ou durante longo período de tempo, e que se realizados manualmente
podem ter elevado custo de recursos humanos e baixa confiabilidade. A automação da atividade de
coleta de dados viabiliza eliminar esses problemas, padronizar sua organização, garantir sua coleta
em situações temporais contínuas e em condições ambientais adversas, além de tornar sua
transmissão mais eficiente e robusta.
Nesse sentido, este texto constitui o documento de requisitos cuja elaboração teve por objetivo
principal especificar os requisitos funcionais e não funcionais de um coletor de dados (datalogger),
que consiste em um sistema de hardware, firmware e software que registra automaticamente os
dados de interesse, sendo composto basicamente por microprocessadores, memória interna,
conexões para sensores e conexões de entrada e saída dos dados, além dos softwares de
configuração e interface. Trata-se de uma das atividades decorrentes de um trabalho vinculado ao
mestrado em Ciência da Computação da Universidade Estadual do Oeste do Paraná cujo objetivo
principal é desenvolver e analisar o uso de um protótipo de datalogger de baixo custo, configurável
e com ampla aplicabilidade na coleta e registro de dados ambientais.
Cabe dizer que Requisitos Funcionais são declarações de serviços que o sistema deve fornecer, de
como o sistema deve reagir a entradas específicas e de como o sistema deve se comportar em
determinadas situações. Em alguns casos, os requisitos funcionais também podem explicitar o que
o sistema não deve fazer (Sommerville, 2011). Requisitos Não-Funcionais, também chamados de
atributos de qualidade, são restrições aos serviços ou funções oferecidas pelo sistema. Incluem
restrições de tempo, de processo de desenvolvimento, de normas, etc. Em geral, aplicam-se ao
sistema como um todo (Sommerville, 2011).
Este documento está assim organizado. A Seção 2 apresenta uma visão geral do datalogger
proposto. A Seção 3 apresenta os stakeholders envolvidos na concepção do protótipo. A Seção 4
apresenta os conceitos chave utilizados no texto. A Seção 5 apresenta a caracterização de prioridade
dos requisitos. A Seção 6 apresenta os requisitos funcionais, não funcionais e diagramas de
Hardware do datalogger. A Seção 7 apresenta os requisitos funcionais, não funcionais e diagramas
relativos ao Firmware. A Seção 8 apresenta os requisitos funcionais, não funcionais e protótipo não
funcional do Software de Configuração. A Seção 9 apresenta os requisitos funcionais e o protótipo
não funcional do Software de Exibição, exclusivo para operação em laboratório. A Seção 10
apresenta os diagramas de casos de uso e a interação dos atores com o datalogger e softwares
criados. A Seção 11 apresenta as validações e testes realizados no protótipo durante e após sua
confecção. A Seção 12 apresenta a referência bibliográfica utilizada.
2. O datalogger
O datalogger consiste em um sistema que deve contar com hardware para leitura e registro dos
dados, firmware configurável, software para sua configuração e software para exibição dos dados
coletados. A Figura 1 ilustra sinteticamente a estrutura do protótipo.
2
Figura 1 - Ilustração sintética da estrutura do protótipo
Fonte: Autoria própria
Tendo como uma das principais motivações ser simples e funcional, o protótipo pretende ser
suficientemente embasado tecnicamente, com interface adequada ao usuário comum, pois o
desenvolvimento desse projeto visa viabilizar coletas de dados acessíveis, tanto em termos de custo
da solução, quanto pela facilidade de configuração e utilização. Por essas características, espera-se
ampliar as possibilidades de coleta e registro de dados de aspectos relevantes ou de potencial
interesse na gestão de dados ambientais, seja por pesquisadores, usuários não especializados ou
empresas que atuem em áreas correlatas.
O protótipo foi idealizado para abarcar dois tipos diferentes de operação, uso em campo ou uso em
laboratório. Dessa forma, foram propostos 2 softwares distintos, um para configuração do
equipamento e coleta dos dados em arquivo .TXT (modo campo) e um para exibição dos dados por
meio de acesso via ambiente web (modo laboratório).
O ambiente de campo exige o uso de equipamentos com menor consumo energético pois a maior
parte dos locais onde se faz necessária a coleta deste tipo de dados, em geral, não possui rede
elétrica e, portanto, deve-se fazer uso de energia proveniente de um conjunto de baterias e/ou
painéis solares. Para atender os requisitos desses cenários, o protótipo deve fazer uso apenas do
Arduino Mega 2560 para realização do processo de coleta dos dados. A escolha do Arduino Mega
2560 se deu devido ao seu baixo custo e fácil aquisição, à quantidade de portas analógicas
disponíveis (16) e também devido à quantidade de memória existente para execução das rotinas
internas.
Já para uso em ambiente de laboratório, é prevista a adição/conexão de um módulo Raspberry PI
para que os dados possam ser visualizados em tempo real à medida em que são coletados, seja em
um monitor, seja através da rede interna (acessando-se o endereço do equipamento). Essa
configuração do equipamento possui maior consumo de energia, portanto, deve ser alimentada
diretamente na rede de energia do local.
O diagrama da Figura 2 ilustra as camadas de software, firmware e hardware que compõem o
protótipo em ambos os cenários previstos, o de laboratório e o de campo. Cabe dizer que estas
camadas justificaram a opção de especificação neste documento de requisitos, de duas aplicações
distintas, denominadas Software de Configuração e Software de Exibição, melhor descritas ao longo
deste texto.
3
Figura 2 - Diagrama ilustrativo das camadas do protótipo
Mais detalhadamente, a Figura 3 mostrada a seguir ilustra a arquitetura geral do protótipo. Seu
objetivo é apresentar um modelo completo do sistema com seus diferentes componentes, suas
interfaces e conexões (Sommerville, 2011), envolvendo ambas as diferentes operações, em campo
ou em laboratório.
Figura 3 – Visão geral da arquitetura do protótipo

4
As Figuras 4 e 5 acrescentam um nível a mais de detalhamento da arquitetura, ilustrando as camadas
física e lógica do protótipo, respectivamente.
Figura 4 – Visão da camada física da arquitetura do protótipo

5
Figura 5 – Visão da camada lógica da arquitetura do protótipo
3. Stakeholders
Os seguintes stakeholders contribuíram, em diferentes fases e escopos, com a coleta, análise e
validação dos requisitos do sistema:
Prof. Dr. Deonir Secco, do Programa de Pós Graduação em Engenharia de Energia na Agricultura,
PPGEA-UNIOESTE. Atuou como idealizador e patrocinador do projeto do simulador de regimes de
chuva.
Pablo Chang, doutorando do Programa de Pós Graduação em Engenharia de Energia na Agricultura,
PPGEA-UNIOESTE. Atuou como idealizador e principal envolvido no levantamento de requisitos para
o projeto do simulador de regimes de chuva.
Prof. Dr. Rogério Luis Rizzi, do Programa de Pós-Graduação em Ciência da Computação, PPGCOMP-
UNIOESTE. Atuou como orientador desse projeto, participando ativamente no levantamento de
requisitos no que tange a dados científicos.
Prof. Dra. Claudia Brandelero Rizzi, do Programa de Pós-Graduação em Ciência da Computação,
PPGCOMP-UNIOESTE. Atuou como coorientadora desse projeto, participando ativamente na
elaboração do documento de requisitos e demais aspectos relativos à Engenharia de Software.
Leonardo Contini, técnico em mecatrônica, formado em Engenharia de Produção pela PUC-PR e
aluno de Tecnologia em Sistemas para Internet – UTFPR. Atuou como revisor do circuito impresso
criado nesse projeto e como principal envolvido no levantamento de requisitos para o projeto de
coleta de dados meteorológicos.
6
4. Conceitos
Esta seção apresenta os principais conceitos envolvidos neste projeto e neste documento de
requisitos organizados em ordem alfabética.
Arduino Mega 2560: O Arduino Mega 2560 é uma placa microcontrolada baseada no
microcontrolador ATmega2560. Possui 54 pinos de entrada / saída digital (dos quais 15 podem ser
usados como saídas PWM), 16 entradas analógicas, 4 UARTs (portas seriais de hardware), um
oscilador de cristal de 16 MHz, uma conexão USB, um conector de alimentação, um conector ICSP,
e um botão de reset.
Casos de uso: Casos de uso são uma técnica de descoberta de requisitos e, em geral, são
documentados por um diagrama de alto nível. O conjunto de casos de uso representa as possíveis
interações descritas nos requisitos. Ele identifica os atores envolvidos em uma interação com o
sistema (Sommerville, 2011).
Conversor TTL-RS485: Hardware que converte o nível lógico proveniente do protocolo RS485 em
nível de lógico do padrão TTL (Transistor Transistor Logic), que é o padrão de comunicação utilizado
pelo Arduino e Raspberry PI.
Dados Brutos: São dados em seu estado original ou RAW; significa que não passaram por nenhum
processamento. Os dados brutos estão associados e decorrem dos parâmetros de cálculo (ver
conceito de parâmetros de cálculo).
Diagrama esquemático do Circuito: É um diagrama que mostra os componentes e as interconexões
do circuito usando representações simbólicas padronizadas. A apresentação das interconexões
entre os componentes do circuito no diagrama esquemático não corresponde necessariamente aos
arranjos físicos no dispositivo acabado.
Geração de casos de teste: Tipo de verificabilidade que visa, por meio de diversos tipos de testes,
identificar problemas de requisitos. O desenvolvimento de testes a partir dos requisitos do usuário
antes de qualquer código escrito é parte integrante do Extreme Programming (Sommerville, 2011).
Parâmetro para Cálculo: São parâmetros definidos no momento da configuração dos dados a serem
processados. Por exemplo, supondo um sensor de temperatura analógico que esteja medindo 32
graus. O valor lido pelo datalogger será um número inteiro relativo ao nível de tensão ou da
intensidade da corrente elétrica que o sensor retornará naquele momento. No exemplo dos 32
graus, haveria um valor como 590, que após aplicados os devidos cálculos com base nas
características do sensor, apresentaria novamente os 32 graus. Esse valor de 590, seria considerado
o dado bruto ou “RAW data”.
Porta analógica: Uma entrada analógica é um sinal elétrico, mensurável, e definido numa gama de
valores. Esta entrada é gerada por um sensor e recebida por um controlador. A entrada analógica
varia continuamente de uma forma definida em relação à propriedade medida.
Porta digital contadora de pulso: Uma entrada digital possui a capacidade de atuar com variáveis
discretas digitais (dois dígitos '0' ou '1'). Pode atuar de forma como entrada, para que interprete se
o nível de sinal está alto (1) ou baixo (0), ou como saída, para que ao produzir um sinal alto (1) possa
acionar um relé, ou ao produzir um nível baixo (0), possa desligá-lo, por exemplo. A porta contadora
do pulso contabilizará por quantas vezes houve uma alteração no sinal (de 1 para 0 ou de 0 para 1).
Protocolo I2C: Inter-Integrated Circuit (I2C) é um barramento serial desenvolvido pela Philips que é
usado para conectar periféricos de baixa velocidade a uma placa mãe, ou a um sistema embarcado.
É implementado apenas com duas linhas: SDA – Serial Data e SCL – Serial Clock.
7
Prototipação: Tipo de verificabilidade que visa, por meio da apresentação aos stakeholders de
modelos do sistema, executáveis ou não, verificar se ele efetivamente atende as demandas
identificadas (Sommerville, 2011).
Raspberry PI: O Raspberry PI é um computador de baixo custo, do tamanho de um cartão de crédito.
Possui a capacidade de rodar distribuições Linux embarcadas, o que facilita a utilização de diversos
softwares e sua aplicação nos mais diversos tipos de solução.
Revisões de requisitos: Tipo de verificabilidade que visa analisar o documento de requisitos
sistematicamente por uma equipe de revisores objetivando identificar erros e inconsistências
(Sommerville, 2011).
Sensor I2C: O protocolo I2C descreve o funcionamento de um barramento de comunicação serial
que utiliza apenas dois fios. Inventado pela Philips no início da década de 90, este protocolo é muito
utilizado para conectar periféricos de baixa velocidade a placas mãe, micro controladores e afins.
Vários sensores de baixo custo, voltados a operação com Arduino e Raspberry, fazem uso desse
protocolo.
Sensor RS485: RS485 é uma interface de comunicação operando em linhas diferenciais capaz de se
comunicar com 32 “unidades de carga”. Normalmente, um dispositivo transmissor/receptor
corresponde a uma “unidade de carga”, o que faz com que seja possível comunicar com até 32
dispositivos. Alguns sensores ambientais, principalmente os que trabalham com a leitura de mais
de uma grandeza, fazem uso desse protocolo de comunicação.
Stakeholders: Qualquer indivíduo ou organização que, de alguma forma, é impactado pelas ações
de uma determinada empresa. Em uma tradução livre para o português, o termo significa parte
interessada ou envolvidos no projeto.
Verificabilidade: Visa identificar se os requisitos podem ser verificados no sentido de que o sistema
atende a cada requisito especificado. A verificabilidade envolve processos de revisões de requisitos,
prototipação e geração de casos de testes (Sommerville, 2011).
Verificação de completude: Visa identificar se todas as funções necessárias para os stakeholders
foram efetivamente listadas. O documento de requisitos deve incluir requisitos que definam todas
as funções e as restrições pretendidas pelo usuário do sistema (Sommerville, 2011).
Verificação de consistência: Visa identificar se há conflitos entre os requisitos já listados, ou seja,
não deve haver restrições contraditórias ou descrições diferentes da mesma função do sistema
Verificação de realismo: Visa identificar se os requisitos podem ser implementados com a
tecnologia e orçamento disponíveis. Usando o conhecimento das tecnologias existentes, os
requisitos devem ser verificados para assegurar que realmente podem ser implementados
Verificação de validade: Visa responder se o sistema fornece as funções que melhor atendem as
necessidades do usuário. No entanto, como o sistema tem diferentes stakeholders com diferentes
necessidades, a validade precisa considerar esses diferentes tipos de demandas e expectativas
Watchdog timer: É uma função ou dispositivo eletrônico temporizador que dispara um reset ao
sistema se o programa principal, devido a alguma condição de erro, deixar de funcionar.
8
5. Caracterização dos Requisitos
Na próxima seção são listados os requisitos do sistema. Cada requisito tem um identificador
único, uma descrição, um nível de prioridade e sua dependência. Quanto ao nível de prioridade,
adotou-se o seguinte padrão:
Alta: Os requisitos marcados com essa prioridade são obrigatórios.
Média: Os requisitos marcados com essa prioridade são desejados, mas não obrigatórios,
significando que o sistema pode operar sem eles, mas com alterações.
Baixa: Os requisitos marcados com essa prioridade são desejados, mas o sistema pode
operar sem eles sem grandes alterações.
Quanto à dependência, menciona-se após o uso deste termo, o identificador do(s) requisito(s) que
está(ão) a ele relacionado(s) em termos de dependência.
6. Hardware
6.1 Requisitos Funcionais de Hardware (RFH)
RFH-01: Hardware principal
Descrição: O equipamento deve possuir um hardware com conectores de ligação para acoplamento
de um Arduino Mega 2560, um Raspberry PI 3B+, um módulo de relógio, um módulo conversor TTL-
RS485 e demais componentes necessários ao seu funcionamento.
Prioridade: Alta.
Dependência: Não há.
RFH-02: Sistema de obtenção de data e hora
Descrição: O equipamento deve possuir um módulo relógio de tempo real (RTC - Real Time Clock)
para controle de data e hora. Esse relógio servirá de base tanto para o intervalo e período de coleta,
quanto para marcação no arquivo de registro dos dados.
Prioridade: Alta.
Dependência: RFH-01.
RFH-03: Sistema de Armazenamento de dados
Descrição: O equipamento deve possuir em seu hardware principal os componentes necessários
para que seja possível realizar o armazenamento de dados em um dispositivo de memória não
volátil (pen drive ou cartão SD), de forma que possam ser recuperados a qualquer momento pelo
usuário.
Prioridade: Alta.
RFH-04: Portas analógicas de leitura
Descrição: O equipamento deve possuir a capacidade de capturar leituras de até 16 sensores
analógicos com sinais de 4-20mA ou 0-5V. As leituras podem ser capturadas de forma individual ou
sequencial.
Prioridade: Alta.
9
RFH-05: Portas digitais para contagem de pulso
Descrição: O equipamento deve possuir a capacidade de capturar leituras de até 2 sensores de
efeito hall, realizando a contagem dos pulsos. As leituras podem ser capturadas de forma individual
ou sequencial.
Prioridade: Alta.
RFH-06: Portas digitais adicionais
Descrição: O equipamento deve possuir a capacidade de capturar leituras de até 5 sensores digitais.
As leituras podem ser capturadas de forma individual ou sequencial. Nem todos os sensores serão
implementados e, portanto, compatíveis com o firmware padrão, dada a necessidade de utilização
de bibliotecas específicas. A depender da aplicação e sensor a ser utilizado, o firmware padrão terá
de ser adaptado ou personalizado.
Prioridade: Baixa.
RFH-07: Portas I2C
Descrição: O equipamento deve possibilitar a ligação de sensores que façam uso do protocolo I2C.
Nem todos os sensores serão implementados e, portanto, compatíveis com o firmware padrão,
dada a necessidade de utilização de bibliotecas específicas. A depender da aplicação e sensor a ser
utilizado, o firmware padrão terá de ser adaptado ou personalizado.
Prioridade: Baixa.
RFH-08: Porta RS485
Descrição: O equipamento deve possibilitar a ligação de sensores que façam uso do protocolo
RS485.
Prioridade: Baixa.
RFH-09: Saídas de comunicação RS232 ou RS485
Descrição: O equipamento deve possuir saídas de comunicação em padrão RS232 e RS485, para
intercomunicação com outros equipamentos.
Prioridade: Média.
RFH-10: Alimentação
Descrição: O equipamento deve ser alimentado por corrente contínua (CC). O sistema pode ser
alimentado por meio de uma fonte (ligada à tomada) ou então por meio de bateria, controlador de
carga e painel solar.
Prioridade: Alta.
RFH-11: Microcomputador para exibição dos dados
10
Descrição: O equipamento deve possuir a capacidade de suportar a adição de um microcomputador
Raspberry PI 3 B+, para prover ambiente Web para receber e exibir informações em tempo real.
Prioridade: Baixa.
As Figuras 6 e 7 apresentam o diagrama esquemático do circuito. Nelas, estão descritos todos os
componentes utilizados, empregando uma simbologia padronizada, bem como suas respectivas
ligações.
A Figura 8 apresenta o layout final do circuito impresso, com o posicionamento dos componentes e
respectivas trilhas de ligação.
As Figuras 9 e 10 apresentam a placa em seu estado atual, a qual é utilizada para realização dos
testes e validações.
11
6.2. Diagramas de Hardware

12
13
Figura 8 – Layout da placa de circuito impresso
/
Figura 9 – Protótipo montado (parte superior)
14
Figura 10 – Protótipo montado (parte inferior)
6.3. Requisitos Não-Funcionais de Hardware (RNFH)

RNFH-01: Facilidade de uso
Descrição: O equipamento deve apresentar conectores/bornes devidamente identificados e
posicionados de forma a facilitar as ligações, sejam elas de alimentação, sensores ou saída de dados.
Prioridade: Alta.
RNFH-02: Precisão
Descrição: O equipamento deve apresentar precisão em suas leituras. A precisão esperada para
contagem de pulsos é de 100%, mediante uso de filtros. Para as portas analógicas, espera-se uma
precisão/resolução de 10bits.
Prioridade: Alta.
RNFH-03: Precisão de data
Descrição: O equipamento deve possuir módulo de relógio (RTC) de alta precisão, com variação de
no máximo +- 3 minutos por ano.
Prioridade: Alta.
RNFH-04: Confiabilidade
15
Descrição: O equipamento deve possuir componentes eletrônicos de alta qualidade, a fim de
garantir seu funcionamento por um período mínimo de 1 ano, sem necessidade de manutenção.
Prioridade: Alta.
RNFH-05: Desempenho
Descrição: O equipamento deve ser capaz de identificar as configurações pré-definidas e realizar
sua inicialização de forma automática, sem qualquer tipo de intervenção. Após a inicialização, deve
realizar todas as leituras necessárias e então entrar em estado de stand-by até o próximo intervalo
esperado.
Prioridade: Alta.
RNFH-06: Espaço
Descrição: O equipamento deve ser capaz de suportar cartões de memória de até 32G e de
armazenar dados de todos os sensores por um período mínimo de 365 dias. Caso atinja o espaço
máximo, o equipamento deve descartar os arquivos mais antigos para possibilitar a gravação dos
mais novos.
Prioridade: Alta.
RNFH-07: Custo
Descrição: O equipamento deve ser de baixo custo, não excedendo os R$ 1.100,00.
Prioridade: Alta.
RNFH-08: Consumo de energia
Descrição: O equipamento, quando em ambiente de campo, deve possuir baixo consumo de
energia, sendo de no máximo de 75mA/h.
Prioridade: Média.
7. Firmware
7.1 Requisitos Funcionais de Firmware (RFF)
RFF-01: Comunicação Serial
Descrição: O firmware deve ser capaz de iniciar as portas de comunicação serial existentes no
hardware.
Prioridade: Alta.
RFF-02: Relógio de tempo real (RTC)
Descrição: O firmware deve ser capaz de iniciar o módulo RTC existente no hardware, buscando
data e hora atual com base na sua última sincronização. Caso algum problema ocorra nesse
16
processo, uma mensagem de erro deve ser lançada na interface serial RS232 e o processo deve ser
interrompido.
Prioridade: Alta.
Dependência: RFF-01.
RFF-03: Cartão de memória
Descrição: O firmware deve ser capaz de iniciar o cartão de memória. Caso algum problema ocorra
nesse processo, uma mensagem de erro deve ser lançada na interface serial RS232 e o processo
deve ser interrompido.
Prioridade: Alta.
RFF-04: Arquivo de configuração
Descrição: O firmware deve ser capaz de localizar o arquivo de configuração e extrair todos os
parâmetros necessários ao seu funcionamento. Caso algum problema ocorra nesse processo, uma
mensagem de erro deve ser lançada na interface serial RS232 e o processo deve ser interrompido.
Prioridade: Alta.
Dependência: RFF-01 e RFF-03.
RFF-05: Watchdog
Descrição: O firmware deve ser capaz de inicializar o processo de Watchdog timer, definindo o
tempo de checagem e o processo de reset em caso de falha.
Prioridade: Alta.
RFF-06: Sincronização
Descrição: O firmware, deve checar, em ciclo de segundo, se o horário condiz com o intervalo
configurado. Em caso afirmativo, deve chamar o processo para coleta dos dados. Caso contrário,
deve aguardar para que o momento seja o esperado.
Prioridade: Alta.
RFF-07: Coleta
Descrição: O firmware deve ser capaz de coletar as informações dos diversos sensores configurados,
tanto analógicos quanto digitais, em seu intervalo previamente determinado e acionar o processo
de armazenamento. Durante o processo de coleta, serão realizados também os cálculos necessários,
conforme configuração, para tornar o dado coletado interpretável ao usuário final.
Prioridade: Alta.
Dependência: RFF-03 e RFF-04.
RFF-08: Armazenamento
Descrição: O firmware deve ser capaz de armazenar as informações coletadas em arquivos no cartão
de memória.
Prioridade: Alta.
17
Dependência: RFF-02, RFF-03 e RFF-04.
RFF-09: Envio dos dados em tempo real
Descrição: O firmware deve ser capaz de enviar os dados coletados, se assim configurado, para as
portas de comunicação RS232 e/ou RS485. O dado será enviado conforme padrão de
armazenamento, sendo: data e hora da coleta, identificação do sensor, valor bruto, valor
interpretável pelo usuário. Essa funcionalidade permite a visualização em tempo real dos dados
coletados, evitando assim a retirada frequente do cartão SD e facilitando o acesso às informações
pelo usuário, seja por interface gráfica ou por visualização textual em um software de terminal
RS232.
Exemplo dos dados enviados pela RS232: DT=01/03/2021 23:0:0;D1=0;D2=0;A1-UMIDADE=987;
Prioridade: Média.
Dependência: RFF-01, RFF-02, RFF-03 e RFF-04.
7.2. Diagramas de Firmware

O diagrama mostrado na Figura 11 ilustra o processo geral realizado pelo firmware no contexto do
funcionamento do datalogger.
Figura 11 – Diagrama de funcionamento do Firmware

7.3. Requisitos Não-Funcionais de Firmware (RNFF)

RNFF-01: Confiabilidade
Descrição: O firmware deve realizar todos os processos pré-determinados dentro da janela de
tempo prevista. Em caso de qualquer falha na coleta, armazenamento ou envio, considerando ser
18
esta uma falha grave ao objetivo principal do equipamento, ele será automaticamente reiniciado
para que possa voltar ao seu estado padrão.
Prioridade: Alta.
RNFF-02: Tamanho
Descrição: O firmware deve possuir tamanho máximo de 253.932 bytes, limite da plataforma do
Arduino Mega 2560, considerando todas suas linhas de código e bibliotecas necessárias ao seu
funcionamento.
Prioridade: Alta.
RNFF-03: Tipos de arquivo
Descrição: O processo de armazenamento deverá registrar dois arquivos com dados em formatos
distintos, o primeiro em formato “.RAW” e o segundo em formato “.CSV”.
O primeiro, registrará a data e hora, a identificação do sensor e seus respectivos valores, tanto
brutos (leitura sem aplicação de cálculo), quanto em formato interpretável ao usuário (após
aplicação dos cálculos previamente configurados). Deve ser criado um arquivo por dia e seu nome
deve ser composto pela data em formato “ddmmaaaa”. Esse arquivo deverá estar dentro de uma
pasta com a identificação do equipamento.
Exemplo de nome da pasta: EQUIP1.
Exemplo de nome de arquivo: 01122020.RAW.
Exemplo do caminho completo do arquivo: /EQUIP1/01122020.RAW.
Exemplo dos dados registrados no arquivo RAW: DT=01/03/2020 23:0:0;D2=0;A1-UMIDADE=987;

O segundo arquivo, registrará a data, a hora e os valores dos sensores (após a aplicação dos cálculos
previamente configurados). Deve ser criado um arquivo por dia e seu nome deve ser composto pela
data em formato “ddmmaaaa”. Esse arquivo deverá estar dentro de uma pasta com a identificação
do equipamento e deve conter um cabeçalho identificando a ordem dos dados coletados.
Exemplo de nome de arquivo: 01122020.CSV.
Exemplo do caminho completo do arquivo: /EQUIP1/01122020.CSV.
Exemplo dos dados registrados no arquivo .CSV: data;hora;digital1;digital2;analogico1;analogico2;

01/03/2020;23:0:0;0;0;1.10;1.20;20;...
No firmware padrão, os dados provenientes da porta RS485 serão gravados em um arquivo

adicional, com extensão “.RS485”, dentro de uma pasta gerada com o nome do datalogger.
Exemplo de nome de arquivo: 01122020.RS485.
19
Exemplo do caminho completo do arquivo: /EQUIP1/01122020.RS485.
Para leitura e gravação dos dados de forma específica, o firmware terá de ser adaptado ou
personalizado.
Prioridade: Alta.
8. Software de configuração
8.1 Requisitos Funcionais de Software de Configuração (RFSC)
RFSC-01: Interface para configuração
Descrição: O sistema deve possuir campos para configuração de todas as suas funcionalidades,
sendo: nome da estação (limitado a 8 caracteres, sem acentos ou caracteres especiais), intervalo de
coleta, intervalo de transmissão, 16 portas analógicas (com seus respectivos parâmetros para
cálculo, necessários para se chegar à grandeza desejada) e 2 portas digitais contadoras de pulso.
Prioridade: Média.
RFSC-02: Sincronizar RTC
Descrição: O sistema deve disponibilizar uma função para ajustar o horário do equipamento de
acordo com o horário do computador. Essa funcionalidade deverá ser executada no primeiro uso
ou caso permaneça por longo período fora de operação.
Prioridade: Alta.
RFSC-03: Criar arquivo de configuração
Descrição: O sistema deve estar apto a criar um arquivo em formato “.TXT”, contendo todas as
configurações realizadas na interface gráfica. Esse arquivo deverá ser copiado para cartão SD que
será utilizado pelo equipamento.
Prioridade: Média.
RFSC-04: Envio de aplicações (firmwares)
Descrição: O sistema deve estar apto a realizar o envio de aplicações (firmwares) ao equipamento.
O envio será feito por meio de uma porta de comunicação que deve ser selecionada antes do envio.
As aplicações disponíveis devem ser: teste de funcionamento (que exibirá os dados de segundo em
segundo), aplicação de produção (que realizará a coleta e envio de acordo com o configurado) e
atualização de horário (que deverá ser utilizada na primeira utilização do equipamento ou após ter
ficado sem utilização durante períodos maiores que uma semana).
Prioridade: Alta.
8.2. Requisitos Não-Funcionais de Software de Configuração (RNFSC)

RNFSC-01: Tela de informação
20
Descrição: O sistema deve dispor de uma tela de informação, onde são descritas as motivações do
projeto.
Prioridade: Baixa.
RNFSC-02: Ajuda
Descrição: O sistema deve dispor da função de ajuda, que irá abrir um arquivo .PDF para auxiliar o
usuário a configurar de forma correta o equipamento.
Prioridade: Baixa.
RNFSC-03: Manual de instalação do ambiente
Descrição: O sistema deve dispor de um manual de instalação, que irá abrir um arquivo .PDF para
auxiliar o usuário a instalar o ambiente de visualização do datalogger.
Prioridade: Baixa.
RNFSC-04: Multiplataforma
Descrição: O sistema de configuração deve estar apto a executar em plataformas Linux e Windows.
Prioridade: Média.
RFSC-05: Barra de Progresso
Descrição: Componente da interface que visa apresentar o progresso das tarefas da aba
“Aplicações”: teste de funcionamento e aplicação de produção.
Prioridade: Baixa.
8.3 Protótipo não funcional do software de configuração

As figuras apresentadas a seguir ilustram o protótipo não funcional do sistema proposto. Ele está
dividido em quatro possibilidades (abas) distintas: “Sobre”, “Configurações”, “Aplicações” e “Dados
em Tempo Real”. Cada uma delas é apresentada a seguir.
A Figura 12, identificando a opção “Sobre”, apresenta informações sobre o sistema proposto. Nessa
figura também é possível identificar a existência de dois botões. O botão “Manual de instalação”
realiza a abertura do manual de instalação do ambiente de visualização dos dados, que contém o
passo a passo a ser realizado para utilização do protótipo em ambiente de laboratório. O botão
“Ajuda” exibe o manual do sistema de configuração, com a descrição de todos os campos existentes
no sistema e qual sua relação com o funcionamento do firmware.
21
Figura 12 – Tela inicial do configurador com informações sobre o projeto
A Figura 13, identificando a opção “Configurações” viabiliza realizar as configurações para o

datalogger. O campo “Nome” serve para identificar o datalogger, o campo “Intervalo de Coleta e
Transmissão” determina de quantos em quantos minutos o datalogger realizará a gravação dos
dados em memória interna, o campo “Porta de saída de dados “determina para quais portas de
saída os dados deverão ser enviados. As caixas de seleção “Porta Digital 1” e “Porta Digital 2”
permitem que seja ou não habilitado o registro das informações dos sensores conectados às
respectivas portas físicas do datalogger.
As abas de A1 a A16, permitem que sejam configuradas as portas analógicas existentes no
datalogger. As configurações possíveis são a habilitação ou não da coleta, quais os valores do
intervalo inicial/final da leitura realizada pelo sensor (também chamada de range) e o valor a ser
somado ou subtraído da leitura realizada pelo sensor (também chamado de offset).
22
Figura 13 – Tela de configurações do datalogger e dos sensores existentes
A Figura 14 ilustra um exemplo da tela de confirmação que é exibida ao clicar no botão “Gerar
arquivo de configuração”. Essa tela apresenta um resumo dos campos que foram preenchidos
anteriormente.
Figura 14 – Mensagem de confirmação das configurações

A Figura 15, identificando a opção “Aplicações” possibilita o envio das aplicações/firmwares ao

equipamento. As opções existentes são:
23
“Testar funcionamento”: realizará a coleta de informações de segundo em segundo, conforme
configurações previamente realizadas, e trará essas informações coletadas na aba “Dados em
Tempo Real” para que possam ser avaliadas e eventualmente corrigidas.
“Enviar aplicação de produção”: entrará em modo de “produção”, que significa que realizará as
coletas e envios de acordo com as configurações previamente realizadas.
“Sincronizar horário”: função para atualizar o relógio interno do equipamento. Necessária durante
a primeira utilização do equipamento ou após períodos maiores do que 7 dias sem utilização
(desligado).
Figura 15 – Tela de envio de aplicações ao datalogger

A Figura 16, identificando a opção “Dados em Tempo Real” possibilita a visualização, de forma
gráfica, dos dados que estão sendo coletados e registrados pelo datalogger. O campo “Console”
apresenta toda a troca de informação que estiver ocorrendo pela porta USB do equipamento.
24
Figura 16 – Tela de acompanhamento dos dados
9. Software de exibição
9.1 Requisitos Funcionais de Software de Exibição (RFSE)
RFSE-01: Consulta de dados
Descrição: O sistema deve possibilitar a visualização dos dados dos sensores em um determinado
intervalo de tempo. Os dados devem ser exibidos por meio de gráfico e por meio de uma tabela.
Prioridade: Alta.
RFSE-02: Exportação dos dados
Descrição: O sistema deve possibilitar a exportação dos dados em formato .CSV para utilização em
outras plataformas, como Excel e R.
Prioridade: Média.
RFSE-03: Suporte à visualização, em tempo real dos dados
Descrição: O sistema deve disponibilizar uma página web em que seja possível visualizar os dados
que estão sendo recebidos em tempo real. O objetivo dessa tela é, em casos de pesquisas em
laboratório, prover um monitor que exiba ao pesquisador os dados, pré-processados, conforme eles
são coletados, sem necessidade da retirada do cartão. Esta facilidade visa apresentar ao
pesquisador uma ferramenta de avaliação dos dados que estão sendo registrados, bem como a
exportação desses dados sem a necessidade de estar fisicamente no local.
Prioridade: Alta.
25
9.2. Estrutura de Banco de Dados
O quadro 1 lista os campos constantes na tabela de banco de dados criada para o armazenamento
dos dados coletados pelo datalogger. O banco de dados utilizado é o MySQL/MariaDB.
Quadro 1: Estrutura da tabela do banco de dados utilizada para armazenamento dos dados
coletados
NOME DO CAMPO TIPO DE DADO
Id INTEGER
Data TIMESTAMP
SensorNome VARCHAR
Valor DOUBLE
9.3. Protótipo não funcional do software de exibição

A Figura 17, mostra a tela principal do software de exibição dos dados provenientes do datalogger.
Esse software, que será acessado por meio do browser, possibilitará a seleção da data para exibição
dos dados coletados de todos os sensores. Os dados selecionados serão exibidos por meio de gráfico
e em formato de tabela.
Figura 17 – Modelo da tela do software de exibição dos dados

26
9.4. Requisitos Não-Funcionais de Software de Exibição (RNFSE)
RNFSE-01: Tela de ajuda
Descrição: O sistema deve dispor da função de ajuda, identificada na parte superior por um ícone,
para auxiliar o usuário a configurar de forma correta o equipamento.
Prioridade: Baixa.
RNFSE-02: Ambiente
Descrição: O sistema deve rodar sob plataforma Apache + PHP, embarcada num Raspberry PI que
possua Linux embarcado, preferencialmente rodando a distribuição Raspbian.
Prioridade: Alta.
RNFSE-03: Restrições lógicas de base de dados
Descrição: O acesso ao servidor será limitado à velocidade da rede local.
Prioridade: Baixa.
RNFSE-04: Restrições de projeto
Descrição: O software utilizado na implementação do sistema deverá ser livre.
Prioridade: Baixa.
RNFSE-05: Acesso
Descrição: Optou-se por não realizar controle de acesso (usuário/senha) ou criptografia dos
dados, visto que se entendeu que os dados coletados não requerem cuidados quanto a sigilo.
Prioridade: Baixa.
10. Casos de uso

Esta seção apresenta os casos de uso do datalogger. A Figura 18 apresenta o diagrama de casos de uso do
funcionamento geral do datalogger, considerando os dois possíveis atores envolvidos no processo, o
pesquisador de campo e o de laboratório. O quadro 2 sintetiza os casos de uso identificados.
27
Figura 18 – Diagrama de casos de uso do datalogger
Quadro 2: Identificação dos casos de uso

ID DESCRIÇÃO
UC01 Gerar arquivo de configuração do equipamento
UC02 Enviar aplicação ao equipamento
UC03 Visualizar dados coletados em tempo real
UC04 Acessar dados coletados em .CSV
UC05 Visualizar dados em interface WEB
Os quadros abaixo detalham os casos de uso identificados e individualizados no quadro 2.
Quadro 3: UC01 – Gerar arquivo de configuração do equipamento

ID [UC01]
Descrição Gerar arquivo de configuração do equipamento.
Atores PC e PL
28
Pré-condições PC ou PL abrem o sistema e clicam na aba “configurações“.
Pós-condições PC ou PL preenchem os campos disponíveis na aba e clicam no botão “gerar
arquivo de configurações”.
Fluxo Principal 1 – PC ou PL abrem o sistema.
2 – PC ou PL clicam sobre a aba “configurações”.
3 – PC ou PL preenchem os campos de acordo com suas necessidades.
4 – PC ou PL clicam no botão “gerar arquivo de configuração”.
5 – PC ou PL escolhem o local onde será salvo o arquivo de configuração.
6 – PC ou PL copiam o arquivo gerado para o cartão SD do equipamento.
Fluxo Secundário Se algum campo obrigatório não tiver sido preenchido, o sistema alertará o
usuário para que o preencha.
Quadro 4: UC02 – Enviar aplicação ao equipamento

ID [UC02]
Descrição Enviar aplicação ao equipamento.
Atores PC e PL
Pré-condições PC ou PL, após terem gerado o arquivo de configurações e copiado o mesmo
para o cartão, clicam na aba “aplicações”.
Pós-condições PC ou PL escolhem a aplicação/firmware a ser enviada para o equipamento.
2 – PC ou PL clicam sobre a aba “aplicações”.
3 – PC ou PL indicam a porta de comunicação na qual o equipamento está
conectado.
4 – PC ou PL escolhem a aplicação a ser enviada.
Fluxo Secundário Se houver um erro no envio da aplicação, o sistema alertará o usuário.
Quadro 5: UC03 – Visualizar dados coletados em tempo real

ID [UC03]
Descrição Visualizar dados coletados em tempo real.
Atores PC e PL
Pré-condições PC ou PL abrem o sistema e clicam na aba “dados em tempo real”. Para
visualizar os dados é necessário que o equipamento esteja devidamente
conectado e que a aplicação de teste ou a aplicação de produção tenham
sido enviadas.
Pós-condições PC ou PL irão visualizar nos devidos campos as informações coletadas.
29
2 – PC ou PL clicam sobre a aba “aplicações”.
3 – PC ou PL indicam a porta de comunicação na qual o equipamento está
conectado.
4 – PC ou PL certificam-se que a aplicação que está rodando é a aplicação de
teste ou de produção.
5 – PC ou PL clicam sobre a aba “dados em tempo real”.
6 – PC ou PL conseguem verificar, de acordo com o intervalo de tempo
previamente programado, os dados que estão sendo capturados.
Fluxo Secundário Se a aplicação de teste ou produção não tiver sido enviada, nenhum dado
será exibido.
Quadro 6: UC04 – Acessar dados coletados em .CSV

ID [UC04]
Descrição Acessar dados coletados em .CSV.
Atores PC e PL
Pré-condições PC ou PL deverão ter configurado o equipamento e enviado a aplicação de
teste ou de produção. PC ou PL devem retirar o cartão SD do equipamento e
inseri-lo no computador para leitura.
Pós-condições PC ou PL abrem o cartão SD e selecionam o arquivo ou arquivos que desejam
ter acesso.
Fluxo Principal 1 – PC ou PL certificam-se que o equipamento esteve devidamente
configurado e operando.
2 – PC ou PL retiram o cartão SD do equipamento e o inserem em um
computador.
3 – PC ou PL abrem o cartão SD e visualizam ou copiam os arquivos desejados.
Fluxo Secundário Caso haja algum erro de leitura no cartão, esse erro será reportado pelo
sistema operacional.
Quadro 7: UC05 – Visualizar dados em interface WEB

ID [UC05]
Descrição Visualizar dados em interface WEB.
Atores PL
Pré-condições PL certifica-se que o equipamento está devidamente configurado e
operando.
Pós-condições PL acessa o sistema WEB para visualização dos dados.
Fluxo Principal 1 – PL acessa a página WEB por um computador externo por meio de uma
URL ou diretamente por meio de um monitor, mouse e teclado conectados
ao equipamento.
30
2 – PL seleciona o intervalo de datas e sensor desejados.
3 – PL visualiza, por meio de gráficos e tabelas, os dados desejados.
Fluxo Secundário Se houver erro no acesso ao sistema, uma mensagem de erro é exibida.
11. Validação dos Requisitos

Considerando que a validação de requisitos é o processo pelo qual se verifica se os requisitos
identificados para o sistema realmente o definem quanto às necessidades e expectativas dos
stakeholders (Sommerville, 2011), nesta seção são feitos comentários sobre como este processo foi
conduzido para o datalogger.
Os seguintes tipos de verificações foram considerados: 1) Validade; 2) Consistência; 3) Completude;
4) Realismo e 5) Verificabilidade. Este último tipo envolve ainda questões de revisão, prototipação
e geração de casos de testes. A tabela 1 sintetiza os quatro primeiros tipos de verificação realizados
para cada um dos requisitos identificados.
As verificações de validade, consistência e completude foram realizadas junto aos stakeholders. As
demandas dos projetos propostos foram avaliadas e, em ambos os casos, atendidas
satisfatoriamente.
A verificação de consistência foi realizada, a fim de identificar se algum requisito apresentava
restrição contraditória ou funções iguais descritas de formas distintas. Não foram encontradas
falhas de consistência durante a verificação.
Na verificação de completude, foram revisados todos os requisitos a fim de identificar se alguma
funcionalidade havia sido ignorada ou esquecida. Todas as funcionalidades necessárias foram
elencadas e descritas corretamente.
A checagem de realismo foi a última dessa fase a ser realizada. Ocorreu após as validações junto aos
stakeholders a fim de identificar se todos os requisitos poderiam ser implementados dadas as
restrições de tempo e orçamento previstos. Concluiu-se que os requisitos apurados poderiam ser
implementados conforme orçamento e prazo existentes.
Tabela 1 – Validação dos requisitos de Validade, Consistência, Completude e Realismo
Requisito Validade Consistência Completude Realismo
RFH-01: Hardware principal
RFH-02: Sistema de obtenção de data e
hora
RFH-03: Sistema de armazenamento de
dados
RFH-04: Portas analógicas de leitura
RFH-05: Portas digitais contadoras de pulso
RFH-06: Portas digitais adicionais
RFH-07: Portas I2C
RFH-08: Porta RS485
31
RFH-09: Saídas de comunicação RS232 ou
RS485
RFH-10: Alimentação
RFH-11: Microcomputador para exibição
dos dados
RNFH-01: Facilidade de uso
RNFH-02: Precisão
RNFH-03: Precisão de data
RNFH-04: Confiabilidade
RNFH-05: Desempenho
RNFH-06: Espaço
RNFH-07: Custo
RNFH-08: Consumo de energia
RFF-01: Comunicação Serial
RFF-02: Relógio de tempo real (RTC)
RFF-03: Cartão de memória
RFF-04: Arquivo de configuração
RFF-05: Watchdog
RFF-06: Sincronização
RFF-07: Coleta
RFF-08: Armazenamento
RFF-09: Envio dos dados em tempo real
RNFF-01: Confiabilidade
RNFF-02: Tamanho
RNFF-03: Tipos de arquivo
RFSC-01: Interface para configuração
RFSC-02: Sincronizar RTC
RFSC-03: Criar arquivo de configuração
RFSC-04: Envio de aplicações (firmwares)
RFSC-05: Barra de Progresso
RNFSC-01: Tela de informação
RNFSC-02: Ajuda
RNFSC-03: Manual de instalação do
ambiente
RNFSC-04: Multiplataforma
32
RFSE-01: Consulta de dados
RFSE-02: Exportação dos dados
RFSE-03: Suporte à visualização, em tempo
real dos dados
RNFSE-01: Tela de ajuda
RNFSE-02: Ambiente
RNFSE-03: Restrições lógicas de base de
dados
RNFSE-04: Restrições de projeto
RNFSE-05: Acesso
Com relação à verificabilidade, o datalogger passou por revisões, sua prototipação foi realizada e
por fim, casos de testes foram propostos. Essas questões são discutidas a seguir.
A revisão dos requisitos foi realizada incremental e recursivamente conforme os dados foram sendo
coletados. A Tabela 2 documenta os diversos encontros realizados, as discussões efetuadas e as
contribuições decorrentes.
Tabela 2 – Tabela síntese das reuniões para revisão dos requisitos

Data do Stakeholders Discussão Contribuição
encontro
07/06/2019 Édipo Discussão sobre quais as Identificação da demanda e
Carneiro, necessidades de um levantamento das primeiras
Pablo Chang, possível projeto de funcionalidades e requisitos do
Rogério Rizzi Simulador de regimes de projeto;
Chuva. Esboço inicial do projeto.
20/06/2019 Édipo Discussão sobre as Sugestão de realizar avaliação de
Carneiro, necessidades explanadas na alguns sensores de solo existentes
Pablo Chang, reunião anterior; no mercado;
Rogério Rizzi
Discussão sobre possíveis Sugestão de realizar levantamento
componentes e sensores. de possíveis limitações do
hardware que estava sendo
planejado, com uso de plataforma
Arduino Mega 2560.
28/06/2019 Édipo Discussão sobre sensores Definição sobre quais sensores
Carneiro, existentes no mercado e seriam inicialmente utilizados para
Pablo Chang, suas características. o primeiro caso de aplicação
Rogério Rizzi (simulador de regimes de chuva);
Planejamento de quais tipos de
portas de comunicação seriam
necessárias e também de quantas
33
portas de cada tipo seriam
utilizadas.
01/07/2019 Édipo Revisão das necessidades Características principais definidas;
Carneiro, do hardware para aplicação Planejamento para execução de um
Pablo Chang, no simulador de chuva.
protótipo.
Rogério Rizzi
29/08/2019 Édipo Apresentação de Aprovação do esboço;
Carneiro, documento com esboço do
Planejamento para elaboração de
Deonir protótipo, com suas
projeto de circuito impresso e
Secco, Pablo principais características e testes iniciais; Software utilizado:
Chang, funcionalidades.
Eagle 7.2.0.
Rogério Rizzi
02/09/2019 Édipo Revisão do projeto da placa Ajustes no planejamento inicial;
Carneiro, de circuito impresso do
Revisão de componentes;
Leonardo protótipo.
Contini Revisão das trilhas de ligação.
30/10/2019 Édipo Apresentação do projeto da Aprovação para seguir com a
Carneiro, placa de circuito impresso elaboração da placa.
Pablo Chang, do protótipo.
Rogério Rizzi
11/02/2020 Édipo Apresentação da Sugestão da realização da

Carneiro, montagem da placa PCB montagem de firmware inicial para
Pablo Chang, com respectivos validação dos recursos;
Rogério Rizzi componentes. Sugestão de reunião de
alinhamento com stakeholders do
projeto de simulador de regimes de
chuva.
20/03/2020 Édipo Discussão sobre detalhes da Definição do gabinete a ser
a Carneiro, automação proposta no utilizado para abrigar o hardware;
06/04/2020 Pablo Chang, projeto do simulador de Definição de calhas a serem
Rogério Rizzi regime de chuvas;
utilizadas para suportarem o
Discussão sobre desenho da cabeamento dos sensores;
estrutura mecânica/física Definição da localização dos
do simulador de regime de sensores na estrutura.
chuvas.
23/08/2020 Édipo Discussão sobre detalhes na Revalidação de todas as ligações e
Carneiro, PCB levantados durante especificações de trilhas utilizadas
Rogério Rizzi validação com consultores no projeto.
externos.
26/11/2020 Claudia Criação do documento de Sugestão de novos requisitos de
Brandelero requisitos; hardware;
Rizzi, Édipo Revisão dos Requisitos de Correções gerais nos textos de
Carneiro, hardware. introdução e objetivos;
Rogério Rizzi
34
Revisão textual.
11/01/2021 Édipo Validação dos requisitos. Identificada uma falha nos
a Carneiro requisitos RFH-06 e RFH-07,
22/01/2021 durante a checagem de realismo. O
requisito foi ajustado e checado
novamente para validar se atendia
completamente ao proposto.
01/02/2021 Édipo Avaliação do local para Local avaliado e aprovado.
Carneiro, instalação do sensor multi
Leonardo paramétrico para coleta de
Contini dados meteorológicos.
05/02/2021 Édipo Instalação do sensor e do Realização de testes;
Carneiro, datalogger no local Início da coleta de dados.
Leonardo previamente escolhido
Contini (cobertura de um edifício na
cidade de Cascavel/PR)
26/05/2021 Claudia Banca de qualificação Realização dos ajustes apontados
Brandelero pela banca de qualificação;
Rizzi, Édipo
Ajustes em diagramas e imagens;
Carneiro,
Rogério Rizzi Revisão total do texto.
A prototipação foi realizada incrementalmente conforme as reuniões de validação foram sendo

realizadas. Após a etapa de qualificação do projeto, uma nova revisão foi feita em decorrência dos
apontamentos e sugestões feitas pelos avaliadores. A versão apresentada neste documento
correspondente ao produto de todas as validações realizadas. Os testes descritos na Tabela 3 foram
desenvolvidos e executados durante a elaboração do hardware do protótipo proposto.
Tabela 3 – Tabela síntese dos testes iniciais de hardware

Teste Objetivo Metodologia/Resultado
Portas Identificar se as Foi realizada a criação de um firmware para habilitação e leitura
digitais portas digitais dos valores provenientes das portas digitais D1 e D2 do
estavam protótipo;
contando pulso
Foi inserido no borne de ligação das portas digitais do protótipo,
corretamente.
um fio de cobre em cada terminal. Ao encostarem-se os fios, um
pulso deveria ser registrado;
O resultado do teste foi positivo, pois os dados foram
registrados corretamente, conforme esperado.
Portas Identificar se as Foi realizada a criação de um firmware para habilitação e leitura
analógicas portas analógicas dos valores provenientes das portas digitais, de 1 a 16;
estão realizando Foi realizada a ligação em cada um dos bornes de uma fonte
leituras
chaveada que fornecia de 1v a 5v de tensão, conforme
corretamente.
regulagem. Conforme esses valores eram alterados na fonte
35
chaveada, observava-se a variação da leitura capturada pelo
equipamento;
O resultado do teste foi positivo, pois os dados foram
capturados corretamente, conforme esperado.
Relógio de Identificar se o Foi realizada a criação de um firmware para habilitação e
Tempo módulo de relógio sincronização do horário do módulo de relógio com o horário
Real (RTC) está do computador;
desempenhando
O equipamento foi mantido desligado e sem qualquer fonte de
sua função alimentação durante 7 dias;
corretamente.
Ao religar o equipamento o horário estava dentro da faixa da
fonte, sem variação de tempo, conforme esperado.
Portas Identificar se a Foi realizada a criação de um firmware específico para
RS232 comunicação das habilitação das portas de comunicação e envio de dados de
portas RS232 segundo em segundo por meio delas;
estão Foi realizada a ligação das portas de comunicação do
funcionando equipamento a um computador. No computador, por meio de
corretamente. um software de terminal, foi possível verificar as mensagens
chegando corretamente, conforme esperado.
Porta Identificar se a Foi realizada a criação de um firmware específico para
RS485 comunicação da habilitação da porta de comunicação e função para
porta RS485 está recebimento e envio de informações;
funcionando Foi realizada a ligação da porta de comunicação do
corretamente.
equipamento a um computador. No computador, por meio de
um software de terminal, foi possível realizar o envio e
recebimento de mensagens corretamente, conforme esperado.
Os testes descritos na Tabela 4 foram desenvolvidos e realizados durante a elaboração das

funcionalidades do protótipo proposto.
Tabela 4 – Tabela síntese dos testes de operação

Teste Objetivo Metodologia/Resultado
Usabilidade Testar todas as Foram realizadas as seguintes checagens:
funcionalidades
 O sistema foi testado em plataforma Windows e Linux;
do sistema
 Funcionamento da interface para configuração;
 Sincronismo do relógio de tempo real;
 Criação do arquivo de configuração;
 Envio de aplicações (firmwares);
 Funcionamento da barra de progresso;
 Exibição de tela de informação do projeto e ajuda;
Todos os testes obtiveram o resultado desejado, conforme
especificado no levantamento de requisitos.
36
Simulação Testar o Foi realizado teste do equipamento em ambiente de campo
em campo funcionamento para atestar sua funcionalidade. O datalogger foi deixado por
do datalogger em 3 dias, entre 06 e 08/02/2021, coletando e armazenando os
ambiente de dados de um sensor meteorológico 5 parâmetros (velocidade
campo e direção de vento, umidade relativa, temperatura e pressão
atmosférica) e saída RS485.
As Figuras 19 e 20 ilustram o ambiente da realização do teste.
Figura 19 – Sensor utilizado para leitura

Figura 20 – Protótipo com as respectivas ligações para leitura

do sensor
37
161
APÊNDICE B – Manual de instalação do

ambiente de visualização do datalogger
Manual de Instalação do ambiente de visualização do Datalogger
30/03/2021
Índice
1. Instalação do Raspberry PI OS ............................................................................ 2
2. Configuração geral do Raspberry Pi .................................................................... 3
3. Instalação do Servidor HTTP Apache .................................................................. 4
4. Instalação do PHP .............................................................................................. 5
5. Instalação do MySQL/MariaDB .......................................................................... 6
6. Instalação do Java.............................................................................................. 7
7. Instalação dos softwares do Datalogger ............................................................. 7
8. Instalação do PHPMyAdmin (opcional) .............................................................. 7
1. Instalação do Raspberry PI OS
1.1. Acesse o site da Raspberry, (https://www.raspberrypi.org/).
1.2. Na aba Software, faça o download do Raspberry PI OS.
Figura 1 - Página de download do Raspberry Pi OS
1.3. Ao finalizar o download, execute o programa Raspberry Pi Imager.

1.4. Insira no computador o cartão SD que será utilizado no Raspberry Pi.
1.5. Selecione a opção Raspberry PI OS Lite (32-bit) na opção “Operating System” e
localize o seu cartão SD na opção “SD Card”. Na sequência, clique em WRITE.
1.6. Aguarde o término da instalação, retire o cartão SD do computador e insira-o no
Raspberry.
2
Figura 2 - Tela do Software Raspberry Pi Imager
2. Configuração geral do Raspberry Pi

2.1. Antes de iniciar, conecte um monitor e um teclado as portas USB do Raspberry.
2.2. Ligue o equipamento.
2.3. Faça o login no Linux.
Usuário: pi
Senha: raspberry
2.4. Habilite a conexão SSH para facilitar futuros acessos sem a necessidade de um
monitor
# sudo raspi-config
Opção 3 – Interface Options
Selecione a Opção P2 SSH
Selecione a Opção Yes
2.5. Habilite a porta Serial do Raspberry Pi
# sudo raspi-config
Selecione a Opção 3 – Interface Options
Selecione a Opção P6 Serial Port
Selecione a Opção No
Selecione a Opção Yes
3
3. Instalação do Servidor HTTP Apache
3.1. Atualize a base de dados do APT
# sudo apt upgrade
# sudo apt update
3.2. Faça a instalação do pacote Apache2
# sudo apt-get install apache2
3.3. Identifique qual o IP do Raspberry na rede
# sudo if-config eth0
Figura 3 - Tela com resultado do comando ifconfig
3.4. Acesse por meio de um browser o IP localizado no passo anterior. A página inicial do
projeto Apache2 deve ser exibida.
4
Figura 4 - Página inicial do Servidor Apache
4. Instalação do PHP
4.1. Faça a instalação do pacote PHP
# sudo apt-get install php php-mbstring
4.2. Remova o arquivo index.html padrão
# sudo rm /var/www/html/index.html
4.3. Crie um arquivo chamado index.php
# cd /var/www/html/
# sudo vi index.php
4.4. Adicione o seguinte conteúdo ao arquivo:
“<?php
phpinfo();
?>“
4.5. Acesse por meio de um browser o IP localizado no 3.4. Uma página com as
informações do PHP deverá ser exibida.
5
Figura 5 - Página com dados do PHP
5. Instalação do MySQL/MariaDB
5.1. Instale os pacotes necessários
# sudo apt-get install mariadb-server-10.0 php-mysql
5.2. Crie um usuário para acesso ao banco de dados
# sudo mysql --user=root
# CREATE USER 'mestrado'@'localhost' IDENTIFIED BY 'mestrado123';
# GRANT ALL PRIVILEGES ON *.* TO 'mestrado'@'%' WITH GRANT OPTION;
5.3. Crie o banco de dados padrão
# CREATE DATABASE ‘mestrado’;
5.4. Crie a tabela para recepção dos dados
# CREATE TABLE `dado` (
ìd` bigint(20) UNSIGNED NOT NULL,
6
`data` timestamp NULL DEFAULT NULL,
`sensorNome` varchar(255) NOT NULL,
`valor` double NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
# ALTER TABLE `dado`

ADD UNIQUE KEY ìd` (ìd`);
# ALTER TABLE `dado`

MODIFY ìd` bigint(20) UNSIGNED NOT NULL AUTO_INCREMENT;
# QUIT;
6. Instalação do Java
6.1. Instale os pacotes necessários
# sudo apt install openjdk-8-jdk
# sudo apt-get install wiringpi
7. Instalação dos softwares do Datalogger

7.1. Copie o conteúdo do arquivo ProjetoMestrado-Rasp.zip para
/home/pi/ProjetoMestrado-Rasp/
7.2. Adicione a execução automática do programa ao inicializar o Linux
# vi/etc/rc.local
Adicionar o seguinte conteúdo:
/home/pi/ProjetoMestrado-Rasp/
java –jar ProjetoMestrado-Rasp.jar
exit 0
7.3. Copie o conteúdo do arquivo ProjetoMestrado.zip para /var/www/ProjetoMestrado/
8. Instalação do PHPMyAdmin (opcional)

8.1. Instale os pacotes necessários:
# sudo apt install phpmyadmin
Selecione a opção apache2
Selecione a opção Não para a configuração dbconfig-common
7
8.2. Adicione a extensão no Apache
# sudo phpenmod mysqli
# sudo /etc/init.d/apache2 restart
8.3. Acesse por meio de um browser o IP localizado no 3.4/phpmyadmin. Uma página com
campos para login deverá ser exibida.
Figura 6 - Página inicial do phpMyAdmin
8
171
APÊNDICE C – Código fonte do firmware do

datalogger
#include <MemoryFree.h>
#include <avr/wdt.h>
#include <QueueArray.h>
#include <Wire.h>
#include <SD.h>
#include <SPI.h>
#include "RTClib.h"
#include <Time.h>
#include <TimeAlarms.h>
#include <DS3231.h>
//Pino para leitura do SD

#define SDCARD 48
//Numero de leituras para chegar ao valor da porta
#define NUM_READS 20
// Init the DS3231 using the hardware interface

// Arduino Mega:
// ----------------------
// DS3231: SDA pin -> Arduino Digital 20 (SDA) or the dedicated SDA pin
// SCL pin -> Arduino Digital 21 (SCL) or the dedicated SCL pin
DS3231 rtc(SDA, SCL);
char nivel_str[10];
struct parameters {
String nome = "DEFAULT";
int intervaloColeta = 5;
String portaSaida = "RS232";
String RS485 = "false";
String D1 = "true";
String D2 = "false";
String A1 = "'A1', true, 0, 10 ,0";
String A2 = "'A2', true, 0, 10 ,0";
String A3 = "'A3', true, 0, 10 ,0";
String A4 = "'A4', true, 0, 10 ,0";
String A5 = "'A5', true, 0, 10 ,0";
String A6 = "'A6', true, 0, 10 ,0";
String A7 = "'A7', true, 0, 10 ,0";
String A8 = "'A8', true, 0, 10 ,0";
String A9 = "'A9', true, 0, 10 ,0";
String A10 = "'A10', true, 0, 10 ,0";
String A11 = "'A11', true, 0, 10 ,0";
String A12 = "'A12', true, 0, 10 ,0";
String A13 = "'A13', true, 0, 10 ,0";
String A14 = "'A14', true, 0, 10 ,0";
String A15 = "'A15', true, 0, 10 ,0";
String A16 = "'A16', true, 0, 10 ,0";
} configs;
//Demais variaveis
volatile int pulseCounterD2 = 0;
volatile int pulseCounterD3 = 0;
volatile int mainLoopCounter = 0;
boolean alarmed = false;
boolean keepRunning = true;
boolean hasError = false;
int countError = 0;
AlarmId lastAlarm;
//SD card utilitarios

Sd2Card card;
SdVolume volume;
SdFile root;
boolean failSD = false;
//Varivel de DATA geral

DateTime dtPrincipal;
void setup() {
// Inicializa a comunicacao SERIAL -- debug USB
Serial.begin(9600);
// Serial 1 -- Conexão raspberry
Serial1.begin(9600);
// Serial 2 -- Conector 2
// Serial 3 -- Conector 3 (pode ser RS485 ou RS232, entrada ou saída)
//Inicializa o RTC
Wire.begin();
rtc.begin();
//Atualiza a hora da compilacao como horario inicial

Serial.print("Data/Hora: ");
//Sincroniza o metodo se alarme

setSyncProvider(syncProvider);
setSyncInterval(1);
printDate();
//Inicializa o SD card
Serial.print("Inicializando cartao SD... ");
if (!SD.begin(SDCARD)) {
Serial.print("Modulo SD falhou! ");
failSD = true;
hasError = true;
}
if (!card.init(SPI_HALF_SPEED, SDCARD)) {
Serial.print("Cartao SD falhou! ");
failSD = true;
hasError = true;
}
if ((!volume.init(card)) && (!failSD)) {

Serial.println("Nao foi possivel encontrar uma particao FAT16 ou FAT32.
\nVerifique se voce formatou o cartao corretamente ");
failSD = true;
}
if (hasError) {
Serial.print("Inicializacao falhou! ");
} else {
Serial.println("Inicializacao completa. ");
}
Serial.println();
//Se o SD não falhou, carrega as configurações

if (!failSD) {
//Busca configuracoes
keepRunning = getSettings();
//Mostra configuracoes
printConfigs();
//Preenche variaveis com as configurações
fillSettings();
} else {
keepRunning = false;
}
//Inicializa o watchdog, com 8 segundos de inatividade para reset.

wdt_enable(WDTO_8S);
}
void loop() {
//Reinicia se ocorreu erro na inicialização
if (hasError) {
Serial.println(" Reiniciando devido erro de inicializacao");
delay(10000);
}
//Verifica se leu o arquivo de configuracoes e se deve continuar rodando

if (keepRunning) {
//Busca data e hora atuais
dtPrincipal = rtc.getUnixTime(rtc.getTime());
//Se tiver sido alarmado, incrementa 1 segundo. Caso contrario, incrementa o

loop.
if (alarmed) {
//Se houver algo chegando pela RS485 e estiver ativo a configuração para
gravação, recebe dado e grava
if (configs.RS485) {
if (Serial3.available() > 0) {
String comando = Serial3.readString();
//Chama gravação em arquivo
fileRS485(dtPrincipal, comando);
//Envia para raspberry
sendMessage(comando);
}
}
//Necessario para incrementar o contador de segundos do alarme.

Alarm.delay(1000);
//Reseta o watchdog, ou seja se o programa travar e não passar por esse

reset, em 8 segundos o módulo será reiniciado
wdt_reset();
} else {
Serial.print(".");
delay(1000);
//Reseta o watchdog, ou seja se o programa travar e não passar por esse
reset, em 8 segundos o módulo será reiniciado
wdt_reset();
}
if (!alarmed) {
//Quanto o resto da divisão do minuto pelo intervalo configurado for 0,
alarma
//----------------------------------------------------------------------
alterar para debug -------------------------------------------------------------
if ((dtPrincipal.second() % configs.intervaloColeta) == 0) {
//if ((dtPrincipal.minute() % configs.intervaloColeta) == 0) {
alarm();
} else
//Se intervalo = 60, testar minuto 0
//----------------------------------------------------------------------
alterar para debug -------------------------------------------------------------
if ((dtPrincipal.second() == 0) && (configs.intervaloColeta == 60)) {
//if ((dtPrincipal.minute() == 0) && (configs.intervaloColeta == 60)) {
alarm();
}
}
} else {
Serial.println("Erro!");
if (countError == 0) {
Serial2.print("Erro: ErroKeepRunning");
Serial2.println();
countError++;
}
delay(10000);
}
}
void alarm() {
alarmed = true;
//Programa alarme (HORA, MINUTO, SEGUNDO, METODO)

//Alarm.timerRepeat(horaAlarm, minAlarm, secAlarm, mainLoop);
//--------------------------------------------------------------------------------
---------- alterar para debug -----------------------------------
Alarm.timerRepeat((configs.intervaloColeta), mainLoop);
//Alarm.timerRepeat((configs.intervaloColeta * 60), mainLoop);
Serial.println("Sistema alarmado com sucesso");

Serial.println("");
//Chama loop principal

mainLoop();
}
void mainLoop() {
mainLoopCounter++;
//Obtem a data e hora atuais

DateTime dt = now();
//Exibe dados atuais na serial de Debug

printPortStatus(dt);
//Chama a escrita em arquivo e envio, de acordo com a quantidade configurada

para ser acumulada antes de ennviar.
if (mainLoopCounter == 1) {
fileLoop(dtPrincipal);
mainLoopCounter = 0;
Serial1.flush();
Serial2.flush();
}
//Exibe memoria disponivel depois do processo

Serial.print("Memoria livre e temperatura: ");
Serial.print(freeMemory());
Serial.print(" ");
Serial.print(rtc.getTemp());
Serial.println("C");
Serial.println("");
}
void fileRS485(DateTime dt, String data) {

//Gerando arquivo (um por dia, dentro da pasta com o nome da estacao)
SD.mkdir(configs.nome);
String fileName = "/" + configs.nome + "/";
fileName += printFileName(dt);
fileName += ".dig";
//Gerando arquivo DIG

File file = SD.open(fileName.c_str() , FILE_WRITE);
Serial.print("Abrindo o arquivo: ");

Serial.print(fileName);
Serial.print(" ... ");
//Se o arquivo abrir corretamente, escrever.

if (file) {
file.println(data);
file.close();
Serial.println("Escreveu a leitura!");
}
else {
//Se o arquivo nao abrir, exibir erro.
Serial.println("Erro ao abrir o arquivo");
}
}
void fileLoop(DateTime dt) {

//Instancia String de dados
String dataString = "";
String dataStringRAW = "";
String dataStringOUT = "";
boolean printHeader = false;
//Gerando arquivo (um por dia, dentro da pasta com o nome da estacao)
SD.mkdir(configs.nome);
String fileName = "/" + configs.nome + "/";
fileName += printFileName(dt);
fileName += ".txt";
String fileNameRAW = "/" + configs.nome + "/";
fileNameRAW += printFileName(dt);
fileNameRAW += ".raw";
/* Data
*/
dataStringRAW += "DT=";
dataStringRAW += printFormatedDate(dt);
dataStringRAW += " ";
dataStringRAW += printFormatedHour(dt);
dataStringRAW += ";";
dataString += printFormatedDate(dt);
dataString += ";";
dataString += printFormatedHour(dt);
dataString += ";";
/* Portas digitais
Registrador: Porta Digital (D1, D2);
Unidade de medida: cacambadas
*/
//Pega os valores dos sensores
int chuva;
if (configs.D1 == "true") {
dataStringRAW += "D1=";
dataStringRAW += pulseCounterD2;
dataString += "D1=";
dataString += pulseCounterD2;
dataString += ";";
}
dataStringRAW += "D2=";
dataStringRAW += pulseCounterD3;
dataString += "D2=";
dataString += pulseCounterD3;
dataString += ";";
}
dataStringOUT = dataStringRAW;
/* Analogicos
Registrador: Portas Analogicas (A1, A2, A3, A4);
*/
if (getSplittedValue(configs.A1, ',', 1) == "true") {
float auxRead = getAnalogRead(1, true);
dataStringRAW += getSplittedValue(configs.A1, ',', 0)+"=";
dataStringRAW += auxRead;
dataStringOUT += getSplittedValue(configs.A1, ',', 0)+"=";
dataStringOUT += getAnalogRead(1, false);
dataStringOUT += ";";
dataString += getAnalogRead(1, false);

dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}
dataStringOUT +=getSplittedValue(configs.A6, ',', 0)+"=";


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}

dataString += ";";
}


dataString += ";";
}


dataString += ";";
}


dataString += ";";
}

dataString += ";";
}
//Testa se o arquivo já existe para determinar se terá ou não header

if (!SD.exists(fileName)) {
printHeader = true;
}
//Gerando arquivo CSV

File file = SD.open(fileName.c_str() , FILE_WRITE);

Serial.print(fileName);

if (file) {
if (printHeader) {
file.println(createHeader());
}
file.println(dataString);
file.close();
Serial.println("Escreveu a leitura!");
}
else {
}
//Gerando arquivo RAW

file = SD.open(fileNameRAW.c_str() , FILE_WRITE);

Serial.print(fileNameRAW);

if (file) {
file.println(dataStringRAW);
file.close();
Serial.println("Escreveu a leitura RAW!");
}
else {
}
//Envia os dados para o raspberry

sendMessage(dataStringRAW);
//Envia os dados para as demais seriais, caso necessário

sendMessageOUT(dataStringOUT);
String createHeader() {
String aux = "data;hora;";
aux += "digital1;";
}
aux += "digital2;";
}
aux += "analogico1;";
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
return aux;
}
void printPortStatus(DateTime dt) {

Serial.print("Data: ");
Serial.print(printFormatedDate(dt));
//Pega os valores dos sensores

Serial.print(" D1: ");
Serial.print(pulseCounterD2);
}
Serial.print(" D2: ");
Serial.print(pulseCounterD3);
}

Serial.print(" A1: ");
Serial.print(getAnalogRead(1, false));
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
Serial.println("");
void printDate() {
Serial.print(rtc.getDateStr(FORMAT_LONG, FORMAT_LITTLEENDIAN, '/'));
Serial.print(" ");
Serial.println(rtc.getTimeStr());
Serial.println("");
}
void printTemp() {
Serial.println(rtc.getTemp());
}
String printDateString() {
String data = "";
data += rtc.getDateStr(FORMAT_LONG, FORMAT_LITTLEENDIAN, '/');
data += " ";
data += rtc.getTimeStr();
return data;
}
String printFileName(DateTime dt) {

String fileName = "";
String strDay = "";
if (dt.day() < 10) {
strDay += "0";
strDay += dt.day();
} else {
strDay += dt.day();
}
fileName += strDay;
String strMonth = "";

if (dt.month() < 10) {
strMonth += "0";
strMonth += dt.month();
} else {
}
fileName += strMonth;
fileName += dt.year();
return fileName;
}
String printFormatedDate(DateTime dt) {

String date = "";
String strDay = "";

if (dt.day() < 10) {
strDay += "0";
strDay += dt.day();
} else {
strDay += dt.day();
}
date += strDay;
date += '/';
String strMonth = "";

if (dt.month() < 10) {
strMonth += "0";
} else {
}
date += strMonth;
date += '/';
date += dt.year();
return date;
}
String printFormatedHour(DateTime dt) {

String date = "";
date += dt.hour();
date += ':';
date += dt.minute();
date += ':';
date += dt.second();
return date;
}
String printDataLoggerDate(DateTime dt) {

//Formato: 9/23/2014
String date = "";
date += dt.month();
date += '/';
date += dt.day();
date += '/';
date += dt.year();
date += ' ';
date += dt.hour();
date += ':';
date += dt.minute();
date += ':';
date += dt.second();
date += ' ';
return date;
}
void countPulseD2() {
pulseCounterD2++;
}
void countPulseD3() {
pulseCounterD3++;
}
float getAnalogRead(int sensor, boolean isRaw) {

float valorFinal = 0;
int port = 0;
String isTopCase = "false";
float intervaloIni = 0.0;
float intervaloFim = 0.0;
float offset = 0.0;
float slope = 0;
//Testa qual sensor está ativo

if (sensor == 1) {
port = 1;
intervaloIni = getSplittedValue(configs.A1, ',', 2).toFloat();
intervaloFim = getSplittedValue(configs.A1, ',', 3).toFloat();
offset = getSplittedValue(configs.A1, ',', 4).toFloat();
}
} else if (sensor == 2) {
port = 2;
}
port = 3;
}
port = 4;
}
port = 5;
}
port = 6;
}
port = 7;
}
port = 8;
}
port = 9;
}
port = 10;
}
port = 11;
}
port = 12;
}
port = 13;
}
port = 14;
}
port = 15;
}
port = 16;
}
}
//Debug
// Serial.print("intervaloIni = ");
// Serial.println(intervaloIni);
// Serial.print("intervaloFim = ");
// Serial.println(intervaloFim);
// Serial.print("offset = ");
// Serial.println(offset);
//Testa se o intevalo inicial é negativo

boolean wasNegative = false;
float intervaloIniAux = 0;
if (intervaloIni < 0) {
intervaloIniAux = intervaloIni * -1;
wasNegative = true;
} else {
intervaloIniAux = intervaloIni;
}
// Serial.println(intervaloIni);
//Calcula range
float range = 0.0;
if (wasNegative) {
range = intervaloFim + intervaloIniAux;
} else {
range = intervaloFim - intervaloIniAux;
}
// Serial.println(range);
//Fator de variacao (range = variacao total 1023-203)

float fatorVariacao = 820 / range;
// Serial.println(fatorVariacao);
//Faz a leitura bruta do sensor

int leituraBruta = readAnalog(port);
if (isRaw) {
return leituraBruta;
}
// Serial.print("Leitura Bruta:");
// Serial.println(leituraBruta);
//Encontra diferenca entre o valor encontrado e o zero. 203/205 é a leitura

referente a 4mA ou 0v.
float leituraLimpa = leituraBruta - 203;
// Serial.print("Leitura Limpa:");
// Serial.println(leituraLimpa);
//Leitura bruta
float valorBruto = (float)leituraLimpa / fatorVariacao;
// Serial.print("Valor Bruto");
// Serial.println(valorBruto);
//Leitura real
float leituraReal = valorBruto + (float) intervaloIniAux;
if (wasNegative) {
leituraReal = valorBruto - (float) intervaloIniAux;
}
// Serial.print("Leitura Real:");
// Serial.println(leituraReal);
//Valor final
float sensorFinal = leituraReal;
//Somar REGUA/OFFSET
if (isTopCase.indexOf("true") > -1) {
sensorFinal = offset - sensorFinal;
} else {
sensorFinal = offset + sensorFinal;
}
// Serial.print("Leitura Final:");
// Serial.println(sensorFinal);
return sensorFinal;
}
float readAnalog(int sensorpin) {

// read multiple values and sort them to take the mode
int sortedValues[NUM_READS];
for (int i = 0; i < NUM_READS; i++) {
int value = analogRead(sensorpin);
int j;
if (value < sortedValues[0] || i == 0) {
j = 0; //insert at first position
}
else {
for (j = 1; j < i; j++) {
if (sortedValues[j - 1] <= value && sortedValues[j] >= value) {
// j is insert position
break;
}
}
}
for (int k = i; k > j; k--) {
// move all values higher than current reading up one position
sortedValues[k] = sortedValues[k - 1];
}
sortedValues[j] = value; //insert current reading
}
long returnval = 0;
for (int i = 0; i < NUM_READS; i++) {
returnval += sortedValues[i];
}
returnval = returnval / NUM_READS;
return returnval;
}
boolean getSettings() {
// Open the settings file for reading:
File myFile = SD.open("config.txt");
if (!myFile) {
Serial.println("Arquivo de configuracoes nao encontrado.");
Serial.println("Parando a aplicacao!");
return false;
}
Serial.print("Abrindo arquivo configuracoes... ");
char character;
String description = "";
String value = "";
// Varre o arquivo ate que nao haja mais nada a ser lido
while (myFile.available()) {
character = myFile.read();
//Ignora os comentários
if (character == '/') {
while (character != '\n') {
};
} else if (isalnum(character)) { //Se for alfanumerico, faz parte da descricao
description.concat(character);
} else if (character == '=') {
//Remove espacos em branco
do {
} while (character == ' ');
//Pega os parametros na ordem do arquivo
//Serial.println(description);
if (description == "nome") {
value = "";
//Concatena enquanto nao houver quebra de linha
do {
value.concat(character);
} while (character != '\n');
configs.nome = value;
// Serial.println(value);
} else if (description == "intervaloColeta") {
value = "";
do {
configs.intervaloColeta = atoi(value.c_str());
} else if (description == "portaSaida") {
value = "";
do {
configs.portaSaida = value;
} else if (description == "D1") {
value = "";
do {
configs.D1 = value;
} else if (description == "D2") {
value = "";
do {
configs.D2 = value;
} else if (description == "RS485") {
value = "";
do {
configs.RS485 = value;
} else if (description == "A1") {
value = "";
do {
configs.A1 = value;
value = "";
do {
configs.A2 = value;
value = "";
do {
configs.A3 = value;
value = "";
do {
configs.A4 = value;
value = "";
do {
configs.A5 = value;
value = "";
do {
configs.A6 = value;
value = "";
do {
configs.A7 = value;
value = "";
do {
configs.A8 = value;
value = "";
do {
configs.A9 = value;
value = "";
do {
configs.A10 = value;
value = "";
do {
value = "";
do {
value = "";
do {
value = "";
do {
value = "";
do {
value = "";
do {
} else {
while (character != '\n')
}
description = "";
} else {
}
}
Serial.println("Configuracoes carregadas com sucesso!");

Serial.println("");
//Fecha a leitura do arquivo

myFile.close();
return true;
}
void fillSettings() {
//Inicializa portas digitais (contadoras de pulso)
pinMode(2, INPUT);
digitalWrite(2, HIGH);
attachInterrupt(0, countPulseD2, FALLING);
}
pinMode(3, INPUT);
digitalWrite(3, HIGH);
attachInterrupt(1, countPulseD3, FALLING);
}
void sendMessage(String message) {

Serial.print("Enviando mensagem para o Rasberry (");
//@9/23/2014 16:30:0 A 1: 1.88 P 1: 0 B 1: 13.13
Serial.print(message);
Serial1.print(message);
Serial1.print("--EOF");
Serial1.println();
Serial.println(")... Mensagem enviada!");
Serial.println("");
}
void sendMessageOUT(String message) {

Serial.print("Enviando mensagem para Seriais (");
//@9/23/2014 16:30:0 A 1: 1.88 P 1: 0 B 1: 13.13
Serial.print(message);
if (configs.portaSaida.indexOf("RS232") > -1) {

Serial2.println();
}
if (configs.portaSaida.indexOf("RS485") > -1) {
Serial3.println();
}
Serial.println(")... Mensagem enviada!");

Serial.println("");
}
void printMessages(DateTime dt, int chuva, float nivel) {

Serial.print("Data: ");
Serial.print(printDataLoggerDate(dt));
Serial.print(" Nivel: ");
Serial.print(nivel);
Serial.print(" Chuva: ");
Serial.print(chuva);
Serial.print("");
}
void printConfigs() {
Serial.print("Nome: ");
Serial.println(configs.nome);
Serial.print("Intervalo de Coleta: ");
Serial.println(configs.intervaloColeta);
Serial.print("Porta de Saida: ");
Serial.println(configs.portaSaida);
Serial.print("D1: ");
Serial.println(configs.D1);
Serial.print("D2: ");
Serial.println(configs.D2);
Serial.print("RS485: ");
Serial.println(configs.RS485);
Serial.print("A1: ");
Serial.println(configs.A1);
Serial.println("");
}
//Funções uteis
String getSplittedValue(String data, char separator, int index) {
/* Exemplo:
String split = "hi this is a split test";
String word3 = getValue(split, ' ', 2);
Serial.println(word3);
*/
int found = 0;
int strIndex[] = {0, -1};
int maxIndex = data.length() - 1;
for (int i = 0; i <= maxIndex && found <= index; i++) {

if (data.charAt(i) == separator || i == maxIndex) {
found++;
strIndex[0] = strIndex[1] + 1;
strIndex[1] = (i == maxIndex) ? i + 1 : i;
}
}
return found > index ? data.substring(strIndex[0], strIndex[1]) : "";
}
time_t syncProvider() {
return rtc.getUnixTime(rtc.getTime());
}
203
APÊNDICE D – Roteiro em R das análises

de dados
# ____________________________________________
# ANÁLISES DO ARTIGO SOBRE SENSOR DE UMIDADE
# Criado em: 09/08/2021
# Atualizado em: 04/09/21
# ____________________________________________
# Leitura e preparação dos dados ----
# ____________________________________________
# Comando para definir a localização da pasta:
{
library(rstudioapi) # precisa ter instalado o pacote "rstudioapi"
current_path =
rstudioapi::getActiveDocumentContext()$path
setwd(dirname(current_path ))
print( getwd() )
}
# Troque o nome do arquivo de dados (entre " .csv"):
dados <- read.csv2(
"dados_calib2.csv",
header = T)
# Mostra as 6 primeiras linhas para visualização.
# As colunas devem seguir a ordem: tratamento // resposta;
head(dados)
# Definir as variáveis X e Y.
attach(dados)
dados <- data.frame(X = c(Valor),
Y = c(Umidade)*100, # para transformar em %
Sensor = c(Sensor)
)
# Fazer cópia dos dados
dados2 <- dados
# Mostra as 6 primeiras linhas para ver como ficou.
head(dados)
# Deletar o sensor 9 antigo da tabela
r <- with(dados, which(Sensor==9, arr.ind=TRUE))
dados <- dados[-r, ]
attach(dados)
# Renomear 9.2 para 9
dados$Sensor[dados$Sensor == 9.2] <-
rep("9", length(dados$Sensor[dados$Sensor == 9.2]))
attach(dados)
# ____________________________________________
# Gráficos da regressão ----
# ____________________________________________
{require(ggplot2)
require(gridExtra) # forma grade
require(cowplot)
# Gráficos em grade
grafico <- ggplot(dados, aes(X, Y)) +
labs(x = "Leitura dos sensores de umidade (V)",
y = "Umidade do solo (%)") +
facet_wrap(. ~ Sensor,ncol=3) + # Grade de gráficos
stat_smooth(method = "lm",
fill = "gray", # Cor do intervalo de confiança
aes(alpha = "Ajustado")) + # Método linear
panel_border() + # and a border around each panel
geom_point(aes(alpha = "Observado")) +
scale_alpha_manual(name = NULL,
values = c(1, 1),
204 APÊNDICE D. Roteiro em R das análises de dados
breaks = c("Observado", "Ajustado"),

guide = guide_legend(
override.aes = list(linetype = c(0, 1),
shape = c(16, NA),
color = c("black",
"blue"))
)
) +
theme_gray() +
theme(legend.position="bottom") +
background_grid(major = ’none’, minor = "none") # add thin horizontal lines
}
grafico
# Exportar para formato vetorial .svg
#ggsave(file = "graficosCalibracao.svg",
# plot = grafico,
# width = 10, # comprimento
# height = 6) # altura
# ____________________________________________
# Tabela de coeficientes e métricas ----
# ____________________________________________
# Lista de modelos ajustados para 9 sensores:
Sensor <- as.factor(Sensor)
# Criando objetos:
s <- c(1:length(levels(Sensor)))
a <- c(1:length(levels(Sensor)));
b <- c(1:length(levels(Sensor)));
r2 <- c(1:length(levels(Sensor)));
theta <- c(1:length(levels(Sensor)));
rmse <- c(1:length(levels(Sensor)))
#aic <- c(1:length(levels(Sensor)))
p_value <- c(1:length(levels(Sensor)))
tabela <- as.data.frame(cbind(s, a, b, r2, theta, rmse, p_value))
# Coeficientes da regressão
# y = ax+b
for (i in 1:9){
tabela$a[i] =
coef(
lm(dados$Y[Sensor==i] ~ dados$X[Sensor==i])
)[2] # intercepto y do modelo
tabela$b[i] =
coef(
)[1] # coeficiente angular do modelo
}
tabela
# R^2
for (i in 1:9){
tabela$r2[i] <- summary(
lm(dados$Y[Sensor==i] ~ dados$X[Sensor==i]))$r.squared/
summary(lm(dados$Y[Sensor==i] ~ factor(dados$X[Sensor==i])
))$r.squared
}
tabela
# theta^2
for (i in 1:9){
tabela$theta[i] <- deviance(
)
}
tabela
# rmse
require(Metrics)
for (i in 1:9){
tabela$rmse[i] <- rmse(dados$Y[Sensor==i],
lm(dados$Y[Sensor==i] ~ dados$X[Sensor==i])$fitted.values)
}
tabela
# # AIC
# for (i in 1:9){
205
# tabela$aic[i] <- AIC(lm(dados$Y[Sensor==i] ~ dados$X[Sensor==i]))

# }
# tabela
# p-value
for (i in 1:9){
tabela$p_value[i] <- anova(lm(dados$Y[Sensor==i] ~ dados$X[Sensor==i]))$"Pr(>F)"[1]
}
tabela
# Exportar para Excel:
#write.csv2(tabela,
# file =
# "Tabela de coeficientes e métricas.csv")
# ____________________________________________
# tabela2 de coeficientes e métricas (para o sensor 9 quebrado) ----
# ____________________________________________
# Lista de modelos ajustados para 9 sensores:
Sensor <- as.factor(Sensor)
# Criando objetos:
s <- c(1:length(levels(Sensor)))
a <- c(1:length(levels(Sensor)));
b <- c(1:length(levels(Sensor)));
r2 <- c(1:length(levels(Sensor)));
theta <- c(1:length(levels(Sensor)));
rmse <- c(1:length(levels(Sensor)))
#aic <- c(1:length(levels(Sensor)))
p_value <- c(1:length(levels(Sensor)))
tabela2 <- as.data.frame(cbind(s, a, b, r2, theta, rmse, p_value))
# Coeficientes da regressão
# y = ax+b
for (i in 1:9){
tabela2$a[i] =
coef(
lm(dados2$Y[Sensor==i] ~ dados2$X[Sensor==i])
)[2] # intercepto y do modelo
tabela2$b[i] =
coef(
)[1] # coeficiente angular do modelo
}
tabela2
# R^2
for (i in 1:9){
tabela2$r2[i] <- summary(
lm(dados2$Y[Sensor==i] ~ dados2$X[Sensor==i]))$r.squared/
summary(lm(dados2$Y[Sensor==i] ~ factor(dados2$X[Sensor==i])
))$r.squared
}
tabela2
# theta^2
for (i in 1:9){
tabela2$theta[i] <- deviance(
)
}
tabela2
# rmse
for (i in 1:9){
tabela2$rmse[i] <- rmse(dados2$Y[Sensor==i],
lm(dados2$Y[Sensor==i] ~ dados2$X[Sensor==i])$fitted.values)
}
tabela2
# AIC
# for (i in 1:9){
# tabela2$aic[i] <- AIC(lm(dados2$Y[Sensor==i] ~ dados2$X[Sensor==i]))
# }
# tabela2
# p-value
for (i in 1:9){
tabela2$p_value[i] <- anova(lm(dados2$Y[Sensor==i] ~ dados2$X[Sensor==i]))$"Pr(>F)"[1]
}
tabela2
#write.csv2(tabela2,
# file =
# "tabela2 de coeficientes e métricas.csv")
# ____________________________________________
# ANÁLISES DO EXPERIMENTO: UMIDADE X PALHA ----
#
#
# ____________________________________________
# ____________________________________________
# Leitura dos dados ----
# ____________________________________________
dados_palha10 <- read.table("dados_experimento/02082021.txt",
sep = ";", # separado por ;
header = T) # Cabeçalho
header = T,
fill = TRUE) # Cabeçalho
# Mostrar o início dos dados
head(dados_palha10)
head(dados_palha5)
head(dados_palha0)
colnames(dados_palha10)
# Alterando o dados_palha0
# Excluindo colunas desnecessárias:
dados_palha0 <- dados_palha0[,-c(14:19)]
# Trocando nome da coluna "analogico14"
colnames(dados_palha0)[14] <- "analogico10"
# Juntando tudo em uma tabela
require(dplyr)
dados_total <- bind_rows(dados_palha10,
dados_palha5,
dados_palha0)
# Deletar a coluna "analogico9"
dados_total <- dados_total[,-13]
# Deletar os caracteres "D1=" e "D2="
# require(stringr)
# dados_total$digital1 <- str_replace(dados_total$digital1,
# "D1=", # subst. este
# "") # por este
# dados_total$digital2 <- str_replace(dados_total$digital1,
# "D2=", # subst. este
# "") # por este
# Mostrar o início dos dados
head(dados_total)
# ____________________________________________
# Atribuindo variáveis temporais ----
# ____________________________________________
require(lubridate)
# convertendo para data/dia
dados_total$data <- as.POSIXct(dados_total$data,
format = "%d/%m/%Y")
# Convertendo para hora
dados_total$hora <- as.POSIXct(dados_total$hora,
format = "%H:%M:%S")
# Classe da variável
class(dados_total$data)
class(dados_total$hora)
# Corrigindo a coluna de horas
# paste(hour(tabela_palha10$hora[1]),minute(tabela_palha10$hora[1]), sep=":")
# Início dos dados
head(dados_total$data)
207
head(dados_total$hora)
# ____________________________________________
# Convertendo as leituras para umidade percentual ----
# ____________________________________________
# Correção dos sensores com influência do datalogger profissional
dados_total$analogico2 <- dados_total$analogico2 + 38
# Fazendo cópia da planilha
dados_total2 <- dados_total
# Calculando em função das equações dos 9 sensores.
# y = ax+b
# a = tabela$a[i]
# b = tabela$b[i]
# x = dados_total[,i+4] ## colunas da tabela de dados
for (i in 1:9){
dados_total[,i+4] <- tabela$a[i]*dados_total[,i+4]+tabela$b[i]
}
# Mostra a pós-conversão
head(dados_total)
# ____________________________________________
# Conversão para o sensor 9 quebrado ----
# "tabela2" é do sensor quebrado
# "tabela" é do sensor novo
# ____________________________________________
# Calculando em função das equações dos 9 sensores.
# y = ax+b
# a = tabela$a[i]
# b = tabela$b[i]
# x = dados_total[,i+4] ## colunas da tabela de dados
for (i in 1:9){
dados_total2[,i+4] <- tabela2$a[i]*dados_total2[,i+4]+tabela2$b[i]
}
# Mostra a pós-conversão
head(dados_total2)
# ____________________________________________
# Filtrando por período de tempo (20 minutos coletados) ----
# ____________________________________________
# Separando por datas
tabela_palha10 <- dados_total2 %>%
filter(data == as.Date("2021-08-02 -03"))
tabela_palha5 <- dados_total2 %>%
tabela_palha0 <- dados_total %>%
# Separando por hora
tabela_palha10 <- tabela_palha10 %>%
filter(between(hora, # coluna de data/dia
as.POSIXct("15:21:41", # hora inicial
format = "%H:%M:%S"),
as.POSIXct("17:21:41", # hora final
format = "%H:%M:%S")))
# ____________________________________________
# Converter para o "incremento de umidade" ----
# ____________________________________________
# Para fins de comparação, será convertido todos os valores de umidade

# para o valor de incremento. Fazendo o cálculo da umidade atual menos
# o primeiro valor.
# i para colunas
# j para linhas
for (i in 1:9) {
tabela_palha10[,i+4] <- tabela_palha10[,i+4]-tabela_palha10[1,i+4]
}
# Visualizar os dados
head(tabela_palha10)
head(tabela_palha5)
head(tabela_palha0)
# Criando uma nova coluna de tratamentos
tabela_palha10[,1] <- 10
# Juntando novamente as 3 tabelas
dados_filtrados <- bind_rows(tabela_palha10,
tabela_palha5,
tabela_palha0)
# Trocar nome da variável "data" para "TRAT"
colnames(dados_filtrados)[1] <- "TRAT"
# Visualizar
head(dados_filtrados)
# Zerar valores negativos
neg <- with(dados, which(dados_filtrados<0, arr.ind=TRUE))
dados_filtrados[neg] <- 0
# Visualizar os dados
head(dados_filtrados)
# ____________________________________________
# Média dos incrementos por camada ----
# ____________________________________________
attach(dados_filtrados)
media_camada1 <- c(1:length(TRAT))
for (i in 1:length(dados_filtrados$TRAT)) {
media_camada1[i] <- mean(c(analogico4[i]))
media_camada2[i] <- mean(c(analogico2[i],
analogico5[i]))
media_camada3[i] <- mean(c(analogico6[i]),
na.rm=TRUE)
}
# for (i in 1:length(dados_filtrados$TRAT)) {
# media_camada1[i] <- analogico4[i]
# }
# Juntar as novas colunas de médias
dados_filtrados <- cbind(dados_filtrados,
media_camada1,
media_camada2,
media_camada3)
dados_filtrados
# Criar uma coluna de tempo
dados_filtrados$hora <- rep(1:length(tabela_palha10$data),
3)
length(dados_filtrados$hora)
# Renomear "hora" para "tempo
colnames(dados_filtrados)[2] <- "tempo"
# Resumir a tabela só o necessário
dados_filtrados <- dados_filtrados[,c(1,
2,
17:19)]
# Juntar as colunas em uma linha só
library(tidyr)
209
dados_alinhado <- dados_filtrados %>%

pivot_longer(
cols = c("media_camada1",
"media_camada2",
"media_camada3"),
names_to = "Camadas",
values_to = "Umidade"
)
# Guarndando na memória
attach(dados_alinhado)
# Atribuindo variáveis
TRAT <- as.character(TRAT)
# ____________________________________________
# Gráfico do experimento da palha e umidade ----
# ____________________________________________
require(ggplot2)
require(gridExtra) # forma grade
require(cowplot)
require(latex2exp)
# Renomeando as variáveis
variable_names <- list(
"media_camada1" = "0-10 cm",
"media_camada2" = "10-20 cm",
"media_camada3" = "20-30 cm"
)
variable_labeller <- function(variable,value){
return(variable_names[value])
}
# Gráficos em grade
grafico2 <- ggplot(data = dados_alinhado,
aes(x = tempo,
y = Umidade,
group = factor(TRAT))) +
geom_line(aes(colour = factor(TRAT)),
#size= 1,
labeller="Grupo") +
geom_point(aes(colour = factor(TRAT),
shape = factor(TRAT)),
size= 2) +
facet_wrap(. ~ Camadas,
ncol=3,
labeller=variable_labeller) +
labs(x = "Tempo (min)",
y = "Incremento de umidade (%)") +
scale_colour_brewer(palette = "Set1",
name = expression("Cobertura de palha (t h" * a^-1 * ")" ),
labels = c(0, 5, 10)) +
scale_shape_manual(values = c(15,16,17),
name = expression("Cobertura de palha (t h" * a^-1 * ")" ),
labels = c(0, 5, 10)) +
geom_vline(xintercept = 20,
color = "blue",
size = 0.5,
linetype = "dotted") +
theme_bw() +
theme(legend.position="bottom")
grafico2
# Salvar
#ggsave(file = "grafico_palha.svg",
# plot = grafico2,
# width = 9,
# height = 5)
# ____________________________________________
# Delineamento Inteiramente ao Acaso
# Elaborado por: Pablo Chang (27/07/2021)
# https://github.com/PabloChang/R
# ____________________________________________
# ____________________________________________
# FILTRAR OS ÚLTIMOS 10 MINUTOS ----
# ____________________________________________
head(dados_alinhado)
# Filtrar dados por categorias, quando existir:
# Exemplo: mostrar somente dados da Profundidade 2.
# (Para usar, exclua o "#" abaixo e modifique)
require(dplyr)
dados_alinhado <- filter(dados_alinhado, tempo > 110)
head(dados_alinhado)
# ____________________________________________
# TESTE DE NORMALIDADE ----
# ____________________________________________
# Pacote com alguns testes:
library(nortest)
library(ExpDes)
# Tabela de dados
dados <- data.frame(TRAT = as.factor(dados_alinhado$TRAT),
BLOCO = as.factor(dados_alinhado$Camadas),
RESP = as.numeric(dados_alinhado$Umidade))
head(dados)
attach(dados)
class(UMIDADE)
# Cálculo dos resíduos:
mod = aov(dados$RESP ~ dados$TRAT + dados$BLOCO)
# Teste Tukey
easyanova::ea1(dados, design=2, plot=2)$‘Adjusted means‘
# Gráficos de resíduos:
# Para ser normal, o histograma deve ter formato de sino no centro.
# Se o gráfico Normal Q-Q se assemelhar a uma reta crescente,
# então existe normalidade.
plotres(mod)
# Testes:
# Se p-value > 0,05, os resíduos possuem distribuição normal.
shapiro.test(mod$res) # Shapiro-Wilk
ad.test(mod$res) # Anderson-Darling
# Os resíduos são normais?
# Se SIM, rode o comando abaixo e pule para a etapa 5).
{RESP.TR <- RESP
# Se NÃO, faça a transformação em 4.1).
# ____________________________________________
# 4.1) TRANSFORMAÇÃO DE DADOS NÃO-NORMAIS ----
# ____________________________________________
# Faça os testes, até atingir a normalidade!
# TR1. Raiz quadrada:
TR1 <- sqrt(dados$RESP)
modTR1 = aov(TR1 ~ dados$TRAT)
# Gráfico dos resíduos
plotres(modTR1)}
# Testes
shapiro.test(modTR1$res) # Shapiro-Wilk
ad.test(modTR1$res) # Anderson-Darling
# TR2. Logarítmica:
# Obs: precisa excluir valores = 0.
{TR2 <- log(dados$RESP)
plotres(modTR2)}
# Testes
# TR3. Hiperbólica
{TR3 <- 1/dados$RESP
plotres(modTR3)}
# Testes
# TR4. Box-Cox
{require(MASS)
# Cálculo
211
par(mfrow=c(1, 1))
bc=boxcox(RESP ~ TRAT, data=dados, plotit=T)
lambda.max <- bc$x[which.max(bc$y)]
lambda.max # Se for próximo de zero, usar logarítmico (TR2).
TR4 <- (RESP^(lambda.max)-1)/lambda.max
modTR4 = aov(TR4 ~ TRAT)
plotres(modTR4)}
# Testes
# Digite o TR escolhido dentro de ( ):
RESP.TR <-
(dados$RESP) # troque aqui, por exemplo: (TR2).
# Com isso, as próximas análises irão usar os
# dados transformados!
# ____________________________________________
# 5) TESTE DE HOMOCEDASTICIDADE DAS VARIÂNCIAS ----
# ____________________________________________
# Isso implica que cada tratamento que está sendo
# comparado pelo teste F, deve ter aproximadamente
# a mesma variância para que a ANOVA tenha validade.
# Redefinição de dados:
{
dados.TR <- data.frame(dados$TRAT, dados$BLOCO, RESP.TR)
attach(dados.TR)
TRAT <- as.factor(dados$TRAT)
RESP.TR <- as.numeric(RESP.TR)
mod.TR <- aov(RESP.TR ~ TRAT)
}
# Teste de Bartlett:
# Se p-value > 0,05, há homogeneidade das variâncias.
bartlett.test(mod$res ~ dados$TRAT)
# Boxplot de tratamentos vs resíduos:
# Se os boxplots forem semelhantes, há homocedasticidade.
{
par(mfrow=c(1, 1))
boxplot(mod.TR$res ~ TRAT)
}
# ____________________________________________
# 6) TESTE DE INDEPENDÊNCIA ----
# ____________________________________________
# Os dados são aleatórios e independentes.
# Ou seja, uma observação não influencia na outra
# e não existe influência do tempo ou local da coleta.
# Teste de Durbin-Watson:
# Se p-value > 0,05, então há independência.
{
require(lmtest)
dwtest(mod)
}
# Gráfico de resíduos padronizados vs valores ajustados
# (Standardized Residuals vs Fitted Values):
# Se os pontos forem aleatórios e espalhados,
# então os dados são aleatórios e independentes;
# Se apresentar uma tendência, então há dependência.
plotres(mod.TR)
# ____________________________________________
# 7) ANOVA - análise de variância ----
# ____________________________________________
# Tabela ANOVA
# Se Pr(>F) < 0,05, então existe diferença
# significativa a 5%.
# df=graus de liberdade. Pr=probabilidade
# de ser maior que F tabelado.
summary(mod)
# Exportar tabela ANOVA para Excel:
write.csv2(
as.data.frame(summary(mod)[[1]]),
file =
"Palha - Tabela ANOVA.csv")

# ____________________________________________
# 8) TESTE DE COMPARAÇÃO DE MÉDIAS ----
# ____________________________________________
# Teste Tukey, SNL (Student-Newman-Keuls), Duncan, t e
# Scott-Knott a 5% de significância.
# Tabela usando dados transformados (quando for o caso),
# mas mostrando médias originais:
{
require(easyanova)
require(dplyr)
par(mfrow=c(1, 1))
ttuk <- easyanova::ea1(dados, design=2, plot=2)
teste <- arrange(ttuk$‘Adjusted means‘, ttuk$‘Adjusted means‘$treatment)
ttuk.o <- easyanova::ea1(dados, design=2, plot=2)
teste.o <- arrange(ttuk.o$‘Adjusted means‘, ttuk.o$‘Adjusted means‘$treatment)
teste$mean <- teste.o$mean
colnames(teste) <- c(
"Tratamentos",
"Médias",
"Erro padrão",
"Tukey",
"SNK",
"Duncan",
"t",
"Scott-Knott"
)
teste
}
#write.csv2(teste, file =
# "Palha - Testes de Comparação de Médias.csv")
# ____________________________________________
# 9) DMS - Diferença Mínima Significativa do teste Tukey ----
# ____________________________________________
# Valor que retrata a diferença mínima para que duas
# médias tenham diferença significativa a 5%.
# Cálculo do DMS com transformação inversa:
t.HSD <- TukeyHSD(mod, ordered=TRUE)
dms <- unname(0.5*diff(t.HSD$’dados$TRAT’[1, 2:3]))
dms # Valor do DMS
# ____________________________________________
# 10) TABELA RESUMIDA (COM TESTE TUKEY) ----
# ____________________________________________
{
tabela <- data.frame(
Tratamentos = c(
teste$Tratamentos,
"Média Geral",
"CV (%)",
"DMS"),
Médias = c(
teste$Médias,
mean(RESP),
100*sd(RESP)/mean(RESP),
dms),
Tukey =
c(
as.character(teste$Tukey),
" ",
" ",
" "),
stringsAsFactors = FALSE)
tabela
}
# Pode acumular resultados de testes anteriores num mesmo arquivo.
# Pode colocar títulos diferentes em "TÍTULO":
# write.csv2(tabela, file =
# "Palha - Tabela Resumida.csv")
213
# ____________________________________________
# 11) GRÁFICO DE BARRAS DE TUKEY ----
# ____________________________________________
{
my_bar <- barplot(teste$Médias,
ylim=c(0, 1.3*max(teste$Médias)),
beside=T,
col="darkseagreen1",
names.arg = teste$Tratamentos,
xlab="Anos de avaliação",
ylab="Médias de notas")
# Barras de erro padrão médio
mean.worm = tapply(dados$RESP, dados$TRAT, mean) # média
sd.worm = tapply(dados$RESP, dados$TRAT,sd) # desvio padrão
n.worm = tapply(dados$RESP, dados$TRAT, length) # número por grupo
sem.worm = sd.worm/sqrt(n.worm) # erro padrão
mean.worm-sem.worm
arrows(my_bar,
mean.worm-sem.worm,
my_bar,
mean.worm + sem.worm,
code = 3,
angle = 90,
length = 0.1)
# Letras do Tukey
text(my_bar,
0.1*max(teste$Médias),
teste$Tukey, cex=1)
}
# ____________________________________________
# COMPARAÇÃO ENTRE DATALOGGER ACADÊMICO X PROFISSIONAL
# Criado em: 01/09/21
# Atualizado em: 08/11/21
library(tidyr)
require(dplyr)
# ____________________________________________
# DATALOGGER PROFISSIONAL ----
#
#
# ____________________________________________
# ____________________________________________
# Leitura e preparação dos dados # PROFISSIONAL ----
# ____________________________________________
# Comando para definir a localização da pasta:
{
library(rstudioapi) # precisa ter instalado o pacote "rstudioapi"
current_path =
rstudioapi::getActiveDocumentContext()$path
setwd(dirname(current_path ))
print( getwd() )
}
# Troque o nome do arquivo de dados (entre " .csv"):
dados <- read.csv(
"dados_experimento/082170EA.csv",
header = T)
# Mostra as 6 primeiras linhas para visualização.
# As colunas devem seguir a ordem: tratamento // resposta;
head(dados)
# Resumir as colunas
dados <- dados[,c(1:3)]
head(dados)
# Selecionando as variáveis
A1 <- dados$data[dados$name == "A1"]
# Obs: eu tive que resumir manualmente no .csv, porque o
# A4 estava tendo 2 números faltantes! E isso compromete
# na minha estratégia de organização!!
# ____________________________________________

# ____________________________________________
require(lubridate)
dados$date <- as.POSIXct(dados$date,
format = "%m/%d/%Y %H:%M:%S")
class(dados$date)
# Cabeçalho
head(dados)
# Limpar dados vazios, apenas deixando as linhas de datas:
tempo <- na.omit(dados)
tempo <- tempo[,1]
head(tempo)
# Juntando tudo numa tabela só:
dados_total <- data.frame(tempo, A1, A2, A3, A4)
head(dados_total)
# ____________________________________________
# ____________________________________________
filter(between(tempo, # coluna de data/dia
as.POSIXct("2021-08-02 15:21:41"),
as.POSIXct("2021-08-02 17:21:41")))
as.POSIXct("2021-08-09 11:26:50"),
as.POSIXct("2021-08-09 13:26:50")))
as.POSIXct("2021-08-16 12:52:20"),
as.POSIXct("2021-08-16 14:52:20")))
# ____________________________________________
# Reorganizando a tabela para ANOVA ----
# ____________________________________________
# Juntar as 3 tabelas
tabela_uni <- bind_rows(tabela_palha10,
tabela_palha5,
tabela_palha0)
tabela_uni$duracao <- rep(1:length(tabela_palha10$tempo),
3)
tabela_uni$Palha <- rep(c("10", "5", "0"),
each = length(tabela_palha10$tempo))
# Deletar primeira coluna
tabela_uni <- tabela_uni[,-1]
library(tidyr)
dados_profissional <- tabela_uni %>%
pivot_longer(
cols = c("A1",
"A2",
"A3",
"A4"),
names_to = "Sensor")
# ____________________________________________
# DATALOGGER ACADÊMICO ----
#
#
# ____________________________________________
# ____________________________________________
# Leitura dos dados ----
# ____________________________________________
215
header = T,
fill = TRUE) # Cabeçalho
# Escolhendo apenas 4 sensores
dados_palha10 <- dados_palha10[,c(1:2, 6, 8:10)]
head(dados_palha10)
head(dados_palha5)
head(dados_palha0)
# Juntando tudo em uma tabela
require(dplyr)
dados_total <- bind_rows(dados_palha10,
dados_palha5,
dados_palha0)
# ____________________________________________
# ____________________________________________
require(lubridate)
dados_total$data <- as.POSIXct(dados_total$data,
format = "%d/%m/%Y")
# Convertendo para hora
dados_total$hora <- as.POSIXct(dados_total$hora,
format = "%H:%M:%S")
class(dados_total$data)
class(dados_total$hora)
# Início dos dados
head(dados_total$data)
# ____________________________________________
# ____________________________________________
# Separando por datas
# Separando por hora
# ____________________________________________
# Reorganizando a tabela para ANOVA ----
# ____________________________________________
# Juntar as 3 tabelas
tabela_uni <- bind_rows(tabela_palha10,
tabela_palha5,
tabela_palha0)
tabela_uni$duracao <- rep(1:length(tabela_palha10$data),
3)
# Criar uma coluna de palha
tabela_uni$Palha <- rep(c("10", "5", "0"),
each = length(tabela_palha10$data))
# Selecionar apenas o que precisa
tabela_uni2 <- tabela_uni[,c(7,8,3:6)]
# Renomear as variáveis
colnames(tabela_uni2) <- c("duracao",
"Palha",
"A1",
"A2",
"A3",
"A4")
head(tabela_uni2)
library(tidyr)
dados_academico <- tabela_uni2 %>%
pivot_longer(
cols = c("A1",
"A2",
"A3",
"A4"),
names_to = "Sensor")
head(dados_academico)
# ____________________________________________
# COMPARANDO OS 2 DATALOGGERS ----
#
#
# ____________________________________________
# Criando uma coluna a mais sobre tipo do datalogger
dados_profissional$datalogger <- rep("Profissional",
length(dados_profissional$duracao))
dados_academico$datalogger <- rep("Academico",
length(dados_academico$duracao))
# Juntando as duas tabelas
require(dplyr)
dados <- bind_rows(dados_profissional, dados_academico)
head(dados)
attach(dados)
# Diferença média entre os dois dataloggers
difer <- mean(dados$value[dados$datalogger == "Profissional"])-
mean(dados$value[dados$datalogger == "Academico"])
difer
dados$value[dados$datalogger == "Profissional"] <-
dados$value[dados$datalogger == "Profissional"]-difer
# Filtrar apenas Datalogger profissional
require(dplyr)
valores_prof <- filter(dados, datalogger=="Profissional")
medias_prof <- tapply(valores_prof$value,
valores_prof$duracao,
mean)
# Filtrar apenas Datalogger profissional
valores_acd <- filter(dados, datalogger=="Academico")
medias_acd <- tapply(valores_acd$value,
valores_acd$duracao,
mean)
# Gráfico-teste
plot(medias_acd)
lines(medias_prof,
col="red")
t.test(medias_acd,
medias_prof)
td_acd <- dados$value[dados$datalogger == "Academico"]
td_prof <- dados$value[dados$datalogger == "Profissional"]
217
# ____________________________________________
# Correlação de Pearson ----
# ____________________________________________
# Correlação de Pearoson
cor_pear <- cor(td_acd, td_prof)
cor_pear
# Correlação com significância
cor.test(td_acd, td_prof)
# ____________________________________________
# Correlação de Spearman ----
# ____________________________________________
# Correlação de Spearman
spearman <- cor(td_acd, td_prof, method=c("spearman"))
spearman
# Correlação com significância
cor.test(td_acd, td_prof, method=c("spearman"))
# --------------------------------------------
# 12) Gráfico de comparação
# --------------------------------------------
# Legenda
require(latex2exp)
texto <- TeX(sprintf(r’($ r = %.3f $)’,
cor_pear))
plot(texto)
# Organizar para gráfico
tb <- data.frame(intervalo = c(1:length(tabela_palha10$data)),
medias_acd,
medias_prof)
tb2 <- tb %>% pivot_longer(
cols = c(medias_acd,
medias_prof),
names_to = "Datalogger"
)
head(tb2)
attach(tb2)
# Gráfico
require(ggplot2)
grafico <- ggplot(data = tb2,
aes(x = intervalo,
y = value),
group = factor(Datalogger)) +
geom_line(aes(colour = factor(Datalogger))) +
labs(x = "Tempo (min)",
y = "Leitura do sensor") +
scale_colour_brewer(palette = "Set1",
name = expression("Datalogger"),
labels = c("Acadêmico",
"Profissional")) +
theme_bw() +
theme(legend.position = c(0.9, 0.85)) +
annotate("text",
x = min(intervalo)*110,
y = min(value),
label= texto,
hjust= 0)
grafico
# Salvar
ggsave(file = "grafico_academicovsprofissional.svg",
plot = grafico,
width = 9,
height = 4)
# ____________________________________________
# Delineamento Inteiramente ao Acaso
# Elaborado por: Pablo Chang (27/07/2021)
# https://github.com/PabloChang/R
# ____________________________________________
# ____________________________________________
# FILTRAR OS ÚLTIMOS 10 MINUTOS ----
# ____________________________________________
head(tb2)
# Filtrar dados por categorias, quando existir:
# Exemplo: mostrar somente dados da Profundidade 2.
# (Para usar, exclua o "#" abaixo e modifique)
require(dplyr)
tb2 <- filter(tb2, intervalo > 110)
head(tb2)
# ____________________________________________
# TESTE DE NORMALIDADE ----
# ____________________________________________
# Pacote com alguns testes:
library(nortest)
library(ExpDes)
# Tabela de dados
dados <- data.frame(TRAT = as.factor(tb2$Datalogger),
RESP = as.numeric(tb2$value))
# dados <- data.frame(TRAT = as.factor(dados_alinhado$TRAT),
# BLOCO = as.factor(dados_alinhado$Camadas),
# RESP = as.numeric(dados_alinhado$Umidade))
head(dados)
attach(dados)
# Cálculo dos resíduos:
mod = aov(RESP ~ dados$TRAT)
# mod = aov(RESP ~ dados$TRAT + dados$BLOCO)
# Gráficos de resíduos:
# Para ser normal, o histograma deve ter formato de sino no centro.
# Se o gráfico Normal Q-Q se assemelhar a uma reta crescente,
# então existe normalidade.
plotres(mod)
# Testes:
# Se p-value > 0,05, os resíduos possuem distribuição normal.
shapiro.test(mod$res) # Shapiro-Wilk
ad.test(mod$res) # Anderson-Darling
# Os resíduos são normais?
# Se SIM, rode o comando abaixo e pule para a etapa 5).
{RESP.TR <- RESP
# Se NÃO, faça a transformação em 4.1).
# ____________________________________________
# 4.1) TRANSFORMAÇÃO DE DADOS NÃO-NORMAIS ----
# ____________________________________________
# Faça os testes, até atingir a normalidade!
{TR1 <- sqrt(dados$RESP)
plotres(modTR1)}
# Testes
# Obs: precisa excluir valores = 0.
{TR2 <- log(dados$RESP)
plotres(modTR2)}
# Testes
# TR3. Hiperbólica
{TR3 <- 1/dados$RESP
plotres(modTR3)}
# Testes
# TR4. Box-Cox
{require(MASS)
# Cálculo
219
par(mfrow=c(1, 1))
bc=boxcox(RESP ~ TRAT, data=dados, plotit=T)
lambda.max <- bc$x[which.max(bc$y)]
lambda.max # Se for próximo de zero, usar logarítmico (TR2).
TR4 <- (RESP^(lambda.max)-1)/lambda.max
modTR4 = aov(TR4 ~ TRAT)
plotres(modTR4)}
# Testes
# Digite o TR escolhido dentro de ( ):
RESP.TR <-
(dados$RESP) # troque aqui, por exemplo: (TR2).
# Com isso, as próximas análises irão usar os
# dados transformados!
}
# ____________________________________________
# 5) TESTE DE HOMOCEDASTICIDADE DAS VARIÂNCIAS ----
# ____________________________________________
# Isso implica que cada tratamento que está sendo
# comparado pelo teste F, deve ter aproximadamente
# a mesma variância para que a ANOVA tenha validade.
# Redefinição de dados:
{
dados.TR <- data.frame(dados$TRAT, RESP.TR)
attach(dados.TR)
TRAT <- as.factor(dados$TRAT)
RESP.TR <- as.numeric(RESP.TR)
mod.TR <- aov(RESP.TR ~ TRAT)
}
# Teste de Bartlett:
# Se p-value > 0,05, há homogeneidade das variâncias.
bartlett.test(mod.TR$res ~ TRAT)
# Boxplot de tratamentos vs resíduos:
# Se os boxplots forem semelhantes, há homocedasticidade.
{
par(mfrow=c(1, 1))
boxplot(mod.TR$res ~ TRAT)
}
# ____________________________________________
# 6) TESTE DE INDEPENDÊNCIA ----
# ____________________________________________
# Os dados são aleatórios e independentes.
# Ou seja, uma observação não influencia na outra
# e não existe influência do tempo ou local da coleta.
# Teste de Durbin-Watson:
# Se p-value > 0,05, então há independência.
{
require(lmtest)
dwtest(mod.TR)
}
# Gráfico de resíduos padronizados vs valores ajustados
# (Standardized Residuals vs Fitted Values):
# Se os pontos forem aleatórios e espalhados,
# então os dados são aleatórios e independentes;
# Se apresentar uma tendência, então há dependência.
plotres(mod.TR)
# ____________________________________________
# 7) ANOVA - análise de variância ----
# ____________________________________________
# Tabela ANOVA
# Se Pr(>F) < 0,05, então existe diferença
# significativa a 5%.
# df=graus de liberdade. Pr=probabilidade
# de ser maior que F tabelado.
summary(mod.TR)
# Exportar tabela ANOVA para Excel:
write.csv2(
as.data.frame(summary(mod.TR)[[1]]),
file =
"prof x acd - Tabela ANOVA.csv")
# ____________________________________________
# 8) TESTE DE COMPARAÇÃO DE MÉDIAS ----
# ____________________________________________
# Teste Tukey, SNL (Student-Newman-Keuls), Duncan, t e
# Scott-Knott a 5% de significância.
# Tabela usando dados transformados (quando for o caso),
# mas mostrando médias originais:
{
require(easyanova)
require(dplyr)
par(mfrow=c(1, 1))
ttuk <- easyanova::ea1(dados.TR, design=1, plot=2)
teste <- arrange(ttuk$Means, ttuk$Means$treatment)
ttuk.o <- easyanova::ea1(dados, design=1, plot=2)
teste.o <- arrange(ttuk.o$Means, ttuk.o$Means$treatment)
teste$mean <- teste.o$mean
colnames(teste) <- c(
"Tratamentos",
"Médias",
"Erro padrão",
"Tukey",
"SNK",
"Duncan",
"t",
"Scott-Knott"
)
teste
}
write.csv2(teste, file =
"prof x acd - Testes de Comparação de Médias.csv")
# ____________________________________________
# 9) DMS - Diferença Mínima Significativa do teste Tukey ----
# ____________________________________________
# Valor que retrata a diferença mínima para que duas
# médias tenham diferença significativa a 5%.
# Cálculo do DMS com transformação inversa:
{
t.HSD <- TukeyHSD(mod.TR, ordered=TRUE)
dms <- unname(0.5*diff(t.HSD$TRAT[1, 2:3]))
LimSup <- mean(RESP.TR)
LimInf <- LimSup-dms
if(RESP.TR != RESP){
if(RESP.TR == TR1){
dms <- (LimSup)^2-(LimInf)^2
}
if(RESP.TR == TR2){
dms <- exp(LimSup)-exp(LimInf)
}
# TR3. Hiperbólica:
if(RESP.TR == TR3){
dms <- (LimSup)^(-1)-(LimInf)^(-1)
}
# TR4. Box-Cox:
if(RESP.TR == TR4){
dms <- ((LimSup*lambda.max)+1)^(1/lambda.max) -
((LimInf*lambda.max)+1)^(1/lambda.max)
}
}
}
dms # Valor do DMS
# ____________________________________________
# 10) TABELA RESUMIDA (COM TESTE TUKEY) ----
# ____________________________________________
{
tabela <- data.frame(
221
Tratamentos = c(
teste$Tratamentos,
"Média Geral",
"CV (%)",
"DMS"),
Médias = c(
teste$Médias,
mean(RESP),
100*sd(RESP)/mean(RESP),
dms),
Tukey =
c(
as.character(teste$Tukey),
" ",
" ",
" "),
stringsAsFactors = FALSE)
tabela
}
# Pode acumular resultados de testes anteriores num mesmo arquivo.
# Pode colocar títulos diferentes em "TÍTULO":
if(file.exists("DIC - Tabela Resumida.csv")){
tabela.comb <- read.csv2(file="DIC - Tabela Resumida.csv")
tabela.comb <- cbind(tabela.comb, "TÍTULO", tabela)
write.csv2(tabela.comb, file =
"DIC - Tabela Resumida.csv")
}else{
write.csv2(tabela, file =
"DIC - Tabela Resumida.csv")
}
# ____________________________________________
# 11) GRÁFICO DE BARRAS DE TUKEY ----
# ____________________________________________
{
my_bar <- barplot(teste$Médias,
ylim=c(0, 1.3*max(teste$Médias)),
beside=T,
col="darkseagreen1",
names.arg = teste$Tratamentos,
xlab="Anos de avaliação",
ylab="Médias de notas")
# Barras de erro padrão médio
mean.worm = tapply(dados$RESP, dados$TRAT, mean) # média
sd.worm = tapply(dados$RESP, dados$TRAT,sd) # desvio padrão
n.worm = tapply(dados$RESP, dados$TRAT, length) # número por grupo
sem.worm = sd.worm/sqrt(n.worm) # erro padrão
mean.worm-sem.worm
arrows(my_bar,
mean.worm-sem.worm,
my_bar,
mean.worm + sem.worm,
code = 3,
angle = 90,
length = 0.1)
# Letras do Tukey
text(my_bar,
0.1*max(teste$Médias),
teste$Tukey, cex=1)
}
Figura 53 – Teste em ambiente de campo

(a) Sensor utilizado para leitura em local (b) Protótipo com as respectivas ligações
de instalação para leitura do sensor
Fonte: Autor
Figura 54 – Dados coletados pelo teste realizado em 06/02/2021
Fonte: Autor
223
Figura 55 – Teste em ambiente de laboratório

(a) Amostra de solo com a instalação de (b) Amostra de solo com 50% de sua área
dois sensores de umidade molhada
Fonte: Autor
Anexos
227
ANEXO A – Datasheet do sensor de vazão

de água
MODEL: YF-S201
Description:
Water flow sensor consists of a plastic valve body, a water rotor, and a hall-effect sensor. When water flows through the rotor, rotor rolls. Its speed changes with
different rate of flow. The hall-effect sensor outputs the corresponding pulse signal. This one is suitable to detect flow in water dispenser or coffee machine. We
have a comprehensive line of water flow sensors in different diameters. Check them out to find the one that meets your need most.
Features:
Compact, Easy to Install
High Sealing Performance
High Quality Hall Effect Sensor
RoHS Compliant
Specifications:
Working Voltage: DC 4.5V~24V
Normal Voltage: DC 5V~18V
Max. Working Current: 15mA (DC 5V)
Load capacity: ≤ 10 mA (DC 5V)
Flow Rate Range: 1~30L/min
Load Capacity: ≤10mA (DC 5V)
Operating Temperature: ≤80℃
Liquid Temperature: ≤120℃
Operating Humidity: 35%～90%RH
Allowing Pressure: ≤1.75MPa
Storage Temperature: -25～+ 80℃
Storage Humidity: 25%～95%RH
Electric strength 1250V/min
Insulation resistance ≥ 100MΩ
External threads: 1/2"
Outer diameter: 20mm
Intake diameter: 9mm
Outlet diameter: 12mm
Application:
Water heaters, credit card machines, water vending machine, flow measurement device!
Cercuit: Red: Positive

Black: GND
Yellow: Output signal
Flow Range: 100L/H-/1800H-L/H

Flow (L/H) Frezq.(Hz) Erro range
120 16
240 32.5
360 49.3 ±10
480 65.5 5%
600 82
720 90.2
N° Item Material
1 Wire PVC
2 Bonnet PA
3 Screw Zinc Plated
4 Valve Body PA
5 Press Valve
6 Magnet
7 Hall
8 Impeller POM
9 Steel Sharft SUS304
Closed
229
ANEXO B – Datasheet do sensor

ultrassônico
Tech Support: services@elecfreaks.com
Ultrasonic Ranging Module HC - SR04
 Product features:
Ultrasonic ranging module HC - SR04 provides 2cm - 400cm non-contact

measurement function, the ranging accuracy can reach to 3mm. The modules
includes ultrasonic transmitters, receiver and control circuit. The basic principle
of work:
(1) Using IO trigger for at least 10us high level signal,
(2) The Module automatically sends eight 40 kHz and detect whether there is a
pulse signal back.
(3) IF the signal back, through high level , time of high output IO duration is
the time from sending ultrasonic to returning.
Test distance = (high level time×velocity of sound (340M/S) / 2,
 Wire connecting direct as following:
5V Supply
Trigger Pulse Input
Echo Pulse Output
0V Ground
Electric Parameter
Working Voltage DC 5 V
Working Current 15mA
Working Frequency 40Hz
Max Range 4m
Min Range 2cm
MeasuringAngle 15 degree
Trigger Input Signal 10uS TTL pulse
Echo Output Signal Input TTL lever signal and the range in
proportion
Dimension 45*20*15mm
Vcc Trig Echo GND
Timing diagram
The Timing diagram is shown below. You only need to supply a short 10uS
pulse to the trigger input to start the ranging, and then the module will send out
an 8 cycle burst of ultrasound at 40 kHz and raise its echo. The Echo is a
distance object that is pulse width and the range in proportion .You can
calculate the range through the time interval between sending trigger signal and
receiving echo signal. Formula: uS / 58 = centimeters or uS / 148 =inch; or: the
range = high level time * velocity (340M/S) / 2; we suggest to use over 60ms
measurement cycle, in order to prevent trigger signal to the echo signal.
 Attention:
 The module is not suggested to connect directly to electric, if connected

electric, the GND terminal should be connected the module first, otherwise,
it will affect the normal work of the module.
 When tested objects, the range of area is not less than 0.5 square meters
and the plane requests as smooth as possible, otherwise ,it will affect the
results of measuring.
www.Elecfreaks.com
233
ANEXO C – Figuras revisão bibliográfica
Figura 56 – Interface de coleta e módulo de armazenamento

(a) Interface de coleta. (b) Módulo de armazenamento.
Fonte: Abdalla (2015)
Figura 57 – Datalogger desenvolvido pelo autor, com destaque ao módulo RTC e ao módulo
SD-Card
Fonte: Galdino et al. (2019)

234 ANEXO C. Figuras revisão bibliográfica
Figura 58 – Datalogger criado por Netto e Arigony-Neto (2019)
Fonte: Netto e Arigony-Neto (2019)
Figura 59 – PCB criada por Pereira (2013) utilizando microcontrolador ATMEL, e Shield
do cartão SD, respectivamente
(a) PCB utilizando microcontrolador Arduino. (b) Shield do cartão SD.
Fonte: Pereira (2013)

235
Figura 60 – Visualização renderizada da placa de circuito impresso (PCB) criada por

Reges (2017)
Fonte: Reges (2017)

236 ANEXO C. Figuras revisão bibliográfica
Figura 61 – Montagem do protótipo de datalogger proposto por López-Vargas et al. (2018)
Fonte: López-Vargas et al. (2018)

Édipo Carneiro2022

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Édipo Carneiro2022

Enviado por

Direitos autorais:

Formatos disponíveis

Édipo Alexandre Pereira Carneiro

Desenvolvimento de um datalogger configurável

Desenvolvimento de um datalogger configurável e de

Dissertação apresentada como requisito par-

Universidade Estadual do Oeste do Paraná – Unioeste – Cascavel

Orientador: Dr. Rogério Luis Rizzi

Orientador: Dr. Rogério Luis Rizzi

Dissertação (Mestrado) – Universidade Estadual do Oeste do Paraná – Unioeste – Cascavel

Desenvolvimento de um datalogger configurável e de

Dissertação apresentada como requisito par-

Dr. Rogério Luis Rizzi

Dra. Claudia Brandelero Rizzi

Dr. Marcio Seiji Oyamada

Dr. Ivonei Freitas da Silva

Dr. Fernando de Lima Alves

Palavras-chave Datalogger, Metodologia Ágil, Arduino, Raspberry, Dados ambientais.

Keywords: Datalogger, Agile methodology, Arduino, Raspberry, Environmental data.

Figura 1 – Camadas de desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . 30

Quadro 1 – Comparativo entre projetos acadêmicos pesquisados . . . . . . . . . . 56

Tabela 1 – Sensores utilizados no projeto de Abdalla (2015) . . . . . . . . . . . . 36

ANOVA Análise de Variância

ARM Advanced RISC Machine

CEMADEM Centro Nacional de Monitoramento e Alertas de Desastres Naturais

DBC Delineamento em Blocos Casualizados

DIC Delineamento Inteiramente Casualizado

FTP File Transfer Protocol

GPS Global Positioning System

HTTP Hypertext Transfer Protocol

I2C Inter-Integrated Circuit

IEC Comissão Eletrotécnica Internacional

IEQ Qualidade Ambiental em Ambientes Internos

ISR Interrupt Service Routine

LED Light-Emitting Diode

NTP Network Time Protocol

mca Metros de Coluna D’Agua

PCB Printed Circuit Board

PCI Placa de Circuito Impresso

PHP Hypertext Preprocessor

PWM Pulse Width Modulation

RS232 Recommended Standard 232

RS485 Recommended Standard 485

RTC Real Time Clock

SMTP Simple Mail Transfer Protocol

TTL Transistor-Transistor Logic

UFMT Universidade Federal do Mato Grosso

VDC Volts Direct Current

VOC Volatile organic compound

6 TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . 115

APÊNDICE A – DOCUMENTO DE REQUISITOS . . . . . . . . . 123

APÊNDICE B – MANUAL DE INSTALAÇÃO DO AMBIENTE DE

APÊNDICE C – CÓDIGO FONTE DO FIRMWARE DO DATA-

APÊNDICE D – ROTEIRO EM R DAS ANÁLISES DE DADOS . . 203

ANEXO A – DATASHEET DO SENSOR DE VAZÃO DE ÁGUA . 227

ANEXO B – DATASHEET DO SENSOR ULTRASSÔNICO . . . . 229

A principal motivação para o desenvolvimento dessa dissertação de mestrado foi

1.2 Objetivos, Geral e Específicos

1. Levantamento bibliográfico para avaliação de aspectos técnicos e metodológicos das

2. A criação de um protótipo de hardware de baixo custo para leitura e registro dos

3. O projeto e desenvolvimento, fazendo uso de metodologias ágeis, de um firmware

4. Fundamentação detalhada da metodologia adotada para o desenvolvimento das

5. A realização de atividades específicas para a calibração do protótipo e a análise de

1.3 Justificativa e relevância do trabalho

1.4 Organização do trabalho