MONITORAMENTO HOSPITALAR PARA AVALIAC˘AO~ REMOTA...

MONITORAMENTO HOSPITALAR PARA AVALIACAO

REMOTA DE PACIENTES

Jean Philipe Sabino da Fonseca

Projeto de Graduacao apresentado ao Curso

de Engenharia Eletronica e de Computacao

da Escola Politecnica, Universidade Federal

do Rio de Janeiro, como parte dos requisitos

necessarios a obtencao do tıtulo de Enge-

nheiro.

Orientador: Miguel Elias Mitre Campista

Rio de Janeiro

Marco de 2018

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politecnica - Departamento de Eletronica e de Computacao

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitaria

Rio de Janeiro - RJ CEP 21949-900

Este exemplar e de propriedade da Universidade Federal do Rio de Janeiro, que

podera incluı-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

E permitida a mencao, reproducao parcial ou integral e a transmissao entre bibli-

otecas deste trabalho, sem modificacao de seu texto, em qualquer meio que esteja

ou venha a ser fixado, para pesquisa academica, comentarios e citacoes, desde que

sem finalidade comercial e que seja feita a referencia bibliografica completa.

Os conceitos expressos neste trabalho sao de responsabilidade do(s) autor(es).

iv

DEDICATORIA

Aos meus avos.

v

AGRADECIMENTO

Agradeco aos colegas e professores do GTA por toda companhia e troca de conhe-

cimento nos anos de laboratorio. Um agradecimento especial ao professor Miguel,

pela dedicacao e apoio em incontaveis momentos durante a graduacao.

Aos meus colegas da TV Globo por todo crescimento pessoal e profissional propor-

cionado no ultimo ano, trabalhar com voces tem sido uma experiencia fantastica.

Um agradecimento especial aos meus superiores Eduardo e Diego, pela sonhada

primeira oportunidade e por todos os conselhos valiosos.

Aos ”sobreviventes”de 2012/2: Marcelo, Lucas, Chau, Andrei e outros. Minha

graduacao so foi possıvel por todo companheirismo e superacao.

A minha namorada Fernanda, por me aturar e me suportar nos momentos difıceis.

Ao meu tio e minhas tias, por todo incentivo e carinho ao longo de todos esses

anos.

Aos meus avos, Arthur e Carmelita, por terem sidos incansaveis em minha educacao.

Tudo o que sou hoje e somente um reflexo do amor de voces.

Ao meu padrasto Lemos, pelo carinho, conselhos e zoacoes nesses mais de dez

anos. Voce e como um segundo pai para mim, muito obrigado por tudo.

Ao meu pai Marcelo, por todos os conselhos, conversas, esporros e historias. Obri-

gado por fazer parte da minha vida.

Por fim, a minha mae Andrea, voce e a pessoal mais especial da minha vida e

palavras nao podem mensurar o quao grato sou por tudo que faz por mim. Muito

obrigado por tudo, eu nao seria absolutamente NADA sem voce.

vi

RESUMO

A Internet das Coisas tem como objetivo a utilizacao dos mais diversos objetos

como produtores de informacao, permitindo a criacao de aplicacoes que analisem

e facam uso desses dados. Este trabalho propoe uma aplicacao para coletar as

condicoes de um ambiente de leito hospitalar, as armazena para consultas posteri-

ores e as expoe de uma maneira amigavel ao usuario final. O ambiente hospitalar

se caracteriza pela necessidade de controle sob alguns aspectos, como sua tempera-

tura, entrada e saıda de indivıduos e qualidade do ar. O sistema tambem permite

que usuarios sejam notificados via dispositivos moveis sobre mudancas no recinto.

Experimentos em um ambiente real foram conduzidos com a aplicacao para ates-

tar o seu funcionamento e mensurar o intervalo de tempo entre coleta e exibicao

de informacoes. Os resultados mostraram que a aplicacao e capaz de descrever as

condicoes do ambiente em detalhes, como a entrada e saıda de pessoas no recinto e

movimentos dentro do ambiente monitorado. Alem disso, os tempos de resposta da

aplicacao nao representam um impeditivo para seu bom funcionamento, mesmo em

um cenario com restricoes de atraso como o hospitalar.

Palavras-Chave: Internet das Coisas, Sensores, Redes de Sensores Sem Fio, Pla-

taforma IoT, Arduino, Raspberry PI.

vii

ABSTRACT

The Internet of Things has as its objective the utilization of the most diverse

objects as information providers, allowing the creation of applications that analyze

and make use of this data. This work proposes an application to collect the con-

ditions of a hospital environment, store them for further use and expose them in a

friendly way to the final user. The hospital environment characterizes itself by the

need of control in some of its aspects, like temperature, the entry and exit of people

and air quality. The system also proposes that users receive notifications via mobile

devices about changes in the environment. Experiments in a real environment were

conducted with the application to attest its working and measure the time interval

between the collection and delivery of information. The results showed that the ap-

plication its capable of describing in details the conditions of the environment, such

as the entry and exit of people and movements inside the monitored environment.

In addition, the response time of the application do not represent an impeditive to

its well-functioning, even in a scenario with delay restrictions such as the hospital

one.

Key-words: Internet of Things, Sensors, Wireless Sensor Networks, IoT Platform,

Arduino, Raspberry PI.

viii

SIGLAS

IoT - Internet Of Things

WSN - Wireless Sensor Networks

RF - Radio Frequencia

IO - Input/Output

API - Application Programming Interface

ix

Sumario

1 Introducao 1

1.1 Organizacao do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Fundamentos Teoricos 4

2.1 Redes de Sensores Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Caracterısticas dos Nos . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Transmissao de Informacoes . . . . . . . . . . . . . . . . . . . 7

2.1.3 Escalabilidade e Tolerancia a falhas . . . . . . . . . . . . . . . 8

2.1.4 Pilha de Protocolos . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Plataformas IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Arquitetura de uma plataforma IoT . . . . . . . . . . . . . . . 10

2.2.2 Conectividade . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 Proposta de Aplicacao e Construcao do Prototipo 14

3.1 Proposta de Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1 Monitoramento do Ambiente . . . . . . . . . . . . . . . . . . . 14

3.1.2 Controle do Ambiente . . . . . . . . . . . . . . . . . . . . . . 16

3.1.3 Consumo das Informacoes . . . . . . . . . . . . . . . . . . . . 17

3.2 Construcao do Prototipo . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Construcao dos Nos . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Configuracao da plataforma IoT . . . . . . . . . . . . . . . . . 23

3.2.3 Aplicacao Movel . . . . . . . . . . . . . . . . . . . . . . . . . 24

4 Testes e Resultados 27

4.1 Captacao de dados em um ambiente . . . . . . . . . . . . . . . . . . . 27

4.2 Tempo de resposta de medicao . . . . . . . . . . . . . . . . . . . . . . 30

x

4.3 Variacao da temperatura . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Conclusao e Trabalhos Futuros 34

Bibliografia 36

A Codigos Fonte 40

xi

Lista de Figuras

2.1 Comportamento de Nos dentro de um Campo Sensorial. . . . . . . . . . . 5

2.2 Interacoes entre os Compartimentos Basicos. . . . . . . . . . . . . . . . . 6

2.3 Divisao de Camadas Dentro de um Componente das RSSF. . . . . . . . . 9

2.4 Visao Geral de uma Plataforma IoT. . . . . . . . . . . . . . . . . . . . . 10

