Trabalho de Conclusão de Curso

Sistema de monitoramento de varíaveis ambientais

em terapia intensiva utilizando Internet das Coisas

Arthur Monteiro Alves Melo

monteiroamelo@gmail.com

Orientador:
Prof. Dr. André Luiz Lins de Aquino

Maceió, Setembro de 2018

 Arthur Monteiro Alves Melo

Sistema de monitoramento de varíaveis ambientais

em terapia intensiva utilizando Internet das Coisas

Monografia apresentada como requisito parcial para

obtenção do grau de Bacharel em Engenharia de
Computação do Instituto de Computação da Univer-
sidade Federal de Alagoas.

Orientador:

Prof. Dr. André Luiz Lins de Aquino

Maceió, Setembro de 2018

 Monografia apresentada como requisito parcial para obtenção do grau de Bacharel em
Engenharia de Computação do Instituto de Computação da Universidade Federal de Ala-
goas, aprovada pela comissão examinadora que abaixo assina.

Prof. Dr. André Luiz Lins de Aquino - Orientador

Instituto de Computação
Universidade Federal de Alagoas

Prof. Dr. Fábio José Coutinho da Silva - Examinador

Instituto de Computação
Universidade Federal de Alagoas

Pro. Dr. Rian Gabriel Santos Pinheiro - Examinador

Instituto de Computação
Universidade Federal de Alagoas

Maceió, Setembro de 2018

 Agradecimentos

Agradeço primeiramente aos meus pais, minha mãe, Maria Josiete, que sempre me apoiou
incodicionalmente e me deu todo o suporte necessário, ao meu pai, José Aílton, onde quer
que esteja essa vitória também é sua. Agradeço à minha irmã, Laila, pela paciência e ajuda
nessa caminhada e à minha namorada, Clara, por aguentar eu falando do TCC tantas vezes
e me apoiar em todos os momentos. Agradeço ao meu primo, Edávio Jr, por me ajudar em
todas as etapas do TCC. Por fim, agradeço a todos os meus amigos, familiares e aos pro-
fessores que tanto me fizeram crescer e aprender para chegar a este ponto, pessoalmente e
profissionalmente.

“O primeiro dever da inteligência é desconfiar dela mesma.”

– Albert Einstein

“Você erra todo arremesso que não tenta.”

– Michael Jordan

i
 “You can’t aspire to be loved, because that isn’t going to happen, nor do you want
people to be frightened of you. Stay somewhere in the middle and have them respect
and trust and see you as fair.”
– Sir Alex Ferguson
 Resumo

Uma das grandes preocupações em ambientes de terapia intensiva, além do monitoramento

individual de cada paciente, é o monitoramento do ambiente como um todo. A humaniza-
ção das UTINs (Unidades de Terapia Intensiva Neonatal) é uma das principais metas das ins-
tituições hospitalares. Normas internacionais e nacionais guiam os parâmetros em que tais
ambientes críticos devem se manter. Todos esses aspectos físicos do ambiente podem de-
sequilibrar o comportamento humano, principalmente em recém-nascidos, nos quais qual-
quer alteração é capaz de acarretar déficit no desenvolvimento neuropsicomotor ao longo
de suas vidas. Sendo assim, é necessário manter esse ambiente o mais acolhedor e confor-
tável possível, mantendo níveis de iluminação, ruído, temperatura e umidade com o padrão
de qualidade esperado, propiciando um tratamento seguro e eficaz. O objetivo deste tra-
balho é desenvolver e aplicar um sistema de monitoramento passivo em "tempo real"das
variáveis ambientais em uma UTIN, determinando níveis de ruídos em decibéis, iluminân-
cia em lux, temperatura em celcius e a taxa de umidade no ambiente em porcentagem. O
dispositivo gera dados em tempo real e através de um aplicativo mobile é possível acom-
panhar tais dados. Esse sistema visa uma nova maneira de controle em um ambiente de
terapia intensiva, para que, assim, possa proporcionar mais efetividade no planejamento de
ações que mitiguem condições desfavoráveis e fora dos padrões preconizados de segurança
e qualidade. O monitoramento foi realizado na UTIN da Maternidade Escola Santa Mônica,
onde os dispositivos por lá ficaram durante o período de 31 dias ininterruptos.

Palavras-chave: IoT, Smart Health, Android, Firebase, Sistemas Embarcados, Computa-

ção em Nuvem

iii
 Abstract

One of the major concerns in intensive care settings, apart from the individual monitor-
ing of each patient, is the monitoring of the environment as a whole. The humanization of
NICUs (Neonatal Intensive Care Units) is one of the main goals of hospital institutions. Inter-
national and national standards guide the parameters in which such critical environments
must be maintained. All these physical aspects of the environment can unbalance human
behavior, especially in newborns, in whom any change is capable of causing deficits in neu-
ropsychomotor development throughout their lives. Therefore, it is necessary to keep this
environment as cozy and comfortable as possible, maintaining levels of illumination, noise,
temperature and humidity with the expected quality standard, providing a safe and effective
treatment. The objective of this work is to develop and apply a "real time" passive monitor-
ing system of environmental variables in a NICU, determining noise levels in decibels, lux
illuminance, temperature in celcius and the percentage humidity in the environment. The
device generates data in real time and through a mobile application it is possible to track
such data. This system aims at a new way of control in an intensive care environment, so that
it can provide more effective planning in actions that mitigate unfavorable conditions and
outside the recommended standards of safety and quality. The monitoring was performed
at the NICU of Maternidade Escola Santa Mônica, where the devices were kept during the
period of 31 uninterrupted days.

Keywords:IoT, Smarth Health, Android, Firebase, Embedded Systems, Cloud Computing

iv
Conteúdo

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

1 Introdução 1

2 Fundamentação Teórica 4
2.1 A Importância das Variáveis Ambientais . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Dimensionando o ruído . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 Medindo a iluminância . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.3 Temperatura e a umidade relativa do ar . . . . . . . . . . . . . . . . . . 6
2.2 Sistemas de Tempo Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Aplicações Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4 Computação em Nuvem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 Materiais e Métodos 13
3.1 Arquitetura do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Tecnologias e Ferramentas Utilizadas . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Criação do dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.1 Projeto de Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.2 Projeto de Software embarcado . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Criação da aplicação Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5 Conexão com o Firebase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.1 Enviando os Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5.2 Consultando dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4 Resultados e Discussões 27
4.1 Posicionamento dos Dispositivos . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Monitoramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.1 Iluminação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.2 Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2.3 Umidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.4 Ruído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Considerações Finais 39

Referências bibliográficas 40

v
Lista de Figuras

2.1 A porção óptica do espectro eletromagnétic. [Retirada de (Ryer, 1997)] . . . . . 5

2.2 Iluminância. [Retirada de (Ryer, 1997)] . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Relação entre a pressão vapor com a temperatura. [Retirada de https://
commons.wikimedia.org/wiki/File:Water_vapor_pressure_graph.
jpg ] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 Ar sendo aquecido em cubo hermético. [Retirada de (Guths, 2012)] . . . . . . . 8
2.5 Processo de resfriamento de um ar enclausurado. [Retirada de (Guths, 2012)] . 8
2.6 Utilização de sistema operacional em dispositivos móveis. [Retirada de (LTD,
2017)] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1 Diagrama da aquitetura do sistema . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2 Módulo WiFi ESP8266 NodeMCU. [Retirada de https://www.filipeflop.
com/produto/modulo-wifi-esp8266-nodemcu-esp-12/] . . . . . 15
3.3 Sensor de Umidade e Temperatura DHT11. [Retirada de https://www.
filipeflop.com/produto/sensor-de-umidade-e-temperatura-dht11/
] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4 Sensor de Luz BH1750FVI Lux. [Retirada de https://www.filipeflop.
com/produto/sensor-de-luz-bh1750fvi-lux/] . . . . . . . . . . . 16
3.5 Sensor de som Grove. [Retirada de https://www.filipeflop.com/
produto/sensor-de-som-grove/] . . . . . . . . . . . . . . . . . . . . . 17
3.6 Firebase Authentication. [Retirada de (Firebase, 2018)] . . . . . . . . . . . . . . 18
3.7 Firebase Realtime Database. [Retirada de (Firebase, 2018)] . . . . . . . . . . . . 18
3.8 Esquemático do Circuito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.9 Figura do circuito na protoboard . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.10 Imagem frontal do dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.11 Monitoramento de tempo real do ruído . . . . . . . . . . . . . . . . . . . . . . 23
3.12 Monitoramento de tempo real da iluminância . . . . . . . . . . . . . . . . . . 24
3.13 Acessando Firebase pelo microcontrolador . . . . . . . . . . . . . . . . . . . . 24
3.14 Árvore criada no banco de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.15 Estrutura dos dados salvos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.16 Consultando os dados em tempo real na nuvem . . . . . . . . . . . . . . . . . 26
4.1 Dispositivo 1, posicionado próximo as incubadoras . . . . . . . . . . . . . . . 28
4.2 Dispositivo 2, posicionado próximo a pia comum do box . . . . . . . . . . . . . 28
4.3 Dispositivo 3, posicionado próximo a lixeira e a pia de serviço . . . . . . . . . . 29
4.4 Janelas e iluminação artificial do Box 1 . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Tecido para atenuar iluminação dentro da incubadora . . . . . . . . . . . . . . 30
4.6 Monitoramento da iluminância feito pelo dispositivo 3 durante as 4 semanas . 31
4.7 Monitoramento da iluminância feito pelo dispositivo 1 durante as 4 semanas . 32
4.8 Monitoramento da temperatura no final de semana . . . . . . . . . . . . . . . 33

