Disserta Assinatura

Instituto Federal de Educação, Ciência e Tecnologia da Paraíba
Campus João Pessoa

Programa de Pós-Graduação em Tecnologia da Informação
Nível Mestrado Profissional
ÁTILA DE SOUZA MEDEIROS
MONITORAMENTO E MEDIÇÃO DE ÁGUA EM UM

CAMPUS INTELIGENTE COM PLATAFORMAS DE IOT
DISSERTAÇÃO DE MESTRADO
JOÃO PESSOA
2023
Átila de Souza Medeiros
Monitoramento e medição de água em um campus inteligente

com plataformas de IoT
Dissertação apresentada como requisito parcial

para obtenção do título de Mestre em Tecno-
logia da Informação, pelo Programa de Pós-
Graduação em Tecnologia da Informação do
Instituto Federal de Educação, Ciência e Tec-
nologia da Paraíba – IFPB.
Orientador: Profº. D.Sc. Ruan Delgado Gomes.

Coorientador: Profº. D.Sc. Anderson Fabiano
Batista Ferreira da Costa.
João Pessoa
2023
Dados Internacionais de Catalogação na Publicação (CIP)
Biblioteca Nilo Peçanha do IFPB, campus João Pessoa
M488m Medeiros, Átila de Souza.

Monitoramento e medição de água em um campus inteligente
com plataformas de IoT/ Átila de Souza Medeiros. – 2023.
132 f. : il.
Dissertação (Mestrado -Tecnologia da Informação) – Instituto
Federal de Educação, Ciência e Tecnologia da Paraíba, Programa
de Pós-Graduação em Tecnologia da Informação, João Pessoa, PB,
2023.
Orientador: Profº. D.Sc. Ruan Delgado Gomes.
Coorientador: Profº. D.Sc. Anderson Fabiano Batista Ferreira da
Costa.
1. Medição inteligente de água 2. Metrologia - tecnologias 3.

Dojot 4. Plataforma IoT 5. LoRa® I. Título
CDU 628.17:004(043)
Lucrecia Camilo de Lima

Bibliotecária - CRB 15/132
MINISTÉRIO DA EDUCAÇÃO
SECRETARIA DE EDUCAÇÃO PROFISSIONAL E TECNOLÓGICA
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DA PARAÍBA
PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU
MESTRADO PROFISSIONAL EM TECNOLOGIA DA INFORMAÇÃO
ÁTILA DE SOUZA MEDEIROS
MONITORAMENTO E MEDIÇÃO DE ÁGUA EM UM CAMPUS INTELIGENTE COM PLATAFORMAS

DE IOT
Dissertação apresentada como requisito para obtenção do

título de Mestre em Tecnologia da Informação, pelo Programa
de Pós- Graduação em Tecnologia da Informação do Instituto
Federal de Educação, Ciência e Tecnologia da Paraíba –
IFPB - Campus João Pessoa.
Aprovado em 15 de fevereiro de 2023
Membros da Banca Examinadora:

Dr. Ruan Delgado Gomes
IFPB - PPGTI
Dr. Anderson Fabiano Batista Ferreira da Costa
IFPB - PPGTI
Dra. Luciana Pereira Oliveira
IFPB - PPGTI
Dr. José Antônio Cândido Borges da Silva
IFPB - Campus Campina Grande
Dr. Abel Cavalcante Lima Filho
UFPB
João Pessoa/2023
Documento assinado eletronicamente por:

Ruan Delgado Gomes,
Gomes PROFESSOR ENS BASICO TECN TECNOLOGICO,
TECNOLOGICO em 15/02/2023 17:00:19.
Luciana Pereira Oliveira,
Oliveira PROFESSOR ENS BASICO TECN TECNOLOGICO,
TECNOLOGICO em 15/02/2023 17:02:52.
Anderson Fabiano Batista Ferreira da Costa,
Costa PROFESSOR ENS BASICO TECN TECNOLOGICO,
TECNOLOGICO em 15/02/2023 17:16:30.
Jose Antonio Candido Borges da Silva, PROFESSOR ENS BASICO TECN TECNOLOGICO,
TECNOLOGICO em 18/02/2023 12:41:02.
Abel Cavalcante Lima Filho,
Filho PROFESSOR DE ENSINO SUPERIOR NA ÁREA DE ORIENTAÇÃO EDUCACIONAL,
EDUCACIONAL em 02/03/2023 15:35:55.
Este documento foi emi do pelo SUAP em 13/02/2023. Para comprovar sua auten cidade, faça a leitura do QRCode ao lado ou acesse h ps://suap.ifpb.edu.br/auten car-
documento/ e forneça os dados abaixo:
Código 388753
Verificador: 14cb8bed69
Código de Autenticação:
Av. Primeiro de Maio, 720, Jaguaribe, JOÃO PESSOA / PB, CEP 58015-435
http://ifpb.edu.br - (83) 3612-1200
Este trabalho é dedicado às crianças adultas que,
quando pequenas, sonharam em se tornar cientistas.
RESUMO
A escassez de recursos hídricos é uma realidade que assola diversos países no mundo e tende a
se agravar nos próximos anos em virtude do crescimento populacional, das mudanças climáticas
e da má gestão dos sistemas de distribuição de água, principalmente em países subdesenvolvidos,
no qual os índices de perdas de água potável nesses sistemas são alarmantes. No Brasil, dados do
Sistema Nacional de Informações sobre Saneamento (SNIS) informam que o indicador médio
de perda de água potável não contabilizada ou perdida na distribuição em 2021 chegou ao
impactante índice de 40,14%, ou seja, a cada 100 litros de água tratada, mais de 40 litros são
desperdiçados ao longo do sistema de distribuição de água. Uma saída para melhorar a gestão
dos recursos hídricos e reduzir indicadores de perdas em sistemas de distribuição de água está
em soluções IoT (Internet of Things) de sistemas de monitoramento e “medição inteligente de
água” (Smart Water Metering), no qual medidores inteligentes de água (Smart Water Meters)
permitem o monitoramento e a medição em tempo real de diversos parâmetros do sistema, como
por exemplo: pressão, vazão e qualidade da água, como também possibilitam o acionamento
de válvulas e bombas hidráulicas de forma remota e automática. Com isso, o uso de soluções
IoT vem ganhando cada vez mais destaque e popularidade tanto no âmbito comercial quanto no
âmbito acadêmico, no qual as universidades desempenham um papel fundamental na busca por
novas soluções e desenvolvimento de aplicações inteligentes baseadas em tecnologias de IoT, em
um processo que interconecta pessoas, serviços, processos e coisas, tornando as universidades
em Campi Inteligentes. Nesse contexto, o presente trabalho apresenta os resultados de uma
solução de medição inteligente de água, baseada em tecnologias de IoT de baixo custo, que foi
implantada no Campus Campina Grande do IFPB, como um projeto piloto e uma iniciativa para
torna-lo um campus inteligente (Smart Campus). O artefato desenvolvido se destaca pelo uso
da tecnologia LoRa® e do middleware Dojot na camada de aplicação, em vez de soluções na
nuvem, com uma comunicação bidirecional através do LoRa® gateway Dragino LG02. Ademais,
foram realizadas adaptações de metodologias metrológicas estabelecidas em normas brasileiras
vigentes para calibração do sensor de vazão do medidor inteligente de água desenvolvido, o
cálculo do índice de desempenho do medidor e da incerteza da medição. Os resultados obtidos
com a solução desenvolvida demonstram um índice de desempenho da medição de 97,83% e
uma margem de erro de indicação menor do que ± 2 % para as faixas de vazão calibradas para
o sensor de vazão (FS400A) utilizado. A comunicação LoRa® se mostrou estável com índice
médio de indicador de intensidade do sinal recebido (RSSI) no gateway de -89 dBm e uma
taxa de perda de pacote de 0,35%. O Dojot, embora seja uma solução relativamente nova no
mercado, se comportou de forma satisfatória, dando indícios de que pode ser utilizada como
uma ferramenta de produção em um futuro próximo, sendo uma opção viável para um campus
inteligente.
Palavras-chaves: Medição Inteligente de Água; LoRa®; Dojot; IoT.

ABSTRACT
The scarcity of water resources is a reality that affects many countries in the world and tends to
worsen in the coming years due to population growth, climate change and poor management
of water distribution systems, especially in underdeveloped countries, in which the rates of
loss of potable water in these systems are alarming. In Brazil, data from the National Sanita-
tion Information System (SNIS) report that the average indicator of unaccounted for or lost
drinking water loss in distribution in 2021 reached the impressive rate of 40.14%, that is, for
every 100 liters of treated water, more than 40 liters are wasted along the water distribution
system. A way to improve management of water resources and reduce indicators of losses in
water distribution systems is in IoT (Internet of Things) solutions for monitoring systems and
“intelligent measurement of water” (Smart Water Metering), in which smart water meters (Smart
Water Meters) allow real-time monitoring and measurement of various system parameters, such
as for example: pressure, flow and water quality, as well as enabling the activation valves and
hydraulic pumps remotely and automatically. Therefore, the use of solutions IoT is gaining more
and more prominence and popularity both in the commercial field and in the academic scope,
in which universities play a fundamental role in the search for new solutions and development
of intelligent applications based on IoT technologies, in a process that interconnects people,
services, processes and things, making universities in Smart Campi. In this context, this paper
presents the results of a smart water metering solution, based on low-cost IoT technologies,
which was implanted in the IFPB Campina Grande Campus, as a pilot project and an initiative
to makes it an intelligent campus (Smart Campus). The artifact developed stands out for its
use of LoRa® technology and Dojot middleware at the application layer, instead of solutions
at the cloud, with two-way communication through the LoRa® gateway Dragino LG02. Fur-
thermore, adaptations of metrological methodologies established in Brazilian standards were
carried out current regulations for calibrating the flow sensor of the smart water meter developed,
the calculation of meter performance index and measurement uncertainty. The obtained results
with the developed solution demonstrate a measurement performance index of 97.83% and a
margin of indication error of less than ± 2% for the calibrated flow ranges for the flow sensor
(FS400A) used. The LoRa® communication proved to be stable with an index average received
signal strength indicator (RSSI) on the gateway of -89 dBm and a 0.35% packet loss rate. Dojot,
although a relatively new solution in the market, behaved satisfactorily, giving indications that
it can be used as a a production tool in the near future, being a viable option for a campus
intelligent.
Key-words: Smart Water Metering; LoRa®; Dojot; IoT.

LISTA DE FIGURAS
Figura 1 – Principais tecnologias utilizadas na “medição inteligente de água”. Fonte:

Adaptado de (SINGH; AHMED, 2020) . . . . . . . . . . . . . . . . . . . 24
Figura 2 – LoRa® X LoRaWAN® em relação a camada de rede ISO/OSI. Fonte: Adap-
tado de (SEMTECH, 2019). . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figura 3 – Distribuição de frequência dos canais (Uplink x Downlink) na banda AU 915
mHz. Fonte: (ALLIANCE, 2019). . . . . . . . . . . . . . . . . . . . . . . 32
Figura 4 – Arquitetura Publish/Subscribe (Pub/Sub). Fonte: (HIVEMQ, 2015). . . . . . 36
Figura 5 – Exemplo de estrutura de tópico MQTT. Fonte: (HIVEMQ, 2015). . . . . . . 36
Figura 6 – Arquitetura de microsserviço do middleware Dojot. Fonte: (DOJOT, 2020). 38
Figura 7 – Exemplo de comunicação interna entre os componentes DeviceManager e
DataBroker através de tópicos Kafka. Fonte: (DOJOT, 2020). . . . . . . . . 39
Figura 8 – Diagrama de pinagem do WIFI LoRa® 32. Fonte: (HELTEC, 2021). . . . . 41
Figura 9 – Síntese dos conceitos e fundamentos da Design Science . . . . . . . . . . . 49
Figura 10 – Etapas do método DSR x Abordagem Científica X Saídas das Etapas . . . . 50
Figura 11 – Sensor de fluxo FS400A G1. Fonte: Adaptado de (HAOYU, 2021) . . . . . 56
Figura 12 – Curva característica do sensor de fluxo FS400A G1 (Equação 1). . . . . . . 57
Figura 13 – Arquitetura de rede do SMMIA. Fonte: Autoria própria. . . . . . . . . . . . 65
Figura 14 – Instalação do "medidor inteligente de água" no cavalete de entrada de água
do campus (perspectiva vertical). Fonte: Autoria própria. . . . . . . . . . . 66
Figura 15 – Instalação do medidor inteligente de água no cavalete de entrada de água do
campus (perspectiva horizontal). 1- Válvula de abertura manual; 2 - filtro de
água; 3 - válvula reguladora de pressão com manômetro analógico e sensor
eletrônico de pressão; 4 - sensor de vazão; 5 válvula solenoide; 6 - válvula de
retenção de água. Fonte: Autoria própria. . . . . . . . . . . . . . . . . . . . 67
Figura 16 – Diagrama esquemático de interconexão hidráulica e elétrica do medidor
inteligente de água no cavalete de entrada de água do campus. Fonte: Autoria
própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 17 – Caixa do SMMIA. Fonte: Autoria própria. . . . . . . . . . . . . . . . . . . 70
Figura 18 – Arquitetura do LoRa® gateway Dragino LG02. Fonte: (DRAGINO, 2020). . 71
Figura 19 – Interface de configuração e visualização de dados em tempo real, versão 1 no
Dojot. Fonte: Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 20 – Interface de configuração e visualização de dados em tempo real, versão 2 no
Dojot. Fonte: Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . 74
Figura 21 – Configurações da máquina virtual no VMware ESXi. Fonte: Autoria própria. 75
Figura 22 – Visualização dos containers no Portainer. Fonte: Autoria própria. . . . . . . 76
Figura 23 – Alocação de disco após a instalação do Dojot. Fonte: Autoria própria. . . . . 77
Figura 24 – Dashboard de visualização da base de dados no Mongo Express. Fonte:
Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Figura 25 – Dashboard de buckets do InfluxDB. Fonte: Autoria própria. . . . . . . . . . 79
Figura 26 – Dashboard do pgAdmin. Fonte: Autoria própria. . . . . . . . . . . . . . . . 79
Figura 27 – Dashboard de containers no InfluxDB. Fonte: Autoria própria. . . . . . . . 81
Figura 28 – Dashboard de containers no InfluxDB. Fonte: Autoria própria. . . . . . . . 82
Figura 29 – Dashboard de visualização de dados no MongoDB Express . Fonte: Autoria
própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figura 30 – Cenário da comunicação LoRa®. Fonte: Autoria Própria. . . . . . . . . . . 84
Figura 31 – Setup de configurações do LoRa® gateway Dragino LG02. Fonte: Autoria
Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figura 32 – Script MQTT do gateway Dragino LG02. Fonte: Dragino . . . . . . . . . . 86
Figura 33 – Configurações de canais no LG02 (A) e exemplo de código para envio de
pacote LoRa® (B). Fonte: Autoria Própria. . . . . . . . . . . . . . . . . . . 86
Figura 34 – Característica da potência do sinal recebida no gateway Dragino LG02. Fonte:
Autoria Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figura 35 – Protótipo inicial. Fonte: Autoria própria. . . . . . . . . . . . . . . . . . . . 90
Figura 36 – Caracterização do perfil de consumo do campus com protótipo inicial. Fonte:
Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Figura 37 – Caracterização do perfil de consumo do campus com protótipo final. Fonte:
Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figura 38 – Comparação do volume total contabilizado entro o SMMIA e o hidrometro
SAGA da CAGEPA com o solenoide desenergizado. Fonte: Autoria própria. 92
Figura 39 – Caracterização da pressão no cavalete de entrada de água do campus. Fonte:
Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figura 40 – Caracterização da pressão no cavalete de entrada de água do campus. Fonte:
Autoria própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figura 41 – Diagrama de uma instalação para calibração por pesagem (método está-
tico (1C), alimentação por bombeamento direto). Fonte: ABNT NBR ISO
4185:2009. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figura 42 – Diagrama da bancada adaptada para calibração do sensor de vazão FS400A
G1"(método estático, alimentado por pressurização direta). Fonte: Autoria
Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figura 43 – Bancada adaptada ao método estático 1C da ABNT NBR ISO 4185:2009.
Fonte: Autoria Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figura 44 – Fluxograma do processo de medição. Fonte: Autoria Própria. . . . . . . . . 98
Figura 45 – Comportamento da pressão estática na bancada adaptada com pressurizador
configurado em 1,0 bar. Fonte: Autoria Própria. . . . . . . . . . . . . . . . 99
configurado em 1,5 bar. Fonte: Autoria Própria. . . . . . . . . . . . . . . . 99
configurado em 2 bar. Fonte: Autoria Própria. . . . . . . . . . . . . . . . . 100
Figura 48 – Comportamento da pressão estática na bancada adaptada. Fonte: Autoria
Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figura 49 – Imagens de medição da pressão estática no manômetro analógico. Fonte:
Autoria Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figura 50 – Erro de indicação da balança. Fonte: Autoria Própria. . . . . . . . . . . . . 102
Figura 51 – Gráfico do erro de indicação obtido no processo de calibração. Fonte: Autoria
Própria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
Figura 52 – Resumo das medições. Fonte: Autoria Própria. . . . . . . . . . . . . . . . . 109
LISTA DE TABELAS
Tabela 1 – Comparação entre alcance de sinal e consumo energético das tecnologias de

rede sem fio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Tabela 2 – Características de propagação de sinal LoRa® em relação ao Fator de Espa-
lhamento (SF). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Tabela 3 – Características dos trabalhos relacionados. . . . . . . . . . . . . . . . . . . 45
Tabela 4 – Requisitos de hardware para instalação do Dojot. . . . . . . . . . . . . . . 54
Tabela 5 – Setup inicial da camada física LoRa®. . . . . . . . . . . . . . . . . . . . . 55
Tabela 6 – Parâmetros para determinação do erro de indicação e IDM. . . . . . . . . . 58
Tabela 7 – Lista de ferramentas, materiais e dispositivos utilizados. . . . . . . . . . . . 63
Tabela 8 – Atributos da aplicação SMMIA configurados no dispositivo 41719c do Dojot. 73
Tabela 9 – Dados de métricas de serviços do Dojot extraídos da ferramenta "docker stats". 83
Tabela 10 – Faixas de vazão de ensaio. . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Tabela 11 – Consumo médio de água do campus no ano de 2022 em metros cúbicos. . . 88
Tabela 12 – Acompanhamento das soluções (SAGA e SMMIA) na totalização do volume
total contabilizado (m3). . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Tabela 13 – Exemplo dos demais parâmetros coletados durante a calibração do sensor de
vazão. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Tabela 14 – Fatores de correção (M) da calibração utilizados. . . . . . . . . . . . . . . . 104
Tabela 15 – Resultado ensaio curva de erro para vazão de 250 l/h ou 4,167 l/min. . . . . 106
Tabela 16 – Resultado ensaio curva de erro de indicação para vazão de 450 l/h ou 7,5 l/min.107
Tabela 17 – Resultado ensaio curva de erro de indicação para vazão de 700 l/h ou 11,667
l/min. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
l/min. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
l/min. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Tabela 20 – Exemplo do cálculo do IDM para as três primeiras medições. . . . . . . . . 110
LISTA DE ABREVIATURAS E SIGLAS
AESBE Associação Brasileira das Empresas Estaduais de Saneamento
AMQP Advanced Message Queuing Protocol
ANA Agência Nacional das Águas
Anatel Agência Nacional de Telecomunicações
API Application Programming Interface
AWS Amazon Web Services
CoAP Constrained Application Protocol
CPqD Centro de Pesquisa e Desenvolvimentoem Telecomunicações
CR Code Rate
CSS ChirpSpread Spectrum
DC Direct Current
DDS Data Distribution Service
DE Diâmetro Externo
DS Design Science
DSR Design Science Research
EMA Erro Máximo Admissível
ESP32 Espressif 32
FSK Frequency-shift keying
GUM Guia para Avaliação da Incerteza daMedição
HTTP Hypertext Transfer Protocol
I/Os Input / Output
IDM Índice de Desempenho do Medidor
IFPB Instituto Federal de Educação, Ciência e Tecnologia da Paraíba
Inmetro Instituto Nacional de Metrologia, Qualidade e Tecnologia

IoT Internet of Things
IPF Índice de Perda de Faturamento
ISO International Organization for Standardization
ITB Intituto Trata Brasil
JWT JSON Web Token
Li-Po Polímero de Lítio
LoRa® Long Range
MDR Ministério do Desenvolvimento Regiona
MQTT Message Queuing Telemetry Transport
MVP Minimum Viable Product
NBR Norma Brasileira
OLED Organic Light Emitting Diode
ONU Organização das Nações Unidas
PHY Physical Layer
PWAN Low Power Wide Area Networks
QoS Quality of Service
RAM Random Access Memory
REST Representational State Transfer
RTM Regulamento Técnico Metrológico
SF Spread Spectrum
SI Sistema Internacional
Siga Sistema de Gerenciamento de Água
SMMIA Sistema de Monitoramento e Medição Inteligente de Água
SNIS Sistema Nacional de Informações Sobre Saneamento
SoC System on Chip
SWG Smart Water Grid

SWM Smart Water Management
TCP Transmission Control Protocol
URL Uniform Resource Locator
VIM Vocabulário Internacional de Metrologia
WRI World Resources Institute
WWDR World Water Development Report

LISTA DE SÍMBOLOS
ai Metade da faixa estimada de um componente da incerteza, associada com a

estimativa da entrada xi
c Combinada
ci Coeficiente de sensibilidade usado para multiplicar a incerteza na estimativa

da entrada, xi , para obter a incerteza da estimativa da saída, y
c⇤i Coeficiente de sensibilidade relativo utilizado para multiplicar a incerteza

relativa na estimativa da entrada, xi , com o objetivo de se obter o efeito
relativo de uma mudança relativa na grandeza de entrada, na incerteza
relativa da estimativa da saída y
EP Erro ponderado
f Relação funcional entre estimativas do mensurando, y, e estimativas da

entrada, Xi , da qual y depende
h Hora
i Da i-ésima entrada
K Fator de abrangência empregado para calcular a incerteza expandida U
L Litro
m³ Metro cúbico
N Da N ésima entrada
n Da n ésima observação
Q Vazão expressa em metros cúbicos por segundo, nas condições de escoa-

mento
S(X̄) Desvio-padrão experimental da média aritmética X̄
U Incerteza Expandida
U⇤ Incerteza Expandida Relativa
u(x) Incerteza Padrão
uc Incerteza Combinada
uc (y) Incerteza-padrão combinada relativa, associada com a estimativa da saída y
u⇤c (y) Incerteza-padrão combinada, associada com a estimativa da saída y
u(Xi ) Incerteza-padrão associada, com a estimativa da entrada, xi
u(X̄i ) Desvio-padrão da média de medições repetidas
x De x
x̄ Média aritmética ou média de n observações repetidas, xm , de grandezas

variando aleatoriamente, x
xi Estimativa da grandeza de entrada, Xi
xm m ésima observação de uma grandeza aleatória, x
Dxi Incremento em xi usado para a determinação numérica do coeficiente de

sensibilidade
y Estimativa do mensurando,Y
Dy Incremento em y encontrado na determinação numérica do coeficiente de

sensibilidade mudança relativa na grandeza de entrada, na incerteza relativa
da estimativa da saída y
∂ y / ∂ xi Derivada parcial com relação à grandeza de entrada xi da relação funcional f

entre o mensurando e as grandezas de entrada
® Marca Registrada
™ Marca Comercial
Â Somatório
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1 Motivação e Definição do Problema . . . . . . . . . . . . . . . . . . . . . 20
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.1 Objetivo geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.2.2 Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . . . 27
2.1 Metrologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.1 Sistema de Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2 Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.3 Incerteza da Medição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 Modelo de Medição ou Modelo Matemático . . . . . . . . . . . . . . . . . 30
2.1.5 Calibração, Verificação e Validação . . . . . . . . . . . . . . . . . . . . . . 31
2.2 Redes LPWAN (Low Power Wide Area Network) . . . . . . . . . . . . . 31
2.2.1 LoRa® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Protocolos de Camada de Aplicação IoT . . . . . . . . . . . . . . . . . . 34
2.3.1 MQTT (Message Queuing Telemetry Transport) . . . . . . . . . . . . . . . 35
2.4 Middleware IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.1 Dojot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5 Sistemas Embarcados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1 WIFI LoRa® 32 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Contribuições da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2 Aplicabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3 Método . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.1 Método Design Science Research . . . . . . . . . . . . . . . . . . . . . . . 48
3.3.2 Plano de Ação de Desenvolvimento e Implantação do Artefato . . . . . . . . 53
3.3.2.1 Instalação e configuração do middleware Dojot . . . . . . . . . . . . . . . . 54
3.3.2.2 Desenvolvimento do software embarcado . . . . . . . . . . . . . . . . . . . 54
3.3.2.3 Testes, verificação de sensores e comunicação com o Dojot . . . . . . . . . 55
3.3.2.4 Caracterização do perfil de consumo de água do campus . . . . . . . . . . . 55
3.3.2.5 Ensaio para calibração do sensor de fluxo . . . . . . . . . . . . . . . . . . . 56
3.3.2.6 Cálculo da incerteza da medição e índice de desempenho do medidor . . . . 58
3.3.2.7 Montagem e instalação do protótipo . . . . . . . . . . . . . . . . . . . . . . 62
3.3.2.8 Monitoramento do sistema de medição inteligente de água . . . . . . . . . . 62
3.4 Ferramentas, Dispositivos e Materiais Utilizados . . . . . . . . . . . . . 63
4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1 Protótipo SMMIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.1.1 Arquitetura da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1.1 Camada Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.1.1.2 Camada de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.1.3 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2 Middleware Dojot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 Avaliação Antes da Coleta de Dados . . . . . . . . . . . . . . . . . . . . . 75
4.2.2 Avaliação Após a Coleta de Dados . . . . . . . . . . . . . . . . . . . . . . 80
4.3 Comunicação LoRa® . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.4 Caracterização do Perfil de Consumo . . . . . . . . . . . . . . . . . . . . 88
4.5 Calibração do Sensor de Vazão . . . . . . . . . . . . . . . . . . . . . . . 95
4.6 Índice de Desempenho da Medição - IDM, e Incerteza da Mediação . . . 105
5 CONCLUSÕES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.1 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . . . . . 114
APÊNDICES 122
APÊNDICE A – TABELA COMPLETA DO CÁLCULO DO IDM . . . 123
APÊNDICE B – MÉDIA E DESVIO-PADRÃO DOS

PARÂMETROS AUXILIARES NO PROCESSO DE
CALIBRAÇÃO DO SENSOR FS400A . . . . . . . . 127
18
1 INTRODUÇÃO
A água, o elemento mais precioso e essencial à vida terrestre, está em risco; é o que
aponta a organização não governamental ambientalista World Resources Institute (WRI), por
meio do seu projeto global de monitoramento e mapeamento de riscos hídricos: o Aqueduct
Water Risk Atlas1 (WRI, 2021). Ainda de acordo com (WRI, 2021), “mais de 1 bilhão de pessoas
já vivem atualmente em regiões de escassez de água, e cerca de 3,5 bilhões podem sofrer escassez
de água até 2025”. No Brasil, segundo (ANA, 2020), “cerca de 22 milhões de pessoas foram
afetadas por secas e estiagens em 2019, no qual aproximadamente 94% das pessoas afetadas
pela seca vivem na região Nordeste”.
Neste cenário de iminente escassez dos recursos hídricos, as cidades enfrentam enormes
desafios para gerenciar seus recursos naturais vitais, forçando-as a se reinventarem e criarem
soluções tecnológicas otimizadas e sustentáveis para se tornarem “cidades inteligentes” (ou
Smart Cities) (RUSSO; RINDONE; PANUCCIO, 2014; EC, 2021). As Smart Cities podem ser
definidas como grandes centros urbanos que utilizam tecnologias inovadoras na gestão pública,
como também em suas infraestruturas, para melhorar aspectos socioeconômicos de uma região,
visando o desenvolvimento urbano sustentável e planejado em prol da qualidade de vida dos
cidadãos (VERSTAEVEL; BOES; GLEIZES, 2017; NEVES et al., 2017).
Diversas soluções desenvolvidas para as Smart Cities nascem em campi universitários,
em que de acordo com (MOTTA; LIMA; CUNHA, 2018), o “limite físico do campus não é
mais definido e são projetados edifícios com funções mistas, podendo ser utilizada tanto pela
comunidade acadêmica quanto pela população”, o que para (VERSTAEVEL; BOES; GLEIZES,
2017) os tornam verdadeiros laboratórios vivos e parceiros ideais para cidades que buscam
explorar e promover iniciativas de cidades inteligentes.
Segundo (NEVES et al., 2017), o “modelo de uma Smart City pode ser escalado e
adaptado para as universidades”, criando o conceito de “campus inteligente” ou Smart Campus",
no qual as instituições adotam tecnologias de Internet das Coisas (Internet of Things - IoT) para
criar aplicações inteligentes, servindo como verdadeiros bancos de testes (OBERASCHER et
al., 2022), voltadas ao controle e monitoramento remoto das instalações e serviços do campus
como, por exemplo, serviços de energia elétrica, iluminação, água, estacionamento, entre outros,
proporcionando o desenvolvimento sustentável, reduzindo custos e desperdícios (FACENS,
2020).
No contexto das aplicações inteligentes, a medição inteligente de água (ou Smart Water
Metering) surge como uma aplicação baseada em tecnologias IoT, que visam minimizar a
escassez hídrica dos grandes centros urbanos por meio da leitura remota e automática de pontos
1 Disponível em: ATER RISK ATLAS.. Acessado em: 25 de ja. de 2023.
Capítulo 1. Introdução 19
de medições estratégicos nos sistemas de distribuição de água, principalmente na entrada de

