TCC JFRN Final

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE
INSTITUTO METRÓPOLE DIGITAL

PROGRAMA DE RESIDÊNCIA EM TECNOLOGIA DA INFORMAÇÃO
Argus: Dispositivo IoT para Monitoramento

de Ambientes de Infraestrutura de TI na
JFRN.
Robson da Silva Andrade
Natal-RN, Brasil
2022
Argus: Dispositivo IoT para Monitoramento de

Ambientes de Infraestrutura de TI na JFRN.
Trabalho de Conclusão de Curso apresentado

ao Programa de Residência em Tecnologia
da Informação do Instituto Metrópole Digi-
tal da Universidade Federal do Rio Grande
do Norte como requisito parcial para a obten-
ção do título de Especialista em Tecnologia
da Informação. Área de Concentração: Infra-
estrutura e redes de computadores.
Orientador: Prof. Dr. Marcos Cesar Madruga Alves Pinheiro
Natal-RN, Brasil
2022
Argus: Dispositivo IoT para Monitoramento de

Ambientes de Infraestrutura de TI na JFRN.
Trabalho de Conclusão de Curso apresentado

ao Programa de Residência em Tecnologia
da Informação do Instituto Metrópole Digi-
tal da Universidade Federal do Rio Grande
do Norte como requisito parcial para a obten-
ção do título de Especialista em Tecnologia
da Informação. Área de Concentração: Infra-
estrutura e redes de computadores.
Trabalho aprovado. Natal-RN, Brasil, 28 de julho de 2022:
Prof. Dr. Marcos Cesar Madruga Alves Pinheiro

Orientador
Prof. Msc. Wellington Silva de Souza

Examinador
Prof. Dr. Aluízio Ferreira da Rocha Neto

Examinador
Natal-RN, Brasil
2022
Dedico a minha Mãe Maria Valdete da Silva, a minha Filha Raissa Arianda da Silva
Andrade e a minha Noiva Ingrid Pereira dos Santos
Agradecimentos
Agradeço primeiramente a Deus e ao meu protetor São Miguel Arcanjo, a toda

minha família, em especial a minha Mãe, minha Filha e minha Noiva, aos amigos da equipe
de Infraestrutura da residência, a Justiça Federal e a todos os seus servidores, a todos
da coordenação e professores da UFRN / IMD e ao meu Orientador por terem tornado
possível o desenvolvimento desse trabalho, cada um contribuindo de forma imprescindível
para alcançarmos com sucesso o objetivo final.
“If you think that the internet has changed your life, think again. The IoT is about to
change it all over again!”
“Se você acha que a internet mudou sua vida, pense novamente. A IoT está prestes a
mudar tudo de novo!”
(Brendan O’Brien, Chief Architect & Co-Founder, Aria Systems.)
Resumo
Ambientes de TI são essenciais para a execução das atividades nas instituições garan-
tindo agilidade e impactando diretamente na produtividade, desempenho e qualidade no
atendimento das demandas.
Para garantir que toda essa estrutura de TI se mantenha funcional, surge a necessidade
de monitoramento em tempo real da temperatura, umidade, presença de pessoas, fumaça,
gases e fogo nos ambientes de TI na Justiça Federal do Rio Grande do Norte - JFRN/RN.
Esse trabalho visa o desenvolvimento de um dispositivo de baixo custo, nomeado nesse

projeto como Argus Monitor, utilizando a plataforma arduino e esp8266, contendo sensores
e módulos para conexão via rede wireless e cabeada.
O equipamento terá uma interface web para parametrizar os alertas através dos limites
mínimo e máximo (threshold) das variáveis ambientais, configuração das conexões de rede
e demais módulos, monitoramento em tempo real com gráficos (gauges) e Bot do Telegram
funcionando independentemente de outras plataformas e ou sistemas externos
O Argus Monitor também deverá ter a capacidade de integração com sistemas de monito-
ramento de infraestrutura de TI do NOC da JFRN, tais como Zabbix e Grafana, através
do protocolo SNMP, possibilitando coletar, manipular e gerar alertas.
Palavras-chave: Arduino, API, Bot, Datacenter, IoT, Monitoramento, Sensores, Telegram,

Zabbix.
Abstract
IT environments are essential for the execution of activities in institutions ensuring agility
and directly impacting productivity, performance and quality in meeting demands.
This work aims at the development of a low-cost device, named in this project as Argus
Monitor, using the arduino and esp8266 platform, containing sensors and modules for
wireless and wired network connection.
The equipment will have a web interface to parameterize alerts across the limits minimum
and maximum (threshold) of the environmental variables configuration of network con-
nections and other modules, real-time monitoring graphics (gauges) and Telegram Bot,
working independently of other platforms and or external systems
Argus Monitor should also have the ability to integrate with JFRN NOC IT infrastructure
monitoring systems, such as Zabbix and Grafana, through the SNMP protocol, enabling it
to collect, manipulate and generate alerts.
Keywords: Arduino, API, Bot, Datacenter, IoT, Monitoring, Sensors, Telegram, Temper-
ature, Zabbix.
Lista de ilustrações
Figura 1 – Organograma Resumido da Estrutura do Poder Judiciário Brasileiro. . 16

Figura 2 – Visão externa do container datacenter (DC1) na JFRN. . . . . . . . . . 17
Figura 3 – DC1: Corredor de racks, nobreaks, rack com equipamentos e sistema de
combate a incêndio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Figura 4 – Sala de Equipamentos de Redes - Datacenter 2 (DC2). . . . . . . . . . 18
Figura 5 – Rack do Sistema de monitoramento CMC III da Rittal Systems Ltd,
no DC1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 6 – Painéis do Centro de Operações de Redes (NOC) na JFRN. . . . . . . 19
Figura 7 – Sala de equipamentos de redes na JFRN sem monitoramento das variá-
veis ambientais. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 8 – Benefícios na Implementação de um DCIM . . . . . . . . . . . . . . . . 22
Figura 9 – Modelo Gartner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figura 10 – Arquiteturas de Computadores . . . . . . . . . . . . . . . . . . . . . . 25
Figura 11 – Componentes de um microcontrolador . . . . . . . . . . . . . . . . . . 26
Figura 12 – Tipos de encapsulamento de microcontroladores . . . . . . . . . . . . . 26
Figura 13 – Modelo de arquitetura IoT em três camadas. . . . . . . . . . . . . . . . 28
Figura 14 – Modelo de arquitetura IoT em cinco camadas. . . . . . . . . . . . . . . 29
Figura 15 – Modelo de arquitetura IoT em sete camadas. . . . . . . . . . . . . . . . 29
Figura 16 – Modelos de placas Arduino . . . . . . . . . . . . . . . . . . . . . . . . 31
Figura 17 – Logomarcas da empresa Arduino. . . . . . . . . . . . . . . . . . . . . . 31
Figura 18 – Arduino Uno: classificação quanto a origem da fabricação. . . . . . . . 32
Figura 19 – Diagrama de Portas / Pinagem / Pinos (pinout) do Arduino UNO. . . 33
Figura 20 – Comunicação - SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 21 – Dashboards Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figura 22 – Bot Telegram - Menu de Comandos . . . . . . . . . . . . . . . . . . . . 38
Figura 23 – Layout Funcionamento do Argus Monitor . . . . . . . . . . . . . . . . 41
Figura 24 – Comparação do tamanho do Megapro x Arduino Mega . . . . . . . . . 42
Figura 25 – Arduino MegaPro - Diagrama de Portas / Pinagem / Pinos (pinout) . 43
Figura 26 – Comparação das Dimensões entre Placas . . . . . . . . . . . . . . . . . 44
Figura 27 – ESP01 - Diagrama de Portas - Pinagem - Pinos . . . . . . . . . . . . . 44
Figura 28 – Sensor DHT11 - Módulo DHT11 - Especificações . . . . . . . . . . . . 45
Figura 29 – DHT11 - Componente Medição da Umidade - Eletrodos - Substrato . . 46
Figura 30 – DHT11 - Componente Medição da Temperatura - Termistor - NTC . . 46
Figura 31 – Módulo MQ-2 Detalhes . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 32 – Sensor MQ-2 - Detalhes Internos . . . . . . . . . . . . . . . . . . . . . 48
Figura 33 – Módulo HC-SR501 Detalhes . . . . . . . . . . . . . . . . . . . . . . . . 49
Figura 34 – Sensor HC-SR501 - Funcionamento . . . . . . . . . . . . . . . . . . . . 49
Figura 35 – Módulo W5500 - Detalhes . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 36 – Módulo Conversor de Nível Lógico - Detalhes . . . . . . . . . . . . . . 51
Figura 37 – Módulo Display LCD 16x2 I2C . . . . . . . . . . . . . . . . . . . . . . 52
Figura 38 – Módulo Relé 1 Canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figura 39 – Sirene Piezoelétrica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Figura 40 – LED RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figura 41 – Diagrama - Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 42 – Caixa Plástica - Prototipagem Eletrônica . . . . . . . . . . . . . . . . . 56
Figura 43 – Visão Geral Componentes . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 44 – Cases dos Sensores - Impressão 3D . . . . . . . . . . . . . . . . . . . . 57
Figura 45 – ArgusConfig - Tela Login . . . . . . . . . . . . . . . . . . . . . . . . . 61
Figura 46 – Página Inicial - ArgusMonitor - Barra de Opções . . . . . . . . . . . . 62
Figura 47 – Configuração da Interface de Rede W5500 . . . . . . . . . . . . . . . . 62
Figura 48 – Configuração do Wi-Fi - Modo Station . . . . . . . . . . . . . . . . . . 63
Figura 49 – Configuração do Modo AP . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figura 50 – Aba Config - Configuração threshold, sirenes e senha do usuário do
ArgusConfig . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Figura 51 – Telegram Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 52 – Telegram Bot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 53 – Wireshark - Detalhes dos Pacotes get-request e get-response . . . . . . 67
Figura 54 – Terminal Linux - SNMPGET . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 55 – Argus Monitor - Recebimento da requisição get-request - Monitor Serial 67
Figura 56 – Grafana - Argus Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Lista de quadros
Quadro 1 – Especificação de alguns modelos de placas Arduino . . . . . . . . . . . 30

Quadro 2 – Placa Arduino, Microcontrolador e Arquitetura . . . . . . . . . . . . . 33
Quadro 3 – Principais Diferenças - Mega 2560 Pro x Arduino Mega 2560 . . . . . 42
Quadro 4 – ESP01 - Descrição Portas - Pinagem - Pinos . . . . . . . . . . . . . . 45
Quadro 5 – Módulo HC-SR501 - Especificações . . . . . . . . . . . . . . . . . . . 49
Quadro 6 – OIDs das Variáveis Monitoradas - SNMP . . . . . . . . . . . . . . . . 66
Lista de abreviaturas e siglas
ASCII American Standard Code
AT Attention (acrônimo)
AP Access Point
API Application Programming Interface
ARM Advanced RISC Machine
BOT Robot
CLI Command-line Interface
CPU Central Processing Unit
DC Datacenter
DC Direct current - Corrente Contínua (eletricidade)
DCIM Datacenter Infrastructure Management
DHCP Dynamic Host Configuration Protocol
GLP Gás liquefeito de petróleo
GPIO General-Purpose Input/Output
GUI Graphical User Interface
HTML HyperText Markup Language
IANA Internet Assigned Numbers Authority
I2C Inter-integrated Circuit
IDE Integrated Development Environment
IMD Instituto Metrópole Digital
ICSP In Circuit Serial Programming
IC Integrated Circuit
IETF Internet Engineering Task Force
I/O Input / Output

IoT Internet of Things
IP Internet Protocol
IR Infrared
JEE Juizado Especial Estadual
JEF Juizado Especial Federal
JFAL Justiça Federal em Alagoas
JFCE Justiça Federal no Ceará
JFPB Justiça Federal na Paraíba
JFPE Justiça Federal em Pernambuco
JFRN Justiça Federal no Rio Grande do Norte
JFSE Justiça Federal em Sergipe
KB Kilobyte
LCD Liquid Crystal Display
MHZ Mega-Hertz
MIB Management Information Base
MOS Metal Oxide Semiconductor
NMS Network Management System
NOC Network Operations Center
NTC Negative Temperature Coefficient
NTP Network Time Protocol
OID Object Identifier
PCB Printed Circuit Board
PEN Private Enterprise Number
PIR Passive Infrared Sensor
PPM Partes por milhão
PWM Pulse Width Modulation

RFC Request for Comments (acrônimo)
RGB Red Green Blue
SMI Structure of Management Information
SNMP Simple Network Management Protocol
SOIC Small Outline Integrated Circuit
SPI Serial Peripheral Interface
SRAM Static Random Acess Memory
SSID Service Set Identifier
STJ Superior Tribunal de Justiça
STM Superior Tribunal Militar
TI Tecnologia da Informação
TIA Telecommunications Infrastructure for datacenters
TJ Tribunal de Justiça
TJM Tribunal de Justiça Militar
TR Turma Recursal
TRE Tribunal Regional Eleitoral
TRF Tribunal Regional Federal
TRT Tribunal Regional do Trabalho
TSE Tribunal Superior Eleitoral
TST Tribunal Superior do Trabalho
UDP User Datagram Protocol
ULA Unidade Lógica Aritmética
UFMG Universidade Federal de Minas Gerais
UFRN Universidade Federal do Rio Grande do Norte
UART Universal Asynchronous Receiver/Transmitter
USB Universal Serial Bus

Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Cenário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 Objetivos Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Objetivos Específicos . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . 21
2.1 Data Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1.1 NOC - Network Operations Center . . . . . . . . . . . . . . . . . 22
2.1.2 DCIM - Datacenter Infrastructure Management . . . . . . . . 22
2.2 Sistemas / Tecnologias Embarcadas . . . . . . . . . . . . . . . . 24
2.2.1 Arquitetura Computacional . . . . . . . . . . . . . . . . . . . . . 24
2.2.2 Microcontroladores . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Plataforma Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4.1 Arquitetura da Placa Arduino . . . . . . . . . . . . . . . . . . . . 32
2.4.2 Sensores Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.3 Módulos Arduino . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5 Protocolo SMNP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.6 Ferramentas de Monitoramento de Redes . . . . . . . . . . . . . 35
2.6.1 Zabbix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.2 Grafana . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.7 Bot Telegram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3 O DISPOSITIVO: ARGUS MONITOR . . . . . . . . . . . . . 40