vi
LISTA DE FIGURAS vii

4.9 Monitoramento da temperatura no início da semana . . . . . . . . . . . . . . . 34

4.10 Monitoramento da umidade no final de semana . . . . . . . . . . . . . . . . . 35
4.11 Monitoramento da umidade no início da semana . . . . . . . . . . . . . . . . . 35
4.12 Monitoramento feito pelo dispositivo 1 nos dias 12/07 e 17/07 . . . . . . . . . . 37
4.13 Monitoramento feito pelo dispositivo 2 nos dias 12/07 e 17/07 . . . . . . . . . . 37
4.14 Monitoramento feito pelo dispositivo 3 nos dias 12/07 e 17/07 . . . . . . . . . . 38
Lista de Tabelas

4.1 Resultado de níveis de iluminação nos dispositivos em lux . . . . . . . . . . . . 33

4.2 Resultado da temperatura nos dispositivos em celcius . . . . . . . . . . . . . . 34
4.3 Resultado da umidade relativa do ar nos dispositivos em porcentagem . . . . . 36
4.4 Resultado de níveis de ruídos nos dispositivos em dB(A) . . . . . . . . . . . . . 38

viii
 1
Introdução

O termo Internet das Coisas (em inglês, Internet Of Things) foi citado pela primeira vez por
Kevin Ashton em 1999 no contexto da gestão da cadeia de alimentos (Ashton, 2009). Con-
tudo, ao longo dos anos a definição se abrangeu a uma série de aplicações como saúde,
serviços públicos, transporte e várias outras (Sundmaeker et al., 2010).
O conceito IoT, portanto, visa tornar a Internet ainda mais imersiva e abrangente. Além
disso, ao possibilitar fácil acesso e interação com uma grande variedade de dispositivos
como, por exemplo, eletrodomésticos, câmeras de vigilância, sensores de monitoramento,
atuadores, displays, veículos e assim por diante, IoT formenta o desenvolvimento de diver-
sas aplicações que fazem uso da enorme quantidade e variedade de dados gerados por esses
objetos para fornecer novos serviços aos cidadãos, às empresas e às administrações públicas
(Zanella et al., 2014).
Um estudo recente de McKinsey estima que o impacto de Internet das Coisas será entre
$3.9 até $11 trilhões de doláres em 2025 (McKinsey&Company, 2015). Isso se explica pelo
fato que IoT tem se tornado cada vez mais real e aplicada graças à evolução dos meios de
transmissão e acesso à internet, aumento da capacidade para armazenamento, processa-
mento e análise de dados, somados à diminuição de tamanho e custo dos microprocessado-
res (Guardian, 2016).
Neste cenário complexo, a aplicação do paradigma de IoT para um contexto urbano é
de forte interesse, uma vez que responde à forte pressão de muitos governos nacionais para
adotar soluções de TIC (Tecnologia da Informação e Comunicação) na gestão dos assun-
tos públicos, realizando assim o chamado conceito de Cidades Inteligentes (Schaffers et al.,
2011).
Para (Washburn et al., 2010) Cidades Inteligentes são o uso de tecnologias Smart Com-
puting para tornar os componentes e serviços de infra-estrutura críticos da cidade (que in-
cluem administração municipal, educação, saúde, segurança pública, imóveis, transporte e
utilitários) mais inteligentes, interconectados e eficientes.

1
INTRODUÇÃO 2

São várias as aplicações possíveis usando o conceito de Cidades Inteligentes, dentre elas
o monitoramento e controle de ambientes. Segundo (Aquino, 2015), o ponto chave na defi-
nição de espaços inteligentes é que eles devem possuir uma estrutura especial que permita
aos ocupantes controlarem, programarem automaticamente ou que o próprio ambiente se
adapte autonomamente ao comportamento dos ocupantes.
Todo esse impacto também atinge a medicina, sendo talvez o efeito mais importante
e pessoal. Se estima que em 2020, 40% da tecnologia relacionada à IoT será relacinada à
saúde, mais do que qualquer outra categoria, totalizando $117 bilhões de doláres (Bauer
et al., 2016). Esse casamento de medicina e TIC, comumente denominado Smart Health,
transformarão a saúde como comhecemos, reduzindo custos, ineficiências e salvando vidas.
Os ritmos biológicos são parte da fisiologia dos organismos vivos, existindo enquanto
mecanismos adaptativos ao ambiente. Diversas atividades fisiológicas apresentam compor-
tamento rítmico, sendo o ciclo sono/vigília um dos exemplos mais clássicos de ritmos circa-
dianos manifestados pelo nosso organismo (Marques and Menna-Barreto, 2003).
O período de 24 horas sobre qual se baseia o ciclo anabólico de quase todos os seres vivos
é chamado de ritmo circadiano, ele é influenciado principalmente pela variação de luz, tem-
peratura, ruídos, marés e ventos entre o dia e noite. O rompimento do ritmo circadiano por
exposição à luzes anormais pode fazer com que as várias circunstâncias metabólicas e crô-
nicas se agravem, incluindo tumores, diabetes, depressão e obesidade, como uma resposta
à dessincronização de vários processos fisiológicos.
Nesse contexto, outro fator importante são os níveis de ruído, aos quais os seres humanos
são expostos todos os dias. Os efeitos fisiológicos se iniciam a partir de 65 dB(A) quando o
eixo hipotálamo-hipófise-adrenal é sensibilizado em adultos gerando a secreção de elevados
níveis de adrenalina, noradrenalina e corticosteróides, tendo como consequência a elevação
da pressão arterial, alterações do ritmo cardíaco e vasoconstrição periférica (Oliveira et al.,
2013).
Distúrbios do ciclo sono/vigília são muito comuns em ambientes hospitalares, tanto em
pacientes internados quanto em funcionários que realizam plantões. A disrupção de sono
tem efeitos potencialmente prejudiciais à saúde, sendo que em pacientes internados pode
contribuir para aumento de tempo de internação. O ambiente hospitalar parece agir como
um dificultador da indução e manutenção do ciclo sono/vigília, na medida em que nem
sempre permite contato com a iluminação do ambiente, sujeita os pacientes e funcionários
à iluminação durante a noite e promove interrupção do sono em decorrência das avaliações
e intervenções de rotina e emergenciais (Bano et al., 2014).
A qualidade de vida das pessoas é influenciada pela qualidade do ar que respiram (Qua-
dros, 2008). No caso especifíco de unidade de saúde, a qualidade do ar pode exercer uma
influência direta e de grande significância na velocidade de recuperação dos pacientes e na
frequência de ocorrência de infecções relacionadas à assistência à saúde, nesse contexto,
temperatura e umidade são as variáveis preponderantes na qualidade do ar em ambientes
INTRODUÇÃO 3

climatizados artificialmente. No Brasil a resolução RE nº 9, da (ANVISA, 2003) estabelece

padrões de referência para a qualidade do ar inteiror, em ambientes climatizados artifici-
almente, de uso público e coletivo. A faixa recomenda as operações das temperaturas, nas
condições internas para verão, deverá variar de 23ºC a 26ºC e no invero a faixa recomen-
dável de operação deverá variar de 20ºC a 22ºC. No caso da Umidade Relativa do ar, a faixa
recomendada nas condições internas para verão deverá variar de 40% a 65%, já no inverno
a faixa recomendável fica entre 35% a 65%.
Todos esses aspectos físicos do ambiente podem desequilibrar o comportamento hu-
mano, principalmente em recém-nascidos, nos quais qualquer alteração é capaz de acar-
retar déficit no desenvolvimento neuropsicomotor ao longo de suas vidas. Sendo assim, é
necessário manter o ambiente da UTIN o mais acolhedor e confortável possível, mantendo
níveis de iluminação, ruído, temperatura e umidade com o padrão de qualidade esperado,
propiciando um tratamento segura e eficaz.
O objetivo do trabalho é desenvolver e aplicar um sistema de monitoramento passivo em
"tempo real"que consiga caracterizar as variáveis ambientais na UTIN (Unidade de Terapia
Intensiva Neonatal) da Maternidade Escola Santa Mônica, determinando níveis de ruídos
em decibéis, iluminância em lux, temperatura em celcius e a taxa de umidade no ambiente
em porcentagem.
Este trabalho se divide como segue: Capítulo 2 é discutido o estado da arte das variáveis
ambientais ruído, iluminância, temperatura e umidade, sistemas de tempo real, aplicações
mobile e computação em nuvem; Capítulo 3 define a arquitetura do sistema, os materias e os
métodos utilizados; Capítulo 4 apresenta os resultados obtidos; e, finalmente, o Capítulo 5
apresenta as considerações finais, concluindo este trabalho.
 2
Fundamentação Teórica