casas, indústrias e escritórios comerciais, por meio de medidores inteligentes de água (ou Smart
Water Meters) (LALLE et al., 2020).
Os medidores inteligentes de água são dispositivos microcontrolados acoplados a senso-
res que monitoram o fluxo de água remotamente em tempo real, de forma automática ou sob
demanda, que utilizam geralmente tecnologias de redes de longa distância e baixa potência (Low
Power Wide Area Networks - LPWANs) – na qual se destacam as tecnologias Narrowband IoT
(NB-IoT), Sigfox e Long Range (LoRa®) (LALLE et al., 2019) – para enviar as informações a
uma central de processamento local ou na nuvem, em que “os clientes podem tomar decisões
inteligentes analisando seu consumo de água e as concessionárias podem melhorar seus serviços
explorando as informações fornecidas pelos medidores” (LALLE et al., 2020).
Estes medidores inteligentes são componentes essenciais dos sistemas de gestão inteli-
gente de água (Smart Water Management - SWM) ou redes inteligentes de água (Smart Water
Grid - SWG), no qual o acesso a dados e informações relacionadas à água em tempo real é
fundamental para construir estratégias sofisticadas para a gestão da água e, consequentemente,
contribuir para a redução da escassez hídrica nos centros afetados (MATTOS, 2018). As SWG
são definidas por (MARTYUSHEVA, 2014) como “uma rede bidirecional em tempo real com
sensores e dispositivos que monitoram contínua e remotamente o sistema de distribuição de
água”. Já um SWM, de acordo com (YI et al., 2018), é caraterizado pelo “uso de soluções
integradas de Tecnologia da Informação e Comunicação (TIC) em tempo real, como sensores,
monitores, sistema de informação geográfica (GIS) e mapeamento de satélite e outras ferramentas
de compartilhamento de dados na gestão da água”, ou seja, são conceitos correlatos.
Com isso, percebe-se que a complexidade dessas soluções necessitam de uma infraes-
trutura relativamente robusta para suportar o volume de dados gerados, assim como uma boa
plataforma (middleware local ou na nuvem), com um conjunto de serviços avançados para
gerenciar todo o ecossistema IoT. Atualmente encontram-se disponíveis no mercado diversas
soluções de middlewares para IoT gratuitos e de código aberto, com propósitos diferentes, como
por exemplo, Kaa IoT, ThingSpeak, DeviceHive, Zetta, Dojot, entre outras. (MANKAD; AROL-
KAR, 2020) ressalta que há vários pesquisadores trabalhando na área de suporte a aplicativos
de medição inteligente em diferentes frameworks e que o “desenvolvimento e implantação de
frameworks baseados em IoT para medidores inteligentes foram propostos e implementados por
muitas organizações como, Maven Systems, Sensus, WebNMS e muito mais”.
No Brasil, diversas universidades como a UFCG, Facens, UFRN, Unicamp, entre outras,
já implementam soluções de “medição inteligente” em seus Smart Campi, além de diversas
concessionárias de água do país já terem iniciado projetos para realizar a medição inteligente de
água, como por exemplo a companhia de saneamento básico do estado de São Paulo – Sabesp,
que já instalou 7,5 mil medidores inteligentes de água, operando através da rede Sigfox da WND
Brasil (PAIVA, 2019).
Embora as aplicações IoT de água inteligente (Smart Water - SW) venham crescendo
nas universidades, ainda existe uma baixa adesão desses sistemas no âmbito das organizações
educacionais, no qual os principais obstáculos para adoção de medidores inteligentes nessas
organizações são os fatores tecnológicos, ambientais e por último, fatores organizacionais
(ADAMS; JOKONYA, 2022).
Neste contexto, visando não apenas contribuir para a redução do consumo de água do
campus e conscientizar a comunidade para a importância da gestão dos recursos hídricos, o
trabalho desenvolvido nesta dissertação consistiu-se no desenvolvimento, implantação e avaliação
de uma solução de medição inteligente de água implantada no campus Campina Grande (PB)
do IFPB, utilizando a tecnologia LoRa® em conjunto com a plataforma Dojot 2 , como projeto
piloto de uma iniciativa para tornar o "campus inteligente"(Smart Campus).
1.1 Motivação e Definição do Problema
Dados do Relatório Mundial das Nações Unidas (ONU) sobre Desenvolvimento dos
Recursos Hídricos (World Water Development Report – WWDR, 2021) — desenvolvido por
mais de 20 de agências do Sistema ONU em um esforço internacional denominado ONU-Água
(UN-Water) — apontam que o consumo de água potável no mundo aumentou aproximadamente
6 vezes no último século e continua a avançar a uma taxa de 1% ao ano desde a década de
80, fruto do crescimento populacional, da expansão da agricultura (responsável por 69% do
consumo de toda a água doce do planeta), do setor industrial (19%), do crescimento econômico
e da própria alteração do padrão de consumo humano (12%) (KONCAGüL; TRAN; CONNOR,
2021).
Durante o mesmo período, a qualidade da água diminui em regiões da Ásia, África
e América do Sul e, o estresse hídrico3 aumentou, afetando mais de 2 bilhões de pessoas ao
redor do planeta (KONCAGüL; TRAN; CONNOR, 2021). Além disso, “cerca de 1,6 bilhão de
pessoas enfrentam escassez “econômica” de água, o que significa que, embora a água possa estar
fisicamente disponível, não existe infraestrutura necessária para que as pessoas tenham acesso a
essa água” (KONCAGüL; TRAN; CONNOR, 2021) apud (AGRICULTURE, 2007).
Corroborando com as informações acima, dados do relatório Diagnóstico Temático:
Serviços de Água e Esgoto, Visão Geral, de 2022, elaborado pelo Ministério do Desenvolvimento
Regional/Secretaria Nacional de Saneamento, demonstram que a média nacional de perda nos
sistemas de distribuição de água em 2021 foi de 40,3% (SNIS, 2022), ou seja, para cada 100 litros
de água tratada, mais de 40 litros de água é desperdiçada ao longo do caminho e não chegam ao
consumidor final, o que representa uma perda de 168,66% acima do índice considerado ideal
2 Disponível em: Dojot. Acesso em: 25 de jan. de 2023.
3 O termo estresse hídrico é utilizado para descrever um cenário no qual, em uma determinada região, a demanda
por água é maior do que a sua disponibilidade e capacidade de renovação. Fonte: (SUçUARANA, 2021)
(15%) pelo relatório, gerando um impacto financeiro estimado em R$ 12 bilhões de reais por
ano (ITB, 2020b).
Na cidade de Campina Grande (PB), o índice de perda de água em 2021, de acordo
com dados extraídos da plataforma "Painel de Indicadores" do sítio governamental SISTEMA
NACIONAL DE INFORMAÇÕES SOBRE SANEAMENTO - SNIS4 , foi de 27,54%, índice
inferior à média geral do estado da Paraíba (35.38%) (SNIS, 2021).
Além dos altos índices de perdas nos sistemas de distribuição de água, o relatório
PERDAS DE ÁGUA 2020 (SNIS 2018): DESAFIOS PARA DISPONIBILIDADE HÍDRICA
E AVANÇO DA EFICIÊNCIA DO SANEAMENTO BÁSICO ressalta que “a maior parte das
empresas não mede as perdas de água de maneira consistente, do modo que, por exemplo, não
são divulgados indicadores que reflitam de maneira independente as perdas físicas e comerciais”
(ITB, 2020a).
Nesse contexto, entende-se por perdas físicas ou reais, toda água desperdiçada (nos
mais diversos processos), tratada ou não, que é disponibilizada para distribuição e não chega ao
consumidor, ou seja, a água é desperdiçada ao longo do trajeto por motivos diversos, como por
exemplo, vazamentos provocados por excesso de pressão (SNIS, 2018).
Já as perdas comerciais ou aparentes (também identificado nos relatórios citados por
Índice de Perda de Faturamento - IPF), são falhas nos sistemas de medição (ocasionadas por erro
humano ou mecânico) que não registram o consumo real do usuário (SNIS, 2018), onerando
o faturamento das concessionárias de água, além de aumenta a necessidade de captação dos
mananciais, o que impacta diretamente na eficiência das companhias (EOS, 2019).
Entre as principais causas de perdas aparentes estão:
“falhas decorrentes de erros de medição (hidrômetros inoperantes, com sub-

medição, erros de leitura, fraudes, equívocos na calibração dos hidrômetros),
ligações clandestinas,by pass irregulares nos ramais das ligações (conhecidos
como “gatos”), falhas no cadastro comercial e outras situações”. (BRASIL,
2019)
No Brasil, o “indicador médio de perdas de faturamento total foi 38,64% em 2021, uma
pequeno retrocesso frente aos 40,89% observados em 2020” (SNIS, 2022), em que presume-se
que a submedição (parcela do volume entregue ao consumidor final, que não é registrado pelo
medidor) seja responsável por 4% a 22% da perda de faturamento. (SNIS, 2018)
Diversos fatores que colaboram para a submedição já foram identificados na literatura,
como por exemplo:
“dimensionamento incorreto (capacidade e/ou classe metrológica), tecnologia

inadequada do medidor, instalação inadequada (inclinação do hidrômetro no
cavalete, hidrômetro sujeito a esforço mecânico, choques/vibrações e intempé-
ries), regime de vazões do ramal predial afetado pelo abastecimento indireto,
4 Disponível em: Painel de Saneamento. Acesso em: 25 de jan. de 2023.
com ação da boia da caixa d’água prejudicando a medição em vazões muito

baixas (período noturno e/ou vazamentos internos)”. (SNIS, 2018)
Ainda de acordo com (SNIS, 2018), outros fatores como “deficiências na manutenção da
rede de distribuição (o que provoca a existência de partículas sólidas, notadamente partículas
de ferro que podem danificar o hidrômetro e/ou interferir na sua sensibilidade), bem como
deficiência no programa de manutenção e substituição de hidrômetros”, contribuem para o
aumento da submedição.
Além disso, (AESB, 2015) informa que os “medidores velocimétricos de classe B 5 ,
extensamente utilizados no país, tem se mostrado pouco eficientes em baixas vazões e perdem
capacidade com poucos anos de uso”, ou seja, mesmo em equipamentos novos, os medidores
apresentam erros de leitura e, com o passar do tempo, a margem de erro tende a aumentar com
o desgaste do equipamento, levando a índices de erro que podem extrapolar os indicadores
definidos em normas técnicas.
No Brasil, o órgão balizador de normas técnicas referentes à hidrômetros e equipamentos
de medição é o Instituto Nacional de Metrologia, Qualidade e Tecnologia (Inmetro), que através
da PORTARIA Nº 155, DE 31 DE MMARÇO DE 2022, institui o REGULAMENTO TÉCNICO
METROLÓGICO - RTM, que estabelece requisitos técnicos e metrológicos para os medidores
utilizados para medir o volume de água potável fria e água quente até 15m³/h. O RTM preconiza,
entre outros, os índices de erro máximo admissível (EMA) de leitura de ± 5% para vazões baixas
(faixa inferior de medição) e ± 2% para vazões de trabalho nominal (faixa superior de medição)
em equipamentos novos e, para equipamentos usados, os valores são de ± 10% para vazões
baixas e ± 5% para vazões de trabalho nominal (BRASIL, 2022).
Visando reduzir os indicadores apresentados anteriormente e promover melhorias na
infraestrutura do saneamento básico do Brasil, o Ministério do Desenvolvimento Regional
(MDR) lançou a portaria Nº 490, DE 22 DE MARÇO DE 2021 que estabelece indicadores que
deverão ser cumpridos pelos municípios de todo país para reduzir as perdas de água até 2034,
tendo como meta, o índice máximo permitido de 25% de perdas nos sistemas de distribuição de
água dos municípios (BRASIL, 2021). Ainda de acordo com a portaria, os municípios devem se
adequar e buscar soluções para reduzir as perdas, intervindo no que couber, na “setorização e
zonas de medição e controle; macromedição e pitometria no sistema distribuidor; micromedição;
e implantação, ampliação ou melhoria do controle operacional” (BRASIL, 2021).
No âmbito do IFPB, campus Campina Grande (PB), a micromedição é realizada através
de um hidrômetro ultrassônico do fabricante ViewShine, modelo U-WR-S DN156 , de respon-
sabilidade da concessionária de água estatal CAGEPA, instalado na entrada do campus na rua
5 Quanto maior a classe, mais preciso e eficiente é o hidrômetro, como por exemplo, um hidrômetro Classe C é
melhor do que o Classe B, e assim sucessivamente.
6 Para especificações técnicas do produto e mais informações, consulte o site do fabricante, disponível em:
Viewshine.
Tranqüilino Coelho Lemos, 671 - Dinamérica, em 2022 (última substituição do equipamento),

em que o registro do consumo é realizado de forma manual por um agente da CAGEPA in
loco, embora o dispositivo esteja preparado comunicação com e sem fio: saída de pulso de dois
fios/três fios, LoRaWAN, NB-IoT.
Além disso, todo gerenciamento hidráulico do campus é realizado de forma manual,
por meio de um operador que controla a abertura de válvulas e acionamento de bombas para
encher reservatórios do tipo caixa d’água distribuídos ao longo do campus, no qual muitas
vezes as válvulas não são fechadas em tempo hábil e o desperdício de água é gerado com o
transbordamento dos reservatórios.
Diante do exposto, fica evidente que o mau uso da água associado à falta de manutenção
em estruturas e equipamentos hídricos, assim como medições imprecisas, acarretam enormes
danos econômicos, sociais e ambientais em todo país, logo, necessitam de melhorias e avanços
tecnológicos para uma maior precisão nas medições e uma melhor gestão dos recursos hídricos,
contribuindo assim, para redução das perdas de água e consequentemente amenizar a escassez
hídrica.
Nesse contexto, visando mitigar os problemas apresentados, as tecnologias de IoT surgem
como principal expoente na otimização dos sistemas de distribuição de água. No campo da
micromedição, as soluções IoT de medição inteligente de água começam a emergir e diversas
propostas são encontradas atualmente na literatura. Porém, como é uma área relativamente nova
no campo de pesquisa, ainda não existe um padrão definido, logo, “o principal desafio para a
medição inteligente de água com IoT é ter uma estrutura padronizada para conectar qualquer
medidor de água existente a uma rede IoT” (MANKAD; AROLKAR, 2020).
Essa constatação é facilmente visualizada na revisão sistemática apresentada por (SINGH;
AHMED, 2020) e corroborada por (ADAMS; JOKONYA, 2022), no qual os autores fazem um
levantamento na literatura sobre as principais tecnologias de comunicação, sensores, controlado-
res, plataformas na nuvem, e parâmetros utilizados para a medição de diversas propriedades da
água analisadas nos sistemas de medição inteligente de água utilizando tecnologias de IoT. A
consolidação desse levantamento é apresentada na Figura 1.
Figura 1 – Principais tecnologias utilizadas na “medição inteligente de água”. Fonte: Adaptado

de (SINGH; AHMED, 2020)
Na Figura 1 percebe-se claramente que há uma grande diversidade de tecnologias de

IoT utilizadas no desenvolvimento de soluções de medição inteligente de água. É importante
ressaltar que o estudo apresentado por (SINGH; AHMED, 2020) aborda apenas as principais
tecnologias, e soluções de plataformas IoT baseadas em infraestrutura locais (edge computing)
não foram citadas nesse estudo.
Mediante esta breve contextualização acerca da motivação e do problema de pesquisa, as
seguintes Questões de Pesquisa (QP) podem ser levantadas:
• QP01 - O medidor inteligente de água desenvolvido será capaz de medir com a precisão e
requisitos estabelecidos em normas vigente?
• QP02 - A pressão da água na entrada do sistema de distribuição de água do campus está

em conformidade com as normas vigentes?
• QP03 - O middleware Dojot pode ser utilizado com uma ferramenta de produção no atual
estágio de desenvolvimento da ferramenta?
• QP04 - A tecnologia LoRa® será capaz de apresentar um desempenho de comunicação

com baixa taxa de perdas de pacotes para o cenário da aplicação?
• QP05 - É possível calibrar um sensor de vazão com resultados satisfatórios, dentro da

margem de erro de indicação estabelecido em norma, com uma bancada de calibração não
certificada?
A relevância do assunto em estudo se dá não apenas no âmbito das perdas nos sistemas
de distribuição de água interna do campus ocasionadas por erro de leitura no equipamento de
mensuração do consumo com a informação do volume micromedido, como também, no âmbito
social, uma vez que visa diminuir as perdas de água e conscientizar a comunidade acadêmica para
importância da gestão eficiente dos recursos hídricos, além de contribuir com o desenvolvimento
de sistemas de medição inteligente de água utilizando tecnologias IoT de baixo custo como
ferramentas para o gerenciamento e planejamento do controle das perdas de água de um Smart
Campus.
1.2 Objetivos
1.2.1 Objetivo geral
Este trabalho tem como objetivo geral o desenvolvimento de um artefato (protótipo) para
Medição Inteligente de Água (Smart Water Metering) baseado em plataformas de IoT de baixo
custo para mensurar o consumo geral de água do campus Campina Grande (PB) do IFPB, de
maneira remota e automática.
1.2.2 Objetivos específicos
Abaixo, os objetivos específicos da pesquisa:
• Instalar e configurar a plataforma Dojot (middleware IoT);
• Realizar ensaio para calibração e verificação de sensores;
• Desenvolver protótipo de medidor inteligente de água;
• Instalar protótipo no cavalete de entrada de água do campus;
• Avaliar o desempenho da comunicação LoRa, do Dojot e do medidor inteligente de água;
• Verificar se a solução apresenta índices de medições compatíveis com normas brasileiras

vigentes para validar a solução.
1.3 Estrutura do Documento
Estruturalmente, o documento encontra-se organizado da seguinte maneira: no Capítulo

2, é apresentada uma breve explanação sobre:
• Metrologia, no qual são abordados os conceitos chave para uma melhor compreensão
sobre o processo de medição e sua complexidade;
• Redes LPWAN, com foco na tecnologia LoRa®;
• Protocolos da Camada de Aplicação IoT, com ênfase no protocolo MQTT;
• Middlewares IoT, descrevendo a arquitetura da plataforma Dojot;
• Sistema Embarcados, abordando sumariamente as características do WIFI LoRa® 32 e,

• Trabalhos Relacionados, na qual é apresentada uma série de artigos que representam o

estado da arte relacionado ao tema em estudo.
No Capítulo 3, é apresentada a metodologia utilizada para o desenvolvimento deste

trabalho, bem como, as contribuições da pesquisa e a aplicabilidade da solução desenvolvida,
como também, a heurística de desenvolvimento do artefato e as ferramentas, dispositivos e
materiais utilizados.
Apresenta-se no Capítulo 4, os resultados obtidos durante os ensaios de desenvolvimento
do artefato, respondendo as questões de pesquisa levantadas.
Finalizando o documento, o Capítulo 5 apresenta as conclusões e propostas de trabalhos
futuros.
27
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo são apresentados os principais fundamentos teóricos utilizados para o

desenvolvimento deste trabalho. Uma rápida explanação sobre Metrologia, Redes LPWAN, Pro-
tocolos de Camada de Aplicação IoT, Middleware IoT e Sistemas Embarcados são apresentados
a seguir. Ainda nesta seção, são apresentados os Trabalhos Relacionados com o tema em estudo,
em que são discutidos artigos recentes sobre o tema.
2.1 Metrologia
A Metrologia é a ciência das medidas e suas aplicações, que “engloba todos os aspectos
teóricos e práticos da medição, qualquer que seja a incerteza de medição e o campo de aplicação”
(INMETRO, 2012b). De acordo com (MENDES; ROSáRIO, 2020), a “metrologia existe para
sustentar um acordo universal para as unidades de medida, ou seja, a existência de uma padroni-
zação dos valores”. Logo, é de suma importância entender os conceitos básicos dessa ciência e
os termos empregados em metrologia, pois, são necessários para interpretação e especificação de
resultados de medição.
As definições e terminologias apresentadas a seguir são extraídas dos documentos:
Vocabulário Internacional de Metrologia - VIM (2012) e Guia para Avaliação da Incerteza da
Medição - GUM (2008), publicados pelo Inmetro.
2.1.1 Sistema de Medição

De acordo com (INMETRO, 2012b), entende-se por Sistema de Medição, um:
“conjunto de um ou mais instrumentos de medição e frequentemente outros

dispositivos, compreendendo, se necessário, reagentes e insumos, montado e
adaptado para fornecer informações destinadas à obtenção dos valores medidos,
dentro de intervalos especificados para grandezas de naturezas especificadas”.
Ainda de acordo com (INMETRO, 2012b), “um sistema de medição pode consistir em
apenas um instrumento de medição” (instrumento de medição indicador), ou seja, equipamento
que fornece um sinal de saída contendo informações sobre o valor da grandeza medida, como
por exemplo, voltímetro (grandeza medida: tensão), termômetro (grandeza medida: temperatura)
etc.
2.1.2 Medição
Medição é definido por (INMETRO, 2012a) como um conjunto de procedimentos que

tem por objetivo “determinar o valor do mensurando, isto é, o valor da grandeza específica a ser
Capítulo 2. Fundamentação Teórica 28
medida. Uma medição começa, portanto, com uma especificação apropriada do mensurando, do
método de medição e do procedimento de medição”.
Já em (INMETRO, 2012b), medição é o “processo de obtenção experimental de um ou
mais valores que podem ser, razoavelmente, atribuídos a uma grandeza”. O método de medição
é a uma “descrição genérica de uma organização lógica de operações utilizadas na realização
de uma medição” (INMETRO, 2012b), ou seja, uma sequência lógica de procedimentos para
conhecermos o valor de uma dada grandeza.
A forma como uma grandeza pode ser mensurada (método de medição) se dá principal-
mente de duas maneiras (MENDES; ROSáRIO, 2020):
1. Direta: consiste na utilização de um instrumento para obter o resultado de uma única

grandeza envolvida no processo;
2. Indireta: consiste na medição de uma ou mais grandezas por meio de modelos matemáticos.
Essas formas de medição devem seguir um procedimento de medição, ou seja, a “des-

crição detalhada de uma medição de acordo com um ou mais princípios de medição e com um
dado método de medição, baseada num modelo de medição e incluindo todo cálculo destinado à
obtenção de um resultado de medição” (INMETRO, 2012b).
Ao final desse processo, temos o resultado de uma medição, que é “geralmente expresso
por um único valor medido e uma incerteza de medição” (INMETRO, 2012b). O resultado pode
ser expresso como um único valor, caso a incerteza de medição seja considerada desprezável para
alguma finalidade. Porém, é sabido que todo processo de medição contém falhas ou imperfeições
que dão origem a um erro no resultado da medição, e, esse erro contém dois componentes:
• Aleatório: “presumivelmente se origina de variações temporais ou espaciais, estocásticas

ou imprevisíveis, de grandezas de influência” (INMETRO, 2012a), e não é passível de
compensação, embora tenha seu efeito minimizado aumentando o número de observações,
em que a esperança ou valor esperado do erro tende a zero.
• Sistemático: análogo ao erro aleatório, o erro sistemático também não pode ser eliminado
do processo de medição, porém, também pode ser minimizado, principalmente “se origina
de um efeito reconhecido de uma grandeza de influência em um resultado de medição e,
se for significativo com relação à exatidão requerida da medição, uma correção ou fator de
correção pode ser aplicado para compensar o efeito” (INMETRO, 2012a), em que após
esta correção, a esperança ou valor esperado do erro provocado por um efeito sistemático
seja próximo de zero.
(INMETRO, 2012a) ainda ressalta que “frequentemente, os instrumentos e sistemas de

medição são ajustados ou calibrados utilizando-se padrões de medição e materiais de referência
para eliminar os efeitos sistemáticos; entretanto, as incertezas associadas a esses padrões e

materiais ainda devem ser levadas em conta”.
2.1.3 Incerteza da Medição

De acordo com (INMETRO, 2012a),
“Quando se relata o resultado de medição de uma grandeza física deve-se sem-

pre dar alguma indicação quantitativa da qualidade do resultado, de forma que
aqueles que o utilizam possam avaliar sua confiabilidade. Sem essa indicação,
resultados de medição não podem ser comparados, seja entre eles mesmos ou
com valores de referência fornecidos numa especificação ou numa norma. É,
portanto, necessário que exista um procedimento que seja de pronta aplica-
ção, fácil compreensão e ampla aceitação para caracterizar a qualidade de um
resultado de uma medição, isto é, para avaliar e expressar sua incerteza”.
Assim, (INMETRO, 2012a) define formalmente incerteza de medição como “parâmetro,

associado ao resultado de uma medição, que caracteriza a dispersão dos valores que podem ser
razoavelmente atribuídos ao mensurando”. Já em (INMETRO, 2012b), incerteza de medição é
definida como “parâmetro não negativo que caracteriza a dispersão dos valores atribuídos a um
mensurando, com base nas informações utilizadas”.
Em termos gerais, a incerteza de medição engloba muitos componentes, como por
exemplo, componentes de erros sistemáticos. De acordo com (INMETRO, 2012a), “alguns
destes componentes podem ser estimados com base na distribuição estatística dos resultados
de séries de medições e podem ser caracterizados por desvios-padrão experimentais”, ou ainda,
“outros componentes, que também podem ser caracterizados por desvios-padrão, são avaliados
por meio de distribuições de probabilidade supostas, baseadas na experiência ou em outras
informações” (INMETRO, 2012a).
Assim, a incerteza de medição pode ser classificada como:
Incerteza-Padrão: “incerteza do resultado de uma medição expressa como um desvio-
padrão” (INMETRO, 2012a). Incerteza Definicional: “Componente da incerteza de medição que
resulta da quantidade finita de detalhes na definição de um mensurando” (INMETRO, 2012a).
Além disso, a incerteza da medição pode ser avaliada com:
• Tipo A: “método de avaliação de incerteza pela análise estatística de séries de observações”

(INMETRO, 2012a).
• Tipo B: outros meios que não estatísticos, como por exemplo, avaliação baseada na
informação (INMETRO, 2012a):
– associada a valores publicados por autoridade competente;

– associada ao valor de um material de referência certificado;
– obtida a partir de um certificado de calibração;

– relativa à deriva1 ;
– obtida a partir da classe de exatidão dum instrumento de medição verificado e,
– obtida a partir de limites deduzidos da experiência pessoal.
Para se obter um resultado mais detalhado da incerteza da medição, os métodos de

avaliação podem ser combinados ou expandidos, o que é denominado por (INMETRO, 2012a),
como:
• Incerteza-padrão Combinada: “Incerteza-padrão obtida ao se utilizarem incertezas-padrão

individuais associadas às grandezas de entrada num modelo de medição” (INMETRO,
2012b).
• Incerteza Expandida ou Incerteza Global: “Produto de uma incerteza-padrão combinada

por um fator maior do que o número um” (INMETRO, 2012b).
A incerteza expandida pode ser obtida através de um fator de abrangência (k, tipicamente
na faixa de 2 a 3) multiplicado pela incerteza-padrão combinada (INMETRO, 2012a).
2.1.4 Modelo de Medição ou Modelo Matemático

Na perspectiva de (INMETRO, 2012a),
“O modelo matemático da medição, que transforma o conjunto de observações

repetidas no resultado de medição, é de importância crítica porque, além das
observações, ele geralmente inclui várias grandezas de influência que são
conhecidas de forma inexata. Essa falta de conhecimento contribui para a
incerteza do resultado da medição, assim como também contribuem as variações
das observações repetidas e qualquer incerteza associada ao próprio modelo
matemático”.
Assim, modelo de medição ou modelo matemático é definido em (INMETRO, 2012b),

como a “relação matemática entre todas as grandezas que se sabe estarem envolvidas numa
medição”, e pode ser utilizado para calcular a incerteza de medição. (INMETRO, 2012a)
ressalta que “uma vez que o modelo matemático pode ser incompleto, todas as grandezas
relevantes devem ser variadas até a maior extensão prática possível de modo que a avaliação da
incerteza possa ser baseada, tanto quanto possível, nos dados observados”. Ainda de acordo com
(INMETRO, 2012a), “o modelo matemático deve ser revisado sempre que os dados observados,
incluindo o resultado de determinações independentes do mesmo mensurando, demonstrarem
que ele está incompleto”.
1 Medida de desvio que, com o decorrer do tempo, certo instrumento ou aparelho passa a apresentar face ao seu
padrão de funcionamento normal. Fonte: (DERIVA, 2021)
Para auxiliar a análise do modelo matemático, um “experimento bem projetado pode

facilitar sobremaneira avaliações confiáveis da incerteza e é uma parte importante da arte de
medição” (INMETRO, 2012a).
2.1.5 Calibração, Verificação e Validação
O resultado de uma calibração é “a relação entre as leituras de um instrumento de

medição, ou sistema de medição, e os valores indicados pelo padrão” (MENDES; ROSáRIO,
2020), ou seja, em termos práticos, a comparação entre o valor medido pelo instrumento a ser
calibrado com o valor de instrumento já calibrado e certificado, ou ainda, comparado com um
padrão rastreado ao Sistema Internacional (SI) (LIRA, 2018).
Em (INMETRO, 2012b), o conceito de calibração é definido como:
“Operação que estabelece, sob condições especificadas, numa primeira etapa,

uma relação entre os valores e as incertezas de medição fornecidos por padrões
e as indicações correspondentes com as incertezas associadas; numa segunda
etapa, utiliza esta informação para estabelecer uma relação visando a obtenção
de um resultado de medição a partir de uma indicação”.
Já a verificação, é definida como “fornecimento de evidência objetiva de que um dado

item satisfaz requisitos especificados” (INMETRO, 2012b), e a validação é a “verificação na
qual os requisitos especificados são adequados para um uso pretendido” (INMETRO, 2012b).
2.2 Redes LPWAN (Low Power Wide Area Network)
As redes sem fio de baixa potência e longo alcance (Low Power Wide Area Network -
LPWAN) são conjuntos de tecnologias, em essência, voltadas para aplicações de baixo consumo
energético e baixo custo, o que se encaixa perfeitamente com a proposta de Internet das Coisas
(IoT) (LALLE et al., 2019). Ainda de acordo com (LALLE et al., 2019), as tecnologias LPWAN
surgiram para superar a questão energética das redes celulares e o problema de alcance das redes
de curto alcance, como pode ser observado na comparação de dados contidos na Tabela 1.
Tabela 1 – Comparação entre alcance de sinal e consumo energético das tecnologias de rede sem
fio.
Classificação da Consumo Energético
Tecnologia Alcance do Sinal
Tecnologia Estimado (Potência de Transmissão)
Bluetooth 4.0 Curto Alcance 10 m 2,5 mW
Wi-Fi 6 Curto Alcance 50 m 80 mW
3G/4G Celular 5 km 5000 mW
2-5 km (Urbano)
LoRa® LPWAN 5-15 km (Rural) 20 mW
15 km (Linha de Visada Direta)
Fonte: Adaptado de (LORA, 2018).
As principais tecnologias LPWAN apontadas por (LALLE et al., 2019) são: LoRa®,
Narrowband - IoT (NB-IoT) e SigFox. Neste trabalho utilizou-se a tecnologia LoRa® como meio
de comunicação entre dispositivos finais e a aplicação (middleware Dojot) através de um LoRa®

gateway. Suas principais características são brevemente apresentadas na subseção a seguir.
2.2.1 LoRa®
LoRa®, acrônimo de “longo alcance” (Long Range), é uma das tecnologias LPWAN
mais promissoras no campo IoT. Para (ORTIZ et al., 2019), LoRa® se destaca pela “redução na
complexidade do hardware, a diminuição do tamanho dos cabeçalhos e da complexidade da rede
em termos de saltos e endereçamento, viabilizando uma comunicação bidirecional simples, com
o uso de uma infraestrutura mınima e com baixo consumo de energia”.
Os termos LoRa® (camada física) e LoRaWAN® (protocolo de rede) são frequentemente
usados de forma intercambiável. No entanto, referem-se a tecnologias distintas, pois operam
em camadas de rede diferentes (SEMTECH, 2019), conforme apresentado na Figura 2. As
características do protocolo LoRaWAN® não serão abordadas neste documento.
Figura 2 – LoRa® X LoRaWAN® em relação a camada de rede ISO/OSI. Fonte: Adaptado de

(SEMTECH, 2019).
A camada física (PHY) utiliza uma técnica de modulação de espalhamento espectral

(Spread Spectrum) proprietária, criada pela empresa Semtech, que deriva da técnica CSS (Chirp
Spread Spectrum), no qual opera com canais de largura de banda fixa de 125 kHz ou 500
kHz (para canaisuplink) e 500 kHz (para canais downlink) (SEMTECH, 2019), na banda ISM
(Industrial Sientific and Medical) de 915-928 mHz (AU915-928), homologada para região
brasileira pela Agência Nacional de Telecomunicações (Anatel), por meio do ATO Nº 14448, de
4 de dezembro de 2017 (ANATEL, 2017). A distribuição de frequência dos canais (uplink ⇥
downlink) pode ser observada na Figura 3.
Figura 3 – Distribuição de frequência dos canais (Uplink x Downlink) na banda AU 915 mHz.
Fonte: (ALLIANCE, 2019).
É importante ressaltar que as características de modulação LoRa® variam de região para

região e são definidas pela LoRa Alliance®, por meio do documento LoRaWAN® Regional
Parameters2 . Outra característica da modulação da camada física LoRa® é o código de espa-
lhamento aplicado ao sinal de dados original, denominado de fator de propagação ou fator de
espalhamento (SF). O LoRa® fornece 6 parâmetros SF (SF7 a SF12), que possibilita ajustar a
propagação do sinal, ou seja, o alcance do sinal, porém, quanto maior o fator (alcance do sinal),
menor a taxa de bits (SEMTECH, 2019).
Um exemplo dessa relação está contido na Tabela 2, que considera um payload de 11
bytes para um canal de uplink de 125 mHz, e os quatro primeiros valores de SF (SF7 a SF10).
Outra característica apresentada na tabela é o tempo de propagação da informação no ar (Time on
Air -ToA), também conhecido como ciclo de trabalho ou ciclo de serviço, definido por (LORA,
2018) como “a proporção de tempo durante o qual um componente, dispositivo ou sistema é
operado”.
Tabela 2 – Características de propagação de sinal LoRa® em relação ao Fator de Espalhamento

(SF).
Taxa de Alcance do Tempo de Propagação no Ar Sensibilidade do
SF
Bits Sinal (ToA) Receptor (RX) em dBm
SF10 980 bps 8 km 371 ms -137,5
SF9 1760 bps 6 km 185 ms -135,0
SF8 3125 bps 4 km 103 ms -132,5
SF7 5470 bps 2 km 61 ms -130,0
Fonte: Adaptado de (SEMTECH, 2019; LALLE et al., 2020).
O LoRa® também possui mecanismos de identificação e correção de erros, implemen-

tados através de redundância nas mensagens, em que é definido um conjunto de bits para esse
propósito, também conhecido como taxa de código (Code Rate - CR).(ORTIZ et al., 2019;
SEMTECH, 2019).
As principais características do LoRa®, segundo (SEMTECH, 2015), são:
• Largura de banda escalável: A modulação LoRa® é escalonável em largura de banda e

frequência, podendo ser facilmente adaptada para qualquer modo de operação com apenas
algumas alterações de parâmetros de configuração.
• Envelope constante/baixo consumo de energia: o LoRa® utiliza a técnica de modulação

de envelope constante (na qual todas as informações residem na fase do sinal, não na
amplitude) o que pode ser utilizado por amplificadores de potência (PA) padrões do
mercado, sem nenhuma modificação, o que barateia o custo do hardware. Além disso, o
conjunto de técnicas permite um baixo consumo energético, o que permite a criação de
dispositivos operados por bateria que podem durar até 10 anos.
2 Disponível em:RP2-1.0.3 LoRaWAN® Regional Parameters
• Alta Robustez: Devido ao produto Bandwidth ⇥ Time (largura de banda ⇥ tempo) ser
maior que 1 (BT>1) e sua natureza assíncrona, o LoRa® é muito resistente a interferências
dentro e fora de banda.
• Resistente a problemas de atenuação por multipercurso e desvanecimento: o chirp (sinal

no qual a frequência aumenta ou diminui com o tempo) utilizado na modulação ocupa uma
largura de banda relativamente larga (broadband) e, portanto, LoRa® oferece um bom
nível de imunidade a trajetórias múltiplas (multipath) e atenuação (fading), tornando-o
ideal para uso em ambientes urbanos e rurais.
• Resistente a efeito Doppler: O efeito Doppler (fenômeno físico que altera a percepção da
frequência ondulatória no receptor quando o emissor ou o receptor se desloca em relação
ao outro em um movimento contínuo) causa um pequeno deslocamento de frequência do
pulso LoRa®, que introduz um deslocamento relativamente insignificante na frequência
de banda base. Essa tolerância de deslocamento de frequência atenua a necessidade de
hardware extra, tornando o LoRa® ideal para links de comunicação de dados móveis,
como por exemplo, sistemas de monitoramento sem fio de pressão de pneus de um carro;
• Longo alcance: o conjunto de técnicas de modulação do LoRa® permitem um alcance 4

vezes maior se comparado a outras tecnologias de modulação, como o FSK (Frequency-
shift keying), para uma mesma potência de transmissão e taxa de bits fixa;
• Capacidade de rede aprimorada: O esquema de modulação Semtech LoRa® emprega

fatores de propagação (SF) ortogonais que permitem que vários sinais de propagação
sejam transmitidos ao mesmo tempo e no mesmo canal sem alterar a sensibilidade do
receptor;
• Variação/Localização: Uma propriedade inerente do LoRa® é a capacidade de discriminar

linearmente entre erros de frequência e tempo. LoRa® é a modulação ideal para aplicações
de radar e, portanto, é ideal para aplicações de alcance e localização, como serviços de
localização em tempo real.
2.3 Protocolos de Camada de Aplicação IoT
Os dispositivos IoT se comunicam usando protocolos padrões da indústria. De maneira

geral, um protocolo é um conjunto de regras que determina como os dados são tabulados e
compreendidos por dispositivos em um processo de comunicação. No contexto IoT, os protocolos
garantem que as informações de um dispositivo ou sensor sejam lidas e compreendidas por
outros dispositivos, gateways ou serviços (MICROSOFT, 2021; KONDORO et al., 2021).
Na camada de aplicação IoT, os seguintes protocolos se destacam (KONDORO et al.,
2021):
• AMQP (Advanced Message Queuing Protocol);
• CoAP (Constrained Application Protocol);
• DDS (Data Distribution Service);
• MQTT (Message Queuing Telemetry Transport).
Cada um dos protocolos listados atende a um conjunto de requisitos específicos e não