3.1 Placas, Módulos e Sensores Utilizados no Projeto . . . . . . . 42
3.1.1 Placa Mega 2560 Pro . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.1.2 Placa ESP01 - ESP8266 . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.3 Módulo DHT11 - Temperatura e Umidade . . . . . . . . . . . . 45
3.1.4 Módulo MQ-2 - Gases e Fumaça . . . . . . . . . . . . . . . . . . 47
3.1.5 Módulo HC-SR501 - Sensor PIR - Presença . . . . . . . . . . . 48
3.1.6 Módulo W5500 - Rede . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.7 Módulo Conversor de Nível Lógico Bidirecional - 3.3v <-> 5v 50
3.1.8 Módulo Display 16x2 - I2C . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.9 Módulo Relé 1 canal . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.10 Sirene Piezoelétrica . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.11 Led RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2 Projeto Físico / Eletrônico . . . . . . . . . . . . . . . . . . . . . . 55
3.2.1 Montagem do Equipamento . . . . . . . . . . . . . . . . . . . . . 56
3.3 Desenvolvimento dos Softwares . . . . . . . . . . . . . . . . . . . 58
3.3.1 Firmware da Placa Arduino MegaPro 2560 . . . . . . . . . . . 58
3.3.2 Firmware da Placa ESP01 - ESP8266 . . . . . . . . . . . . . . . 59
3.3.3 Página Web de Configuração - Placa ESP01 . . . . . . . . . . . 60
3.3.4 Bot Telegram - Firmware da Placa ESP01 . . . . . . . . . . . . 64
3.4 Integração com Softwares de Monitoramento - Zabbix / Grafana 66
4 CONCLUSÃO E RESULTADOS . . . . . . . . . . . . . . . . . 69
4.1 Considerações Finais, Sugestões e Trabalhos Futuros . . . . . . 71
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
16
1 Introdução
Esse capítulo tem o objetivo de apresentar uma visão geral da JFRN e sua relevância
como instituição jurídica, detalhar a necessidade real para o desenvolvimento do projeto,
descrevendo a motivação, os objetivos gerais e específicos.
1.1 Cenário
A Justiça Federal é o órgão do Poder Judiciário que tem como missão a pacificação
dos conflitos que envolvem os cidadãos e a Administração Pública Federal, em diversas
áreas. Formada por juízes federais, que representam a primeira instância, e os Tribunais
Regionais Federais, de segunda instância, onde atuam os Desembargadores Federais, e pelos
Juizados Especiais Federais que compreende a Justiça do Trabalho, a Justiça Eleitoral e a
Justiça Militar. A Justiça Federal no Rio Grande do Norte - JFRN faz parte do Tribunal
Regional da 5ª Região, juntamente com a JFAL, JFCE, JFPB, JFPE e JFSE, Figura: 1.
As competências da Justiça Federal, sendo parte da justiça comum, e dos juízes
federais são definidas no Art. 109 da Constituição Federal Brasileira (STF, 2022):
“Art. 109. Aos juízes federais compete processar e julgar:
I — as causas em que a União, entidade autárquica ou empresa pública
federal forem interessadas na condição de autoras, rés, assistentes ou
oponentes, exceto as de falência, as de acidentes de trabalho e as sujeitas
à Justiça Eleitoral e à Justiça do Trabalho; [...]”
Figura 1 – Organograma Resumido da Estrutura do Poder Judiciário Brasileiro.
Fonte: O autor (2022)

Capítulo 1. Introdução 17
Devido a importância da instituição, da grande quantidade de dados nela processa-

dos e para garantir a disponibilidade, integridade, confiabilidade e autenticidade no acesso
aos processos, aos sistemas internos e sites que fornecem os serviços da instituição aos
servidores e cidadãos é necessário uma infraestrutura de TI que atenda tal demanda.
O container datacenter (DC1), é um dos principais ambientes de TI dessa infra-
estrutura, responsável por interligar os hosts através de conexões externas e internas,
segurança e da maior parte do processamento dos dados, conforme mostrado na Figura: 2
e 3.
Figura 2 – Visão externa do container datacenter (DC1) na JFRN.
Figura 3 – DC1: Corredor de racks, nobreaks, rack com equipamentos e sistema de combate
a incêndio.

Como parte integrante da infraestrutura existem oito salas de equipamentos de redes,

nas instalações dos prédios da instituição, contendo servidores, storages, equipamentos
de backups, ativos de redes, cabeamento estruturado e demais dispositivos responsáveis
por interligar as estações de trabalho, impressoras e demais dispositivos locais ou remotos,
sendo uma delas denominada datacenter 2, ou DC2, mostrado na Figura: 4.
Figura 4 – Sala de Equipamentos de Redes - Datacenter 2 (DC2).
Tal infraestrutura não será detalhada por motivos de segurança da instituição e

por não ser o foco desse trabalho. No DC1 é utilizado o sistema de monitoramento de
temperatura e umidade CMC III da Rittal Systems Ltd (RITTAL, 2022), mostrado nas
Figura 5, integrado ao NOC (Network Operations Center, ou traduzido para o português,
Centro de Operações de Redes), conforme a Figura: 6, e aos softwares Zabbix e Grafana.
Figura 5 – Rack do Sistema de monitoramento CMC III da Rittal Systems Ltd, no DC1.
Fonte: O autor (2022).

Figura 6 – Painéis do Centro de Operações de Redes (NOC) na JFRN.
Nas salas de equipamentos de rede e no DC2 inexiste qualquer tipo de monitora-

mento e ou controle de temperatura, umidade, presença de pessoas, fumaça, gases e fogo,
sendo algumas destas sem refrigeração ou refrigeradas por ar-condicionados do tipo split
conforme mostrado na Figura: 7.
Figura 7 – Sala de equipamentos de redes na JFRN sem monitoramento das variáveis

ambientais.

1.2 Motivação
Durante a execução da residência, entre outubro de 2020 à abril de 2022, foram
registrados alguns incidentes no DC2 e salas de equipamentos que resultaram na interrupção
e ou degradação do funcionamento da infraestrutura da rede.
Como explicitado anteriormente, não existe sistema de monitoramento nesses
ambientes. Tais problemas podem ter sidos ocasionados pelo alcance do limite mínimo e
máximo recomendável da temperatura e umidade nesses ambientes, bem como da presença
de pessoas não autorizadas, prestadores de serviços fazendo manuseio inadequado dos
equipamentos e do sistema de cabeamento estruturado, e ou devido a problemas no sistema
de refrigeração (ar-condicionado split) quando existente na sala.
Analisando esse cenário a equipe de infraestrutura verificou a necessidade do
monitoramento da temperatura, umidade, presença de pessoas, fumaça, gases e fogo
nas salas de equipamentos de rede e do DC2, sendo este último a principal motivação
do desenvolvimento desse projeto, para mitigar dessa forma, possíveis problemas que
possam gerar a indisponibilidade e ou mau funcionamento dos equipamentos de redes e
consequentemente dos sistemas da instituição.
1.3 Objetivos Gerais

O presente trabalho tem o objetivo de desenvolver um equipamento de baixo
custo, quando comparado aos equipamentos comerciais similares, para monitoramento
da temperatura, umidade, presença de pessoas, fumaça, gases e fogo, com a plataforma
arduino e esp8266, para as salas de equipamentos de redes, integrado ao NOC da JFRN
através do protocolo SNMP.
1.4 Objetivos Específicos

De modo a atingir os objetivos gerais do projeto foram elencados os seguintes
objetivos específicos:
a) Definir os componentes de hardware e software para o dispositivo de monitora-
mento (Argus Monitor);
b) Desenvolver um dispositivo de monitoramento da temperatura, umidade, pre-
sença de pessoas, fumaça, gases e fogo;
c) Demonstrar o processo de construção do dispositivo;
d) Apresentar as funcionalidades do dispositivo;
e) Executar o sistema proposto em um ambiente de estudo de caso;
f) Verificar a eficiência do dispositivo;
21
2 Referencial Teórico
Essa seção apresenta as principais referências usadas para compreensão do problema

e desenvolvimento da solução proposta.
2.1 Data Center

Segundo (VERAS, 2012), um datacenter (ou data center) é um conjunto integrado
de componentes de alta tecnologia que permitem fornecer serviços de infraestrutura de TI
de valor agregado, tipicamente processamento e armazenamento de dados, em larga escala,
para qualquer tipo de organização. Os datacenters e suas conexões formam a infraestrutura
da nuvem, quer seja pública ou privada.
A meta central de um projeto de datacenter é obter resiliência, que em TI significa
atender a demanda de negócios de maneira efetiva, reduzir o custo total de propriedade
(TCO) e tornar o negócio flexível. Os critérios a serem considerados em um projeto de
datacenter para o atingimento desta meta são: desempenho, disponibilidade, escalabilidade,
segurança e gerenciabilidade.
Com relação a instalação e construção do datacenter (VERAS, 2012), diz que o
local de instalação deve considerar uma seleção apropriada do local incluindo provimento
de energia, telecomunicações, água, gás, qualidade do ar e influências geográficas como
a possibilidade de ocorrência de tsunamis, terremotos, etc. A construção do datacenter
envolve calcular a necessidade de energia e refrigeração, cabeamento, controles de umidade
e temperatura, sistemas de prevenção contra incêndios; segurança física, espaço para os
racks e muitas vezes piso elevado.
Amplamente utilizada a norma internacional (ANSI/TIA-942, 2013) trata de
disciplinas intimamente relacionadas com o projeto de data centers, tais como: arquitetura,
comunicações, elétrica, mecânica, segurança física, segurança contra incêndios e eficiência.
Energia e Refrigeração, Temperatura e Umidade são aspectos críticos a serem
considerados no projeto de datacenters (VERAS, 2012).
• Energia e Refrigeração: o provimento de energia e refrigeração deve estar de acordo

com as premissas adotadas quando da formulação do projeto. A carga de TI e a carga
dos equipamentos que suportam a refrigeração e o seu crescimento futuro devem ser
considerados no correto dimensionamento dos componentes chaves do datacenter.
• Temperatura e Umidade: devem ser monitoradas e controladas por meio de sistemas

de climatização precisos e redundantes. Os datacenters utilizam em muitos casos
pisos elevados para possibilitar que o fluxo de ar seja insuflado para baixo dos
equipamentos, a fim de mantê-los refrigerados.
Capítulo 2. Referencial Teórico 22
2.1.1 NOC - Network Operations Center

(VERAS, 2012) define que o Centro de Operações de Redes (NOC) é local onde se
centraliza a gerência da rede e dos componentes do datacenter. A partir desse centro e
de aplicações que monitoram a rede os administradores podem saber, em tempo real, a
situação de cada componente dentro da rede.
Segundo ele, um dos aspectos fundamentais a serem considerados em termos de
segurança física com relação às instalações de um datacenter é que o NOC deve ter sistemas
de monitoramento de energia, clima, temperatura e umidade. Deve operar 24 horas por
dia e ter meios redundantes de comunicação.
2.1.2 DCIM - Datacenter Infrastructure Management

(VERAS, 2012) afirma que a função do Datacenter Infrastructure Management
(DCIM) é fazer o gerenciamento de todo o datacenter integrando infraestrutura e TI. A
proposta do DCIM é ser um único sistema para diagnosticar toda a infraestrutura de TI e
as instalações.
A gestão da infraestrutura de datacenter (DCIM) de acordo com a (POTTS, 2012),
pode ser caracterizada como um conjunto de soluções que integram as funções tradicionais
de gestão de data centers com a gestão dos ativos físicos e recursos da infraestrutura
predial, envolvendo softwares especializados, hardware e sensores, que promovem uma série
de benefícios. Para ilustrar esses pontos, considere os componentes primários da gestão de
datacenters conforme a Figura: 8.
Figura 8 – Benefícios na Implementação de um DCIM
Fonte: Michael (2012) - Traduzido pelo autor
O DCIM pode ser resumido em uma palavra: informação. Cada faceta da gestão
de datacenters gira em torno de ter informações completas e precisas e pode oferecer os
seguintes benefícios:
• Acesso a dados precisos e acionáveis sobre o estado atual e as necessidades futuras

do data center;
• Procedimentos padrão para mudanças de equipamentos;
• Única fonte de verdade para a gestão de ativos;
• Melhor previsibilidade para espaço, potência e capacidade de resfriamento significa

maior tempo para planejar;
• Maior compreensão do estado atual da infraestrutura e ambiente de energia e

refrigeração aumenta a disponibilidade geral do data center;
• Redução do custo operacional da eficácia e eficiência do uso de energia.
Um dos modelos mais utilizado para projetos DCIM é o da empresa de pesquisa e

consultoria de tecnologia da informação (GARTNER, 2012). No modelo Gartner, os
principais componentes de uma solução DCIM são a entrada, o processo e a saída.
Nesse modelo os vários sensores e entradas do usuário (Other system feeds) do
sistema compreendem a entrada (Input) os quais enviam os dados, que são processados
(process), analisados e apresentados como saída (Output) para o usuário em diferentes
formas, como por exemplo de um painel ou gráfico, e também pode ser usado como controle
sendo enviado de para o componente de entrada conforme verificamos na Figura 9.
Figura 9 – Modelo Gartner
Fonte: Cole (2013)

2.2 Sistemas / Tecnologias Embarcadas

Tecnologias embarcadas são sistemas eletrônicos e ou eletromecânicos que são
projetados para executar uma função específica. São compostos pela combinação de
hardware e software (firmware). Por exemplo: brinquedos eletrônicos, celulares, máquinas de
lavar, ar condicionado, unidades de controle automotivo e de injeção eletrônica, maquinetas
de cartão de crédito, roteadores, switchs etc (SHIBU, 2009).
Um sistema embarcado é projetado para servir ao propósito da combinação ou de
uma das seguintes tarefas:
• coleta/armazenamento/representação de dados
• comunicação de cados;
• processamento de dados (sinal);
• monitoramento;
• controle;
• interface de usuário específica do aplicativo;
2.2.1 Arquitetura Computacional

A arquitetura é o projeto conceitual e fundamental da estrutura operacional de
um sistema computacional. É o estudo dos requisitos necessários para que um sistema
computacional funcione e de como organizar os diversos componentes para obter melhores
desempenhos. A arquitetura se refere ao comportamento de um sistema computacional
visível para o programador, ou seja, aos aspectos relacionados com a execução lógica de um
programa. A organização se refere às unidades estruturais e seus relacionamentos lógicos e
eletrônicos. Na computação o termo foi adaptado para denominar a técnica de projetar e
construir computadores. Existem basicamente duas arquiteturas utilizadas desde a criação
dos computadores (STALLINGS, 2010), figura 10:
• Arquitetura de Von Neumann: Arquitetura cujo design é baseado no conceito de

sistemas computacionais de programas armazenados, utilizando uma única região
de memória para dados e instruções. Usado em computadores pessoais e pequenos
computadores. Projetada pelo famoso matemático e físico John Von Neumann em
1945 1 .
• Arquitetura de Harvard: Arquitetura onde o design é baseado no conceito de arma-

zenamento em memórias e barramentos (caminho dos sinais) independentes, tendo
uma memória exclusiva para instruções, outra exclusiva para dados e barramentos
1
<https://www.britannica.com/biography/John-von-Neumann>
da mesma forma. Inicialmente idealizada por Howard Aiken2 , na Univesidade de

Harvard em 1937 apenas como uma curiosidade acadêmica, sendo depois evoluída
criando-se a Arquitetura de Harvard Modificada (FERNANDEZ, 2015). Usado em
microcontroladores e processamento de sinais.
Resumidamente a principal diferença entre as arquiteturas são claramente notadas

com relação à memória e conjunto de instruções que estas possuem. Essas divergências
entre os modelos geram diferenças de desempenho, contudo depende de diversos fatores
como tempo de resposta para execução da tarefa e throughput (quantidade de tarefas
que a máquina pode executar de uma vez) (OLIVEIRA, 2014). Os sistemas computacio-
nais modernos utilizam modelos de arquiteturas híbridas que maximizam o desempenho
utilizando o melhor dos dois mundos das arquiteturas de Von Neumann e Harvard.
Figura 10 – Arquiteturas de Computadores
Fonte: Google (2022)
2.2.2 Microcontroladores
Segundo (KERSCHBAUMER, 2018), microcontroladores são circuitos integrados
que possuem em seu interior todos os componentes necessários ao seu funcionamento
dependendo unicamente da fonte de alimentação externa. Pode-se dizer que os microcon-
troladores são “computadores” de um único chip que podem ser programados e é composto
por processador (Unidade Lógica Aritmética - ULA), memória, portas de I/O, dispositivos
de comunicação serial dentre outros, conforme mostra a Figura 11.
2
<https://www.britannica.com/biography/Howard-Aiken>
Figura 11 – Componentes de um microcontrolador
Fonte: Kerschbaumer (2018)
Os microcontroladores são utilizados em praticamente todos os dispositivos eletrôni-