Nesta secção é apresentada uma revisão bibliográfica sobre as variáveis ambientais medi-
das, sistemas de tempo real, dispositivos móveis e computação em nuvem, que são de suma
importância para o desenvolvimento deste trabalho.

2.1 A Importância das Variáveis Ambientais

2.1.1 Dimensionando o ruído

O ruído pode ser visto como uma forma de poluição acústica tanto quanto o óxido de car-
bono (CO) é para o ar (Maisonneuve et al., 2009). Segundo (Aurelio, 2009), o ruído é capaz
de ser conceituado como sendo uma mescla de sons com frequências que não seguem lei
precisa e que diferem entre si por valores imperceptíveis ao ouvido humano, ou ainda, como
sendo qualquer som que cause nas pessoas efeitos inesperados e desagradáveis.
O ouvido humano capta ondas sonoras com frequências compreendidas entre 20 Hz
(sons graves) e 20000 Hz (sons agudos) (Mendez, 1994).
O nível de pressão sonora é o parâmetro utilizado quando o objetivo é a avaliação de
situações de incomodidade ou de risco de trauma auditivo e é expresso por uma relação
logarítmica entre a pressão medida e a pressão de referência.

P 2 P
NPS = 10log( ) = 20log( ) (2.1)
Po Po
onde,

• NPS: Nível de pressão sonora, em decibeis (dB(A))

• log: Base 10

• P: Valor eficaz da pressão, em pascals

4
2.1. A IMPORTÂNCIA DAS VARIÁVEIS AMBIENTAIS 5

• Po: Pressão sonora de referência, em pascals (ABNT, 2017)

2.1.2 Medindo a iluminância

A luz é apenas uma parte das várias ondas eletromagnéticas que voam através do espaço.
O espectro eletromagnético cobre uma gama extremamente ampla, de ondas de rádio com
comprimentos de onda de um metro ou mais, até raios-x com comprimentos de onda in-
feriores a um bilionésimo de metro. A radiação óptica fica entre ondas de rádio e raios-x
no espectro, exibindo uma mistura única de raios, ondas, e propriedades quânticas (Ryer,
1997).

Figura 2.1: A porção óptica do espectro eletromagnétic. [Retirada de (Ryer, 1997)]

A iluminância é uma medida do fluxo fotométrico por unidade de área, ou visível densi-
dade de fluxo. A iluminação é tipicamente expressa em lux (lumens por metro quadrado) ou
pé-velas (lumens por pé quadrado).

φ
E= (2.2)
A
onde,

• E: Iluminância, em lux

• φ: Fluxo luminoso, em lumens

• A: Área, em metros quadrados (USP, 2018)

2.1. A IMPORTÂNCIA DAS VARIÁVEIS AMBIENTAIS 6

Figura 2.2: Iluminância. [Retirada de (Ryer, 1997)]

2.1.3 Temperatura e a umidade relativa do ar

A umidade relativa é comumente definida de duas formas, seja como a relação da pressão
real do vapor de água  para a pressão de vapor de equilíbrio sobre um plano de água ξ
(muitas vezes chamado de pressão de vapor "saturação") (Lawrence, 2005).


UR = 100 (2.3)
ξ
onde,

• UR: Umidade relativa do ar, em porcentagem

• : Pressão real do vapor de água, em pascals

• ξ: Pressão de vapor de equilibiro sobre um plano de água, em pascals

Ou a relação de mistura da massa seca real do vapor de água ω com a razão de mistura
Ω de equilíbrio (ou saturação) à temperatura ambiente e pressão.

ω
UR = 100 (2.4)
Ω
A pressão de vapor é uma propriedade física que depende do valor da temperatura, como
é visto na figura 2.3.
A Umidade relativa apresenta ainda uma peculiaridade: um ar mais quente consegue
suportar mais água na forma de vapor, assim quando a temperatura aumenta a umidade
relativa diminui, e vice versa (Guths, 2012).
2.1. A IMPORTÂNCIA DAS VARIÁVEIS AMBIENTAIS 7

Figura 2.3: Relação entre a pressão vapor com a temperatura. [Retirada de https://
commons.wikimedia.org/wiki/File:Water_vapor_pressure_graph.jpg ]

Em ambientes artificialmentes refrigerados, normalmente essa lógica não é obedecida,

pois sistemas de refrigeração em seu processo de resfriamento retiram a densidade de água
do ar desumidificando o ambiente.
2.2. SISTEMAS DE TEMPO REAL 8

Figura 2.4: Ar sendo aquecido em cubo hermético. [Retirada de (Guths, 2012)]

Figura 2.5: Processo de resfriamento de um ar enclausurado. [Retirada de (Guths, 2012)]

2.2 Sistemas de Tempo Real

Sistemas embarcados são coisas diferentes para pessoas diferentes. Para alguém que traba-
lha em servidores, um aplicativo desenvolvido para um telefone é um sistema embarcado.
Para alguém que escreveu código para pequenos microprocessadores de 8 bits, qualquer
coisa com um sistema operacional não parece muito um sistema embarcado. Uma ma-
neira fácil de definir o termo sem pechinchar sobre a tecnologia é: Um sistema embarcado é
um sistema computadorizado que é construído especificamente para sua aplicação (White,
2011).
O projeto deste tipo de sistema computacional é extremamente complexo por envolver
conceitos até agora pouco analisados pela computação de propósitos gerais. Por exemplo,
as questões de portabilidade e do limite de consumo de potência sem perda de desempe-
nho, a baixa disponibilidade de memória, a necessidade de segurança e confiabilidade, a
possibilidade de funcionamento em uma rede maior, e o curto tempo de projeto tornam o
desenvolvimento de sistemas computacionais embarcados uma área em si (Wolf, 2000).
Executando sistemas computacionais - normalmente identificados como Sistemas Trans-
2.3. APLICAÇÕES MOBILE 9

formacionais - que calculam valores de saída a partir de valores de entrada e depois termi-
nam sesus processamentos como ocorre, por exemplo, com compiladores, programas de
engenharia econômica e programas de cálculo numérico, uma grande parte dos sistemas
computacionais atuais interagem permanentemente com os seus ambientes. Estre esses,
distingue-se os chamados Sistemas Reativos que reagem enviando respostas continuamente
a estímulos de entrada vindos de seus ambientes. Sistemas de tempo real de uma forma ge-
ral se encaixam neste conceito de sistemas reativos: Um Sistema de Tempo Real (STR) é um
sistema computacional que deve reagir estímulos oriundos do seu ambiente em prazos es-
pecíficos (Farines et al., 2000).
Os STRs podem ser classificados a partir do ponto de vista da segurança em:

• Sistemas Não Críticos de Tempo Real: As consequências de uma falha devida ao

tempo é da mesma ordem de grandeza que os benefícios do sistema em operação nor-
mal. Exemplo: Um sistema de caixa bancário;

• Sistemas Críticos de Tempo Real: As consequências de pelo menos uma falha tempo-
ral excedam em muito os benefícios os benefícios normais do sistema. Exemplo: Um
sistema de controle de voo;

É típico, ao estudar sistemas em tempo real, considerar a natureza do tempo, porque os

prazos são instantes no tempo. No entanto, surge a pergunta: "De onde vêm os prazos?". De
um modo geral, os prazos são com base nos fenômenos físicos subjacentes do sistema sob
controle (Laplante and Osaka, 2011). Com um prazo bem estabelecido, é possível criar STRs
de várias maneiras mantendo a integridade e confiabilidade dos dados.

2.3 Aplicações Mobile

Os dispositivos móveis são produtos eletrônicos projetados para serem facilmente levados
de um lugar ao outro. Hoje em dia muito ligados aos smartphones, tables e até smartwatches.
Com a evolução tecnológica em conjunto com a inclusão digital, além do aumento da
quantidade de pessoas que utilizam computadores e smartphones, os dispositivos mó-
veis vêm se tornando um objeto essencial no dia-a-dia. O Brasil superou a marca de um
smartphone por habitante e hoje conta com 220 milhões de celulares inteligentes ativos, de
acordo com a 29ª Pesquisa Anual de Administração e Uso de Tecnologia da Informação nas
Empresas, realizada pela Fundação Getúlio Vargas de São Paulo (FGV-SP) (Lima, 2018).
Os sistemas operacionais mais utilizados nestes dispositivos são o Android e o iOS, sendo
o primeiro utilizado em mais 85% dos dispositivos no segundo quarto do ano de 2016, como
pode ser visto na figura 2.6 (LTD, 2017).
2.3. APLICAÇÕES MOBILE 10

Figura 2.6: Utilização de sistema operacional em dispositivos móveis. [Retirada de (LTD,

2017)]

Há três abordagens normalmente usados para a construção de plataformas mobile:

• Desenvolvimento Nativo: Os aplicativos nativos têm o mais alto desempenho, inter-