necessariamente são protocolos concorrentes, logo, a correta seleção do protocolo é fundamental
para lograr êxito na implantação de um projeto IoT (HERRERO, 2021; YUGHA; CHITHRA,
2020). Neste trabalho, é proposta a utilização do protocolo MQTT. Suas principais características
são descritas na subseção a seguir.
2.3.1 MQTT (Message Queuing Telemetry Transport)
MQTT é um protocolo padronizado pela OASIS cujo objetivo é facilitar a comunicação

entre dispositivos IoT. De acordo com a documentação atual (versão 5.0) das especificações do
protocolo, elaborado pela OASIS (BANKS et al., 2019), o MQTT é um protocolo leve, de código
aberto, simples e fácil de implementar, que transporta mensagens do tipo publicação/assinatura
(também conhecido como publish/subscribe), o que o torna ideal para uso em muitas situações,
incluindo ambientes restritos, como para comunicação em contextos máquina a máquina (M2M)
e IoT, ou seja, é adequado para dispositivos com restrições de recursos e que usam tecnologias
de comunicação com baixa taxa de bits e alta latência (MILEVA et al., 2021).
Segundo (HIVEMQ, 2015), a arquitetura publish/subscribe desvincula o cliente que
envia uma mensagem (o editor) do cliente ou clientes que recebem as mensagens (os assinantes),
ou seja, a comunicação entre os dispositivos finais não é direta e necessita de um intermediário
(denominado broker) para gerenciar a troca de informações, como pode ser observado no exemplo
da Figura 4, no qual um endpoint transmite uma mensagem contendo a informação da velocidade
do veículo (publish 70 mph) para o tópico (ou assunto) “speed”, e o broker (software HiveMQ)
se encarrega de distribuir a mensagem entre os assinantes do tópico (representado na figura pelo
dispositivo móvel e o computador). Para que essa comunicação seja possível, é necessária a
conexão prévia das partes com o broker.
Figura 4 – Arquitetura Publish/Subscribe (Pub/Sub). Fonte: (HIVEMQ, 2015).
Um tópico refere-se a uma string UTF-8 (semelhante a uma URL - Uniform Resource
Locator) que o broker usa para filtrar mensagens para clientes conectados e pode conter um ou
mais níveis, em que cada nível do tópico é separado por uma barra (separador de nível de tópico),
como esboça a Figura 5.
Figura 5 – Exemplo de estrutura de tópico MQTT. Fonte: (HIVEMQ, 2015).
No exemplo de estrutura de tópico apresentada na Figura 5, a string pode ser interpretada

como um tópico em que faz-se uma alusão a compartimentos de uma casa (sala de estar do térreo)
em que se pretende monitorar a temperatura (atributo) do ambiente. Essa estrutura de tópico
além de ser de fácil interpretação não sobrecarrega a aplicação (HIVEMQ, 2015). É importante
ressaltar que a estrutura do tópico pode variar de aplicação para aplicação e a documentação do
desenvolvedor deve ser consultada previamente.
O MQTT utiliza o protocolo TCP (Transmission Control Protocol) na camada de trans-
porte para fornecer conexões ordenadas, sem perdas e bidirecionais. De acordo com (BANKS et
al., 2019), suas principais características são:
• Suporte para três níveis de Qualidade de Serviço (QoS);
• Possui mecanismos de notificação quando há perda na conexão;
• Baixa sobrecarga (overhead) na rede;
• Comunicação assíncrona;
• É agnóstico de dados, ou seja, o editor decide se quer enviar (publicar) dados binários,
dados de texto ou até mesmo XML (Extensible Markup Language) ou JSON (JavaScript
Object Notation) completos.
(MILEVA et al., 2021) ressalta que “embora o MQTT v5.0 tenha herdado muito do seu
antecessor, ou seja, o v3.1.1, ambas as versões não são, em princípio, compatíveis. Isso é causado
pela diferente estrutura de mensagens, bem como recursos adicionais que foram introduzidos na
nova versão”.
2.4 Middleware IoT
Middleware é definido por (VIKASH; MISHRA; VARMA, 2021), como um conjunto de

componentes de software que opera em uma camada intermediaria entre o sistema operacional e
a interface de aplicativo do usuário final, como também fornece uma camada comum de abstração
de software para aplicação distribuída.
No contexto IoT, o middleware reduz a complexidade do ecossistema e fornece um
ambiente com um conjunto de recursos (serviços) que facilitam o desenvolvimento de aplicações
de forma ágil. Nesse contexto, diversas soluções de middleware são encontradas atualmente
no mercado e podem ser classificadas de acordo com sua arquitetura, que pode ser monolítica
(todo o sistema está estruturado em uma grande aplicação) ou baseada no novo paradigma de
microsserviços (todo o sistema é decomposto em pequenos componentes independentes, que
podem ser interligados para compartilhar serviços) (BENAYACHE et al., 2019).
Neste trabalho, é proposto o uso do middleware Dojot, baseado no novo paradigma de
microsserviços. Suas principais características são apresentados na subseção a seguir.
2.4.1 Dojot
O Dojot foi lançado em 2017 com o objetivo de desenvolver e demonstrar tecnologias

para as cidades inteligentes e IoT pela Fundação CPqD (Centro de Pesquisa e Desenvolvimento
em Telecomunicações). Trata-se de um middleware de código aberto que utiliza tecnologias
no estado da arte e possui uma arquitetura baseada em microsserviços (DOJOT, 2017). Seus
componentes estruturais podem ser observados na Figura 6.
Figura 6 – Arquitetura de microsserviço do middleware Dojot. Fonte: (DOJOT, 2020).
A arquitetura é composta por vários componentes, em que cada um desses elementos é

composto por um ou mais microsserviços que executam em um ambiente virtualizado (container
Docker ou Kubernetes). A comunicação interna é realizada por dois tipos de mensagens: tópicos
Kafka (estrutura de dados análoga a “uma pasta em um sistema de arquivos, e os eventos
são os arquivos nessa pasta” (KAFKA, 2017), no qual deve conter um subject e um tenant,
como pode ser observado no exemplo da Figura 7) e requisições HTTP (Hypertext Transfer
Protocol) REST (Representational State Transfer). O componente Data Broker (software Apache
Kafka + Redis) fornece dois serviços: gerenciamento de mensagens do tipo subject e tópicos do
Kafka, além de conexões socket.io e dados em tempo real (lida com o roteamento de dados). O
API Gateway (software Kong) gerencia o fluxo de mensagens (requisições HTTP REST) entre
serviços externos e internos do Dojot (DOJOT, 2020).
Figura 7 – Exemplo de comunicação interna entre os componentes DeviceManager e DataBroker

através de tópicos Kafka. Fonte: (DOJOT, 2020).
No exemplo mostrado na Figura 7, o componente DeviceManager precisa publicar uma

mensagem sobre um novo dispositivo, no qual envia uma solicitação ao DataBroker (que consulta
o componente Auth para autorização), indicando qual tenant (dentro do JSON Web Token - JWT)
e qual subject (dojot.device-manager.devices) deseja usar para enviar a mensagem.
O Apache Kafka é uma “plataforma distribuída de transmissão de dados que é capaz de
publicar, subscrever, armazenar e processar fluxos de registro em tempo real” (HAT, 2021). O
Kong é um gateway de API’s RESTFul otimizado para operar em arquiteturas de microsserviços
e sistemas distribuídos, desenvolvido para processar altas taxas de informações em tempo real
com latência muito baixa, podendo ser implementado em infraestruturas locais ou na nuvem
(NADA, a).
Na ponta da comunicação com os dispositivos finais encontram-se os agentes IoT, em
que atualmente o software implementado na versão 0.6.0 do Dojot é o VerneMQ. O IoT Agent
também é responsável por traduzir as mensagens dos endpoints em mensagens Kafka e vice-
versa (DOJOT, 2020). Embora a figura ilustre outros agentes, apenas o módulo com suporte ao
protocolo MQTT é implementado, contudo, o Dojot fornece API (Application Programming
Interface) para desenvolvimento de novos agentes IoT. O VerneMQ é um broker (intermediário)
que gerencia mensagens de publicação/assinatura MQTT e fornece recursos relacionados à
escalabilidade e confiabilidade (VERNEMQ, 2021).
O formato padrão de mensagem MQTT usado pela Dojot (VerneMQ) é uma estrutura
de dados JSON do tipo “chave-valor” (é possível traduzir qualquer formato para esse esquema
utilizando fluxos) e devem seguir os seguintes requisitos, de acordo com (DOJOT, 2020):
• A assinatura do tópico para publicação (publisher) deve assumir o padrão: <tenant>:<device-

id>/attrs (por exemplo: admin:efac/attrs);
• O tópico de subscrição (subscriber) deve conter o seguinte formato: <tenant>:<device-

id>/config (por exemplo: admin:efac/config);
• A identificação do usuário deve conter a mesma assinatura do tópico: <tenant>:<device-

id> (por exemplo: admin:efac);
• O corpo da mensagem (payload) deve ser um JSON com cada chave sendo um atributo do
dispositivo cadastrado no Dojot (por exemplo: "temperature": 10.5, "pressure": 770 ).
Os demais componentes da arquitetura são:
• Auth: responsável pelo gerenciamento, autenticação e autorização do usuário. É invocado

pelo Kong sempre que uma solicitação é recebida por um dispositivo IoT registrado (DO-
JOT, 2020);
• DeviceManager: armazena e recupera informações de dispositivos e modelos (templates)

no banco de dados PostgreSQL, além de algumas informações estáticas sobre estes através
de mensagens Kafka (DOJOT, 2020);
• Persister: é o componente responsável por armazenar os dados enviados pelos endpoints

no banco de dados MongoDB, o qual sempre que uma nova mensagem é recebida, os
dados são armazenados no documento referente ao ID do dispositivo (DOJOT, 2020);
• History: componente que realiza a interface de acesso ao MongoDB, ou seja, é responsável

por consultar e retornar as informações de um dispositivo do banco de dados (DOJOT,
2020) e,
• Flowbroker: é um serviço baseado no front end Node-RED, mas usa seu próprio motor
para processar as mensagens, ou seja, lida com fluxos (CRUD e execução de fluxo) e
fornece um editor de fluxo baseado em navegador que facilita a transferência de fluxos
usando a ampla gama de blocos de funções (módulos) disponíveis na interface (DOJOT,
2020).
MongoDB é um banco de dados de documentos que utiliza estrutura de dados seme-

lhantes ao JSON (acrônimo de JavaScript Object Notation). Sob a perspectiva de (MONGODB,
2021) “esta é a maneira mais natural de pensar sobre dados, e é muito mais expressiva e poderosa
do que o modelo tradicional de linha/coluna”.
Outro ponto importante observado na arquitetura do Dojot é a implementação do software
Redis em alguns microsserviços (Data Broker, Device Manager e Auth), utilizado para otimizar
o processo de armazenamento dos dados e reduzir a latência na comunicação interna entre os
componentes, uma vez que, é um banco de dados do tipo chave-valor que executa diretamente
na memória RAM (Random Access Memory), podendo funcionar como cache de dados, realizar
gerenciamento de sessões publish/subscribe e classificações (AWS, 2021).
2.5 Sistemas Embarcados
Para (MORAES; ALMEIDA; SERAPHIM, 2016), sistemas embarcados são “sistemas

eletrônicos microprocessados que, após serem programados, possuem uma função específica que
geralmente não pode ser alterada”. Ainda de acordo com (MORAES; ALMEIDA; SERAPHIM,
2016), outra característica dos sistemas embarcados são “a restrição de recursos, tanto com-
putacionais: memória e processamento, quanto físicos: número de terminais e interfaces de
exibição/entrada de dados”.
Neste trabalho é proposta a utilização da plataforma WiFi LoRa® 32 para a construção
do sistema embarcado, de modo a controlar os sensores e atuadores do medidor inteligente de
água. Suas características são descritas sumariamente na subseção a seguir.
2.5.1 WIFI LoRa® 32
O WIFI LoRa® 32 é um kit de desenvolvimento fabricado pela empresa Heltec Au-

tomation™, projetado para desenvolver aplicações IoT para ambientes inteligentes (cidades,
casas, fazenda etc.), que integra um SoC (System on Chip ou Sistema em um Chip) ESP32 (do
fabricante Espressif Systems), módulos LoRa® SX127x (do fabricante Semtech), sistema de
gerenciamento de baterias Li-Po (polímero de lítio) e um display OLED (Organic Light Emitting
Diode) de 0,96"(HELTEC, 2018). Na Figura 8 é mostrado seu diagrama de pinagem e as funções
associadas a cada pino.
Figura 8 – Diagrama de pinagem do WIFI LoRa® 32. Fonte: (HELTEC, 2021).
Já o ESP32 é descrito por (BERTOLETI, 2019), como um combo de chips que “oferece
conectividade (Wi-Fi e Bluetooth, com frequência 2,4GHz), poder computacional (CPU +
memórias), I/Os, RTC, suporte à comunicações diversas (SPI, I²C, I²S, etc.), suporte à operação
Low-Power e blocos de hardware dedicados à segurança em um único chip”, logo, se mostra uma
solução compacta com diversos recursos importantes para o desenvolvimento de aplicações IoT.
2.6 Trabalhos Relacionados
Nesta seção, são apresentados seis trabalhos relacionados ao tema em estudo, que
fornecem uma visão do estado da arte e o potencial da aplicabilidade da “medição inteligente de
água” encontrada atualmente na literatura.
A primeira proposta (YE et al., 2021) apresenta uma solução de hidrômetro com arquite-
tura híbrida de medição (mecânico e eletrônico), como uma proposta para utilização em Smart
City, substituindo os hidrômetros convencionais. Com uma abordagem mais ampla, o segundo
trabalho (SARAVANAN; DAS; IYER, 2017) apresenta um projeto piloto de implantação de
uma rede inteligente de água (Smart Water Grid) em uma vila na Índia. Na terceira proposta
(BRANDÃO, 2019) é apresentado um trabalho de desenvolvimento de um protótipo de medidor
inteligente de água (Smart Water Meter) de baixo custo, para fins de micromedição do consumo
final em um campus universitário. O quarto trabalho (WISINTAINER, 2020) demonstra a viabi-
lidade de um medidor inteligente de água para medição do consumo de água através de protótipo
desenvolvido com dispositivos IoT operando em rede SigFox. As duas últimas propostas (RAY;
GOSWAMI, 2020; NADIPALLI et al., 2021) são análogas do ponto de vista do conjunto de
tecnologias IoT utilizadas, porém o escopo da última proposta se diferencia por apresentar uma
solução voltada para uso consciente da água no âmbito residencial. A seguir são fornecidos mais
detalhes de cada trabalho.
Em (YE et al., 2021) os autores propuseram uma nova abordagem de sistema de medição
inteligente de água (Smart Water Metering System - SWATS) para cidades inteligentes baseado
na tecnologia LoRa®, na plataforma STM32 (microcontrolador de 32-bits da família Arm®
Cortex®-M) e em um sensor de indução em conjunto com algoritmo de detecção para monitorar
e mapear o relógio analógico do medidor inteligente de água proposto. O ponto alto do trabalho
é a implementação de um algoritmo para redução de erro de leitura ocasionado por altas pressões
ou altos fluxos de água em hidrômetros mecânicos, em um fenômeno conhecido por flutuação de
pressão, o que pode ser aproveitado para testes futuros na solução proposta neste documento.
Para validar a proposta, foram realizados experimentos em diferentes condições de temperatura,
pressão e qualidade da água, em uma simulação de consumo de uma residência, variando-se o
fluxo e o tempo de vazão da água, bem como alterações no algoritmo de medição. Os resultados
demonstraram que a diferença geral na leitura entre o relógio mecânico e o sistema eletrônico
foi de 0,36%, quando utilizado o algoritmo de prevenção de vazamento de água. Porém, para
utilização em cenário real a solução precisaria seguir metodologias metrológicas para garantir a
qualidade da medição.
O projeto piloto demonstrado por (SARAVANAN; DAS; IYER, 2017) implementa uma
solução de Smart Water Grid na vila de Mori, situada no delta sudeste de Andhra Pradesh,
Índia. O projeto envolve o monitoramento e a medição de diversos parâmetros da qualidade da
água (ORP, pH, Salinidade, Nível, Turbidez, Temperatura e Fluxo de Água) através de sensores
instalados no reservatório central de água da vila e em canais de água em seu entorno. Foram
usados microcontroladores Arduino e módulos LoRa® para transmissão das informações dos
sensores a um LoRa® gateway conectado à plataforma em nuvem Ericsson Cloud. De acordo
com os autores, três objetivos foram alcançados com a implantação do sistema: melhorias na
qualidade da água na região; sistema de alerta eficiente para controle de enchentes e detecção
de alta salinidade da água, além de facilidade no acesso às informações da qualidade da água
para os moradores da região e autoridades locais. Foi utilizada a técnica estatística de regressão
logística aplicada através da ferramenta de aprendizagem de máquina WEKA para analisar os
dados dos sensores armazenados na nuvem. Os resultados obtidos demonstraram que 99% dos
valores são corretamente classificados para prever a potabilidade da água no tanque e canais. O
destaque da solução proposta é a utilização de ferramentas de Machine Learning para otimizar a
identificação de padrões da qualidade da água.
No trabalho apresentando em (BRANDÃO, 2019), os autores demonstram uma solução
de um dispositivo de medição inteligente de água de baixo custo, visando o monitoramento
automatizado de consumo em pontos de utilização do campus Campina Grande da UFCG
(Universidade Federal de Campina Grande). Foram utilizados microcontroladores Arduino
e NodeMCU (do fabricante Espressif Systems) com sensores de fluxo de água tipo turbina.
A plataforma utilizada para consolidar os dados foi o SIGA (Sistema de Gerenciamento de
Água), fruto de um projeto de pesquisa realizado em parceria com o curso de Ciência da
Computação da UFCG. Para avaliar a eficiência do dispositivo proposto, os medidores foram
instalados em chuveiro, lavatório, mictório, bacia sanitária e pia da cozinha de um bloco do
campus. Os resultados demonstraram que o “maior consumo foi da pia da copa 45%, seguido da
bacia sanitária 43% e depois o lavatório do banheiro 12%, valores divergentes do apresentado
pela literatura que são de 17%, 29%, e 6% respectivamente” (BRANDÃO, 2019). Embora o
trabalho apresente dados estatísticos para efeito comparativo, a qualidade da medição pode ser
questionada, uma vez que não é apresentada uma metodologia para calibração dos sensores.
Com o escopo do trabalho voltado para o desenvolvimento de um protótipo de medidor
inteligente de água para uso residencial, em (WISINTAINER, 2020) é apresentada uma solução
baseada em sensor de fluxo de água tipo turbina (modelo YF-S201), microcontrolador NodeMCU
, sensor de pressão (modelo SKU237545) e módulo de comunicação Sigfox Wisol WSSFM10R2
Breakout Board. Na proposta, os autores também desenvolveram uma aplicação para proces-
samento dos dados do medidor e visualização do consumo de água baseada nas tecnologias
Node.js, banco de dados Firebase e no framework Angular. A aplicação foi hospedada na nuvem
Heroku. De acordo com os autores, o protótipo obteve resultados satisfatórios em relação ao
cálculo do consumo de água, atingindo uma precisão acima de 90% para fluxos constantes de
água e uma de precisão de 99% para testes com vazões alternadas. Para chegar aos resultados
apresentados, os autores realizaram 3 experimentos, em que foram realizadas 3 medições para
cada volume (3L, 5L e 10L), variando-se o fluxo da água em baixa, média e alta vazão. No
primeiro cenário, levou-se em consideração apenas a verificação do sensor de fluxo em fluxo de
água constante. De forma análoga, no segundo experimento, levou-se em consideração o valor
da pressão para calcular a vazão. Por fim, variou-se o fluxo da água e utilizou-se a medição dos
dois sensores para realizar o cálculo de consumo. Pode-se dizer que o ponto alto do trabalho está
na utilização dos dados de pressão para otimizar o cálculo do consumo, em que utilizou-se o
valor da pressão para criar um fator de correção no cálculo. Este é um ponto interessante e pode
ser adotado na solução proposta neste trabalho.
Em (RAY; GOSWAMI, 2020) os autores propõem uma solução de medição inteligente
de água baseada no dispositivo embarcado NodeMCU, em um sensor de água do tipo turbina
(modelo YF-S201), uma unidade de memória e um placa de painel solar para alimentar o sistema.
Os dados são transmitidos em intervalos regulares para a plataforma na nuvem ThingSpeak
através de rede Wi-Fi. Como diferencial da proposta, a solução utiliza aprendizado de máquina
(Machine Learning) em um modelo de regressão linear para identificar e diferenciar padrões de
fluxo como fluxo normal, excessivo ou contínuo. Outra função adicionada ao sistema (utilizando
a tecnologia WebHooks em conjunto com a plataforma IFTTT), foi a adição de um mecanismo
de alerta, na qual é disparada uma notificação via e-mail em caso de detecção de anomalias.
Porém, não são apresentados dados substanciais para comprovação da qualidade da medição.
Análoga às soluções apresentadas no parágrafo anterior, (NADIPALLI et al., 2021)
também apresenta uma solução de medidor inteligente de água com o mesmo conjunto de
dispositivos IoT (YF-S201 + NodeMCU), porém a plataforma em nuvem utilizada foi aThinger.io.
O escopo do trabalho é apresentar uma solução que visa o uso consciente da água para usuários
residenciais, no qual apresenta uma dashboard de monitoramento em uma escala de cores na
qual o usuário define suas metas de consumo (verde = consumo dentro do limite estabelecido;
amarelo = consumo extrapolado, redução do fluxo da água; vermelho = consumo muito excedido,
fluxo da água cortado). O trabalho não apresenta uma amostra de dados relevantes nem métodos
estatísticos para uma avaliação mais precisa do sistema proposto.
A Tabela 3 contêm as informações resumidas das principais características dos trabalhos
de medição inteligente de água apresentados.
Tabela 3 – Características dos trabalhos relacionados.

Parâmetros Sensores Plataformas IoT Tecnologia de
Art.
Monitorados Utilizados (Hardware+Middleware) comunicação
(YE et al., 2021) Vazão Não informado SM32 LoRa®
ORP
pH
Salinidade
Arduino NANO LoRa®
(SARAVANAN; DAS; IYER, 2017) Nível Não informado
Erricson Cloud (867 MHz)
Turbidez
Temperatura
Vazão
NodeMCU
(BRANDÃO, 2019) Vazão Não informado Wi-Fi
Plataforma própria
NodeMCU
Vazão YF-S201
(WISINTAINER, 2020) Wisol WSSFM10R2 Sigfox
Pressão SKU237545
Plataforma Própria
NodeMCU
(RAY; GOSWAMI, 2020) Vazão YF-S201 Wi-Fi
ThingSpeak
NodeMCU
(NADIPALLI et al., 2021) Vazão YF-S202 Wi-Fi
Thinger.io
Fonte: Autoria própria.
É importante salientar que nenhum dos estudos apresentados nesta seção descreve
métodos de calibração e cálculos da incerteza de medição utilizados em normas técnicas de
metrologia para validar seus sistemas de medição propostos, preocupando-se muitas vezes
apenas com seu caráter tecnológico e funcional, em que boa parte das soluções não levam em
consideração o perfil de consumo do usuário, as vazões típicas reais do sistema no qual serão
inseridos e demais variáveis inerentes a esse tipo de aplicação.
Outra característica observada nos artigos apresentados é que os autores não levam em
consideração ou pelo menos não é declarado de forma explícita o índice de incerteza da medição
de seus medidores inteligentes de água, o que por si só é considerado uma medição incompleta,
pois não acompanha o valor declarado da incerteza da medição (INMETRO, 2012a).
A solução desenvolvida nesta dissertação se diferencia das demais soluções apresentadas
pelos seguintes pontos:
• O método para calibração do sensor de fluxo, o cálculo de incerteza da medição do

medidor inteligente de água desenvolvido e o índice de desempenho do medidor (IDM)
foi baseado em metodologia metrológica estabelecido em normas técnicas brasileiras e no
Regulamento Técnico Metrológico (RTM) de 2022 do INMETRO;
• Utilizou-se o middleware Dojot (de código aberto e gratuito) na camada de aplicação,

em vez de soluções na nuvem (soluções pagas), contribuindo para diminuir a latência
na comunicação entres os dispositivos (o que agiliza a tomada de decisão) e economizar
largura de banda da rede, além de fornecer uma interface para visualização dos dados em
tempo real;
• Desenvolveu-se um medidor inteligente de água modular, que inclui sensores para verificar
a vazão de água, a pressão e, a temperatura, pressão atmosférica e a umidade do ambiente,
bem como, uma válvula tipo solenoide para controlar remotamente o fluxo da água, uma
válvula de retenção de água e um filtro de partículas, garantindo assim uma maior eficiência
na verificação do consumo de água e,
• Utilizou-se o dev-board IoT Wi-Fi LoRa® 32 (V2) (do fabricante Heltec), operando na
frequência de 917 mHz, em uma comunicação de camada física LoRa®.
47
3 METODOLOGIA
3.1 Contribuições da Pesquisa
Como contribuições da pesquisa, levantou-se a caracterização do perfil de consumo de

água do campus, bem como os níveis de pressão da água na entrada do sistema de distribuição
de água, sendo possível averiguar se os valores obtidos estão dentro dos limites impostos por
normas brasileiras vigentes.
Outra contribuição almejada para a pesquisa é a avaliação de desempenho de comunica-
ção da camada física da rede LoRa® em ambiente real implementado no campus. Além disso,
validou-se o ecossistema IoT utilizado (com a utilização do middleware Dojot, do protocolo
MQTT e da tecnologia LoRa®), facilitando o desenvolvimento de novas aplicações IoT no
campus.
3.2 Aplicabilidade
A solução desenvolvida aplica-se não apenas no contexto do controle e gerenciamento

remoto do fluxo de água em sistemas de distribuição de água de um campus, mas em qualquer
rede de distribuição de água em que necessite coletar dados em tempo real para um controle
remoto efetivo que vise a redução de perdas e uma otimização no uso dos recursos hídricos,
desde que se respeite os limites da tecnologia. Ademais, a arquitetura utilizada com o uso da
plataforma Dojot no centro da aplicação pode ser utilizada em qualquer contexto IoT em que
se deseje monitorar e controlar serviços e instalações remotamente através de protocolos como
MQTT ou HTTP, agentes de comunicação IoT já implementados no middleware Dojot.
3.3 Método
A pesquisa desenvolvida neste trabalho pode ser classificada como aplicada, pois visa
solucionar um problema local do campus Campina Grande do IFPB.
Em relação à classificação dos objetivos, pode-se denominar como do tipo descritiva,
pois descreve as características do sistema desenvolvido, bem como analisa estatisticamente os
dados coletados através deste, ou seja, a pesquisa configura-se como uma abordagem quantita-
tiva.
Quanto ao local de obtenção das informações, realizou-se um levantamento biblio-
gráfico através de bases de dados amplamente conhecidas pela comunidade acadêmica, como
por exemplo, IEEE Xplorer, Science Direct, ACM DIGITAL LIBRARY, entre outros. Em um
segundo momento, realizou-se um levantamento laboratorial, por meio de ensaios para calibra-
Capítulo 3. Metodologia 48
ção de sensores e testes de comunicação entre o sistema embarcado, sensores e o middleware

utilizado na solução desenvolvida. Por fim, realizou-se a coleta de campo de forma remota e
automática, com o medidor inteligente de água instalado no cavalete de entrada de água.
A metodologia aplicada neste trabalho foi uma adaptação do método Design Science Rese-
arch (DSR) desenvolvida por (DRESCH; LACERDA; ANTUNES, 2020), explanado brevemente
na próxima seção. O uso do DSR se dá por “ter um objetivo mais amplo: gerar conhecimento
que seja aplicável e útil para a solução de problemas, melhoria de sistemas existentes e criação
de novas soluções e/ou artefatos” (LACERDA DANIEL PACHECO, 2013).
A tabulação dos dados se deu através de planilhas eletrônicas para uma melhor visuali-
zação dos dados coletados e facilidade para gerar gráficos, além da ferramenta Overleaf para
produção textual e da própria interface de visualização dos dados do Dojot.
O Ambiente de Desenvolvimento Integrado (do inglês Integrated Development Envi-
ronment - IDE) para programação do dispositivo final LoRa® utilizado neste trabalho, foi o
Visual Studio Code, desenvolvido pela Microsoft em conjunto com o framework PratformIO. A
linguagem de programação selecionada para o desenvolvimento da aplicação foi a linguagem C,
padrão de desenvolvimento do microcontrolador ESP32 integrado ao WIFI LoRa® 32. Estas
ferramentas permitiram o desenvolvimento do trabalho em sua plenitude, pois, fornecessem os
recursos necessários sem custos complementares.
Todo registro documental, bem como as respectivas abordagens analíticas foram organi-
zadas em uma estrutura monográfica apresentada neste documento.
3.3.1 Método Design Science Research
O Design Science Research é um método científico que evoluiu do conceito “ciência

do artificial” ou “ciência do projeto” (do inglês Design Science - DS) e, ganhou destaque na
comunidade científica através do ganhador do Prêmio do Banco da Suécia para as Ciências
Econômicas em Memória de Alfred Nobel de 1978, Herbert Simon, embora outros autores
(Fuller (1965) e Gregory (1966)) tenham utilizado o termo primeiro (RODRIGUES, 2018).
Em sua obra seminal “As Ciências do Artificial” (The Sciences of the Artificial) de 1969,
Simon consolida um arcabouço conceitual sobre o que ele denomina de “ciência do artificial”,
defendendo assim a “necessidade de criar uma ciência (i.e., um corpo de conhecimento rigoroso
e validado) que se dedique a propor como construir artefatos que possuam certas propriedades
desejadas – isto é, como projetá-los” (RODRIGUES, 2018).
Os principais conceitos da DS, segundo (DRESCH, 2013), são apresentados de forma
sistemática na Figura 9.
Figura 9 – Síntese dos conceitos e fundamentos da Design Science

.
Fonte: (DRESCH, 2013)
A relação entre DS e DSR é estabelecida por (DRESCH; LACERDA; ANTUNES, 2020)

como:
“A design science é a base epistemológica quando se trata do estudo do que é

artificial. A design science research, por sua vez, é o método que fundamenta
e operacionaliza a condução da pesquisa quando o objetivo a ser alcançado é
um artefato ou uma prescrição. Como método de pesquisa orientado à solução
de problemas, a design science research busca, a partir do entendimento do
problema, construir e avaliar artefatos que permitam transformar situações,
alterando suas condições para estados melhores ou desejáveis. Ela é utilizada
nas pesquisas como forma de diminuir o distanciamento entre teoria e prática”.
Ainda sob a ótica de (DRESCH; LACERDA; ANTUNES, 2020),
“Uma característica fundamental da pesquisa que utiliza a design science re-

search como método é ser orientada à solução de problemas específicos, não
necessariamente buscando a solução ótima, mas a solução satisfatória para a
situação. No entanto, as soluções geradas devem ser passíveis de generalização
para uma determinada classe de problemas, permitindo que outros pesquisa-
dores e profissionais, em situações diversas, também possam fazer uso do
conhecimento gerado”.
Corroborando com a citação acima, (PIMENTEL; FILIPPO; SANTORO, 2020) ressalta

que na DSR “o pesquisador está comprometido com dois objetivos: (1) resolver um problema
prático num contexto específico por meio de um artefato e (2) gerar novo conhecimento cientí-
fico”.
Para chegar a esses objetivos, o uso de um método rigoroso faz-se necessário para
operacionalizar a Design Science. Diversos autores formalizaram métodos DSR ao longo dos
anos, como BUNGE (1980), VAN AKEN, VAISHNAVI e KUECHLER (2004), ALTURKI,
GABLE e BANDARA (2011), entre outros (DRESCH; LACERDA; ANTUNES, 2020), porém,
a escolha do método DSR utilizado neste trabalho é uma adaptação da proposta DSR apresentada
por DRESCH, LACERDA e ANTUNES (2015), que consiste na consolidação da proposta de
vários autores em um processo bem definido, conforme ilustrado na Figura 10.
Figura 10 – Etapas do método DSR x Abordagem Científica X Saídas das Etapas