2.5 Componentes Gerais de uma Plataforma IoT. . . . . . . . . . . . . . . . 11

2.6 Envio de um Pacote via Conexao Serial. . . . . . . . . . . . . . . . . . . 12

3.1 Exemplo de Posicionamento Fısico Possıvel dos Nos da Solucao. . . . . . . 16

3.2 No 1 da Aplicacao Proposta. . . . . . . . . . . . . . . . . . . . . . . . . 19




3.6 Hospedeiro da Plataforma IoT. . . . . . . . . . . . . . . . . . . . . . . . 23

3.7 Interface Web da Plataforma IoT. . . . . . . . . . . . . . . . . . . . . . 24

3.8 Painel Principal da Aplicacao Movel. . . . . . . . . . . . . . . . . . . . . 25

3.9 Notificacao no Dispositivo Movel. . . . . . . . . . . . . . . . . . . . . . 26

4.1 Horarios de Ativacao do Sensor da Porta. . . . . . . . . . . . . . . . . . 28

4.2 Horarios de Ativacao do Sensor de Presenca. . . . . . . . . . . . . . . . . 28

4.3 Variacao da Temperatura no Ambiente ao Longo do Tempo. . . . . . . . 29

4.4 Variacao da Luminosidade no Ambiente ao Longo do Tempo. . . . . . . . 30

4.5 Tempo Medio de Resposta dos Sensores. . . . . . . . . . . . . . . . . . . 31

4.6 Tempo de Resfriamento do Sensor de Temperatura. . . . . . . . . . . . . 32

xii

Lista de Tabelas

xiii

Capıtulo 1

Introducao

Em um ambiente hospitalar, a interacao entre medicos e pacientes e crucial. Se-

gundo numeros divulgados pelo Ministerio da Saude em 2014, doencas do coracao e

aparelho circulatorio sao as maiores causas de morte do Brasil [1]. Em relacao a es-

tes quadros, o presidente da Sociedade Brasileira de Arritmias Cardıacas, Adalberto

Longa Filho, afirma que a cada minuto sem atendimento perde-se 10% da chance de

sobrevivencia. Buscando reduzir os tempos de atendimento a pacientes, ambientes

hospitalares vem passando por um processo de informatizacao, sendo um dos exem-

plos bem sucedidos dessa transformacao, o emprego de Sistemas de Informacoes

Hospitalares [2].

Alem do monitoramento aos pacientes, ambientes hospitalares tambem possuem

condicoes e caracterısticas que devem ser controladas. Nessa direcao, pode-se ci-

tar o exemplo das UTIs, que devem ser mantidas fechadas, com alta luminosidade,

temperatura entre 20◦ e 25◦, umidade controlada e outras determinacoes [3]. Nesse

contexto, um sistema de monitoramento tornaria possıvel a identificacao de situacoes

anormais com o paciente ou com ambiente e criacao de alertas para que essas si-

tuacoes possam ser detectadas e resolvidas no menor tempo possıvel. Como de-

safios para essas solucoes de monitoramento, podem ser citados: a necessidade de

rapido processamento de informacoes, para rapida deteccao de situacoes; avaliacao

constante em tempo real das condicoes do ambiente, dada a imprevisibilidade de si-

tuacoes de risco; a comunicacao eficiente com medicos e enfermeiros, possibilitando

respostas ageis a incidentes.

1

Existem trabalhos da literatura que abordam a utilizacao de dispositivos de In-

ternet das Coisas (IoT) [4] para solucoes de monitoramento. Hassanalieragh et

al. [5], por exemplo, propoem o monitoramento remoto de sinais vitais e condicoes

de pacientes a partir de pulseiras inteligentes e celulares. Essas informacoes sao

posteriormente armazenadas em um banco de dados na nuvem e disponibilizadas

para um medico. Outro exemplo e a proposta de Kelly [6], que faz uso de hardware

construıdo de maneira personalizada para monitorar o ambiente de uma residencia,

sendo coletadas informacoes de temperatura, luminosidade e consumo energetico.

Depois, esses dados sao expostos em uma interface web para consumo.

Este projeto possui similaridades com os trabalhos de Hassanalieragh et al e Kelly

ao propor o monitoramento de um ambiente hospitalar baseado em dispositivos IoT e

exposicao de informacoes coletadas. Porem, sao diferenciais positivos a utilizacao de

hardware de prateleira em toda construcao do sistema proposto e a disponibilizacao

de uma aplicacao de dispositivos moveis para medicos e enfermeiros. A arquitetura

da solucao proposta e composta por uma rede de sensores sem fio para a captacao de

informacoes do ambiente, um servidor para receber e armazenar os dados obtidos na

rede de sensores, interfaces graficas para desktop e dispositivos moveis e um sistema

de notificacoes. A solucao tambem e expansıvel para outras aplicacoes, podendo se

utilizar das informacoes coletadas para detectar outros eventos e incidentes.

Para validar o funcionamento da solucao ela foi instalada em um ambiente fe-

chado durante alguns dias. Nesse perıodo de tempo foram avaliadas as condicoes

do ambiente e situacoes que se passaram no recinto, como por exemplo a entrada e

saıda de pessoas e a movimentacao no espaco. As condicoes foram acompanhadas

em tempo real via aplicativo movel e notificacoes. Os resultados foram satisfatorios,

uma vez que nao houve problemas no acompanhamento do estado do ambiente.

Alem disso, foram realizados testes controlados com a intencao de aferir o tempo

necessario para exibicao de informacoes a partir da captacao de cada um dos sen-

sores. Os tempos encontrados nessa avaliacao nao foram impeditivos para o escopo

da solucao proposta.

2

1.1 Organizacao do Texto

O projeto esta dividido em seis capıtulos. No Capıtulo 2 serao apresentados os

fundamentos teoricos basicos dos temas relacionados ao projeto. O Capıtulo 3 apre-

senta a proposta de solucao explicando-a em detalhes. A construcao do prototipo

sera apresentada no Capıtulo 3. Nele serao explicitados detalhes tecnicos dos com-

ponentes da solucao e do processo de prototipagem. Serao abordados no Capıtulo 4

testes realizados e seus resultados. Por fim, o Capıtulo 5 traz a conclusao do projeto

e propoe possıveis trabalhos futuros.

3

Capıtulo 2

Fundamentos Teoricos

Este capıtulo apresenta conceitos teoricos que compoem o tema Internet das Coi-

sas. Esses conceitos serao utilizados ao longo deste trabalho.

2.1 Redes de Sensores Sem Fio

Uma Rede de Sensores Sem Fio (RSSF) e definida como uma rede com diversos

agrupamentos de componentes fısicos capazes de coletar e transmitir dados de um

ambiente. Esses agrupamentos se comunicam sem conexoes fısicas entre si e dire-

cionam os dados coletados ate um Gateway. Na literatura tais agrupamentos sao

comumente chamados de Nos [7].

Cada No tem em sua composicao um processador, memorias RAM e ROM, um

transceptor de radio, um ou mais sensores e uma fonte de alimentacao. O alcance

da comunicacao entre Nos e tipicamente de dezenas de metros e a taxa de trans-

ferencia de dados de kbps. O Gateway recebe os dados de todos os Nos e os repassa

para o controlador, uma Plataforma IoT, que tera suas funcionalidades explicadas

posteriormente nesse capıtulo. Os Nos tipicamente ficam espalhados fisicamente e a

area de cobertura da captura de informacoes e denominada Campo Sensorial, vide