face nativa, possuem acesso total aos recursos do dispositivo, usam os recursos de
hardware mais atualizados, a fim de melhorar o desempenho. As aplicações são cons-
truídas em linguagens que a plataforma suporta, como consequência, tem acesso a
IDEs (Integrated Development Environment ou Ambiente de Desenvolvimento Inte-
grado), que fornece as melhores ferramentas para o desenvolvimento, bem como uma
rápida depuração do projeto. Aplicativos para Android podem ser construídos em Java
no Android Studio, e aplicativos para iOS podem ser criados no objetivo C em XCode,
que têm todas as ferramentas para depurar ou para projetar as interfaces e, em se-
guida, verificar o desempenho usando instrumentos. No entanto, o desenvolvimento
do aplicativo nativo precisa de tempo inicial para o aprendizado dos idiomas e das fer-
ramentas fornecidas disponibilizadas pelo fornecedor específico da plataforma e, em
seguida, o desenvolvimento do aplicativo (Smutny, 2013).

• Desenvolvimento Web: Os aplicativos da Web para dispositivos móveis são desenvol-

vidos usando tecnologias padrões, geralmente HTML5, JavaScript e CSS. Esses aplica-
tivos são fáceis de desenvolver, embora não possam usar recursos de hardware especí-
ficos do dispositivo, como câmera ou sensor de GPS, e a falta de aparência e compor-
tamento do aplicativo nativo (Corral et al., 2012).

• Desenvolvimento Híbrido: Os aplicativos híbridos para dispositivos móveis são uma

combinação entre os aplicativos da web e nativo. Esse tipo não funciona tão bem
quanto os outros programas que são baseados em linguagens nativas. Mesmo que
2.4. COMPUTAÇÃO EM NUVEM 11

eles sejam empacotados nativamente, eles não são aplicativos nativos, eles são exe-
cutados no mecanismo da web de plataformas, Webkit no caso de Android e iOS, que
é outra camada entre o usuário e o aplicativo e, portanto, o desempenho não pode
corresponder aos aplicativos nativos (Dalmasso et al., 2012).

Dessa forma, com a disseminação dessa tecnologia e a facilidade de acesso, o desen-

volvimento de aplicações para plataformas mobile (Android, IOS e outros) se tornou uma
tendência para os desenvolvedores.
Neste trabalho foi escolhida a plataforma Android com desenvolvimento nativo, devido
ao número elevado de usuários e ao conhecimento já estabelecido do desenvolvedor na lin-
guagem Java.

2.4 Computação em Nuvem

A computação em nuvem é um modelo para permitir acesso à rede conveniente sob de-
manda para um conjunto compartilhado de recursos de computação configuráveis (por
exemplo, redes, servidores, armazenamento, aplicativos e serviços) que podem ser rapida-
mente provisionados e liberados com esforço mínimo de gerenciamento ou interação com
o provedor de serviços (Zhang et al., 2010).
Os modelos de serviços em nuvem normalmente consistem em PaaS, SaaS, IaaS e BaaS.

• PaaS: Em PaaS (Plataform as a Service), o provedor do sistema faz a maioria das es-
colhas que determinam como a infraestrutura de aplicativos opera, qual o tipo de sis-
tema operacional usado, as APIs (Application Programming Interface que significa em
tradução para o português Interface de Programação de Aplicativos), a linguagem de
programação e os recursos de gerenciamento.

Os usuários criam seus aplicativos com as ferramentas e ambiente de desenvolvi-

mento colaborativo sob demanda do provedor. Os proponentes dizem que a aborda-
gem tem inúmeros benefícios, como o aumento produtividade do programador, per-
mitindo as empresas construir e lançar produtos mais rapidamente e reduzir custos
do desenvolvimento (Lawton, 2008).

• SaaS: SaaS: Software as a Service, é uma forma de disponibilizar softwares e soluções

de tecnologia por meio da internet, como um serviço. Com esse modelo, sua empresa
não precisa instalar, manter e atualizar hardwares ou hardwares. O acesso é fácil e
simples: apenas é necessária a conexão com a internet.

Os aplicativos SaaS também são chamados de softwares baseados na Web, softwares

sob demanda ou softwares hospedados. Independente do nome, eles são executados
nos servidores das empresas provedoras, que têm a responsabilidade de gerenciar o
2.4. COMPUTAÇÃO EM NUVEM 12

acesso e manter a estrutura de segurança de dados, conectividade e servidores neces-

sários para o serviço (SalesForce, 2018).

• IaaS: Infrastructure as a Service (IaaS) é a entrega de hardware (servidor, armazena-

mento e rede) e software (tecnologia de virtualização de sistemas operacionais, sis-
tema de arquivos), como um serviço. É uma evolução da hospedagem tradicional que
não requer nenhum compromisso de longo prazo e permite que os usuários provisio-
nem recursos sob demanda.

Ao contrário dos serviços de PaaS, provedor faz muito pouca gestão que não seja man-
ter o data center operacional e os usuários devem implantar e gerenciar os serviços de
software da maneira que fariam em seus próprios data centers (Bhardwaj et al., 2010).

• BaaS: Um serviço extremamente importante em computação em nuvem é o BaaS

(Backend as a Service). BaaS é um serviço que serve como middleware (programa com-
putacional que faz a mediação entre outros softwares). Ele fornece aos desenvolvedo-
res uma forma para conectar suas aplicações mobile e web a serviços a partir de APIs e
SDKs (Software Development kits).

Esse tipo de serviço auxilia os desenvolvedores a acelerar a criação de aplicações web

e mobile. Em vez de codificar o backend inteiro, o desenvolvedor usa o BaaS para criar
as APIs e conectá-las às aplicações, desta forma a infraestrutura do lado do servidor é
abstraída completamente permitindo ao desenvolvedor se concetrar a experiência de
usuário, o frontend (Batschinski, 2016).

Neste projeto foi usado um serviço BaaS chamado Firebase, uma ferramenta mantida
pelo Google.
 3
Materiais e Métodos

Neste capítulo é mostrada a arquitetura do sistema de monitoramento que foi implemen-

tado para monitorar o comportamento de variáveis ambientais na UTIN da Maternidade
Escola Santa Mônica. São descritas as ferramentas utilizadas, a criação do dispositivo, a
criação da aplicação Android, a configuração e conexão com a API Firebase e os trabalhos
correlatos.

3.1 Arquitetura do Sistema

A plataforma de monitoramento é formada por pelos seguintes componentes:

• Sistema Embarcado: Foram criados três dispositivos para serem posicionados de

acordo com as normas brasileiras NBR10151 e ANVISA na UTIN. Os dispositivos são
idênticos na sua forma física, ou seja, detém dos mesmos sensores e leds, o que muda
em cada um é sua label de identificação, embarcada em software para o reconheci-
mento na nuvem.

• Aplicação Android: Um aplicativo nativo Android para maior perfomace, utilizando

linguagem de programação Java. Esta aplicação está conectada diretamente ao Fire-
base, na qual ela conta com uma camada de autenticação, para só usuários autoriza-
dos poderem visualizar os dados. Sua missão é mostrar as variáveis em tempo real.

• Firebase: É uma plataforma Baas com todas as funcionalidades para a execução deste
projeto. Com ela é possível desenvolver para iOS, Android, Web e IoT já que todo o
backend será configurado e gerenciado pelo próprio (Moribe, 2016).

O sistema segue o seguinte fluxo: os três dispositivos conectados à internet enviam os

dados captados através dos sensores e o timestamp (hora e data), essas informações são en-
capsuladas em um JSON (JavaScript Object Notation), de cada dado para o Real-Time Data-
base do Firebase. No Firebase os dados são separados de acordo com seus respectivos labels

13
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 14

(identificação no banco de dados), assim pode-se distinguir o tipo de variável ambiental e o

dispositivo que a captou. O aplicativo android solicita ao Firebase snapshots do Real-Time
Database, após isso o Firebase envia as solicitações feitas pela aplicação, tais informações
são enviadas e são armazenadas em objetos especifícos de cada tipo de variável, e assim os
dados são mostrados em tela.
A interação entre esses componentes pode ser caracterizada pela figura 3.1.

Figura 3.1: Diagrama da aquitetura do sistema

3.2 Tecnologias e Ferramentas Utilizadas

As tecnologias e ferramentas utilizadas são as seguintes:

• Sistema Embarcado

Para a criação do dispositivo foram usados os seguintes componentes:

– Módulo WiFi ESP8266 NodeMCU: É uma placa de desenvolvimento que com-

bina o chip ESP8266, uma interface usb-serial e um regulador de tensão 3,3V. A
programação pode ser feita usando LUA ou a IDE do Arduino, utilizando via cabo
micro-usb. NodeMCU possui antena embutida e conector micro-usb para co-
nexão ao computador além de 11 pinos de I/O e conversor analógico digital. A
figura 3.2 apresenta um módulo WiFi ESP8266 NodeMCU.

* Padrão IEEE 802.11: Wireless 802.11 b/g/n;

* Frequência de Operação: 2,4GHz-2,5GHz;
* Portas GPIO: têm funcões de PWM, I2C, UART e SPI (Electrodragon, 2017);
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 15

Figura 3.2: Módulo WiFi ESP8266 NodeMCU. [Retirada de https://www.filipeflop.

com/produto/modulo-wifi-esp8266-nodemcu-esp-12/]

– Sensor de Umidade e Temperatura DHT11: É um sensor de temperatura e umi-