. Fonte: Adaptado de (DRESCH; LACERDA; ANTUNES, 2020).
O método consiste em 12 passos bem definidos, em que ao final de cada iteração é gerada
uma saída. As setas contínuas indicam a ordem direta para realização de cada um dos passos e o
produto da realização destes. Um resumo da resultante da realização de cada etapa é descrito na
coluna saída.
No Passo 1, Identificação do Problema, o pesquisador investiga um problema passível
de ser resolvido com auxílio do método DSR, justificando a relevância e a importância para
área em estudo, de forma clara e objetiva, buscando “encontrar resposta para uma questão
importante, ou a solução para um problema prático ou para uma classe de problemas” (DRESCH;
LACERDA; ANTUNES, 2020).
A etapa Conscientização do Problema (referente ao Passo 2), é o momento em que o
pesquisador busca o máximo de conhecimento possível sobre o problema investigado, tentando
obter uma compreensão ampla sobre diversos aspectos do problema, incluindo suas causas e em
quais contextos são observados. O produto desta fase é o levantamento das “funcionalidades
do artefato, a performance esperada, bem como seus requisitos de funcionamento” (DRESCH;

LACERDA; ANTUNES, 2020).
Seguindo o fluxo iterativo do método, o Passo 3 (em destaque vermelho na Figura 10) pro-
põe a realização de uma Revisão Sistemática da Literatura (RSL)1 , pois, segundo (DRESCH;
LACERDA; ANTUNES, 2020), “permite que o pesquisador faça uso de um conhecimento
existente e consulte outros estudos com foco no mesmo problema ou em problemas similares
aos dele".
Nessa etapa do método, é sugerida uma adaptação na saída do processo, no qual em
vez de produzir uma RSL (embora entenda-se que seja a forma mais adequada para obtenção
do panorama completo acerca do problema e das possíveis soluções), é sugerido a busca por
RSL recentes na literatura, uma vez que a produção de um RSL geralmente requer um tempo
demasiadamente longo para produção satisfatória. Nesse sentido, foram utilizados neste trabalho
RSLs disponíveis na literatura recente, que se enquadram no tema, contexto e questões de
pesquisa análogas ao desenvolvido neste trabalho.
Na Identificação dos Artefatos e Configuração das Classes de Problemas (Passo 4)
o pesquisador busca elencar, por meio da RSL realizada na fase anterior, artefatos e classes de
problemas relacionados ao que ele está tentando resolver e, caso se depare com um artefato ideal
para resolução do problema, sua pesquisa poderá continuar na medida em que o novo artefato
traga melhores soluções em comparação aos existentes (DRESCH; LACERDA; ANTUNES,
2020).
Ainda de acordo com (DRESCH; LACERDA; ANTUNES, 2020), esta etapa “permite
que o pesquisador faça uso das boas práticas e lições adquiridas e construídas por outros
estudiosos. Também é uma forma de assegurar que a pesquisa que está sendo desenvolvida
oferece uma contribuição relevante para uma determinada classe de problemas”.
Através da abordagem abdutiva, o Passo 5, Proposição de Artefatos para Resolução do
Problema, se propõe a apresentar (formalizar) um artefato para resolução do problema em estudo.
(DRESCH; LACERDA; ANTUNES, 2020) ressalta que este processo é essencialmente criativo,
pois, “o pesquisador usará seus conhecimentos prévios, com o intuito de propor soluções robustas
que possam ser utilizadas para a melhoria da situação atual”. Nesta fase, algumas soluções são
apresentadas ao responsável pelo projeto da organização para seleção.
O Passo 6, Projeto do Artefato, é onde o pesquisador inicia a descrição e as definições
de projeto da solução selecionada na etapa anterior, levando-se em consideração os requisitos
estabelecidos na no Passo 2, em que as características operacionais de funcionamento, bem
como, limites e relações com o ambiente externo devem ser respeitados. Vale ressaltar que, ainda
nesta etapa, o pesquisador deve descrever todos os procedimentos de construção e avaliação do
1 “Revisão Sistemática da Literatura (RSL), ou simplesmente Revisão Sistemática (RS), é um dos principais
meios para sumarizar evidências de pesquisa. Fonte: (NAKAGAWA et al., 2017)
artefato, como também, o desempenho esperado (DRESCH; LACERDA; ANTUNES, 2020).

No Desenvolvimento do Projeto (Passo 7), o pesquisador executa o que foi estabelecido
na fase anterior. Ao final desta etapa, devem ser produzidos o artefato em seu estado funcional,
bem como a heurística de construção (proveniente do desenvolvimento do artefato), contribuição
do método DSR para o avanço de conhecimento (DRESCH; LACERDA; ANTUNES, 2020).
A fase seguinte do método DSR demonstrado na Figura 10 é a Avaliação do Artefato
(Passo 8). Nessa etapa, o investigador preocupa-se em observar e avaliar o funcionamento da
solução proposta, averiguando se o artefato está funcionando a contento, de acordo com os
requisitos pré-estabelecidos. A avaliação do artefato pode ser realizada em ambiente simulado
ou real, a depender do tipo de artefato. (DRESCH; LACERDA; ANTUNES, 2020) destaca
que “elementos de outros métodos de pesquisa, como a pesquisa-ação, por exemplo, poderão
ser utilizados, uma vez que, muito provavelmente, haverá a necessidade de interação entre o
pesquisador, os usuários e as pessoas da organização na qual o artefato está sendo instanciado”.
Ainda sob a ótica de (DRESCH; LACERDA; ANTUNES, 2020), a resultante desse passo, além
do artefato devidamente avaliado, é a “formalização das heurísticas contingenciais, por meio
das quais o pesquisador poderá explicitar os limites do artefato e suas condições de utilização,
ou seja, a relação do artefato com o ambiente externo em que irá atuar, o qual foi especificado
durante a conscientização do problema”.
Na etapa de Explicitação das Aprendizagens (9), os pesquisadores devem relatar as
dificuldades encontradas no desenvolvimento do artefato, explicando de forma concisa os pontos
altos e baixos do processo de pesquisa. Segundo (DRESCH; LACERDA; ANTUNES, 2020),
o “ objetivo dessa etapa é assegurar que a pesquisa realizada possa servir de referência e como
subsídio para a geração de conhecimento, tanto no campo prático quanto no teórico”.
Já na fase de Conclusão (10), os resultados do trabalho, bem como as decisões tomadas
durante a execução da pesquisa devem ser apresentadas e formalizadas. (DRESCH; LACERDA;
ANTUNES, 2020) ressalta que devem ser apontadas nesta etapa as limitações da pesquisa,
visando orientar, inclusive, trabalhos futuros e novas ideias, onde um novo ciclo da DSR se inicia
para estudar os novos problemas observados caso sejam identificados.
Finalizando o ciclo DSR apresentado, temos a Generalização para uma Classe de
Problemas (11) e Comunicação dos Resultados (12). Na perspectiva de (DRESCH; LACERDA;
ANTUNES, 2020), a “generalização permite que o conhecimento gerado em uma situação
específica possa, posteriormente, ser aplicado a outras situações similares e que são enfrentadas
por diversas organizações”, logo, para que o conhecimento gerado seja utilizado por outros
interessados na mesma temática, é necessário sua publicação no maior número de meios de
informação científicas possível, como em periódicos, revistas setoriais, seminários, congressos
etc.
3.3.2 Plano de Ação de Desenvolvimento e Implantação do Artefato
O desenvolvimento e implantação do artefato (passos 6 e 7 do método DSR) do Sistema

de Monitoramento e Medição Inteligente de Água - SMMIA, envolve 8 fases que abordam
desde a instalação e configuração de sistemas (middleware Dojot) ao monitoramento do artefato
(Passo 8 do método DSR).
Essa etapas consistem em:
1. Instalação e configuração do middleware Dojot;
2. Desenvolvimento do software embarcado;
3. Testes, verificação de sensores e comunicação com o Dojot;
4. Caracterização do perfil de consumo de água do campus;
5. Ensaio para calibração do sensor de fluxo;
6. Cálculo da incerteza da medição e índice de desempenho do medidor;
7. Montagem e instalação do protótipo;
8. Monitoramento do sistema de medição inteligente de água.
É importante ressaltar que embora o campus Campina Grande do IFPB não possua
laboratório certificado para avaliação e calibração de instrumentos de medição de água, os
procedimentos metrológicos utilizados neste trabalho são baseados nas normas brasileiras
(NBR) NBR ISO (International Organization for Standardization) 5168:2015 (Procedimento
para avaliação de incertezas), NBR 15538:2014 (Medidores de água potável — Ensaios para
avaliação de eficiência) e NBR 16043:2021 (Medidores para água potável fria e água quente),
que se divide em 4 partes:
1. Requisitos técnicos e metrológicos (NBR 16043-1:2021);
2. Métodos de ensaio (NBR 16043-2:2021);
3. Requisitos não metrológicos não abrangidos pela ABNT NBR 16043-1 (NBR 16043-
3:2021) e,
4. Requisitos de instalação (NBR 16043-4:2021).
As etapas são descritas a seguir.

3.3.2.1 Instalação e configuração do middleware Dojot
O Dojot é um middleware baseado na arquitetura de microsserviços, que funciona sobre

o conceito de contêineres de aplicação, no qual pode ser instalado e configurado através da
tecnologia Docker (nó único) ou Kubernetes (conjunto de nós). De acordo com a documentação
do desenvolvedor (DOJOT, 2020), os requisitos de hardware para suportar 500 dispositivos com
um intervalo de mensagens a cada 15 segundos estão contidos na Tabela 4.
Tabela 4 – Requisitos de hardware para instalação do Dojot.

Implantação da Dojot Tipo de Instalação CPU RAM Espaço livre em disco
Docker Nó único 4 Núcleos 6 GB 20 GB
Kubernetes Master 2 Núcleos 2 GB 30 GB
Kubernetes Worker 4 Núcleos 6 GB 40 GB
Kubernetes Balancer 1 Núcleo 1 GB 10 GB
Fonte: Adaptado de (DOJOT, 2020)
Para o ambiente de monitoramento e “medição inteligente de água” desenvolvidos e

instalados neste trabalho, bem como para o gerenciamento do ecossistema IoT, foi utilizado
o Dojot versão 0.6.1 e foram utilizadas as configurações padrões do Docker Compose (versão
Docker Engine; Docker-Compose), em que o middleware foi instalado em uma distribuição
Linux Debian (versão 10.9.0) no servidor Lenovo (modelo ThinkSystem SR630) localizado
na Coordenação de Tecnologia da Informação do campus Campina Grande do IFPB, em um
ambiente virtualizado (hypervisor VMware ESXi versão 6.7) de rede privada.
Após a instalação da plataforma, simulou-se a comunicação de um dispositivo IoT
através do protocolo MQTT, utilizando a ferramenta Mosquitto para subscrever (mosquitto_sub)
e publicar (mosquitto_pub) informações no Dojot. Todos os procedimentos de testes estão
descritos na documentação do Dojot2 .
3.3.2.2 Desenvolvimento do software embarcado
Para o desenvolvimento da aplicação para a plataforma embarcada WIFI LoRa® 32

utilizou-se a ferramenta Visual Studio Code em conjunto com o plugin PlatformIO. A linguagem
de programação utilizada foi a linguagem C, com o framework para Arduino. As principais
bibliotecas utilizadas foram:
• “FlowMeter.h”: biblioteca utilizada para calibração do sensor de fluxo;
• “DallasTemperature.h”: biblioteca específica para leitura de temperatura do sensor DS18B20;
• “Adafruit_BME280.h”: biblioteca para leitura de temperatura, umidade e pressão atmosfé-

rica do sensor BME280.
2 Disponível em: Documentação do Dojot. Acesso em: 25 de jan. de 2023.
A lista completa com todas as bibliotecas utilizadas, bem como o código-fonte da solução
implementada está disponível no repositório do projeto3 .
3.3.2.3 Testes, verificação de sensores e comunicação com o Dojot
Nesta etapa, foram realizados testes básicos para verificação dos componentes eletrônicos
do artefato, em que foi possível verificar a comunicação entre os sensores e o WIFI LoRa® 32,
plataforma Dojot e LoRa® gateway. O parâmetros de configuração do Setup inicial utilizado
para comunicação de camada física LoRa® está contido na Tabela 5 .
Tabela 5 – Setup inicial da camada física LoRa®.

Parâmetro Valor Configurado
Frequência 915 mHz
Potência de transmissão 14 dBm
Fator de espalhamento (SF) 7
Largura de banda 500 kHz
Taxa de código 4/5
Uma avaliação da comunicação em ambiente real é apresentada na Seção 4.3.
3.3.2.4 Caracterização do perfil de consumo de água do campus

De acordo com (ABNT, 2014), o perfil de consumo é uma
"característica proveniente do consumo de água potável em um determinado

consumidor, relacionado a vazão instantânea de operação e os volumes escoados
em cada faixa de vazão por um período significativo, para um determinado
grupo de consumidores, escolhidos de acordo com o seu consumo médio mensal
cadastrado, pressão da rede de distribuição e regime de abastecimento (direto,
indireto ou misto)”.
Logo, a caracterização do perfil de consumo de água (regime de vazões ⇥ volume

totalizado) e pressão é importante para o correto dimensionamento do sensor de medição. Nesta
etapa, realizou-se o levantamento do perfil de consumo estabelecido no Anexo C da NBR
15538:2104.
Para isso, foi realizado o monitoramento em tempo real durante o período de sete dias,
no ponto de entrada de água do campus, através do sensor de vazão FS400A G1 e do sensor de
pressão OEM 1.2 MPa, conectados ao WIFI LoRa® 32, enviando pacotes com as informações
para a plataforma Dojot a cada 15 segundos, onde os dados foram armazenados. Ainda nesta
etapa, realizou-se o levantamento do histórico de consumo de água do campus, do período de
Janeiro de 2022 a Dezembro de 2022, através da plataforma WEB da concessionaria de água
CAGEPA. Uma análise detalhada desta etapa pode ser observada na Seção 4.4 deste documento.
3 Repositório do Projeto SMMIA
3.3.2.5 Ensaio para calibração do sensor de fluxo

De acordo com (ABNT, 2014),
“Cada instrumento de medição pode introduzir incertezas. O objetivo principal

da calibração é reduzir a incerteza na medição para um nível aceitável. O
processo de calibração atinge este objetivo, substituindo a grande incerteza
de um instrumento não calibrado pela menor combinação de incertezas do
instrumento-padrão e da comparação entre este e o instrumento de medição”.
Nesse contexto, o sensor de fluxo adotado no desenvolvimento do artefato SMMIA deve

ser calibrado para reduzir o erro de indicação, já que, o principal parâmetro a ser medido pelo
medidor inteligente de água depende desse sensor. O FS400A G1 é um sensor de fluxo do tipo
turbina, que contém em sua estrutura um sensor de efeito hall (montado externamente), um rotor
de alta precisão provido de aletas (montado axialmente dentro do sensor), e um núcleo magnético
(imã) inserido no corpo da turbina. O fluido a ser medido, ao atravessar o sensor de fluxo, desloca
o rotor que passa a girar a uma velocidade angular (rotacional) proporcional à vazão. A aleta
do rotor ao se movimentar próximo do sensor de efeito hall, aplica uma variação de campo
magnético sobre o componente, que gera uma tensão alternada (pulso) na saída (SENAI, 2015),
como ilustra a Figura 11.
Figura 11 – Sensor de fluxo FS400A G1. Fonte: Adaptado de (HAOYU, 2021)
Cada pulso representa um volume discreto de forma que o número total de pulsos gerados
em determinado período de tempo corresponde ao volume total medido pelo sensor. A esse pulso
dar-se o nome de Fator de Calibração “K” ou coeficiente de vazão da turbina, que é dado pela
Equação 1: ✓ ◆
f requncia(pulso/seg)
K(pulso/volume) = . (1)
vazao(volume/tempo)
De acordo com a documentação do sensor encontrada em (HAOYU, 2021), o fator de

calibração K padrão do dispositivo é 4, 8, como pode ser observado na Figura 12, que ilustra a
curva característica da relação de frequência de rotação da turbina com a vazão total (em l/min)
contabilizada pelo sensor.
Figura 12 – Curva característica do sensor de fluxo FS400A G1 (Equação 1).

Fonte: Adaptado de (HAOYU, 2021)
Assim, um sensor de vazão deve ser calibrado com o menor erro de indicação possível
para a faixa de vazão nominal (Qn ou Q3), ou seja, a faixa de vazão mais frequente, expressa em
metros cúbicos por hora, na qual o medido deve operar dentro da margem de erro de indicação
definida em norma (ABNT, 2014).
Embora na teoria os sensores de vazão do tipo turbina apresentem um comportamento
linear, na prática podem ocorrer variações para diferentes tipos fluxos, em que é necessário
ajustar o fator de calibração K para se obter uma leitura mais próxima da realidade.
Segundo (ABNT, 2021a), existem dois métodos de calibração para medidores de água:
• Calibração estática:
"Neste método a vazão é estabelecida abrindo uma válvula situada a jusante

do medidor e é interrompida pelo fechamento da mesma válvula. A leitura
do volume indicada é feita quando o medidor está estático em que mede-se
o tempo entre o início do movimento de abertura da válvula e o término do
movimento de fechamento. Durante o início do escoamento e durante o período
que o escoamento ocorre em vazão constante, o erro de indicação do medidor
varia em função da variação da vazão (curva de erros)” (ABNT, 2021a).
• Calibração dinâmica:
“A medição é efetuada quando a vazão está estabilizada. Um dispositivo direci-

ona o escoamento para um reservatório calibrado no início da medição e diverge
o escoamento de volta para a linha no final do ensaio. A leitura é efetuada com
o medidor em funcionamento, sendo a leitura sincronizada com o movimento

do diversor. O volume coletado no reservatório é o volume que passou pelo
medidor durante o intervalo de medição. Neste caso, a incerteza introduzida no
volume coletado devido ao início e término da medição pode ser considerada
não significativa, se o chaveamento em cada direção não diferir de mais de 5%
e se o tempo de acionamento for inferior a 1/50 do tempo de escoamento total
do ensaio” (ABNT, 2021a).
Nesta etapa, utilizou-se o método de calibração estático, uma vez que o procedimento
operacional torna-se mais adequado ao modelo de bancada de calibração adaptada da norma
ABNT NBR ISO 4185:2009 utilizada para este fim. A Seção 4.5 apresenta em detalhes o
procedimento e os resultados obtidos nesta etapa.
O processo de calibração também é utilizado para estimar a incerteza de medição Tipo A
determinada, utilizando-se a análise estatística em uma série de observações, como também o
índice de desempenho do medidor (IDM), que é um “parâmetro de avaliação do desempenho
do medidor que permite calcular qual é a capacidade que um equipamento qualquer tem de
registrar o volume por ele escoado, baseado em um perfil de consumo” (SNIS, 2018). A subseção
seguinte descreve o passo a passo para o cálculo da incerteza de medição e do IDM do artefato
desenvolvida.
3.3.2.6 Cálculo da incerteza da medição e índice de desempenho do medidor

O método desenvolvido na NBR15538:2014 para o cálculo do IDM, de acordo com
(SNIS, 2018),
"consiste em submeter o medidor a um ensaio em 10 vazões distintas, cada

vazão representando uma faixa entre 0 e 1.500 l/h, calculando-se o erro de
indicação do medidor nestas vazões para posteriormente calcular o erro ponde-
rado, aplicando-se um determinado peso a cada faixa de vazão de acordo com a
representatividade de determinada faixa de vazão no todo".
A Tabela 6 contêm os valores normalizados para cada faixa de vazão utilizada e os

parâmetros para determinação dos erros de indicação e cálculo do IDM, em que para medidores
com Q4  1325 l/h, a vazão de ensaio da última faixa deve ser a Q4 (ABNT, 2014).
Tabela 6 – Parâmetros para determinação do erro de indicação e IDM.

Intervalo de Vazão (l/h) Vazões para determinação dos Erros (l/h) Perfil de Consumo (%)
0a5 2,5 4,56
5 a 15 10 6,99
15 a 30 22,5 6,83
30 a 50 40 7,34
50 a 150 100 23,21
150 a 350 250 23,92
350 a 550 450 12,27
550 a 850 700 7,29
850 a 1 150 1000 5,86
1 150 a 1 500 1325 1,73
Fonte: Adaptado de (ABNT, 2014).
De acordo com (ABNT, 2014), para calcular o IDM os seguintes passos devem ser
seguidos:
1. Calcular o erro ponderado (EP): “parâmetro de avaliação de desempenho, obtido pela

associação entre o perfil de consumo e o erro relativo apresentado pelo medidor de água,
em faixas de vazões previamente definidas, representado pela seguinte equação” (ABNT,
2014):
Â [(erro Qx ) ⇥ (peso Qx )]
EP(%) = , (2)
100
em que peso Qx é o volume consumido em cada faixa de vazão/volume total consumido.
2. Calcular o índice de desempenho da medição (IDM): “valor numérico percentual que

corresponde ao desempenho de um medidor de água, sob condições específicas de ensaio,
obtido pela equação” (ABNT, 2014):
IDM = 100 + EP. (3)
Como apresentado na Seção 2.1.3, o parâmetro associado ao resultado de uma medição,

que caracteriza a dispersão de valores atribuídos à grandeza submetida à medição, é chamado de
incerteza da medição, e comumente é expressada da seguinte forma: (valor da grandeza medida
± incerteza da medição) [unidade].
A seguir, são transcritos trechos da Seção 5 (Avaliação da incerteza em um processo de
medição) da NBR ISO 1568 para uma melhor compreensão da relação matemática do cálculo da
incerteza da medição.
“Se a relação funcional entre as grandezas de entrada X1 , X2 , ..., XN e a grandeza de
saída Y em um processo de medição de escoamento for especificada na Equação 4:
Y = f (X1 , X2 , ..., Xn ) , (4)
então, uma estimativa de Y , denominada y, é obtida da Equação 4, utilizando as estimati-

vas de entrada x1 , x2 , ..., xN , como mostra a Equação 5:
y = f (x1 , x2 , ..., xn ) . (5)
Desde que as grandezas de entrada Xi sejam não correlacionadas, a incerteza total do

processo pode ser encontrada, calculando e combinando a incerteza de cada um dos fatores de
contribuição, de acordo com a Equação 6:
s
N
uc (y) = Â [ciu (xi)]2. (6)
i=1
Quando o grau de interdependência é reconhecidamente pequeno, a Equação 6 pode

ser aplicada mesmo se algumas das grandezas de entrada forem correlacionadas. Cada um dos
componentes individuais da incerteza u(xi ) é avaliado usando um dos métodos a seguir:
• avaliação do Tipo A: calculada a partir de uma série de leituras, empregando métodos

estatísticos, como descrito na Seção 6 da norma;
• avaliação do Tipo B: calculada utilizando outros métodos, como avaliações de engenharia,

como descrito na Seção 7 da norma.
Os coeficientes de sensibilidade ci fornecem os elos entre a incerteza em cada entrada e

a incerteza resultante na saída.”
A NBR ISO 1568, em seu Anexo A, descreve o procedimento passo a passo para o
cálculo da incerteza da medição, que consiste em 8 passos:
1. Definir se a incerteza será dimensional ou adimensional: “Decidir se serão usadas esti-

mativas das incertezas dimensionais ou adimensionais (por exemplo, ppm, porcentagem)
para evitar qualquer confusão. Ao tomar esta decisão, deve se levar em consideração a
recomendação da Seção 9 referente aos parâmetros com zeros arbitrários” (ABNT, 2015).
2. Definir a relação matemática: “Determinar a relação matemática entre as grandezas de

entrada e a grandeza de saída, de acordo com a Equação 4” (ABNT, 2015).
3. Calcular a Incerteza-padrão: identificar as fontes de incerteza em cada uma das grandezas

de entrada, que podem ser divididas arbitrariamente em categorias, como, por exemplo:
incerteza na calibração, incerteza na coleta de dados, incerteza no processamento dos dados,
incerteza devido aos métodos, outras fontes, em que deve-se estimar a incerteza-padrão
para cada fonte. O método de cálculo para cada componente depende das estimativas das
incertezas fornecidas e das distribuições de probabilidade associadas. Os dados disponíveis
usualmente permitem que a incerteza-padrão seja calculada utilizando um dos métodos a
seguir (ABNT, 2015).
• Avaliações Tipo A - Desvio-padrão da média de medições repetidas, dado pela

Equação 7:
u (X̄i ) = S (X̄i ) . (7)

• Avaliações Tipo B - Baseadas na experiência e avaliação subjetiva, em que tipi-

camente são distribuição retangular de probabilidades e/ou distribuição normal de
probabilidades, dadas pelas equações 8 e 9:
ai
u (Xi ) = p . (8)
3
U
u (Xi ) = . (9)
K
4. Cálculo dos Coeficientes de sensibilidade: Os coeficientes de sensibilidade podem ser
calculados de modo dimensional ou adimensional (depende da escolha do Passo 1), usando
tanto métodos analíticos como numéricos, e são dados pelas Equações 10 e 11 (ABNT,
2015):
∂y Dy
ci = ⇡ . (10)
∂ xi Dxi
∂ y xi Dy xi
ci = ⇡ . (11)
∂ xi y Dxi y
5. Cálculo da Incerteza combinada: Verificar se algumas das entradas estão correlacionadas,
caso não haja correlação, calcular a incerteza-padrão combinada da medida a partir da
Equação 12 (dimensional) e Equação 13 (adimensional). “Se houver correlação, seguir o
Guia apresentado no Anexo F” (ABNT, 2015).
s
N
uc (y) = Â [ciu (xi)]2. (12)
i=1
s
N ⇥ ⇤ ⇤2
u⇤c (y) = Â ci u⇤ (xi ) . (13)
i=1
6. Grandezas de entrada não-confiáveis: “Quando forem empregadas grandezas de entrada

não confiáveis, por exemplo, pequenas amostras, o procedimento do Anexo C deve ser
usado para obter o fator de abrangência para o cálculo da incerteza expandida” (ABNT,
2015), demonstrada a seguir.
7. Cálculo da Incerteza expandida: de forma análoga ao Passo 5, o cálculo da incerteza

expandida também é dado de forma dimensional e adimensional, através das Equações 14
e 15:
U = Kuc (y) . (14)

U ⇤ = Ku⇤c (y) . (15)
8. Expressão dos resultados: “Os resultados calculados de acordo com este Anexo A devem
ser apresentados como descrito na Seção 10” (ABNT, 2015).
Como demonstrado nos parágrafos anteriores, o cálculo da incerteza da medição é uma

atividade complexa, que envolve diversos fatores e procedimentos que devem ser seguidos,
como também depende da expertise do profissional e informações complementares. Nesta etapa,
realizou-se apenas a avaliação Tipo A da incerteza da medição. Os detalhes desse processo são
apresentados na Seção 4.6.
3.3.2.7 Montagem e instalação do protótipo
A montagem final do medidor inteligente de água desenvolvido neste trabalho baseou-se

nas recomendações da norma brasileira NBR 16043-4 (no que couber), em que são definidos os
seguintes critérios a jusante do medidor (ABNT, 2021b):
• um dispositivo de comprimento ajustável para facilitar a instalação e a remoção do

medidor de água. Este dispositivo é especialmente recomendado para medidores com
Q3 16 m3 /h;
• um dispositivo que inclua uma válvula de drenagem, que possa ser usada para monitora-
mento de pressão, esterilização e amostragem de água;
• uma válvula de bloqueio para medidores com Q3 > 4 m3 /h, que deve ser operado no
mesmo sentido que a válvula a montante e,
• uma válvula de retenção, se necessário, exceto para aplicação de escoamento bidirecional.
Vale salientar que a NBR 16043-4 aborda outros critérios de instalação, como métodos
para eliminar perturbações de escoamento de água em tubulações, além de outras recomendações.
Na seção 4.1.1.1 são exibidas imagens do medidor inteligente de água desenvolvido e instalado
no cavalete de entrada de água do campus.
3.3.2.8 Monitoramento do sistema de medição inteligente de água
Após a instalação do artefato, monitorou-se remotamente através das interfaces de

visualização de dados do Dojot, como também realizou-se vistorias periódicas in loco para
verificação de possíveis anomalias e vazamentos. Esta etapa refere-se ao Passo 8 (Avaliação do
Artefato) do método DSR adotado. os resultados obtidos neste passo podem ser observado nas
seções 4.2 e 4.1.1.1.
3.4 Ferramentas, Dispositivos e Materiais Utilizados
A Tabela 7 contem a lista de materiais utilizados no desenvolvimento do SMMIA,

relacionando o quantitativo e preço unitário estimado dos produtos.
Tabela 7 – Lista de ferramentas, materiais e dispositivos utilizados.

1 Sensor de Fluxo Tipo Turbina FG400S A 1” 01 R$ 135,00
2 Sensor de Pressão OEM 1.2 MPa 01 R$ 145,00
3 Válvula Solenóide 01 R$ 230,00
4 Pressurizador de Água Lorenzetti PL-20 01 R$ 850,00
Válvula Reguladora de Pressão
5 Válvula 1” 01 R$ 400,00
com Manômetro Analógico
6 Caixa Acrílica Caixa para medidor de luz Taf 01 R$ 65,00
7 Válvula de passagem DECA 1/4 volta 01 R$ 130,00
8 Servidor de Aplicações ThinkSystem SR630 01 Já disponível no Campus
9 Sistema Embarcado WIFI LoRa 32 (V2) 01 R$ 200,00
10 Válvula de retenção de ar CONVALLIS 1” 01 R$ 98,00
11 Filtro de Partículas Lorenzetti Loren Acqua 10” 01 R$ 380,00
Sensor de Temperatura,
12 BME 280 01 R$ 60,00
Umidade, e Pressão ATM.
13 Sensor de Temperatura DS18B20 01 R$ 25,00
14 LoRa Gateway Dragino LG02 01 R$ 700,00
15 Conversor ADC de 16 bits ADS 1115 01 R$ 90,00
O custo estimado total do projeto, com a aquisição de sensores, equipamentos e acessórios

foi de R$ 3.508,00. Levando-se em consideração apenas os itens (1, 2, 3, 5, 6, 7, 9, 10, 11, 12,13
e 15) referentes ao medidor inteligente de água, o custo total estimado foi de R$ 1.958,00. Vale
ressaltar que o objetivo do projeto não foi desenvolver um medidor inteligente de água de menor
custo em comparação a outras soluções já apresentadas na literatura, mas, um sistema que melhor
se ajuste ao propósito geral do projeto.
Além disso, um possível produto final oriundo a partir do protótipo desenvolvido poderia
ter o custo reduzido, a partir da confecção de placas de circuito impresso customizadas, e
aquisição dos componentes em maior quantidade direto dos fornecedores. No entanto, essa
análise de custo final está fora do escopo desta dissertação.
64
4 RESULTADOS
São discutidos no presente capítulo os resultados obtidos durante os ensaios executados

no desenvolvimento do protótipo. Para um melhor entendimento dos resultados a serem apre-
sentados, o capítulo foi dividido em seções visando elucidar as questões de pesquisa levantadas,
bem como, alguns conceitos-chave são recapitulados.
Inicialmente, na Seção 4.1 (Protótipo SMMIA), apresenta-se o projeto do protótipo em
camadas, elencando as tecnologias utilizadas em cada camada e a justificativa de suas escolhas.
Na Seção 4.2 (Middleware Dojot), demonstra-se os resultados quantitativos obtidos
com o middleware Dojot, em relação ao consumo de recursos físicos da máquina virtual onde o
sistema foi instalado, ilustrando alguns telas do dashboard do Influxdb (microsserviço adicionado
ao Dojot) que fornece informações de métricas do sistema sobre o consumo de memória RAM,
disco, CPU, rede, entre outros.
Em seguida, na Seção 4.3 (Comunicação LoRa®), caracterizam-se os aspectos da co-
municação LoRa®, apresentando o setup de configurações da camada física, bem como os
resultados obtidos na comunicação entre WiFi LoRa® 32 (V2) da Heltec e o LoRa® gateway
Dragino LG02, em relação aos parâmetros RSSI e percentual de pacotes perdidos.
Na seção 4.4 (Caracterização do Perfil de Consumo), apresentam-se histogramas que
demonstram as vazões e as pressões típicas obtidas no cavalete de entrada de água, conforme
preconiza a norma ABNT NBR 15538:2014.
Por fim, na Seção 4.5 (Calibração do Sensor de Vazão), aponta-se os passos para calibra-
ção do sensor de vazão, acompanhados do índice de desempenho do medidor de vazão FS400A
utilizado no SMMIA e do índice de incerteza da medição (Seção 4.6).
4.1 Protótipo SMMIA
A presente seção discorre sobre o desenvolvimento do artefato para monitoramento e

medição inteligente de água, implantado no campus Campina Grande do IFPB, como um projeto
piloto e uma iniciativa para tornar o campus um “campus inteligente” (Smart Campus).
O SMMIA (Sistema de Monitoramento e Medição Inteligente de Água) é composto por
uma solução de hardware (“medidor inteligente de água”) e software (middleware Dojot), em
uma arquitetura de camadas, que visa mensurar o consumo de água do campus Campina Grande
do IFPB de forma remota e automática, como também verificar a pressão no ponto de entrada da
rede de distribuição de água do campus, além de medir a temperatura e a umidade do ambiente
e pressão atmosférica onde o medidor inteligente de água encontra-se instalado. A seguir, é
apresentada a arquitetura do artefato desenvolvido, os dispositivos e tecnologias selecionados
Capítulo 4. Resultados 65
por camada e suas respectivas justificativas de seleção.
4.1.1 Arquitetura da Solução
O protótipo desenvolvido é baseado na arquitetura padrão de rede LoRa®/LoRa®WAN™

apresentando por (ALLIANCE, 2020), conforme ilustrado na Figura 13.
Figura 13 – Arquitetura de rede do SMMIA. Fonte: Autoria própria.
A Camada 1, ou camada física, é composta por nós sensores ou dispositivos finais

(endpoints) LoRa®, ou seja, é onde se encontram os sensores e atuadores hídricos do sistema,
conectados a um microcontrolador com transceptor LoRa® integrado. A comunicação entre os
endpoints LoRa® e o LoRa® gateway ocorre pela técnica de modulação de rádio padrão da
camada física da tecnologia. Para este cenário, não foi utilizado o protocolo LoRa®WAN™,
uma vez que a comunicação de camada física LoRa® é suficiente para a aplicação.
A Camada 2 (ou camada de rede), é composta por um LoRa® gateway, dispositivo
responsável por traduzir as mensagens e encaminhar para a aplicação através dos protocolos
TCP/IP (camada de transporte e rede) e MQTT (camada de aplicação).
Por fim, a Camada 3 é composta por um servidor de aplicação, em que os dados enviados
pelos endpoints LoRa® são processados, armazenados e encaminhados para as diferentes
aplicações que possuem interesse em consumir os dados enviados pelos nós finais.
O modelo de três camadas garante uma maior flexibilidade no desenvolvimento, pois
cada camada é independente e pode ser facilmente adaptada a novos contextos e tecnologias que
venham a surgir, além de facilitar os testes e a manutenção do artefato desenvolvido.
4.1.1.1 Camada Física
Na camada física, desenvolveu-se um medidor inteligente de água (Smart Water Meter)

modular, em que a parte "inteligente"(eletrônica e software embarcado) é separada dos sensores
hídricos, conforme ilustram as Figuras 14 e 15 sob diferentes perspectivas. Os elementos
do medidor no cavalete de entrada de água do campus foram instalados entre duas junções
hidráulicas (também conhecida como união soldável), permitindo assim uma maior flexibilidade,
facilidade de manutenção e ajustes da solução.
Figura 14 – Instalação do "medidor inteligente de água" no cavalete de entrada de água do