cos digitais que nos cercam, como por exemplo, centrais de alarme, teclados do computador,
monitores, discos rígidos de computador, relógio de pulso, máquinas de lavar, forno de
micro-ondas, telefones, rádios, televisores, automóveis, aviões, impressoras, marca passos,
calculadores, entre outros.
Possuem diversos tipos de encapsulamento, que é basicamente uma proteção que
envolve um circuito integrado e sua principal função é garantir a conexão segura entre
os circuitos e as placas físicas. Esta proteção é composta por pinos de metal, que fixam
um envoltório retangular feito de metal, plástico ou de outros materiais conforme visto na
Figura 12.
Figura 12 – Tipos de encapsulamento de microcontroladores
Fonte: Kerschbaumer (2018)
Microcontroladores são geralmente usados em aplicações embarcadas devendo exe-

cutar tarefas definidas de forma confiável e eficiente, com recursos baixos ou limitados. Por
isso que o modelo de arquitetura de Harvard é usado principalmente em microcontroladores:
os microcontroladores têm um pequeno programa e memória de dados que precisam ser
acessados simultaneamente. No entanto, a arquitetura Harvard nem sempre é usada em
microcontroladores; algumas famílias de microcontroladores usam modelos de arquitetura

híbrida ou Von Neumann.
2.3 Internet das Coisas

A expressão Internet das Coisas ou Internet of Things (IoT) em inglês, foi utilizada
pela primeira vez em 1999 por Kevin Ashton, como título de uma apresentação sobre
identificação por radiofrequência para executivos seniores na empresa Procter & Gamble
(VALERO, 2020).
Atualmente, estar conectado não é mais uma característica específica de determi-
nados equipamentos, mas passou a englobar uma diversidade cada vez maior de "coisas",
que também podem ser equipamentos eletrônicos do dia a dia das pessoas, como eletrodo-
mésticos, relógios, veículos, automação de casas etc. Isso foi possível graças a IoT, que
possibilitou a comunicação entre os mais diversos tipos de objetos pela internet.
De forma mais geral, (ATZORI; IERA; MORABITO, 2010) conceitua a IoT como
a presença de uma variedade de coisas ou objetos eletrônicos, identificados em uma rede,
que interagem e cooperam entre si com um objetivo em comum. Com uma visão mais
tecnológica, (MCEWEN; CASSIMALLY, 2014) sintetiza o conceito de IoT como sendo
o resultado da soma entre objetos físicos, controladores, sensores, atuadores e serviço de
Internet.
Em projetos IoT são utilizados modelos de arquiteturas que fazem referência
à prática de se dividir um protocolo em camadas, onde cada uma dessas camadas é
responsável por realizar uma tarefa específica, facilitando o entendimento, manutenção
e concepção de sistemas. Existem diversos modelos de arquitetura IoT sendo a de três
camadas e cinco camadas as duas arquiteturas mais comuns, amplamente consideradas em
negócios, pesquisa industrial e aplicações (AL-QASEEMI et al., 2016).
A arquitetura de 3 camadas (Figura 13) é formada pelas camadas de percepção,
rede e aplicação.
• Percepção (Perception): Esta é a camada física da arquitetura. Nessa camada os

sensores e dispositivos conectados disponibilizam dados à medida que os coletam
de acordo com a necessidade do projeto. Estes podem ser os dispositivos de borda,
sensores e atuadores que interagem com o ambiente.
• Rede (Network): Os dados coletados na camada de percepção precisam ser transmiti-

dos e processados. Essa é a função de camada de rede, conectando esses dispositivos
a outros objetos inteligentes, servidores, sensores, dispositivos de rede e transmitindo
todos os dados.
• Aplicação (Application): A camada da aplicação é a camada de interação com o

usuário através do fornecimento de serviços específicos por aplicativos ao usuário.
Figura 13 – Modelo de arquitetura IoT em três camadas.
Fonte: Yousuf et al. (2015)
Pode ser um monitoramento inteligente de um ambiente, por exemplo, onde os

usuários configuram uma aplicação para emitir alertas ao se atingir determinados
limites.
No modelo de arquitetura IoT em cinco camadas basicamente as camadas perception,

network e application têm as mesmas funções do modelo de três camadas existindo 2
camadas adicionais: middleware e business conforme mostrado na Figura 14.
• Middleware: Responsável pelo processamento das informações recebidas que podem

ser armazenadas e analisadas, utilizando metodologias avançadas de análise de dados.
O objetivo principal é alcançar um processo de tomada de decisão autônomo, que
possa enviar comandos de atuação de retorno para a camada de percepção (objetos
físicos), para executar ações que influenciarão nas condições gerais do ambiente físico,
como por exemplo aumentar ou diminuir a temperatura (YOUSUF et al., 2015).
• Business: Sua função é permitir que os administradores possam gerenciar e controlar

estrategicamente a funcionalidade geral da plataforma IoT. Com base nos dados
recebidos da camada de aplicativo, essa camada pode construir vários modelos de
negócios que são essenciais para o sucesso no desenvolvimento de uma tecnologia.
Um exemplo de projeto IoT bem sucedido é o da Uber uma prestadora de serviços

eletrônicos na área do transporte privado urbano através de um aplicativo mobile de
transporte que permite a busca por motoristas baseada na localização (ANTÃO et al.,
2018).
Figura 14 – Modelo de arquitetura IoT em cinco camadas.
Fonte: ANTÃO et al. (2018)
Existe um modelo de arquitetura IoT em sete camadas que segundo (SANCHEZ

et al., 2020) foi sugerida na The Internet of Things World Forum (IOTWF, 2022). Este
modelo baseia-se na premissa que os dispositivos (camada 1) enviam e recebem dados
interagindo com a rede (camada 2) onde os dados são transmitidos, normalizados e filtrados
(camada 3) antes de serem armazenados (camada 4) e estarem acessíveis (camada 5) por
aplicativos (camada 6) que os processam e fornecem para as pessoas que irão agir e
colaborar (camada 7) conforme a Figura 15.
Figura 15 – Modelo de arquitetura IoT em sete camadas.
Fonte: Sanchez et al. (2020)

2.4 Plataforma Arduino

Conforme descrito no site oficial da arduino.cc (ARDUINO, 2022a), Arduino é
uma plataforma eletrônica de prototipagem, de baixo custo, de código aberto baseada em
hardware e software fáceis de usar, capaz de ler através das portas de entrada e transformá-
la em uma saída, utilizando uma linguagem de programação baseada em Wiring (WIRING,
2022), e o Software Arduino IDE baseado em Processing (PROCESSING, 2022), dá suporte
as linguagens de programação C e C++ para o desenvolvimento das aplicações.
Um ambiente de desenvolvimento integrado, ou em inglês Integrated Development
Environment (IDE), é um software para criar aplicações que combina ferramentas comuns
de desenvolvimento em uma única interface gráfica do usuário (GUI), contendo geralmente:
editor de código-fonte, automação de compilação local, debugger entre outros utilitários
que ajudam os desenvolvedores a programar novas aplicações de forma rápida (REDHAT,
2019).
A Arduino IDE é um software oficial, de código aberto disponibilizado na Plataforma
Github , desenvolvido com a linguagem Java, pela Arduino.cc, usado principalmente para
3
escrever, compilar e carregar códigos nos módulos e placas Arduino. Está facilmente
disponível para download e instalação no site oficial da Arduino, suportando sistemas
operacionais como Windows, Linux e Mac, como também disponibiliza uma plataforma
Web Online e uma interface de linha de comando (CLI).
Oficialmente existe quase uma centena de modelos de placas da plataforma Arduino
no site oficial (em produção e descontinuadas), sendo os mais utilizados mostrados na
Figura 16 e suas especificações no Quadro 1.
Quadro 1 – Especificação de alguns modelos de placas Arduino
Fonte: Electropeak (2020) - Adaptado pelo Autor
3
Arduino IDE Versão 1.X e 2.x<https://github.com/arduino/>
Figura 16 – Modelos de placas Arduino
Fonte: (ELECTROPEAK, 2020)
Por ser uma plataforma open hardware, os diagramas esquemáticos das placas e
os códigos são lançados sob a licença CC BY-SA license e disponibilizados publicamente
(CREATIVECOMMONS, 2022). A empresa italiana Arduino é detentora de uma série de
marcas, mas não limitado somente a palavra Arduino e os logotipos oficiais como visto na
Figura 17, havendo restrições no uso da marca registrada, direitos autorais e o tipo de
licença de uso dos produtos.
Figura 17 – Logomarcas da empresa Arduino.
Fonte: Arduino (2022a)
Dessa forma, existem diversos fabricantes em todo o mundo, geralmente China e

Estados Unidos, de placas da plataforma Arduino que podem ser consideradas genéricas,
similares, clones, compatíveis ou até mesmo falsificadas por utilizar a marca indevidamente.
Existem diversas dicas de como identificar o Arduino original do falsificado, como
por exemplo no site oficial do fabricante (ARDUINO-COUNTERFEIT, 2022) e no vídeo
do Youtube A Tale of 4 Arduino Unos - Genuine, Counterfeit, Clone and Improved
(YOUTUBE, 2021).
Na Figura 18 são mostrados quatro Arduinos do modelo Uno e a classificação
segundo a origem da fabricação:
1. Arduino Original / Genuíno: Identificado pela alta qualidade da impressão da marca,

cores e componentes eletrônicos.
2. Arduino Falsificado: Identificado pelo uso indevido da marca, baixa qualidade da

impressão, cores e dos componentes.
3. Arduino Genérico / clone: Fabricado sem uso da marca e com componentes de baixa
qualidade (geralmente fabricados na China).
4. Arduino Compatível: Fabricado legalmente, sem uso da marca e com alta qualidade
dos componentes.
Figura 18 – Arduino Uno: classificação quanto a origem da fabricação.
Fonte: Youtube (2021) - Compilação do Autor
2.4.1 Arquitetura da Placa Arduino

A plataforma Arduino pode utilizar a arquitetura Von Neumann e Harvard de-
pendendo do modelo da placa e do microcontrolador utilizado. As placas Arduino são
baseadas principalmente em duas famílias de microcontroladores: AVR (MICROCHIP,
2022) e ARM (ARM, 2022). Enquanto os microcontroladores da família AVR são baseados
no modelo de arquitetura Harvard, os microcontroladores da família ARM podem ser
baseados nos modelos de arquitetura von Neuman ou Harvard. O Quadro 2 resume as
arquiteturas dos microcontroladores das placas Arduino:
O modelo Arduino UNO é a placa mais usada e documentada de toda a família
Arduino. Possui microcontrolador ATmega328P (MICROCHIP-ATMEGA328P, 2022)
de 8 bits RISC-based, disponibilizando 14 pinos de entrada/saída digital (dos quais 6
podem ser usados como saídas PWM) (ARDUINO-PWM, 2022), 6 entradas analógicas,
16 MHz de velocidade da CPU, conexão USB, conector de alimentação, conector ICSP
(ARDUINO-ICSP, 2022) e botão de reset conforme visualizado no diagrama de pinagem
(pinout em inglês) na Figura 19.
Quadro 2 – Placa Arduino, Microcontrolador e Arquitetura

Placa Microcontrolador Família Arquitetura
UNO Mini ATmega328P AVR Harvard
UNO Rev3 ATmega328P AVR Harvard
UNO WiFi Rev2 ATmega4809 AVR Harvard
Leonardo ATmega32u4 AVR Harvard
Mega 2560 Rev3 ATmega2560 AVR Harvard
Micro ATmega32u4 AVR Harvard
Zero ATSAMD21G18 ARM Cortex M0+ Von Neumann
Nicla Sense ME nRF52832 ARM Cortex M4 Harvard
Nano RP2040 Connect RP2040 ARM Cortex M0+ Von Neumann
MKR FOX 1200 ATSAMD21G18 ARM Cortex M0+ Von Neumann
MKR NB 1500 ATSAMD21G18 ARM Cortex M0+ Von Neumann
MKR WiFi 1010 ATSAMD21G18 ARM Cortex M0+ Von Neumann
MKR Zero ATSAMD21G18 ARM Cortex M0+ Von Neumann
MKR1000 WIFI ATSAMW25H18 ARM Cortex M0+ Von Neumann
MKR WAN 1300 ATSAMD21G18 ARM Cortex M0+ Von Neumann
Nano ATmega328P AVR Harvard
Nano 33 IoT ATSAMD21G18 ARM Cortex M0+ Von Neumann
Nano 33 BLE nRF52840 ARM Cortex M4 Harvard
Fonte: Arduino-Architectures (2022) - Adaptado pelo Autor.
Figura 19 – Diagrama de Portas / Pinagem / Pinos (pinout) do Arduino UNO.
Fonte: Datasheet no Site do Fabricante Arduino-Uno (2022)
2.4.2 Sensores Arduino

Sensores são dispositivos que detectam informações externas, substituindo-as na
saída por um sinal que humanos e máquinas podem distinguir. São componentes que servem
para medir um estímulo externo ao sistema no ambiente em que ele estiver (KARVINEN;
KARVINEN, 2014). Os dados de saída são baseados na medição.
Os sensores possibilitam a coleta de dados em quase todas as situações e em
vários setores como assistência médica e de enfermagem, industrial, logística, transporte,

agricultura, prevenção de desastres, turismo, segurança e muitos outros.
Neste projeto serão utilizados diversos sensores tais como: de temperatura, de
umidade, de presença de pessoas (movimento), gases, fogo e fumaça.
2.4.3 Módulos Arduino

Um módulo na plataforma Arduino é uma placa pronta para uso com um sensor ou
um dispositivo I/O. Por exemplo para usar um sensor de temperatura e umidade DHT11,
são necessários alguns componentes eletrônicos adicionais. O que um módulo Arduino faz
é integrar todos os componentes e conexões necessários para que um sensor funcione sendo
um produto pronto para uso. (ELECTRONICSHUB, 2021).
Na Figura 28, nas quatro primeiras imagem vemos o sensor DHT1 e na quinta
imagem o módulo DHT11 onde é observado que o sensor é fixado em uma PCB, com
alguns componentes eletrônicos adicionais, tais como resistores, led e pinos I/O, formando
o módulo pronto para uso. Somente o sensor, sem estar no módulo também pode ser
utilizado, contanto que se monte manualmente o circuito eletrônico necessário para o seu
funcionamento.
2.5 Protocolo SMNP

O Protocolo Simples de Gerenciamento de Redes (SNMP), ou em inglês Simple
Network Managemengt Protocol, é composto por um conjunto de operações, e as informações
que essas operações coletam, dando aos administradores de redes a capacidade de alterar
o estado e ou monitorar algum dispositivo SNMP. Qualquer dispositivo executando um
software que permita a recuperação das informações do SNMP pode ser gerenciada, desde
dispositivos físicos tais como switchs, roteadores e sensores, como também softwares, como
por exemplo servidores web e bancos de dados (MAURO; SCHMIDT, 2005).
Possui uma estrutura hierárquica, baseada na comunicação de gerentes e agentes,
não definindo quais informações pode se ter, mas utilizando uma Estrutura de Gestão
da Informação (SMI, do inglês Structure of Management Information) que fornece uma
maneira de definir os objetos gerenciados e seu comportamento. Esta lista define coletiva-
mente as informações que um sistema de monitoramento de redes (NMS, do inglês Network
Management System) pode usar para determinar o estado ou a saúde do dispositivo em
que o agente reside.
É basicamente um banco de dados de objetos gerenciados e rastreados pelos
agentes onde qualquer tipo de status ou dados estatísticos podem ser acessado pelo
gerente, denominado de Base de informações Gerenciadas (MIB, do inglês Management
Information Base). O SMI fornece uma maneira de definir objetos gerenciados enquanto o
MIB é a definição, usando a sintaxe SMI, desses objetos os quais utilizam de identificadores
de objetos (OIDs, do inglês Object Identifier) para consulta e armazenamento dessas

