Monitoramento de variáveis ambientais para um data center · 1 Costa, G. R. Monitoramento de...
51
Guilherme Rocha da Costa Monitoramento de variáveis ambientais para um data center Sorocaba 2018 UNIVERSIDADE ESTADUAL PAULISTA “JÚLIO DE MESQUITA FILHO” Campus Experimental de Sorocaba
Transcript of Monitoramento de variáveis ambientais para um data center · 1 Costa, G. R. Monitoramento de...
Guilherme Rocha da Costa
Monitoramento de variáveis ambientais para
um data center
Sorocaba
2018
UNIVERSIDADE ESTADUAL PAULISTA
“JÚLIO DE MESQUITA FILHO”
Campus Experimental de Sorocaba
Guilherme Rocha da Costa
MONITORAMENTO DE VARIÁVEIS AMBIENTAIS
PARA UM DATA CENTER
Trabalho de Conclusão de Curso apresentado ao
Instituto de Ciência e Tecnologia de Sorocaba,
Universidade Estadual Paulista (UNESP), como
parte dos requisitos para a obtenção do grau de
Bacharel em Engenharia de Controle e
Automação.
Orientador: Prof. Dr. Galdenoro Botura Junior
Sorocaba
2018
1
Costa, G. R. Monitoramento de variáveis ambientais para um data center, Trabalho de
Conclusão do Curso de Engenharia de Controle e Automação – Universidade Estadual Paulista,
Sorocaba – SP, 2018.
RESUMO
Para que as indústrias atendam eficazmente as exigências crescentes do
mercado, é de extrema importância que elas consigam garantir um tempo de atividade alto, um
alto grau de confiabilidade nos seus sistemas e também o desempenho de sistemas produtivos.
Desta forma, medir e acompanhar as variáveis de sistemas de data centers tornou-se
indispensável e imprescindível na execução de atividades de toda indústria, comércio e
empresa, uma vez que todos estes setores têm sistemas críticos presos a servidores
computacionais. A distribuição, monitoramento e controle dessas informações pode ser
implementada através de sistemas de monitoria. Tais sistemas permitem a integração de
inúmeros dispositivos controlados em uma única central de controle, proporcionando a
visualização e tomada de ação com base nas informações contidas nele. A implementação
desses sistemas é feita através de sensores, microcontroladores e interfaces capazes de se
comunicar via web a fim de monitorar e permitir o controle de variáveis importantes para a
performance e vida útil de hardwares de informática. As etapas desse projeto consistem no
desenvolvimento de um programa para rodar em um microcontrolador integrado com sensores
e placas comunicadoras e enviar estes dados a um servidor web que os tratará e os
disponibilizará para monitoria. Os conhecimentos adquiridos nesse trabalho podem ser
expandidos e generalizados para a implementação de outros sistemas baseados em tecnologias
como IoT, Web server e tratamento de dados digitais.
Palavras-chave: variáveis de ambiente; Data Center; Microcontrolador; Arduino;
monitoria.
2
ABSTRACT
In order to effectively meet the growing requirements of the market it is extremely
important that companies must able to guarantee uptime, system reliability and also
performance in their productive environments. Thus, to measure and track environmental
variables for data centers has become indispensable and essential for the activities of
industries, companies and stores as these segments of the economy are dependent on
computational servers for their critical systems. The distribution, monitoring and control of this
information can be enforced through tracking systems. Such systems allow the integration of
many devices in a single process center, providing the viewing and decision-making capabilities
from the information contained therein. The implementation of these systems is done using
sensors, microcontrollers and interfaces capable of communication through web protocols to
track and keep important variables to guarantee the performance and lifespan of hardware.
This project aims to develop a code to run in a microcontroller that is integrated with sensors
and communication boards to send the sensor data to a web server that will process it and make
it available for monitoring. The knowledge acquired in this work can be expanded and
extrapolated to the implementation of any other system based in IoT technologies and digital
data treatment.
Keywords: Environmental variables; Data Center; Microcontroller; Arduino;
monitoring.
3
LISTA DE FIGURAS
Figura 1 – Fumaça após incêndio em um datacenter na região sul do Brasil ......................... 9
Figura 2 – PUE para todos os datacenters de larga escala do google. ................................ 10
Figura 3 – Estrutura de rede do Data Center da IBM ........................................................... 13
Figura 4 – Medição de tensão entregue aos sensores por dia ............................................ 14
Figura 5 – Detecção de pontos de aquecimento .................................................................. 15
Figura 6 – Pontos de aquecimentos após as correções no sistema de resfriamento ........... 15
Figura 7 – Variação da temperatura em um servidor em relação ao quarto todo ................. 16
Figura 8 – Arquitetura do Data Center Genome ................................................................... 17
Figura 9 – Genomote master e escravo, comparados com uma moeda de 25 centavos
americanos. ......................................................................................................................... 19
Figura 10 – Concentração de ar gelado no meio dos racks. ................................................ 20
Figura 11 – Arduino Uno ...................................................................................................... 23
Figura 12 – Interface IDE Arduino ........................................................................................ 24
Figura 13 – ESP8266 - 01 ................................................................................................... 25
Figura 14 – Pinagem do ESP8266 ....................................................................................... 25
Figura 15 – DHT 22 ............................................................................................................. 26
Figura 16 – Circuito montado ............................................................................................... 29
Figura 17 – Configuração de um Device e seu Token.......................................................... 31
Figura 18 – Diagrama de funcionamento da carga no Thingsboard ..................................... 31
Figura 19 – Configuração de um gráfico .............................................................................. 32
Figura 20 – Dashboard de demonstração dos dados coletados. .......................................... 32
Figura 21 – Diagrama de processor do código..................................................................... 36
Figura 22 – Valores medidos sem uso de fontes de calor externas ..................................... 37
Figura 23 – Aumento da humidade relativa do ar. ................................................................ 38
4
LISTA DE TABELAS
Tabela 1 – Requisitos mínimos para um datacenter ............................................................ 21
Tabela 2 – Diferenças entre os principais Arduinos do mercado .......................................... 22
Tabela 3 – Pinagem ESP8266 ............................................................................................. 25
Tabela 4 – Detalhamento operacional DHT 22 .................................................................... 26
Tabela 5 – Pinagem DHT22................................................................................................. 26
Tabela 6 – Valor médio dos componentes utilizados ........................................................... 28
Tabela 7 – Tabela de Conexões ESP8266 .......................................................................... 29
Tabela 8 – Tabela de conexões do DHT22 .......................................................................... 30
5
LISTA DE ABREVIATURAS E SIGLAS
IBM International Business Machines
MQTT Message Queuing Telemetry Transport
rDCP Reliable Data Collection Protocol
IoT Internet of Things
CoAP Constrained Application Protocol
HTTP Hypertext Transfer Protocol
DC Datacenter
TI Tecnologia da Informação
API Application Programming Interface
6
SUMÁRIO
RESUMO........................................................................................................................................1
ABSTRACT....................................................................................................................................2
1. INTRODUÇÃO......................................................................................................................7
1.1 Justificativa ........................................................................................................................................ 7
1.1.1 Demanda Corporativa ........................................................................................................................ 7
1.1.2 Demanda Energética .......................................................................................................................... 9
1.2 Objetivos ........................................................................................................................................... 11
2. LEVANTAMENTO BIBLIOGRÁFICO........................................................................12
2.1 IBM Datacenter em Genova ............................................................................................................. 12
2.1.1 Rede Wireless ................................................................................................................................... 12
2.1.2 Resultados ......................................................................................................................................... 13
2.1.2.1 Avaliação da rede ......................................................................................................................... 13
2.1.2.2 Avaliação da temperatura ............................................................................................................ 14
2.2 Projeto Genome ................................................................................................................................ 16
2.2.1 Arquitetura de Medição ................................................................................................................... 17
2.2.2 Rede sem fio ...................................................................................................................................... 18
2.2.3 Genomotes ........................................................................................................................................ 18
2.2.4 Resultados ......................................................................................................................................... 19
3. MATERIAL E MÉTODO.................................................................................................21
3.2 MATERIAIS....................................................................................................................22
3.2.1 ARDUINO UNO..........................................................................................................22
3.2.2 ESP8266........................................................................................................................24
3.2.3 DHT22...........................................................................................................................26
3.2.4 THINGSBOARD.........................................................................................................27
3.2.5 CUSTO..........................................................................................................................27
3.3 DESENVOLVIMENTO................................................................................................28
3.3.1 MONTAGEM DO CIRCUITO................................................................................28
3.3.2 Configuração do Thingsboard ......................................................................................................... 30
3.3.3 Código ............................................................................................................................................... 33
4. RESULTADOS...................................................................................................................37
5. CONCLUSÃO.....................................................................................................................40
6. TRABALHOS FUTUROS................................................................................................41
7. REFERÊNCIAS BIBLIOGRÁFICAS............................................................................42
7
1. INTRODUÇÃO
1.1 Justificativa
1.1.1 Demanda Corporativa
Ao olhar para uma empresa de grande ou médio porte e mais atentamente a evolução
que estas passaram nos últimos anos fica claro o impacto que a transformação digital teve.
Pequenos softwares, planilhas, papéis e processos manuais, dentre outros, foram todos dando
espaço para softwares empresariais de grande porte. Hoje dificilmente vemos uma empresa que
não possui um ERP (Enterprise Resource Planning, Planejamento de recursos empresariais, em
tradução livre) como o software principal para gestão de gastos, recursos e planejamento
financeiro. Atrelados ao ERP vemos sistemas de HCM (Human Capital Management, Gestão
de Capital Humano) para o setor de recursos humanos de uma empresa e CX (Customer
Experience, Experiência do consumidor) para a área de vendas. Conforme uma empresa cresce
ela começa a ficar tão dependente de sistemas como este que poucas horas com um sistema fora
do ar significa que os funcionários não têm trabalho, significa que os fornecedores podem deixar
de receber, os credores de pagar e o negócio de crescer, isso se traduz em um prejuízo enorme
para a empresa. Um exemplo claro do dia-a-dia é imaginarmos se o servidor de e-mail de uma
empresa parasse, o quanto ela não deixaria de operar até que se voltasse a normalidade? Em
2013 o site da Amazon, maior site de vendas dos Estados Unidos ficou fora do ar por cerca de
30 minutos, de acordo com a Forbes a estimativa é que o prejuízo tenha sido na casa de 2
milhões de dólares (FORBES, 2013)
Uma companhia opera de forma previsível, os gastos já estão todos previstos, a
rentabilidade é pré calculada baseada em diversos indicadores econômicos e o lucro está todo
baseado no pipeline e forecast da área de vendas. Para a área de tecnologia da informação não
é diferente e para atender as áreas de negócio com previsibilidade são instituídos SLAs (Service
Level Agreement) que é um compromisso assumido por um prestador de serviços de TI perante
um cliente. Este compromisso descreve o serviço de TI, os níveis de qualidade que devem ser
garantidos, as responsabilidades das partes e eventuais compensações quando os níveis de
qualidade não forem atingidos (ANS, 2018). Para atender esses níveis de serviço a arquitetura
de um software é toda planejada de forma que este seja altamente disponível, evitando pontos
8
únicos de falha e muitas vezes eles são replicados, uma ou até duas vezes, em locais geográficos
diferentes de forma a evitar que o software fique fora do ar.
Um dos principais pontos de uma arquitetura redundante é o custo. A replicação total
dos sistemas em uma outra região dobra o valor de implementação o que pode barrar o projeto
ou o ambiente redundante. Muitas empresas, dependendo de seu tamanho e dos sistemas que
rodam, acabam por possuir somente um ambiente de desastre sendo esse menor do que o
ambiente produtivo, visto que esse só ficará ativo enquanto o ambiente de produção retorna ao
ar. Assim o ambiente produtivo deve ser extremamente monitorado e controlado para que sua
interrupção seja a menor possível e para isso um dos pontos de maior importância que deve ser
monitorado é o hardware.
O hardware é o servidor físico que hospeda as aplicações de uma empresa e é um dos
componentes mais caros quando falamos em computação. Para o hardware não existe um
ambiente de desastre, ele é o próprio hospedeiro do ambiente de desastre, e assim garantir a
perfeita operação e tempo de atividade de um é de extrema importância
Um exemplo da importância de monitoria e controle de um datacenter ocorreu em março
deste ano. O datacenter da BRDigital, um dos maiores fornecedores de collocation e hosting do
sul do país, pegou fogo no fim de semana do dia 6 de março e pelo menos 50% de todos os
racks foram afetados de alguma maneira pelas chamas que se iniciaram em apenas 2 dos 50
racks do andar (BAGUETE, 2018). Algumas empresas tiveram seus serviços offline por conta
do incidente, como foi o caso da Unimed de Porto Alegre que ficou horas sem seus sistemas
relativos a consultas e exames fora do ar e o Esporte Clube Internacional que ficou um dia fora
do ar, antes de uma partida contra o Grêmio, equipe rival, por 24 horas, complicando a venda
para mais de 75 mil torcedores que estavam tentando fazer o check-in para a partida. A figura
1 mostra uma foto do prédio onde fica localizado o datacenter, na figura pode-se ver a fumaça
que está sendo expelida pelo sistema de contra incêndio do datacenter.
9
Figura 1 – Fumaça após incêndio em um datacenter na região sul do Brasil
Fonte: (BAGUETE, 2018)
1.1.2 Demanda Energética
Cerca de 7% de toda a energia consumida atualmente é gasta pela área de Tecnologia
da Informação e é esperado que esse número cresça para 13% até 2030 (SADLER, 2017). Desse
total cerca de 40% é utilizado somente para os sistemas de refrigeração (KHAJAJ, 2016).
Levando em conta que toda essa geração energética é responsável por 2% de todas as emissões
globais de CO2 fica clara uma preocupação também ambiental com relação ao consumo
energético e geração de gases nocivos ao efeito estufa.
Para se medir a eficiência energética em um datacenter é medido o seu PUE (Power
Usage Efffectiveness), que foi definido como o padrão global para medição da eficiência de um
data center (ISSO, 2016) e é a energia total entregue ao DC pela energia consumida pelos
equipamentos de TI, como mostra a equação 1.
10
𝑃𝑈𝐸 = %&'()*+-./+0&.12%&'()*+/./+03.4'56*7+8'&/.3'-9
(1)
Então, valores mais baixos de PUE são ideais para um DC com alta eficiência energética.
O valor ideal e mínimo é 1, sem considerar reutilização de calor gerado para alimentação
energética. Com a crescente preocupação ambiental dos últimos anos, empresas de tecnologia
de ponta, como Google e Facebook investiram em tecnologias disruptivas e técnicas de
instalação novas para poder diminuir o valor de PUE de seus datacenters e em 2015 e 2016,
respectivamente, apresentaram datacenters com PUE de aproximadamente 1,10, como pode ser
visto na figura 2, o PUE médio dos datacenters do Google ao longo dos últimos 10 anos
(GOOGLE, 2018) (FACEBOOK, 2018).
Figura 2 – PUE para todos os datacenters de larga escala do google.
Fonte: (GOOGLE, 2018)
Porém nem as empresas apresentam essa mesma preocupação que as gigantes da internet
e a média reportada para a indústria de tecnologia é um PUE de em média 2,9, sendo que menos
de 20% dos datacenters pesquisados possuíam um PUE menor do que 2.
Assim, fica claro que empresas mais novas e com os meios para tal estão buscando novas
formas de ter uma performance energética melhor, mas que essa não é a realidade da indústria.
Para tal o primeiro ponto para se buscar uma melhor eficiência energética é o monitoramento
11
das variáveis ambientais afim de se evitar o resfriamento demasiado, que contribui para um
maior PUE, maior gasto energético (BELL, 2009) e até mesmo aumento na taxa de falha de
unidades de disco (PINHEIRO, 2007)
1.2 Objetivos
Este trabalho objetiva desenvolver um sistema de monitoria de temperatura e humidade
com funcionamento remoto e de baixo custo. Desta maneira iremos avaliar se uma das partes
mais críticas na implementação de um data center, sua monitoria, impõe uma dificuldade
financeira ou técnica para ser implementada dentro das melhores práticas do mercado.
12
2. Levantamento Bibliográfico
2.1 IBM Datacenter em Genova
A fim te atender as necessidades de resfriamento, redução de custo e aprimoramento de
seus serviços a IBM montou seu próprio sistema de monitoria para seu Data Center em Genova,
na Suíça. Com foco em otimização de recursos de resfriamento a IBM montou uma rede se
sensores com o objetivo de reduzir a utilização excessiva de resfriamento.
2.1.1 Rede Wireless
A figura 3 apresenta a arquitetura da Rede wireless do datacenter. Esta é composta por
diversos sensores a bateria localizados em regiões estratégicas dos servidores. Cada um desses
sensores envia suas medidas periodicamente para o broker MQTT-S que se comporta como
gateway que encaminha as mensagens para as aplicações.
O gerenciamento da rede funciona de duas maneiras: Um modo de gerenciamento e um
modo de sincronismo. No modo de gerenciamento o gateway monitora a rede em relação a
qualidade do link e assim pode calcular as melhores rotas e cronograma para os sensores
enviarem os dados. Configurado a parte de gerenciamento o gateway estabelece o modo de
sincronismo em que os sensores só operam ou em modo de envio ou recebimento, dependendo
de seu cronograma, assim toda a rede consegue operar em modo de baixo consumo energético.
A opção pelo MQTT-S se deu por ser um protocolo de mensageria desenhado para redes
de baixo consumo e também por sua performance em diferentes tipos de rede, como redes locais
e de celular. (WEISS, 2011)
13
Figura 3 – Estrutura de rede do Data Center da IBM
Fonte: (WEISS,2011)
2.1.2 Resultados
2.1.2.1 Avaliação da rede
Com os sensores implementados em uma topologia estrela em relação ao seu gateway
foram avaliadas as variáveis de rede onde a força e qualidade do sinal sem fio foram medidos
para ver a viabilidade do datacenter para suportar tal topologia. Após os sucessos dos testes
foram iniciados os testes e durante 35 dias 29 milhões de resultados de temperaturas foram
coletados. Uma das principais medidas feitas foi a taxa de entrega de pacotes, uma relação entre
a quantidade de pacotes que o gateway recebeu em relação a taxa de pacotes que o gateway
enviou. Na média a taxa ficou em 97,63%, um excelente valor. Sensores que apresentaram uma
taxa pior tiveram seus pacotes roteados por outros com melhores taxas de entrega.
Por fim a rede foi avaliada em relação ao seu consumo energético. Como os sensores
funcionam a bateria a entrega da tensão por estas foi medida diariamente e está representada
14
pela figura 4. Percebe-se o comportamento natural de baterias alcalinas na queda tensão
entregue ao longo do tempo. O período sem medição foi reflexo de um problema na rede que
impediu a comunicação e medição por 3 dias.
Figura 4 – Medição de tensão entregue aos sensores por dia
Fonte: (WEISS,2011)
Como durante os testes as baterias não chegaram a ser descarregadas não foi possível
precisar o tempo de duração das mesmas, mas testes em laboratórios, feitos pela própria IBM
estimam em 8 meses de duração.
2.1.2.2 Avaliação da temperatura
Durante os testes foram observados 3 pontos principais onde as correntes de ar gelado
não estavam sendo suficientes para atender a temperatura desejada (abaixo dos 25ºC), como
apresentado na figura 5.
15
Figura 5 – Detecção de pontos de aquecimento
Fonte: (WEISS,2011)
Com base nos dados gerados por esta monitoria foram feitas as alterações necessárias,
neste caso a substituição da grade perfurada que compunha o chão por uma grade também
perfurada, porém com furos maiores, que permitiu o melhor fluxo do ar gelado. Com isso a
redução da temperatura ficou evidente nos softwares de monitoria, como apresentado na figura
6.
Figura 6 – Pontos de aquecimentos após as correções no sistema de resfriamento
Fonte: (WEISS,2011)
16
Apesar das mudanças físicas na base do datacenter a temperatura geral do mesmo do
mesmo não se alterou, porém, os valores obtidos nos locais de atenção foram corrigidos, como
pode ser observado na figura 7.
Figura 7 – Variação da temperatura em um servidor em relação ao quarto todo
Fonte: (WEISS,2011)
2.2 Projeto Genome
A fim de entender como a energia é consumida em relação ao design do datacenter, sua
capacidade de resfriamento, seu tipo de hardware e a distribuição da carga de trabalho em
relação a estes hardwares o centro de pesquisa da Microsoft implementou, em seus data centers
um projeto de milhares sensores e uma rede de sensores proprietária, RACNet, para capturar,
medir e analisar os dados de temperatura do datacenter. (LIU, 2011)
17
2.2.1 Arquitetura de Medição
O sistema implementado para o projeto Genome não foi somente um sistema de
melhoria, mas sim de gerenciamento de datacenter, onde são medidos e controladas variáveis
físicas e digitais para que seja possível um controle mais granular e uma melhor otimização do
datacenter, como apresentado na figura 8. A arquitetura proposta tem por base a coleta de
informações do layout do datacenter para ser a base das informações coletadas, o sistema de
resfriamento que fornece informações da atuação dos ar-condicionado, sistemas de retirada de
humidade, resfriadores de água e outros para um controle de energia, os sistemas de alimentação
para se obter um detalhamento do consumo de energia, já os sistemas de performance dos
servidores e as variações de carga no mesmo para que seja possível relacionar as variáveis
ambientes como temperatura do ambiente com a temperatura do próprio hardware e pôr fim a
coleta de informações de variáveis ambientais.
Figura 8 – Arquitetura do Data Center Genome
Fonte: (LIU, 2014)
18
Os dados coletados então passam por uma área de manipulação de dados para
alimentarem sistemas de apresentação de dados, backup, e ferramentas analíticas para que sejam
gerados relatórios e melhorias ao datacenter.
2.2.2 Rede sem fio
Assim como o projeto do datacenter em Genova da IBM a Microsoft também utilizou
uma rede específica para sensores em seu projeto, a RACNet que teve por objetivo atender 3
pré-requisitos fundamentais para qualquer rede se sensores:
• Baixo custo de implementação: Permitindo que a tecnologia possa ser facilmente
adotada
• Alta confiabilidade dos dados: A rede deve gerar stream de dados constante para poder
alimentar os sistemas de modelagem e análise de dados para a tomada de decisões
• Integração transparente: A rede deve ser fácil de simples de ser integrada a diversos
sistemas de gerenciamento e entrega de dados para que sua adoção seja rápida e de baixo
custo ainda atendendo todas as necessidades técnicas do projeto.
Para então atender a necessidade de alta confiabilidade dos dados a RACNet utiliza um
protocolo próprio, rDCP, que por sua vez utiliza algumas tecnologias chave para sua
performance: Sua diversidade de canais permite que se conecte a diversos sensores mestre de
uma vez, sendo um sensor por canal, reduzindo a probabilidade de conflito de pacotes, sua
tecnologia de árvore de adaptação permite que sejam escolhidos os links mais performáticos
dentro da rede para garantir a qualidade da comunicação e por fim é o próprio gateway da rede
que faz a coleta dos dados, ao invés de os sensores enviarem, assim é mais uma garantia que
não existira perda de pacotes na rede.
2.2.3 Genomotes
Para a coleta de dados o instituto de pesquisa da Microsoft desenvolveu o que eles
chamaram de Genomotes, sensores que atendem a especificações básicas para o projeto: baixo
custo, fácil instalação e baixo consumo de energia. Eles são capazes de coletar informações
como temperatura e humidade e são divididos em escravos e mestres. Os mestres possuem
comunicação wireless através do padrão IEE 802.15.4, que especifica a camada física e efetua
o controle de acesso para rede sem fios e é a base para especificações como ZigBee (IEEE
19
802.15 document 15-13-0257-06-0000). Os Genomotes escravos apresentam portas serias para
comunicação com o mestre, que está instalado em cima dos servidores. Um exemplo de
Genomotes pode ser visto na figura 9.
Figura 9 – Genomote master e escravo, comparados com uma moeda de 25 centavos
americanos.
Fonte: (LIU, 2014)
2.2.4 Resultados
Após a implementação dos Genomotes em diversos datacenters foi possível entender
padrões de comportamento da refrigeração e temperatura nos racks com mais clareza.
A figura 10 mostra a diferença de temperatura entre diferentes alturas de um rack, ou
seja, com a capacidade de ventilar o are gelado a alturas maiores pode ser possível aumentar a
temperatura média entregue a sala sem danificar o equipamento. O efeito Venturi nos diz que
quanto maior a velocidade de um fluido menor é sua pressão, assim o ar gelado que se move
rapidamente perto do chão cria bolsões de baixa pressão que atraem o a quente, por isso a
concentração de ar gelado no meio dos racks (Venturi).
20
Figura 10 – Concentração de ar gelado no meio dos racks.
Fonte: (LIU, 2014)
A utilização da RACNet foi uma das primeiras tentativas de fornecer dados detalhados
sobre a operação dos datacenters. Sua capacidade de escalabilidade, confiabilidade e custo
atenderam as exigências mais complexas em termos de monitoria e se apresenta como uma
excelente opção na montagem de um sistema completo para controle de variáveis físicas e
digitais.
21
3. MATERIAL E MÉTODO
3.1 Especificações
Esta sessão irá tratar do desenvolvimento proposto para esse trabalho, assim como da
descrição dos materiais e metodologias aplicadas na construção de um sistema de
monitoramento.
Este projeto visa como objetivo final o desenvolvimento da programação e montagem
de um medidor de temperatura e humidade com apresentação dos dados em tempo real. A seguir
estão descritos os principais componentes que foram utilizados para a montagem do coletor de
variáveis ambientais bem como o processo de montagem do mesmo. O trabalho não abrange a
parte de criação de alarmes e regras de monitoria que ajudariam a complementar as capacidades
de análise e atuação das medições feita, uma vez que o sistema de realimentação para um
componente de refrigeração de ar depende que o componente permita essa realimentação, como
a ideia do projeto é um sistema de baixo custo supõem-se que estes refrigeradores precisem de
intervenção manual
A TIA (Telecommunications Industry Association) é credenciada a ANSI para
desenvolver padrões e consensus para a indústria de Tecnologia e comunicação. Em 2005 a TIA
publicou sua primeira versão do ANSI/TIA-942, com normas e padrões a serem seguidos na
implantação de datacenters e centros de operações. Após diversas reestudos e alterações a TIA
lançou, em julho de 2017 o ANSI/TIA-942-B com informações mais detalhadas sobre a normas
para construção de um datacenter. Em seu conjunto de normas a TIA também informa os
melhores valores para a operação do DC, em termos de temperatura e humidade para a operação
do datacenter, estes estão apresentados na tabela 1.
Tabela 1 – Requisitos mínimos para um datacenter
Requisitos Valores Mínimos Máximos
Temperatura 20ºC 25ºC Humidade Relativa 40% 55% Taxa máxima de mudança - 5ºC/Hora Ponto de Orvalho - 21ºC
Baseando-se nas informações da Tabela 1 o sistema a ser montado tem que ser capaz de
coletar informações de temperatura entre 20 e 25ºC, 40 e 50% de humidade e capaz de registrar
mudanças de até 5ºC dentro de 1 hora.
22
3.2 Materiais
3.2.1 Arduino UNO
O Arduino é uma plataforma de hardware código livre, de fácil utilização, ideal para a
criação de dispositivos que permitam interação com o ambiente, dispositivos estes que utilizem
como entrada sensores de temperatura, luz, som etc., e como saída leds, motores, displays,
autofalantes etc., criando desta forma possibilidades ilimitadas para projetos profissionais e
caseiros (SOUZA, 2011).
A maior parte das placas Arduino consiste em estruturas com microcontroladores de 8-
bit AVR da Atmel e possuem uma vasta quantidade de memória flash, entradas e saídas e outras
características disponíveis (ARDUINO).
Existem inúmeros modelos de Arduino, desde Arduinos para controle de videogames
até Arduino para vestimentas. Para determinar qual seria o modelo ideal para este trabalho
foram levantados os principais e mais comuns modelos do mercado, Arduino Uno, Mega,
ethernet e Due. A diferença física entre estes Arduinos pode ser vista na Tabela 2.
Tabela 2 – Diferenças entre os principais Arduinos do mercado
Uno Mega Ethernet Due Alimentação 5v 5v 5V 5v Portas Digitais 14 54 14 54 Portas PWM 6 15 6 12 Portas Analógicas
6 16 6 12
Memória 32K 256K 32K 512K Conexão USB USB FTDI Micro USB
Ao analisas as placas pelas suas configurações físicas fica claro a diferença de propósito
que cada uma atende. Arduino uno, a mais básica possui menos interfaces I/O e menos memória
que as demais. As placas Mega e Due possuem muitas portas e bem mais memória,
recomendadas para projetos de grande escala com diversos Shields conectados. Por fim a placa
Ethernet possui uma facilidade pois já vem com uma interface para conexão com redes ethernet
o que permite a comunicação entre o Arduino e outros serviços em redes locais ou internet.
Por ser uma plataforma extremamente difundida no mercado, de baixo custo e fácil
manipulação foi optado pela utilização do Arduino uno para o projeto de monitoria de variáveis
ambientais. As placas Mega e Due possuem mais portas que não seriam usadas e sua memória
23
não é necessária para o código desenvolvido, já a placa Ethernet não se faz necessária pois o
propósito do trabalho é desenvolver um medidor capaz de enviar dados através de redes sem
fio. Então o Arduino uno, figura 11, irá fazer as vezes de controlador do sistema, seu
processador será responsável pela execução do código construído quer captura as informações
digitais dos sensores via porta serial, faz o tratamento das informações e o envia para o esp8266.
Figura 11 – Arduino Uno
Fonte: (ARDUINO)
O Arduino é alimentado via USB com 5v e possui saídas de 3V e 5V, porém estas não
foram utilizadas, uma vez que elas não conseguem suprir corrente suficiente para alimentar o
esp8266 e os sensores adjacentes. Para isso foi utilizada uma fonte externa de 5V.
As placas já possuem programação de bootloader de fábrica, uma rotina de inicialização
que facilita o envio de programas para a memória interna do chip do microcontrolador. Tal
envio é feito, nas placas atuais, através de conexão no computador via porta USB (Arduino,
2018). Já no que diz respeito ao Software, os programas para Arduino podem ser escritos em
qualquer linguagem que possua compiladores que convertam o código em linguagem de
máquina para o processador da placa em uso. A Arduino oferece uma interface de
desenvolvimento integrada (do inglês, IDE – Integrated Development Environment),
multiplataforma, através da qual o usuário pode utilizar a linguagem Wiring similar à C/C++
24
para escrever seus programas. Tais códigos são salvos pela interface no computador utilizando
a extensão .ino e são chamadas de Sketch. Assim, um Sketch nada mais é do que um programa
para Arduino escrito na interface do próprio fabricante (Arduino, 2018).
A figura 12 apresenta o ambiente IDE com um código exemplo desenvolvido.
Figura 12 – Interface IDE Arduino
Fonte: Autoria Própria.
3.2.2 ESP8266
EPS8266 é o nome de um sistema embarcado projetado pela Espressiff Systems. O
ESP8266 se define como uma solução de redes Wi-fi autossuficiente se oferecendo como uma
ponte entre um micro controlador pré-existente e a rede com sinal Wi-fi, e que também é capaz
de executar aplicações de maneira independente. (KOLBAN, 2015).
Existem diversos modelos de placas com variações de operações e funcionalidades, para
esse projeto utilizamos o modelo 01, figura 13, que além de possuir um custo baixíssimo é um
dos mais utilizados no mercado. Também foi o shield mais fácil de encontrar à venda.
25
Figura 13 – ESP8266 - 01
Fonte: (KOLBAN,2015)
Um ponto de atenção em relação ao trabalho com o ESP8266 é sua pinagem, conforme
figura 14. A listagem de seus pinos aparece na tabela 3.
Tabela 3 – Pinagem ESP8266
Pino Função RX Recebimento de dados TX Transmissão de dados
GND Terra Vcc Alimentação 3,3V
Reset Ativo quando em alto GPIO0 Uso geral, entrada e saída GPIO2 Uso geral CH_PD Habilitação do chip para funcionamento
Figura 14 – Pinagem do ESP8266
Fonte: (ESP8266)
26
3.2.3 DHT22
O DHT 22 é um sensor digital que permite a captura de valores de temperatura e
humidade do ar. Sua escolhe se deu pela facilidade de ser encontrado no mercado, pela
simplicidade de uso e comunicação com o Arduino, através de sua interface digital. A Tabela 4
também mostra sua capacidade de medida de valores extremos, referência técnica e acuracidade
na coleta de dados, já a tabela 5 nos mostra sua pinagem.
Tabela 4 – Detalhamento operacional DHT 22
DHT 22 Valores Alimentação 3,3V – 5,5V Valores de operação: Humidade 0-100%RH Valores de Operação: Temperatura -40~80 °C Acuracidade +-2%RH, +-0,5 °C
Tabela 5 – Pinagem DHT22
DHT 22 Terminal 1 Alimentação Terminal 2 Pino de dados Terminal 3 Sem função Terminal 4 Terra
Figura 15 – DHT 22
Fonte: (DHT22)
27
3.2.4 ThingsBoard
Para a apresentação dos dados foi utilizada o ThingsBoard, uma plataforma de código
livre que permite um rápido desenvolvimento, gerenciamento e escalonamento de projetos de
IoT (THINGSBOARD).
A plataforma permite a ingestão de dados utilizando diversos protocolos de mensageria
e transferência via web, como por exemplo CoAP, HTTP e MQTT. Neste projeto foi utilizado
o protocolo MQTT uma vez que as bibliotecas do Arduino facilitam sua implementação.
Para garantir que o valor que está sendo transimitido pelo Arduino seja entendível pelo
Thingsboard, este possui uma API MQTT que diz quais são as formas possíveis em que a troca
de informação pode acontecer para que eles se entendem.
Segundo a documentação do Thingsboard (THINGSBOARD,b) a comunicação é feita
via JSON, um formato de arquivo para troca de dados, onde as informações passadas podem
ser ou booleanas, double, long ou string. O exemplo abaixo é um tipo de JSON que pode ser
enviado ao ThingsBoard:
"stringKey":"value1", "booleanKey":true, "doubleKey":42.0, "longKey":73
Para pode enviar o JSON primeiro é necessário dizer que tipo de cliente você é para a
API do Thingsboard e em seguida o que você deseja fazer. Estes tipos de clientes são,
PUBLISH, uma publicação, ou seja, um cliente para envio de informação e SUBSCRIBE, para
receber as informações. Para dizer o que você deseja fazer é necessário enviar a mensagem de
PUBLISH ou SUBSCRIBE para um determinado tópico, por exemplo para enviar os valores
de temperatura e humidade para o Thingsboard você deve enviar sua mensagem para o tópico
v1/devices/me/telemetry, da mesma forma, se você quiser coletar informações do Thingsboard
você precisa enviar uma mensagem SUBSCRIBE para o mesmo tópico.
3.2.5 Custo
A fim de analisar a viabilidade do projeto estão listados os principais custos para a
construção do protótipo na tabela 6. Estes valores podem variar muito, principalmente em
28
relação a localização (frete), loja e quantidade comprada, assim servem apenas para base da
análise
Tabela 6 – Valor médio dos componentes utilizados
Componente Preço Esp8266 22,90 Arduino uno 36,90 DHT22 29,90 Fonte 8,90 Protoboard 11,90 Total 110,50
3.3 Desenvolvimento
3.3.1 Montagem do circuito
O primeiro passo da montagem foi o estudo individual de cada um dos componentes do
trabalho. Como cada um dos equipamentos operavam e qual a forma de comunicação e coleta
de dados deles.
Para o Arduino a própria interface IDE apresenta sketchbooks de exemplos e tutorias
para sua programação, bem como o envio e recebimento de comandos através da sua interface
serial, o que por sua vez se tornou essencial para fazer testes com o código em relação a captura
e envio das informações.
O esp8266 se apresentou como o mais difícil de configurar sua porta serial para
comunicação teve de ser alterada para permitir a comunicação correta através do Arduino e de
sua interface serial monitor (terminal 2 e 3). No período de testes também ficou claro que o
Arduino não conseguia entregar corrente suficiente para o ESP8266 e por isso foi necessária
uma fonte externa de 3,3v para alimentá-lo com uma corrente superior a 500mA
O DHT22 só possui um terminal para envio de dados de forma digital assim sua
configuração foi mais simples.
Depois dos estudos e testes necessários foi iniciada a montagem do circuito. O ESP8266
foi montado conforme a tabela 7. Tanto seu pino alimentação quando CH_PD foram conectados
diretamente na alimentação de 3.3V isso pois o pino CH_PD necessita de um sinal alto para
habilitar seu funcionamento. Apesar de não ter sido necessário no cenário deste projeto
29
recomenda-se a utilização de um resistor de pull-up para manter o nível lógico do pino CH_PD
em alto sem danificar o componente. As saídas seriais do ESP8266 não foram ligadas as saídas
TX e RX do próprio Arduino para que fosse possível utilizar a interface serial monitor do
Arduino IDE para monitorar a comunicação entre os componentes, sendo assim foram
conectadas nos terminais 2 e 3 das saídas digitais e foi utilizada a biblioteca SoftwareSerial.h
do Arduino para simular a conexão serial e o recebimento e envio de informações. A figura 16
mostra o esquema de conexões do sistema pronto.
Figura 16 – Circuito montado
Fonte: Autoria Própria.
Nota-se que a terminal data do DHT22 está conectada por um resistor pull-up de 10k
para certificar que se tenha um sinal logico positivo e garantir o funcionamento do DHT22. Tabela 7 – Tabela de Conexões ESP8266
Esp8266 Componente VCC Fonte 3,3V
CH_PD Fonte 3,3V GND Negativo da fonte RX Arduino 2 TX Arduino3
30
Tabela 8 – Tabela de conexões do DHT22
DHT22 Componente VCC Fonte 3,3V Data Resistor entre 4,7kΩ e 10kΩ NC -
GND Negativo da fonte
3.3.2 Configuração do Thingsboard
A configuração do Thingsboard foi feita no próprio ambiente de demo que é
disponibilizado no site da aplicação. É possível também instalar e configurar um servidor
thingsboard em uma máquina virtual para rodar em um computador local, porém essa
configuração adiciona dificuldades técnicas e de segurança uma vez que será necessária uma
máquina com capacidade para rodar uma máquina virtual, configurações de rede para expor as
portas http na máquina virtual para o computador host, do computador host para o modem ou
appliance de rede que por sua vez irá expor uma porta aberta da sua rede local na internet.
Utilizando o ambiente demo da própria Thingsboard ele já vem configurado e preparado para
uso, além de não ser necessária a preocupação com a parte de segurança do sistema.
O ponto principal de comunicação do Thingsboard com o esp8266 é a configuração de
um “device”, figura 17, que fará as vezes de um gateway dentro do servidor para coletar a
informação e alimentar os componentes (gráficos) do painel de apresentação. Este gateway fica
escutando a porta configurada no servidor, para este projeto, utilizando o ambiente demo da
Thingsboard, a porta 1883, quando uma tentativa de conexão é gerada ele confere se o Token
que está sendo passado é o mesmo que está registrado nele mesmo, em caso positivo ele permite
a conexão e captura os dados. O valor deste token é fornecido pelo “device” e configurado no
código do Arduino.
O diagrama da figura 18 apresenta um diagrama que simplifica o funcionamento da
comunicação entre o código, o esp8266 e o “Device” do servidor na internet.
31
Figura 17 – Configuração de um Device e seu Token
Fonte: Autoria Própria.
Figura 18 – Diagrama de funcionamento da carga no Thingsboard
Fonte: Autoria Própria.
Encapsulamento
• O protocolo MQTT encapsula o payload com as informações coletadas
Conexão• Inicia a conexão, passando host, porta e Token ID
Desencapsulamento
• O Device desencapsula as informações e alimenta os componentes definidos
32
Configurado o device é a vez de montar o dashboard. Utilizando os widgets prontos da
própria plataforma configuramos, vide figura 19, a coleta de informações a partir do device e
por fim são inseridos os gráficos no próprio dashboard.
Figura 19 – Configuração de um gráfico
Fonte: Autoria Própria.
Com os gráficos prontos foi montado um dashboard, como apresentado na figura 20.
Figura 20 – Dashboard de demonstração dos dados coletados.
Fonte: Autoria Própria.
33
3.3.3 Código
Com toda a montagem concluída foi escrito o código apresentado no anexo I, comentado
e identado, e carregado para o Arduino através do Arduino IDE. Para fins de teste e correção
de problemas foi mantido no código toda a parte de teste de conexão e envio das cargas para o
Thingsboard para acompanhamento através da interface serial.
No primeiro momento, como pode ser visto no código abaixo, são carregadas as
bibliotecas. Também são declaradas as informações de conexão para a rede Wi-Fi do local, o
token do device Thingsboard, as portas seriais utilizadas e as configurações para a comunicação
com o servidor web.
A Bibliotecas utilizadas e suas funções são:
• DHT.h: A biblioteca DHT é utilizada para os sensores DHT11 e DHT22, por isso na
declaração das variáveis da função dht, o pino do Arduino utilizado, 4, e o tipo DHT22
são passados. A biblioteca também permite a inicialização do DHT e a coleta de suas
variáveis através de funções prontas.
• WiFiEsp.h, WiFiEspClient.h: A bibliotecas para permitir o Arduino a se transformar em
um client para a conexão com o thingsboard.
• PubSubClient.h: é a biblioteca que permiteo encapsulamento MQTT e faz a
comunicação UDP com o servidor thingsboard.
• SoftwareSerial.h: Permite que os pinos digitais sejam utilizados para comunicação
serial.
• ESP8266.h: Permite a comunicação do Arduino com o ESP8266
#include "DHT.h" #include <WiFiEspClient.h> #include <WiFiEsp.h> #include <PubSubClient.h> #include "SoftwareSerial.h" #include "ESP8266.h" #define WIFI_AP "Nome_da_sua_rede" #define WIFI_PASSWORD "Senha da sua rede Wifi" #define TOKEN "Token_do_devide_thingsboard" #define DHTPIN 4 #define DHTTYPE DHT22 char thingsboardServer[] = "demo.thingsboard.io"; WiFiEspClient espClient; DHT dht(DHTPIN, DHTTYPE);
34
PubSubClient client(espClient); SoftwareSerial soft(2, 3); ESP8266 wifi(soft); int status = WL_IDLE_STATUS; unsigned long lastSend; void setup() Serial.begin(9600); dht.begin(); InitWiFi(); client.setServer( thingsboardServer, 1883 ); lastSend = 0;
Então são inicializadas as conexões com a rede Wi-Fi, como não estão sendo utilizadas
as portas seriais a interface serial monitor apresenta as em mensagens os prints a seguir, que
servem como ferramenta de logs.
void loop() status = WiFi.status(); if ( status != WL_CONNECTED) while ( status != WL_CONNECTED) Serial.print("Tentando conectar a rede Wifi: "); Serial.println(WIFI_AP); status = WiFi.begin(WIFI_AP, WIFI_PASSWORD); delay(500); Serial.println("Conectado"); if ( !client.connected() ) reconnect();
Com o Wi-Fi conectado a leitura do DHT22 é feita a cada 2 segundos. Seu valor é
impresso na tela e armazenado em variáveis que serão utilizadas na formação da carga que será
enviada. Com o valor de temperatura e humidade armazenados é então montado um JSON como
o exemplo a seguir:
"temperature":x", "humidity":xx
Seguindo os próprios requisitos da documentação da Thingsboard
(THINGSBOARD,b). O JSON é então enviado como uma string como uma mensage
35
PUBLISH para o tópico "v1/devices/me/telemetry" do device dentro do servidor e a conexão é
mantida enquanto o wi-fi estiver ativa.
if ( millis() - lastSend > 1000 ) getAndSendTemperatureAndHumidityData(); lastSend = millis(); client.loop(); void getAndSendTemperatureAndHumidityData() Serial.println("Coletando dados:"); float h = dht.readHumidity(); float t = dht.readTemperature(); String temperature = String(t); String humidity = String(h); Serial.print( "Enviando dados : [" ); Serial.print( Temperatura ); Serial.print( "," ); Serial.print( Humidade ); Serial.print( "] -> " ); String payload = ""; payload += "\"temperature\":"; payload += temperature; payload += ","; payload += "\"humidity\":"; payload += humidity; payload += ""; char attributes[100]; payload.toCharArray( attributes, 100 ); client.publish( "v1/devices/me/telemetry", attributes ); Serial.println( attributes );
Por fim o Wi-Fi, caso esteja desconectado é conectado novamente e a conexão com a
plataforma Thingsboard é estabelecida, já passando o valor do token para permitir a conexão
void InitWiFi() soft.begin(9600); WiFi.init(&soft); if (WiFi.status() == WL_NO_SHIELD) Serial.println(“Sem Esp"); while (true); Serial.println("Connecting to AP ..."); while ( status != WL_CONNECTED) Serial.print("Tentando se reconectar: "); Serial.println(WIFI_AP);
36
status = WiFi.begin(WIFI_AP, WIFI_PASSWORD); delay(500); Serial.println("Conectado"); void reconnect() while (!client.connected()) Serial.print("Conectado no Thingsboard ..."); if ( client.connect("Arduino Uno Device", TOKEN, NULL) ) Serial.println( "[DONE]" ); else Serial.print( "[FAILED] [ rc = " ); Serial.print( client.state() ); Serial.println( " Reconectando ); delay( 5000 );
A figura 21 apresentada o diagrama esquemático do código para facilitar seu
entendimento.
Figura 21 – Diagrama de processor do código
Fonte: Autoria Própria.
• Carga de Bibliotecas;• Inicialização das variáveis de
conexão wi-fi e Thingsboard;• Configuração inicial dos pinos
e funções.
Setup Inicial
• Configuração do ESP8266 para conexão com a rede Wi-Fi.
Wi-Fi• Coleta das variáveis
ambientais pelo DHT22;• Formação do JSON de carga
no device;• Conexão com o Device.
DHT22-Thingsboard
• Verificação da conexão Wi-Fi e em caso negativo inicialização de uma nova conexão;
• Conexão com o servidor Thingsboard.
Conexão Thingsboard
37
4. RESULTADOS
Após deixar o medidor de variáveis ambientais ligados por aproximadamente 1 hora o
DHT22 coletou aproximadamente 107,942 amostras de temperatura, mas pelo o que foi
observado através da interface serial monitor do Arduino IDE apenas 23 pacotes não foram
enviadas para o servidor web. Isso resulta em uma taxa de 99,97% de coleta de informações. O
principal motivo de interferência na comunicação com o servidor foi a qualidade da internet
sem fio no local de teste. O modem provedor da comunicação sem fio já é antigo e apresenta
perdas de pacote ainda na rede local. Os mesmos testes rodados através de uma rede 4g de
celular apresentaram, também em testes de 1 hora, 100% de transmissão de pacotes.
O segundo levantamento foi o tempo de resposta para alterações de input de leitura. Ao
aproximar uma fonte de calor do sensor este levou aproximadamente 5 segundos para começar
a apresentar os novos resultados, levando em conta o tempo de coleta de novas informações do
DHT22 de 2 segundos e o tempo para a nova fonte de calor se propagar ao sensor é seguro
afirmar que o tempo de resposta é excelente as necessidades de um datacenter.
A figura 22 apresenta o resultado da temperatura e umidade no local de provas sem
alterações de fontes externas de calor.
Figura 22 – Valores medidos sem uso de fontes de calor externas
Fonte: Autoria Própria.
38
A figura 23 apresenta os valores obtidos após a saturação do ambiente com vapor
d’água, aumentando a humidade relativa do ambiente de provas. Pode se observar o aumento
exponencial nas medições até a saturação em 100% de umidade relativa. Visto que o vapor
d’água se encontra a uma temperatura maior do que a temperatura do ar é possível notar também
o incremento na temperatura do local.
Figura 23 – Aumento da humidade relativa do ar.
Fonte: Autoria Própria.
O projeto foi todo desenvolvido utilizando fontes de energia externas. O DHT22 e o
ESP8266 foram alimentados através de uma fonte ajustável de 110V para 3,3V e o Arduino
através interface USB do computador. Em um cenário de implementação o ideal é o uso de
baterias para não necessitar a introdução de novos elementos na rede elétrica do datacenter.
O consumo do ESP866 e o DHT22 ficou em torno de 110mA e do Arduino cerca de
40mA, portanto o consumo total do projeto gira em torno de 150mA. Neste momento o projeto
não levou em conta nenhuma otimização do consumo energético, porém esta seria necessária
para permitir o uso de baterias por longos períodos de tempo.
39
Fatores que podem ser estudados em uma otimização energética para o projeto levam
em conta tanto hardware quanto software. Tanto o Arduino quanto o ESP822 possuem estados
de baixo consumo de energia enquanto não estão funcionando, estes estados, aliado a um
possível agendamento dos períodos de funcionamento do sistema, por exemplo, coletas a cada
5 ou 10 segundos pode reduzir o consumo energético para níveis mais aceitáveis para o uso
com bateria. Alterações mais específicas também podem ser feitas, como por exemplo
desabilitar leds do Arduino e esp8266 e usar um diferente Arduino com menor consumo
energético.
40
5. CONCLUSÃO
Esse projeto realizou o desenvolvimento de um sistema de monitoria de temperatura e
umidade de baixo custo que viabilizasse sua implementação em datacenters de maneira ágil,
barata e com alta confiabilidade.
A análise de performance do sistema demonstra sua confiabilidade, em que mesmo com
redes mais instáveis ou até mesmo redes mais complexas, como de celular sua taxa de
transferência de pacotes fica acima de 99,9%. Seu tempo de feedback fica próximo ao limiar
do próprio sensor DHT22 o que prova sua rápida resposta a drásticas mudanças nas variáveis
medidas e podendo ser aprimorado, dada a necessidade do projeto, pela utilização de outros
sensores. Assim é possível atender as especificações técnicas estipuladas pela própria TIA-942.
Os valores de produtos do mercado com características semelhantes (conexão sem fio,
geração de alerta, variáveis monitoradas) possuem uma grande variabilidade, mas encontramos
diversos na casa dos milhares de reais (SENSOR, 2018). Uma simples comparação entre o custo
de produção e a facilidade de construção do sistema apresentado nesse trabalho com estes
produtos encontrados no mercado já nos mostra que o sistema está apto a atender as
necessidades mais comuns de pequenos datacenters.
Um ponto importante a ser considerado é que para datacenters maiores e mais
complexos as necessidades de monitoria e detalhamento das funções são mais granulares e
exigem um nível de monitoria que considerem essas variáveis. Para se atender as necessidades
de monitoria como fluxo do ar, altura dos servidores, quantidade de sensores, conflitos de
pacotes na rede, alimentação energética e outros, não só é necessário um sistema mais completo
e ágil, mas também uma rede sem fio capaz de entregar confiabilidade e agilidade no
fornecimento destes dados. Dessa maneira o projeto aqui discutido deve ser estudado para
verificar se ele possui a capacidade de ser incrementado para atender as necessidades citadas.
E se uma rede local pode atender as demandas da mesma forma que redes de sensores.
41
6. TRABALHOS FUTUROS
Para trabalhos futuros existem alguns pontos que podem ser estudados e discutidos
quanto a sua viabilidade. Estes pontos podem ser separados em dois grandes grupos, atender
necessidades corporativas de datacenters maiores e mais complexos e baratear o custo de
fabricação do projeto citado.
Para atender as necessidades de datacenters mais complexos alguns detalhes devem ser
considerados, como por exemplo: a capacidade de medição de fluxo de ar, a integração de mais
sensores para a medição em diferentes alturas dos servidores e a implementação de uma rede
que consiga gerencia a presença de diversos medidores ao mesmo tempo.
Pensando em baratear os custos de produção deste projeto uma das possibilidades é a
implementação do código dentro do chip ESP8266. Uma técnica recente e que está começando
a ganhar força em outros projetos é a capacidade de remover o firmware do próprio ESP e rodar
o código nele, eliminando a necessidade do Arduino e assim barateando ainda mais o projeto.
42
7. REFERÊNCIAS BIBLIOGRÁFICAS
Forbes. Amazon.com Goes Down, Loses $66,240 Per Minute, outubro 2013.
https://www.forbes.com/sites/kellyclay/2013/08/19/amazon-com-goes-down-loses-66240-per-
minute/#1d097606495c (acessado em janeiro de 2018)
ANS. Acordo de nível de serviço. Disponível em:< https://pt.wikipedia.org/wiki/Acordo_de_n%C3%ADvel_de_servi%C3%A7o>. Acesso em: 15/03/2018.
Baguete. BRDigital depois do incêndio. Disponível ein: < https://www.baguete.com.br/noticias/13/03/2018/brdigital-depois-do-incendio>. Acesso em 10 de maio de 2018
Sadler, R. Video Demand Drives up Global CO2 Emissions. Disponível em: http://climatenewsnetwork. net/video-demand-drives-global-co2-emissions/ Acesso em 10 junho 2017.
Khalaj, A.H.; Scherer, T.; Halgamuge, S.K. Energy, environmental and economical saving potential of data centres with various economizers across Australia. Appl. Energy 2016
ISO. ISO/IEC 30134-2:2016. Disponível em <: https://www.iso.org/standard/63451.html>. Acessado em 10 de junho 2018.
GOOGLE, 2018. Efficiency: how we do it. Google—Data Centers. Disponível em <: https://www.google.com/about/datacenters/efficiency/internal/>. Acessado em 15 de abril de 2018
FACEBOOK, 2016. Forest City Data Center—PUE/WUE. Disponível em<: https://www. facebook.com/ForestCityDataCenter/app/288655784601722/>. Acessado em 10 de junho de 2018.
Digital Realty Trust 2013. North America Campos Survey Results. Disponível em <: https://c.na6.content.force.com/sfc/dist/version/download?oid=00D300000005uRq&ids=06880000000k573&d=/a/80000000CpC7/k_RJOcsv31zvPC4hgEz9NMQjNd0m4KjS_CzGO5_ni48% 3D&viewId=05H80000000EDGV&operationContext=DELIVERY.> Acessado em 10 de junho de 2018
43
Bell, Geoffrey C., Cliff Federspiel. September 2009. Demonstration of Datacenter
Automation Software and Hardware (DASH) at the California Franchise Tax Board
California Energy Commission. Disponível em <:
https://escholarship.org/uc/item/639529jk>
Pinheiro, E., W. D. Weber, and L. A. Barroso, 2007, “Failure Trends in a Large Disk
Drive Population” Proceedings of the 5th USENIX Conference on File and Storage
Technologies (FAST ’07).
WEISS, Beat; TRUONG, Linh. Wireless Sensor Network for Continuously
Monitoring Temperatures in Data Centers. Disponível em:
<http://domino.watson.ibm.com/library/cyberdig.nsf/papers/11D5DB9B654E35AD852578C4
004D6EC1/$File/rz3807.pdf>
LIU, Jie; Zhao, Feng. Project Genome: Wireless Sensor Network for Data Center
Cooling. Disponível em <:
https://www.researchgate.net/publication/255563465_Project_Genome_Wireless_Sensor_Net
work_for_Data_Center_Cooling>
TIA. TIA-942. Disponível em
<:https://manuais.iessanclemente.net/images/9/9f/Tia942.pdf>
Venturi. Wikipedia. Disponível em: < THINGSBOARD. ThingsBoard Global Website.
Disponível em: < https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard/>.
Acesso em: 01 maio.2018.>. Acesso em: 01 maio.2018.
“802.15.4-2015 - IEEE Standard for Low-Rate Wireless Networks” IEEE 802.15
document 15-13-0257-06-0000, 2015.
SOUZA, Anderson; PAIXÃO, Alexsander. A placa Arduino: uma opção de baixo
custo para experiências de física assistidas pelo PC. Instituto de F´ısica, Universidade
Federal do Rio de Janeiro, Rio de Janeiro, RJ, Brasil, 2011.
DHT22. Dht22. Disponível em <: https://leeselectronic.com/en/product/7375.html >.
Acesso em 14 de junho de 2018
ARDUINO. What is Arduino? Arduino, 2018a. Disponivel em: . Acesso em: 13
Fevereiro 2018.
44
KOLBAN, Neil. Kolban's Book on ESP8266.Texas, USA. 2015.
THINGSBOARD. ThingsBoard Global Website. Disponível em: <
https://thingsboard.io/docs/getting-started-guides/what-is-thingsboard/>. Acesso em: 01
maio.2018.
THINGSBOARD,b. ThingsBoard, Global Website. Disponível em: <
https://thingsboard.io/docs/iot-gateway/getting-started/#step-81-mqtt-broker-file-
configuration/>. Acesso em: 01 maio.2018.
SENSOR. Valor de sensor wireless. Disponível em: <https://www.mundoclima.com.br/instrumentos-de-medicao-climatica/higrometros/monitor-de-temperatura-e-umidade-via-internet/>. Acesso em 02/05/2018.
ESP8266. ESP866 PINOUT. Disponível em <: https://iotbytes.wordpress.com/esp8266-pinouts/> . Acesso em 02 de junho de 2018
45
Anexo I – Código desenvolvido
#include "DHT.h"
#include <WiFiEspClient.h>
#include <WiFiEsp.h>
#include <WiFiEspUdp.h>
#include <PubSubClient.h>
#include "SoftwareSerial.h"
#include "ESP8266.h"
#define WIFI_AP "Nome_da_sua_rede"
#define WIFI_PASSWORD "Senha da sua rede Wifi"
#define TOKEN "Token_do_devide_thingsboard"
// DHT
#define DHTPIN 4
#define DHTTYPE DHT22
char thingsboardServer[] = "demo.thingsboard.io";
// Inicialização do esp8266
WiFiEspClient espClient;
// Inicialização do dht22
DHT dht(DHTPIN, DHTTYPE);
// Encapsulamento MQTT payload
PubSubClient client(espClient);
// Declaração
SoftwareSerial soft(2, 3); // RX, TX
46
ESP8266 wifi(soft);
int status = WL_IDLE_STATUS;
unsigned long lastSend;
void setup()
// Initializando portas serial e de envio para thingsboard. Atenção ao valor de 9600 que pode
ser diferente dependendo do esp
Serial.begin(9600);
dht.begin();
InitWiFi();
client.setServer( thingsboardServer, 1883 );
lastSend = 0;
void loop()
status = WiFi.status();
if ( status != WL_CONNECTED)
while ( status != WL_CONNECTED)
Serial.print("Tentando conectar a rede Wifi: ");
Serial.println(WIFI_AP);
status = WiFi.begin(WIFI_AP, WIFI_PASSWORD);
delay(500);
Serial.println("Conectado");
if ( !client.connected() )
reconnect();
if ( millis() - lastSend > 2000 )
getAndSendTemperatureAndHumidityData();
47
lastSend = millis();
client.loop();
void getAndSendTemperatureAndHumidityData()
Serial.println("Coletando dados:");
// Coleta humidade
float h = dht.readHumidity();
// Coleta Temperatura
float t = dht.readTemperature();
String temperature = String(t);
String humidity = String(h);
// Debugging messages da formação do payload e envio
Serial.print( "Enviando dados : [" );
Serial.print( Temperatura ); Serial.print( "," );
Serial.print( Humidade );
Serial.print( "] -> " );
// Montando JSON para envio do payload
String payload = "";
payload += "\"temperature\":"; payload += temperature; payload += ",";
payload += "\"humidity\":"; payload += humidity;
payload += "";
// Envio do payload
char attributes[100];
payload.toCharArray( attributes, 100 );
client.publish( "v1/devices/me/telemetry", attributes );
48
Serial.println( attributes );
void InitWiFi()
// Initializando ESP
soft.begin(9600);
// initialize ESP module
WiFi.init(&soft);
if (WiFi.status() == WL_NO_SHIELD)
Serial.println(“Sem Esp");
// don't continue
while (true);
Serial.println("Connecting to AP ...");
// Conectando na rede
while ( status != WL_CONNECTED)
Serial.print("Tentando reconectar: ");
Serial.println(WIFI_AP);
status = WiFi.begin(WIFI_AP, WIFI_PASSWORD);
delay(500);
Serial.println("Conectado");
void reconnect()
while (!client.connected())
Serial.print("Conectado no Thingsboard ...");
if ( client.connect("Arduino Uno Device", TOKEN, NULL) )
Serial.println( "[DONE]" );
else
Serial.print( "[FAILED] [ rc = " );
49
Serial.print( client.state() );
Serial.println( " Reconectando );
delay( 5000 );