campus (perspectiva vertical). Fonte: Autoria própria.
Figura 15 – Instalação do medidor inteligente de água no cavalete de entrada de água do campus

(perspectiva horizontal). 1- Válvula de abertura manual; 2 - filtro de água; 3 - válvula
reguladora de pressão com manômetro analógico e sensor eletrônico de pressão; 4 -
sensor de vazão; 5 válvula solenoide; 6 - válvula de retenção de água. Fonte: Autoria
própria.
Para uma visão mais detalhada da interconexão elétrica e hidráulica do sistema, ilustra-se
na Figura 16 o diagrama esquemático com suas respectivas legendas.
Figura 16 – Diagrama esquemático de interconexão hidráulica e elétrica do medidor inteligente

de água no cavalete de entrada de água do campus. Fonte: Autoria própria.
A lista completa de todos os elementos que compõe a solução do medidor inteligente de

água é apresentada a seguir:
1. uma Válvula hidráulica de abertura manual 1/4 de volta (metálica);

2. um sensor de fluxo de água do tipo turbina, modelo FS400A G1, com sensibilidade de
medição 1-60 l/min e pressão máxima de operação de 1,2 MPa;
3. um sensor de pressão modelo OEM 1,2 MPa com uma faixa de trabalho entre 0 e 12
bar/174 psi;
4. um manômetro analógico com escala de medição de 0 a 4 bar;
5. uma válvula reguladora de pressão manual;
6. uma válvula solenoide do tipo normalmente aberta (NA) operando a 220V AC;
7. um módulo relé de estado sólido 5V de um canal para carga de até 250V AC/2A;
8. um sensor de temperatura, umidade e pressão, modelo BME280;
9. um sensor de temperatura, modelo DS18B20;
10. uma antena omnidirecional de 5 dBi;
11. um dev-board IoT Wi-Fi LoRa®® 32 (V2) do fabricante Heltec;
12. um conversor de tensão Dc-Dc tipo step down com display LCD, modelo ZK-J5X;
13. uma caixa acrílica para acomodação da placa eletrônica;
O dev-board IoT WIFI LoRa® 32 (V2) do fabricante Heltec (também conhecido por
ESP32 LoRa® Heltec) foi selecionado por apresentar uma solução compacta (o que facilita
a prototipagem), com vários recursos de conectividade (conforme já apresentado na Seção ),
a um custo relativamente baixo, como também por possuir uma vasta documentação e boa
disponibilidade no mercado.
Já o sensor de fluxo de água do tipo turbina, modelo FS400A G1, foi escolhido por
apresentar uma alta taxa de abertura ou rangeabilidade (turndown ratio ou rangeability) de 60:1,
possibilitando uma maior escala de medição se comparado a outros sensores do mesmo tipo
com turndown ratio inferior. Ademais, o sensor oferece um custo inferior a outras soluções do
mercado (como por exemplo, sensores de fluxo baseados na tecnologia ultrassom) e baixa taxa
de erro de medição (± 3 a 5% por padrão), que pode ser reduzido a patamares menores quando
devidamente calibrado (ver Fator de Calibração K na Seção 3.3.2.5) via software para o fluxo
operacional desejado.
A válvula reguladora de pressão foi selecionada por apresentar mecanismo de ajuste
manual da pressão, bem como derivações para acomodação do manômetro analógico e do sensor
eletrônico de pressão, o que possibilita a verificação da pressão in loco, facilitando a detecção de
discrepâncias de medição entre os medidores de pressão.
O sensor BME280 foi adicionado à solução para fins de acompanhamento dos níveis de
temperatura, umidade e pressão dentro da caixa onde a parte eletrônica do medidor inteligente
foi instalado. Já o sensor DS18B20 foi escolhido por ser blindado e suportar as intemperes do
tempo, servindo para monitorar a temperatura ambiente fora da casa de máquina onde o medidor
encontra-se instalado.
A válvula solenoide foi adotada para acionamento remoto e automático do sistema em
caso de detecção de anomalias no fluxo de água por algoritmos de detecção de vazamento
(implementação futura, com adição de novos medidores à rede de distribuição de água do
campus), controlando a abertura ou fechando do fluxo da água e, consequentemente, evitando
desperdícios. Além disso, poderá ser acionada remotamente através de aplicativo para celular
(APP de implementação futura) para facilitar a manutenção e o controle de enchimento da caixa
d’água central de distribuição de água do campus.
Os demais dispositivos que contemplam a solução foram adotados por suas características
de usabilidade, compatibilidade com os demais elementos da solução e pela disponibilidade de
mercado.
Complementando a solução, dois elementos passivos são sugeridos para melhorar a
acurácia de medição do sistema:
1. um filtro de partículas de alta vazão e,
2. uma válvula de retenção (bloqueadora) de água.
A utilização destes elementos são imprescindíveis para uma medição do consumo de