Figura 2.1.

4

Figura 2.1: Comportamento de Nos dentro de um Campo Sensorial.

2.1.1 Caracterısticas dos Nos

Segundo Akyildiz [8] um No e geralmente composto por quatro compartimentos

basicos: Uma unidade sensorial, uma unidade de processamento, uma unidade trans-

ceptora e uma unidade de energia. Eventualmente podem ser tambem incorporadas

a um No unidades extras, como unidades de localizacao ou atuacao.

• Unidade Sensorial: E a unidade que diferencia um No das RSSF de outros

sistemas com capacidade de comunicacao, ela e composta por um ou mais

sensores que sao responsaveis pela coleta de informacoes analogicas presentes

no mundo fısico. Alguns dos exemplos de tipo de informacoes que podem ser

coletadas sao: temperatura, luminosidade, qualidade do ar e ruıdo sonoro.

Normalmente essas informacoes analogicas sao posteriormente tratadas por

um conversor analogico-digital (ADC) antes de serem enviadas ate a proxima

unidade.

• Unidade de Processamento: E o principal responsavel pelo controle de No.

Tipicamente e composto por um processador, memoria e uma pequena unidade

de armazenamento. Nessa unidade os codigos e algoritmos que permitem a

unidade sensorial funcionar de maneira adequada sao executados e ocorre a

coordenacao de toda comunicacao sem fio do No.

• Unidade Transceptora: A comunicacao entre componentes das RSSF e

5

realizada nessa unidade. Aqui sao realizados os procedimentos necessarios

para a conversao dos bits de informacao para radio frequencia (RF) e seu

envio para outro No, alem do recebimento de dados de outros componentes da

RSSF.

• Unidade de Energia: Essa unidade e a responsavel pela alimentacao energetica

de todas as outras unidades. Tipicamente baterias sao utilizadas para RSSF,

mas tambem e possıvel utilizar outras fontes.

Figura 2.2: Interacoes entre os compartimentos basicos.

Devido a natureza da utilizacao dos Nos das RSSF, que costumam ser voltados

para a coleta de dados nos mais diversos ambientes, e recomendado que as unidades

presentes sejam diminutas, assim possibilitando que o No seja de tamanho reduzido.

Alem disso, os Nos idealmente devem consumir pouca energia e serem facilmente

adaptados em novos ambientes. Dentre os fatores citados, a maior preocupacao

atual na construcao de Nos e a questao energetica, ja que em algumas aplicacoes e

inviavel a troca de bateria ou ate mesmo a alimentacao contınua. Se combinado ao

fator ja citado da limitacao de tamanho, fica ainda mais difıcil prover uma fonte de

energia razoavel para essas solucoes.

Dentre as unidades de um No, a mais dispendiosa energeticamente e a unidade

Transceptora. Comunicacoes de RF precisam de modulacao, demodulacao, filtra-

gem e multiplexacao, e cada uma dessas etapas possui gastos energeticos. Para

6

amenizar este problema, a unidade transceptora fica em estado de espera na maior

parte do tempo, sendo somente acionada no recebimento ou no envio de pacotes de

informacao [9].

Tambem e incentivada nas RSSF a utilizacao de grandes quantidades de Nos com

alguns objetivos bem definidos: Maior numero de informacoes coletadas, melhor

alcance de rede e maior tolerancia a falhas. Como esses Nos podem possuir uma alta

quantidade de sensores embutidos, alem de alguns outros componentes, e importante

que o preco individual de cada componente seja baixo, possibilitando a viabilidade

economica das RSSF. Atualmente, componentes populares para a construcao de

solucoes de monitoramento podem ser encontrados por valores baixos. Transceptores

e sensores que atuam na coleta de dados mais comuns, como temperatura e umidade,

podem ser comprados por valores em torno de R$20 reais.

2.1.2 Transmissao de Informacoes

Nas RSSF, Nos se comunicam a partir de um meio sem fio criando links entre

si. Esses links podem ser formados de diversas maneiras, como por exemplo: Radio

Frequencia, optica e acustica.

Na transmissao das informacoes os Nos atuam em dois papeis complementares. O

primeiro deles e o de Gerador de Informacao, nele unidade a sensorial do No capta

informacoes do ambiente atraves dos seus diversos sensores e as transmite adiante

ate outros Nos. O segundo papel possıvel e o de Repassador de Informacao, que

faz o No ser responsavel por transmitir adiante conteudo proveniente de outros Nos.

Devido as limitacoes de hardware anteriormente citadas, o alcance de transmissao

dos Nos costuma ser baixo, fazendo que em algumas aplicacoes sejam necessarios

alguns saltos ate a chegada no Gateway, o que torna o segundo papel especialmente

relevante.

Na transmissao de informacoes, os Nos atuam em dois papeis complementares.

O primeiro deles e o de Gerador de Informacao, onde a unidade sensorial do No

capta informacoes do ambiente atraves dos seus diversos sensores e as transmite

adiante ate outros Nos. O segundo papel possıvel e o de Repassador de Informacao,

7

que faz o No ser responsavel por transmitir adiante conteudo proveniente de outros

Nos. Devidos as limitacoes de hardware, o alcance de transmissao dos Nos costuma

ser baixo, fazendo que em algumas aplicacoes sejam necessarios alguns saltos ate a

chegada no Gateway, o que torna o segundo papel especialmente relevante.

Atualmente, o meio de comunicacao mais utilizado para enlaces entre Nos de

RSSF e o meio sem fio. No meio sem fio, existem algumas frequencias popularmente

utilizadas, como as da banda ISM (Industrial, Scientific and Medical) [10] que sao

popularmente utilizadas por nao exigirem licenca para operacao. Por isso mesmo,

a banda ISM e frequentemente utilizada para comunicacoes telefonicas sem fio e

na criacao de WLANs. Os transceptores mais utilizados na construcao de Nos

RSSF costumam utilizar frequencias dessa banda, o que acarreta na possibilidade

de interferencia proveniente de outros diversos sistemas de comunicacoes sem fio.

2.1.3 Escalabilidade e Tolerancia a falhas

Uma grande quantidade de Nos ajuda a redundancia e melhora a tolerancia a

falhas de uma RSSF, uma vez que esses novos Nos atuam como repassadores de

informacao alternativos para a rede. Desta forma, e importante que protocolos de

rede utilizados nas RSSF sejam capazes de lidar com uma grande quantidade de

dados de maneira eficiente.

Devido as caracterısticas de hardware citadas neste capıtulo, Nos estao mais pro-

pensos a falhar ou ter seu funcionamento interrompido por algum tempo do que

outros sistemas de informacao. Porem, o fato da comunicacao nao seguir sempre

um caminho pre-definido aumenta a tolerancia a falhas [11] das RSSF.

2.1.4 Pilha de Protocolos

Uma pilha de protocolos e utilizada por todos os Nos e pelo Gateway. Os pro-

tocolos desempenham algumas funcoes, como por exemplo: Integrar dados com

protocolos de rede, transportar potencia de maneira eficiente pelo meio sem fio e

promover a cooperacao entre diversos Nos. A pilha de protocolos pode ser divi-

dida como na Figura 2.3 em camadas fısica, de enlace, de rede, de transporte e de

8

Figura 2.3: Divisao das camadas dentro de um componente das RSSF.

aplicacao.

• Camada Fısica: E a camada responsavel pela selecao de frequencias de trans-