dade que permite fazer leituras de temperaturas entre 0ºC e 50ºC e umidade entre
20% e 90%. O elemento sensor de temperatura é um termistor do tipo NTC e o
sensor de Umidade é do tipo HR202, o circuito interno faz a leitura dos sensores
e se comunica a um microcontrolador através do um sinal serial de uma via. A
figura 3.3 apresenta um Sensor de Umidade e Temperatura DHT11.

* Precisão de Umidade: 5,0%;

* Precisão de Temperatura: 2,0 ºC;
* Tempo de Resposta: 2 segundos (Aosong, 2017);
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 16

Figura 3.3: Sensor de Umidade e Temperatura DHT11. [Retirada de https://www.

filipeflop.com/produto/sensor-de-umidade-e-temperatura-dht11/]

– Sensor de Luz BH1750FVI Lux: Ele é capaz de determinar a quantidade de luz

que está incidindo sobre o sensor, se comunica com um microcontrolador atra-
vés de sua interface I2C. A figura 3.4 apresenta um Sensor de Luz BH1750.

* Módulo sensor de luminosidade: GY-302;

* Faixa de Medição: 1 à 65.535 lux;
* Variação de medição: 20%(Rohm, 2010);

Figura 3.4: Sensor de Luz BH1750FVI Lux. [Retirada de https://www.filipeflop.

com/produto/sensor-de-luz-bh1750fvi-lux/]
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 17

– Sensor de som Grove: É uma placa com microfone que detecta o som ambiente
e gera um sinal de acordo com a intensidade do som captado. A figura 3.5 apre-
senta um Sensor de Som Grove.

* Amplificador: LM386;
* Interfaces de comunicação: I2C, UART e SPI (Jiankai, 2015);

Figura 3.5: Sensor de som Grove. [Retirada de https://www.filipeflop.com/

produto/sensor-de-som-grove/]

• Firebase

O Firebase possui diversos recursos, dos quais foram usados nesse projeto os seguin-
tes:

– Autenticação: permite implementar um sistema de autenticação segura e de me-

lhor experiência de login para os usuários finais. Oferece uma solução de identi-
ficação compatível com contas como email normal, conta google, facebook, twit-
ter, github e anônimo.

– Realtime Database: É um banco de dados hospedado na nuvem. Os dados ar-

mazenados como JSON e sincronizados em tempo real com todos os clientes co-
nectados. Os dados são mantidos localmente e, mesmo off-line, os eventos em
tempo real continuam sendo acionados. Ele fornece uma linguagem de regras
flexíveis, denominadas regras de segurança, para definir como os dados são es-
truturados e quando podem ser lidos e gravados. Por meio da integração com
o Firebase Authentication é possível definir quem tem acesso, a quais dados e
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 18

Figura 3.6: Firebase Authentication. [Retirada de (Firebase, 2018)]

.

como esses dados pode ser acessados. O Realtime Database é um banco de da-
dos NoSQL e, por isso, tem otimizações e funcionalidades diferentes de um banco
de dados relacional. Também é permitido realizar backups diários dos dados
enviando-os para a Google Cloud vinculada.

Figura 3.7: Firebase Realtime Database. [Retirada de (Firebase, 2018)]

– Monitoramento e Desempenho: mecanismo que fornece insights sobre o de-

sempenho dos dispositivos conectados, como tempo de inicialização e latência
da rede à qual o usuário está conectado.
Além dessas funcionalidades, existem outras vantagens em utiltizar o serviço do
Firebase. Entre essas vantagens aponta-se: a isenção de responsabilidade, pois
toda a segurança das informações fica sob responsabilidade da Google; a alta
disponibilidade e escalabilidade, pois os servidores da Google possuem extrema
confiabilidade; a alta performance, pois com o realtime database a conexão en-
tre a aplicação e o sistema embarcado com o servidor mantém-se constante; o
baixo custo, visto que não é preciso ter um local físico para alocar servidores e a
economia em tempo, pela disponibilidade de diversas APIs (Firebase, 2018).
3.2. TECNOLOGIAS E FERRAMENTAS UTILIZADAS 19

• CAD

CAD (Computer-Aided Design)), ou projeto e desenho auxilidados por computador

(CADD), é o uso de tecnologias para projetar e documentar projetos. O software CAD
sibstitui o rascunho manual por um processo automatizado (AutoDesk, 2018).

Programas CAD têm vários recursos, dentro eles gráficos vetoriais em 2D ou modela-
gem de superfícies sólidas em 3D, podendo girar o objeto em três dimensões para uma
melhor visualização de qualquer ângulo.

• KiCAD

KiCAD é um software de código aberto para Electronic Design Automation (EDA). O

software lida com captura esquemática e PCB Layout com saída Gerber. Tem extensão
para Windows, Linux e MacOS e é licenciado sob a GNU GPL v3 (KiCAD, 2018).

• C++

C++ é uma linguagem de programação "middle-level"desenvolvida por Bjame Strous-

trup a partit de 1979 na Bell Labs. C++ é executado em uma variadade de plataformas,
como Windows, Mac OS e as várias versões do UNIX (TutorialsPoint, 2018).

• Arduino IDE

É um software de código aberto, que facilita a gravação de código e o upload para

vários tipos de placa além da arduino. Ele é executado no Windows, Mac OS X e Linux
(Arduino, 2018).

• Java

A linguagem de programação Java representa uma linguagem simples, orientada a ob-

jetos, multithread, interpretada, neutra de arquitetura, portável, robusta e segura. A
tecnologia Java é composta de uma linguagem de programação e de uma plataforma
(API e máquina virtual) (Mendes, 2009).

• Android

Android é um sistema operacional baseado no Linux, teve seu desenvolvimento inici-

ado em 2003 pelas empresa Android Inc. e em, 2005, foi adquitira pela Google (Mon-
teiro, 2013).

• Android Studio

Android Studio é a IDE (Integrated Development Environment) oficial para o desen-

volvimento de aplicativos para Android, baseado no InteliJ IDEA. Além do poderoso
editor de código e das ferramentas de desenvolvedor IntelliJ (Studio, 2018).
3.3. CRIAÇÃO DO DISPOSITIVO 20

• BitBucket

É um sistema de controle de versão distribuído que torna mais fácil para o desenvol-
vimento. Aproveita a análise do código de forma mais eficiente com solititações pull.
Usando o bitbucket o código está sempre seguro em seu respectivo repositório. Ele
também pode ser conectado diretamente com o Android Studio (Bitbucket, 2018).

3.3 Criação do dispositivo

A criação do dispositivo se divide na parte de hardware e na parte de software embarcado.

3.3.1 Projeto de Hardware

O dispositivo é formado pelo módulo WiFi ESP8266 NodeMCU, Sensor de Temperatura e
Umidade DHT11, Sensor de Luminância BH1750FVI, Sensor Grove e três LEDs (diodos emis-
sores de luz). Todos os componentes foram soldados à mão numa placa fenolite perfurada
e colocados em uma caixa de MDF (placa de fibra de média densidade) com aberturas na
parte frontal para a passagem dos sensores. Ao todo foram criados três dispositivos idên-
ticos para a captação em três pontos diferentes no ambiente hospitalar, cada dispositivo
conta com uma tomada dedicada a ele com uma alimentação 5V e 1A de corrente. Na figura
3.8 podemos ver o esquemático do projeto, na imagem 3.9 uma ilustração dos componentes
conectados em uma protoboard e, finalmente, a figura 3.10 mostra como ficou a versão final.

Figura 3.8: Esquemático do Circuito

3.3. CRIAÇÃO DO DISPOSITIVO 21

Figura 3.9: Figura do circuito na protoboard

Figura 3.10: Imagem frontal do dispositivo

3.3.2 Projeto de Software embarcado

O software foi criado na linguagem C++ utilizando a IDE Arduino para a programação, ele
foi embarcado no módulo ESP8266 WiFi NodeMCU. O algoritmo conta com as bibliotecas
Firebase Arduino, DHT Adafruit, BH1750, ESP8266WiFi e NTP.

• Firebase Arduino: Uma biblioteca para simplificar a conexão ao banco de dados do

Firebase a partir de clientes arduino. É uma abstração completa da API REST do Fi-
rebase exposta por meio de chamadas C++ de uma maneira amigável para a conexão.
3.3. CRIAÇÃO DO DISPOSITIVO 22

Todas as análises de JSON são tratas pela biblioteca para que o deselvovedor apenas
lide com a programação do controlador.

• DHT Adafruit: É uma biblioteca para os produtos DHTs de sensores de temperatura e

umidade de baixo custo.

• BH1750: Biblioteca para o uso do sensor BH1750FVI. Criando a interface necessária

para a rápida utilização de tal.

• ESP8266WiFi: A biblioteca WiFi para ESP8266. Ela permite se conectar ao wifi com o
kit esp8266 rapidamente, apenas tendo o nome da rede e a chave de acesso.

• NTP: É a bilbioteca do NTP (Network Time Protocol). É o protocolo que permite a sin-
cronização dos relógios dos dispositivos de uma rede como servidores, estações de
trabalho, roteadores e outros equipamentos à partir de referências de tempo confiá-
veis.

Seu funcionamento é simples, primeiro o controlador se conecta ao Firebase, definindo