água mais próximo da realidade, uma vez que o filtro de partículas garante a passagem de água
limpa, sem resíduos, o que aumenta a vida útil dos sensores, bem como garante que partículas
como grãos de areia, argila, entre outros, não causem perturbações na medição dos sensores. Já
o uso da válvula de retenção de água garante que apenas o fluxo de água seja contabilizado em
um sentido, impedindo que o fluxo da água retorne e seja contabilizado.
Todos os dispositivos hidráulicos utilizados neste projeto possuem diâmetro externo (DE)
de uma polegada (1 in, 32 mm ou 1”, exceto o filtro de partículas, que possui um diâmetro de 1
1/2"), seguindo o padrão de tubulação hidráulica do ponto de entrada de água do campus.
A caixa que acomoda a parte eletrônica do sistema, é esboçada na Figura 17. O sistema é
alimentado através da rede elétrica (220V AC), no qual é utilizado uma fonte de alimentação de
12V/2A para alimentar a fonte interna da caixa, em que é possível verificar a tensão e acorrente
de saída. A conexão da caixa e os sensores no cavalete de entrada de água do campus se dá
através de cabos de rede Categoria 6.
Figura 17 – Caixa do SMMIA. Fonte: Autoria própria.
Destaca-se que o consumo energético do sistema se manteve praticamente constante em

aproximadamente 115 mA, com picos de 120 mA a 125 mA quando em transmissão LoRa®.
Também foi implementado no sistema, o horário de fechamento (23:00) e abertura
(06:00) da válvula solenoide, como uma medida protetiva de esquecimento do operador em
deixar a válvula de passagem de água do cavalete aberta durante a noite, evitando assim que a
caixa d’água trasborde, desperdiçando água, algo que é corriqueiro no campus. O código-fonte
do dispositivo embarcado utilizado na solução SMMIA pode ser consultado no repositório do
projeto1 .
4.1.1.2 Camada de Rede
Na camada de rede utilizou-se o LoRa® gateway do fabricante Dragino, modelo LG02

de canal duplo (ver Figura 18). De acordo com o fabricante, o appliance (solução de hardware +
software integrados em uma “caixa”) utiliza uma distribuição Linux customizada para controlar
diretamente dois módulos LoRa® de frequências de operação distintas (Sx1276 - 868/915MHZ
e Sx1278 - 433Mhz), permitindo ao dispositivo funcionar no modo LoRa® full duplex.
Figura 18 – Arquitetura do LoRa® gateway Dragino LG02. Fonte: (DRAGINO, 2020).
A escolha por esse dispositivo se deu por apresentar uma relação custo-benefício alinhada
à realidade financeira do projeto, bem como por oferecer um conjunto de funcionalidades
adequado à aplicação em desenvolvimento (como por exemplo: interface Web para configuração
de parâmetros de camada física LoRa® e logs de comunicação LoRa®), o que diminui a
complexidade e facilita a implementação da rede LoRa®.
O dispositivo dá suporte à conexão de até 300 dispositivos finais dependendo das con-
figurações adotadas, o que garante uma escalabilidade para projetos futuros. Além disso, a
interface de configuração é simples e amigável, com uma rápida curva de aprendizagem e uma
boa documentação disponível no site do fabricante.
Na Seção 4.3 apresenta-se o setup de configuração do dispositivo, o script de funciona-
mento do protocolo MQTT implementado pelo fabricante e uma análise acerca do comporta-
mento da potência de sinal (RSSI) e da taxa de perda de pacotes durante os ensaios.
4.1.1.3 Camada de Aplicação
Na camada de aplicação utilizou-se a plataforma Dojot (versão 0.6.1) desenvolvida no

Brasil pelo CPqD. O Dojot é um middleware que fornece um conjunto de recursos avançados
que simplificam o gerenciamento do ecossistema IoT, como por exemplo:
• APIs de código aberto, facilitando o acesso de aplicações externas aos recursos da plata-
forma;
• Gerenciamento do ciclo de vida de dispositivos finais (planejamento, configuração e

monitoramento, bem como, atualizações de firmware de endpoints remotamente);
• Interface visual para construção de fluxos de dados e regras de processamento de dados

em tempo real;
• Persistência dos dados;

• Dashboard com interface intuitiva para acesso aos dados em tempo real.
A opção por esta plataforma se deu por atender perfeitamente ao propósito do projeto
(piloto), pois, além de ser gratuita e de código aberto, a ferramenta utiliza tecnologias no estado
da arte no campo de serviços IoT, com constantes atualizações pelos mantenedores, o que
faz parte da “estratégia do CPqD de dar suporte à evolução e ao aperfeiçoamento constante
da plataforma Dojot, que tem como foco o estímulo à inovação aberta e à construção de um
ecossistema voltado para a oferta de soluções IoT adequadas à realidade brasileira” (BIOCAM,
2018).
A ferramenta também fornece baixa complexidade de implantação e configuração, uma
vez que utiliza o conceito de microsserviços, facilitando a customização e escalabilidade da
aplicação sob demanda, bem como uma fácil integração com outros sistemas baseados em
serviços. Um dos diferenciais da plataforma, de acordo com (CPQD, 2017), é que a ferramenta
possibilita a criação do Produto Mínimo Viável (do inglês Minimum Viable Product - MVP),
que permite ao desenvolvedor checar e validar conceitos antes do início da implementação do
produto final.
O Dojot fornece duas interfaces para visualização de dados, sendo a primeira (referente
ao serviço “gui”) onde configura-se os dispositivos IoT e seus atributos (lado direito da imagem),
permitindo a visualização de forma rápida dos dados recebidos pela plataforma, clicando-se
sobre o nome do atributo, no qual abre-se um gráfico referente as últimas 10 registros recebidos,
como pode ser visualizado na Figura 19.
Figura 19 – Interface de configuração e visualização de dados em tempo real, versão 1 no Dojot.

Ainda na Figura 19, pode-se visualizar o nome (hidrômetro) e o Identificador de disposi-

tivo (ID) 41719c (lado esquerdo da imagem). Os atributos da aplicação SMMIA coletados pelo
Dojot são expressos em detalhes na Tabela 8 a seguir.
Tabela 8 – Atributos da aplicação SMMIA configurados no dispositivo 41719c do Dojot.

Nº Atributo Tipo Descrição
1 bar FLOAT Pressão no cavalete de água registra pelo sensor de pressão (bar)
2 er FLOAT Valor do fator de correção utilizado pela biblioteca Flowmeter (%)
3 hz INTEIRO Quantidade de pulsos do sensor de vazão FS400A (hz)
4 mch FLOAT Vazão instantane em metro cúbico hora (m³/h)
5 mct FLOAT Volume total contabilizado em metro cúbico (m³)
6 pa FLOAT Pressão atmosferica registrada pelo sensor BME280 (mPa)
7 rssi FLOAT Potência do sinal recebido no Dragino L02 (dBm)
8 ss INTEIRO Status do Solenoide (1 = acionado; 0 = desativado)
9 ta FLOAT Umidade ambiente captada pelo sensor BME280 (ºC)
10 te FLOAT Temperatura externa registrada pelo sensor (ºC)
11 tx INTEIRO Número de pacotes LoRa® enviados
12 um FLOAT Umidade ambiente captada pelo sensor BME280 (%)
13 vi FLOAT Vazão instantane em litros por minuto (l/min)
14 vt FLOAT Volume total contabilizado em litros (l)
Vale salientar que o nome dos atributos foram abreviados em no máximo 4 caracteres,
pois isso impacta no tamanho do pacote LoRa® e do JSON armazenado nos bancos de dados
(MongoDB e InfluxDB), como por exemplo, o JSON escrito no formato {"vt": 10.0} apresenta
uma redução de 10 bytes se comparada ao JSON escrito no formato {"volume_total": 10.0}.
Tratando-se de um volume de dados intenso, a depender da aplicação, pode fazer uma diferença
significativa no tempo de propagação no ar do pacote LoRa®, como também no volume de dados
armazenados.
Já a segunda interface de visualização (referente ao serviço “gui_v2” do Dojot) de dados
disponível no Dojot, oferece mais opções para visualização dos dados, com a possibilidade de
optar sobre o tipo de gráfico (dispersão, área, tabela, geolocalização e barra), quantidade de
registros a serem plotados (inclusive podendo selecionar períodos específicos) e quais atributos
de um dispositivo devem ser exibidos, como ilustrado na Figura 20.
Figura 20 – Interface de configuração e visualização de dados em tempo real, versão 2 no Dojot.

Ainda na Figura 20, observa-se que foram adicionados gráficos de visualização de

temperatura (interna e externa), vazão instantânea (l/min), volume total contabilizado (m3 ),
pressão no cavalete de entrada de água do campus, potência do sinal (RSSI) recebido no Dragino
L02 e pressão atmosférica. Os gráficos foram configurados para visualização dos últimos 50
registros, podendo ser editado a qualquer momento.
A seção a seguir traz mais informações sobre a plataforma Dojot e uma análise sobre o
comportamento da ferramenta quanto ao consumo de recursos físicos da máquina virtual na qual
foi instalada.
4.2 Middleware Dojot
Este tópico apresenta os resultados da avaliação do middleware Dojot em relação ao

comportamento de utilização dos recursos físicos da VM e dos microsserviços que compõem
a solução. Para uma melhor compreensão do comportamento da ferramenta, os dados serão
expostos em duas etapas:
1. Antes da coleta de dados, ou seja, a partir da instalação e antes de iniciar o registro das
métricas do sistema e do hidrômetro inteligente;
2. Após a coleta de dados, ou seja, após o registro das métricas do sistema (RAM, CPU, Rede
e Disco) e do hidrômetro inteligente (pressão estática e dinâmica do cavalete de entrada de
água do campus, temperatura e umidade do ambiente e vazão total e instantânea).
Os detalhes das avaliações são apresentados a seguir, na ordem mencionada anterior-

mente.
4.2.1 Avaliação Antes da Coleta de Dados
O middleware Dojot foi instalado em uma máquina virtual (VM) Debian (GNU/Linux),
versão 10.9 (64 bits), gerenciada pelo hypervisor vSphere ESXi, versão 6.7, do fabricante
VMware, sobre um host hospedeiro Lenovo ThinkSystem SR630, com as seguintes configura-
ções:
• 2 Pentes de memória RAM DDR4 de 16GB, operando a 2666 MHz;
• 4 Discos de 1.00TB 7.2K 6Gbps SATA 2.5"HDD, em RAID 5, totalizando 2791.172GB

disponíveis para armazenamento;
• 1 processador Intel(R) Xeon(R) Gold 6134 CPU @ 3.20GHz, com 8 núcleos;
Para a VM foram alocados 8 GB de memória RAM (2 GB a mais de memória RAM em

relação a configuração miníma exigida, em virtude dos serviços extras adicionados ao Dojot), 4
processadores virtuais e 20 GB de armazenamento, conforme recomendações do desenvolvedor.
Para mais detalhes consulte Requisitos de Hardware do Dojot 2 .
A Figura 21 ilustra a tela de configurações da VM executando o Debian no ESXi, após
a instalação do Dojot, como também apresenta um gráfico de consumo de recursos em tempo
real. É importante observar no gráfico o alto consumo de memória RAM (⇡6GB), com alguns
picos de carga de CPU de aproximadamente 60% do recurso alocado. Esse comportamento é
esperado, uma vez que o Dojot é um middleware baseado na arquitetura de microsserviços, no
qual diversos contêineres (39 serviços após a customização) são executados simultaneamente
para troca de informações.
Figura 21 – Configurações da máquina virtual no VMware ESXi. Fonte: Autoria própria.

2 Disponível em: Guia de Instalação do Dojot. Acesso em: 25 de jan. de 2023.
O conjunto de microsserviços que compõem o middleware Dojot e os serviços adicionais:

InfluxDB, Portainer, MongoDB Express, Telegraf e pgAdmin foram instalados através da
ferramenta Docker Compose, com a customização do compose file "docker-compose.yml" que
acompanha o repositório clonado do GitHub da plataforma (para detalhes da customização dos
serviços consulte o repositório do projeto3 ). Estes serviços são abordados a seguir.
A Figura 22 apresenta o dashboard do serviço Portainer, no qual é possível verificar o
comportamento de todos os serviços (containers) instalados e gerenciar de forma rápida (parar,
reiniciar, excluir, etc.), além de acompanhar os logs e as métricas de cada serviço.
Figura 22 – Visualização dos containers no Portainer. Fonte: Autoria própria.
Em relação ao consumo de armazenamento permanente (disco), a Figura 23 ilustra como

ficou a estrutura de diretórios e o percentual de uso após a instalação dos microsserviços do
Dojot. Ressalta-se que durante a instalação do Debian aplicou-se o sistema de arquivos EXT4
(third extended filesystem, em português: terceiro sistema de arquivos estendido) em partição
única, em disco virtual emulando um barramento SCSI (Small Computer System Interface).
Figura 23 – Alocação de disco após a instalação do Dojot. Fonte: Autoria própria.
Ainda na Figura 23, percebe-se que o espaço livre após a instalação do Dojot e serviços
adicionais foi de 7,3 GB, espaço este utilizado para armazenar os dados de métricas do sistema e
os dados do hidrômetro inteligente. Vale salientar que este espaço é compartilhado com todo
o sistema e que a dinâmica de consumo do disco vai depender também da política de retenção
de dados utilizada no Dojot, uma vez que por padrão a retenção de dados se dá por 7 dias no
MongoDB.
Destaca-se que foi adicionado o serviço MongoDB Express para facilitar a gerência dos
dados, uma vez que o Dojot ainda não apresenta uma interface para tal, ou seja, não é possível
apagar dados ou alterar a política de retenção de dados do Dojot após a instalação. A Figura 24
apresenta um exemplo da tela de gerência do MongoDB Express, referente ao device ID 76107C,
tenant 4 admin, criado no Dojot.
4 Tenant, em inglês inquilino, é uma separação lógica entre recursos que podem estar associados a vários usuários.
Fonte: Dojot.
Figura 24 – Dashboard de visualização da base de dados no Mongo Express. Fonte: Autoria

própria.
Ainda neste contexto, o serviço IndluxDB foi ativado (por padrão, encontra-se comentado
no compose file), como uma forma de redundância, já que os dados dos dispositivos IoT são ar-
mazenados tanto no MongoDB como no InfluxDB, além de apresentar uma interface de gerência
centralizada de fácil integração com outros serviços (como por exemplo o Telegraf 5 ), no qual
permite visualizar tanto as métricas do sistema, como dos microsserviços (containers Docker) e
os dados dos dispositivos IoT coletados pelo Dojot, através de dashboards customizadas.
As políticas de retenção de dados aplicadas no InfluxDB podem ser visualizadas na
Figura 25. Observa-se que foram adicionados dois buckets6 :
1. devices: recipiente responsável por armazenar os dados dos dispositivos criados no Dojot.
O tempo de retenção definido foi “ilimitado”.
2. docker: recipiente que armazenas as métricas do sistema e dos containers. A política de

retenção atribuída foi de 2 dias.
5 Telegraf é um agente baseado em servidor para coletar e enviar todas as métricas e eventos de bancos de dados,
sistemas e sensores de IoT. Escrito em Go, ele compila em um único binário sem dependências externas, e requer
um consumo mínimo de memória. Fonte: Influxdata. Disponível em: Telegraf. Acesso em: 25 de jan. de 2023.
6 Um bucket é um recipiente ou espaço alocado para armazenar objetos (arquivos).
Os buckets _monitoring e _tasks são reservados pelo sistema e criados automaticamente

durante a instalação.
Figura 25 – Dashboard de buckets do InfluxDB. Fonte: Autoria própria.
Outro serviço adicionado ao portfólio do Dojot foi a ferramenta de gerenciamento do

banco de dados PostgreSQL, o pgAdmin. Este serviço foi incluso em virtude da ausência de
funcionalidade de mudança de senha de novos usuários (Tenets) após a sua criação na interface
do Dojot, o que impossibilita o login de novos usuários. Através do pgAdmin é possível realizar
a troca da senha, gerenciar a base de dados, visualizar em tempo real as métricas do banco e
visualizar a estrutura completa das tabelas usadas pelo Dojot, conforme ilustra a Figura 26.
Figura 26 – Dashboard do pgAdmin. Fonte: Autoria própria.

4.2.2 Avaliação Após a Coleta de Dados
Após a analise preliminar do comportamento da ferramenta Dojot depois de sua instalação

e adição de serviços extras, apresenta-se a seguir os resultados observados durante a coleta de
dados. Este ensaio foi dividido em duas etapas:
1. Análise das métricas do sistema: em que observou-se a estabilidade do sistema e o consumo

de recursos do Dojot antes da carga de trabalho durante um período de 15 dias, ou seja,
antes do fluxo de dados gerado pelo hidrômetro inteligente através da comunicação LoRa®
com o middleware;
2. Análise da coleta de dados do hidrômetro inteligente: no qual registrou-se o consumo de

disco, RAM, CPU e rede provocado pela carga de trabalho do dispositivo IoT durante o
período de 7 dias, coletando dados a cada 15 s (fase de levantamento das vazões típicas).
Como reportado anteriormente nesta seção, o InfluxDB possui uma interface de gerência
que possibilita a integração com a ferramenta de coleta de dados Telegraf, permitindo registrar
métricas da VM e dos serviços executando no Docker através de dashboards customizadas com
mais opções de gráficos, facilitando a observação do comportamento (consumo de recursos)
de contêineres, da VM e do Dojot em uma única tela (serviço), embora seja possível analisar
algumas métricas também por outras ferramentas, como o Portainer (fora do escopo deste
trabalho).
Nesse sentido, apresenta-se na Figura 27 o dashboard “Docker” adicionado ao InfluxDB,
que aborda uma série de informações relevantes tanto da VM quanto dos serviços Docker, como
o consumo de disco, CPU, rede, memória RAM, tempo em execução da VM, carga de trabalho,
entre outros, em que cada serviço é representado por uma cor nos gráficos exibidos, o que
dificulta a visualização em uma imagem estática como a apresentada, pois, são 39 serviços em
execução.
Figura 27 – Dashboard de containers no InfluxDB. Fonte: Autoria própria.
As informações exibidas na Figura 27 foram processadas por um período de aproxima-

damente 15 dias, no qual foi possível verificar a estabilidade do Dojot (não foram observados
travamentos ou engasgos) antes de iniciar a carga de trabalho. Destaca-se ainda na Figura 27 que
durante esse período a média de consumo de disco ficou em torno de 62% do total compartilhado
(restando apenas ⇡6,9 GB de disco para registrar os dados do hidrômetro inteligente), o que
representa uma aumento de 5% em relação a instalação do sistema (59%), com um consumo
médio de memória RAM de 65% do total alocado (8 GB). Lembrando que o tempo de retenção
dos dados para esse bucket foi definido para apenas 2 dias.
Após essa breve observação sobre as métricas do sistema, iniciou-se o ciclo de carga de
trabalho do Dojot, em que realizou-se o registro de dados enviados pelo hidrômetro inteligente
durante o período de 7 dias, em conjunto com o registro das métricas do sistema. A Figura 28
ilustra os dados obtidos após essa etapa.
Figura 28 – Dashboard de containers no InfluxDB. Fonte: Autoria própria.
Constata-se que houve um pequeno acréscimo no consumo de memória RAM (de 65%
para 68%) e de disco (de 62% para 67%), em que o volume de dados gerado pelo hidrômetro
inteligente nesse período (incluindo alguns testes anteriores), foi de aproximadamente 106 MB,
como 1063332 objetos (documentos) gravados no MongoDB, como ilustrado na Figura 29.
Figura 29 – Dashboard de visualização de dados no MongoDB Express . Fonte: Autoria própria.
Um retrato em tempo real das métricas do sistema também pode ser observado através
do comando nativo da ferramenta Docker, o “docker stats”, que exibe todas as métricas (já
apresentas graficamente no InfluxDB) de forma numérica, como os dados expressos na Ta-
bela 9. É importante destacar que os valores entre parênteses foram adicionados para facilitar a
identificação dos serviços que mais consomem recursos, sendo “(01)” o maior consumidor de
recursos.
Tabela 9 – Dados de métricas de serviços do Dojot extraídos da ferramenta "docker stats".

CPU RAM NET NET BLOCK BLOCK
NAME
(%) (%) (IN) (OUT) (IN) (OUT)
kafka 6,05% (01) 11,73% (01) 56,4GB (01) 92,6GB (01) 126 MB (04) 1,89GB (4)
iotagent-mqtt 3,62% (02) 3,94% (06) 75,9 MB (21) 65,6 MB (20) 259 MB (03) 158 MB (7)
rabbitmq 2% (03) 1,1% (11) 377 MB (17) 397 MB (16) 45,6 MB (14) 592 MB (19)
auth 1,84% (04) 0,74% (14) 425 MB (16) 272 MB (18) 22,9 MB (23) 0B
persister 1,75% (05) 0,22% (31) 5,11GB (09) 3,09GB (12) 1,71 MB (36) 0B
mongodb 1,55% (06) 6,07% (04) 756 MB (14) 4,71GB (10) 66,6 MB (08) 83,1GB (2)
telegraf 1,37% (07) 0,74% (15) 1,34GB (12) 7,32GB (06) 108 MB (05) 0B
device-manager 1,2% (08) 0,69% (17) 3,61 MB (29) 3,81 MB (32) 15,3 MB (26) 0B
flowbroker 1,16% (09) 1,31% (09) 28,8GB (02) 18GB (02) 10,2 MB (29) 0B
apigw 0,99% (10) 4,88% (05) 7,99GB (07) 8,48GB (05) 26,4 MB (20) 53,2 kB (13)
history 0,96% (11) 0,49% (27) 4,33GB (10) 4,84GB (09) 9,41 MB (30) 0B
image-manager 0,92% (12) 0,53% (26) 136 kB (36) 72,4 kB (36) 15,1 MB (27) 0B
data-broker 0,68% (13) 0,63% (20) 18,2GB (04) 11,4GB (04) 30,1 MB (15) 4,1 kB (22)
influxdb-storer 0,67% (14) 0,55% (24) 24,7GB (03) 14,3GB (03) 13,5 MB (28) 8,19 kB (21)
cron 0,51% (15) 0,55% (25) 8,45GB (06) 5,66GB (08) 8,48 MB (31) 0B
postgres 0,48% (16) 0,77% (13) 667 MB (15) 3,39GB (11) 62,3 MB (10) 8,85GB (3)
k2v-bridge 0,47% (17) 0,65% (19) 8,67GB (05) 5,87GB (07) 26,9 MB (18) 24,6 kB (15)
x509-identity-mgmt 0,44% (18) 8,09% (02) 3,31GB (11) 374 MB (17) 305 MB (02) 9,76 MB (22)
v2k-bridge 0,26% (19) 0,71% (16) 175 MB (18) 57,5 MB (21) 28,8 MB (16) 24,6 kB (17)
backstage 0,22% (20) 0,59% (21) 4,92GB (09) 2,7GB (13) 28,3 MB (17) 8,19 kB (20)
influxdb 0,2% (21) 6,13% (03) 7,07GB (08) 871 MB (14) 427 MB (01) 92,1GB (1)
grafana 0,18% (23) 0,46% (28) 46,4 MB (24) 14,5 MB (29) 91 MB (06) 67,8 MB (21)
kafka-ws 0,18% (22) 0,94% (12) 155 MB (19) 45,7 MB (22) 24,1 MB (21) 24,6 kB (16)
zookeeper 0,16% (24) 2,99% (07) 47,6 MB (23) 28,6 MB (24) 54,4 MB (11) 143 kB (11)
device-manager-redis 0,14% (29) 0,04% (39) 68,7 kB (38) 0B (38) 172 kB (39) 0B
data-broker-redis 0,14% (28) 0,05% (37) 1,07 MB (33) 1,01 MB (34) 885 kB (37) 77,8 kB (7)
auth-redis 0,14% (27) 0,05% (36) 56,4 MB (22) 26,1 MB (25) 565 kB (38) 582 kB (10)
flowbroker-redis 0,14% (26) 0,08% (34) 13,8 MB (27) 9,76 MB (31) 3,13 MB (35) 20,5 kB (18)
kafka-ws-redis 0,14% (25) 0,09% (33) 30,3 MB (26) 16,6 MB (28) 5,28 MB (32) 0B
influxdb-retriever 0,11% (30) 0,69% (18) 42,6 MB (25) 35,6 MB (23) 4,76 MB (34) 12,3 kB (19)
iotagent-lwm2m 0,1% (31) 1,56% (08) 1,49 MB (32) 1,62 MB (33) 26,5 MB (19) 0B
minio 0,04% (32) 0,24% (30) 87,6 kB (37) 13,1 kB (37) 50 MB (12) 0B
portainer 0,03% (34) 0,28% (29) 1,9 MB (31) 20,8 MB (26) 67,3 MB (07) 730 MB (18)
postgres-admin 0,03% (33) 1,16% (10) 40,4 kB (39) 0B (39) 65,2 MB (09) 0B
mongo-express 0,01% (35) 0,59% (22) 152 MB (20) 159 MB (19) 46,4 MB (13) 0B
gui 0% (39) 0,05% (38) 333 kB (34) 18,5 MB (27) 24 MB (22) 0B
gui-v2 0% (38) 0,08% (35) 193 kB (35) 14 MB (30) 20,4 MB (24) 0B
fb-context-manager 0% (37) 0,22% (32) 978 MB (13) 715 MB (15) 5,08 MB (33) 0B
data-manager 0% (36) 0,59% (23) 4,32 MB (28) 74,4 kB (35) 18,5 MB (25) 36,9 kB (14)
Ainda sobre os dados da Tabela 9, chama a atenção o grande volume de dados processados
pelo serviço Kafka, com relação às métricas de rede (NET IN e NET OUT), além de ser
responsável por consumir os maiores recursos de CPU e memória RAM em praticamente todo
tempo operacional.
Apesar do curto período de análise do middleware Dojot, verificou-se algumas limitações
na ferramenta, como por exemplo, a ausência de funcionalidade para configuração do tempo de
retenção de dados no MongoDB após a instalação, ausência funcionalidade para alteração de
senha de novos usuário, como também observou-se engasgos na interface de visualização de
dados v2 (serviço “gui-v2”) e na ferramenta InfluxDB ao tentar plotar gráficos em tempo real
com mais de 1000 registros.
Ante o exposto, pode-se responder à questão de pesquisa “QP03 - O middleware Dojot
pode ser utilizado com uma ferramenta de produção no atual estágio de desenvolvimento
da ferramenta?” Sim, a ferramenta demonstra ser robusta, embora tenha apresentado algumas
limitações que podem ser corrigidas em atualizações, dando indícios de que pode vir a ser
utilizada como um middleware de produção em um futuro próximo.
4.3 Comunicação LoRa®
LoRa® é uma tecnologia de comunicação sem fio que vem ganhando bastante destaque
no cenário de IoT. Utilizando técnicas de modulação de espalhamento espectral por pulsos curtos
(chirps), a tecnologia apresenta um conjunto de vantagens (baixa potência, longo alcance, alta
imunidade a ruido etc) e se torna ideal para aplicações de IoT em um campus inteligente. Nesse
sentido, a presente seção discorre sobre os resultados da comunicação entre o protótipo e o
LoRa® gateway Dragino LG02 instalado na Coordenação de Tecnologia da Informação (CTI)
do campus.
O cenário da comunicação é ilustrado na Figura 30, em que apresenta-se uma imagem do
Google Maps com a localização e a distância estimada entre os dispositivos, uma foto da casa de
máquinas onde o hidrômetro inteligente está instalado e uma foto da vista frontal do hidrômetro
inteligente para a sala da coordenação. A distância entre hidrômetro inteligente (H na figura) e o
gateway (G na figura) é de aproximadamente 85 metros.
Figura 30 – Cenário da comunicação LoRa®. Fonte: Autoria Própria.
O setup de configuração da camada física LoRa®, bem como as configurações do cliente

MQTT do gateway, são apresentados na Figura 31. Utilizou-se a frequência de 917Mhz 7 uma
vez que foi constatado que a frequência padrão de 915 mHz já estava sendo utilizada por outros
dispositivos, mitigando assim a possibilidade de colisão de pacotes. Vale ressaltar que a potência
de transmissão (TX) tanto do WiFI LoRa® 32 (hidrômetro inteligente) quanto do gateway não
foram alterados, utilizando assim a potência padrão de 14 dBm.
Figura 31 – Setup de configurações do LoRa® gateway Dragino LG02. Fonte: Autoria Própria.
Um ponto chave da comunicação entre o dispositivo final e o servidor (broker MQTT ou

middleware) é o script MQTT do LG02. Suponha que existam dois nós sensores LoRa®, em
que o ID do nó 01 (Node1) é 6734 e o ID do nó 02 (Node2) é 7456. No broker MQTT remoto há
dois tópicos: Topic1:/channel/765800 e Topic2:/channel/367860. Podemos configurar o LG02
para mapear o Node1 para o Topic1 e o Node2 para o Topic2. Portanto, quando houver dados do
sensor do Node1, o LG02 encaminhará os dados para o Topic1 e quando houver dados do sensor
do Node2, o LG02 encaminhará para o Topic2. A dinâmica desse processo é exemplificada na
Figura 328 , na qual ilustra dois nós enviando dados de temperatura e umidade para um servidor
remoto.
7 o plano de frequência LoRa® do Brasil é de 915 mHz a 928 mHz, de acordo com o ato 14448 de 2017 da
ANATEL.
8 Para mais informações consulte: Wiki Dragino. Acesso em: 25 de jan. de 2023.
Figura 32 – Script MQTT do gateway Dragino LG02. Fonte: Dragino
Nesse sentido, configurou-se o canal local (Local Channel) do LG02 como “1” e o canal
remoto (Remote Channel) como “2”, de acordo com o ilustrado na Figura 33 (A). A Figura 33
(B) exemplifica como se dá a estrutura de código para envio de pacotes LoRa® para o LG02.
Figura 33 – Configurações de canais no LG02 (A) e exemplo de código para envio de pacote
LoRa® (B). Fonte: Autoria Própria.
As demais configurações permaneceram inalteradas, uma vez que a distância entre os

dispositivos é considerada baixa, e a comunicação se deu de forma satisfatória. Assim, não se

detectou a necessidade de fazer testes alterando outras configurações da camada física, como a
taxa de bits, o tamanho da palavra de sincronismo, entre outros.
Durante a coleta de dados, a comunicação entre o dispositivo final e o LG02 apresentou
uma flutuação na potência do sinal (RSSI) de -80 dBm a -100 dBm, com uma potência média
do sinal de aproximadamente -89,14 dBm. Insta salientar que a sensibilidade do transceptor do
Dragino LG02 é < -148 dBm, de acordo com o manual do fabricante 9 .
A Figura 34 traz um recorte de 1000 registros em que é possível visualizar um fenômeno
fora do padrão detectado, bem como a média do parâmetro RSSI. Percebe-se que no período entre
09:16:44 e 21:00:03 da figura, que há uma pertubação atípica do sinal, período este marcado
por chuvas no local, o que dá indícios de que a água da chuva interfere negativamente na
comunicação, como já reportado na literatura.
Figura 34 – Característica da potência do sinal recebida no gateway Dragino LG02. Fonte:

Autoria Própria.
A relação sinal/ruido (SNR) não pôde ser observada com o equipamento Dragino LG02
utilizando apenas a camada física LoRa®, uma vez que esse parâmetro só é acessível quando
se utiliza o protocolo LoRaWAN®. Quanto à taxa de perda de pacotes, durante o período de
análise, do pacote 1 ao 30729 (último pacote durante a extração dos dados), foram perdidos 110
pacotes apenas, o que representa um taxa de perda de pacote de 0,35 %, ou seja, a comunicação
obteve um índice de desempenho de 99,65 %.
Mediante os dados apresentados, pode-se responder a questão de pesquisa: “ QP04 - A
tecnologia LoRa® será capaz de apresentar um desempenho de comunicação com baixa
taxa de perdas de pacotes para o cenário da aplicação?” Sim, a questão foi elucidada, logo,
entende-se que o uso da tecnologia LoRa® mostra-se madura o suficiente para ser utilizada em
aplicações de um campus inteligente, podendo facilmente ser implementada e otimizada para
diversos cenários.
9 Disponível em: LG02/OLG02 LoRa Gateway User Manual. Acesso em: 25 de jan. de 2023.
4.4 Caracterização do Perfil de Consumo
Esta seção apresenta os resultados da caracterização do perfil de consumo de água do

campus Campina Grande do IFPB, ou seja, apresenta as vazões de operação e os volumes
contabilizados em cada faixa de vazão (Tabela 10), além da pressão obtida no cavalete de entrada
de água do campus.
Tabela 10 – Faixas de vazão de ensaio.

Vazões para Vazões para
Faixa de Faixa de Perfil de
verificação verificação
vazão (l/h) vazão (l/min) consumo %
de erros (l/h) de erros (l/min)
0a5 2,5 0 a 0,083 0,042 4,56
5 a 15 10 0,083 a 0,25 0,167 6,99
15 a 30 22,5 0,25 a 0,5 0,375 6,83
30 a 50 40 0,5 a 0,83 0,667 7,34
50 a 150 100 0,83 a 2,5 1,667 23,21
150 a 350 250 2,5 a 5,83 4,167 23,92
350 a 550 450 5,83 a 9,16 7,500 12,27
550 a 850 700 9,16 a 14,16 11,667 7,29
850 a 1150 1000 14,16 a 19,16 16,667 5,86
1150 a 1500 1325 19,16 a 25 22,083 1,73
Fonte: Adaptado de ABNT NBR 15538:2014
Não menos importante, a Tabela 11 carrega os dados com a série histórica de consumo
de água do campus extraídos da plataforma da concessionária de água CAGEPA do ano de 2022.
Esse parâmetro serve como um parâmetro auxiliar para verificar se o medidor de vazão está
operando dentro dos padrões de consumo previstos historicamente. De acordo com os dados
da CAGEPA informados na Tabela 11, o consumo médio faturado em Janeiro de 2022 (mês
de férias, com pouca demanda) foi de 233 m3 , com um consumo diário de aproximadamente
7,76 m3 , sendo a média histórica para o mês de 154 m3 .
Tabela 11 – Consumo médio de água do campus no ano de 2022 em metros cúbicos.

Código Data da Cons. Cons. Cons. Dias de
Leitura
Mês/Ano leitura Medido Faturado Médio Consumo
dez/22 09/12/2022 1624 530 530 30
nov/22 09/11/2022 1094 628 611 470 32
out/22 08/10/2022 466 465 664 393 29
set/22 09/09/2022 26525 641 641 316 31
ago/22 09/08/2022 25884 416 416 279 32
jul/22 08/07/2022 25468 279 279 271 30
jun/22 08/06/2022 5392 200 200 30
mai/22 09/05/2022 24615 434 246 189 31
abr/22 08/04/2022 24181 205 205 182 29
mar/22 10/03/2022 23976 177 177 181 30
fev/22 08/02/2022 23799 193 193 178 29
jan/22 10/01/2022 23606 233 233 154 32
Fonte: CAGEPA
Ainda sobre os dados da CAGEPA, observa-se na Tabela 11 que após a troca do hidrô-
metro realizada no mês de Agosto pelo modelo ultrassônico da Viewshine/SAGA, houve um
aumento do consumo médio registrado, ou seja, o hidrômetro anterior (SENSUS IM-T20) estava
apresentando um elevado erro de leitura em virtude do desgaste temporal (instalado há mais de 8

anos), o que já é esperado para esse tipo de hidrômetro mecânico.
A metodologia para realização desse ensaio baseou-se no Anexo C da ABNT NBR
15538:2014, que visa padronizar o método de coleta de dados de vazões de operação e expressão
dos resultados, facilitando a identificação dos volumes escoados no período em função da vazão
que operou, através de gráficos do tipo barra (histograma). Dessa forma, pode-se identificar
as vazões e as pressões mais significativas operacionalmente e verificar se o hidrômetro ou
dispositivo medidor está corretamente dimensionado para operar no local a ser monitorado, como
também o manômetro analógico.
Para uma melhor compreensão metodológica, elencamos a seguir os principais pontos
do Anexo C da ABNT NBR 15538:2014:
• Quanto a aparelhagem (medidor):
1. medidores de tipo volumétrico, classe C ou melhor, de vazão máxima de 3 m3 /h,

dotados de saída de pulsos com resolução de 0,1 l/pulso ou melhor;
2. data logger adequado ao registro de pulsos de consumo e registro de sinal de pressão
(no caso do levantamento de dados de pressão) e com capacidade de memória
suficiente para registro ininterrupto de uma semana completa;
3. alternativamente, a entrada para registro dos consumos no data logger pode ser por
intervalo de tempo, desde que se possa fixar intervalos de 15 s.
• Quanto a metodologia de registro: O medidor pode ser instalado no lugar do hidrômetro

utilizado para medição do consumo, ou em série, fazendo uso de um cavalete especial,
visando à coleta dos dados com o data logger sem interferir no consumo e no faturamento
do usuário, por um período mínimo de uma semana inteira sem interrupções.
Antes de realizar o procedimento descrito na norma, realizou-se um levantamento pre-

liminar do perfil de consumo, utilizando-se apenas o sensor de vazão FG400A (capacidade
máxima de 3,6 m3 /h e 4,8 l/pulso), enviando dados a cada 1 segundo para a plataforma Dojot,
com um protótipo inicial, para efeito comparativo com o versão final do SMMIA. Neste teste,
o protótipo foi alimentado por uma bateria estacionária de no-break de 12 V e 9 a/h, a qual
suportou alimentar o circuito (carga) por pouco mais de 108 h (quatro dias). O protótipo é exibido
na Figura 35.
Figura 35 – Protótipo inicial. Fonte: Autoria própria.
Após esse período de coleta de dados da vazão (l/min), obteve-se o histograma ilustrado
no gráfico da Figura 36.
Figura 36 – Caracterização do perfil de consumo do campus com protótipo inicial. Fonte: Autoria
própria.
Observa-se na Figura 36 que os perfis de 50-150 l/h (0,83-2,5 l/min) e 150-350 l/h
(2,5-5,83 l/min) representaram a maior frequência de vazão de operação do sistema. É importante
ressaltar que a terceira maior frequência de operação registrada (1500-3000 l/h) está fora do
escopo da norma (1150-1500 l/h), embora a faixa de vazão represente o maior consumo de água
do campus, com um volume totalizado de aproximadamente 15,76 m3 .
Ainda neste ensaio, foi possível verificar que a menor vazão instantânea registrada pelo
sensor foi de 0,26 l/min e a maior vazão registrada foi de 45 l/min, o que demonstra que o sensor
FS400A está em conformidade com as faixas de vazão apresentadas pelo sistema, uma vez que a
vazão máxima suportada pelo sensor é de 60 l/min.
No segundo ensaio – seguindo os 15 segundos de intervalo para envio de dados de vazão
e pressão com a versão final do protótipo – os resultados obtidos geraram o histograma exibido
na Figura 37.
Figura 37 – Caracterização do perfil de consumo do campus com protótipo final. Fonte: Autoria
própria.
Percebe-se no histograma do protótipo final que houve uma tendência de uniformização

da faixa de vazão para faixa de 25-50 l/min (1500-3000 l/h), com um volume total estimado de
aproximadamente 37 m3 . Ainda neste período, observou-se uma interferência na faixa de vazão
operacional quando a válvula solenoide encontra-se energizada em comparação com a mesma
desenergizada. Quando não alimentada (fora da rede elétrica), a faixa de vazão observada ficou
entre 22 e 25 l/min (1320 a 1500 l/h), com um volume total contabilizado no período de um dia
(período de observação para ajustes no algoritmo e calibração do sensor de pressão) de 26,68 m3 ,
apresentando uma diferença de 0,61 m3 ou 2,5 % a mais na solução SMMIA, como pode ser
observado na Figura 38.
Figura 38 – Comparação do volume total contabilizado entro o SMMIA e o hidrometro SAGA

da CAGEPA com o solenoide desenergizado. Fonte: Autoria própria.
Com o solenoide energizado, a faixa de vazão operacional mudou para faixa de 30 a

35 l/min (1800 a 2100 l/h), com uma vazão média de aproximadamente 31 l/min (1860 l/h),
sendo a maior vazão contabilizada no período observado de 34,58 l/min (2074,8 l/h) e a menor
de 0,1 l/min (6 l/h), o que pode ser considerado ruído, pois mesmo com o solenoide fechado
(energizado) durante o período das 23:00 h as 06:00 h, constatou-se diversos registros de
0,1 l/min.
A Tabela 12 sistematiza os dados do monitoramento do consumo total durante o período
de observação, comparando a solução SMMIA com o hidrômetro SAGA da CAGEPA.
Tabela 12 – Acompanhamento das soluções (SAGA e SMMIA) na totalização do volume total

contabilizado (m3).
Dia SAGA (m3 ) SMMIA (m3 ) SAGA - SMMIA (m3 ) Erro (%)
02/01/2023 0 0 0 0
04/01/2023 24,85 23,05 1,80 7,24
05/01/2023 34,50 32,16 2,34 6,77
06/01/2023 45,20 42,99 2,21 4,90
07/01/2023 53,28 49,67 3,61 6,77
09/01/2023 57,50 52,44 5,06 8,79
10/01/2023 73,82 68,16 5,66 7,67
Média 3,45 7,02
Observa-se que durante esse período constatou-se uma diferença média na contabilização
do volume total escoado de aproximadamente 7,00 % a menos na solução SMMIA, o que pode
ser explicado por algum dos fatores reportados a seguir:
1. o sensor não foi calibrado para essa faixa de vazão (abordado na seção seguinte);
2. o hidrômetro SAGA apresenta uma maior sensibilidade e precisão, já que utiliza a tec-
nologia de sensor ultrassônico com inicio de funcionamento em 0,03 l/min (2 l/h) contra
1 l/min (60 l/h) do sensor FS400A;
3. o fluxo de água entrante no sensor de vazão não possui um fluxo laminar, gerando uma
leitura equivocada do sensor, e/ou;
4. outros fatores ainda não conhecidos.
Com isso, a seguinte questão de pesquisa: “QP01 - O medidor inteligente de água

desenvolvido será capaz de medir com a precisão e requisitos estabelecidos em normas
vigente?” pode ser parcialmente respondida, já que a solução SMMIA apresentou um erro de
indicação médio (-7,00%) acima do valor esperado (entre ±3 % e ±5 %, taxa de erro máximo,
segundo o fabricante), logo, para elucidar essa quentão em sua plenitude é necessário um período
maior de testes e ajustes da solução.
Embora tenha-se observado uma mudança de padrão no perfil de consumo, com uma
redução de aproximadamente 22 % da vazão máxima (de 45 l/min para 35 l/min) entre o protótipo
inicial e o final, provocado aparentemente pelo solenoide, esse comportamento em nada afeta o
abastecimento de água do campus, porém, pode ser um fator de impacto na redução do consumo,
além de proporcionar uma maior regularidade na leitura dos sensores, aumentando sua vida útil,
como também pode facilitar futuramente uma calibração mais precisa in loco, uma vez que a
faixa de vazão é praticamente restrita a um único intervalo.
Observou-se também que o volume contabilizado está em conformidade com a série
histórica apresentada pela CAGEPA, com um leve aumento se comparado ao mesmo período do
ano anterior (7,2 m3 ), apresentando um consumo médio diário de aproximadamente 8,15 m3 até
a data final do período de monitoramento.
Quanto à caracterização da pressão no cavalete de entrada de água do campus, a Figura 39
exibe o histograma com o comportamento apresentado durante o período de observação. Vale
salientar que a maior pressão registrada foi de 4,73 bar (48,23 mca), com uma média aproximada
de 3,90 bar (39,77 mca), o que demonstra que o manômetro analógico utilizado deve ser
substituído por um manômetro com fundo de escala > 5 bar.
Figura 39 – Caracterização da pressão no cavalete de entrada de água do campus. Fonte: Autoria

própria.
Embora o histograma apresente uma frequência muito alta de pressões entre 0,5 bar e
2 bar, na prática observou-se que trata-se de pressões “residuais” na tubulação após o fechamento
da válvula de passagem de água manual do cavalete de entrada de água, como pode-se perceber
no gráfico exibido na Figura 40, em que a vazão instantânea encontra-se em zero, e a pressão na
tubulação variando entre 1,4 bar e 1,5 bar aproximadamente, logo foram descartadas do cálculo
da pressão média.
Figura 40 – Caracterização da pressão no cavalete de entrada de água do campus. Fonte: Autoria

própria.
Cabe destacar que a pressão observada durante o ensaio está dentro dos limites estabele-
cidos pela NBR 12218, que estabelece que as redes de abastecimento de água tenham pressão
mínima de 10 mca (0,98 bar) e máxima de 50 mca (4,90 bar). Com isso, responde-se à questão
de pesquisa “QP02 - A pressão da água na entrada do sistema de distribuição de água do
campus está em conformidade com as normas vigentes?” Sim.
4.5 Calibração do Sensor de Vazão
A calibração de sensores de vazão pode ser realizada por meio de comparações volumétri-
cas ou mássicas, através do método estático ou dinâmico. Neste sentido, o presente tópico aborda
em detalhes a metodologia adotada para calibração do sensor de vazão FS400A G1 utilizado
neste projeto. O procedimento utilizado baseou-se em um dos três modelos (1C) de bancada de
ensaio de calibração por pesagem com método estático, descrito na ABNT NBR ISO 4185:2009.
O princípio gravimétrico por pesagem estática consiste em pesar o volume do líquido
represado em um recipiente (de peso conhecido) em um tanque de pesagem, uma vez que se
conhece o tempo, a densidade específica do líquido e a temperatura de operação. Nesse contexto,
a Figura 41 ilustra o diagrama da bancada de calibração de sensores de vazão para o método
estático descrito na norma, no qual utiliza o método por bombeamento direto.
Figura 41 – Diagrama de uma instalação para calibração por pesagem (método estático (1C),
alimentação por bombeamento direto). Fonte: ABNT NBR ISO 4185:2009.
Nesse ensaio (1C), a bomba direciona o líquido do reservatório sob pressão constante
para o estabilizador de vazão, que mantém o fluxo do líquido constante para o sensor sob
calibração, ajustando a vazão de saída através da válvula reguladora de vazão, que direciona o
fluxo para o diversor, período no qual é registrada a massa inicial (m0 ). Com o fluxo do líquido
estabilizado, o diversor é acionado e direciona a vazão do líquido para o tanque de pesagem,
acionando o cronômetro e contabilizado o volume escoado por um tempo t. A pesagem (a massa
final aparente m1 ) se dá quando o líquido se estabiliza no tanque, momento no qual o valor deve
ser registrado e o líquido drenado novamente para o reservatório.
A vazão mássica média (qm ) desse ensaio é dada pela equação 16.
m m1 m0
qm = = 1, 00106 , (16)
t t
e a vazão volumétrica dada pela equação 17:

qm m1 m0
qv = = 1, 00106 . (17)
r r ⇥t
O valor de 1, 00106 nas equações acima se deve à aplicação de um fator de correção (e),
em virtude da diferença entre o empuxo exercido pela atmosfera em uma determinada massa de
líquido e em uma mesma massa padrão construída em metal, utilizada na calibração da balança,
quando o líquido sob ensaio é a água, levando-se em consideração a massa específica da água (r)
de 1000 kg/m3 , a massa específica do ar (ra ) de 1,21 kg/m3 e a massa específica do material dos
pesos-padrão (r p ) de 8000 kg/m3 (ABNT NBR ISO 4185:2009). Vale ressaltar que uma exatidão
de 0,5°C é suficiente para assegurar um erro menor que 10 4 na avaliação da massa específica,
uma vez que as propriedades físicas da água são bem estáveis nas condições atmosféricas (ABNT
NBR ISO 4185:2009).
Para calibração do sensor de vazão FS400A utilizou-se a biblioteca FlowMeter 10 versão
1.2.0. É importante ressaltar que o algoritmo dessa biblioteca não leva em consideração a
viscosidade, a massa específica (considerado a massa específica da água como 1~ g/cm3 ) e a
temperatura do líquido sob medição, ou seja, para todos os efeitos é considerado 1 kg/min =
1 l/min.
As propriedades ou características dos sensores de vazão utilizadas pelo FlowMeter são
compostos por uma estrutura de dados contendo os seguintes atributos:
1. Fator K (KF): Fatores K são valores de calibração (pulsos por unidade de volume) usados
para converter frequências de saída do sensor de vazão em taxas de vazão, ou seja, converte
a frequência de rotação da aleta em litros por minuto (l/min), obedecendo a seguinte
relação:
f
Q= , (18)
KF
em que Q é a vazão contabilizada, f é a frequência de rotação da aleta e KF é o fator K.
2. Fator M (MF): é o conjunto de fatores de correção do fator K, uma vez que na prática os
sensores não são lineares. Por padrão, a FlowMeter trabalha com 10 índices, dividindo a
capacidade do sensor (cap) em percentis, com a seguinte relação matemática para cada
ponto de calibração:
f
Q corrigido = ( ) ⇥ MF. (19)
KF
3. Capacidade do sensor (cap): define o valor máximo de vazão que o sensor suporta. A
estrutura de dados antes da calibração para a taxa de erro padrão ( de ±3% a ±5% 11 ) do
sensor FS400A é apresentada a seguir:
• FlowSensorProperties FS400A = {60.0f, 4.8f, {1, 1, 1, 1, 1, 1, 1, 1, 1, 1}};
Em virtude da impossibilidade de utilizar uma bancada certificada como a apresentada

em norma, realizou-se uma adaptação do modelo 1C, utilizando-se materiais de fácil acesso
10 Para mais detalhes consulte: FlowMeter Library. Acesso em: 25 de jan. de 2023.
11 Disponível em: AliExpress. Acesso em: 25 de jan. de 2023.
no mercado local e de custo relativamente viável, viabilizando a execução dos ensaios para
calibração do sensor de vazão, índice da incerteza da medição e do índice de desempenho do
medidor, apresentados em tópicos subsequentes.
A Figura 42 apresenta um esboço do diagrama esquemático (eletroeletrônico e hidráulico)
da bancada adaptada utilizada para realização dos ensaios. Para uma melhor visualização do
cenário, a Figura 43 ilustra a bancada em cenário real.
A bancada é composta por um reservatório de 100 l, uma válvula tipo borboleta de
abertura manual (1) de corpo em policloreto de vinila (PVC), um pressurizador de água (2), uma
válvula reguladora de pressão (3) – que acomoda o sensor de pressão eletrônico e o manômetro
analógico –, um sensor de vazão (4), uma válvula tipo borboleta de abertura manual (5) de corpo
em metal, uma válvula do tipo solenoide (6) normalmente aberta (NA) operando em 220V, e
uma válvula de retenção de água. Toda a tubulação utilizada é de PVC 32 mm/25 DN, análoga à
tubulação utilizada no cavalete de entrada de água do campus.
Figura 42 – Diagrama da bancada adaptada para calibração do sensor de vazão FS400A

G1"(método estático, alimentado por pressurização direta). Fonte: Autoria Pró-
pria.
Figura 43 – Bancada adaptada ao método estático 1C da ABNT NBR ISO 4185:2009. Fonte:
Autoria Própria.
O fluxograma com o processo de medição para calibração do sensor de vazão e outros

indicadores é ilustrado na Figura 44.
Figura 44 – Fluxograma do processo de medição. Fonte: Autoria Própria.
Inicialmente, liga-se os equipamentos (pressurizador, sensores, atuador e microcontrola-

dor) e aguarda-se um período de dois minutos para estabilização do sistema. Após esse período,
realiza-se a expurga do ar da tubulação, com todas as válvulas abertas e o parafuso central do
pressurizador removido, para que o ar seja completamente drenado do sistema. Em seguida,
verifica-se a estabilidade da pressão do sistema através do manômetro analógico acoplado à
válvula reguladora de pressão e pelo gráfico da pressão visualizado no Dojot, bem como é
verificado se o conjunto eletrônico (sensores, atuadores e microcontrolador) está funcionando a
contento, assim como a comunicação com o Dojot.
As Figuras a seguir (de 45 a 47) demonstram o comportamento da curva característica da

pressão estática do sistema para cada um dos níveis de ajuste do pressurizador. A curva na cor
azul ilustra a pressão (em bar), a curva na cor laranja apresenta a média aritmética da amostra e
as barras na vertical representam o desvio padrão da amostra. Os dados foram coletados a cada
dois segundos, em um total de 50 amostras.
Figura 45 – Comportamento da pressão estática na bancada adaptada com pressurizador configu-

rado em 1,0 bar. Fonte: Autoria Própria.

rado em 1,5 bar. Fonte: Autoria Própria.

rado em 2 bar. Fonte: Autoria Própria.
Percebe-se que o nível 1 (1 bar) de ajuste do pressurizador apresenta maior regularidade

na variação de pressão, com apenas 0,04 bar de diferença entre a menor (0,62 bar) e a maior
pressão registrada (0,66 bar) pelo sensor de pressão eletrônico, com uma variação percentual
de ⇡6,00 %, desvio padrão amostral de ⇡0,012 bar e a média de ⇡0,64 bar. Já o nível máximo
(2 bar) de ajuste do pressurizador apresenta maior irregularidade na variação de pressão, com
0,13 bar de diferença entre a menor (1,52 bar) e a maior pressão registrada (1,65 bar) pelo sensor
de pressão eletrônico, com uma variação percentual de ⇡7,88 %, desvio padrão amostral de
⇡0,031 bar e a média de ⇡1,59 bar.
Outro ponto a ser observado entre os gráficos das curvas de pressão é o tempo que o
sistema leva para obter uma certa tendência de estabilização (amostra 20 ou 40 segundos) da
pressão, embora não seja possível manter a pressão estável em um valor fixo 100 % do tempo
com os equipamentos e acessórios utilizados na bancada. A Figura 48 ilustra o comparativo
do comportamento das curvas de pressão estática do sistema, para os três níveis de ajuste do
pressurizador, facilitando a percepção de variação de pressão entre elas.
Figura 48 – Comportamento da pressão estática na bancada adaptada. Fonte: Autoria Própria.
Ademais, constatou-se que em nenhum momento o pressurizador atingiu seus valores

nominais de pressão, o que pode ser compreendido pela ausência miníma de pressão de entrada
(0,19 bar, conforme manual do fabricante) no pressurizador, um vez que, o reservatório principal
(100 l) exerce apenas uma pressão de 0,055 bar na entrada do equipamento. A Figura 49 ilustra
a pressão no manômetro analógico, para cada um dos níveis, o que demonstra que o sensor de
pressão eletrônico está em conformidade com os dados apresentados.
Figura 49 – Imagens de medição da pressão estática no manômetro analógico. Fonte: Autoria

Própria.
Com todo o sistema estabilizado e operante, regula-se a válvula tipo borboleta de abertura
manual (Item 5 na Figura 43) e aciona-se o botão capacitivo do microcontrolador, para abertura
da válvula solenoide e ajuste da vazão para o valor tipico desejado, de acordo com a norma. Uma
vez ajustada, aciona-se novamente o botão e inicia-se o processo de medição por um minuto, no
qual a água é escoada para um reservatório graduado e os dados dos sensores enviados para o
Dojot a cada dois segundos. Após esse período, a válvula solenoide é fechada, o cronômetro
zerado e a leitura dos sensores suspensa. A posteriori, aguarda-se o escoamento cessar, para então
levar o reservatório graduado para ser pesado, colocando-o no centro da balança e aguardando o
sistema estabilizar. Uma vez que o display da balança esteja estabilizado, o valor é registrado
manualmente em uma tabela e a água do reservatório graduado é devolvida para o reservatório
principal.
É importante ressaltar as limitações da bancada de ensaio, uma vez que não foi possível
realizar a contento os ensaios para as faixas de vazão de 2,5 l/h a 100 l/h, em virtude do mau
funcionamento da válvula solenoide em baixas vazões, pois ela não consegue cessar o fluxo de
água de forma instantânea, como também não foi possível ajustar exatamente o fluxo de água
(vazão) para as vazões sob ensaio devido ao tipo de válvula utilizada para este fim. No entanto, os
resultados obtidos foram bem próximos dos valores estabelecidos em norma, o que não invalida
os resultados da avaliação.
Outra limitação do ensaio foi a impossibilidade de avaliar o erro de indicação, como
também efetuar a calibração do sensor para as faixas de vazões típicas (Q3) constatadas no
ensaio de caracterização do perfil de consumo do campus – reportado na Seção 4.4 – em virtude
da incapacidade do pressurizador utilizado gerar vazões superiores a 31 l/min, como também
não foi possível verificar o Q112 e o Q413 pelos motivos já mencionados.
Vale salientar ainda que para o processo de verificação do erro de indicação da balança,
foram utilizados dois pesos padrão classe F2 de 100 g e 200 g (ver Figura 50), em que foi
constatado um erro sistemático de -5 g para essas faixas de medições. Embora não seja possível
afirmar que o erro se estenda por toda a faixa de medição da balança (40 kg), adotou-se um fator
de correção de +5 g para todas as medições, visando compensar o erro sistemático observado.
Figura 50 – Erro de indicação da balança. Fonte: Autoria Própria.
Assim, no processo de pesagem o registro final da massa da água foi descontado o peso
do reservatório graduado (⇡695 g + 5 g do erro sistemático da balança) e o peso do volume
de água (massa) represado entre o sensor de vazão e a válvula de retenção de água (⇡700 g),
ou seja, o peso de tara (⇡1400 g). Para facilitar o procedimento visual da pesagem, o volume
12 menor faixa de vazão que o sensor opera dentro dos limites de erro de indicação estabelecido em norma.
13 maior faixa de vazão que o sensor opera dentro dos limites de erro de indicação estabelecido em norma.
represado foi adicionado ao reservatório graduado e pesado, configurado diretamente o valor de

tara na balança, no qual subtrai o valor automaticamente.
Desse modo, foram realizadas 15 medições para cada ponto de calibração (de 250 l/h
ou 4,167 l/min a 1350 l/h ou 22,083 l/min) seguindo o procedimento descrito anteriormente. A
Figura 51 apresenta os resultados da curva de erro de indicação obtidos no processo de calibração
do sensor FS400A.
Figura 51 – Gráfico do erro de indicação obtido no processo de calibração. Fonte: Autoria

Própria.
Observa-se na Figura 51 que nas faixas de vazão abaixo de 11,667 l/min, o sensor FS400A
apresenta um comportamento altamente não linear, passando a obter uma maior regularidade
em vazões superiores, caraterística já reportada na documentação da biblioteca de calibração
FlowMeter 14 .
Embora o sensor apresente essa característica de não linearidade em baixas vazões, todas
as medições se mantiveram dentro da margem de erro permitida em norma, ou seja, em nenhuma
das medições o erro de indicação foi superior a 2 %, sendo um ótimo resultado para um sensor de
baixo custo. Outras variáveis estáticas como média da amostra e o desvio padrão são aparentadas
na seção seguinte deste documento.
Vale destacar que durante o processo de calibração do sensor de fluxo FS400A diversos
parâmetros complementares foram coletados de acordo como a norma, como a temperatura
ambiente (th), temperatura da água (ta), umidade do ambiente (um) volume total escoado (vt), o
volume instantâneo em litros por minuto (vi), o cálculo da média e do desvio-padrão de cada
parâmetro, como o exemplo da Tabela 13 com os dados obtidos durante a calibração para faixa
de vazão de 4,167 l/min. O Apêndice B traz as informações da média e do desvio-padrão das 15
medições para cada faixa de vazão ensaiada .
14 Para mais detalhes consulte: FlowMeter Library. Acesso em: 25 de jan. de 2023.
Tabela 13 – Exemplo dos demais parâmetros coletados durante a calibração do sensor de vazão.
Timestamp bar ta th tx um vi vt
28/10/2022 13:13 1,06 28,31 31,38 1 51,39 0,041 0,077
28/10/2022 13:13 1,04 28,31 31,35 2 51,52 4,132 0,138
28/10/2022 13:13 1,05 28,31 31,37 3 51,59 4,134 0,276
28/10/2022 13:13 1,04 28,31 31,38 4 51,59 4,237 0,417
28/10/2022 13:13 1,05 28,31 31,38 5 51,59 4,237 0,559
28/10/2022 13:13 1,04 28,31 31,4 6 51,69 4,132 0,697
28/10/2022 13:13 1,04 28,25 31,42 7 51,69 4,233 0,838
28/10/2022 13:13 1,05 28,25 31,46 8 51,69 4,229 0,98
28/10/2022 13:13 1,05 28,31 31,49 9 51,69 4,235 1.121
28/10/2022 13:13 1,03 28,31 31,5 10 51,69 4,229 1.262
28/10/2022 13:13 1,05 28,31 31,49 12 51,59 4,229 1.545
28/10/2022 13:13 1,06 28,25 31,5 13 51,59 4,139 1.683
28/10/2022 13:13 1,05 28,31 31,5 14 51,59 4,242 1.825
28/10/2022 13:13 1,05 28,25 31,52 15 51,59 4,242 1.966
28/10/2022 13:13 1,05 28,25 31,54 16 51,59 4,233 2.107
28/10/2022 13:13 1,06 28,25 31,53 17 51,49 4,233 2.249
28/10/2022 13:14 1,05 28,31 31,54 18 51,49 4,132 2.387
28/10/2022 13:14 1,05 28,31 31,54 19 51,49 4,231 2.528
28/10/2022 13:14 1,07 28,31 31,56 20 51,49 4,242 2.669
28/10/2022 13:14 1,05 28,25 31,49 21 51,49 4,229 2.811
28/10/2022 13:14 1,06 28,25 31,49 22 51,49 4,139 2.949
28/10/2022 13:14 1,06 28,31 31,49 23 51,59 4,235 3,09
28/10/2022 13:14 1,06 28,31 31,47 24 51,59 4,242 3.232
28/10/2022 13:14 1,05 28,38 31,47 25 51,69 4,134 3,37
28/10/2022 13:14 1,06 28,31 31,47 26 51,69 4,237 3.511
28/10/2022 13:14 1,06 28,31 31,49 27 51,69 4,229 3.652
28/10/2022 13:14 1,06 28,25 31,5 28 51,69 4,136 3,79
28/10/2022 13:14 1,04 28,31 31,54 29 51,69 4,235 3.932
28/10/2022 13:14 1,05 28,31 31,59 30 51,59 4,235 4.073
Média 1,051 28,294 31,478 - 51,594 4,063 -
Desvio Padrão 0,009 0,033 0,062 - 0,085 0,775 -
Quanto aos fatores de correção de calibração (Fator M) da biblioteca FlowMeter, os

resultados são expostos na Tabela 14.
Tabela 14 – Fatores de correção (M) da calibração utilizados.

Índice 1 2 3 4 5 6 7 8 9 10
Vazão
0-6 6-12 12-18 18-24 24-30 30-36 36-42 42-48 48-54 54-60
(l/min)
Fator M 0.9695 1.0255 1.0350 1.0250 1 1 1 1 1 1
Observa-se que o Índice 2 atua sobre duas faixas de vazão sob ensaio (7,500 l/min e
11,667 l/min), logo, optou-se por tentar calibrar com menor erro de indicação a faixa de vazão
de 7,5 l/min, uma vez que o sensor tem maior dificuldade em aferir faixas menores de vazão.
Com os resultados apresentados até aqui, pode-se responder a questão de pesquisa “
QP05 - É possível calibrar um sensor de vazão com resultados satisfatórios, dentro da
margem de erro de indicação estabelecido em norma, com uma bancada de calibração
não certificada?” Embora não tenha sido possível realizar o ensaio de calibração para todas as
faixas de vazão com a bancada de calibração desenvolvida, infere-se que é possível a calibração
de um sensor de vazão com uma bancada de calibração não certificada, desde que a bancada de
calibração não certificada consiga prover mecanismos de ajuste de pressão e vazão com um fluxo
de água relativamente estável.
4.6 Índice de Desempenho da Medição - IDM, e Incerteza da Mediação
O IDM é o método de estimação da submedição em hidrômetros apresentado na ABNT

NBR 15.538 – Medidores de água potável – ensaios para avaliação de eficiência, no qual realiza-
se o levantamento da curva de erros para vazões médias correspondentes às faixas do perfil de
consumo apresentado na Tabela 10. Já a incerteza da Mediação é um parâmetro que indica a
qualidade de uma medida de uma forma quantitativa, ou seja, “a incerteza caracteriza a faixa de
valores dentro da qual se espera que a vazão ou a grandeza medida se situe, com um nível de
confiança especificada” (ABNT ISO 5168:2015).
Neste sentido, apresenta-se a seguir os resultados obtidos do IDM e da incerteza da
medição para os respectivos ensaios de curva de erro das vazões estabelecidas em norma. O
modelo matemático utilizado para o cálculo da vazão no sensor FS400A é baseado no principio
de funcionamento de sensores de efeito hall, em que a cada revolução da aleta é gerada um onda
quadrada (pulso), e a vazão é computada como a Equação 20:
f
Q = Â( ) ⇥ MF, (20)
KF
em que Q é a vazão, expressa em litros por minuto (l/min); f é a frequência de rotação da
aleta (pulsos por unidade de volume), dado em Hz; KF é o fator de conversão, ou seja, se em
1 segundo a aleta do sensor gerar 4,8 pulsos, significa que será contabilizado 1 l/min, com um
volume total contabilizado de 1 l; MF é o fator de correção do fator KF.
O erro de indicação do sensor em litros (l) é dado pela relação:
E v = Vs Vr , (21)
em que E v é o erro de indicação do sensor em litros (l); Vs é o volume contabilizado pelo sensor
em litros (l); Vr é o peso da massa volumétrica real, ou seja, o peso da massa volumétrica menos
o peso de tara PT do sistema, que inclui o peso do reservatório graduado Pr somado ao peso da
massa volumétrica represado na tubulação Pa .
O erro de indicação percentual é calculado como:
Vs Vr
Erro(%) = ⇥ 100. (22)
Vr
As Tabelas 15 a 19 exibem os dados dos resultados obtidos nos ensaios para vazões de
250 l/h a 1350 l/h, nos quais são apresentados o erro de indicação (%) da medição, a média
aritmética (X̄) da amostra, o desvio padrão da amostra (S), a variância (S2 ), a incerteza padrão
(ux ) e a incerteza expandida da medição (U x ) para 15 observações e 14 graus de liberdade (v),

fator de abrangência k = 2, 2, e nível de confiança de 95,45 %, de acordo com a Tabela C.1 da
ABNT NBR ISO 5168:2015. A avaliação da incerteza da mediação Tipo B foge do escopo deste
trabalho, sendo recomendada em trabalhos futuros para uma análise ainda mais precisa.
Para o ensaio de erro de indicação de 250 l/h (Tabela 15) os dados obtidos durante
o processo de calibração do sensor apontam para um erro de indicação médio entre o valor
computado pelo sensor (Vs ) e o valor obtido pelo método gravimétrico de ±0, 553%, com um
desvio-padrão da média do erro de indicação de 0,930 %, o que demonstra uma certa imprecisão
do sensor para essa faixa de vazão, embora o erro de indicação médio possa ser considerado
baixo.
Quanto à medição, a vazão média obtida pelo sensor foi de Vs = (4,055 ± 0, 021) l. Já
para volume total "real" obtido pelo método gravimétrico Vr = (4,032 ± 0, 015) l, ou seja, a
probabilidade do valor real do mensurando encontra-se entre [4,017 l a 4,047 l] para um um grau
de confiança de 95,45 % para essa faixa de vazão.
Tabela 15 – Resultado ensaio curva de erro para vazão de 250 l/h ou 4,167 l/min.
Medição Vs (l) Balança (kg) Vr (l) Ev (l) Erro (%)
1 4,073 5,470 4,070 0,003 0,074
2 4,046 5,430 4,030 0,016 0,397
3 4,029 5,445 4,045 -0,016 -0,396
4 4,097 5,42 4,02 0,077 1,915
5 4,040 5,420 4,020 0,020 0,498
6 4,093 5,435 4,035 0,058 1,437
7 4,080 5,465 4,065 0,015 0,369
8 4,036 5,475 4,075 -0,039 -0,957
9 4,090 5,420 4,020 0,070 1,741
10 4,050 5,380 3,980 0,070 1,759
11 4,006 5,400 4,000 0,006 0,150
12 3,999 5,415 4,015 -0,016 -0,399
13 4,120 5,455 4,055 0,065 1,603
14 4,046 5,425 4,025 0,021 0,522
15 4,013 5,430 4,030 -0,017 -0,422
X̄ 4,055 5,432 4,032 0,022 0,553
S² 0,001 0,001 0,001 0,001 0,864
S(X̄) 0,036 0,026 0,026 0,037 0,930
uX̄ 0,009 0,007 0,007 0,010 0,240
U X̄ 0,021 0,015 0,015 0,021 0,528
De forma análoga, a mesma análise pode ser aplicada às demais tabelas de ensaios de
curva de erro de indicação. Observa-se portanto que a faixa de vazão na qual o sensor apresentou
uma maior precisão durante o processo de calibração foi a faixa de 700 l/h ou 11,667 l/min,
com uma dispersão (desvio-padrão) do erro de indicação de 0,258 %, embora tenha apresentado
um erro de indicação médio de ± 1, 297 %. Já a faixa de vazão com maior imprecisão foi a de
450 l/h ou 7,5 l/min, com um desvio-padrão do erro de indicação de 1,125 %, embora tenha
apresentado um baixo erro de indicação médio de ± 0, 090 %.
Tabela 16 – Resultado ensaio curva de erro de indicação para vazão de 450 l/h ou 7,5 l/min.
Medição Vs (l/min) Balança (kg) Vr (l) Ev (l) Erro (%)
1 6,950 8,380 6,980 -0,030 -0,430
2 6,956 8,325 6,925 0,031 0,448
3 7,064 8,330 6,930 0,134 1,934
4 7,060 8,330 6,930 0,130 1,876
5 6,921 8,300 6,900 0,021 0,304
6 6,880 8,305 6,905 -0,025 -0,362
7 7,247 8,625 7,225 0,022 0,304
8 7,025 8,330 6,930 0,095 1,371
9 6,885 8,345 6,945 -0,060 -0,864
10 6,849 8,295 6,895 -0,046 -0,667
11 6,771 8,295 6,895 -0,124 -1,798
12 6,808 8,310 6,910 -0,102 -1,476
13 6,769 8,230 6,830 -0,061 -0,893
14 6,863 8,300 6,900 -0,037 -0,536
15 6,871 8,310 6,910 -0,039 -0,564
X̄ 6,928 8,334 6,934 -0,006 -0,090
S² 0,016 0,008 0,008 0,006 1,266
S(X̄) 0,128 0,087 0,087 0,078 1,125
uX̄ 0,033 0,022 0,022 0,020 0,291
U X̄ 0,073 0,049 0,049 0,044 0,639
1 11,281 12,560 11,160 0,121 1,084
2 11,210 12,455 11,055 0,155 1,402
3 11,209 12,440 11,040 0,169 1,531
4 11,253 12,520 11,120 0,133 1,196
5 11,199 12,520 11,120 0,079 0,710
6 11,260 12,510 11,110 0,150 1,350
7 11,278 12,550 11,150 0,128 1,148
8 11,260 12,490 11,090 0,170 1,533
9 11,217 12,480 11,080 0,137 1,236
10 11,142 12,435 11,035 0,107 0,970
11 11,256 12,480 11,080 0,176 1,588
12 11,260 12,470 11,070 0,190 1,716
13 11,274 12,535 11,135 0,139 1,248
14 11,206 12,450 11,050 0,156 1,412
15 11,202 12,455 11,055 0,147 1,330
X̄ 11,234 12,490 11,090 0,144 1,297
S² 0,002 0,002 0,002 0,001 0,067
S(X̄) 0,039 0,040 0,040 0,028 0,258
uX̄ 0,010 0,010 0,010 0,007 0,067
U X̄ 0,022 0,023 0,023 0,016 0,147
1 16,334 17,685 16,285 0,049 0,301
2 16,348 17,610 16,210 0,138 0,851
3 16,258 17,550 16,150 0,108 0,669
4 16,373 17,620 16,220 0,153 0,943
5 16,269 17,640 16,240 0,029 0,179
6 16,230 17,520 16,120 0,110 0,682
7 16,090 17,525 16,125 -0,035 -0,217
8 16,291 17,695 16,295 -0,004 -0,025
9 16,313 17,670 16,270 0,043 0,264
10 16,324 17,655 16,255 0,069 0,424
11 16,212 17,505 16,105 0,107 0,664
12 16,245 17,575 16,175 0,070 0,433
13 16,201 17,520 16,120 0,081 0,502
14 16,262 17,500 16,100 0,162 1,006
15 16,136 17,530 16,130 0,006 0,037
X̄ 16,259 17,587 16,187 0,072 0,448
S² 0,006 0,005 0,005 0,003 0,131
S(X̄) 0,078 0,070 0,070 0,058 0,362
uX̄ 0,020 0,018 0,018 0,015 0,094
U X̄ 0,044 0,040 0,040 0,033 0,206
Medição Vs (l/min) Balança (kg) Vr (L) Ev (L) Erro (%)
1 21,148 23,130 21,220 0,072 0,339
2 21,322 23,120 21,210 -0,112 -0,528
3 21,208 23,125 21,215 0,007 0,033
4 21,219 23,095 21,185 -0,034 -0,160
5 21,268 23,090 21,180 -0,088 -0,415
6 21,343 23,130 21,220 -0,123 -0,580
7 21,411 23,155 21,245 -0,166 -0,781
8 21,194 23,060 21,150 -0,044 -0,208
9 21,237 23,080 21,170 -0,067 -0,316
10 21,276 23,115 21,205 -0,071 -0,335
11 21,133 23,020 21,110 -0,023 -0,109
12 21,105 23,025 21,115 0,010 0,047
13 21,272 23,185 21,275 0,003 0,014
14 21,108 23,050 21,140 0,032 0,151
15 21,186 23,030 21,120 -0,066 -0,312
X̄ 21,229 23,094 21,184 -0,045 -0,211
S² 0,008 0,002 0,002 0,004 0,090
S(X̄) 0,089 0,050 0,050 0,064 0,301
uX̄ 0,023 0,013 0,013 0,016 0,078
U X̄ 0,050 0,028 0,028 0,036 0,171
A Figura 52 traz um quadro resumo com os principais indicadores das medições (média,
desvio padrão, incerteza expandida da medição e erro de indicação), para uma melhor visuali-
zação dos resultados, com destaque em negrito para os "piores" valores obtidos nos ensaios de
calibração do sensor FS400A.
Figura 52 – Resumo das medições. Fonte: Autoria Própria.
Destaca-se que aplicou-se o teste de Grubbs 15 para o nível de confiança de 95 % e 15

observações sobre o erro de indicação, no qual não foi identificado nenhum valor aberrante
(>2,51).
É possível verificar na Tabela 20 os dados referente ao IDM para as três primeiras
medições (para tabela completa dos cálculos consulte o Apêndice A). O IDM calculado após
a média aritmética do ensaio das 15 medições atingiu um índice de 97,83 % de eficiência,
ou seja, apenas -2,17 % (EP) do volume escoado pelo sensor FS400A não será contabilizado
(submedição), demonstrando que a principio esse tipo de sensor pode ser utilizado se devidamente
calibrado e bem acomodado, embora seja necessária uma avaliação minuciosa do IDM ao longo
de 10 anos, com uma amostra maior de sensores, conforme preconiza a norma, para averiguar
por quanto tempo o sensor funciona dentro dos limites.
15 O teste de Grubbs compara a distância entre o valor aberrante e a média com o desvio-padrão do conjunto total
de dados, de acordo com a equação: Zn = |XmS X̄| . Fonte: ABNT NBR ISO 5168:2015.
Tabela 20 – Exemplo do cálculo do IDM para as três primeiras medições.

Verificação
Ordem Vazão (l/min) Erro Médio (%) Peso (%) EP (%) IDM (%)
de erros (l/min)
0 a 0,083 0,042 -5,00 4,56
0,083 a 0,25 0,167 -5,00 6,99
0,25 a 0,5 0,375 -5,00 6,83
0,5 a 0,83 0,667 -5,00 7,34
0,83 a 2,5 1,667 -5,00 23,21
1 -2,38 97,62
2,5 a 5,83 4,167 0,07 23,92
5,83 a 9,16 7,500 -0,43 12,27
9,16 a 14,16 11,667 1,08 7,29
14,16 a 19,16 16,667 0,30 5,86
19,16 a 25 22,083 0,34 1,73
0 a 0,083 0,042 -5,00 4,56
0,083 a 0,25 0,167 -5,00 6,99
0,25 a 0,5 0,375 -5,00 6,83
0,5 a 0,83 0,667 -5,00 7,34
0,83 a 2,5 1,667 -5,00 23,21
2 -2,19 97,81
2,5 a 5,83 4,167 0,40 23,92
5,83 a 9,16 7,500 0,45 12,27
9,16 a 14,16 11,667 1,40 7,29
14,16 a 19,16 16,667 0,30 5,86
19,16 a 25 22,083 -0,53 1,73
0 a 0,083 0,042 -5,00 4,56
0,083 a 0,25 0,167 -5,00 6,99
0,25 a 0,5 0,375 -5,00 6,83
0,5 a 0,83 0,667 -5,00 7,34
0,83 a 2,5 1,667 -5,00 23,21
3 -2,14 97,86
2,5 a 5,83 4,167 -0,40 23,92
5,83 a 9,16 7,500 2,01 12,27
9,16 a 14,16 11,667 1,53 7,29
14,16 a 19,16 16,667 0,67 5,86
19,16 a 25 22,083 0,03 1,73
Destaca-se que em virtude da impossibilidade de se verificar as vazões de 0,042 l/min

a 1,667 l/min, aplicou-se o maior percentual de erro estabelecido em norma (-5,0 %) para
essas faixas de vazões (pior caso), embora o sensor não tenha extrapolado os 2 % em nenhuma
medição, podendo apresentar níveis reais ainda melhores ou, a depender da faixa de vazão,
exceder os limites estabelecidos em norma, o que só pode ser confirmado executando-se o ensaio
de calibração para todas as faixas de vazão.
111
5 CONCLUSÕES
Este trabalho apresentou a construção e obtenção de resultados a partir de um protótipo

de sistema de monitoramento e "medição inteligentes de água" implantado no ponto de entrada
de água do campus Campina Grande do IFPB, como um projeto piloto e uma iniciativa para
tornar o campus um campus inteligente (Smart Campus), como também, abordou alguns tra-
balhos correlatos ao tema apresentado e tópicos da fundamentação teórica necessária para o
desenvolvimento do artefato desenvolvido.
O protótipo se destaca pelo uso da tecnologia LoRa® e do middleware Dojot, em
vez de soluções na nuvem, no qual a comunicação é bidirecional através do LoRa® gateway
Dragino LG02, além de utilizar adaptações a metodologias metrológicas estabelecidas em normas
brasileiras vigentes, para calibração do sensor de vazão do "medidor inteligente de água", o
cálculo do índice de desempenho do medidor e o cálculo da incerteza da medição (Tipo A).
O middleware Dojot demonstra ser uma ferramenta promissora para o gerenciamento de
ecossistemas IoT, reduzindo a complexidade de desenvolvimento de “aplicações inteligentes”,
como também, facilita a prototipação do produtos mínimo viável (Minimum Viable Product
- MVP). Além disso, demonstra ser uma plataforma robusta para produção em um “campus
inteligente”, embora apresente algumas limitações já reportadas neste documento, o que já é
esperado para um plataforma considerada em fase beta.
A comunicação LoRa® entre hidrômetro inteligente e o Dragino LG02, apresentou um
ótimo índice de desempenho (99,65%) em relação a taxa de perda de pacotes, mesmo com as
configurações padrões (exceto pela frequência de operação, que foi alterada para 917 mHz) e
com o gateway posicionado sobre uma estação de trabalho dentro da Coordenação de Tecnologia
da Informação (CTI), com uma potência de sinal (RSSI) média de -89,00 dBm, demonstrando
que a tecnologia LoRa® é viável e bem robusta para o desenvolvimento de aplicações IoT em
um campus inteligente.
O resultado de uma medição é uma estimativa do valor do mensurando e, desta forma, a
apresentação do resultado só é completa quando acompanhada por uma quantidade que declara
sua incerteza. Assim, foi apresentado para as faixas de vazão no qual realizou-se a calibração do
sensor de vazão FS400A, a avalização do Tipo A da incerteza da medição.
Embora o sensor de vazão de baixo custo FS400A utilizado no hidrômetro inteligente
tenha apresentado resultados satisfatórios na fase de calibração, com uma taxa de erro médio
menor que ±2 % em todas as faixas de vazão ensaiadas, na fase de caracterização do perfil
de consumo, com o sensor já instalado no cavalete de entrada de água do campus, o mesmo
apresentou um taxa de erro de aproximadamente -7 % na contabilização do volume total (m³)
em relação ao hidrômetro SAGA da concessionária de água CAGEPA , no qual era esperado
Capítulo 5. Conclusões 112
uma margem de erro entre ±3 % e ±5 % (taxa de erro máximo, segundo o fabricante), já que
não foi possível calibrar o sensor para faixa de vazão operacional, demonstrando assim, que a
solução necessita de ajustes.
Ainda sobre o sensor FS400A, para as faixas de vazão ensaiadas, o mesmo apresentou um
índice de desempenho da medição (IDM) de 97,83 % de eficiência, ou seja, apenas -2,17 % (EP)
do volume escoado pelo sensor FS400A não será contabilizado (submedição), demonstrando que
a principio esse tipo de sensor pode ser utilizado se devidamente calibrado e bem acomodado,
embora seja necessário uma avaliação minuciosa do IDM ao longo de 10 anos conforme preconiza
a norma ABNT NBR 15538:2014.
Quanto a pressão no cavalete de entrada de água do campus, constatou-se que as pressões
registradas operam dentro dos limites estabelecidos pela norma brasileira ABNT NBR 12218
(entre 10 mca e 50 mca), atuando a maior parte do tempo na casa dos 4,00 bar (40,78 mca), com
alguns picos de pressão (máximo registrado de 4,73 bar ou 48,23 mca) próximo dos 5,00 bar, o
que demonstra que o manômetro analógico utilizado deve ser substituído por um manômetro
com um fundo de escalar de pelo menos 5,00 bar.
Embora o rigor metodológico das normas não tenham sido seguidos a risca, em virtude
da falta de infraestrutura e recursos, tornando o controle de variáveis dos procedimentos de
ensaio (como temperatura, umidade, vazão e pressão do sistema) impossíveis de serem obtidos
com a precisão estabelecida em norma, além da ausência de equipamentos já calibrados e
certificados para efeito comparativo — apesar de o objetivo não ser a certificação de sensores —
demonstrou-se mediante o exposto, que a adaptação ao modelo de bancada apresentado pode ser
viável para calibração de sensores de vazão.
Considerando-se que o artefato atingiu os resultados esperados após a etapa de avaliação,
podemos destacar como aprendizagem durante o desenvolvimento do protótipo, que a implemen-
tação de uma solução IoT é complexa e envolve diversas áreas de conhecimento, como eletrônica,
programação, redes de computadores, sistemas, etc, e que em cada uma dessas áreas enfreou-se
dificuldades e limitações, como por exemplo, na bancada de calibração do sensor de vazão, que
não foi possível realizar os ensaios em alguns faixas de vazão estabelecidas em norma.
Ante o exposto, constata-se que a telemetria em tempo real (monitoramento) e o controle
remoto do abastecimento de água de um campus são possíveis utilizando tecnologias IoT de
baixo custo, através da tecnologia de comunicação sem fio LoRa®, ou seja, o ecossistema
utilizado neste projeto piloto pode ser replicado com uma solução para aplicações IoT em
um Smart Campus, uma vez que, ainda não existe um padrão de fato na literatura ou solução
comercial.
Capítulo 5. Conclusões 113
5.1 Trabalhos Futuros
Embora os resultados obtidos durante o desenvolvimento deste trabalho tenham apresen-

tado resultados satisfatórios, sempre há o que melhorar e ajustar para se obter resultados ainda
mais precisos.
Nesse sentido, como recomendações de trabalhos futuros, podemos elencar uma série
de melhorias que podem ser realizadas, tanto em termos de hardware como de software, como
também, em procedimentos metodológicos de ensaios e equipamentos a serem utilizados.
Inicialmente, recomenda-se a adoção de um sistema de placas solares e/ou de geradores
do tipo turbina para uma autonomia energética do sistema, garantindo assim, que os dados serão
preservados com a ausência de energia da rede elétrica, além de adaptar-se a uma tendência
futura de ecossistema Smart imprescindível para um campus inteligente autossustentado.
Em termos de hardware, sugere-se a utilização de sensores de vazão do tipo ultrassônico,
que são mais precisos, não invasivos (não há necessidade de romper tubulações), apresentam
maior vida útil com uma maior precisão e baixa perda de carga, como também, recomenda-se a
substituição do manômetro analógico por um manômetro com fundo de escala > 5,0 bar.
Já no quesito software, recomenda-se a utilização de um sistema operacional de tempo
real (do inglês: Real Time Operating Systems - RTOS) como o FreeRTOS para o dispositivo
embarcado, garantindo assim, uma maior precisão nos contadores de tempo e isolamento de
tarefas.
Quanto a bancada proposta para calibração do sensor de vazão, sugere-se adaptações
para um melhor desempenho na calibração do sensor, com a introdução de uma válvula esta-
bilizadora de vazão e uma válvula reguladora de vazão, conforme preconiza a norma ABNT
NBR 4185:2009, como também, recomenda-se a substituição do pressurizador de pressão por
um dispositivo de maior capacidade de pressão, para que seja possível atingir vazões maiores,
assim como, recomenda-se a substituição da válvula solenoide, uma vez que, a válvula utilizada
apresentou falhas de funcionamento em baixas vazões, inviabilizando o ensaio em faixas de
vazões menores.
Por fim, recomenda-se uma avaliação estatística da incerteza da qmedição Tipo B, para
que seja possível realizar o cálculo da incerteza-padrão combinada (uC = u2A + u2B ), em que uA
é incerteza do Tipo A e uB são as incerteza do Tipo B, tornando assim, uma avaliação ainda mais
precisa da incerteza da medição.
114
REFERÊNCIAS BIBLIOGRÁFICAS
CPQD. Citado na página 39.
ADAMS, M. N.; JOKONYA, O. An investigation of smart water meter adoption

factors at universities. Procedia Computer Science, v. 196, p. 324–331, 2022. ISSN
1877-0509. International Conference on ENTERprise Information Systems / ProjMAN
- International Conference on Project MANagement / HCist - International Conference
on Health and Social Care Information Systems and Technologies 2021. Disponível em:
<https://www.sciencedirect.com/science/article/pii/S1877050921022432>. Citado 2 vezes nas
páginas 20 e 23.
AESB. Guia Prático de Procedimentos para Estimativa de Submedição no Parque de

Hidrômetros. 1ª. ed. Brasília: Associação Brasileira das Empresas Estaduais de Saneamento -
AESB, 2015. Disponível em: <http://www.aesbe.org.br/wp-content/uploads/2018/04/GUIA-3_
V5-.pdf>. Acesso em: 22 de abr. de 2021. Citado na página 22.
AGRICULTURE, C. A. of Water Management in. Water for Food, Water for Life: A
Comprehensive Assessment of Water Management in Agriculture. London: Earthscan,
and Colombo: International Water Management Institute, 2007. Disponível em:
<https://www.iwmi.cgiar.org/assessment/files_new/synthesis/Summary_SynthesisBook.pdf>.
Acesso em: 15 de abr. de 2021. Citado na página 20.
ALLIANCE. RP002-1.0.0 LoRaWAN Regional Parameters. LoRa Alliance, 2019. Disponível

em: <https://lora-alliance.org/wp-content/uploads/2019/11/rp_2-1.0.0_final_release.pdf>.
Acesso em: 26 de maio de 2021. Citado 2 vezes nas páginas 7 e 32.
ALLIANCE, L. LoRaWAN, What is it? A technical overview of LoRa® and LoRaWAN™.

Fremont, CA: LoRa Alliance®, 2020. Disponível em: <https://lora-alliance.org/wp-content/
uploads/2020/11/what-is-lorawan.pdf>. Acesso em: 22 de maio. de 2021. Citado na página 65.
ANA. Conjuntura dos recursos hídricos no Brasil 2020: informe anual. Brasília:
Agência Nacional de Águas e Saneamento Básico - ANA, 2020. Disponível em:
<http://conjuntura.ana.gov.br/static/media/conjuntura-completo.23309814.pdf>. Acesso em: 11
de mar. de 2021. Citado na página 18.
ANATEL. ATO Nº 14448, DE 04 DE DEZEMBRO DE 2017. AGÊNCIA NACIONAL DE

TELECOMUNICAÇÕES, 2017. Disponível em: <https://sei.anatel.gov.br/sei/publicacoes/
controlador_publicacoes.php?acao=publicacao_visualizar&id_documento=2549681&id_
orgao_publicacao=0>. Acesso em: 26 de mar. de 2021. Citado na página 32.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 15538: Medidores de água

potável — ensaios para avaliação de eficiência. Rio de Janeiro, 2014. 24 p. Citado 5 vezes nas
páginas 55, 56, 57, 58 e 59.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO 1568: Medição de vazão

de fluidos - procedimento para avaliação de incertezas. Rio de Janeiro, 2015. 83 p. Citado 3
vezes nas páginas 60, 61 e 62.
Referências Bibliográficas 115
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 16043-2: Medidores para água

potável fria e água quente parte 2: Métodos de ensaio. Rio de Janeiro, 2021. 125 p. Citado 2
vezes nas páginas 57 e 58.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR 16043-4: Medidores para água
potável fria e água quente parte 4: Requisitos de instalação. Rio de Janeiro, 2021. 12 p. Citado
na página 62.
AWS. O que é o Redis? Amazon Web Services, Inc., 2021. Disponível em: <https:
//aws.amazon.com/pt/elasticache/what-is-redis/>. Acesso em: 28 de maio de 2021. Citado na
página 40.
BANKS, A. et al. MQTT Version 5.0. OASIS Standard, 2019. Disponível em: <https:
//docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html>. Acesso em: 27 de maio de 2021. Citado
2 vezes nas páginas 35 e 36.
BENAYACHE, A. et al. Msm: A microservice middleware for smart wsn-based iot application.
Journal of Network and Computer Applications, v. 144, p. 138–154, 2019. ISSN 1084-8045.
Disponível em: <https://www.sciencedirect.com/science/article/pii/S1084804519302206>.
Citado na página 37.
BERTOLETI, P. Projetos com ESP32 e LoRa. 1. edição do kindle. ed. São Paulo: Editora NCB,
2019. Citado na página 41.
BIOCAM. Empresas de Campinas São Referências na Criação De
Soluções de Internet das Coisas para a Área de Saúde. BIOCAM So-
luções Hospitalares, 2018. Disponível em: <https://www.biocam.com.br/
empresas-de-campinas-sao-referencias-na-criacao-de-solucoes-de-internet-das-coisas-para-a-area-de-saude
>. Acesso em: 29 de maio de 2021. Citado na página 72.
BRANDÃO, I. A. D. P. e. a. Sistema inteligente para automação do consumo de água dos pontos
de utilização no campus da ufcg de campina grande-pb. [S.l.], 2019. Acesso em: 21-06-2021.
Citado 3 vezes nas páginas 42, 43 e 45.
BRASIL. Diagnóstico dos Serviços de Água e Esgotos. Brasília: Sistema Nacional de
Informações sobre Saneamento, 2019. Disponível em: <http://www.snis.gov.br/downloads/
diagnosticos/ae/2019/DiagnC3B3stico_SNIS_AE_2019_Republicacao_31032021.pdf>. Acesso
em: 22 de abr. de 2021. Citado na página 21.
BRASIL. Portaria nº 490, de 22 de março de 2021. Brasília: Ministério do Desenvolvimento
Regional. Gabinete do Ministro, 2021. Disponível em: <https://www.in.gov.br/en/web/dou/-/
portaria-n-490-de-22-de-marco-de-2021-309988760>. Acesso em: 22 de abr. de 2021. Citado
na página 22.
BRASIL. Portaria nº 155, de 31 de MARÇO de 2022. Brasília: Ministério da Indústria, Comércio
Exterior e Serviços – MDIC. Instituto Nacional de Metrologia, Qualidade e Tecnologia -
INMETRO, 2022. Disponível em: <http://sistema-sil.inmetro.gov.br/rtac/RTAC002971.pdf>.
Acesso em: 18 de jan. de 2021. Citado na página 22.
CPQD. CPQD lança dojot, plataforma aberta para o desenvolvimento de apli-
cações de IoT. CPQD, 2017. Disponível em: <https://www.cpqd.com.br/releases/
cpqd-lanca-dojot-plataforma-aberta-para-o-desenvolvimento-de-aplicacoes-de-iot/>. Acesso
em: 29 de maio de 2021. Citado na página 72.
DERIVA. deriva no Dicionário infopédia da Língua Portuguesa. In: Infopédia, Dicionários

Porto Editora, 2021. Disponível em: <https://www.infoescola.com/ecologia/estresse-hidrico/>.
Acesso em: 23 de mar. de 2021. Citado na página 30.
DOJOT. Você conhece a dojot? DOJOT, 2017. Disponível em: <https://dojot.com.br/

sobre-a-dojot-iot/>. Acesso em: 28 de maio de 2021. Citado na página 37.
DOJOT. Documentação da dojot. DOJOT, CPqD, 2020. Disponível em: <https:

//dojotdocs.readthedocs.io/pt_BR/latest/>. Acesso em: 28 de maio de 2021. Citado 5 vezes nas
páginas 7, 38, 39, 40 e 54.
DRAGINO. LG02 Dual Channels LoRa IoT Gateway. Dragino Technology Co., LTD., 2020.
Disponível em: <https://www.dragino.com/products/lora-lorawan-gateway/item/135-lg02.html>.
Acesso em: 22 de maio. de 2021. Citado 2 vezes nas páginas 7 e 71.
DRESCH, A. Design Science e Design Science Research como Artefatos Metodológicos para
Engenharia de Produção. 184 p. Dissertação (Mestrado) — Universidade do Vale do Rio dos
Sinos – UNISINOS, São Leopoldo, 2013. Citado 2 vezes nas páginas 48 e 49.
DRESCH, A.; LACERDA, D. P.; ANTUNES, J. A. V. J. Design Science Research: Método de

Pesquisa para Avanço da Ciência e Tecnologia. Edição do kindle. Porto Alegre: Bookman, 2020.
Citado 5 vezes nas páginas 48, 49, 50, 51 e 52.
EC. Smart cities. European Commission, 2021. Disponível em: <https://ec.europa.eu/info/

eu-regional-and-urban-development/topics/cities-and-urban-development/city-initiatives/
smart-cities_en>. Acesso em: 11 de mar. de 2021. Citado na página 18.
EOS. Impactos das Perdas de Água Comerciais no Faturamento das Empresas

de Saneamento. EOS Organização e Sistemas Ltda, 2019. Disponível em: <https:
//www.eosconsultores.com.br/impacto-das-perdas-de-agua-comerciais/>. Acesso em: 19 de abr.
de 2021. Citado na página 21.
FACENS. Guia FACENS para Cidades Inteligentes, Sustentáveis e Seguras. Sorocaba, São
Paulo: FACENS, 2020. Disponível em: <https://blog.facens.br/wp-content/uploads/2020/09/
Cartilha-Cidades-Inteligentes-Smart-Campus.pdf>. Acesso em: 13 de mar. de 2021. Citado na
página 18.
HAOYU. G1"Water Flow Sensor. HAOYU STAR Electronics, 2021. Disponível em:
<https://www.hotmcu.com/g1-water-flow-sensor-p-312.html>. Acesso em: 08 de jun. de 2021.
Citado 3 vezes nas páginas 7, 56 e 57.
HAT, R. O que é Apache Kafka? Red Hat, Inc., 2021. Disponível em: <https:
//www.redhat.com/pt-br/topics/integration/what-is-apache-kafka>. Acesso em: 28 de
maio de 2021. Citado na página 39.
HELTEC. WIFI LoRa 32(V2). Chengdu Heltec Automation Technology Co., Ltd, 2018.
Disponível em: <https://heltec.org/project/wifi-lora-32/>. Acesso em: 28 de maio de 2021.
HELTEC. WIFI LoRa 32(V2) Pinout Diagram. Chengdu Heltec Automation Technology Co.,
Ltd, 2021. Disponível em: <https://resource.heltec.cn/download/WiFi_LoRa_32/WIFI_LoRa_
32_V2.pdf>. Acesso em: 28 de maio de 2021. Citado 2 vezes nas páginas 7 e 41.
HERRERO, R. Towards protocol stack virtualization in massive iot deployments.

Internet of Things, v. 14, p. 100396, 2021. ISSN 2542-6605. Disponível em: <https:
//www.sciencedirect.com/science/article/pii/S2542660521000408>. Citado na página 35.
HIVEMQ. MQTT & MQTT 5 Essentials: A comprehensive overview of MQTT facts and features
for beginners and experts alike. Bavaria, Germany: HiveMQ GmbH, 2015. v. 1. Disponível em:
<https://www.hivemq.com/mqtt-5/>. Citado 3 vezes nas páginas 7, 35 e 36.
INMETRO. Avaliação de dados de medição: Guia para a expressão de incerteza de medição –

GUM 2008. 1ª. ed. Duque de Caxias, RJ: INMETRO/CICMA/SEPIN, 2012. Disponível em:
<http://www.inmetro.gov.br/inovacao/publicacoes/gum_final.pdf>. Acesso em: 25 de maio de
2021. Citado 6 vezes nas páginas 27, 28, 29, 30, 31 e 45.
INMETRO. Vocabulário Internacional de Metrologia: Conceitos fundamentais e gerais e

termos associados (VIM 2012). 1ª. ed. Duque de Caxias, RJ: INMETRO, 2012. Disponível em:
<http://www.inmetro.gov.br/inovacao/publicacoes/vim_2012.pdf>. Acesso em: 25 de maio de
2021. Citado 5 vezes nas páginas 27, 28, 29, 30 e 31.
ITB. Perdas de Água 2020 (SNIS 2018): Desafios para Disponibilidade Hídrica e
Avanço da Eficiência do Saneamento Básico. Instituto Trata Brasil, 2020. Disponível em:
<http://tratabrasil.org.br/images/estudos/Relat%C3%B3rio_Final_-_Estudo_de_Perdas_2020_
-_JUNHO_2020.pdf>. Acesso em: 17 de abr. de 2021. Citado na página 21.
ITB. Redução das perdas de água potável tem potencial de ganhos líquidos de R$ 30 bilhões
até 2033. Instituto Trata Brasil, 2020. Disponível em: <http://www.tratabrasil.org.br/images/
estudos/Release_-_Estudo_Perdas_de_%C3%81gua_JUNHO_2020.pdf>. Acesso em: 17 de abr.
de 2021. Citado na página 21.
KAFKA. DOCUMENTATION: Kafka 2.8 Documentation. Apache Software Foundation, 2017.

Disponível em: <https://kafka.apache.org/documentation/>. Acesso em: 28 de maio de 2021.
KONCAGüL, E.; TRAN, M.; CONNOR, R. Relatório mundial das Nações Unidas
sobre desenvolvimento dos recursos hídricos 2021: o valor da água; fatos e dados.
Paris, France: UNESCO World Water Assessment Programme, 2021. Disponível em:
<https://unesdoc.unesco.org/ark:/48223/pf0000375751_por>. Acesso em: 15 de abr. de 2021.
KONDORO, A. et al. Real time performance analysis of secure iot protocols for microgrid
communication. Future Generation Computer Systems, v. 116, p. 1–12, 2021. ISSN 0167-739X.
Disponível em: <https://www.sciencedirect.com/science/article/pii/S0167739X20305707>.
LACERDA DANIEL PACHECO, D. A. P. A. A. J. J. A. V. Design Science Research:

método de pesquisa para a engenharia de produção. Gestão & Produção, scielo, v. 20,
p. 741–761, 2013. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=
S0104-530X2013000400001&lang=pt>. Citado na página 48.
LALLE, Y. et al. A comparative study of lorawan, sigfox, and nb-iot for smart water grid. In:
2019 Global Information Infrastructure and Networking Symposium (GIIS). [S.l.: s.n.], 2019.
p. 1–6. Citado 2 vezes nas páginas 19 e 31.
LALLE, Y. et al. Lorawan network capacity analysis for smart water grid. In: 2020 12th
International Symposium on Communication Systems, Networks and Digital Signal Processing
(CSNDSP). [S.l.: s.n.], 2020. p. 1–6. Citado 2 vezes nas páginas 19 e 33.
LIRA, F. A. d. Metrologia na Indústria. 10. ed. Pinheiros, São Paulo: Érica, 2018. Citado na
página 31.
LORA. LoRa. LoRa, 2018. Disponível em: <https://lora.readthedocs.io/en/latest/>. Acesso em:
25 de mar. de 2021. Citado 2 vezes nas páginas 31 e 33.
MANKAD, U.; AROLKAR, H. A. A study of the open source framework osgp / gxf for
implementing smart water metering. In: 2020 Fourth World Conference on Smart Trends in
Systems, Security and Sustainability (WorldS4). [S.l.: s.n.], 2020. p. 357–361. Citado 2 vezes
nas páginas 19 e 23.
MARTYUSHEVA, O. Smart Water Grid: Plan B Technical Report. Fort Collins, Colorado:
Department of Civil and Environmental Engineering. Colorado State University, 2014.
Disponível em: <"https://www.engr.colostate.edu/~pierre/ce_old/Projects/Rising%20Stars%
20Website/Martyusheva,Olga_PlanB_TechnicalReport.pdf">. Acesso em: 18 de mar. de 2021.
MATTOS, C. H. d. Cidades Inteligentes: Motivações e Desafios da Adoção de Medidores
Inteligentes de Água. Rio de Janeiro: O Instituto de Tecnologia e Sociedade do Rio - ITS, 2018.
Disponível em: <https://beta.itsrio.org/wp-content/uploads/2018/03/agatha_mattos-agua.pdf>.
Acesso em: 14 de mar. de 2021. Citado na página 19.
MENDES, A.; ROSáRIO, P. P. N. d. Metrologia e Incerteza de Medição: conceitos e aplicações.
1ª. edição do kindle. ed. Rio de Janeiro: LTC, 2020. Citado 3 vezes nas páginas 27, 28 e 31.
MICROSOFT. Tecnologias e protocolos de IoT. Microsoft, 2021. Disponível em:
<https://azure.microsoft.com/pt-br/overview/internet-of-things-iot/iot-technology-protocols/>.
Acesso em: 27 de maio de 2021. Citado na página 34.
MILEVA, A. et al. Comprehensive analysis of mqtt 5.0 susceptibility to network covert
channels. Computers Security, v. 104, p. 102207, 2021. ISSN 0167-4048. Disponível em:
páginas 35 e 37.
MONGODB. The database for modern applications. MongoDB, Inc., 2021. Disponível em:
<https://www.mongodb.com/>. Acesso em: 28 de maio de 2021. Citado na página 40.
MORAES, C. H. V. d.; ALMEIDA, R. M. A. d.; SERAPHIM, T. d. F. P. Programação de
Sistemas Embarcados: Desenvolvendo Software para Microcontroladores em Linguagem C. 1.
ed. Rio de Janeiro: Elsevier, 2016. Citado na página 41.
MOTTA, A. C. S.; LIMA, C. d. A.; CUNHA, T. C. d. C. Campus universitário e espaço urbano:
integração socioespacial em metrópole e cidades médias no sul do brasil. In: X Seminario
Internacional de Investigación en Urbanismo, Barcelona-Córdoba, Junio 2018. Córdoba,
Barcelona: [s.n.], 2018. ISSN 2604-7756. Disponível em: <http://hdl.handle.net/2117/134353>.
NADIPALLI, L. S. P. S. et al. Water conservation control by using iot smart meter. In: 2021 5th
International Conference on Computing Methodologies and Communication (ICCMC). [S.l.:
s.n.], 2021. p. 448–452. Citado 3 vezes nas páginas 42, 44 e 45.
NAKAGAWA, E. Y. et al. Revisão Sistemática da Literatura em Engenharia de Software. Edição

do kindle. Rio de Janeiro: GEN LTC, 2017. Citado na página 51.
NEVES, A. R. de M. et al. Iniciativa smart campus: um estudo de caso em progresso

na universidade federal do pará. In: Anais do I Workshop de Computação Urbana.
Porto Alegre, RS, Brasil: SBC, 2017. ISSN 2595-2706. Disponível em: <https:
//sol.sbc.org.br/index.php/courb/article/view/2576>. Citado na página 18.
OBERASCHER, M. et al. Smart water campus – a testbed for smart water applications. Water
Science and Technology, v. 86, n. 11, p. 2834–2847, 11 2022. ISSN 0273-1223. Disponível em:
<https://doi.org/10.2166/wst.2022.369>. Citado na página 18.
ORTIZ, F. M. et al. Caracterização de desempenho de uma rede lora em ambientes

urbanos: Simulação vs. prática. In: Anais do III Workshop de Computação Urbana.
Porto Alegre, RS, Brasil: SBC, 2019. p. 167–180. ISSN 2595-2706. Disponível em:
<https://sol.sbc.org.br/index.php/courb/article/view/7476>. Citado 2 vezes nas páginas 32 e 33.
PAIVA, F. Sabesp adota medidores inteligentes de consumo de água. Mobile

Time, 2019. Disponível em: <https://www.mobiletime.com.br/noticias/22/11/2019/
sabesp-adota-medidores-inteligentes-de-consumo-de-agua/>. Acesso em: 18 de mar. de 2021.
PIMENTEL, M.; FILIPPO, D.; SANTORO, F. M. Design Science Research: fazendo

pesquisas científicas rigorosas atreladas ao desenvolvimento de artefatos computacionais
projetados para a educação. Porto Alegre: SBC, 2020. v. 1. Disponível em: <https:
//metodologia.ceie-br.org/livro-1/>. Acesso em: 15 de maio de 2021. Citado na página 49.
RAY, A.; GOSWAMI, S. Iot and cloud computing based smart water metering system. In: 2020
International Conference on Power Electronics IoT Applications in Renewable Energy and its
Control (PARC). [S.l.: s.n.], 2020. p. 308–313. Citado 3 vezes nas páginas 42, 44 e 45.
RODRIGUES, D. Design science research como caminho metodológico para disciplinas

e projetos de design da informação | design science research as methodological path for
information design subjects and projects. InfoDesign - Revista Brasileira de Design da
Informação, v. 15, p. 111–124, 08 2018. Citado na página 48.
RUSSO, F.; RINDONE, C.; PANUCCIO, P. The process of smart city definition at an eu level.
In: . [S.l.: s.n.], 2014. v. 191, p. 979–989. ISBN 9781845648206. Citado na página 18.
SARAVANAN, M.; DAS, A.; IYER, V. Smart water grid management using lpwan iot
technology. In: 2017 Global Internet of Things Summit (GIoTS). [S.l.: s.n.], 2017. p. 1–6.
Citado 2 vezes nas páginas 42 e 45.
SEMTECH. AN1200.22: LoRa™ Modulation Basics. Semtech Corporation, 2015. Disponível

em: <https://www.frugalprototype.com/wp-content/uploads/2016/08/an1200.22.pdf>. Acesso
em: 26 de maio de 2021. Citado na página 33.
SEMTECH. LoRa® and LoRaWAN®: A Technical Overview. Semtech Corporation, 2019.

Disponível em: <https://lora-developers.semtech.com/uploads/documents/files/LoRa_and_
LoRaWAN-A_Tech_Overview-Downloadable.pdf>. Acesso em: 26 de maio de 2021. Citado 3
vezes nas páginas 7, 32 e 33.
SENAI. Serviço Nacional de Aprendizagem Industrial Fundamentos de instrumentação :

pressão / nível / vazão / temperatura. Edição do kindle. São Paulo: SENAI-SP, 2015. Citado na
página 56.
SINGH, M.; AHMED, S. Iot based smart water management systems: A systematic
review. Materials Today: Proceedings, 2020. ISSN 2214-7853. Disponível em:
páginas 7, 23 e 24.
SNIS. Perdas Aparentes: Ações de Assistência Técnica em Redução e Controle de Perdas de

Água e Uso Eficiente de Energia Elétrica. Sistema Nacional de Informações sobre Saneamento,
2018. Disponível em: <http://www.snis.gov.br/downloads/publicacoes-acertar/perdas/Vol.
4-Perdas-Aparentes.pdf>. Acesso em: 17 de abr. de 2021. Citado 3 vezes nas páginas 21, 22
e 58.
SNIS. Sistema Nacional de Informações sobre Saneamento. Sistema Nacional de Informações

sobre Saneamento, 2021. Disponível em: <http://appsnis.mdr.gov.br/indicadores/web/agua_
esgoto/mapa-agua>. Acesso em: 23 de abr. de 2021. Citado na página 21.
SNIS. Diagnóstico Temático Serviços de Água e Esgoto. Visão Geral. Ministério do

Desenvolvimento Regional Secretaria Nacional de Saneamento, 2022. Disponível em:
<https://arquivos-snis.mdr.gov.br/DIAGNOSTICO_TEMATICO_VISAO_GERAL_AE_
SNIS_2022.pdf>. Acesso em: 18 de jan. de 2023. Citado 2 vezes nas páginas 20 e 21.
SUçUARANA, M. d. S. Estresse hídrico. InfoEscola: Navegando e Aprendendo, 2021.

Disponível em: <https://www.infoescola.com/ecologia/estresse-hidrico/>. Acesso em: 22 de
mar. de 2021. Citado na página 20.
VERNEMQ. What is VerneMQ? Octavo Labs AG, 2021. Disponível em: <https:
//vernemq.com/intro/index.html>. Acesso em: 28 de maio de 2021. Citado na página 39.
VERSTAEVEL, N.; BOES, J.; GLEIZES, M.-P. From smart campus to smart cities issues of the
smart revolution. In: 2017 IEEE SmartWorld, Ubiquitous Intelligence Computing, Advanced
Trusted Computed, Scalable Computing Communications, Cloud Big Data Computing, Internet
of People and Smart City Innovation (SmartWorld/SCALCOM/UIC/ATC/CBDCom/IOP/SCI).
[S.l.: s.n.], 2017. p. 1–6. Citado na página 18.
VIKASH; MISHRA, L.; VARMA, S. Middleware technologies for smart wireless sensor
networks towards internet of things: A comparative review. Wireless Personal Communications,
v. 116, 02 2021. Citado na página 37.
WISINTAINER, E. H. P. e Aurélio Faustino Hoppe e M. A. Smart water:a prototype for

monitoring water consumption. Anais do Computer on the Beach, v. 11, n. 1, p. 321–325, 2020.
ISSN 2358-0852. Disponível em: <https://siaiap32.univali.br/seer/index.php/acotb/article/view/
16786>. Citado 3 vezes nas páginas 42, 43 e 45.
WRI. Ensuring Prosperity in a Water-stressed World. [S.l.]: World Resources Institute - WRI,
2021. "https://www.wri.org/water". Acesso em: 01 de mar. de 2021. Citado na página 18.
YE, Y. et al. A lora-based low-power smart water metering system. In: 2021 IEEE International
Conference on Consumer Electronics and Computer Engineering (ICCECE). [S.l.: s.n.], 2021. p.
301–305. Citado 2 vezes nas páginas 42 e 45.
YI, S. et al. Smart Water Management: Case Study Report. K-water, IWRA, 2018. Disponível
em: <"https://www.iwra.org/wp-content/uploads/2018/11/SWM-report-final.pdf">. Acesso em:
18 de mar. de 2021. Citado na página 19.
YUGHA, R.; CHITHRA, S. A survey on technologies and security protocols: Reference for
future generation iot. Journal of Network and Computer Applications, v. 169, p. 102763,
2020. ISSN 1084-8045. Disponível em: <https://www.sciencedirect.com/science/article/pii/
S108480452030237X>. Citado na página 35.
Apêndices
123
APÊNDICE A – TABELA COMPLETA DO CÁLCULO DO

IDM
Vazões para Vazões para
Faixa de Faixa de vazão Erro Bancada
Ordem verificação de verificação de Peso (%) EP (%) IDM (%)
vazão (L/h) (L/min) (%)
erros (L/h) erros (L/min)
0a5 2,5 0 a 0,083 0,042 -5,00 4,56

5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
1 -2,38 97,62
150 a 350 250 2,5 a 5,83 4,167 0,07 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,43 12,27
550 a 850 700 9,16 a 14,16 11,667 1,08 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,30 5,86
1150 a 1500 1325 19,16 a 25 22,083 0,34 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
2 -2,19 97,81
150 a 350 250 2,5 a 5,83 4,167 0,40 23,92
350 a 550 450 5,83 a 9,16 7,500 0,45 12,27
550 a 850 700 9,16 a 14,16 11,667 1,40 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,30 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,53 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
3 -2,14 97,86
150 a 350 250 2,5 a 5,83 4,167 -0,40 23,92
350 a 550 450 5,83 a 9,16 7,500 2,01 12,27
550 a 850 700 9,16 a 14,16 11,667 1,53 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,67 5,86
1150 a 1500 1325 19,16 a 25 22,083 0,03 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
4 -1,47 98,53
150 a 350 250 2,5 a 5,83 4,167 2,55 23,92
350 a 550 450 5,83 a 9,16 7,500 1,88 12,27
550 a 850 700 9,16 a 14,16 11,667 1,20 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,94 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,16 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
5 -2,24 97,76
150 a 350 250 2,5 a 5,83 4,167 0,50 23,92
350 a 550 450 5,83 a 9,16 7,500 0,30 12,27
550 a 850 700 9,16 a 14,16 11,667 0,71 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,18 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,42 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
6 -2,27 97,73
150 a 350 250 2,5 a 5,83 4,167 0,37 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,36 12,27
550 a 850 700 9,16 a 14,16 11,667 1,35 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,68 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,58 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
7 -1,70 98,30
150 a 350 250 2,5 a 5,83 4,167 0,37 23,92
350 a 550 450 5,83 a 9,16 7,500 4,88 12,27
550 a 850 700 9,16 a 14,16 11,667 1,15 7,29
850 a 1150 1000 14,16 a 19,16 16,667 -0,22 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,78 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
8 -2,40 97,60
150 a 350 250 2,5 a 5,83 4,167 -0,96 23,92
350 a 550 450 5,83 a 9,16 7,500 1,37 12,27
550 a 850 700 9,16 a 14,16 11,667 1,53 7,29
850 a 1150 1000 14,16 a 19,16 16,667 -0,02 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,21 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
9 -2,04 97,96
150 a 350 250 2,5 a 5,83 4,167 1,74 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,86 12,27
550 a 850 700 9,16 a 14,16 11,667 1,24 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,26 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,32 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
10 -2,02 97,98
150 a 350 250 2,5 a 5,83 4,167 1,76 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,67 12,27
550 a 850 700 9,16 a 14,16 11,667 0,97 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,42 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,33 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
11 -2,48 97,52
150 a 350 250 2,5 a 5,83 4,167 0,15 23,92
350 a 550 450 5,83 a 9,16 7,500 -1,80 12,27
550 a 850 700 9,16 a 14,16 11,667 1,59 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,66 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,11 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
12 -2,57 97,43
150 a 350 250 2,5 a 5,83 4,167 -0,40 23,92
350 a 550 450 5,83 a 9,16 7,500 -1,48 12,27
550 a 850 700 9,16 a 14,16 11,667 1,72 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,43 5,86
1150 a 1500 1325 19,16 a 25 22,083 0,05 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
13 -1,99 98,01
150 a 350 250 2,5 a 5,83 4,167 1,60 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,89 12,27
550 a 850 700 9,16 a 14,16 11,667 2,17 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,50 5,86
1150 a 1500 1325 19,16 a 25 22,083 0,01 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
14 -2,22 97,78
150 a 350 250 2,5 a 5,83 4,167 0,52 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,54 12,27
550 a 850 700 9,16 a 14,16 11,667 1,41 7,29
850 a 1150 1000 14,16 a 19,16 16,667 1,01 5,86
1150 a 1500 1325 19,16 a 25 22,083 0,15 1,73
0a5 2,5 0 a 0,083 0,042 -5,00 4,56
5 a 15 10 0,083 a 0,25 0,167 -5,00 6,99
15 a 30 22,5 0,25 a 0,5 0,375 -5,00 6,83
30 a 50 40 0,5 a 0,83 0,667 -5,00 7,34
50 a 150 100 0,83 a 2,5 1,667 -5,00 23,21
15 -2,52 97,48
150 a 350 250 2,5 a 5,83 4,167 -0,42 23,92
350 a 550 450 5,83 a 9,16 7,500 -0,56 12,27
550 a 850 700 9,16 a 14,16 11,667 1,33 7,29
850 a 1150 1000 14,16 a 19,16 16,667 0,04 5,86
1150 a 1500 1325 19,16 a 25 22,083 -0,31 1,73
MÉDIA -2,17 97,83
EP (%) IDM (%)

-2,17 97,83
127
APÊNDICE B – MÉDIA E DESVIO-PADRÃO DOS

PARÂMETROS AUXILIARES NO PROCESSO DE
CALIBRAÇÃO DO SENSOR FS400A
Medição BAR (X) BAR (S) TA (X) TA (S) TH (X) TH (S) UM (X) UM (S) VI (X) VI (S)
1 1,051 0,009 28,294 0,033 31,478 0,062 51,594 0,085 4,063 0,775
2 1,031 0,011 28,365 0,044 31,456 0,055 51,444 0,112 3,964 0,743
3 1,047 0,011 28,428 0,029 31,276 0,198 51,405 0,240 3,947 0,738
4 1,022 0,008 28,470 0,034 31,301 0,067 52,090 0,149 4,019 0,758
5 1,035 0,009 28,538 0,033 31,083 0,113 52,802 0,178 3,958 0,743
6 1,041 0,010 28,574 0,030 31,388 0,041 52,319 0,159 4,021 0,756
7 1,056 0,010 28,613 0,032 31,366 0,075 52,311 0,112 4,000 0,750
8 1,066 0,014 28,734 0,031 31,253 0,123 52,174 0,138 3,964 0,743
9 1,040 0,012 28,800 0,032 30,977 0,077 51,689 0,077 4,015 0,758
10 1,028 0,010 29,042 0,032 - - 52,247 0,088 3,969 0,746
11 1,040 0,009 29,100 0,042 - - 52,742 0,108 3,924 0,747
12 1,039 0,008 29,102 0,040 - - 52,442 0,435 3,921 0,737
13 1,057 0,007 29,167 0,034 - - 52,365 0,131 4,045 0,759
14 1,045 0,009 29,220 0,035 - - 53,528 0,234 3,972 0,744
15 1,049 0,010 29,232 0,028 - - 54,491 0,135 3,938 0,738
 1,043 0,010 28,779 0,034 31,287 0,090 52,376 0,159 3,981 0,749
S² 0,000 0,000 0,113 0,000 0,028 0,002 0,654 0,008 0,002 0,000
S() 0,012 0,002 0,336 0,005 0,166 0,048 0,809 0,090 0,043 0,010
u 0,003 0,000 0,087 0,001 0,059 0,017 0,209 0,023 0,011 0,003
U 0,007 0,001 0,191 0,003 0,139 0,040 0,460 0,051 0,025 0,006
Legenda:
Média 
Variância S²
Desvio-Padrão da Média S()
Incerteza-Padrão da Média u
Incerteza Expandida da Média U
Falha na obteção dos dados -
Vazão ensaiada (l/min) 4,167
1 1,009 0,013 24,967 0,030 28,040 0,100 67,288 0,348 7,177 1,305
2 1,003 0,009 25,006 0,033 27,730 0,081 67,563 0,139 6,873 1,292
3 1,002 0,012 25,058 0,025 27,801 0,041 67,467 0,207 6,988 1,323
4 1,008 0,013 25,133 0,043 27,159 0,062 68,746 0,272 6,975 1,316
5 1,000 0,009 25,202 0,030 27,255 0,141 68,632 0,277 6,845 1,287
6 0,999 0,011 25,266 0,035 27,479 0,027 68,098 0,057 6,786 1,274
7 1,007 0,011 25,344 0,034 28,307 0,148 66,480 0,581 7,158 1,347
8 1,014 0,008 25,407 0,039 28,226 0,103 65,906 0,206 6,952 1,312
9 1,017 0,010 25,520 0,029 27,762 0,126 67,184 0,298 6,809 1,281
10 1,006 0,009 25,582 0,033 27,650 0,069 67,656 0,185 6,769 1,275
11 1,005 0,009 25,660 0,049 28,067 0,064 66,953 0,154 6,711 1,287
12 1,003 0,012 25,746 0,035 28,025 0,220 66,645 0,301 6,719 1,261
13 0,990 0,010 25,789 0,038 27,842 0,147 66,892 0,272 6,684 1,249
14 1,006 0,012 25,818 0,037 28,307 0,101 65,920 0,180 6,767 1,298
15 1,014 0,010 25,927 0,052 28,599 0,153 65,379 0,328 6,802 1,266
 1,005 0,011 25,428 0,036 27,883 0,105 67,121 0,254 6,868 1,291
S² 0,000 0,000 0,101 0,000 0,161 0,003 0,942 0,015 0,023 0,001
S() 0,007 0,002 0,318 0,007 0,401 0,051 0,970 0,121 0,153 0,026
u 0,002 0,000 0,082 0,002 0,103 0,013 0,251 0,031 0,040 0,007
U 0,004 0,001 0,181 0,004 0,228 0,029 0,551 0,069 0,087 0,015
Legenda:
Média 
Variância S²
1 0,811 0,008 26,056 0,027 28,762 0,087 63,980 0,114 11,174 2,091
2 0,799 0,014 26,092 0,030 28,589 0,075 64,161 0,179 11,107 2,092
3 0,797 0,011 26,162 0,035 28,721 0,103 63,900 0,242 11,096 2,087
4 0,808 0,009 26,232 0,036 28,626 0,133 64,379 0,144 11,148 2,098
5 0,808 0,010 26,298 0,037 28,738 0,055 63,095 0,107 11,100 2,088
6 0,805 0,012 26,387 0,038 29,151 0,128 62,854 0,292 11,151 2,097
7 0,810 0,010 26,447 0,032 28,945 0,147 63,482 0,348 11,178 2,103
8 0,806 0,011 26,510 0,032 29,547 0,262 61,589 0,417 11,154 2,099
9 0,805 0,010 26,554 0,029 29,395 0,102 61,903 0,161 11,109 2,089
10 0,795 0,012 26,643 0,034 29,120 0,076 61,811 0,127 11,035 2,079
11 0,804 0,011 26,730 0,029 28,542 0,126 63,619 0,394 11,149 2,097
12 0,802 0,010 26,776 0,038 29,054 0,075 62,917 0,177 11,150 2,098
13 0,798 0,013 26,836 0,034 29,337 0,166 62,257 0,245 11,165 2,101
14 0,794 0,012 26,898 0,038 29,269 0,194 61,211 0,162 11,095 2,091
15 0,795 0,013 26,990 0,032 29,380 0,083 61,766 0,214 11,092 2,087
 0,802 0,011 26,507 0,033 29,012 0,121 62,862 0,222 11,127 2,093
S² 0,000 0,000 0,091 0,000 0,111 0,003 1,090 0,010 0,002 0,000
S() 0,006 0,001 0,301 0,004 0,333 0,055 1,044 0,100 0,040 0,007
u 0,001 0,000 0,078 0,001 0,086 0,014 0,270 0,026 0,010 0,002
U 0,003 0,001 0,171 0,002 0,189 0,031 0,593 0,057 0,023 0,004
Legenda:
Média 
Variância S²
1 0,585 0,009 27,324 0,038 29,946 0,215 60,369 0,557 16,311 3,076
2 0,580 0,012 27,401 0,039 30,483 0,059 60,174 0,369 16,222 3,061
3 0,579 0,011 27,488 0,033 30,515 0,042 58,917 0,249 16,132 3,037
4 0,583 0,012 27,566 0,029 30,529 0,114 58,828 0,114 16,250 3,061
5 0,583 0,010 27,615 0,030 29,932 0,120 60,144 0,137 16,150 3,044
6 0,575 0,010 27,678 0,036 30,182 0,154 59,636 0,155 16,107 3,034
7 0,578 0,011 27,752 0,025 29,833 0,104 60,533 0,329 15,966 3,009
8 0,571 0,106 26,884 0,036 29,060 0,037 60,596 0,085 16,143 3,096
9 0,584 0,010 27,863 0,040 29,996 0,150 60,500 0,174 16,195 3,053
10 0,584 0,011 27,929 0,039 30,200 0,092 59,318 0,368 16,185 3,105
11 0,577 0,012 28,010 0,028 30,499 0,086 58,870 0,293 16,100 3,033
12 0,581 0,011 28,068 0,031 29,963 0,246 58,867 0,639 16,105 3,089
13 0,575 0,011 28,139 0,036 30,071 0,041 59,549 0,121 16,077 3,025
14 0,577 0,012 28,197 0,036 30,858 0,081 59,283 0,157 16,139 3,039
15 0,572 0,013 28,212 0,029 30,220 0,077 62,735 0,702 16,011 3,018
 0,579 0,017 27,742 0,034 30,152 0,108 59,888 0,297 16,139 3,052
S² 0,000 0,001 0,140 0,000 0,176 0,004 1,056 0,039 0,008 0,001
S() 0,004 0,025 0,374 0,005 0,419 0,062 1,028 0,199 0,088 0,029
u 0,001 0,006 0,097 0,001 0,108 0,016 0,265 0,051 0,023 0,007
U 0,003 0,014 0,212 0,003 0,238 0,035 0,584 0,113 0,050 0,016
Legenda:
Média 
Variância S²
1 1,101 0,111 - - 32,104 0,138 54,639 0,097 21,117 3,982
2 1,112 0,074 - - 32,213 0,099 53,997 0,180 21,170 3,991
3 1,108 0,089 - - 32,322 0,074 54,403 0,269 21,042 3,969
4 1,103 0,107 - - 31,959 0,223 54,424 0,272 21,039 4,046
5 1,102 0,102 - - 32,362 0,113 54,056 0,226 21,104 3,983
6 1,117 0,091 - - 32,404 0,064 54,380 0,268 21,190 4,000
7 1,133 0,077 - - 32,413 0,099 54,278 0,154 21,264 4,002
8 1,092 0,101 - - 31,807 0,120 55,266 0,144 21,043 3,974
9 1,078 0,027 - - 31,383 0,090 56,624 0,250 21,081 3,977
10 1,092 0,104 - - 31,695 0,138 55,383 0,273 21,121 3,980
11 1,056 0,015 29,389 0,036 32,245 0,070 55,049 0,386 20,976 3,959
12 1,056 0,020 29,565 0,025 32,230 0,066 55,331 0,099 20,945 3,946
13 1,073 0,022 29,698 0,034 32,499 0,139 54,384 0,391 21,124 3,983
14 1,051 0,020 29,796 0,034 32,464 0,064 53,599 0,133 20,947 3,961
15 1,061 0,016 29,988 0,024 32,640 0,065 53,483 0,136 21,016 3,963
 1,089 0,065 29,687 0,031 32,183 0,104 54,620 0,219 21,079 3,981
S² 0,001 0,002 0,052 0,000 0,116 0,002 0,647 0,009 0,008 0,001
S() 0,025 0,039 0,227 0,006 0,340 0,044 0,804 0,094 0,091 0,024
u 0,007 0,010 0,114 0,003 0,088 0,011 0,208 0,024 0,023 0,006
U 0,014 0,022 0,326 0,008 0,193 0,025 0,457 0,054 0,051 0,013
Legenda:
Média 
Variância S²

Disserta Assinatura

Enviado por

Direitos autorais:

Formatos disponíveis

Você também pode gostar

Disserta Assinatura

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

Disserta Assinatura

Enviado por

Direitos autorais:

Formatos disponíveis

Instituto Federal de Educação, Ciência e Tecnologia da Paraíba

Campus João Pessoa

ÁTILA DE SOUZA MEDEIROS

MONITORAMENTO E MEDIÇÃO DE ÁGUA EM UM

Monitoramento e medição de água em um campus inteligente

Dissertação apresentada como requisito parcial

Orientador: Profº. D.Sc. Ruan Delgado Gomes.

M488m Medeiros, Átila de Souza.

1. Medição inteligente de água 2. Metrologia - tecnologias 3.

Lucrecia Camilo de Lima

PROGRAMA DE PÓS-GRADUAÇÃO STRICTO SENSU

MESTRADO PROFISSIONAL EM TECNOLOGIA DA INFORMAÇÃO

ÁTILA DE SOUZA MEDEIROS

MONITORAMENTO E MEDIÇÃO DE ÁGUA EM UM CAMPUS INTELIGENTE COM PLATAFORMAS

Dissertação apresentada como requisito para obtenção do

Aprovado em 15 de fevereiro de 2023

Membros da Banca Examinadora:

Dr. Anderson Fabiano Batista Ferreira da Costa

Dra. Luciana Pereira Oliveira

Dr. José Antônio Cândido Borges da Silva

IFPB - Campus Campina Grande

Dr. Abel Cavalcante Lima Filho

Documento assinado eletronicamente por:

Palavras-chaves: Medição Inteligente de Água; LoRa®; Dojot; IoT.

Key-words: Smart Water Metering; LoRa®; Dojot; IoT.

Figura 1 – Principais tecnologias utilizadas na “medição inteligente de água”. Fonte:

Tabela 1 – Comparação entre alcance de sinal e consumo energético das tecnologias de

AESBE Associação Brasileira das Empresas Estaduais de Saneamento

AMQP Advanced Message Queuing Protocol

ANA Agência Nacional das Águas

Anatel Agência Nacional de Telecomunicações

API Application Programming Interface

AWS Amazon Web Services

CoAP Constrained Application Protocol

CPqD Centro de Pesquisa e Desenvolvimentoem Telecomunicações

CSS ChirpSpread Spectrum

DDS Data Distribution Service

DSR Design Science Research

EMA Erro Máximo Admissível

FSK Frequency-shift keying

GUM Guia para Avaliação da Incerteza daMedição

HTTP Hypertext Transfer Protocol

I/Os Input / Output

IDM Índice de Desempenho do Medidor

IFPB Instituto Federal de Educação, Ciência e Tecnologia da Paraíba

Inmetro Instituto Nacional de Metrologia, Qualidade e Tecnologia

IPF Índice de Perda de Faturamento

ISO International Organization for Standardization

ITB Intituto Trata Brasil

JWT JSON Web Token

Li-Po Polímero de Lítio

LoRa® Long Range

MDR Ministério do Desenvolvimento Regiona

MQTT Message Queuing Telemetry Transport

MVP Minimum Viable Product

NBR Norma Brasileira

OLED Organic Light Emitting Diode

ONU Organização das Nações Unidas