missao, modulacao, geracao da portadora e deteccao de sinais. Tipicamente as

frequencia utilizadas e a deteccao de sinais sao fortemente acopladas a unidade

transceptora.

• Camada de Enlace: A camada de enlace e responsavel pela multiplexacao

dos fluxos de dados, deteccao dos quadros e controle de erros. Ela garante uma

comunicacao ponto a ponto e ponto a multiponto em redes de comunicacao.

Nessa camada e implementado o Medium Acess Control (MAC) [12].

• Camada de Rede: Sua principal funcao e o encaminhamento de pacotes

entre os Nos. E especialmente importante na interoperabilidade entre as RSSF

e outras redes ou a Internet.

• Camada de Transporte:: Para comunicacoes em uma RSSF protocolos a

camada de transporte tem como principal funcao o controle de congestiona-

mento.

• Camada de Aplicacao:: Tem como objetivo nas RSSF prover as interfaces

necessarias para habilitar a coleta de dados e o gerenciamento da rede.

9

2.2 Plataformas IoT

Atualmente, muitas das aplicacoes IoT utilizam plataformas de software em con-

junto com as RSSF [13]. A plataforma IoT e responsavel pelo recebimento e arma-

zenamento de dados dos Nos da RSSF, pelo processamento dos dados recebidos para

o uso em aplicacoes e por controlar unidades atuadoras de Nos a partir do envio de

comandos a serem executados. Os Nos enviam seus dados para plataforma IoT via

Gateway, podendo essa comunicacao ser feita de algumas maneiras diferentes. Alem

das caracterısticas anteriores, as plataformas IoT comumente oferecem funcionali-

dades que sao necessarias para certos sistemas ciber-fısicos [14], como por exemplo,

interfaces graficas e motores de gatilhos e regras. De maneira adicional, uma gestao

de Nos e usuarios da plataforma tambem pode existir.

Conforme mostra a Figura 2.4, se analisada de maneira funcional a plataforma

IoT atua como uma camada de integracao para diferentes tipos de Nos, Gateways e

Aplicacoes.

Figura 2.4: Visao geral de uma plataforma IoT.

2.2.1 Arquitetura de uma plataforma IoT

A arquitetura de uma plataforma IoT tıpica [15] pode ser observada na Figura

2.5. Seus componentes sao os seguintes:

10

Figura 2.5: Componentes gerais de uma plataforma IoT.

• Agrupamento de Conexoes: O agrupamento de conexoes serve para inter-

mediar as comunicacoes entre os diversos Gateways e a plataforma IoT e criar

uma transmissao contınua de dados que sera encaminhada para a plataforma.

Como metodo de conexao ao agrupamento de conexoes pode-se citar a conexao

serial. A conexao serial e tipicamente utilizada por dispositivos que possuam

microprocessadores com quantidade limitada de linhas de entrada/saıda (IO),

essas interfaces transmitem um bit por vez, sendo a velocidade desta trans-

missao chamada de baud rate [16]. O funcionamento da conexao serial pode

ser observado na Figura 2.6.

• Barramento de Mensagens: O barramento de mensagens e utilizado para

a implementar a troca de informacoes na plataforma IoT em um modelo pu-

blicador/subscritor. Na maioria dos casos, os publicadores sao o Agrupamento

de Conexoes e os Gatilhos. Ja os subscritores sao a API e o Banco de Da-

dos. A solucao popularmente utilizada para a implementacao dessa funcao e

o RabbitMQ [17].

11

Figura 2.6: Envio de um pacote via conexao serial.

• Banco de Dados: No banco de dados sao armazenadas todas as informacoes

recebidas pelo agrupamento de conexoes, que posteriormente sao utilizadas

para processamento e exposicao. Os bancos de dados de plataformas IoT

podem ser tanto relacionais quanto nao relacionais, porem, pela grande quan-

tidade de dados que a plataforma deve ser capaz de armazenar e manipular

sao preferidas solucoes leves. Sao exemplos de bancos possıveis para platafor-

mas IoT: Sqlite como opcao relacional ou MongoDB para implementacoes nao

relacionais.

• Gatilhos: Camada implementada em codigo que processa as informacoes

armazenadas no banco de dados e gera conclusoes e registros a partir desse

processamento. Um e exemplo e a media de um valor fısico em determinado

perıodo de tempo. As entradas e saıdas dessa camada podem ser configuradas

via API.

• API: Uma API (Aplication Programming Interface) e o componente que expoe

os recursos presentes na plataforma IoT em pontos finais para serem consumi-

dos via metodos HTTP a partir dos mais diversos dispositivos e sistemas.

• Interface Web: Consome os recursos expostos via API para exibicao de

dados em uma interface utilizada nos mais diversos navegadores web.

12

2.2.2 Conectividade

Com o uso da API disponibilizada pela plataforma IoT, diversas aplicacoes

moveis podem ser criadas a partir do consumo de seus pontos finais. Alem da

interacao com a informacao por intefaces web e aplicacoes moveis, tornou-se

comum a integracao de plataformas IoT com servicos de “push notifications”

[18]. Estes servicos servem para gerar alertas nos mais diversos dispositivos em

situacoes configuradas pelo proprio usuario final. Tipicamente, ele se conecta

a um provedor do servico via Internet e este encaminha a notificacao ate um

usuario. Sao exemplos de meios de comunicacao utilizados: Notificacoes de

celular, SMS e E-mail.

13

Capıtulo 3

Proposta de Aplicacao e

Construcao do Prototipo

A proposta apresentada neste capıtulo faz uso dos conceitos teoricos apresentados

no Capıtulo 2 para a construcao de uma aplicacao de monitoramento de ambientes

hospitalares com baixo custo a partir de componentes de prateleira. A aplicacao tem

por objetivo possibilitar que pacientes sejam monitorados em tempo real por medicos

e enfermeiros em um ambiente de leito hospitalar. Os ambientes monitorados podem

ser desde UTIs ate ambientes com pacientes em condicoes menos crıticas, como quar-

tos e enfermarias. Caso algum evento ou condicao anormal ocorra, a aplicacao, alem

de disponibilizar interfaces graficas para acompanhamento individual, pode enviar

notificacoes via celular ou e-mail. Este capıtulo tambem detalha a construcao da

aplicacao. Os componentes escolhidos, as configuracoes realizadas e as codificacoes

necessarias serao apresentados.

3.1 Proposta de Aplicacao

3.1.1 Monitoramento do Ambiente

A partir de determinacoes do Ministerio da Saude [3], unidades de tratamento

intensivo devem ter seus ambientes mantidos em condicoes especiais, como por

exemplo, em termos de temperatura e isolamento. Alem disso, deve-se garantir

que equipamentos de suporte a vida estejam em posicoes especıficas e prontos para

uso. Sao exemplos de equipamentos de suporte a vida monitores cardıacos, bombas

14

de infusao e ventiladores mecanicos. Baseado nesses requisitos, foram escolhidas al-

gumas informacoes de interesse do ambiente para serem coletadas pela aplicacao. A

temperatura, a umidade do ar, a luminosidade e a qualidade do ar sao monitoradas

para garantir que o leito esteja em condicoes adequadas o tempo todo. A partir des-

ses dados e possıvel elaborar estrategias contra a proliferacao de vırus e bacterias,

alem de deteccao de outros possıveis incidentes como um incendio. A entrada e saıda

do leito e movimentacao do paciente tambem sao utilizadas para monitorar o acesso