informações (COMER; LIMA; LIMA, 2007).
O SNMP é utilizado desde o final dos anos 80, como um protocolo que pode garantir
o trabalho em conjunto entre equipamentos de diferentes fabricantes e ou softwares de
diferentes desenvolvedores. Tipicamente o SNMP utiliza o UDP e as portas 161 para envio
e recebimento de solicitações, e a porta 162 para receber traps dos dispositivos gerenciados.
Existem três versões do protocolo SNMP: SNMPv1, SNMPv2c e SNMPv3, essa última
tenta suprir a deficiência de segurança nas duas versões anteriores.
O SNMP tem suas especificações definidas em diversas RFCs (acrônimo do inglês,
Request for Comments) publicadas pela IETF-Internet Engineering Task Force (IETF,
2022). No site SNMP Research International Inc (SNMP-RESEARCH, 2022) contém uma
lista das RFCs mais utilizadas em cada versão.
Resumidamente o protocolo SNMP apresenta três modos de comunicação:
• Get: habilita a recuperação dos dados do agente pelo gerente.
• Set: habilita a gravação de dados no agente pelo gerente.
• Trap: habilita um agente a notificar o gerente na ocorrência de algum evento relevante.
Os modos são sub-divididos em cinco operações:
• GetRequest: Solicitação por parte do gerente de um determinado dado na MIB do

agente.
• GetNextRequest: Solicitação por parte do gerente do próximo dado na MIB do agente

a partir de um endereço determinado.
• SetRequest: Solicitação de gravação dos dados na MIB do agente por parte do gerente.
• GetResponse: Resposta do agente liberando ou não o acesso por parte do gerente. As

três operações anteriormente citadas só podem ser executadas a partir do recebimento
desta resposta.
• Trap: Mensagem enviada pelo agente ao gerente na ocorrência de um evento que

afeta a MIB.
A Figura 20 mostra detalhes da comunicação entre agente e gerente usando protocolo

SNMP.
2.6 Ferramentas de Monitoramento de Redes

Muito utilizadas em NOCs existem uma grande diversidade dessas ferramentas
gratuitas ou não, complexas ou básicas. Algumas ferramentas gratuitas bastante conhecidas
são o Nagios, Cacti, Zabbix, e pagas o IMC, PRTG, Solarwinds e outras.
Figura 20 – Comunicação - SNMP
Fonte: DCC-UFMG (2022)
Fornecem informações em tempo real o status da rede ou dos dispositivos moni-

torados, para os administradores tomarem de forma proativa as decisões para mitigar
ou resolver os possíveis incidentes, otimizando a eficiência da estrutura da rede. Nesse
tópico iremos descrever sucintamente a ferramenta utilizada na JFRN e utilizada para
esse projeto.
2.6.1 Zabbix
O Zabbix é uma solução de software de nível enterprise, de código aberto, com
suporte a monitoração distribuída de numerosos parâmetros de rede, o estado e a integridade
de servidores, máquinas virtuais, aplicações, serviços, banco de dados, websites, nuvem,
sensores, dispositivos IoT entre outros. Devidamente configurado, pode desempenhar um
papel importante no monitoramento da infraestrutura de TI seja de pequenas organizações
com poucos dispositivos e para grandes empresas com centenas ou milhares de dispositivos
monitorados em NOCs (ZABBIX, 2022a).
O Zabbix usa um mecanismo flexível de notificação que permite aos usuários
configurar alertas baseados em e-mail, BOTs, aplicativos de mensagens instantâneas e
outros, para praticamente qualquer evento, oferecendo um excelente recurso de relatórios
e visualização de dados baseados em dados armazenados, através de um frontend web
que garante que o status dos objetos monitorados sejam avaliados a partir de qualquer
localização (HERNANTES; GALLARDO; SERRANO, 2015).
Foi criado no início dos anos 2000 por Alexei Vladishev (LINKEDIN, 2022).
Atualmente é desenvolvido pela Zabbix SIA (ZABBIX, 2022b), estando na versão 6.0
LTS (do inglês, Long-term Support) ou traduzindo Suporte de Longo Prazo. Escrito e
distribuído sob a GPL General Public License versão 2 (GNU-ORG, 2022), onde o código
fonte é disponibilizado para o público em geral, podendo ser baixado gratuitamente.
2.6.2 Grafana
O Grafana é uma solução de código aberto, muito utilizados em NOCs, para
executar análises de dados de séries temporais, coletados a partir do monitoramento de
aplicativos e dispositivos, com a ajuda de painéis personalizáveis (dashboards).
Uma série temporal é definida como um conjunto de observações sequenciais de
uma grandeza de interesse durante um período de tempo, assim, ela é um tipo de dados
com valores reais e de alta dimensionalidade.
O Grafana é uma ferramenta de visualização de dados que permite conectar em
diversas fontes de dados (datasources) diferentes, através de plug-ins, permitindo criar
dashboards iterativos reunindo dados de diversas fontes em um mesmo painel, podendo
mesclar dados de fontes distintas em um mesmo gráfico, facilitando a visualização e o
correlacionamento dessas informações.
Segundo o site da Empresa desenvolvedora (GRAFANA-LICENSING, 2022) o
núcleo (core), que engloba os principais projetos do Grafana é licenciado pela AGPLv3
(AGPLV3, 2022) e demais plugins, agentes e certas bibliotecas permanecerão licenciadas
pelo ApacheV2.0 (APACHE-LICENSE2, 2022) A Figura 21 mostra alguns dashboards
utilizados nos monitores do NOC da JFRN.
Figura 21 – Dashboards Grafana
Fonte: O Autor (2022)
2.7 Bot Telegram

Segundo o site do Telegram (TELEGRAM, 2022), um Bot4 Telegram é um programa
que se comporta como um parceiro de bate-papo normal com funções adicionais, sem a
necessidade de um ser humano para executar tarefas predefinidas de maneira independente.
Pode basicamente fazer tudo o que um parceiro de bate-papo humano faz, podendo
automaticamente ou a pedido do usuário, enviar mensagens de texto, imagens, vídeos e
quaisquer outros tipos de arquivos.
Uma função importante de um bot do Telegram é a possibilidade de executar
comandos como mensagens que podem corresponder a uma solicitação de informações ou
4
O termo bot é derivado do termo robô, do inglês Robot.
executar uma determinada ação. Por exemplo, é possível enviar ao bot o comando /ajuda
ou /help, e é retornado no chat em forma de texto uma lista dos possíveis comandos
definidos para iteração com esse bot. A Figura 22 mostra o perfil, a tela inicial e um chat
do Telegram com a lista dos comandos e o botão com o menu de comandos criados para o
Bot do Argus Monitor.
Figura 22 – Bot Telegram - Menu de Comandos
Os bots “normais” do Telegram não são privados podendo ser encontrado por
qualquer usuário. No entanto, os bots do Telegram só podem ser disponibilizados para os
usuários se um canal de comunicação direto com o bot for configurado. Este canal é um
grupo “privado” com o bot, ao qual pertencem somente o usuário que o criou, usuários
aprovados por ele e o bot real. Desta forma, o Bot Telegram só pode ser usado pelo grupo
de usuários controlado pelo usuário criador desse canal.
Entre diversas funcionalidades os bots podem ser usados para:
• receber notificações e notícias personalizadas, atuando como um jornal inteligente,

enviando conteúdo relevante assim que for publicado em um determinado canal;
• ser integrado com outros serviços, enriquecendo os chats do Telegram com conteúdo
de serviços externos como Bot do Gmail, bot Wiki, bot de música, bot do Youtube,
GitHubBot, etc;
• aceitar pagamentos de usuários do Telegram, oferecendo serviços pagos ou funcionar

como uma vitrine virtual;
• criar ferramentas personalizadas, fornecendo alertas, dados de sensores, previsões

meteorológicas, traduções ou outros serviços como Bot de markdown, bot de adesivos,
bot de votação, bot de curtidas etc;
• criar jogos para um ou vários jogadores, oferecendo experiências em HTML5, desde

simples arcades e quebra-cabeças até jogos de tiro em 3D e jogos de estratégia em
tempo real.
• construir redes sociais, conectando pessoas que procuram parceiros de conversa com
base em interesses comuns ou proximidade.
O Telegram disponibiliza gratuitamente uma API para que desenvolvedores possam

fazer integração com outras aplicações e a Telegram Database Library (TDLib) para
desenvolver as suas próprias aplicações.
Para criar um Bot Telegram basta acessar <https://t.me/botfather> e seguir as
instruções enviadas automaticamente pelo BotFather.
40
3 O Dispositivo: Argus Monitor
O sistema para monitoramento de ambientes de infraestrutura de TI, “batizado”

pelo autor como Argus Monitor, teve essa nomenclatura inspirada na mitologia Grega
Antiga, cujo significado é: guardião, monitorar ou vigiar.
Argus Panoptes (“Argus que tudo vê”, do inglês “Argus who sees everything”), era
um gigante cujo corpo inteiro era coberto por olhos com a função de vigiar nomeado por
Hera. Enquanto Argus dormia, metade dos seus olhos se fechavam e descansava enquanto
a outra metade continuava vigiando. Hermes, após fazer Argus adormecer ouvindo uma
melodia de sua lira, cortou sua cabeça. Hera, para honrar a morte de seu guardião favorito,
colocou os olhos de Argus Panoptes na cauda de seu pássaro favorito, o pavão (BANE,
2016).
Na sua concepção final, o Argus Monitor é um dispositivo de monitoramento com
a capacidade de ler e enviar dados das leituras dos sensores acoplados ao equipamento em
tempo real, fornecendo essas informações via protocolo SNMP ou através da sua interface
web, que disponibiliza gráficos e também tem a função de configurar os parâmetros do
monitoramento e dos módulos, conforme necessidades da instituição, não sendo necessário
alterar os softwares (firmwares) a cada mudança nessas configurações.
O sistema de monitoramento (hardware e software) Argus Monitor disponibiliza
múltiplas funcionalidades:
1. interface de rede ethernet 10/100Mbits RJ45 para conexão cabeada;
2. interface de rede sem fio 802.11b/g/n com função AP (5 clientes) e station (conectar
a um roteador e ter acessado ou ser acessado pela internet);
3. display LCD 16x2 Linhas para visualização dos dados dos sensores no próprio
equipamento;
4. alertas luminosos multicoloridos através de um LED RGB;
5. sirene Piezoelétrica 12v com potência sonora de 110db para alertar incidentes graves;
6. botão de reset no equipamento;
7. interruptor de liga / desliga;
8. sensor de temperatura e umidade com sensibilidade dentro dos padrões para monito-
ramento, amplamente utilizado no mercado;
9. sensor de gases que possibilita a detecção de GLP, álcool, propano, hidrogênio,

metano, monóxido de carbono, fumaça e consequentemente fogo (o sensor apenas
detecta mas não distingue qual gás foi detectado),
Capítulo 3. O Dispositivo: Argus Monitor 41
10. sensor de presença com capacidade de detectar movimento entre 2-3 milímetros até
7 metros em um ângulo de até 110º com a lente fresnel;
11. sensores removíveis através de plugues de encaixe rápido tipo fone de ouvido (P2);
12. cabos dos sensores com 2 metros para uma melhor disposição dentro do ambiente
monitorado;
13. fonte externa removível com plugue padrão P4 facilmente encontrado no mercado
(funciona com fontes entre 7v e 12v - 1 amp);
14. servidor web integrado para acesso via navegador web para configuração (ArgusCon-
fig) do equipamento e monitoramento por gráficos;
15. portas sobressalentes para futuras ampliações do número de sensores e módulos

(necessário alterar firmware);
16. agente SNMP para integração com qualquer software de monitoramento, através da
resposta (GetResponse) de requisições (GetRequest) e envio de traps caso atinja os
limites configurados no equipamento através do ArgusConfig;
17. Bot Telegram para o monitoramento em tempo real via aplicativo de mensagens
instantâneas, com opção de ativar ou desativar alertas e comandos pré-definidos
(necessário acesso a internet via rede sem fio);
A Figura 23 mostra o layout do Argus Monitor e suas funcionalidades.
Figura 23 – Layout Funcionamento do Argus Monitor

3.1 Placas, Módulos e Sensores Utilizados no Projeto

3.1.1 Placa Mega 2560 Pro
A placa Mega 2560 Pro, conhecida popularmente como Arduino Mega Pro, fabricado
pela empresa Chinesa Diymore (DIYMORE, 2022) é uma versão embarcada e compatível
com o Arduino Mega 2560 fabricada pela Arduino. Apesar de terem as mesmas especi-
ficações básicas como microcontrolador, quantidade de portas, e memória, apresentam
diferenças em algumas características físicas mostradas no Quadro 3.
Quadro 3 – Principais Diferenças - Mega 2560 Pro x Arduino Mega 2560

Características MegaPro Arduino Mega 2560
Dimensões 55,0mm x 38,0mm 53,33mm x 101,59mm
Porta USB Micro USB Tipo B
Conector Alimentação Não Jack P4 2,1mm
Valor em Dólar US$
US$ 18,99 US$ 44,40
(site fabricante, sem acessórios, frete e impostos)
Fonte: O Autor (2022).
Na Figura 24 é mostrado uma comparação entre os tamanhos das placas.
Figura 24 – Comparação do tamanho do Megapro x Arduino Mega
Fonte: Sites dos Fabricantes - Compilação do Autor.

Na Figura 25 é mostrado os respectivos diagramas de portas.
Figura 25 – Arduino MegaPro - Diagrama de Portas / Pinagem / Pinos (pinout)
Fonte: protosupplies (2022)
Como critérios de escolha da placa para o desenvolvimento do projeto foram

analisadas a quantidade suficiente ou maior de portas para controlar todos os sensores,
tamanho físico e valor.
3.1.2 Placa ESP01 - ESP8266

Conforme o datasheet (AI-THINKER-DATASHEET, 2022), a placa ESP01, fabri-
cado pela Chinesa Ai-Thinker (AI-THINKER, 2022), possui microcontrolador ESP8266EX
(ESPRESSIF-ESP8266, 2022) que integra um processador RISC-based Tensilica L106 de
32 bits, atinge um consumo de energia extremamente baixo e velocidade máxima de clock
de 160 MHz com o padrão em 80 Mhz. Possui conexão wireless no padrão 802.11b/g/n
com função AP (no máximo 5 dispositivos clientes se conectam nele) e station (se conectar
ao roteador aceitando múltiplas conexões), 2 portas GPIO, 1 MB de memória SPI Flash
(outros modelos podem conter até 4MB), baseado na arquitetura Harvard disponibiliza
64KB memória SRAM de instruções 64KB e 96K memória SRAM de programas e funciona
com tensão 3.3V.
Com valor médio de US$ 2,50 (não incluído frete e impostos) (ALIEXPRESS,
2022), podendo ser programado utilizando a Arduino IDE, nativamente com comandos
Hayes (AT) (ESPRESSIF-HAYES, 2022) ou utilizando a linguagem de programação LUA
e tendo dimensões de 24,7mm x 14,4mm conforme Figura 26.
Figura 26 – Comparação das Dimensões entre Placas
Na figura 27 é mostrado diagrama de portas / pinagem.
Figura 27 – ESP01 - Diagrama de Portas - Pinagem - Pinos
Fonte: Mischianti (2022)