o seu endereço de host e é fornecido a chave de autenticação para a comunicação com a
API. Após isso o modulo wifi é conectado a internet utilizando o SSID (nome) da rede e seu
password, posteriormente as portas GPIO (General Purpose Input/Output) são ativadas e os
sensores começam a se comunicar com o controlador. A função do protocolo NTP é identi-
ficar a hora e o dia no momento em que os dados são coletados para análise posterior.
Na coleta de dados, tanto as bibliotecas DHT quanto a BH1750 já entregam todas as fun-
ções necessárias para a coleta de temperatura, umidade e luminância. O cálculo do ruído se
remete a fórmula usada na (ABNT, 2003).
Após os dados coletados, cada variável ambiental é salva em um objeto do tipo JSON que
é constituido por: hora de coleta (HH:MM:SS), tipo da variável, e a data do dia (DD/MM/A-
AAA). Estes objetos são enviados a nuvem com uma função push, que sua assinatura requer:
a label salva no Realtime Database e o objeto JSON. Os dados são enviados a cada 30 segun-
dos. Para cada dispositivo foi criada uma label para a sua separação na hora da coleta.
3.4. CRIAÇÃO DA APLICAÇÃO ANDROID 23

3.4 Criação da aplicação Android

O aplicativo proposto nesse trabalho tem a finalidade de permitir que os dados captados
pelos sensores sejam disponibilizadas a todos os usuários com autenticados. Desta forma
o app será um mecanismo simples e objetivo para obter informações do ambiente moni-
torado, de modo que as pessoas interessadas tenham as informações necessárias remota-
mente para tomar as decisões cabíveis. O aplicativo foi desenvolvido na plataforma Android,
que é a mais usada em todo o mundo.
A tela inicial do aplicativo mostra uma área para logar, assim só usuários autorizados vão
ter acesso a esses dados restritos. Após a autorização o usuário é levado a uma tela principal
que contém a monitorização atual das variáveis ambientais e também a média, máxima e
mínima no período do dia (manhã, tarde e noite). É possível também se deslogar do app.

Figura 3.11: Monitoramento de tempo real do ruído

3.5. CONEXÃO COM O FIREBASE 24

Figura 3.12: Monitoramento de tempo real da iluminância

3.5 Conexão com o Firebase

3.5.1 Enviando os Dados

Os dados captados pelo dispositivo são enviados para o Firebase através de uma chave de
acesso a nuvem, como mostra a figura 3.13, e de funções herdadas da biblioteca Firebase
Arduino.

Figura 3.13: Acessando Firebase pelo microcontrolador

Cada dado tem uma identificação onde na árvore do database há uma com o mesmo
nome, assim os dados são rotulados pelo Firebase. Na imagem 3.14 são mostradas as iden-
tificações utilizadas no projeto e a figura 3.15 se pode ver a estrutura dos dados salvos.
3.5. CONEXÃO COM O FIREBASE 25

Figura 3.14: Árvore criada no banco de dados

Figura 3.15: Estrutura dos dados salvos

3.5.2 Consultando dados

Para a consulta dos dados é preciso adicionar o Firebase ao app. Para isso, é necessário
um arquivo de configuração do Firebase chamado google-services.json, onde ele é gerado
automaticamente pelo Firebase.
Com o aplicativo sincronizado ao Firebase, é possível ler os dados salvos no Realtime Da-
tabase, caso o usuário esteja autorizado. Os dados são lidos para cada variável na estrutura
JSON do banco de dados NoSQL (banco de dados não relacional), na figura 3.16 é mostrado
como está sendo a leitura dos níveis de ruído. Com a captação desses dados o uso dele pode
variar de acordo com a necessidade da aplicação.
3.5. CONEXÃO COM O FIREBASE 26

Figura 3.16: Consultando os dados em tempo real na nuvem

 4
Resultados e Discussões

Nesse capítulo são mostrados os resultados do estudo na UTIN da Maternidade Escola Santa
Mônica.
Utilizando os dados obtidos pela monitorização, realizou-se uma análise do comporta-
mento desses dados e a relação deles com o posicionamento de cada grupo de sensores
na UTIN. Ao todo foram captados 406027 dados ambientais, sendo 124897 de iluminância,
124916 de ruído, 78118 de temperatura e 78096 de umidade.
Todos os gráficos e tabelas foram gerados na linguagem R, usando a plataforma RStudio,
devido a sua confiabilidade e precisão ao lidar com funções estatísticas.

4.1 Posicionamento dos Dispositivos

A UTIN da Santa Mõnica é dividida em boxes, o monitoramento ocorreu no Box 01 que pos-
sui área útil 40 m² (8x5m). Esse box dispõe de espaço físico e equipamentos para atender 5
RNs (Recém-nascidos), podendo ser expandido para 6 em caso de necessidade.
Os três dispositivos foram distribuidos no box, cada um ficou a um metro do chão e em
cada extremidade da sala.
Na figura 4.1 temos o dispositivo posicionado próximo às incubadoras, ou seja, a área
mais sensível da UTIN. Na figura 4.2 os sensores foram postos na entrada do box, nesse local
há o movimento mais de profissionais para uso da pia. Já na figura 4.3 o dispositivo foi posto
na outra extremidade , onde há uma grande passagem de profissionais e visitantes, também
pelo uso da pia e da lixeira.

27
4.1. POSICIONAMENTO DOS DISPOSITIVOS 28

Figura 4.1: Dispositivo 1, posicionado próximo as incubadoras

Figura 4.2: Dispositivo 2, posicionado próximo a pia comum do box

4.2. MONITORAMENTO 29

Figura 4.3: Dispositivo 3, posicionado próximo a lixeira e a pia de serviço

4.2 Monitoramento
O sensores ficaram na UTIN durante 31 dias (21/06/2018 até 21/07/2018), porém devido
a queda de transmissão da internet houve alguns momentos em que a comunicação não
ocorreu ou falhou a sincronização com o protocolo NTP.
Relacionado a esses problemas o espaço amostral usado se dividiu entre os períodos
22/06 até 25/07, 28/06 até 29/06, 07/07 até 11/07, 12/07 e 17/07. Assim, os dados analisados
se espalham por 4 semanas sendo possível encontrar padrões e comportamentos peculiares
das variáveis ambientais.

4.2.1 Iluminação
No box existem duas janelas, além da iluminação artificial feita por lâmpadas fluorescentes,
como se pode ver na 4.4.

Figura 4.4: Janelas e iluminação artificial do Box 1

4.2. MONITORAMENTO 30

Figura 4.5: Tecido para atenuar iluminação dentro da incubadora

Com a análise gráfica se notou um padrão no comportamento da luminosidade no am-

biente. Todos os dias a partir de 6 horas da manhã até o começo do meio dia ocorreram os
maiores picos de lux em todos os três dipositivos, inclusive em finais de semana. Isso se deve
a soma da iluminação das janelas, com o aparecimento da claridade do dia, e ao ligamento
das lâmpadas pelos funcionários. As incubadoras ainda contam com um tecido auxiliar 4.5,
para a sua cobertura, fazendo assim uma atenuação dos níveis de iluminação interna.
No dispositivo 3 esses valores se revelaram mais elevados pelo fato de o sensor estar vi-
rado em direção as janelas e próximo de algumas lâmpadas, como mostram os gráficos 4.6.
Se observa medidas na casa de 600 lux, uma claridade fortissima para um ambiente neonatal
ocorrendo diariamente.
Os outros dois dispositivos demostraram comportamento similares, abaixo estão os re-
sultados do dispositivo 1, figura 4.7, que ficou mais próximo das incubadoras.
Podemos ver que os resultados são bem menores que comparados ao dispositivo 3, isso
se deve a posição desse aparelho, que fica na parede onde estão as janelas, onde a incidência
da luz natural é menor. Esse resultado mostra que as incubadores estão na melhor posição
possível, paa que o RN tenha a menor luminosidade e possa se desenvolver normalmente.
4.2. MONITORAMENTO 31

(a) 22/06 - 25/06

(b) 28/06 - 29/06

(c) 07/07 - 11/07

(d) 12/07 e 17/07

Figura 4.6: Monitoramento da iluminância feito pelo dispositivo 3 durante as 4 semanas

4.2. MONITORAMENTO 32

(a) 22/06 - 25/06

(b) 28/06 - 29/06

(c) 07/07 - 11/07

(d) 12/07 e 17/07

Figura 4.7: Monitoramento da iluminância feito pelo dispositivo 1 durante as 4 semanas

4.2. MONITORAMENTO 33

Mínima Máxima Média

Dispositivo 1 15 175 20.42
Dispositivo 2 0 131 24.51
Dispositivo 3 0 645 70.60

Tabela 4.1: Resultado de níveis de iluminação nos dispositivos em lux

Segundo a (ABNT, 2013), que normatiza a iluminação em ambientes de trabalho, indica