de possıveis indivıduos nao autorizados, acompanhar a frequencia de atendimento e

garantir que o paciente nao deixe o local. Por fim, ruıdo sonoro e movimentacoes

bruscas no leito sao acompanhados para garantir o bem-estar do paciente.

Este projeto usa sensores para a coleta de todos os dados da aplicacao. As

medicoes relativas as condicoes ambientais sao realizadas por um termometro, um

sensor de umidade, um sensor de luminosidade e um detector de CO2. Ja o con-

trole de movimentacao e composto por um sensor magnetico na porta e um sensor

de movimento dentro do local. Os sensores de distancia ficam posicionados para

equipamentos de suporte a vida. Por fim, um sensor de vibracoes e um microfone

tambem sao instalados no leito do paciente para captar possıveis anomalias.

Os sensores estao acoplados a micro-controladores com transdutores instalados

para a formacao de Nos, estes formam uma RSSF. Os dados coletados sao trafegados

pelo meio sem fio ate chegarem ao Gateway. Ja que a solucao esta em um ambiente

fechado que possui fonte de energia eletrica disponıvel, a alimentacao se da atraves

de tomadas eletricas, ou seja, eliminando o uso de baterias, para que a questao

energetica nao se torne um limitador. A quantidade de Nos e suas posicoes fısicas

podem variar, sendo um exemplo possıvel mostrado na Figura 3.1.

• No 1 (Gateway): Alem de captar informacoes, tambem atua como Gateway.

Posicionado proximo a porta do ambiente, possui o sensor magnetico e um

sensor de distancia.

• No 2: Possui o sensor de presenca e um sensor de distancia. Este No esta

proximo a area de movimentacao no quarto.

15

Figura 3.1: Exemplo de posicionamento fısico possıvel dos Nos da solucao.

• No 3: Composto por termometro, sensor de umidade, sensor de luminosidade

e detector de CO2. Sua posicao ideal e em uma das paredes, possibilitando a

captura correta da luminosidade.

• No 4: Instalado na cama do paciente com os sensores de vibracao e o microfone

para a geracao de alertas.

3.1.2 Controle do Ambiente

Como ja foi citado anteriormente no Capıtulo 2, as informacoes coletadas por uma

RSSF devem ser enviadas ate uma plataforma IoT para serem armazenadas e dispo-

nibilizadas ao usuario final. Nesta proposta de aplicacao e utilizado um hospedeiro

de dimensoes reduzidas e de baixo custo para hospedar a plataforma IoT. Este fica

posicionado proximo ao Gateway da RSSF que faz uso de uma conexao fısica para

o encaminhamento das informacoes ambientais coletadas. Depois de posicionado, o

hospedeiro tem seu sistema operacional instalado, suas redes configuradas e por fim

a plataforma IoT instalada.

16

3.1.3 Consumo das Informacoes

Ao fim dos passos anteriores estao disponibilizadas as informacoes coletadas nos

Nos via interface web, que pode ser acessada por diversos navegadores e dispositivos.

Mesmo com essa interface disponibilizada nativamente pela plataforma, a intencao

e que se faca uso de uma aplicacao movel construıda como a principal forma de

consumo dos dados coletados. Sendo assim, e utilizada uma plataforma IoT que

disponibiliza APIs para consumo via aplicacoes moveis. Com a aplicacao movel e

possıvel que medicos verifiquem a condicao atual e passada de cada um dos sensores

a qualquer momento.

Alem disso, como o hospedeiro esta conectado a Internet, e possıvel utilizar

servicos que gerem alertas direcionados aos medicos e enfermeiros. Esses alertas

sao gerados a partir de informacoes coletadas por qualquer um dos sensores, e po-

dem receber tratamentos como periodicidade e destinatarios a serem notificados.

3.2 Construcao do Prototipo

3.2.1 Construcao dos Nos

Como ja foi explicitado neste capıtulo, a solucao proposta capta dados relevantes

a partir dos Nos de uma RSSF. Como base comum para a construcao dos Nos,

sao utilizadas placas de desenvolvimento Arduino modelo Uno R3 [19], que fazem

o papel de unidade de processamento e assim permitem a conexao e o controle das

outras unidades basicas de um No. Esse controle e implementado em software a

partir de algoritmos escritos em C++, sendo comum para a construcao dos codigos

a utilizacao de bibliotecas, que sao comumente oferecidas por fabricantes para atuar

sobre os componentes que comercializam.

O Arduino Uno e uma placa de desenvolvimento baseada no chip ATmega328 [20].

Ela possui 14 pinos digitais de I/O, 6 entradas analogicas, um oscilador de 16Mhz,

uma entrada USB, uma entrada de alimentacao e um botao de reinicializacao. Para

sua programacao, so e necessaria uma conexao via USB com um computador e o

uso da IDE fornecida pelo fabricante para carregar codigos. O Arduino e uma das

17

plataformas de prototipagem mais utilizadas do mundo e pode ser comprado por

valores inferiores a vinte dolares [21].

O transceptor de um unico chip nRF24l01 [22] e usado para o estabelecimento

das comunicacoes na RSSF. Seu protocolo de comunicacao e o Enhanced ShockBurst

(ESB) [23], um protocolo basico de comunicacao bidirecional embutido em hardware

que inclui armazenamento de pacotes, reconhecimento de pacotes e retransmissao

automatica de pacotes perdidos. A maior vantagem do transceptor selecionado e

seu baixo consumo energetico se comparado com outros modelos de transceptor. O

nRF24l01 foi projetado para operar em faixas de frequencia entre 2,4 e 2,4835 GHz.

Somente um controlador, no caso deste projeto o Arduino, e alguns componentes

passivos sao necessarios para a construcao de um canal de comunicacao. O chip

e configurado e operado por uma Serial Peripheral Interface (SPI) [24] e suas filas

FIFOs internas garantem a passagem de dados estruturados do receptor de radio ate

o micro-controlador. O nRF24l01 possui parametros configuraveis pelo usuario como

canal de frequencia, potencia de transmissao e taxa de transmissao. Combinando

suas caracterıscas de baixo custo, taxa de transmissao relativamente elevada e baixo

consumo energetico, este transceptor e comumente utilizado em prototipos de RSSF.

Por fim, as unidades sensoriais dos quatros Nos foram construıdas a partir de

sensores variados que atendessem a aplicacao proposta com bom desempenho e

baixo custo. Os componentes e caracterısticas dos Nos da RSSF sao os seguintes:

• No 1 (Gateway)

O monitoramento da porta foi realizado por um sensor magnetico MC 38, que

gera uma tensao quando as suas duas placas magneticas estao proximas. Essa

tensao e entao detectada pelo Arduino, que envia para a plataforma IoT essa

informacao. O codigo de controle dessa funcao do No nao utiliza nenhuma

biblioteca em especıfico, somente de uma logica basica de programacao que

envia informacoes quando o circuito magnetico e fechado.

A avaliacao da posicao de equipamentos de suporte a vida foi realizada com

um sensor de distancia ultrassonico modelo HC-SR04 [25], que permite leitura

18

Figura 3.2: No 1 da aplicacao proposta.

de distancias entre 2 cm e 4 m com uma precisao de 3 mm. Para essa leitura

sao enviados oito pulsos de 40kHz ate o objeto e o tempo de retorno desses

pulsos determina a distancia. A logica utilizada para cada sensor e realizada

em sua totalidade pela biblioteca NewPing.h.

Esse No alem de atuar como uma unidade sensorial tambem atua como o