No quadro 4 é mostrado a descrição das portas do ESP01.
Quadro 4 – ESP01 - Descrição Portas - Pinagem - Pinos

Name Type Function
VCC P Power 3.0 ∼3.6V
GND P Ground
RESET I External reset signal (Low voltage level: Active)
CH_PD I Chip Enable. High: On, chip works properly; Low: Off, small current
GPIO0(FLASH) I/O General purpose IO, low while reset/power=serial programming mode
GPIO1(TX) I/O General purpose IO and Serial TXd
GPIO3(RX) I/O General purpose IO and Serial RXd
GPIO2 I/O General purpose IO and Serial1 TXd
Fonte: Mischianti-ESP01 (2022) - Adaptado pelo Autor
3.1.3 Módulo DHT11 - Temperatura e Umidade

O módulo DHT11 contém um sensor de temperatura e umidade de baixo custo,
desenvolvido pela Chinesa Aosong (AOSONG, 2022). Segundo o site (ALIEXPRESS, 2022)
o DHT11 tem um custo médio de US$ 1,50 (não incluídos frete e impostos), saída de
sinal digital calibrado, inclui um elemento sensor capacitivo (eletrodos e substrato) para
medição da umidade e um dispositivo de medição de temperatura NTC (termistor), conta
com um microcontrolador de 8 bits de alto desempenho conectado. A Figura 28 detalha
as especificações e pinagem desse módulo.
Figura 28 – Sensor DHT11 - Módulo DHT11 - Especificações

O componente de medição da umidade tem dois eletrodos com substrato de retenção

de umidade entre eles. Os íons são liberados pelo substrato a medida que o vapor de
água é absorvido por ele, o que, por sua vez, aumenta a condutividade entre os eletrodos.
A mudança na resistência entre os dois eletrodos é proporcional à umidade relativa. A
umidade relativa mais alta diminui a resistência entre os eletrodos, enquanto a umidade
relativa mais baixa aumenta a resistência entre os eletrodos (Figura 29).
Figura 29 – DHT11 - Componente Medição da Umidade - Eletrodos - Substrato
Fonte: Lastminuteengineers-DHT11 (2022)
Para medir a temperatura contém um NTC/Termistor (Figura 30).
Figura 30 – DHT11 - Componente Medição da Temperatura - Termistor - NTC
Fonte: Lastminuteengineers-DHT11 (2022)
Um termistor é um resistor térmico cuja resistência muda com a temperatura.

O termo “NTC” significa Negative Temperature Coefficient ou traduzindo Coeficiente
de Temperatura Negativo, o que significa que a resistência diminui com o aumento da
temperatura. Dessa forma, para calcular os valores da temperatura e umidade, é aplicada a
primeira lei de Ohm: “A corrente que flui por um resistor é proporcional à tensão aplicada
e inversamente proporcional ao valor de sua resistência”.
3.1.4 Módulo MQ-2 - Gases e Fumaça

Segundo o datasheet do fabricante (WINSEN-SENSOR, 2022), o MQ-2 é um sensor
de gás do tipo metal oxide semiconductor (MOS) também conhecido como Quimiresistor,
pois a detecção é baseada na mudança de resistência do material do sensor quando entra
em contato com o gás. O sensor de gás MQ2 funciona em 5V DC e consome cerca de
800mW.
É um sensor de gás robusto adequado para detectar concentrações de GLP,
Fumaça, Álcool, Propano, Hidrogênio, Metano e Monóxido de Carbono em
qualquer lugar de 200 a 10000ppm. O sensor é sensível a vários gases, mas não identifica
qual o gás, apenas a presença e ou concentração.
Possui duas saídas sendo uma digital para retornar um valor binário (0v/5V) da
presença ou não de gases e uma saída analógica para retornar a concentração desses gases.
A tensão na saída analógica fornecida pelo sensor muda proporcionalmente à concentração
de fumaça/gás. Quanto maior a concentração de gás, maior é a tensão de saída; enquanto
a menor concentração de gás resulta em baixa tensão de saída.
Para calibrar o sensor, deve-se aproximá-lo de uma fonte fumaça/gás que deseja
detectar e girar o potenciômetro na parte traseira do módulo até que o LED vermelho
no módulo comece a acender. Girando o potenciômetro no sentido horário aumenta a
sensibilidade e no sentido anti-horário para diminuir a sensibilidade. Tem um custo médio
de US$ 2,50 não incluídos frete e impostos (ALIEXPRESS, 2022). A Figura 31 mostra
detalhes e o diagrama de pinagem.
Figura 31 – Módulo MQ-2 Detalhes
Fonte: lastminuteengineers-mq2 (2022) - Compilação do Autor (2022)

A Figura 32 mostra os detalhes do sensor MQ-2 no módulo.
Figura 32 – Sensor MQ-2 - Detalhes Internos
Fonte: lastminuteengineers-mq2 (2022)
3.1.5 Módulo HC-SR501 - Sensor PIR - Presença

Conhecido como sensor PIR (passive infrared sensor), sensor infravermelho (IR)
passivo, sensor piroelétrico ou sensor de movimento, permitem a detecção de movimentos
de objetos e corpos humanos ou de animais. Produzidos por diversos fabricantes chineses é
facilmente encontrado a venda pela internet. A quantidade de radiação IR que tais objetos
ou corpos emitem está relacionada com sua temperatura e à composição do material,
emitindo mais IR o quanto mais quente for. Os Sensores PIR são pequenos, baratos,
de baixo consumo de energia, fáceis de usar e não se desgastam. Muito utilizados em
automação residencial, em aplicações de iluminação automática e em alarmes de segurança.
Conforme o datasheet (DATASHEET-HC-SR501, 2022), o módulo HC-SR501 utiliza
um controlador de PIR BISS0001 (SC-TECH, 2022), e um par de sensores infravermelho
passivos piroelétricos (NEWTONCBRAGA, 2022), geralmente do modelo DPS101B (SC-
TECH, 2022), com uma lente de Fresnel (BRAGA, 2010) na frente, recebendo passivamente
a energia térmica que circunda no ambiente, além de um circuito amplificador para que
seja possível realizar o acionamento de dispositivos externos. Esses dois sensores ficam um
ao lado do outro e, quando o sinal diferencial entre os dois sensores muda (se uma pessoa
entrar na sala, por exemplo), o sensor será acionado.
A lente de Fresnel é utilizada na frente do sensor para concentrar de forma apropri-
ada a radiação infravermelha no sensor e possibilitar a sua detecção, também determinando
o ângulo de visão do sensor, ou seja, sua área de cobertura, o que normalmente é expresso
por uma abertura horizontal e uma abertura vertical (BRAGA, 2010). Tem um custo
médio de US$ 1,50 não incluídos frete e impostos (ALIEXPRESS, 2022).
A Figura 33 mostra detalhes do sensor, módulo, e diagrama de pinagem.
Figura 33 – Módulo HC-SR501 Detalhes
Fonte: GoogleImages (2022) - Compilação do Autor
A Figura 34 mostra resumidamente o funcionamento do sensor HC-SR501.
Figura 34 – Sensor HC-SR501 - Funcionamento
Fonte: ModuloEletronica-PIR (2022)
O Quadro 5 descreve as especificações do módulo HC-SR501.
Quadro 5 – Módulo HC-SR501 - Especificações

Módulo HC-SR501
Tensão Entrada 5V. . . 20V
Operating voltage 3.3V
Corrente repouso 50 A
Nível Saída HIGH 3.3 V / LOW 0 V
Tempo Estabilização Inicial 60s
Trigger Single trigger (L) or Repeating trigger (H)
Tempo espera 3s . . . 300s
Distância 2mm ->3m . . . 7m
Ângulo de medição <110°
Dimensões PCB 32.5 mm x 24 mm
Dimensões Lente Fresnel 15 mm x 23 mm
Fonte: Datasheet - Compilação do Autor (2022)
3.1.6 Módulo W5500 - Rede

O Módulo Ethernet W5500 é um módulo baseado no chip W5500 da WIZnet
(WIZNET, 2022) que fornece acesso à rede nos protocolos TCP, UDP, ICMP, IPv4, ARP,
IGMP, PPPoE podendo ser conectado a uma rede local ou com acesso a internet através de
um cabo de rede RJ45. Suporta velocidade de 80 MHz, até 8 sockets simultâneos, possui 10
pinos para utilização e comunicação com protocolo SPI, buffer de memória interna de 32
KB para o processamento de pacotes ethernet, velocidade 10BaseT/100BaseTX, suporta
auto Negotiation (Full and half duplex, 10 and 100-based), não suporta IP Fragmentation,
possui LEDs saída (Full/Half duplex, Link, Speed, Active), tensão de operação 3.3v / 5.0v,
dimensões(CxLxA): 58x27x15mm, conforme mostrado na Figura 35.
Figura 35 – Módulo W5500 - Detalhes
Fonte: O Autor - (2022)
Fabricado por diversas empresas chinesas é de fácil aquisição pela internet com
valor médio de US$ 5,00 não incluído frete e impostos em sites de compras internacionais
(ALIEXPRESS, 2022).
3.1.7 Módulo Conversor de Nível Lógico Bidirecional - 3.3v <->

5v
Conforme o datasheet e informações na página do produto no site da fabricante
Sparkfun (SPARKFUN-LLC, 2022), o módulo conversor de Nível Lógico Bidirecional
(3,3<->5V) é utilizado para integrar dispositivos, CIs, módulos e microcontroladores que
funcionem com tensão de nível lógico de trabalho diferentes. Alguns microcontroladores
podem operar em 3,3V e alguns módulos 5V ou vice e versa, o módulo é capaz de fazer a
conversão de sinais diminuindo o sinal de nível lógico de 5V para 3,3V (step-down) em um
sentido e também aumentando de 3,3V para 5V (step-up) no sentido inverso.
Possui dois canais com quatro pinos cada, podendo operar simultaneamente ou
isoladamente um do outro. Nos pinos centrais, os pinos HV (High Voltage 5v), GND
(terra) e LV (Low Voltage 3.3v), são as tensões de referência e esses pinos devem ser
alimentados para que o módulo funcione. Pode ser utilizado com comunicação serial, I2C,
SPI e qualquer outro sinal digital, não funcionando com sinais analógicos.
Custa em média entre US$ 1,00 e US$ 2,00 não incluídos frete e impostos (ALIEX-
PRESS, 2022).
A Figura 36 mostra detalhes e pinagem do módulo conversor de nível lógico.
Figura 36 – Módulo Conversor de Nível Lógico - Detalhes
Fonte: O Autor - (2022)
3.1.8 Módulo Display 16x2 - I2C

Segundo o site da fabricante Americana Sparkfun (SPARKFUNELECTRONICS,
2022), esse módulo consiste em um display LCD de caracteres baseado em um microcon-
trolador, Hitachi HD44780 (SPARKFUN-LCD, 2022), e um adaptador LCD I2C. O LCD
de 16x2 caracteres, possui uma luz de fundo LED (backlight) e pode exibir 32 caracteres
ASCII em duas linhas com 16 caracteres em cada linha em uma matriz de 5×8 pixels,
sendo alimentado com 5v DC.
Para controlar um display LCD 16x2 é necessário seis portas I/O, mais VCC e
GND, e que dependo do modelo da placa não terá portas suficientes ou disponíveis para
outros sensores e módulos.
O Módulo Adaptador I2C para Display LCD é um pequeno dispositivo capaz de
converter a interface paralela dos displays LCD 16 pinos em interface serial protocolo
I2C com 2 pinos. O Módulo Adaptador I2C utiliza o chip PFC8574AT, da Philips Semi-
conductors (PHILIPS-PCF8574AT, 2022), que é uma porta I/O remota de 8 bits para o
barramento I2C compatível com a maioria dos microcontroladores.
A Figura 37 mostra detalhes do display LCD 16x2 e do módulo I2C fixado na parte
traseira da PCB do display.
Figura 37 – Módulo Display LCD 16x2 I2C
Fonte: Google Images - Compilação do Autor - (2022)
3.1.9 Módulo Relé 1 canal

Um relé é basicamente um interruptor eletromagnético operado por uma corrente
relativamente pequena que pode controlar uma corrente muito maior, tendo a capacidade
de ligar ou desligar dispositivos (abrir ou fechar circuito) (DIAS; FILHO, 2008).
O módulo relé de um canal utilizado no projeto, utiliza um relé JQC-3FF-S-Z da
Fabricante chinesa Tongling e conforme a página web de especificação do produto e o
seu datasheet (TONGLING, 2022), utiliza tensão de operação entre 3,3VDC e 5VDC,
corrente de operação entre 15mA e 20mA com capacidade de 30VDC/10A e 250VAC/10.
O relé será utilizado para acionar uma sirene de alarme externa quando atingir limites
configurados no Argus Monitor (dispositivo do projeto).
A Figura 38 mostra o funcionamento básico de um relé e os seus detalhes.
Figura 38 – Módulo Relé 1 Canal
Fonte: Arduino-Relay (2022) - Compilação do Autor.

3.1.10 Sirene Piezoelétrica

Uma sirene é um componente eletrônico que baseia seu funcionamento no efeito
piezoelétrico reverso. O mesmo funciona a partir de uma diferença de potencial aplicada
que gera uma deformação mecânica variável, produzindo assim uma onda sonora, utilizada
geralmente em alarmes. É composta por um corpo plástico da sirene que acondiciona, uma
placa com um circuito eletrônico amplificador de potência, uma membrana diafragma e
um transdutor piezoelétrico.
O transdutor piezoelétrico possui uma estrutura fina em forma de disco com três
elementos fundamentais: a membrana de piezocerâmica, a folha de metal elástico de liga de
níquel e a última parte composta recoberta com o diâmetro de 24 mm de uma membrana
de solução em gel usada como um eletrodo (VIGINOSK; RIBEIRO, 2013). Aplicando-se
uma tensão no seus terminais com uma determinada frequência a célula piezoelétrica
dentro do componente irá vibrar na mesma frequência produzindo um som. A sirene
utilizada é produzida pela Empresa nacional Lookout (LOOKOUT, 2022) e funciona com
alimentação entre 4v e 12v DC.
A figura 39 mostra detalhes da sirene utilizada no projeto.
Figura 39 – Sirene Piezoelétrica

3.1.11 Led RGB

Um LED, do inglês Light Emitting Diode, significa Diodo Emissor de Luz consiste
em um chip de diodo semicondutor montado numa base refletora em forma de concha.
O chip é conectado aos terminais e o conjunto é envolto por um invólucro de plástico
transparente. São dispositivos monocromáticos com uma faixa de emissão muito estreita,
onde a cor do LED é dada pela frequência de emissão que depende dos níveis de energia
dos materiais usados. Dessa forma, os LEDs comuns podem ser obtidos em comprimentos
de onda que vão desde o infravermelho entre 830 ou 940 nanômetros, até os de menor
comprimento de ondas na faixa dos 700 aos 400 nm que correspondem as cores do espectro
do vermelho ao azul (BRAGA, 2012).
Em um LED RGB, são encapsulados três leds no mesmo dispositivo, onde cada
LED representa uma cor distinta: vermelho (Red), verde (Green) e azul (Blue) e utilizando
a combinação da intensidade de emissão de cada um pode-se obter obter qualquer cor do
espectro. Existem dois tipos de LED RGB, o difuso onde o feixe de luz possui distribuição
homogênea em todas as direções (são foscos e usados em sinalizações), e o LED RGB de
alto brilho onde o feixe de luz possui maior concentração no sentido axial, ou seja para
frente (são cristalinos e usados para iluminação). Podem ter terminal do tipo ânodo comum
(positivo) ou cátodo comum (negativo). Funcionam com as seguintes tensões: vermelho
2,0V, verde 3,2V, azul 3,2V com uma corrente 20mA.
A Figura 40 mostra detalhes dos tipos de um LED RGB e a configuração dos seus
terminais.
Figura 40 – LED RGB
Fonte: BaúdaEletronica-LED (2022) - Compilação do Autor