que em UTIs a iluminação média ideal durante o dia é 100 lux, e durante a noite, quando os
pacientes estão sob observação, de 20 lux. Durante o dia os dispositivos 1 e 2, tirando alguns
momentos de pico pela manhã, se mantivem bem abaixo do nível preconizado, entretanto
o dispositivo 3, pelos motivos citados anteriormente, ultrapassou bastante o valor normati-
zado. No decorrer da noite o dispositivo 1 e 3 se mantiveram entre os 20 lux, já o dispositivo
2 ficou em torno de 30-50 lux pela noite, mas pelo fato dele estar próximo a entrada do Box,
a iluminação dos corredores ajudou nesse pequeno ganho pela noite.

4.2.2 Temperatura
A refrigeração de toda a UTIN é feita artificialmente através de aparelhos de ar condicio-
nado. A variação da amplitude térmica ocorre devido ao fluxo de pessoas e procedimentos
médicos. Por vezes, os aparelhos de ar condicionado precisam ser desligados para que os
profissionais possam examinar os recém-nascidos, evitando o choque térmico nos bebês.
Em sua maioria, os valores de temperatura se mantiveram entre 23ºC-24ºC, nas figuras
4.8 e 4.9 é feita uma comparação entre o monitoramento no fim de semana, dos dias 07/07
e 08/07, com o início da semana, 09/07 até 11/07.
Durante o final de semana a variação de temperatura ficou entre 22ºC e 25ºC, se man-
tendo na maior parte do tempo entre 23ºC e 24ºC. Já durante o início da semana esse pico
chegou a 26ºC com uma maior instabilidade da temperatura, devido a um maior fluxo e nú-
mero de procedimentos no box da UTIN.

Figura 4.8: Monitoramento da temperatura no final de semana

4.2. MONITORAMENTO 34

Figura 4.9: Monitoramento da temperatura no início da semana

Mínima Máxima Média

Dispositivo 1 21 29 24.64
Dispositivo 2 22 27 24.09
Dispositivo 3 N/A N/A N/A

Tabela 4.2: Resultado da temperatura nos dispositivos em celcius

Os dados foram colhidos durante o inverno, de acordo com a (ABNT, 2008) a faixa reco-
mendável de operação das temperaturas de bulbo seco nas condições internas para inverno
é de 20-22ºC. Como podemos ver, através dos gráficos (4.8 e 4.9) e da tabela 4.2, os valo-
res medidos em quase toda a parte do tempo estavam acima da faixa recomendada, com os
valores mais baixos, 21-22ºC, ocorrendo nos finais de semana.
4.2. MONITORAMENTO 35

4.2.3 Umidade
A umidade, principalmente em ambientes refrigerados artificialmente por ar condiciona-
dos, está relacionada com a temperatura do ambiente. O motivo de o ar condicionado dimi-
nuir a umidade do ar é que quando o ar quente do ambiente entra em contato com a tubu-
lação do gás refrigerante o vapor de água se condença. É por isso que o ar condicionado fica
pingando do lado de fora. Como o ar perdeu água ele fica mais seco. apesar de isso não ser
desejado, acontece junto com o processo de diminuição da temperatura do ambiente.
Essa diminuição é benéfica ao ambiente hospitalar, pois com a umidade menor a proli-
feração de bactérias diminui consideravelmente. Nas figuras 4.10 e 4.11 é feita a comparação
da umidade relativa do ar no mesmo período em que foi feito o da temperatura, por estes
valores estarem diretamente relacionados

Figura 4.10: Monitoramento da umidade no final de semana

Figura 4.11: Monitoramento da umidade no início da semana

Como podemos ver, o comportamento da umidade nos dois gráficos se assemelha muito
com o da temperatura, tanto no final de semana onde a umidade tem uma estabilidade
maior, quanto no início da semana no qual os valores variam e tem uma amplitude supe-
ror.
Como na temperatura, a (ABNT, 2008) que preconiza a umidade relativa do ar em am-
bientes fechados. Os valores recomendáveis para condições internas em inverno são de 35-
4.2. MONITORAMENTO 36

Mínima Máxima Média

Dispositivo 1 39 83 52.09
Dispositivo 2 39 83 52.28
Dispositivo 3 N/A N/A N/A

Tabela 4.3: Resultado da umidade relativa do ar nos dispositivos em porcentagem

65%, tais valores oscilaram mais durantes os dias úteis, já nos finais de semana os níveis
pouco variaram, porém em média estavam no intervalo recomandável pela norma.
4.2. MONITORAMENTO 37

4.2.4 Ruído
Existe um grande número de alarmes sonos (respitadores, oxímetros, berços aquecidos, mo-
nitores cardíacos e bombas de infusão) e pessoas circulando pela unidade.
O dispositivo 1 e 2, que ficaram mais próximos das incubadores e equipamentos que
emitem sinais sonoros demonstraram um comportamento similar, como é possível ver nas
figuras 4.12 e 4.13, no qual a curva de intensidade do ruído se mostrou menor durante a
madrugada e uma parte da manhã, pelo menor movimento de pessoas na área, porém no
restante do dia os níveis de variação aumentaram, chegando a mais de 60 dB(A).

Figura 4.12: Monitoramento feito pelo dispositivo 1 nos dias 12/07 e 17/07

Figura 4.13: Monitoramento feito pelo dispositivo 2 nos dias 12/07 e 17/07

O dispositivo 3, que estava longe dos emissores de sons e da passagem de profissionais,

teve os menores níveis de ruídos captados, atingindo seu máximo na casa de 27 db(A), como
mostra a figura 4.14. Ele também teve um comportamento similar aos outros, com as me-
nores medições no período de madrugada e início da manhã.
Os valores preconizados pela (ABNT, 2003) são de 35-45dB(A), porém em média ,nos dis-
positivos 1 e 2, esses valores ultrapassaram os 50 db(A). No dispositivo 3 a média se mostrou
bastante menor, pelo fato dele estar mais afastado dos emissores de sons e alarmes da UTIN
4.2. MONITORAMENTO 38

Figura 4.14: Monitoramento feito pelo dispositivo 3 nos dias 12/07 e 17/07

Mínima Máxima Média

Dispositivo 1 39 64 53.07
Dispositivo 2 39 64 53.07
Dispositivo 3 22 63 25,89

Tabela 4.4: Resultado de níveis de ruídos nos dispositivos em dB(A)

e também da entrada do box, que tem muita passagem de pessoas resultando em ruídos en-
trando no ambiente. Os menores valores captados ocorreram na faixa da madrugada, pelo
fato do pequeno movimento no box, porém ao decorrer do dia e da noite a um aumento nos
níveis de ruído extrapolando o limiar sugerido pela regra.
 5
Considerações Finais

Este trabalho implementou um sistema de monitorização e avaliou as variáveis ambientais

da UTIN na Maternidade Escola Santa Mônica monitoradas de acordo com as normas esta-
belecidas.
Os dados utilizados foram captados durante o período de 31 dias (21/06/2018 a 21/07/2018).
Em suma, o sistema se comportou bem, em alguns momentos a monitorização foi parada
devido a quedas de energia, desconexão com à internet e falhas no protocolo NTP. O sensor
DHT11 no dispositivo 3 parou de funcionar, mas como tinham mais dois no ambiente não
atrapalhou a análise.
Dos três dispositivos colocados na UTIN um se destacou mais que os outros no quesito
de níveis de iluminação, isso se deu por ele estar virado para o lado da janela, então somou
a iluminação aritifical com a natural, assim obtendo uma média muito superior dos outros.
Mas um fator interessante foi que ele demonstrou a menor média em níveis de ruídos.
Os outros dois dispositivos apresentaram comportamentos parecidos e médias. A parte
mais evidente foi a média da captação de ruído que ficou acima dos 45 db(A) preconiza-
dos para tais ambientes, mostrando a necessidade de diminuir essa poluição sonora para o
melhor desenvolvimento dos RNs.
Notou-se o pouco uso da aplicação Android na monitorização, ficando para as pŕóximas
aplicações a necessidade de um monitor local multiparamétrico que avise caso uma taxa
esteja fora do normal para que os profissionais tenham a informação no momento e a apli-
cação mobile sirva como um suporte aos gestores, mostrando o comportamento dos dados
ao longo do tempo.
Os resultados obtidos servirão para a aplicação de aprendizagem de máquina em estudos
posteriores, devido a grande quantidade de dados colhidos e a riqueza dessas informações.

39
 Referências Bibliográficas

ABNT. Nbr 10151: Acústica - avaliação do ruído em áreas habitadas, visando o conforto da
comunidade - procedimento. ABNT, jun 2003.

ABNT. NBR 16401 - 2 - Instalações de ar-condicionado - Sistemas centrais e unitários. Parte

2: Parâmetros de conforto térmico. ABNT, Rio de Janeiro, set 2008.

ABNT. Nbr iso/cire 8995-1. Technical report, ABNT, 2013.

ABNT. Nbr 10152: Níveis de ruído para conforto acústico. ABNT, dec 2017.

ANVISA. Resolução nº 9. Diário Oficial da União, (14), jan 2003.

Aosong. DHT11 Product Manual: Temperature and humidity module. Aosong,

www.aosong.com, dec 2017.

ALL. Aquino. Cidades inteligentes, um novo paradigma da sociedade do conhecimento.

Blucher Education Proceedings, 1:165–178, 2015.

Arduino. Arduino 1.8.6, aug 2018. URL https://www.arduino.cc/en/Main/Software.