Gateway da RSSF. Dessa forma, o No e conectado diretamente a plataforma

IoT por meio de um cabo USB e envia as informacoes captadas por ele e todos

os outros Nos atraves de uma conexao serial. Essa conexao e implementada

a partir da biblioteca MySensors.h [26], que e responsavel pela coordenacao

da chegada de informacao de todos os outros Nos ate o No 1. A biblioteca

orquestra o transceptor nRF24l01 e estrutura a entrega da informacao para a

plataforma IoT.

• No 2

19


O componente utilizado para a verificacao de movimentos dentro do am-

biente proposto no Capıtulo 3 foi o sensor de presenca HC-SR501 [27]. Seu

funcionamento e baseado no uso de elementos piroeletricos para deteccao de

irradiacao infravermelha emitida pelo corpo humano. Quando umas dessas

irradiacoes e emitida, uma tensao de saıda e criada e enviada ate a saıda di-

gital do Arduino. O controle desse sensor nesse prototipo foi implementado

algumas das funcoes da biblioteca SPI.h.

Alem do sensor de movimento, o No 2 tambem possui um sensor HC-SR04

para controle de distancia de equipamento de suporte a vida e tem seu trans-

ceptor nRF24l01 orquestrado pela MySensors.h.

• No 3

O acompanhamento de temperatura e umidade do ar do No 3 foi realizado

por meio do modulo DHT-11 [28], que possui integrados um termistor e um

sensor de umidade capacitivo. De maneira resumida, o termistor e um com-

20


ponente cuja resistencia e sensıvel a variacoes de calor, assim possibilitando a

afericao da temperatura a partir de sua tensao de saıda. Similar ao termistor,

o sensor capacitivo e um componente que tem sua capacitancia alterada com

variacoes na umidade relativa do ar, ocasionando uma mudanca na tensao de

saıda. O DHT11 possui faixa de operacao de 0 a 50◦C (±2◦C) e 20% a 80%UR

(±5%UR), sendo a implementacao do seu controle realizada por funcoes da

biblioteca dht.h, disponibilizada pelo fabricante.

Para a verificacao da luminosidade do ambiente foi utilizado o modulo

BH1750 [29]. Esse modulo e um chip com um conversor AD de 16 bits que

capta informacoes de luminosidade do ambiente. Essas informacoes sao con-

vertidas para valores digitais em Lux e as transmitidas ate o Arduino a partir

do protocolo I2C. Seu fabricante disponibiliza a biblioteca bh1750.h, que foi

utilizada na logica implementada para o controle do modulo.

21

A ultima responsabilidade do No, de checagem da qualidade do ar no am-

biente, foi implementada com o sensor MQ-2 [30], que faz uma verificacao da

quantidade de partıculas por milhao de C02 no recinto. Essa medicao e possıvel

pois a concentracao dessas partıculas no ar altera a condutividade do sensor,

assim gerando valores de saıda de tensao diferentes para quantidades distintas

de C02. Para o MQ-2 nao foram utilizadas bibliotecas em sua orquestracao,

mas sim um codigo disponibilizado pelo fabricante do sensor.

• No 4


Na deteccao de movimentos bruscos na cama foi utilizado um modulo sensor

SW-420 [31], composto por um sensor de vibracao, um potenciometro e um chip

comparador. Sua ativacao ocorre quando o sensor de vibracao detecta uma

movimentacao acima daquela regulada no chip comparador, essa regulacao e

feita pelo potenciometro. Por suas caracterısticas de funcionamento similares

ao detector da porta, o codigo para utilizacao do SW-420 e identico.

22

Por fim, na captacao de ruıdos sonoros fez-se uso do microfone KY-037 [32],

que gera um sinal analogico de intensidade proporcional ao som ambiente.

Bibliotecas nao foram utilizadas no caso desta funcionalidade, sendo imple-

mentada a partir de uma comparacao simples de valores.

3.2.2 Configuracao da plataforma IoT

Figura 3.6: Hospedeiro da plataforma IoT.

Um Raspberry PI [33] modelo 3B e utilizado como hospedeiro da plataforma IoT,

conforme mostrado na Figura 3.6. O Raspberry Pi e um computador com dimensoes

de 85 x 56 x 17mm e possui as seguintes especificacoes de hardware: processador

quad core 64bits de 1,2GHz, 1GB de RAM, adaptadores WiFi e Bluetooth integra-

dos, quatro portas USB, conector Ethernet e entrada para cartao SD. O sistema

operacional usado no Raspberry foi o Raspbian Stretch, instalado em um cartao

SD classe 10 de 32GB. Qualquer outro hospedeiro poderia ter sido utilizado para

a instalacao da plataforma IoT, porem o Raspberry PI foi escolhido pelo seu baixo

custo e dimensoes reduzidas.

23

A plataforma IoT Domoticz e instalada somente apos a instalacao do sistema

operacional, da atualizacao de pacotes, da configuracao da rede e da resolucao de

dependencias [34]. A plataforma Domoticz e de codigo livre, possui um servidor

web acoplado construıdo em C++ e faz uso de um banco de dados SQLite [35]. O

Gateway que esta conectado via USB tem conexao serial configurada no Domoticz,

processo realizado via interface web atraves de um navegador. Vale mencionar que a

configuracao via linha de comando e uma alternativa. Com o Gateway configurado

na plataforma foi possıvel visualizar todos os Nos da RSSF e exibir os dados coletados

em um painel de controle, como mostra a Figura 3.7.

Figura 3.7: Interface web da plataforma IoT.

3.2.3 Aplicacao Movel

A construcao da aplicacao movel e direcionada aos dispositivos Android. A

aplicacao esta escrita em Java e e baseada em um codigo-fonte disponibilizado pelo

proprio Domoticz. A partir dessa base, o layout da aplicacao e modificado para me-

lhorar a experiencia do usuario final, alem das alteracoes nos alertas e notificacoes

que chegam ate ele. A aplicacao e integrada com o Firebase Cloud Messasing [36],

o servico de notificacao (push notifications) da Google, que notifica o celular do

24

usuario no caso de situacoes configuradas no proprio Domoticz. As Figuras 3.8 e 3.9

demonstram a aplicacao sendo utilizada.

Figura 3.8: Painel principal da aplicacao movel.

25

Figura 3.9: Notificacao no dispositivo movel.

26

Capıtulo 4

Testes e Resultados

Esta capıtulo aborda os experimentos realizados para validar o prototipo

descrito no Capıtulo 3.

4.1 Captacao de dados em um ambiente

Para aferir a capacidade do prototipo construıdo de captar informacoes do ambi-

ente e detectar incidentes a partir desses dados, os Nos e o hospedeiro da Plataforma

IoT foram instalados no local de trabalho de um professor universitario. A instalacao

fısica dos Nos foi feita de maneira similar a da proposta de aplicacao do Capıtulo 3.

A ideia e capturar informacoes que possam ser usadas em um ambiente hospitalar,

mesmo utilizando um cenario diferente. Note que cenario utilizado, os dados pode-

riam ser usados para monitorar o ambiente de trabalho do professor. Os sensores de

som, vibracao e distancia nao foram utilizados neste experimento devido as carac-

terısticas do ambiente. Os resultados do experimento sao de um intervalo de tempo

de 24 horas, porem, os graficos gerados desconsideram 12 horas nas quais o professor

nao estava no ambiente. Os dados coletados sao apresentados nas figuras abaixo.