3.2 Projeto Físico / Eletrônico

O diagrama do projeto foi desenvolvido com o Fritzing, que é um software open-
source, multiplataforma, para desenvolvimento de protótipos de circuitos eletrônicos
(FRITZING, 2022).
Todas as placas, módulos e sensores foram escolhidos levando em consideração a
necessidade do projeto em relação às funcionalidades que o equipamento deve disponibilizar,
a adequação ao cenário atual do ambiente onde deve ser colocado em produção, existência
de bibliotecas e documentação, custos e disponibilidade destes pelo autor do projeto.
A figura 41 mostra a interligação física (pinagem) entre todos os módulos. Tal
figura não retrata a visão final do equipamento.
Figura 41 – Diagrama - Projeto
Fonte: O Autor 2022

3.2.1 Montagem do Equipamento

Para a montagem e acondicionamento dos componentes do projeto do equipamento
foi utilizado uma caixa plástica de prototipagem eletrônica (Figura 42), fios e jumpers, cola
quente, ferro de solda, solda, estilete, tesoura, alicates de corte, chaves de fenda e estrela e
demais ferramentas necessárias, seguindo exatamente o diagrama que foi desenvolvido do
circuito do projeto.
Figura 42 – Caixa Plástica - Prototipagem Eletrônica
Fonte: o Autor 2022
Também foram utilizados alguns componentes eletrônicos de conexão para tornar

os sensores facilmente acopláveis, interruptores e botões para facilitar a manipulação do
equipamento após montado, tais como (figura 43):
1. interruptor do tipo rocker para ligar/desligar o equipamento;
2. conector de fonte de alimentação do tipo jack fêmea 5.5x2.1mm 2 terminais;
3. botão do tipo reset (chave táctil, push button) 12mm 2 terminais;
4. plugue jack tipo P2 fêmea 3.5mm;
5. plugue jack tipo P2 macho 3.5mm;

Figura 43 – Visão Geral Componentes
Fonte: o Autor 2022
Foram baixados projetos de cases do site Thingverse para impressão em 3D

para o acondicionamento dos sensores DHT11 (THINGIVERSE-DHT11, 2022), MQ2
(THINGIVERSE-MQ2, 2022) e HC-SR501 (THINGIVERSE-HCSR501, 2022). A Figura
44 mostra detalhes dos cases e dos sensores.
Figura 44 – Cases dos Sensores - Impressão 3D
Fonte: o Autor 2022

3.3 Desenvolvimento dos Softwares

Para o controle de todo o Sistema de Monitoramento Argus foram desenvolvidos
firmwares, para as placas Arduino MegaPro e ESP01, utilizando a Arduino IDE (ARDUINO,
2022b) e a linguagem de programação C++, páginas web para configuração do equipamento
e monitoramento, armazenados na placa ESP01 utilizando as linguagens HTML (W3-
HTML, 2022), JavaScript (MOZILLA-JAVASCRIPT, 2022), CSS (W3-CSS, 2022), os
componentes do Bootstrap (BOOTSTRAP, 2022) e do Canvas Gauges (CANVAS-GAUGE,
2022).
Não serão disponibilizados nesse trabalho os códigos fontes e nem o detalhamento
dos softwares desenvolvidos para não comprometer a segurança de toda a infraestrutura
de TI da Instituição. Todo o código e detalhamento será disponibilizado dentro da infra-
estrutura interna, utilizando uma plataforma de hospedagem de código fonte e arquivos
com controle de versão usando o GitLab (GITLAB, 2022), que é utilizada como padrão
na JFRN.
3.3.1 Firmware da Placa Arduino MegaPro 2560

O firmware será responsável pelo controle de todos os sensores envolvidos, pois
disponibiliza a quantidade de portas necessárias, com algumas sobressalentes no caso
de possíveis expansões, para conectar todos os módulos. Assim, segue uma lista de
funcionalidades desenvolvidas para o firmware:
• Conexão ethernet através do módulo W5500 com a rede cabeada e gerar automatica-
mente o endereço MAC LAA (locally administered addresses) (MACADDRESS-IO,
2022), ou traduzindo endereço administrados localmente, pois o módulo não tem
MAC gerado pelo fabricante.
Um endereço administrado localmente é atribuído a um dispositivo por um admi-
nistrador de rede, substituindo o endereço gerado pelo fabricante da placa. Neste
tipo de endereço o segundo bit menos significativo do primeiro octeto do endereço
é 1. Dessa forma, existem 4 intervalos de intervalos de endereços administrados
localmente que podem ser usados em uma rede local:
1. x2-xx-xx-xx-xx-xx
2. x6-xx-xx-xx-xx-xx
3. xA-xx-xx-xx-xx-xx
4. xE-xx-xx-xx-xx-xx
Onde x pode ser substituído por qualquer valor hexadecimal.
• leitura dos sensores: temperatura e umidade (DHT11), presença (PIR), Gases e

Fumaça (MQ2);
• controle do display LCD 1602 mostrando em tempo real os dados dos sensores;
• envio de traps e respostas das requisições SNMP feitas pelo Zabbix e ou outro
software de monitoramento;
• acionamento da Sirene caso atinja os limites configurados;
• envio dos dados da leitura dos sensores para a placa ESP01 no formato JSON via
interface serial (RX/TX) em intervalos de tempo definidos na configuração;
• Receber as configurações, salvas no formato JSON, da placa ESP01 via interface

serial (RX/TX) em intervalos de tempo definidos na configuração;
Para o desenvolvimento do firmware foram utilizadas as bibliotecas para o controle dos

respectivos módulos e ou funções:
• módulo Rede W5500: Biblioteca Ethernet_Generic (ETHERNET-LIBRARY, 2022);
• módulo Display LCD1602 I2C: Biblioteca LiquidCrystal_I2C (LCD1602-LIBRARY,

2022);
• sensor DHT11: Biblioteca DHT-sensor-library (DHT11-LIBRARY, 2022);
• sensor MQ2: Biblioteca MQSensorsLib (MQ2-LIBRARY, 2022);
• JSON: Biblioteca ArduinoJson (JSON-LIBRARY, 2022);
• NTP: Biblioteca NTPClient (NTP-LIBRARY, 2022). Atualiza a hora através do

servidor NTP(Network Time Protocol);
• SNMP: Biblioteca Arduino_SNMP (SNMP-LIBRARY, 2022);
• sensor PIR: O Sensor envia pela porta de saída um sinal identificando se detectou
presença (HIGH/5V) ou não (LOW/0V).
3.3.2 Firmware da Placa ESP01 - ESP8266

Ao contrário da placa Arduino MegaPro, a placa ESP01 possui uma memória
interna maior (1MB) capaz de armazenar dados através de um sistema de arquivos, o
LittleFS (LITTLEFS, 2022), sendo utilizada para ser a controladora das configurações do
Sistema Argus e onde serão armazenadas as páginas web. O firmware contém as seguintes
funcionalidades:
• servidor web: Responder as requisições enviando as páginas web e ou os arquivos

solicitados.
• memória: Armazenamento na memória flash de todos os arquivos necessários para

configuração do equipamento e todo o Sistema Argus, nesse projeto denominado de
ArgusConfig (páginas web, imagens, arquivos de configuração JSON, javascript, CSS
e demais).
• JSON: Receber e processar o arquivo JSON contendo as leituras dos sensores enviado
pela placa MegaPro. Enviar o arquivo de configuração JSON para a placa MegaPro.
• Bot Telegram: Enviar informações sobre os sensores em tempo real através do

aplicativo de mensagens Telegram 1 .
Para o desenvolvimento do firmware foram utilizadas as bibliotecas para o controle dos

respectivos módulos e ou funções:
• bot telegram: Biblioteca Universal-Arduino-Telegram-Bot (TELEGRAMBOT-LIBRARY,

2022);
• servidor web: Biblioteca ESP8266WebServer (WEBSERVER-LIBRARY, 2022);
• wi-fi: Biblioteca ESP8266WiFi (WIFI-LIBRARY, 2022);
• sistema de arquivos: Biblioteca LittleFS (LITTLEFS-LIBRARY, 2022);
• JSON: Biblioteca bblanchon /ArduinoJson (JSON-LIBRARY, 2022). Ler, gerar e

enviar dados no formato JSON.
• NTP: Biblioteca arduino-libraries/NTPClient (NTP-LIBRARY, 2022). Atualiza a

hora através do servidor NTP(Network Time Protocol);
3.3.3 Página Web de Configuração - Placa ESP01

Denominado nesse projeto de ArgusConfig o conjunto de páginas web responsáveis
pela configuração do equipamento disponibilizando as seguintes funcionalidades:
• modo AP: Rede sem fio padrão, para dispositivos clientes se conectarem e terem
acesso ao ArgusConfig (no máximo 4 conexões simultâneas). No firmware está
configurada como padrão um SSID (service set identifier), que é a identificação da
rede sem fio do Argus Monitor e uma senha (chave da rede) que poderá ser alterada
na interface ArgusConfig: SSID=argus (não configurável) e chave da rede=argus
(configurável).
• tela login: Acessado através do navegador web com o endereço IP da conexão no

modo AP ou o IP da conexão no modo station do Argus Monitor. Apresenta controle
de acesso com login e senha padrão que poderá ser alterada na interface ArgusConfig:
1
<https://telegram.org/>
usuário=argus (não configurável) e senha=argus (configurável), conforme mostrado

na Figura 45.
Figura 45 – ArgusConfig - Tela Login
Fonte: o Autor 2022
• página inicial - Barra de Opções: É disponibilizada no topo de todas as abas uma

barra com botões deslizantes com as opções: DHCP/IP Fixo, Sirene ON/OFF, Wi-Fi
ON/OFF (modo station). A Figura 46 mostra a barra em destaque.
• Argus: Aba da página inicial que mostra gráficos em tempo real das leituras dos
sensores enviadas pela placa MegaPro. A Figura 46 mostra essa funcionalidade.
Figura 46 – Página Inicial - ArgusMonitor - Barra de Opções
Fonte: o Autor 2022
• LAN: Aba de configuração da interface de rede cabeada (W5500), com opção de

atribuição de IP automático através do servidor DHCP da rede local ou IP fixo
configurado pelo usuário. Opção selecionável através da opção DHCP / IP Fixo
da barra de botões deslizantes. Na opção DHCP o IP é atualizado após salvar a
configuração, conforme visto na Figura 47.
Figura 47 – Configuração da Interface de Rede W5500
Fonte: o Autor 2022
• wi-fi: Modo Station, funcionalidade do Argus Monitor se conectar em uma rede

sem fio da instituição, com botão de scan das redes disponíveis no alcance. Após
conectado pode ser ser acessado através do IP atribuído ou através da internet caso
seja permitido pelas regras de acesso da rede local, mostrado na Figura 48.
Figura 48 – Configuração do Wi-Fi - Modo Station
Fonte: o Autor 2022
• AP: Modo AP para configuração da chave da rede (senha) para conectar ao SSID
emphargus para acesso ao ArgusMonitor, mostrado na Figura 49.
Figura 49 – Configuração do Modo AP
Fonte: o Autor 2022
• config: Aba de configuração dos limites (threshold), acionamento da sirene caso

os limites sejam ultrapassados, dos sensores da temperatura, umidade, presença,
gases/fumaça, da senha do usuário da interfaceweb ArgusConfig, do tempo de

atualização das leituras para os gráficos do ArgusMonitor, e botões de reiniciar o
equipamento (reboot) e restaurar a configuração padrão. A Figura 50 mostra os
detalhes dessas configurações.
Figura 50 – Aba Config - Configuração threshold, sirenes e senha do usuário do ArgusConfig
Fonte: o Autor 2022
3.3.4 Bot Telegram - Firmware da Placa ESP01

Os Bots Telegram @ArgusMonitorBot e o @argustelebot foram desenvolvidos
com o intuito de disponibilizar mais uma forma de monitorar em tempo real os sensores
do Argus Monitor independentemente de sistemas de monitoramento ou do local que os
administradores da rede estejam. Para isso é necessário que a interface de rede sem fio
do Argus Monitor esteja conectado a um roteador ou ap com acesso a internet e uma
conta no aplicativo do Telegram para o recebimento automático de mensagens de alertas
ou status dos sensores.
A Figura 51 mostra telas do chat do ArgusBot com as respectivas respostas dos
comandos: /status que mostra os valores das leituras dos sensores e o status dos alertas
(ON/OFF), /monitor que habilita o envio automático do Argus Status, independente-
mente dos limites configurados no ArgusConfig, a cada período de tempo definido pelo
comando /timer=X (onde X=tempo em segundos).
Figura 51 – Telegram Bot
Fonte: o Autor 2022
Na Figura 52 é mostrado o resultado do comando /alerta que habilita o envio

automático do Argus Alerta para o sensor que tenha ultrapassado os limites configurado
no ArgusConfig.
Figura 52 – Telegram Bot
Fonte: o Autor 2022

3.4 Integração com Softwares de Monitoramento -

Zabbix / Grafana
O Sistema Argus Monitor é um Agente SNMP onde tem a função de responder
(get-response) as requisições (get-request) que podem ser feitas por qualquer software que
tenha a capacidade de integração com esse protocolo.
Para isso é necessário a definição de uma OID para cada variável monitorada que
pode ser lida ou escrita.
O uso de OIDs únicos, mundialmente, para equipamentos em instituições privadas
podem ser registrada sem custos, fazendo-se uma requisição de um número de empresa
privada, do inglês Private Enterprise Number(PEN) request, no site da IANA (IANA,
2022).
Após a liberação pela IANA deve-se fazer o registro desse número utilizando as
definições para o protocolo SNMP e criação de OIDs no site OID Repository (OID-INFO,
2022).
Para o projeto foi solicitado utilizando-se o cadastro do autor como Microempre-
endedor Individual (MEI), sendo liberado o PEN 59077 o qual foi cadastrado no OID
Repository o First Registration Authority (FRA), ou traduzindo para o português Primeira
Autoridade de Registro, a OID 1.3.6.1.4.1.59077.
Dessa forma, o projeto utilizará de OIDs registradas, para não haver duplicação
caso seja utilizado uma criada aleatoriamente que coincida com a OID de equipamentos
que estejam na rede e assim gerar problemas na leitura desses dados pelos sistemas de
monitoramento.
Assim tal OID será utilizada temporariamente nesse projeto conforme mostrado
no quadro 6:
Quadro 6 – OIDs das Variáveis Monitoradas - SNMP

Variável OID
Temperatura 1.3.6.1.4.1.59077.1.0
Umidade 1.3.6.1.4.1.59077.2.0
Presença de Pessoas 1.3.6.1.4.1.59077.3.0
Gases/Fumaça/Fogo 1.3.6.1.4.1.59077.4.0
Fonte: O Autor (2022).
A nível de demonstração da resposta (get-response) pelo Argus Monitor, será

aqui utilizado o software Wireshark para captura dos pacotes (WIRESHARK, 2022),
SNMPGET para o envio da requisição (get-request) e do monitor serial da Arduino IDE
para mostrar a requisição chegando ao equipamento, todos na versão Linux.
A Figura 53 mostra detalhes dos pacotes get-request e do get-reponse, capturados
pelo Wireshark.
Figura 53 – Wireshark - Detalhes dos Pacotes get-request e get-response
Fonte: o Autor 2022
Na Figura 54 é mostrado as requisições feitas pelo SNMPGET.
Figura 54 – Terminal Linux - SNMPGET
Fonte: o Autor 2022
Na Figura 55 é verificado o recebimento da requisição pelo equipamento Argus