K. Ashton. That internet of things thing. RFID Journal, 2009.

L. Atozeri, G. Lera, and G. Morabito. The internet of things: a survey. Computer Networks,
pages 2787–2895, 2010.

F. Aurelio. Ruído em unidade de terapia intensiva neonatal. Universidade Federal de Santa

Maria, 2009.

AutoDesk. O que é o software cad?, aug 2018. URL

https://www.autodesk.com.br/solutions/cad-software.

M. Bano, F. Chiaromanni, M. Corrias, M. Turco, M. De Rui, P. Amodio, C. Merkel, A.Gatta,

G. Mazzotta, R. Costa, and S. Montagnese. The influence of environmental factors on
sleep quality in hospitalized medical patients. Front Neurol, dec 2014.

40
REFERÊNCIAS BIBLIOGRÁFICAS 41

G. Batschinski. Backend as a service: Prós e contras., jul 2016. URL

https://www.infoq.com/br/news/2016/07/backend-pros-e-contras.

H. Bauer, M. Patel, and J. Vieira. The internet of things: sizing up the opportunity. McKinsey
& Company, jul 2016.

S. Bhardwaj, L. Jain, and S. Jain. Cloud computing: A study of intrastructure as a service

(iaas). International Journal of Engineering and Information Technology, 2010.

Bitbucket, aug 2018. URL https://br.atlassian.com/software/bitbucket.

L. Corral, A. Janels, and T. Remencius. Potential advantages and disadvantages of

multiplatfom development frameworks-a vision on mobile environments. Procedia
Computer Science, 1:1202–1207, 2012.

I. Dalmasso, S. Datta, C. Bonnet, and N. Nikaein. Survey, comparison and evaluation of

cross platform mobile application development tools. In IEEE Xplore press, editor,
Proceedings of the 9th International Wireless Communications and Mobile Computing
Conference (IWCMC), pages 323–328, 2012.

Electrodragon. ESP-12F Esp8266 Wifi Board. Electrodragon, dec 2017.

J. Farines, J. Fraga, and R. Oliveira. Sistema de Tempo Real, volume 1. Universidade Federal
de Santa Caratina, first edition, jul 2000.

Firebase, aug 2018. URL https://firebase.google.com/?hl=pt-br.

L. Geib, A. Cataldo Neto, R. Wainberg, and M. Nunes. Sono e envelhecimento. Revista

Psiquiátrica do Rio Grande do Sul., 25:453–465, 2003.

The Guardian. What is the internet of things?, jul 2016. URL https://www.theguardian.
com/technology/2015/may/06/what-is-the-internet-of-things-google.

S. Guths. Temperatura, umidade e a cápsula do tempo. EDUFBA, pages 79–91, 2012.

L. Jiankai. User Manual: Grove - Sound Sensor. Seeed, www.seedstudio.com, 1 edition, sep
2015.

KiCAD. About kicad, aug 2018. URL http://kicad-pcb.org/about/kicad/.

P. Laplante and S. Osaka. Real-Time Systems Design and Analysis, volume 1. Wiley-IEEE
Press, fourth edition, nov 2011.

M. Lawrence. The relationship between relative humidity and the dewpoint temperature in
moist air: A simple conversion and applications. American Meteorological Society, feb
2005.
REFERÊNCIAS BIBLIOGRÁFICAS 42

G. Lawton. Developing software online with platform-as-a-service technology. Computer, 6

(41):15–20, 2008.

M. Lima. Brasil já tem mais de um smarphone ativo por habitante, diz estudo da fgv, apr
2018. URL https://link.estadao.com.br/noticias/geral,
brasil-ja-tem-mais-de-um-smartphone-ativo-por-habitante-diz-estudo-da-fgv,
70002275238.

M. LTD. Apple vs android - a comparative study 2017., mar 2017. URL https://android.
jlelse.eu/apple-vs-android-a-comparative-study-2017-c5799a0a1683.

N. Maisonneuve, M. Stevens, M. Niessen, P. Hanappe, and L. Steels. Citizen noise pollution

monitoring. 10th Annu. Int. Conf. Digital Gov. Res.: Soc. Netw.: Making Connec. Between
Citizens, Data Gov., pages 96–103, 2009.

N. Marques and L. Menna-Barreto. Cronobiologia: princípios e aplicações. Edusp - Editora

da Universidade de São Paulo., 2003.

D. Martinez, M. Lenz, and L. Menna-Barreto. Diagnóstico dos transtornos do sono

relacionados ao ritmo circaiano. J Bras Pneumol, 2008.

McKinsey&Company. The internet of things: Mapping the value beyond the hype., jun 2015.

D. Mendes. Programação Java com Ênfase em Orientação a Objetos. Novatec, São Paulo, first
edition, 2009.

A. Mendez. Acustica arquitectonica. Universidade Del Museo Social Argentino, pages

96–103, 1994.

J. Monteiro. Google Android: crie aplicações para celulares e tablets. Casa do Código, first
edition, 2013.

F. Moribe. Vantagens de um baas para sua startup., aug 2016. URL https://medium.com/
@fgmoribe/firebase-vantagens-de-um-baas-parasua-startup-38fd3891329a.

Núcleo de pesquisa e estudos Hospital Arqutetura NUPEHA. O impacto da iluminação

artificial e o ambiente de saúde - parte 1., may 2016. URL
www.hosptalarquitetura.com.br.

F. Oliveira, M. Paixa, M. Nascimento, V. Rezende, A. Silva, and C. Silva. Nível de ruído da

unidade de terapia intensiva pediátrica: estudo observacional correlacional. OBJN:
Online Brazilian Journal of Nursing, sep 2013.
REFERÊNCIAS BIBLIOGRÁFICAS 43

M. Quadros. Qualidade do ar em ambientes internos hospitalares: parâmetros

físico-químicos e microbiológicos. Dissertação (Mestrado em Engenharia Ambiental) -
Universidade Federal de Santa Catarina, dec 2008.

Rohm. Digital 16bit Serial Output Type Ambient Light Sensor IC: BH1750FVI. Rohm
Semiconductor, www.rohm.com, rev.c edition, apr 2010.

N. Russel and P. Norvig. Inteligência Artificial, volume 2. Elsevier, 2004.

A. Ryer. Light measurement handbook, 1997.

SalesForce. Novo em saas? bem-vindo!, 2018. URL

https://www.salesforce.com/br/saas/.

H. Schaffers, N. Komninos, M. Pallot, B. Trousse, M. Nilsson, and A. Oliveira. Smart cities

and the future internet: Towards cooperation frameworks for open innovation. The
Future Internet, Lect. Notes Comput. Sci., 6656:431–446, 2011.

E. Silva and E. Menezes. Metodologia da Pesquisa e Elaboração de Dissertação. UFSC, 2000.

P. Smutny. Mobile development tools and cross-platform solutions. In IEEE Xplore Press,
editor, Proceedgins of the 13th International Conference on Carpathian Control (ICCC),
pages 653–656, 2013.

A. Strauss and J. Corbin. Basics of qualitative research: Techniques and procedures for
developing grounded theory. Thousand Oaks:Sage Publications., 1998.

Android Studio. Conheça o android studio, apr 2018. URL

https://developer.android.com/studio/intro/?hl=pt-br.

J. Sundmaeker, P. Guillemin, P. Friess, and S. Woelfflé. Vision and challenges for realising the
internet of things. CERP IoT, 2010.

Telemedicina. Como a internet das coisas pode revolucionar o cuidado com a saúde?, jul
2018. URL http://portaltelemedicina.com.br/
internet-das-coisas-entenda-os-seus-impactos-no-mundo-da-medicina/.

TutorialsPoint. Learn c++, aug 2018. URL

https://www.tutorialspoint.com/cplusplus/.

USP. Conceitos fundamentais: Grandezas luminosas, jul 2018. URL

http://www.fau.usp.br/arquivos/disciplinas/au/aut0213/Material_de_Apoio/
03_-_Ia._Conceito_Fundamentais_%28grandezas_Luminosas%29.pdf.
REFERÊNCIAS BIBLIOGRÁFICAS 44

D. Washburn, U. Sindhu, S. Balaouras, R. Dines, N. Hayes, and L. Nelson. Helping cios

understand smart city initiatives: Defining the smart city, its drivers, and the role of the
cio. Cambridge, MA: Forrester Research, Inc., 2010.

T. Weich, A. Ourique, T. Tochetto, and C. Franceschi. Eficácia de um programa para redução

de ruído em unidade de terapia intensiva neonatal. Revista Brasileira de Terapia
Intensiva, 23(3):327 – 334, 2011.

E. White. Making Embedded Systems, volume 1. O’Reilly Media, first edition, 2011.

W. Wolf. Computer as Components, volume 1. Morgan Kaufmann, first edition, nov 2000.

A. Zanella, N. Bui, A. Castellani, L. Vangelista, and M. Zorzi. Internet of things for smart
cities. IEEE Internet Things Journal, 1:22–32, feb 2014.

Q. Zhang, L. Cheng, and R. Boutaba. Cloud computing: State-of-the-art and research

challenges. J.Internet Sert. Appl., 1(1):7–18, may 2010.