A Figura 4.1 informa momentos em que a porta foi aberta no ambiente. Com essa

informacao podemos estimar o horario de chegada do professor ao observar a porta

sendo aberta depois de um perıodo longo de porta fechada.

A Fıgura 4.2 apresenta os horarios de ativacao do sensor de presenca no perıodo de

tempo em que o ambiente foi monitorado. Essa informacao e utilizada para perceber

27

Figura 4.1: Horarios de ativacao do sensor da porta.

Figura 4.2: Horarios de ativacao do sensor de presenca.

28

Figura 4.3: Variacao da temperatura no ambiente ao longo do tempo.

movimentos dentro do ambiente.

Ja na Figura 4.3 pode ser observada a variacao de temperatura no perıodo de

monitoramento. Devido ao ar condicionado do recinto, houve quedas de temperatura

na presenca do professor.

Por fim, a Figura 4.4 ilustra a intensidade da luminosidade do ambiente ao longo

do dia. E possıvel reparar picos de luminosidade durante o horario de trabalho do

professor.

E possıvel a partir das Figuras 4.1, 4.2, 4.3 e 4.4 determinar alguns eventos da

rotina do professor. Os horarios de chegada ao trabalho nos dias 22 e 23 foram,

respectivamente, as 9h e as 7h e 48 minutos. Ja o horario de saıda no dia 22 foi

as 16h e 48minutos. Por meio das informacoes de temperatura e luminosidade, que

nao houve seus valores alterados, pode-se concluir que no dia 22 o professor nao

permaneceu em sua sala ao chegar no trabalho, somente retornando ao local as 10h

55 minutos. Os casos de acionamento do sensor de presenca sem abertura de porta

podem ser classificados como a movimentacao do professor dentro do ambiente.

29

Figura 4.4: Variacao da luminosidade no ambiente ao longo do tempo.

Tambem foram detectados casos de outras pessoas no ambiente, via estado ativo

constante no sensor de presenca.

Os resultados obtidos nesse experimento podem ser considerados um sucesso, foi

possıvel identificar eventos com o uso da plataforma. Com o uso da aplicacao movel

e suas notificacoes no escopo original do projeto, e possıvel alertar enfermeiros e

medicos acerca de condicoes detectadas, possibilitando acoes de resposta mais ageis.

4.2 Tempo de resposta de medicao

Esse experimento visa medir o tempo entre o acontecimento de um evento a ser

monitorado e a sua disponibilizacao como informacao no sistema proposto. Para isso,

o comando date do sistema operacional Raspbian foi usado para obter o horario no

hospedeiro em que o evento e registrado. O evento provocado procurou validar cada

um dos sensores utilizados, como o apagar das luzes, o abrir e fechar da porta ou

o movimentar capturado pelo sensor de presenca. Realizada a acao, o instante de

atualizacao da informacao na plataforma IoT e comparado com o obtido via sistema

30

operacional para o mesmo evento. Dez amostras foram produzidas para cada um

dos sensores para exibicao nos graficos dos resultados a partir da media e de uma

barra vertical representando um intervalo de confianca de 95%. Os resultados sao

os apresentados na Figura 4.5:

Figura 4.5: Tempo medio de resposta dos sensores.

Nenhum dos sensores apresentou um tempo de resposta maior do que 5 segundos,

o que os deixa aptos a serem usados em aplicacoes hospitalares. O tempo de resposta

da luminosidade se mostrou alto se comparado com os valores dos outros sensores,

isso pode ter sido ocasionado pelo acumulo de funcoes do seu No, que tem mais

dois componentes acoplados. As respostas dos sensores de distancia e presenca

31

que dividem o mesmo No foram bem similares. Por fim, o sensor da porta obteve

um tempo de resposta alto, algo que nao era esperado devido ao seu codigo simples.

Pode-se concluir, entao, que os tempos de resposta obtidos nao sao impeditivos para

a proposta descrita no Capıtulo 3, uma vez que a acao de um medico ou enfermeiro

e necessaria para a resolucao dos eventos. Levando-se em consideracao o baixo custo

da solucao e que a acao de medicos e enfermeiros tipicamente leva mais tempo do

que 5 segundos, foram obtidos bons resultados nos testes.

4.3 Variacao da temperatura

Com a intencao de avaliar se mudancas abruptas de temperatura captadas pelo

sistema, um recipiente fino de plastico preenchido com gelo foi colocado em con-

tato com o sensor de temperatura. O tempo de inıcio do experimento foi obtido a

partir da funcao date do sistema operacional e, depois, comparado com a variacao

de temperatura exibida na plataforma IoT. A Figura 4.6 apresenta os resultados

obtidos.

Figura 4.6: Tempo de resfriamento do sensor de temperatura.

32

Como pode ser observado na Figura 4.6, a temperatura reportada pelo sistema

decai lentamente ao longo do tempo. Os intervalos no qual a temperatura e redu-

zida variaram entre 3 e 7 segundos, sendo os valores sempre decrescidos de 1◦C. A

temperatura do sensor so se estabilizou em 9◦C apos 114 segundos. Caso ocorra

uma variacao abrupta de temperatura que nao seja ocasionada por um incendio,

medicos e enfermeiros so seriam notificados de tal evento apos algum tempo. Isso

significa que dependendo do evento, outras solucoes precisam ser propostas de forma

complementar.

33

Capıtulo 5

Conclusao e Trabalhos Futuros

Este trabalho propos uma solucao de monitoramento remoto para ambientes hos-

pitalares. A solucao se baseia em conceitos de Internet das Coisas, mais especifica-

mente em redes de sensores e plataformas de Internet das Coisas. No ambiente sao

coletados dados como temperatura, umidade, luminosidade e movimentacao. Esses

dados coletados atraves de sensores sao trafegados em uma rede em malha ate um

Gateway, que encaminha esses dados para uma plataforma de Internet das Coisas.

Na plataforma os dados sao processados e entregues via interface web, aplicacao

movel e notificacao para medicos e enfermeiros. Foram utilizados exclusivamente

componentes de prateleira em toda construcao da aplicacao, tornando-a de baixo

custo.

A validade da aplicacao foi aferida pelo acompanhamento das informacoes geradas

apos instalacao em um ambiente controlado. Foi possıvel observar eventos que acon-

teceram no ambiente a partir do historico combinado dos sensores da aplicacao e das

notificacoes recebidas via aplicacao movel. Alem disso, o desempenho da solucao foi

mensurado a partir de amostras controladas captadas em todos os sensores. Com

elas foram calculados os tempos medios de resposta da aplicacao para cada uma das

variaveis do ambiente.

Como direcao futura pretende-se avaliar a viabilidade de uma versao da aplicacao

alimentada por uma unidade de energia limitada, possivelmente uma bateria conven-

cional, em ambientes hospitalares de baixa criticidade, como enfermarias ou quartos.

Com o uso da bateria, existe a possibilidade das alteracoes serem realizadas nos Nos

34

da solucao. Alem disso, fatores como eficiencia energetica dos sensores e o tempo de

autonomia de cada No devem ser considerados e mensurados. Outra possibilidade

e a construcao de um prototipo que, alem de possuir as capacidades sensoriais da

solucao atual, tambem interaja com o ambiente como um atuador. Em outras pala-

vras, ao detectar determinados eventos seria possıvel atuar nas causas dos mesmos.

Destaca-se tambem que, embora a aplicacao tenha sido construıda para o monitora-