Monitor.
Figura 55 – Argus Monitor - Recebimento da requisição get-request - Monitor Serial
Fonte: o Autor 2022
Para o monitoramento através do Zabbix, ou de qualquer outro software de moni-

toramento, deve-se fazer a criação do host, geralmente utilizando o seu IP, bem como dos
itens monitorados, configurando conforme as OIDs implementadas no projeto e seguindo

a especificação padrão para a integração do software com o equipamento via SNMP. Da
mesma forma aplica-se ao software Grafana que disponibiliza inúmeras funcionalidades e
uma grande diversidade de tipos de gráficos conforme a necessidade da instituição.
A Figura 56 mostra alguns gráficos que foram criados para esse projeto.
Figura 56 – Grafana - Argus Monitor
Fonte: o Autor 2022

69
4 Conclusão e Resultados
O projeto Argus Monitor: Dispositivo IoT para Monitoramento de Ambi-

entes de Infraestrutura de TI na JFRN teve o objetivo de desenvolver um dispositivo
de baixo custo, flexível, escalável, privativo e com a capacidade de atender a demanda da
instituição com relação a necessidade de monitoramento dos ambientes de infraestrutura
de TI, para evitar ou mitigar possíveis interrupções ou degradação da performance de
toda a estrutura computacional.
O projeto foi iniciado como uma atividade paralela, sem prioridade, às demandas
dos trabalhos da residência na JFRN. Começou com uma simples sugestão, por parte
de um servidor integrante da equipe de infraestrutura responsável por tais ambientes na
instituição, de se ter uma placa Arduino, um sensor de temperatura e umidade (DHT11)
e uma sirene que fosse acionada caso os limites aceitáveis fossem ultrapassados. Os limites
seriam fixos e só poderiam ser modificados, com a alteração e compilação do código,
atualizando o firmware na placa.
Durante o desenvolvimento do projeto o autor verificou a possibilidade e a necessi-
dade da ampliação desses recursos que aos poucos foram sendo desenvolvidos em módulos
separados para testes que em uma próxima etapa foram sendo unificados em um produto
final.
Devido ao tempo disponibilizado para o desenvolvimento de todos os módulos e
a complexidade que tomaram proporções bem maiores do que as iniciais do projeto e a
residência estava no seu curso final, todos os testes foram feitos em ambientes pessoais do
autor tentando simular as condições da JFRN.
Durante os testes foram constatadas as seguintes observações:
• o baixo custo final conhecido mundialmente, que é um dos objetivos da plataforma

Arduino e comprovado pelo valor dos itens eletrônicos utilizados, é extremamente
viabilizada quando quando comparado com o valor da solução utilizada no datacenter
da instituição e com outros produtos similares;
• o sensor DHT11 de temperatura e umidade funcionou de maneira estável e com

precisão adequada ao projeto. Para comparação nos testes pois utilizado o sensor
DSB1820 (MAXIMINTEGRATED-DS18B20, 2022), onde foi constatado uma dife-
rença em alguns momentos na faixa de 1% para cima ou para baixo entre a leitura
dos dois sensores.
• o sensor de movimento apresentou uma divergência com relação às suas especificações

alcançando no máximo um pouco mais de 5 metros e não 7 metros como especificado
no datasheet, mas que tal diferença não inviabiliza o seu uso devido o tamanho dos
Capítulo 4. Conclusão e Resultados 70
ambientes e a possibilidade de disposição do sensor conforme necessidade em cada

local.
• a conexão de rede cabeada com o módulo W5500 foi extremamente estável não sendo
percebida a perda de conexão durante o seu uso e com velocidade (10/100Mbits)
adequada para o tráfego que irá usar.
• a conexão de rede Wi-Fi do ESP8266 padrão 802.11b/g/n não alcança as velocidades

máximas especificadas nesses padrões e tem um baixo alcance na detecção das redes
disponíveis devido ao tamanho da antena na PCB (trilha metálica na placa). A
velocidade da conexão também não inviabiliza o projeto pois essa interface será
utilizada geralmente para a configuração do equipamento.
• o sensor de gases MQ2 apresentou um bom nível de detecção de GLP, fumaça e CO2.
Para os testes foram utilizados gás butano de um isqueiro, papel, madeira e plásticos
foram queimados para a geração de fumaça que pode conter monóxido / dióxido
de carbono e outros gases. A sensibilidade do sensor pode ser ajustada através de
potenciômetro localizado atrás do módulo.
• as placas MegaPro e ESP01 apresentaram uma excelente estabilidade e desem-

penho pois durante os testes não apresentaram travamentos e ou reinicializações
significativas.
• demais módulos: display LCD, relé, LED e fonte não foram observadas nenhuma
ocorrência de parada ou mal funcionamento.
• Aa bibliotecas utilizadas no desenvolvimento do firmware cumprem com a função de

controlar os módulos correspondentes sem problemas aparentes.
Analisando o contexto geral de todos os componentes que formam o produto final

desenvolvido, Argus Monitor, pode-se concluir primariamente que o equipamento é
totalmente viável com relação aos custos, desempenho, funcionalidades e tendo a capacidade
de monitorar os ambientes de infraestrutura de TI ou de quaisquer ambientes, onde se
tenha necessidade de um controle em tempo real da temperatura, umidade, presença de
pessoas, gases/fumaça/fogo, evitando ou dando a possibilidade da mitigação proativa por
parte das equipes responsáveis para se manter o funcionamento da infraestrutura de redes
na JFRN.
4.1 Considerações Finais, Sugestões e Trabalhos Fu-

turos
A conclusão primária da viabilidade do Argus Monitor, deve ser comprovada e
homologada através de testes mais apurados e dentro dos ambientes da instituição para se
garantir que o dispositivo atenderá a demanda.
Devido à complexidade do projeto seria necessário um tempo maior para todo
o planejamento, desenvolvimento, alterações, testes, homologação e detalhamento mais
apurado e descrito nesse documento.
Conforme explanado foram adicionadas ao projeto inicial diversas novas funcionali-
dades e identificadas outras que podem ser implementadas futuramente para propiciar uma
maior segurança, estabilidade, facilidade na montagem do equipamento e desenvolvimento
do firmware:
1. adicionar módulos de sensores infravermelhos receptor e emissor no Argus Monitor.

Desenvolver no firmware a capacidade de clonar os comandos do controle remoto
do ar-condicionado. Implementar a funcionalidade de automação do controle da
temperatura, aumentando, diminuindo, ligando ou desligando o ar-condicionado a
partir dos parâmetros (mínimo e máximo) configurados no ArgusConfig.
2. criar uma PCB (placa) única com os módulos, microcontroladores, conexões de rede
e plugues para os sensores on-board, eliminando a necessidade do uso de grande
quantidade de fios, jumpers e soldagem destes nas placas.
3. criar bibliotecas próprias fazendo o fork (cópia) das utilizadas no projeto corrigindo
possíveis problemas e reduzindo o código utilizado;
4. utilizar um módulo de conexão de rede sem fio mais estável e com maior velocidade.
5. Adicionar sensores com conexão sem fio, wi-fi, rádio, bluetooth ou outra que possibilite
a disposição desses sensores em diversos pontos do ambiente.
6. criar um API para configuração do equipamento e leitura dos sensores;
7. atualizar a biblioteca SNMP para a versão SNMPv3.
8. projetar uma case própria com encaixes para os plugues, placas e componentes
utilizados.
9. criar uma versão do dispositivo com a função de um SNMP manager para controlar
diversos módulos em outros ambientes conectados pela rede com ou sem fio.
10. implementar no firmware a funcionalidade OTA, do inglês over-the-air, que é a

atualização do firmware (sketch) através da rede sem fio ou cabeada (OTEthernet),
sem a necessidade da conexão física USB para esse processo.
11. opção de configurar a OID para cada sensor pelo ArgusConfig.
12. implementação de HTTPS nas páginas de configuração do Argus Monitor.

73
Referências
AGPLV3. 2022. Disponível em: <https://github.com/grafana/grafana/blob/

c2aee2b6dadcb7fad86e54a79d300b3abe36c062/LICENSE>. Citado na página 37.
AI-THINKER. 2022. Disponível em: <http://www.ai-thinker.com/>. Citado na página

43.
AI-THINKER-DATASHEET. 2022. Disponível em: <https://docs.ai-thinker.com/

_media/esp8266/docs/esp-01_product_specification_en.pdf>. Citado na página 43.
AL-QASEEMI, S. A. et al. IoT architecture challenges and issues: Lack of

standardization. In: 2016 Future Technologies Conference (FTC). San Francisco,
CA, USA: IEEE, 2016. p. 731–738. ISBN 9781509041718. Disponível em:
<http://ieeexplore.ieee.org/document/7821686/>. Citado na página 27.
ALIEXPRESS: AliExpress - Online Shopping for Popular Electronics, Fashion, Home

& Garden, Toys & Sports, Automobiles and More products. 2022. Disponível em:
<https://www.aliexpress.com>. Citado 6 vezes nas páginas 43, 45, 47, 48, 50 e 51.
ANSI/TIA-942. 2013. Disponível em: <https://tiaonline.org/products-and-services/

tia942certification/ansi-tia-942-standard/>. Citado na página 21.
ANTÃO, L. et al. Requirements for testing and validating the industrial internet of things.
In: . [S.l.: s.n.], 2018. Citado 2 vezes nas páginas 28 e 29.
AOSONG. 2022. Disponível em: <http://www.aosong.com/en/products-21.html>.

Citado na página 45.
APACHE-LICENSE2. 2022. Disponível em: <https://www.apache.org/licenses/

LICENSE-2.0>. Citado na página 37.
ARDUINO. 2022. Disponível em: <https://www.arduino.cc/>. Citado 2 vezes nas

páginas 30 e 31.
ARDUINO. 2022. Disponível em: <https://www.arduino.cc/en/software>. Citado na

página 58.
ARDUINO-ARCHITECTURES: Arduino Memory Guide | Arduino Documentation. 2022.

Disponível em: <https://docs.arduino.cc/learn/programming/memory-guide>. Citado
na página 33.
ARDUINO-COUNTERFEIT. 2022. Disponível em: <https://support.arduino.cc/hc/

en-us/articles/360020652100-How-to-spot-a-counterfeit-Arduino>. Citado na página 31.
ARDUINO-ICSP: Entendendo os 6 pinos de icsp dos arduinos. 2022. Disponível em:

<https://br-arduino.org/2015/05/arduino-icsp-attiny-atmega.html>. Citado na página
32.
ARDUINO-PWM. 2022. Disponível em: <https://www.arduino.cc/en/Tutorial/

Foundations/PWM>. Citado na página 32.
Referências 74
ARDUINO-RELAY. 2022. Disponível em: <https://arduinogetstarted.com/tutorials/

arduino-relay>. Citado na página 52.
ARDUINO-UNO. 2022. Disponível em: <https://docs.arduino.cc/resources/datasheets/

A000066-datasheet.pdf>. Citado na página 33.
ARM: Defining the Future of Computing. 2022. Disponível em: <https://www.arm.com/>.

ATZORI, L.; IERA, A.; MORABITO, G. The Internet of Things: A survey. Computer
Networks, v. 54, n. 15, p. 2787–2805, out. 2010. ISSN 13891286. Disponível em:
<https://linkinghub.elsevier.com/retrieve/pii/S1389128610001568>. Citado na página
27.
BANE, T. Encyclopedia of giants and humanoids in myth, legend and folklore. Jefferson,
North Carolina: McFarland & Company, Inc., Publishers, 2016. ISBN 9781476663517.
BAúDAELETRONICA-LED. 2022. Disponível em: <https://blog.baudaeletronica.com.

br/leds-rgb/>. Citado na página 54.
BOOTSTRAP. 2022. Disponível em: <https://getbootstrap.com/>. Citado na página

58.
BRAGA, N. C. As lentes de Fresnel (ART148). 2010. Disponível em: <https://www.

newtoncbraga.com.br/index.php/como-funciona/1024-as-lentes-de-fresnel-art148.html>.
BRAGA, N. C. LEDS - A iluminação do futuro (EL042). 2012. Disponível em:

<https://newtoncbraga.com.br/index.php/novas-tecnologias/6411-el042.html>. Citado
na página 54.
CANVAS-GAUGE. 2022. Disponível em: <https://canvas-gauges.com/>. Citado na

página 58.
COLE, D. Data Center Infrastructure Management (DCIM). 2013. Disponível em:

<https://files.vogel.de/vogelonline/vogelonline/files/5805.pdf>. Citado na página 23.
COMER, D. E.; LIMA, l. S. d.; LIMA, J. V. d. Redes de computadores e Internet:

abrange transmiss??o de dados, liga????es inter-redes, Web e aplica????es. Porto Alegre:
Bookman, 2007. OCLC: 230895739. ISBN 9788560031368. Citado na página 35.
CREATIVECOMMONS. 2022. Disponível em: <https://creativecommons.org/licenses/

by-sa/3.0/legalcode>. Citado na página 31.
DATASHEET-HC-SR501. 2022. Disponível em: <https://www.mpja.com/download/

31227sc.pdf>. Citado na página 48.
DCC-UFMG. 2022. Disponível em: <https://homepages.dcc.ufmg.br/~mlbc/cursos/

internet/snmp/imgs/snmp.gif>. Citado na página 36.
DHT11-LIBRARY. 2022. Disponível em: <https://github.com/adafruit/

DHT-sensor-library>. Citado na página 59.
Referências 75
DIAS, Y.; FILHO, P. Acionamento de Potência para rede de automação wireless.

Faculdade de Tecnologia, Universidade de Brasília, 2008. Disponível em: <http://www.ene.
unb.br/adolfo/Monographs/Graduation/TG08PedroR.MateusFilhoeYuriF.G.Dias.pdf>.
DIYMORE. 2022. Disponível em: <https://www.diymore.cc/>. Citado na página 42.
ELECTRONICSHUB: List of Arduino Compatible Module | Arduino Modules List. 2021.

Disponível em: <https://www.electronicshub.org/arduino-modules-list/>. Citado na
página 34.
ELECTROPEAK: Arduino buying guide 2020: Complete guide to cho-

ose the right board. 2020. Disponível em: <https://electropeak.com/learn/
arduino-buying-guide-how-to-choose-right-arduino-board/>. Citado 2 vezes nas páginas
30 e 31.
ESPRESSIF-ESP8266. 2022. Disponível em: <https://www.espressif.com/en/products/

socs/esp8266>. Citado na página 43.
ESPRESSIF-HAYES. 2022. Disponível em: <https://pt.wikipedia.org/wiki/Comandos_

Hayes>. Citado na página 43.
ETHERNET-LIBRARY. 2022. Disponível em: <https://github.com/khoih-prog/

Ethernet_Generic>. Citado na página 59.
FERNANDEZ, M. P. Arquitetura de Computadores. 3. ed.. ed. Fortaleza - Ceará: EdUECE,

2015. ISBN 9788578264123. Disponível em: <https://educapes.capes.gov.br/bitstream/
capes/177823/2/Livro_Computacao_Arquitetura%20de%20Computadores.PDF>.
FRITZING. 2022. Disponível em: <https://fritzing.org/>. Citado na página 55.
GARTNER: Delivering actionable, objective insight to executives and their teams. 2012.
Disponível em: <https://www.gartner.com/en>. Citado na página 23.
GITLAB. 2022. Disponível em: <https://about.gitlab.com/>. Citado na página 58.
GNU-ORG. 2022. Disponível em: <https://www.gnu.org/licenses/old-licenses/gpl-2.0.

html.en>. Citado na página 36.
GOOGLE: John von Neumann | Biography, Accomplishments, Inventions, & Facts |

Britannica. 2022. Disponível em: <https://i0.wp.com/www.currentschoolnews.com/
wp-content/uploads/2020/03/Von-Neuman-Vs-Harvard-Architecture.png?w=497&ssl=
1>. Citado na página 25.
GOOGLEIMAGES. 2022. Disponível em: <https://images.google.com/>. Citado na

página 49.
GRAFANA-LICENSING. 2022. Disponível em: <https://grafana.com/licensing/>.

HERNANTES, J.; GALLARDO, G.; SERRANO, N. IT Infrastructure-Monitoring Tools.

IEEE Software, v. 32, n. 4, p. 88–93, jul. 2015. ISSN 1937-4194. Citado na página 36.
Referências 76
IANA. 2022. Disponível em: <https://pen.iana.org/pen/PenApplication.page>. Citado

na página 66.
IETF. 2022. Disponível em: <https://www.ietf.org>. Citado na página 35.
IOTWF. 2022. Disponível em: <https://www.iotwf.com/>. Citado na página 29.
JSON-LIBRARY. 2022. Disponível em: <https://github.com/bblanchon/ArduinoJson>.
Citado 2 vezes nas páginas 59 e 60.
KARVINEN, T.; KARVINEN, K. Primeiros Passos com Sensores: Perceba o Mundo
Usando Eletrônica, Arduino e Raspberry Pi. 1ª ed.. ed. [S.l.: s.n.], 2014. ISBN
9788575224021. Citado na página 33.
KERSCHBAUMER, R. Engenharia de controle e Automação Microcontroladores. 2018.
Disponível em: <https://professor.luzerna.ifc.edu.br/ricardo-kerschbaumer/wp-content/
uploads/sites/43/2018/02/Apostila-Microcontroladores.pdf>. Citado 2 vezes nas páginas
25 e 26.
LASTMINUTEENGINEERS-DHT11. 2022. Disponível em: <https://lastminuteengineers.
com/dht11-module-arduino-tutorial/>. Citado na página 46.
LASTMINUTEENGINEERS-MQ2. 2022. Disponível em: <https://lastminuteengineers.
com/mq2-gas-senser-arduino-tutorial/>. Citado 2 vezes nas páginas 47 e 48.
LCD1602-LIBRARY. 2022. Disponível em: <https://blogmasterwalkershop.com.br/
arquivos/libs/LiquidCrystal_I2C2004V2.zip>. Citado na página 59.
LINKEDIN. 2022. Disponível em: <https://www.linkedin.com/in/
alexei-vladishev-8a12737/>. Citado na página 36.
LITTLEFS. 2022. Disponível em: <https://arduino-esp8266.readthedocs.io/en/latest/
filesystem.html>. Citado na página 59.
LITTLEFS-LIBRARY. 2022. Disponível em: <https://github.com/littlefs-project/littlefs>.
LOOKOUT. 2022. Disponível em: <https://lookout.com.br/>. Citado na página 53.
MACADDRESS-IO. 2022. Disponível em: <https://macaddress.io/faq/
what-are-a-universal-address-and-a-local-administered-address>. Citado na
página 58.
MAURO, D. R.; SCHMIDT, K. J. Essential SNMP. 2nd ed. ed. Sebastopol, CA: O’Reilly,
2005. ISBN 9780596008406. Citado na página 34.
MAXIMINTEGRATED-DS18B20. 2022. Disponível em: <https://datasheets.
maximintegrated.com/en/ds/DS18B20.pdf>. Citado na página 69.
MCEWEN, A.; CASSIMALLY, H. Designing the Internet of things. Reprinted with
corrections. Chichester: Wiley, 2014. ISBN 9781118430620. Citado na página 27.
MICHAEL, P. Why Do I Need DCIM? 2012. Disponível em: <https://www.
datacenterknowledge.com/archives/2012/05/24/why-do-i-need-dcim>. Citado na página
22.
Referências 77
MICROCHIP: Smart | Connected | Secure | Microchip Technology. 2022. Disponível em:

<https://www.microchip.com/>. Citado na página 32.
MICROCHIP-ATMEGA328P. 2022. Disponível em: <https://www.microchip.com/en-us/

product/ATmega328P>. Citado na página 32.
MISCHIANTI. 2022. Disponível em: <https://www.mischianti.org/wp-content/uploads/

2019/01/F61TRALJQMOC8BD.LARGE1_.jpg>. Citado na página 44.
MISCHIANTI-ESP01. 2022. Disponível em: <https://www.mischianti.org/2019/01/14/

esp-01-modules-programming-board/>. Citado na página 45.
MODULOELETRONICA-PIR. 2022. Disponível em: <https://blog.moduloeletronica.com.

br/wp-content/uploads/2018/10/ARTIGO-8_FIGURA-3.jpg>. Citado na página 49.
MOZILLA-JAVASCRIPT. 2022. Disponível em: <https://developer.mozilla.org/pt-BR/

docs/Web/JavaScript>. Citado na página 58.
MQ2-LIBRARY. 2022. Disponível em: <https://github.com/miguel5612/MQSensorsLib>.

NEWTONCBRAGA. 2022. Disponível em: <https://www.newtoncbraga.com.br/index.

php/como-funciona/4571-art632>. Citado na página 48.
NTP-LIBRARY. 2022. Disponível em: <https://github.com/arduino-libraries/

NTPClient>. Citado 2 vezes nas páginas 59 e 60.
OID-INFO. 2022. Disponível em: <http://oid-info.com/index.htm>. Citado na página

66.
OLIVEIRA, N. M. Paralelo entre as arquiteturas von Neumann e Harvard.

UFRPE - Universidade Federal Rural de Pernambuco, 2014. Disponível em:
<http://ww2.deinfo.ufrpe.br/sites/ww2.deinfo.ufrpe.br/files/artigos_aoc/Artigo%201%
20-%20Nicolas%20Melo%20%28corrigido%29.pdf>. Citado na página 25.
PHILIPS-PCF8574AT. 2022. Disponível em: <https://cdn.awsli.com.br/945/945993/

arquivos/datasheetPCF8574AT.pdf>. Citado na página 51.
POTTS, M. DCK Guide to Data Center Infrastructure Management (DCIM).

2012. Disponível em: <https://www.datacenterknowledge.com/archives/2012/05/22/
guide-data-center-infrastructure-management-dcim>. Citado na página 22.
PROCESSING. 2022. Disponível em: <https://processing.org/>. Citado na página 30.
PROTOSUPPLIES. 2022. Disponível em: <https://protosupplies.com/wp-content/

uploads/2019/04/Mega-2560-Pro-Pinout.jpg>. Citado na página 43.
REDHAT: Arduino - what is an ide? 2019. Disponível em: <https://www.redhat.com/en/

topics/middleware/what-is-ide>. Citado na página 30.
RITTAL: Cmc iii monitoring system. 2022. Disponível em: <https://www.rittal.com/

ca-en/products/PG0800ITINFRA1/PG1538ITINFRA1/PGR9560ITINFRA1>. Citado
na página 18.
Referências 78
SANCHEZ, J. et al. Research, An Integral Pedagogical Strategy for Teaching and

Learning IoT Cybersecurity. 2020. Publisher: researchgate.net. Disponível em:
<https://www.researchgate.net/publication/343035783_An_Integral_Pedagogical_
Strategy_for_Teaching_and_Learning_IoT_Cybersecurity>. Citado na página 29.
SC-TECH. 2022. Disponível em: <http://www.sc-tech.cn/en/BISS0001.pdf>. Citado na
página 48.
SHIBU, K. Introduction to embedded systems. New Delhi; Singapore: Tata McGraw-
Hill Education, 2009. OCLC: 911063678. ISBN 9781283186766. Disponível em:
<http://www.myilibrary.com?id=318676>. Citado na página 24.
SNMP-LIBRARY. 2022. Disponível em: <https://github.com/0neblock/Arduino_
SNMP>. Citado na página 59.
SNMP-RESEARCH. 2022. Disponível em: <https://snmp.com/protocol/snmp_rfcs.
shtml>. Citado na página 35.
SPARKFUN-LCD. 2022. Disponível em: <https://www.sparkfun.com/datasheets/LCD/
HD44780.pdf>. Citado na página 51.
SPARKFUN-LLC. 2022. Disponível em: <https://www.sparkfun.com/products/12009>.
SPARKFUNELECTRONICS. 2022. Disponível em: <https://www.sparkfun.com/>.
STALLINGS, W. Arquitetura e organização de computadores. São Paulo (SP): Pearson,
2010. OCLC: 817222637. ISBN 9788576055648. Citado na página 24.
STF. Constituição Federal do Brasil. 2022. Disponível em: <https://constituicao.stf.jus.
br/dispositivo/cf-88-parte-1-titulo-4-capitulo-3-secao-4-artigo-109>. Citado na página
16.
TELEGRAM. 2022. Disponível em: <https://telegram.org/>. Citado na página 37.
TELEGRAMBOT-LIBRARY. 2022. Disponível em: <https://github.com/witnessmenow/
Universal-Arduino-Telegram-Bot>. Citado na página 60.
THINGIVERSE-DHT11. 2022. Disponível em: <https://www.thingiverse.com/thing:
THINGIVERSE-HCSR501. 2022. Disponível em: <https://www.thingiverse.com/thing:
THINGIVERSE-MQ2. 2022. Disponível em: <https://www.thingiverse.com/thing:
TONGLING. 2022. Disponível em: <https://datasheetspdf.com/pdf-file/1480970/
TONGLING/JQC-3FF-S-Z/1>. Citado na página 52.
VALERO, M. C. rfidjournal: Implementación de dos casos de uso para la evaluación
de métricas cualitativas en redes de telecomunicaciones. Ashton K. (2009). “That
’internet of things’ thing in the real world, things matter more than ideas. RFID Journal.
Retrieved from http://www.rfidjournal.com/article/print/4986, 2020. Disponível em:
<https://repository.ucc.edu.co/handle/20.500.12494/33646>. Citado na página 27.
Referências 79
VERAS, M. Cloud Computing. Nova Arquitetura da TI. 1st edition. ed. Rio de Janeiro:
Brasport, 2012. Original-date: 2012. Citado 2 vezes nas páginas 21 e 22.
VIGINOSK, C. L. F.; RIBEIRO, E. P. Sistema utilizando vibração de um transdutor

piezoelétrico para medir densidade de um líquido. UFPR - Universidade Federal do
Paraná, 2013. Disponível em: <https://acervodigital.ufpr.br/bitstream/handle/1884/
36397/R-D-CIBELELEMOSFREIREVIGINOSKI.pdf>. Citado na página 53.
W3-CSS. 2022. Disponível em: <https://www.w3.org/Style/CSS/>. Citado na página

58.
W3-HTML. 2022. Disponível em: <https://www.w3.org/html/>. Citado na página 58.
WEBSERVER-LIBRARY. 2022. Disponível em: <https://github.com/esp8266/Arduino/

tree/master/libraries/ESP8266WebServer>. Citado na página 60.
WIFI-LIBRARY. 2022. Disponível em: <https://github.com/esp8266/Arduino/tree/

master/libraries/ESP8266WiFi>. Citado na página 60.
WINSEN-SENSOR. 2022. Disponível em: <https://www.winsen-sensor.com/d/files/PDF/

SemiconductorGasSensor/MQ-2(Ver1.4)-Manual.pdf>. Citado na página 47.
WIRESHARK. 2022. Disponível em: <https://www.wireshark.org/>. Citado na página

66.
WIRING. 2022. Disponível em: <http://wiring.org.co/>. Citado na página 30.
WIZNET. 2022. Disponível em: <https://docs.wiznet.io/img/products/w5500/w5500_

ds_v109e.pdf>. Citado na página 50.
YOUSUF, T. et al. Internet of things (iot) security: Current status, challenges and
countermeasures. International Journal for Information Security Research, v. 5, p.
608–616, 12 2015. Citado na página 28.
YOUTUBE: A Tale of 4 Arduino Unos - Genuine, Counterfeit, Clone and Improved. 2021.
Disponível em: <https://www.youtube.com/watch?v=If1Ha5pjNwE>. Citado 2 vezes
nas páginas 31 e 32.
ZABBIX: What is zabbix. 2022. Disponível em: <https://www.zabbix.com/

documentation/current/en/manual/introduction/about>. Citado na página 36.
ZABBIX. 2022. Disponível em: <https://www.zabbix.com/>. Citado na página 36.

TCC JFRN Final

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

TCC JFRN Final

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

INSTITUTO METRÓPOLE DIGITAL

Argus: Dispositivo IoT para Monitoramento

Robson da Silva Andrade

Argus: Dispositivo IoT para Monitoramento de

Trabalho de Conclusão de Curso apresentado

Orientador: Prof. Dr. Marcos Cesar Madruga Alves Pinheiro

Argus: Dispositivo IoT para Monitoramento de

Trabalho de Conclusão de Curso apresentado

Trabalho aprovado. Natal-RN, Brasil, 28 de julho de 2022:

Prof. Dr. Marcos Cesar Madruga Alves Pinheiro

Prof. Msc. Wellington Silva de Souza

Prof. Dr. Aluízio Ferreira da Rocha Neto

Agradeço primeiramente a Deus e ao meu protetor São Miguel Arcanjo, a toda

Esse trabalho visa o desenvolvimento de um dispositivo de baixo custo, nomeado nesse

Palavras-chave: Arduino, API, Bot, Datacenter, IoT, Monitoramento, Sensores, Telegram,

Figura 1 – Organograma Resumido da Estrutura do Poder Judiciário Brasileiro. . 16

Quadro 1 – Especificação de alguns modelos de placas Arduino . . . . . . . . . . . 30

ASCII American Standard Code

API Application Programming Interface

ARM Advanced RISC Machine

CLI Command-line Interface

CPU Central Processing Unit

DC Direct current - Corrente Contínua (eletricidade)

DCIM Datacenter Infrastructure Management

DHCP Dynamic Host Configuration Protocol

GLP Gás liquefeito de petróleo

GPIO General-Purpose Input/Output

GUI Graphical User Interface

HTML HyperText Markup Language

IANA Internet Assigned Numbers Authority

I2C Inter-integrated Circuit

IDE Integrated Development Environment

IMD Instituto Metrópole Digital

ICSP In Circuit Serial Programming

IETF Internet Engineering Task Force

I/O Input / Output

JEE Juizado Especial Estadual

JEF Juizado Especial Federal

JFAL Justiça Federal em Alagoas

JFCE Justiça Federal no Ceará

JFPB Justiça Federal na Paraíba

JFPE Justiça Federal em Pernambuco

JFRN Justiça Federal no Rio Grande do Norte

JFSE Justiça Federal em Sergipe

LCD Liquid Crystal Display

MIB Management Information Base

MOS Metal Oxide Semiconductor

NMS Network Management System

NOC Network Operations Center

NTC Negative Temperature Coefficient

NTP Network Time Protocol

OID Object Identifier

PCB Printed Circuit Board

PEN Private Enterprise Number

PIR Passive Infrared Sensor

PPM Partes por milhão

PWM Pulse Width Modulation

RGB Red Green Blue

SMI Structure of Management Information

SNMP Simple Network Management Protocol

SOIC Small Outline Integrated Circuit

SPI Serial Peripheral Interface