mento de ambientes hospitalares, ela tambem e aplicavel em outros cenarios, como

casas ou cidades inteligentes.

35

Referencias Bibliograficas

[1] Ministerio da Saude, “Uma analise da situacao de saude e das causas externas”,

http://bvsms.saude.gov.br/bvs/publicacoes/saude brasil 2014 analise situacao.pdf,

2014, (Acessado em 11 de janeiro de 2018).

[2] SUZUKI, H., “Hospital information system”, U.S. Patent Application No.

10/650,615, 2005.

[3] Ministerio da Saude, “Portaria numero 466, 04 de junho de 1998”,

http://sna.saude.gov.br/legisla/legisla/uti/GM P466 98uti.doc, 1998, (Aces-

sado em 13 de janeiro de 2018).

[4] XIA, F., YANG, L., WANG, L., “Internet of Things”, International Journal of

Communication and Systems, v. 25, pp. 1101–1102, 2012.

[5] HASSANALIERAGH, M., PAGE, A., SOYATA, T., et al., “Health monitoring

and management using Internet-of-Things (IoT) sensing with cloud-based pro-

cessing: Opportunities and challenges”. In: Services Computing (SCC), 2015

IEEE International Conference on, pp. 285–292, IEEE, 2015.

[6] KELLY, S. D. T., “Towards the implementation of IoT for environmental condi-

tion monitoring in homes”, IEEE Sensors Journal, v. 13, n. 10, pp. 3846–3853,

2013.

[7] YICK, J., MUKHERJEE, B., GHOSAL, D., “Wireless sensor network survey”,

Computer networks, v. 52, n. 12, pp. 2292–2330, 2008.

[8] AKYILDIZ, I., VURAN, M., Wireless Sensor Networks Vol.4. John Wiley &

Sons, 2010.

36

[9] WANG, A. Y., SODINI, C. G., “A simple energy model for wireless microsensor

transceivers”, IEEE Globecom’04, pp. 3205–3209, 2004.

[10] ITU Radio Regulations, “CHAPTER II – Frequencies, ARTICLE 5 Frequency

allocations, Section IV – Table of Frequency Allocations”.

[11] HOBLOS, G., STAROSWIECKI, M., AITOUCHE, A., “Optimal design of

fault tolerant sensor networks”, IEEE International Conference on Control Ap-

plications, pp. 467–472, 2000.

[12] YE, W., HEIDEMANN, J., ESTRIN, D., “An energy-efficient MAC protocol

for wireless sensor networks”. In: INFOCOM 2002. Twenty-First Annual Joint

Conference of the IEEE Computer and Communications Societies. Proceedings.

IEEE, v. 3, pp. 1567–1576, IEEE, 2002.

[13] WORTMANN, F., FLUCHTER, K., “Internet of things”, Business & Infor-

mation Systems Engineering, v. 57, n. 3, pp. 221–224, 2015.

[14] BAHETI, R., GILL, H., “Cyber-physical systems”, The impact of control tech-

nology, v. 12, pp. 161–166, 2011.

[15] VANDIKAS, K., TSIATSIS, V., “Performance evaluation of an IoT platform”.

In: Next Generation Mobile Apps, Services and Technologies (NGMAST), 2014

Eighth International Conference on, pp. 141–146, IEEE, 2014.

[16] Spark Fun, “Serial Communication”, https://learn.sparkfun.com/tutorials/serial-

communication, Acessado em 25 de janeiro de 2018.

[17] JONES, B., LUXENBERG, S., MCGRATH, D., et al., “RabbitMQ perfor-

mance and scalability analysis”, project on CS, v. 4284, 2011.

[18] BELL, K. M., BLEAU, D. N., DAVEY, J. T., “Push notification service”,

Nov. 22 2011, US Patent 8,064,896.

[19] D’AUSILIO, A., “Arduino: A low-cost multipurpose lab equipment”, Behavior

research methods, v. 44, n. 2, pp. 305–313, 2012.

[20] MICROCHIP, “ATmega328”, https://www.microchip.com/wwwproducts/en/ATmega328,

Acessado em 10 de fevereiro de 2018.

37

[21] D’AUSILIO, A., “Arduino: A low-cost multipurpose lab equipment”, Behavior

research methods, v. 44, n. 2, pp. 305–313, 2012.

[22] Nordic Semiconductor, “NRF24L01 Product Specification”,

https://www.nordicsemi.com/eng/content/download/2730/34105/file/nRF24L01 Product Specification v2 0.pdf,


[23] Nordic Semiconductor, “Enhanced ShockBurst Users Guide”,

http://infocenter.nordicsemi.com/topic/com.nordic.infocenter.sdk51.v9.0.0/esb users guide.html,


[24] SparkFun, “Serial Peripheral Interface”, https://learn.sparkfun.com/tutorials/serial-

peripheral-interface-spi, Acessado em 10 de fevereiro de 2018.

[25] NAKATANI, A. M., GUIMARAES, A. V., NETO, V. M., “Medicao com Sensor

Ultrassonico Hc-Sr04”, 2013.

[26] “An Open Source Library for DIY IOT”, http://mysensors.org/download,

(Acessado em 23 de novembro de 2017).

[27] Vida de Silıcio, “Sensor de Movimento HC-SR501”,

https://portal.vidadesilicio.com.br/sensor-presenca-movimento-pir-hc-sr501/,


[28] TIANLONG, N., “Application of Single Bus Sensor DHT11 in Temperature

Humidity Measure and Control System [J]”, Microcontrollers & Embedded Sys-

tems, v. 6, pp. 026, 2010.

[29] Mouser, “Digital 16bit Serial Output Type Ambient Light Sensor IC”,

http://www.mouser.com/ds/2/348/bh1750fvi-e-186247.pdf, Acessado em 10 de

fevereiro de 2018.

[30] RAMYA, V., PALANIAPPAN, B., “Embedded system for Hazardous Gas de-

tection and Alerting”, International Journal of Distributed and Parallel Systems

(IJDPS) Vol, v. 3, pp. 287–300, 2012.

[31] ISMAIL, E. S. B., HABAEBI, M. H., DAOUD, J. I., et al., “Optimized Vibra-

tion Chamber for Landslide Sensory and Alarm System”. In: IOP Conference

38

Series: Materials Science and Engineering, v. 260, p. 012018, IOP Publishing,

2017.

[32] NURJANNAH, I., HARIJANTO, A., SI, M., et al., “Sound Intensity Measuring

Instrument Based on Arduino Board with Data Logger System”, Threshold,

v. 1000, n. 140, pp. 100.

[33] “Small Single-board Computer”, https://www.raspberrypi.org/, (Acessado em

22 de novembro de 2017).

[34] “An Open Source Home Automation System”, http://domoticz.com, (Acessado

em 22 de novembro de 2017).

[35] OWENS, M., ALLEN, G., SQLite. Springer, 2010.

[36] Google, “Firebase Cloud Messaging”, https://firebase.google.com/products/cloud-

messaging/, Acessado em 11 de fevereiro de 2018.

39

Apendice A

Codigos Fonte

Os codigos fonte utilizados na construcao da solucao descrita nesse trabalho estao

disponıveis em: https://github.com/jeanfonseca/MHARP

40

MONITORAMENTO HOSPITALAR PARA AVALIAC˘AO~ REMOTA...

Documents

Transcript of MONITORAMENTO HOSPITALAR PARA AVALIAC˘AO~ REMOTA...