Protótipo de Monitoramento Remoto Da Saúde Do Idoso

I NTITUTO F EDERAL DE G OIÁS
D EPARTAMENTO DE Á REAS ACADÊMICAS IV
C ÍCERO J OASYO M ATEUS DE M OURA
Protótipo de Monitoramento Remoto da

Saúde do Idoso
Goiânia
2018
I NTITUTO F EDERAL DE G OIÁS
D EPARTAMENTO DE Á REAS ACADÊMICAS IV
AUTORIZAÇÃO PARA P UBLICAÇÃO DE T RABALHO DE

C ONCLUSÃO DE C URSO EM F ORMATO E LETRÔNICO
Na qualidade de titular dos direitos de autor, AUTORIZO o Departamento de

Áreas Acadêmicas IV da Intituto Federal de Goiás – IFG a reproduzir, inclusive em
outro formato ou mídia e através de armazenamento permanente ou temporário, bem
como a publicar na rede mundial de computadores (Internet) e na biblioteca virtual da
IFG, entendendo-se os termos “reproduzir” e “publicar” conforme definições dos incisos
VI e I, respectivamente, do artigo 5o da Lei no 9610/98 de 10/02/1998, a obra abaixo
especificada, sem que me seja devido pagamento a título de direitos autorais, desde que
a reprodução e/ou publicação tenham a finalidade exclusiva de uso por quem a consulta,
e a título de divulgação da produção acadêmica gerada pela Universidade, a partir desta
data.
Título: Protótipo de Monitoramento Remoto da Saúde do Idoso
Autor(a): Cícero Joasyo Mateus de Moura
Goiânia, 09 de Março de 2018.
Cícero Joasyo Mateus de Moura – Autor
Me. Otávio Calaça Xavier – Orientador


Saúde do Idoso
Trabalho de Conclusão apresentado à Coordenação do

Curso de Sistemas de Informação do Departamento de
Áreas Acadêmicas IV da Intituto Federal de Goiás, como
requisito parcial para obtenção do título de Bacharel em Sis-
temas de Informação.
Área de concentração: Computação.
Orientador: Prof. Me. Otávio Calaça Xavier
Goiânia
2018

Saúde do Idoso
Trabalho de Conclusão apresentado à Coordenação do Curso de Siste-

mas de Informação do Departamento de Áreas Acadêmicas IV da In-
tituto Federal de Goiás como requisito parcial para obtenção do título
de Bacharel em Sistemas de Informação, aprovada em 09 de Março de
2018, pela Banca Examinadora constituída pelos professores:
Prof. Me. Otávio Calaça Xavier

Departamento de Áreas Acadêmicas IV – IFG
Presidente da Banca
Prof. Me. Sanderson Oliveira de Macedo

Departamento de Áreas Acadêmicas IV – IFG
Prof. Me. Ariel Cardoso Mendes

Departamento de Áreas Acadêmicas IV- IFG
Dedico este trabalho primeiramente a Deus, a minha mãe, família e amigos.
Agradecimentos
A Deus por me proporcionar todos estes momentos vividos e ser minha força
em todos as situações. Ao IFG, por fornecer toda a infraestrutura necessária para o
meu aprendizado, crescimento profissional e pessoal. Aos docentes da instituição, que
se esforçaram no processo de passar conhecimento, experiências e orientações para
crescimento da minha carreira profissional e vida pessoal. Ao professor Otávio Calaça
pela orientação e tempo investido no apoio a criação deste trabalho. Aos meus amigos de
curso, que estiveram durante todo este tempo ao meu lado, vencendo desafios, superando
as barreiras e os nosso próprio limites.
Agradecimento especial a minha mãe, Maria Duce por estar ao meu lado apoi-
ando minhas decisões, meus estudos e me incentivando a vencer os desafios. A minha
família, base dos meus valores e força para seguir em frente.
E a todos que de alguma forma contribuíram para a construção deste trabalho ou
em algum momento da minha caminhada.
Aqueles que semeiam com lágrimas, com cantos de alegria colherão.
Aquele que sai chorando enquanto lança a semente, voltará com cantos de
alegria, trazendo os seus feixes.
Salmos 126:5,6,
Bíblia Sagrada.
Resumo
de Moura, Cícero Joasyo Mateus. Protótipo de Monitoramento Remoto da

Saúde do Idoso. Goiânia, 2018. 88p. Relatório de Graduação. Departamento de
Áreas Acadêmicas IV, Intituto Federal de Goiás.
A população idosa no mundo vem crescendo consideravelmente, e a previsão para o
ano de 2050 é que sejam em torno de 22% da população mundial. Pessoas acima dos
65 anos de idade, tendem a enfrentar alguns problemas relacionados a saúde. Devido
a idade podem ficar mais frágeis e acontecer possíveis complicações repentinas. Uma
grande preocupação de problemas da saúde são as quedas, que afetam grande parte da
população idoso. Além disso doenças respiratórias, cardiovascular e outras. Em busca
de controle sobre a saúde do idoso, oferecendo maior independência e acompanhamento
pelos familiares, é relevante soluções que venham oferecer melhorias na qualidade de vida
dos envolvidos.
Este projeto traz o objetivo de construir um sistema de monitoramento a saúde do idoso,
de forma que seja economicamente viável, tecnologicamente possível, confortável para
uso e pratico para o idoso em monitoramento quanto para familiares e cuidadores que
acompanham sua saúde. O sistema deve contemplar o monitoramento sobre frequência
cardíaca, temperatura corporal e detectar quedas, possibilitando respostas rápidas e au-
tomáticas sobre alterações no quadro de sua saúde. Para os familiares e cuidadores é
oferecido um aplicativo móvel para acompanhamento dos dados e recebimento de alertas
sobre situações do monitoramento.
Este trabalho irá apresentar todas as etapas de desenvolvimento do sistema, como os
materiais, recursos tecnológicos, implementação, linguagens de programação, algoritmos
e todas as etapas seguidas para construção do sistema. Nos resultados é feito a análise de
dois estudos de casos, observando e comentando os resultados obtidos.
Como trabalho futuro, deseja-se agregar novos sensores e módulos ao sistema e realizar
análises preditivas sobre os dados para identificar de forma pró-ativa situações de risco a
saúde do idoso.
Palavras–chave
Saúde do Idoso, Internet das Coisas, Monitoramento Remoto, Computação
Vestível
Abstract
de Moura, Cícero Joasyo Mateus. Intelligent and Remote Health Monitoring

of the Elderly. Goiânia, 2018. 88p. Relatório de Graduação. Departamento de
Áreas Acadêmicas IV, Intituto Federal de Goiás.
The elderly population in the world has grown considerably, and the forecast for the year
2050 is around 22 some health-related problems. Due to age can become more fragile
and possible sudden complications happen. A major concern of health problems are falls,
which affect majority of the elderly population. In addition respiratory, cardiovascular
and other diseases. In search of control over the health of the elderly, offering greater
independence and accompaniment by the relatives, it is relevant solutions that will offer
improvements in the quality of life of those involved. This project aims to build a health
monitoring system for the elderly, in a way that is economically feasible, technologically
possible, comfortable for use and practical for the elderly in monitoring, as well as
for family members and caregivers who accompany their health. The system should
include monitoring of heart rate, body temperature and detection of falls, enabling rapid
and automatic responses to changes in the health situation. For family members and
caregivers, a mobile application is offered to monitor data and receive alerts on monitoring
situations. This work will present all the stages of system development, such as materials,
techno- logical resources, implementation, programming languages, algorithms and all
the steps followed to build the system. In the results, two case studies were analyzed,
observing and commenting on the results obtained. As future work, want to add new
sensors and modules to the system and perform predictive analyzes on the data to
proactively identify situations of risk to the health of elderly.
Keywords
Health of the Elderly, Internet of Things, Remote Monitoring, Wearables Com-
puting
Lista de Abreviações
API Application Programming Interface

APK Android Package
AP Access Point
APP Application
BPM Batimentos por Minuto
CLI Command Line Interface
CSS Cascading Style Sheets
CSV Comma-Separated Values
DNS Domain Name System
FCM Firebase Cloud Messaging
GPIO General Purpose Input/Output
GPS Global Positioning System
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hyper Text Transfer Protocol Secure
I 2C Inter-Integrated Circuit
IBGE Instituto Brasileiro de Geografia e Estatística
IDE Integrated Development Environment
IoT Internet of Things
IP Internet Protocol
JS JavaScript
JSON JavaScript Object Notation
LED Light Emitting Diode
MIT Massachusetts Institute of Technology
RAM 4Random Access Memory
ROM Read-Only Memory
SCL Serial Clock
SDA Serial Data
SGDB Sistema de Gerenciamento de Banco de Dados
SQL Structured Query Language
STA Station
TA Tecnologia Assistiva
TCP Transmission Control Protocol
TI Tecnologia da Informação
TS TypeScript
UML Unified Modeling Language
URL Uniform Resource Locator
USB Universal Serial Bus
Wi-Fi Wireless Fidelity
XML Extensible Markup Language
Sumário
Lista de Figuras 12
Lista de Tabelas 14
Lista de Códigos de Programas 15
1 Introdução 16
1.1 Motivação 16
1.2 Justificativa 17
1.3 Objetivos 18
1.3.1 Objetivo Geral 18
1.3.2 Objetivos Específicos 18
1.4 Estrutura do Trabalho 19
2 Referencial Teórico 20
2.1 Frequência Cardíaca 20
2.2 Temperatura Corporal 20
2.3 Tecnologia Assistiva 21
2.4 Computação Vestível 21
2.5 Internet das Coisas 22
2.5.1 Arquitetura básica da Internet das Coisas 22
2.6 Protocolos de Comunicação 23
2.6.1 Protocolo I2C 23
2.6.2 Protocolo Serial 24
2.6.3 Protocolo HTTP 24
2.7 Sistemas Embarcados 25
2.7.1 Microcontrolador 25
2.7.2 Microcontrolador ESP8266 25
2.8 Computação em Nuvem 26
2.9 Banco de Dados NoSQL 28
2.10 Banco de Dados SQLite 29
2.11 Linguagem Python 29
2.12 Linguagem TypeScript 30
2.13 Aplicativos Híbridos 30
2.14 Framework 31
3 Materiais e Recursos 32
3.1 Definição de Escopo do Trabalho 32
3.2 Materiais 33
3.2.1 Compra dos Materiais 33
3.2.2 Placa de Desenvolvimento NodeMCU 34
3.2.3 Sensor de Frequência Cardíaca 36
3.2.4 Acelerômetro, Giroscópio e Sensor de Temperatura 36
3.3 Recursos 37
3.3.1 O IDE Arduino 38
3.3.2 O IDE PyCharm 39
3.3.3 O IDE Visual Studio Code 39
3.3.4 Plataforma Heroku 40
3.3.5 Plataforma Firebase 40
3.3.6 Ionic Framework 41
3.3.7 Flask Microframework 42
4 Desenvolvimento 43
4.1 Estrutura Geral do Sistema 43
4.2 Etapas da Construção do Sistema 44
4.3 Montagem do Hardware 45
4.4 Algoritmo do Sistema Embarcado 48
4.5 Configuração do Firebase 54
4.6 Desenvolvimento da Web API 55
4.6.1 Adicionando a Web API na Plataforma Heroku 58
4.7 Desenvolvimento do Aplicativo Móvel 60
4.7.1 Estruturação do Projeto 60
4.7.2 Instalações e Implementação 63
5 Resultados 68
5.1 Aplicativo Móvel 68
5.2 Estudos de Casos 70
5.3 Análise dos Estudos de Casos 71
5.3.1 Análise do EC1 71
5.3.2 Análise do EC2 75
5.4 Notificações 76
6 Conclusão e Trabalhos Futuros 79
Referências Bibliográficas 81
Lista de Figuras
2.1 Figura ilustrativa mostrando o funcionamento do protocolo I 2C [28] 23

2.2 Alguns módulos que possuem o ESP8266 [77] 26
2.3 Figura ilustrativa do modelo de computação em nuvem [78] 27
3.1 Figura ilustrativa da arquitetura do sistema de monitoramento proposto 33

3.2 Figura ilustrativa do NodeMCU em sua versão 1.0 [70] 34
3.3 Destaque do pinos relacionados a energia do NodeMCU [11] 35
3.4 Figura ilustrativa do sensor de frequência cardíaca[5] 36
3.5 Figura ilustrativa do módulo MPU6050[8] 37
3.6 Tela inicial do IDE Arduino 38
3.7 Exemplo da estrutura do Firebase Real Time Database 41
4.1 Diagrama de Atividade do Sistema de Monitoramento 43

4.2 Fluxo de etapas a serem realizadas no projeto 44
4.3 Figura ilustrativa com o protótipo do sistema embarcado feito no Fritizing 46
4.4 Protótipo real com todos os componentes conectados ao NodeMCU 47
4.5 Primeiro protótipo do sistema costurado na parte interna de uma camiseta 47
4.6 Protótipo final do sistema costurado na parte interna de uma camiseta 48
4.7 Figura ilustrativa da posição do MPU6050 no corpo do paciente 52
4.8 Tela inicial de um projeto criado no Firebase 54
4.9 Estrutura de armazenamento dos dados no bando de dados em tempo
real do Firebase 55
4.10 Conteúdo do arquivo requirements da Web API 59
4.11 Mensagem emitida pela rota principal da Web API quando acessada 60
4.12 Diagrama de atividades com a etapas de desenvolvimento do aplicativo 60
4.13 Diagrama de Casos de Uso do aplicativo móvel 61
4.14 Estrutura padrão do tipo tabs no Ionic 62
4.15 Estrutura do projeto visualizada pelo Visual Studio Code 63
4.16 Laboratório do Ionic com iOS e Android 65
5.1 Página com formulário para preenchimento das informações do paciente 69

5.2 Página inicial do aplicativo mostrando os dados do monitoramento 69
5.3 Página de histórico mostrando as três opções de visualização dos dados 70
5.4 Página de perfil do usuário com a visualização dos dados salvos 70
5.5 Pessoa Utilizando o protótipo em ambiente real para estudo de caso 71
5.6 Gráfico do BPM no dia 1 do estudo de caso 1 72
5.7 Gráfico da temperatura corporal no dia 1 do estudo de caso 1 72
5.8 Gráfico do BPM no dia 2 do estudo de caso 1 73
5.9 Gráfico do acelerômetro com os dados do dia 2 no estudo de caso 1 73
5.10 Gráfico do acelerômetro com os dados do dia 1 e 2 no estudo de caso 1 74
5.11 Gráfico do BPM com temperatura corporal do estudo caso 1 74
5.12 Gráfico do BPM do estudo de caso 2 75
5.13 Gráfico da temperatura corporal do estudo de caso 2 76
5.14 Página de histórico mostrando as situações do estudo de caso 2 76
5.15 Notificações relacionadas ao batimento por minuto 77
5.16 Notificações relacionadas a temperatura corporal 77
5.17 Notificação relacionada a detecção de queda 78
5.18 Notificações relacionadas a média do batimento por minuto 78
Lista de Tabelas
3.1 Lista de materiais utilizados para a construção do sistema de monitoramento 34

3.2 Pinos conectores do MPU6050 37
3.3 Alguns comandos reservados da IDE Arduino 39
3.4 Alguns comandos do Toolbet CLI do Heroku 40
4.1 Tabela com a descrição das atividades 44

4.2 Detalhe da conexão entre os componentes 46
4.3 Comandos para instalar pacotes no Python utilizando o pip 56
4.4 Declaração das rotas utilizando o Python e Flask 56
4.5 Descrição do JSON com os dados de monitoramento da Web API 57
4.6 intervalos de comparação para definir situações da saúde 58
4.7 Comandos executados para adicionar projeto ao Heroku 59
4.8 Descrição das páginas que compõem o aplicativo 62
4.9 Resumo das bibliotecas utilizadas no projeto 64
4.10 Todos os plugins nativos utilizados na aplicação 64
Lista de Códigos de Programas
4.1 Inclusão das bibliotecas utilizadas no algoritmo do sistema embarcado 49

4.2 Função para inicializar as configurações do sistema 50
4.3 Função para estabelecer a conexão com uma rede Wi-Fi 50
4.4 Função para realizar a leitura dos batimentos cardíacos 51
4.5 Função para realizar a leitura do acelerômetro, giroscópio e temperatura 51
4.6 Função para enviar os dados para o servidor Web API 52
4.7 Função para realizar a montagem da URL com os dados 53
4.8 Função para chamar a execução das outras funcionalidades do sistema 54
4.9 Função para estruturação dos dados na Web API em JSON 57
4.10 Código em HTML para mostrar gráfico na página 65
4.11 Código em TS para criar gráfico de linha na página 66
4.12 Código em TS para criar um banco de dados no dispositivo móveç 67
4.13 Código em TS para salvar dados do usuário no banco de dados 67
CAPÍTULO 1
Introdução
1.1 Motivação
A população idosa do Brasil tem aumentado a cada ano consideravelmente e
com isso o aumento da qualidade de vida para esse grupo da sociedade é alvo de diversos
esforços. O objetivo é buscar soluções que possam trazer praticidade, independência,
prevenção, auxílio e conforto a vida das pessoas acima dos 65 anos de idade. No ano de
2010, foi constado que são cerca de 20 milhões de pessoas que estão dentro da população
idosa no Brasil, o que corresponde a 7,4% da população total [16]. E segundo dados do
IBGE, a expectativa média de vida do brasileiro subiu em 2012, chegando a 74,5 anos,
[48].
A atenção aos idosos é tratada de diversas maneiras e os maiores esforços estão
voltados a soluções que propõe melhorias no acompanhamento a saúde. Essa preocupação
quanto à saúde do idoso não acontece somente no Brasil, mas em muitos outros países [9].
Estudos apontam quais são as principais causas de atendimento e internações realizados
pelos pontos de saúde, e entre essas ocorrência pode se destacar: problemas respiratórios,
cardiovasculares, ingerir remédios errados e quedas sofridas [58]. Ainda é importante
destacar que no Brasil cerca de 70% dos idosos possuem pelo menos uma patologia
crônica, ou seja, um problema de saúde que necessita de constante acompanhamento e
monitoramento [12].
Segundo estudo realizado no ano de 2010, as três maiores frequências de atendi-
mentos hospitalar entre os idosos são: problemas no aparelho circulatório, que afeta 28%
dos idosos brasileiros, quedas sofridas que somam 24% ao ano e doenças no aparelho res-
piratório que afeta cerca de 17% da população idosa [10]. Normalmente os idosos querem
ser independentes e por muitas das vezes moram sozinhos. Porém com o risco eminente
de sofrer algum tipo de trauma como a queda ou complicações repentinas em sua saúde
como ataque cardíaco ou parada respiratória, prejudicam a independência do idoso.
1.2 Justificativa 17
1.2 Justificativa
Por se tratar de uma parte da população que tende a ter saúde frágil, é registrado
um grande número de ocorrências que levam a ter diversos atendimentos em hospitais.
Muitas vezes são de emergência e até internações por longos períodos, se tornando
assunto de preocupação da saúde pública. Levando em consideração essa situação,
diversos esforços em estudos têm sido realizados para se criar soluções tecnológicas
que possam oferecer um suporte aos idosos. Ao ser realizado o monitoramento de sua
saúde, o idoso pode ter maior independência e conforto. além de possibilitar o controle e
administração das situações por parte dos familiares e cuidadores.
Em relação ao monitoramento de possíveis quedas que o idoso possa sofrer, o
artigo Fall detection algorithms for real-world falls harvested from lumbar sensors in the
elderly population: a machine learning approach [15] aborda o conceito de tecnologia
assistiva, onde sensores identificam a queda do idoso e o sistema envia mensagens para
parentes ou médicos, para que o auxílio seja feito rapidamente. A identificação da queda
é feita através de sensores e abordagem com algoritmos computacionais de Inteligencia
Artificial.
Outra solução é descrita no artigo IoT system for monitoring vital signs of elderly
population, que faz a utilização de sistema embarcado capaz de monitorar os batimentos
cardíacos para a prevenção de arritmia cardíaca e também módulos de monitoramento
da respiração e da temperatura do corpo, utilizando algoritmos computacionais para
identificar padrões e possíveis alterações na saúde da pessoa em monitoramento [9].
Outra abordagem é proposta no trabalho We-care: An IoT-based health care
system for elderly people é o desenvolvimento de uma pulseira baseada no conceito de
Internet das Coisas, que realiza o monitoramento da frequência cardíaca, temperatura,
saturação de oxigênio e sinais eletrocardiográficos, usando informações em tempo real
através de sensores internos e ainda notificar os membros da família ou cuidadores
designado sobre mudanças inesperadas [73].
Malheiros, Larinni em seu trabalho de conclusão da graduação [60], propõe uma
solução para acompanhamento à distância de pessoas com diagnóstico de Alzheimer, com
quadros de desmaios frequentes, idoso e qualquer um que precise de monitoramento 24
horas. Para isto é utilizado a Internet das Coisas e um aplicativo móvel para acompanhar
posição corporal, frequência cardíaca e possíveis quedas.
Uma outra abordagem é feita no artigo Human fall detection with smartphones
[19], utilizando os sensores do smartphone para detectar quedas, contudo o idoso deve
constantemente carregar em seu bolso o aparelho, o que na maioria das vezes, pode ser
inviável.
Levando em consideração os estudos e soluções apresentados podemos perceber
1.3 Objetivos 18
que se trata de um assunto com importância que relaciona os idosos, familiares, médicos
e o sistema de saúde.
Nesse aspecto este trabalho apresentada uma proposta que possa reunir as
principais necessidades e prover um sistema de monitoramento remoto a saúde de pessoas
acima dos 65 anos. Utilizando técnicas relacionadas a Internet das Coisas para monitorar
batimentos cardíacos, temperatura do corpo e detectar quedas, juntamente com algoritmos
para analisar os dados e oferecer uma resposta rápida e de forma automática a possíveis
alterações na saúde do idoso, e assim emitir alertas para a família ou cuidadores que
estejam acompanhando o monitoramento.
Ainda é necessário que a solução apresentada seja viável economicamente, que
não venha prejudicar o idoso ou lhe fazer sentir desconfortável, eficiente na detecção de
alterações, rápida resposta às situações, com o uso de tecnologias livres e gratuitas, de
forma que possibilite facilmente a sua expansão agregando novas funcionalidades.
1.3 Objetivos
1.3.1 Objetivo Geral

O objetivo geral deste trabalho é criar uma solução baseada em Internet das
Coisas, que seja acessível a população, possibilitando o monitoramento a saúde de pessoas
idosas, que emita alertas automaticamente em caso de alterações imprevistas, para que
o auxílio seja realizado o mais rápido possível por parte de familiares, cuidadores ou
médico, diminuindo assim possíveis consequências a saúde do idoso.
1.3.2 Objetivos Específicos

Os seguinte objetivos específicos foram definidos a fim de alcançar o objetivo
principal:
• Desenvolver uma solução em dispositivo embarcado para monitoramento da saúde

do idoso.
• Desenvolver um sistema viável economicamente para acesso do maior número e
usuários.
• Utilizar tecnologias atuais que sejam livres e gratuitas, simplificando a arquitetura
do sistema.
• Integrar microcontrolador e sensores que sejam viáveis para a construção do protó-
tipo.
• Propor uma solução que seja modular e fácil agregação de novas funcionalidades.
1.4 Estrutura do Trabalho 19
• Realizar a análise dos dados coletados pelos sensores, em busca de respostas a

supostas situações de risco a saúde.
• Implementar sistema de alerta e avisos relacionado a situações de riscos.
• Realizar testes reais para verificar a viabilidade e eficiência dos objetivos propostos.
1.4 Estrutura do Trabalho

No Capitulo 2 é apresentado uma introdução aos conceitos que serão utilizados
para o desenvolvimento do projeto. O Capitulo 3 descreve os materiais físicos e recursos
tecnológicos utilizados na construção do protótipo. No Capitulo 4 é apresentado todas
as etapas seguidas no desenvolvimento do sistema. Os resultados experimentais são
discutidos no Capitulo 5, seguido das conclusões e trabalhos futuros no Capitulo 6.
CAPÍTULO 2
Referencial Teórico
2.1 Frequência Cardíaca

A frequência cardíaca é medida com batimentos por minutos (BPM) e define
a quantidade de vezes que o coração pulsa durante um período de tempo. Existem
valores definidos em média para a frequência cardíaca, que variam por idade, situações
temporárias e condições de saúde. A frequência cardíaca quando baixa, pode indicar
problemas metabólicos, doenças cardíaca-vascular, exaustão e outras situações. Já a
frequência cardíaca alta pode diagnosticar pressão alta, insuficiência cardíaca, infarto e
outras situações de risco [84].
Normalmente um adulto saudável tem a medida entre 72 a 78 BPM como normal
e pode variar entre o sexo, sendo que mulheres tendem a ter frequência cardíaca maior.
Através de estudo é indicado que idosos apresentam de 6 a 10 BPM menores que um
adulto abaixo dos 65 anos [31]. Outro estudo realizado com 93 mulheres indica que a
frequência cardíaca pode chegar até o valor máximo de 169, porém em um caso muito
extremo para a saúde [79].
Com base nos estudos pode-se definir que a frequência cardíaca entre idosos
pode variar em média de 40 e 160 BPM, sendo o primeiro limite baixo e o segundo
muito alto. Neste trabalho será avaliado os dados dentro deste intervalo, para a possível
identificação de problemas cardiovasculares do idoso.
2.2 Temperatura Corporal

A temperatura corporal é uma combinação de calor gerado e perdido pelo corpo
humano. O órgão responsável pela manutenção da temperatura corporal é o Hipotálamo
e tem o papel de manter-la mais ou menos com valor constante [87].
Em geral, a temperatura normal média de uma pessoa adulta situa-se entre 36,7
e 37 graus célsius (o C), podendo variar cerca de 0,6 o C a mais, dependo do lugar no corpo
2.3 Tecnologia Assistiva 21
em que é medida, sendo que abaixo de 34 o C e muito baixa e acima de 37 muito alta.
Ainda podendo ter influência do meio ambiente na camada externa da pele [23].
Pelo valor da temperatura corporal é possível identificar algumas situações de
riscos como a hipotermia, que se refere a perda de temperatura corporal, chegando a
valores muito baixos. A hipertermia, que é elevação da temperatura corporal que pode
caracterizar febre e situações de riscos a saúde [87].
Um dos objetivos deste trabalho é realizar a análise dos dados da temperatura
corporal, buscando oferece alertas sobre possível situações de riscos para temperatura
corporal acima ou abaixo do normal.
2.3 Tecnologia Assistiva

O termo Assistive Technology, traduzido para o Português como Tecnologia
Assistiva (TA), foi criado oficialmente em 1988, fazendo parte da legislação dos Estados
Unidos, garantindo os direitos das pessoas com limitações físicas, especificando que
devem ter acessos aos mesmos serviços e recursos como toda a polução [13].
Com o passar dos anos, a TA ganhou maior destaque e um amplo arsenal de
aplicações, expandindo as fronteiras e assim podendo ser utilizada para descrever o
uso da tecnologia como ferramenta de auxilio para pessoas com deficiências, idosos,
crianças e qualquer um que tenha alguma limitação física. Soluções relacionadas ao uso
da tecnologia que venha ajudar a melhorar a vida das pessoas e auxiliar a execução de
alguma atividade do dia-a-dia, podem ser classificadas como TA.
A proposta deste trabalho se encaixa como TA pois busca ajudar a vida diária
das pessoas idosas, trazendo maior independência e controle sobre sua saúde.
2.4 Computação Vestível

Computação vestível, ou no inglês wearables, são sistemas inteligentes que
podem ser vestidos por uma pessoa. Estes dispositivos podem estar conectados a Internet
ou há outros dispositivos em rede [82].
O termo surgiu em 1998, no artigo escrito por Sterve Mann [61], que define
como: "Um computador vestível é um computador que está alocado no espaço pessoal
do usuário, controlado pelo usuário, e possui constância de operação e interação, ou seja,
está sempre ligado e sempre acessível. Mais notavelmente, ele é um dispositivo que está
sempre com o usuário, e permite que o usuário digite comandos ou os execute, enquanto
anda ou faz outras atividades".
Dispositivos vestíveis estão cada vez mais presentes no cotidiano das pessoas,
e podem ser encontrados através de relógios, roupas, pulseiras, óculos e acessórios em
2.5 Internet das Coisas 22
geral, como o dispositivo proposto neste trabalho, que é vestível e possui um sistema de
computação executando tarefas que interagem com o usuário.
2.5 Internet das Coisas

A Internet das Coisas, ou em inglês, Internet of Things (IoT), é um termo que
foi criado em 1999 por Kevin Ashton, co-fundador do Auto-ID Center do Massachusetts
Institute of Technology (MIT). Esse termo foi criado pois o seu autor previa que todos os
objetos físicos estariam conectados a Internet, com a capacidade de capturar informações
por meio de sensores que detectam o ambiente em que está inserido, podendo assim
identificar e compreender o mundo independentemente das pessoas [46].
Em uma abordagem de Davis [22], o autor define quatro estágios de evolução
da Web. A primeira sendo a Web 1.0, voltada para a conexão e obtenção de informação
através da rede computadores, essa é a internet clássica. A Web 2.0, ou Web Social, uma
internet democrática, voltada para a interação com os usuários, tendo caráter colaborativo
e marcado pelo surgimento das redes sociais. A Web 3.0, ou Web Semântica, marcada
pela experiência dos usuários, buscando esforços para dar significado e contexto as
informações dos usuários da rede. E por fim, a Web Ubíqua, marcada pela Internet das
Coisas, com o objetivo de possibilitar a interação e conectividade entre as pessoas através
da tecnologia, por qualquer dispositivo e independente do lugar, baseada em sensores
inteligentes e computação portátil.
Este trabalho tem como um dos objetivos a criação de um dispositivo para a
Internet das Coisas, onde se possa realizar o monitoramento remoto da saúde de pacientes
idosos utilizando sensores e conexão com a Internet.
2.5.1 Arquitetura básica da Internet das Coisas

Para se entender melhor como a Internet das Coisas funciona e como ela
interage no meio em que está inserida, nesta seção será descrito conceitos básicos da
sua arquitetura e dispositivos envolvidos.
A arquitetura é formada basicamente por quatro unidades: energia, senso-
res/atuadores, processamento/memória e comunicação [88]. Uma descrição geral sobre
esses itens está logo abaixo:
1. Fonte de energia: é a fonte que alimenta o dispositivo eletricamente, pode ser gerada
de uma bateria, rede elétrica e entre outras.
2. Sensores e Atuadores: os sensores realizam a interação com o meio externo,
provendo um monitoramento através de grandezas físicas: temperatura, pressão,
umidade e entre outras. Os atuadores são responsáveis pela resposta, atendendo
a comando e produzindo alguma ação, como envio de mensagens, movimento e

outros.
3. Processamento e memória: o processamento é responsável por prover a capacidade
de interação com o meio, responsável por processar os dados dos sensores. A me-
mória armazena os dados e comandos a serem executados. Os dispositivos embar-
cados, não apresentam uma grande memória e nem alto poder de processamento.
4. Comunicação: é o meio de comunicação utilizado, como a rede de computadores,
podendo ser com fio ou sem fio.
2.6 Protocolos de Comunicação
2.6.1 Protocolo I2C

O I 2C é a sigla para Inter-Integrated Circuit que permite a comunicação entre
dispositivos que utilizam o mesmo protocolo e trabalha de forma mestre/escravo. O
mestre é quem coordena a comunicação, apenas ele envia dados e o escravo recebe e
lê as informações, em nenhum momento o dispositivo escravo inicia a comunicação [28].
O protocolo suporta mais de um mestre ao mesmo tempo, obrigatoriamente tendo pelo
menos um e podendo se comunicar com até 112 dispositivos como escravos.
O protocolo é do tipo barramento, ou seja, necessita apenas de uma ligação
para comunicação, com um fio é possível trocar informações de um mestre com vários
escravos. Dispositivos que utilizam o I 2C possuem dois pinos, o SDA e SCL. O primeiro
é a sigla para Serial Data é o pino responsável por transferir os dados, e o segundo é
a sigla para Serial Clock, responsável pela temporização entre os dispositivos, de modo
que a comunicação pela SDA possa ter confiabilidade. O envio e recebimento dos dados
ocorrem pelo SDA, sendo uma linha bi-direcional, podendo enviar e receber dados.
Figura 2.1: Figura ilustrativa mostrando o funcionamento do pro-

tocolo I 2C [28]
A distância normal de trabalho no barramento com a comunicação utilizando o

protocolo, é de aproximadamente 1 metro, onde passando desta distância a comunicação
já pode passar a conter interferências. O protocolo ainda trabalha com endereçamento,
para identificar os dispositivos no momento da comunicação. O endereço e composto por
8 bits, sendo 7 bits para a identificação do dispositivo e 1 bit para indicar o estado no
momento da comunicação, se é leitura ou escrita. O endereçamento é expresso em forma
de numeração hexadecimal.
O protocolo I 2C é utilizado neste trabalho para a comunicação entre microcon-
trolador e módulos adicionais.
2.6.2 Protocolo Serial

O protocolo Serial possibilita a comunicação do microcontrolador com um
computador ou entre outros módulos, como sensores e atuadores. Faz a interface e
conversão dos dados para o microcontrolador. A comunicação é realizada por dois pinos,
o RX e TX, onde o primeiro é o termo usado para representar o pino receptor de uma
comunicação serial e o segundo representa o transmissor [81].
Para a comunicação utilizando o protocolo, o TX do dispositivo receptor deve
ser ligado ao RX do transmissor, e vice-versa. Com as ligações realizadas é estabelecido
um canal de comunicação utilizando serial. É através desse protocolo que é realizado o
carregamento do código para a placa microcontroladora através de um computador.
2.6.3 Protocolo HTTP

HTTP é a sigla para Hypertext Transfer Protocol (Protocolo de Transferência
de Hipertexto), é um protocolo utilizado para transferência de dados pela Web. A sua
comunicação é baseada em requisições e respostas no modelo de cliente-servidor [86].
O cliente que pode ser qualquer dispositivo com acesso a Internet, que faz uma
requisição, ou seja, solicita um determinado recurso, enviando um pacote de informações
contendo alguns cabeçalhos que caracterizam a solicitação direcionado a uma URL
(Uniform Resource Locator), que é o endereço do local onde está localizado o recurso
desejado. Por outro lado, o servidor recebe estas informações e envia uma resposta, que
pode ser o recurso solicitado ou simplesmente um outro cabeçalho, informando sucesso,
erros ou falhas.
Quando é gerado uma requisição, é preciso especificar qual o método do HTTP
será utilizado. Os métodos também conhecidos como verbos, identificam qual a ação que
deve ser executada em um determinado recurso. Os dois principais são o GET e POST.
O primeiro normalmente é utilizado para solicitar um recurso, porém também pode ser
para criar. O segundo é exclusivo para criar um novo recurso ou processamentos que não
envolvem recursos diretamente.
O HTTP ainda possui sua variação, como o nome de HTTPS (Hyper Text Trans-
fer Protocol Secure), que é uma implementação adicional, fornecendo mais segurança
através do uso de certificados para as requisições.
2.7 Sistemas Embarcados 25
2.7 Sistemas Embarcados

Relacionado a Internet das Coisas, outro conceito importante é o de sistemas em-
barcados, que consistem na combinação de hardware, software e possíveis componentes
adicionais, que são mecânicos, como os sensores. Esses sistemas são desenvolvidos para
a execução de uma função dedicada [57].
O adjetivo embarcado, está relacionado ao fato que esses sistemas, normalmente
são integrantes de um sistema maior, porém nada impede de termos um sistema completo,
apenas com dispositivos embarcados.
Sistemas embarcados estão cada dia mais presentes no nosso cotidiano, influen-
ciando a forma de como as pessoas trabalham, estudam e se divertem. Atualmente é difícil
encontrar na vida diária, segmentos que não envolvem sistemas embarcados em alguma
atividade[14]. Eles estão presentes na indústria, instrumentos médicos e em equipamentos
da rede de computadores.
Uma das partes que compõem o protótipo proposto neste trabalho, se trata de um
sistema embarcado, que realiza a tarefa dedicada de monitoramento a saúde.
2.7.1 Microcontrolador
Microcontroladores são sistemas computacionais inteiros contidos em apenas
um único chip de circuito integrado [2]. Se trata de um hardware específico para executar
funções dedicadas através de uma programação feita em uma linguagem suportada pelo
circuito.
Um microprocessador, utilizado em computadores pessoais, são chamados mi-
croprocessadores de uso geral, pois possuem poder para realizar cálculos de forma rápida
e podem executar praticamente qualquer tarefa, conforme são programados. Por outro
lado os microcontroladores são circuitos mais simples, com interfaces de entrada e saída
(E/S), memória RAM e ROM, interfaces de comunicação serial e USB, podendo possuir
conexão de rede, como Ethernet, Wi-FI e Bluetooth [70].
As grandes vantagens dos microcontroladores são o seu preço acessível e seu
pouco consumo de energia. Juntando essas características e seus componentes agregados
é possível o desenvolvimento de diversas aplicações, em várias áreas diferentes e com
muitas funcionalidades.
2.7.2 Microcontrolador ESP8266

O ESP8266 é um microcontrolador desenvolvido pela empresa chinesa Espressif
Systems, que oferece uma solução que já integra um chip de conexão Wi-Fi ao micro-
controlador. Pode ser utilizado como um dispositivo conectado a rede sem fio (Station),
um ponto de acesso (Access Point) que oferece uma rede para conexões ou então as duas
soluções em conjunto. A rede Wi-Fi suporta os protocolos de conexão 802.11 b/g/n e de
comunicação TCP/IP [83].
O microcontrolador possui arquitetura de 32 bits, e um núcleo de processamento
com 80 MHz que pode chegar até 160 MHz e a memória disponível para os dados do
programa de usuário tem cerca de 50 kB [70]. Possui 17 interfaces de entrada e saída
(GPIO) digitais, suporta os protocolos de comunicação serial e I 2C. A tensão energética
de operação do microcontrolador é de 3,3 volts.
Existem diversos módulos disponíveis no mercado que utilizam o ESP8266
como base, oferecendo interfaces de conexões E/S facilitadas, conexão USB, suporte a
linguagem de programação e ambiente de desenvolvimento integrado (IDE). Conforme
a Figura 2.2, são destacados algumas dessas plataformas que contém o ESP8266 como
microcontrolador.
Figura 2.2: Alguns módulos que possuem o ESP8266 [77]
O ESP8266 foi projetado pensando em aplicações para a Internet das Coisas, dis-
positivos móveis e vestíveis a um baixo custo. Possui diversas tecnologias desenvolvidas
pela empresa proprietária que garantem a utilização desse microcontrolador em diversas
aplicações com a conexão de uma rede sem fio.
2.8 Computação em Nuvem

Cloud Computing ou Computação em Nuvem, proporciona serviços de Tecnolo-
gia da Informação (TI) sob demanda, com acesso pela rede de computadores, possuindo
recursos computacionais compartilhados e configuráveis [62]. Os serviços normalmente
oferecidos em nuvem são: servidores, banco de dados, armazenamento de arquivos e apli-
cativos em geral. O pagamento por serviço em nuvem é feito por demanda e muitas das
vezes é oferecido um plano limitado de forma gratuita.
Algumas características essenciais para um serviço em nuvem são descritas logo
abaixo [80]:
• Serviços sob demanda: o usuário pode adquirir recursos computacionais conforme

a sua necessidade, sem ter contato direto com o provedor, apenas alterando as
configurações conforme o plano contratado.
• Amplo acesso: os recursos são disponibilizados através da rede, e podem ser
acessados por uma plataforma única e por qualquer dispositivo.
• Pooling de recursos: o usuário não precisa ter conhecimento da localização física
dos recursos computacionais e um servidor físico pode oferecer serviços de forma
separada para diversos usuários ao mesmo tempo.
• Elasticidade rápida: serviços em nuvem, são oferecidos por servidores virtuais
que estão armazenado em um servidor físico que contém uma grande capacidade
computacional, e assim podem suportar demandas de aumento nos recursos pelos
usuários.
• Serviço medido: os recursos computacionais são medidos e mostrados de forma
transparente para os usuários, buscando oferecer transparência e aumentar a quali-
dade do serviço oferecido.
Figura 2.3: Figura ilustrativa do modelo de computação em nuvem

[78]
A computação em nuvem ainda é composta por três modelos de arquitetura, que

definem um padrão para as soluções deste tipo [62].
1. Software como um Serviço (SaaS): este modelo proporciona sistemas de software

que estão disponíveis através da Internet. Neste caso os usuários não tem controle
sobre a infraestrutura (rede, servidores e sistema operacional) ou armazenamento
do serviço, apenas algumas configurações do sistema. Normalmente são softwares
acessados por um navegador Web, em qualquer dispositivo e os usuários são apenas
clientes do serviço.
2.9 Banco de Dados NoSQL 28
2. Plataforma como um Serviço (PaaS): neste caso é oferecido uma infraestrutura de

alto nível, onde o usuário passa a ter um controle intermediário, podendo configu-
rar as aplicações disponíveis no servidor. Porém não possui acesso a infraestrutura.
como servidor, rede e sistema operacional. Neste modelo são oferecidas ferramen-
tas que facilitam o desenvolvimento e integração dos softwares do usuário com os
serviços em nuvem.
3. Infraestrutura como um Serviço (IaaS): é o modelo que oferece uma infraestrutura
completa para o usuário, onde os recursos computacionais são facilmente acessíveis
e escaláveis. Neste tipo de serviço o usuário tem controle sobre o sistema operaci-
onal, rede, armazenamento e todo o ambiente de configuração do serviço.
Pela praticidade que a arquitetura em nuvem oferece, neste trabalho serão

utilizadas plataformas que oferecem serviços executados em nuvem de forma gratuita.
2.9 Banco de Dados NoSQL

Banco de dados NoSQL, ou não-relacional, surgiu como uma solução para o
armazenamento de dados em grande escala, podendo processar e armazenar grandes
volumes de dados com maior performance do que os bancos de dados tradicionais,
chamados de relacionais. O termo NoSQL não é preciso para definir esse tipo de banco,
pois a linguagem SQL (Structured Query Language) não é sinônimo de banco de dados,
nem representa as limitações do modelo de armazenamento relacional [24]. O termo
NoSQL tem sido utilizado com o significado de "Não apenas SQL", pois não utiliza a
linguagem SQL para manipular os dados.
O nome NoSQL surgiu no ano de 2009, quando comunidades de softwares
livres, começaram a desenvolver novas opções de banco de dados, tentando solucionar o
problema do armazenamento de grande volume dos dados nos banco de dados relacionais
[24].
O modelo NoSQL possui uma estrutura de armazenamento para dados comple-
xos, semiestruturados ou não estruturados. Podendo armazenar dados do tipo texto, nos
formatos XML (Extensible Markup Language) e JSON (JavaScript Object Notation), ob-
jetos, imagens, documentos de diversos formatos e entre outros [85].
O JSON é uma formatação que define estrutura para transmissão de dados. É uma
formato leve, simples, com fácil leitura e independente de linguagem de programação,
muito utilizado em desenvolvimento Web e bancos de dados NoSQL [55].
Banco de Dados NoSQL ainda possui característica de ser não-relacional, dis-
tribuído, de código aberto e escalável horizontalmente (pode-se criar colunas de dados
2.10 Banco de Dados SQLite 29
sem impactar os demais dados), ausência de esquema e acesso via API1 (Application
Programming Interface) simples [69].
O armazenamento dos dados coletados neste trabalho são armazenados em um
banco de dados NoSQL, por todos os benefícios que foram apresentados anteriormente.
2.10 Banco de Dados SQLite

O SQLite é um pequeno banco dados relacional, com código aberto e disponi-
bilizado por uma biblioteca escrita na linguagem C [71]. O SQLite pode ser acessado
diretamente pela aplicação, sem a necessidade de um SGDB (Sistema de Gerenciamento
de Banco de Dados), o que não ocorre na maioria dos banco de dados relacionais.
É um banco de dados indicado para pequenas aplicações, pois possui o conceito
de "banco de dados embutido", não consumindo muito processamento e necessita de
pouco espaço para armazenamento dos dados [45]. A sua estrutura é simples de ser
implementado, utilizando-se da linguagem SQL para a administração da base de dados
e o modelo relacional para a estrutura dos dados. É indicado para pequenas aplicações
Web ou aplicativos móveis, e não indicado para grandes aplicações, pois sua performance
e limitação de recursos são desvantagem do SQLite.
2.11 Linguagem Python

Python é uma linguagem de programação criada em 1991 por Guido Van Ros-
sum, um programador neerlandês, com objetivos de possuir uma linguagem que fornece
produtividade e legibilidade. O Python foi criado com foco para o desenvolvimento de
código fácil para manutenção, escrita de forma rápida e uma leitura simplificada [63].
É uma linguagem que suporta múltiplos paradigmas de programação. Pode-
se programar de forma estruturada, quando requer um programa simples e rápido. De
forma orientada a objetos, para projetos maiores e com uma estrutura organizada. E até
programação funcional, onde é possível dividir o projeto em módulos separados [32].
A linguagem Python é multiplataforma e livre. Isso quer dizer que programas
escritos em Python podem ser executados sem alterações em código fonte na maioria
dos sistemas operacionais existentes. E por ser livre, os programadores podem utilizar e
modificar a linguagem sem obter custo algum.
A linguagem Python será utilizada para a construção da parte Web deste trabalho,
escolhida por causa de todos os benefícios que foram apresentados.
1 Traduzido como Interface de Programação de Aplicativos, representa um conjunto de rotinas, funções

e padrões de programação que podem ser acessados por outro software ou plataforma Web.
2.12 Linguagem TypeScript 30
2.12 Linguagem TypeScript

TypeScript (TS) é uma linguagem de programação com código aberto, que possi-
bilita o desenvolvimento de aplicações utilizando JavaScript (JS). O JS uma linguagem de
programação na forma de script amplamente utilizada para desenvolvimento Web, possui
a limitação de não se poder programar utilizando o paradigma de orientação a objetos e
nem definir tipos de dados para as variáveis, o que vem ser proposto pelo TS [49].
O TS foi criado em 2012 pelo engenheiro de software Anders Hejlsberg e sua
equipe da Microsoft. Anders também criador da linguagem Delphi, propõe no TS, uma
forma de programar JS em larga escala, que possa ser executado no lado do cliente ou
servidor, suportando projetos maiores, bem estruturados e com uma maior produtividade.
Tudo que é escrito em TS no final vai se transformar em código JS. Porém a
possibilidade de realizar um projeto orientado a objeto tem chamado a atenção para a
linguagem. A sintaxe das duas linguagem são bem parecidas, porém com estrutura de
programação diferentes.
Assim o TS vem ganhando espaço, e pode ser utilizado para a criação de
aplicativos móveis, aplicações Web e sites para a internet.
2.13 Aplicativos Híbridos

Aplicativos híbridos é um conceito de desenvolvimento para dispositivos móveis,
onde um único aplicativo (app) desenvolvido, pode ser utilizado em diversas plataformas,
com sistemas operacionais diferentes. Para melhor entender o que são aplicativos híbri-
dos, é necessário conhecer outros dois conceitos de aplicações móveis [3].
1. Aplicativo nativo: são desenvolvidos especificamente para uma única plataforma

e que podem utilizar todos os recursos oferecidos pelo sistema operacional. De-
senvolvidos em linguagens de programação nativa da plataforma e são instalados
diretamente no dispositivo. Por esse fato, apresentam maior desempenho e melhor
performance em sua utilização.
2. Aplicativo Web: não são nativos, na realidade são sites que se parecem com um
aplicativo. São desenvolvidos pensando em dispositivos móveis, que possuem sua
execução por um navegador Web, podendo ser acessados em qualquer plataforma
por uma URL.
O aplicativo híbrido é uma mistura de aplicação nativa e Web. Podem ser

instalados em mais de uma plataforma e executados em um navegador Web embutido
na aplicação, conhecido como Web Container [59].
2.14 Framework 31
Aplicativos nativos para Android, sistema operacional móvel da Google são

desenvolvidos na linguagem Java ou Kotlin [26]. Para iOS, sistema operacional da Apple
utiliza-se a linguagem Swift [27]. Aplicativos híbridos são desenvolvidos em JS, HTML
(HyperText Markup Language) e CSS (Cascading Style Sheets), e podem ser instalados e
utilizados nas duas plataformas.
Por possibilitar a criação de apenas um aplicativo que pode ser executado em
diversos sistemas operacionais, este trabalho possui um aplicativo híbrido, com o objetivo
de encurtar o tempo de desenvolvimento e alcançar o maior número de usuários possíveis..
2.14 Framework
Um framework ou estrutura em português, em desenvolvimento de software de-
fine uma estrutura a ser seguida na criação do software e ainda disponibiliza bibliotecas
com códigos prontos que é comum em diversos projetos, buscando agilizar o desenvolvi-
mento e fornecer reaproveitamento de código na escrita do programa [39].
O uso de framework no desenvolvimento de um software, ajuda a definir uma
estrutura de organização do projeto e agiliza a sua escrita, por conter diversas funções
comuns em diversos softwares prontas para serem utilizadas.
CAPÍTULO 3
Materiais e Recursos
Nesse capitulo será descrito o escopo do trabalho, destacado os materiais utili-

zados para prototipação do sistema embarcado proposto nos objetivos e os recursos tec-
nológicos que auxiliaram o desenvolvimento.
3.1 Definição de Escopo do Trabalho

O presente trabalho tem como proposta desenvolver um sistema de monitora-
mento remoto a saúde de pessoas idosas. Como escopo o objetivo é realizar monitora-
mento por um dispositivo embarcado, com acompanhamento a distancia, de forma remota
através de um aplicativo móvel, com custo reduzido e não invasivo. O monitoramento
deve abranger a frequência cardíaca, temperatura corporal e detectar quedas. Este dispo-
sitivo deve permitir ao usuário acompanhar o estado do idoso em tempo real através de
um aplicativo para smartphones, poder consultar o histórico e receber notificações sobre
o estado de saúde do idoso.
O dispositivo de monitoramento é conectado a rede Wi-Fi local e para isso é
utilizado o padrão 802.11 b/g/n. Os dados são salvos em plataforma de armazenamento
em nuvem, e para serem consultados, o smartphone deve estar conectado a Internet. O
acompanhamento do paciente pode ocorrer de forma remota e em qualquer lugar com
acesso a Internet. O protocolo de comunicação dos dados é o HTTP e seus métodos de
transmissão POST e GET são utilizados, possibilitando salvar e recuperar informações.
Conforme a Figura 3.1 o dispositivo deve ser vestido pelo paciente em monitora-
mento, todos os dados coletados pelos sensores serão encaminhados para a nuvem, onde
serão tratados, analisados e enviados para armazenamento também em nuvem no banco
de dados em tempo real. E assim os dados serão acessados pelo aplicativo móvel, podendo
consultar histórico e acompanhar o monitoramento.
O dispositivo funciona de forma reativa, e emite alertas para o usuário sobre
estados da saúde do paciente. Caso a temperatura fique acima ou abaixo do normal,
possíveis anormalidades nos batimentos cardíacos ou até mesmo quando detectado quedas
do idoso.
3.2 Materiais 33
Figura 3.1: Figura ilustrativa da arquitetura do sistema de moni-

toramento proposto
3.2 Materiais
Todos os materiais utilizados e estudados no desenvolvimento do projeto serão
descritos individualmente, evidenciando suas funcionalidades e características.
3.2.1 Compra dos Materiais

Após a definição do tema, objetivos e escopo do projeto, foi realizado uma
busca pelos materiais necessários para a construção do dispositivo embarcado, levando em
consideração custo, que deve ser acessível, facilidade de uso para montagem do sistema e
tipo da plataforma, se possível com código aberto, buscando acesso fácil a bibliotecas de
códigos e possibilidades de modificações no código fonte.
Antes de se chegar aos materiais que compõem a versão final do protótipo
proposto neste trabalho, outros componentes foram estudados e feito a tentativa da
construção de um protótipo inicial. Em contrário a versão final, era constituído com a
plataforma Arduino como microcontrolador. O Arduino utilizado se tratava da versão
chamada Lilypad [47], própria para computação vestível. Em relação a conexão com rede
Wi-Fi, o módulo ESP-01 [64] da linha ESP8266 foi testado, e os demais componentes
foram o MPU6050 e Pulse Sensor Amped, que permaneceram na versão final e serão
detalhados neste capitulo.
Porém logo no inicio do desenvolvimento deste protótipo inicial, diversos pro-
blemas foram identificados, relacionados a arquitetura dos componentes e interligação
entre o Arduino Lilypad e o módulo ESP-01. Não houve uma comunicação satisfatória
entre os componentes, impossibilitando o uso da conexão com a rede Wi-Fi e causando
interferências na transmissão dos dados. Como se trata de um sistema com uma grande
coleta e transmissão de dados, foi necessário mudar os componentes envolvidos ao mi-
3.2 Materiais 34
crocontrolador e conexão com a rede sem fio. Assim se chegou aos materiais que serão
mostrados logo a seguir.
A Tabela 3.1 mostra o nome do componente, quantidade e valores dos materiais
que foram utilizados para a construção final do prototipo proposto neste trabalho. Os
valores estão convertidos em dólar americano (segundo cotação da moeda em Setembro
de 2017), porém todos os componentes foram adquiridos no Brasil.
Tabela 3.1: Lista de materiais utilizados para a construção do

sistema de monitoramento
Componente Quantidade Valor
NodeMCU ESP-12 ( 3.2.2) 1 US$ 10,00
Pulse Sensor Amped ( 3.2.3) 1 US$ 5,95
MPU6050 ( 3.2.4) 1 US$ 4,13
Bateria 9 volts Recarregável 1 US$ 12,53
3.2.2 Placa de Desenvolvimento NodeMCU

O NodeMCU é um módulo de prototipação para a Internet das Coisas, que
possui o microcontrolador ESP8266 em sua arquitetura e conta com uma plataforma de
desenvolvimento na linguagem C/C++ ou em Lua [70].
O módulo utiliza a versão ESP-12 do microcontrolador ESP8266, possui con-
versor micro USB para serial que permite a conexão com o computador e um regulador
de tensão interno para adequar a corrente elétrica de entrada no dispositivo. Existe uma
pinagem para cada interface de E/S, facilitando a prototipação e montagem de pequenos
circuitos. O módulo trabalha com uma tensão de 3,3 volts, conforme padrão do micro-
controlador. Ainda conta com antena embutida em seu circuito para conexão com a rede
Wi-FI. O seu modo de operação em rede pode ser como Station (STA), Access Point (AP)
ou com os dois modos combinados.
Figura 3.2: Figura ilustrativa do NodeMCU em sua versão 1.0

[70]
3.2 Materiais 35
Algumas características importantes do NodeMCU são descritas logo abaixo:
• Conexão com rede sem fio no padrão 802.11 b/g/n.

• Contém onze portas para conexões de E/S.
• Possui conexão para leitura e escrita analógica e digital.
• Protocolos suportados para comunicação entre dispositivos são I 2C e serial
Como mencionado anteriormente, o módulo trabalha com uma tensão de 3,3

volts, possuindo um regulador de tensão interno, possibilitando a alimentação do circuito
com uma bateria externa [11]. A Figura 3.3 destaca os pinos de E/S relacionados a energia
do NodeMCU e a seguir uma descrição detalhada de cada um dos pinos destacados.
Figura 3.3: Destaque do pinos relacionados a energia do No-

deMCU [11]
• USB Power: é utilizado como entrada de energia, caso seja necessário a utilização
de um conversor USB para carregar programas no microcontrolador. Não é utilizado
caso o circuito seja alimentado por uma bateria externa.
• 3,3V: funciona como E/S, podendo alimentar a placa com uma bateria externa de
3,3 volts, ou fornecer energia com a mesma tensão para sensores ou atuadores. Ao
total são três pinos com essa funcionalidade.
• VIN: é o pino que passa pelo regulador de tensão interno do NodeMCU, com isso
é utilizado para alimentação do circuito, suportando uma bateria de até 9 volts. O
regulador de tensão irá adequar a corrente elétrica de entrada para 3,3 volts, assim
componentes podem ser alimentados nos outros pinos de mesma voltagem.
• Ground: é o pinos terra, ao todo são cinco no NodeMCU, servindo como referencia
e ponto negativo para a conexão de bateria e outros componentes externos.
3.2 Materiais 36
O NodeMCU em seu circuito ainda apresenta nove pinos de E/S digitais e um

analógico, que servem para conexão de sensores e atuadores. Os pinos digitai são na
sequencia de D0 até D8 e o analógico identificado como A0. Um botão de reset, para
reiniciar o módulo e um flash para coloca-lo em modo de gravação do firmware. A antena
interna da rede Wi-Fi do módulo fica localizada em sua parte superior e logo abaixo o
microcontrolador ESP-12.
3.2.3 Sensor de Frequência Cardíaca

O Pulse Sensor Amped, é um sensor de frequência cardíaca, que realiza a coleta
de dados do BPM de uma pessoa. O sensor utiliza-se da técnica de fotopletismografia,
uma maneira não invasiva de medir a pulsação do coração e em algumas vezes a oxige-
nação do sangue. Essa técnica faz a leitura por meios óticos, através de uma luz infraver-
melha, que é emitida e refletida de volta, computando assim o sinal pletismográfico, que
indica o pulso e oxigenação do sangue [56].
No caso do Pulse Sensor, a identificação dos batimentos cardíacos é feita por um
sensor óptico com amplificador, que emite uma luz de cor verde por um LED e conforme
a luz é refletida de volta ao sensor ele registra a mudança do pulso e envia os dados para
o microcontrolador via sinal analógico [5].
A Figura 3.4 ilustra o Pulse Sensor Amped, que contém hardware e software
livres, podendo ser melhorados por qualquer pessoa interessada no projeto [6].
Figura 3.4: Figura ilustrativa do sensor de frequência cardíaca[5]
O sensor possui três conectores, onde cada um dos fios são ligados a placa
microcontroladora. O primeiro pino, é o GND, representa o fio negativo, o do meio VCC,
que é o de tensão positiva, operando entre 3 a 5 volts, e o último pino é o de sinal, por ele
o sensor envia os dados coletados para o microcontrolador.
3.2.4 Acelerômetro, Giroscópio e Sensor de Temperatura

O MPU6050 é um módulo para Internet das Coisas que possui acelerômetro,
giroscópio e um sensor de temperatura no mesmo chip. O acelerômetro faz a detecção da
3.3 Recursos 37
inclinação, movimentação e orientação no ambiente. O giroscópio identifica a direção do

movimento. O sensor é capaz de fazer a leitura tridimensional (eixo x, y e z) tanto para o
acelerômetro quanto para o giroscópio. O sensor de temperatura integrado, possibilita
a coleta de dados sobre a temperatura ambiente, a princípio em fahrenheit (o F) que
consequentemente pode ser convertida em graus celsius (o C) [8].
Figura 3.5: Figura ilustrativa do módulo MPU6050[8]
O módulo necessita de uma tensão com 3,3 volts para ser ligado, porém pode ser
alimentado com até 5 volts, pois possui um regulador de tensão interno, fazendo assim a
conexão com uma placa microcontroladora de forma transparente e sem muitas compli-
cações. A comunicação desse módulo com um microcontrolador é feita por barramento
I 2C.
O sensor possui 8 pinos que fazem interface com o microcontrolador. A funcio-
nalidade de cada um é descrita na Tabela 3.2.
Tabela 3.2: Pinos conectores do MPU6050
Pino Descrição
VCC pino de tensão positiva do módulo
GND pino de tensão negativa do módulo
SCL pino que faz a controle da comunicação com o microcontrolador
SDA pino que faz a comunicação com o microcontrolador
XDA pode ser usado para auxiliar a comunicação com outros módulos
XCL pino que pode fazer interface com módulos extras
AD0 pino auxiliar para mudar o endereço de comunicação do protocolo I 2C
pino de interrupção, usado para dizer ao microcontrolador quando os
INT
dados estão prontos para ser enviados
3.3 Recursos
Os recursos tecnológicos utilizados para a construção deste trabalho serão des-
critos individualmente nesta seção.
3.3 Recursos 38
3.3.1 O IDE Arduino

O IDE Arduino possibilita a conexão e programação das placas da plataforma
Arduino e de outras como as que utilizam o microcontrolador ESP8266. É um software
multiplataforma, que pode ser executado em diversos sistemas operacionais. A linguagem
de programação utilizada é o C ou C++ com algumas funções adicionadas que são
especificas para as plataforma com microcontroladores.
O ambiente de programação para Arduino, trabalha com sketch, que são os
programadas criados na IDE. Quando criado um sketch, é possível de forma fácil compilar
e carregar a programação para uma placa de desenvolvimento via conexão USB. Todo o
processo de criação, compilação, debug e carregamento do software é feito pelo IDE de
forma simples e intuitiva.
Um sketch contém uma estrutura básica, onde por padrão são duas funções,
setup() e loop(), conforme a Figura 3.6. A função setup() é executada apenas uma
vez, na inicialização do microcontrolador, onde normalmente são adicionados comandos
relacionado a configuração da placa ou de outros componentes. Em contrapartida a função
loop() é executada infinitas vezes, enquanto a placa estiver ligada. Nesta função é feita a
programação do sistema, indicando o que será executado de forma repetitiva.
Figura 3.6: Tela inicial do IDE Arduino
√
Ainda analisando a Figura 3.6 é possível notar dois botões com os símbolos e
→, que são referentes as funções de verificar e carregar respectivamente. Quando o botão
de verificar é acionado, o IDE realiza a compilação do código, verificando se há erros de
sintaxe no sketch. Em caso de erro ou sucesso são exibidas informações na área em preto
na parte inferior da janela. No caso do botão carregar, a compilação também é feita, mas
além disso, o sketch é carregado na placa que está conectada na entrada USB. Os status
3.3 Recursos 39
da compilação/carregamento são mostrados também na área em preto na parte inferior da

tela.
A Tabela 3.3 descreve alguns comandos que são reservados para trabalhar com
o IDE Arduino.
Tabela 3.3: Alguns comandos reservados da IDE Arduino
Código Descrição
pausa a executação da rotina por um período de tempo definido
delay()
em milisegundos
inicia o monitor da porta serial do microcontrolado com interface
Serial.begin()
da USB do computador
Serial.print() exibe um vetor de caracteres na portal serial
analogRead() faz a leitura analogia de um pino e retorna um valor entre 1-1023
digitalRead() faz aleitura digital de um pino e retorna HIGH ou LOW
3.3.2 O IDE PyCharm

O PyCharm é um IDE utilizada para a programação na linguagem Python e
possui diversos recursos extremamente uteis que facilitam diversas tarefas na escrita dos
códigos. Criado e mantido pela empresa JetBrains, é uma ferramente muito utilizada e
bem conceituada para o desenvolvimento em Python [53].
Possui duas versões, a Community Edition e a Professional Edition. Enquanto a
primeira é gratuita e possui alguns recursos limitados a segunda é uma versão completa
que oferece ferramentas avançadas para uma programação mais produtiva. As duas
versões são multiplataformas, podendo ser executadas em diversos sistemas operacionais.
A versão Community Edition, apesar de ser um pouco limitada, atende bem a diversas
situações, pois possui ferramentas para debugger, testes unitário, análise de código, auto
complemento, verificação de sintaxe, refatoração e salvamento de arquivos automáticos.
3.3.3 O IDE Visual Studio Code

O Visual Studio Code desenvolvido pela Microsoft, é um editor de código fonte
com suporte nativo para o desenvolvimento na linguagem JS e TS. É um projeto de código
aberto, que é fornecido de forma gratuita [65].
O IDE é multiplataforma e pode ser executado praticamente em todos os sistemas
operacionais. Desenvolvido no final do ano de 2015, é um editor simples, que consome
poucos recursos computacionais e apresenta eficiência na programação com JS e TS, pois
possui integração nativa com essas linguagens.
3.3 Recursos 40
3.3.4 Plataforma Heroku

O Heroku é uma plataforma de serviço em nuvem, do tipo PaaS, que oferece
suporte a várias linguagens de programação. A plataforma em questão tem como pro-
prietária a empresa Salesforce Company. O Heroku automatiza serviços de criação das
máquinas virtuais para armazenar sites e aplicações Web. O serviço utiliza conceito de
Dyno, onde cada Dyno é uma pequena máquina virtual, com 4 núcleos de processamento
e 512 megabytes de memória RAM. Utiliza-se o sistema operacional Debian, que é uma
distribuição Linux [20].
A princípio os serviços são gratuitos, porém com recursos limitados, onde é
possível armazenar um número indefinido de sites e serviços Web em linguagem como
PHP, Python, NodeJS, Ruby e outras. Pode-se utilizar conexão com banco de dados,
ter controle sobre as alterações nos códigos dos programas e garantir segurança sobre
os serviços armazenados na plataforma. Porém se requer desempenho e segurança mais
eficiente e até armazenar serviços escaláveis, é necessário garantir recursos adicionais que
são pagos. Para testes de aplicações o serviço oferece bons recursos, que conta até com
um nome de domínio personalizado e configuração de DNS (Domain Name System).
Para facilitar o uso do Heroku ao armazenar serviços na plataforma, é oferecido
a ferramenta chamada Toolbet CLI (Command Line Interface), que é multiplataforma e
executada na linha de comando ou terminal do sistema operacional. A mesma pode ser
instalada de forma gratuita e garante a criação e o upload da nova aplicação com poucos
comandos e de forma intuitiva. Juntamente com o CLI do Heroku para armazenar códigos
na plataforma, é utilizado o Git, ferramenta também executada em linha de comando para
interagir com repositórios remotos ou locais, que possibilita criar controle de versão para
o código [21].
Na Tabela 3.4 é descritos os principais comandos da ferramenta Toolbet CLI.
Tabela 3.4: Alguns comandos do Toolbet CLI do Heroku

Comando Descrição
heroku login autentica na conta da plataforma
heroku apps:create mirsi cria uma nova aplicação no servidor com o nome de mirsi
heroku logs –tail visualiza registro dos comandos executadas e suas ações
3.3.5 Plataforma Firebase

O Firebase é uma plataforma com serviços oferecidos na nuvem do tipo PaaS,
que possui diversas ferramentas uteis e eficientes para desenvolvimento de aplicações
Web e móveis. A plataforma é de propriedade do Google, onde a empresa faz manutenção,
evolui a plataforma e realiza a venda de alguns serviços extras. O Firebase atualmente
3.3 Recursos 41
conta com o suporte a aplicações desenvolvidas para iOS, Web e Android nas linguagens
C++, Java, Javascript, NodeJS, Objective-C e Swift [50].
O Firebase possui diversas funcionalidades, entre elas o Analytics, um painel
para monitoramento dos usuários e desempenho em geral das aplicações. Database que
é um banco de dados NoSQL para armazenamento de dados na nuvem em formato
JSON. Real Time Database, banco de dados em tempo real, pois possui o atraso de
armazenamento e recuperação de dados muito pequeno, a estrutura de armazenamento
é NoSQL, que possibilita a sincronização de dados com diversos sistemas ao mesmo
tempo.Firebase Cloud Messaging (FCM), que é um sistema para notificação de usuário,
conhecida como (Push Notification) onde pode ser em tempo real ou agendadas. Essa são
algumas funcionalidades importantes da plataforma.
A principio utilizar os serviços do Firebase é gratuito, porém é possível a
contratação de serviços extras, que proporcionam maior espaço para armazenamento de
dados, segurança e desempenho nas aplicações. A conta gratuita atende bem diversos
serviços, principalmente para testes e prototipação de sistemas.
Figura 3.7: Exemplo da estrutura do Firebase Real Time Database
3.3.6 Ionic Framework

O Ionic é um framework para desenvolvimento de aplicativos móveis na forma
híbrida [35]. Criado no final de 2013, o Ionic possibilita o desenvolvimento de aplicações
híbridas de forma rápida e eficiente.
O framework é composto pelo Cordova [34], da empresa Apache, que possibilita
a instalação de plugins, onde recursos nativos dos dispositivos são disponibilizados para
acesso, como câmera, GPS, acelerômetro e outros. O Angular que é outro framework,
esse mantido pelo Google [37], que utiliza a linguagem de programação JS, e fornece
3.3 Recursos 42
recursos para desenvolvimento Web, com HTML, CSS e JS. O Ionic Module e o Ionic
CLI, onde o primeiro contém as bibliotecas para desenvolvimento das aplicações móveis e
o segundo disponibiliza recursos pelo terminal de comando do sistema operacional para a
criação rápida de diversos componentes [35]. Todo o aplicativo pode ser escrito utilizando
a linguagem TS.
Após o processo de desenvolvimento do aplicativo, é utilizado as ferramentas
disponibilizadas pelo Cordova para gerar e executar o aplicativo no dispositivo móvel,
tanto para Android quanto iOS.
3.3.7 Flask Microframework

O Flask é um microframework que possibilita o desenvolvimento de aplicações
Web utilizando a linguagem Python. É um microframework, pois não define uma estrutura
rígida de projeto a ser seguida, preserva a liberdade de decisão das ferramentas a serem
utilizadas por parte do desenvolvedor [76].
O Flask é utilizado para aplicações de pequeno até grande porte, oferece toda
a simplicidade do Python para escrita de código, possibilitando a execução da aplicação
em um servidor Web. Com o microframework é possível o desenvolvimento de sites, Web
API e API REST1 .
1 Siglapara Representational State Transfer, em português, Transferência de Estado Representacional.

Define princípios e regras para criação de Web API utilizando o protocolo HTTP.
CAPÍTULO 4
Desenvolvimento
Neste capitulo o objetivo é descrever os métodos empregados no projeto até o

desenvolvimento do protótipo final. Os materiais descritos no capitulo 3 foram testados
individualmente e integrados ao protótipo gradualmente. Os softwares implementados na
construção do sistema foram desenvolvidos utilizando os recursos tecnológicos também
descritos no capitulo mencionado.
4.1 Estrutura Geral do Sistema

Antes do desenvolvimento do protótipo, foi realizado o planejamento e docu-
mentação das atividades que cada componente do sistema deve empenhar. Para essa ta-
refa, foi utilizado o software Astah, que possui uma versão gratuita e possibilita a criação
de diagramas conforme as definições da UML (Unified Modeling Language).
Figura 4.1: Diagrama de Atividade do Sistema de Monitoramento

4.2 Etapas da Construção do Sistema 44
O diagrama escolhido para representar de forma ampla a estrutura do sistema é o

de atividades representado na Figura 4.1. Descreve em sequencia o que cada componente
do sistema deve executar, levando em consideração o usuário, a parte física e lógica do
sistema. A Tabela 4.1 contém a descrição das atividades contidas no diagrama apresentado
anteriormente.
Tabela 4.1: Tabela com a descrição das atividades
Componente Descrição da Atividade
Vestir a roupa com o dispositivo e ligar-lo para iniciar o
Idoso
monitoramento e envio dos dados.
Coletar dados através dos sensores e envia-los pela internet
Sistema Embarcado
para o Web API.
Receber os dados do sistema embarcado, analisar os dados,
Web API enviar para o armazenamento e criar notificação em
caso de necessidade.
Armazenar os dados em tempo real, processar e enviar
Firebase
notificação para o aplicativo móvel.
Mostrar os dados salvos de forma personalizada e informar
Aplicativo Móvel
recebimento de notificações quando necessário.
4.2 Etapas da Construção do Sistema

Com o objetivo de alcançar o pleno funcionamento das atividades exercidas
pelo sistema, conforme descrito na seção anterior, foi definido algumas etapas para a
sua construção que são mostradas na Figura 4.2.
Figura 4.2: Fluxo de etapas a serem realizadas no projeto

Com o projeto dividido em etapas, fica mais claro o que deve ser realizado
primeiro para executar uma certa função do sistema e assim as demais funcionalidades.
Uma descrição detalhada de cada etapa se encontra logo abaixo:
1. Construção do sistema embarcado: esta etapa é relacionada a construção física

do dispositivo e sua implementação lógica, interligando todos os componentes de
hardware e construir o algoritmo para realizar a função dedicada do sistema.
2. Configuração do Firebase: neste momento a configuração do Firebase será reali-
zada. Adicionando um novo projeto a plataforma, configurando a autenticação no
serviço, o banco de dados em tempo real e as notificações de usuário.
3. Desenvolvimento da Web API: nesta etapa do desenvolvimento é utilizado Python
e Flask. Com a API é possível oferecer uma interface Web buscando integrar o
sistema embarcado com os serviços do Firebase.
4. Desenvolvimento do Aplicativo Móvel: nesta etapa o desenvolvimento do aplicativo
móvel ocorrerá, com o objetivo de mostrar os dados de forma simples, com fácil
compreensão para a pessoa interessada no monitoramento da saúde do idoso.
5. Testes e Resultados: nesta etapa os testes e resultados serão verificados. O objetivo
é validar a solução proposta e verificar se os resultados estão dentro dos objetivos
traçados. o
Todas as etapas são dependentes das suas anteriores, porém podem ser execu-
tadas em paralelo, mas devem seguir a ordem para pleno funcionamento de cada etapa.
Após a conclusão de duas etapas que se sucedem, a integração das duas ocorrem e assim
sucessivamente até que o sistema esteja desenvolvido por completo.
4.3 Montagem do Hardware

Nesta etapa é realizada a montagem de hardware do sistema embarcado. Primei-
ramente, por questão de documentação e melhor visualização do resultado a ser alcan-
çado, foi utilizado uma ferramenta para prototipação de sistemas voltados para a Internet
das Coisas, chamada Fritizing. É um software com código aberto, onde o objetivo é ajudar
com os esquemas da montagem do hardware e suas conexões físicas.
O protótipo realizado com a ajuda do Fritizing pode ser conferido na Figura 4.3.
Onde no centro do sistema se encontra o NodeMCU que com o microcontrolador
ESP8266 faz a interface de conexão com o sensor de frequência cardíaca, acelerômetro,
giroscópio e o sensor de temperatura. O NodeMCU ainda é responsável por realizar
conexão com a rede Wi-Fi e fazer comunicação com a Internet. O sistema é alimentado
com uma bateria recarregável de 9 volts.
Figura 4.3: Figura ilustrativa com o protótipo do sistema embar-

cado feito no Fritizing
A Tabela 4.2 mostra com detalhes como os componentes estão ligados ao No-
deMCU. Quais os pinos que estão sendo utilizados e como está sendo feito a comunicação
entre os dispositivos que compõem o sistema.
Tabela 4.2: Detalhe da conexão entre os componentes

Pino do Dispositivo Pino
Descrição
NodeMCU Conectado Conectado
3,3V MPU6050 VCC Conexão da tensão positiva
GND MPU6050 GND Conexão da tensão neutra
D5 MPU6050 SDA Conexão de comunicação I 2C
D6 MPU6050 SDL Conexão de comunicação I 2C
A0 Pulse Sensor Sinal Conexão de comunicação analógica
3,3 V Pulse Sensor VCC Conexão da tensão positiva
GND Pulse Sensor GND Conexão da tensão neutra
VIN Bateria + Conexão de alimentação positiva
GND Bateria - Conexão de alimentação neutra
Conforme mencionado na seção 3.2.4 o MPU6050 além das conexões relacio-

nadas a energia, necessita da conexão SDA e SCL, para controlar a pulsação do clock e a
transmissão dos dados para o barramento através do protocolo I 2C. O sensor de frequência
cardíaca, necessita apenas das conexão de energia e os dados são transmitidos de forma
analógica para o microcontrolador. A bateria de 9 volts é conectada direto nos pinos por
onde passa o regulador de tensão, assim todo o circuito é alimentado apenas com 3,3 volts
sem ocorrer danos ao hardware.
A Figura 4.3 mostra o resultado após a conexão de todos os componentes. No
centro o NodeMCU, a esquerda o Pulse Sensor, na parte direita superior o MPU6050 e
abaixo a bateria de 9 volts. Todos os componentes ligados e devidamente conectados.
Figura 4.4: Protótipo real com todos os componentes conectados

ao NodeMCU
Para transformação do sistema embarcado em computação vestível, os compo-

nentes foram costurados em uma camiseta, possibilitando o idoso utilizar a roupa para
monitoramento de sua saúde. Com o intuito de facilitar a costura do dispositivo à roupa,
foi necessário que todos os pinos do NodeMCU fossem entortados de forma externa ao
microcontrolador. Já os pinos que estão conectados ao MPU6050 e Pulse Sensor tiveram
os jumpers de conexão sodados diretamente ao NodeMCU, de forma que o dispositivo
possa ser o menos desconfortável e invasivo ao seu utilizador, possibilitando ainda resis-
tência contra possíveis impactos contra o dispositivo. O primeiro protótipo finalizado é
mostrado na Figura 4.5.
Figura 4.5: Primeiro protótipo do sistema costurado na parte in-

terna de uma camiseta
Porém depois de realizar alguns testes, foi verificado que a forma como o
dispositivo estava costurado à roupa não facilitava a sua vestimenta e também faltava
proteção aos componentes fixados, caso houvesse uma queda ou mesmo um movimento
brusco do utilizador, poderia ocorrer algum dano que desativasse por completo o sistema.
Pensando nessas considerações, o primeiro protótipo foi melhorado, mantendo as mesmas
conexões, mas todos os componentes foram fixados em uma capa protetora. Os fios foram
organizados e a costura na roupa ficou mais simples, podendo ocorrer de formas diferentes
e também facilmente ser removido e costurado em outras roupas. A Figura 4.6 mostra a
esquerda os componentes fixados a capa protetora e a direita como foi costurado em um
roupa para sua utilização.
Figura 4.6: Protótipo final do sistema costurado na parte interna

de uma camiseta
Para obter corretamente o BPM e a temperatura corporal, é necessário que o

MPU6050 e Pulse Sensor estejam em contato diretamente com a pele, na posição do
coração, fixados com algum tipo de fita adesiva. A forma como o dispositivo está anexado
à roupa facilita a mesma ser vestida e os componentes serem ficados à pele do idoso.
4.4 Algoritmo do Sistema Embarcado

Todo o algoritmo desenvolvido nesta seção foi implementado utilizando a lin-
guagem C++ e o IDE Arduino.
Como a plataforma do microcontrolador utilizado não se trata do Arduino e sim
NodeMCU, o suporte para compilar e gravar o código no microcontrolador não está dis-
ponível de forma nativa no IDE, fazendo necessário a instalação de uma placa extra den-
tro do editor [43]. Adicionado a plataforma que contém suporte aos microcontroladores
ESP8266, é necessário incluir e importar as bibliotecas para uso na construção do algo-
ritmo.
As bibliotecas utilizadas neste projeto são descritas logo a seguir:
• Ticker: é uma biblioteca especifica para ESP8266, com o objetivo de colocar

uma função em segundo plano e através do ticker fazer com que ela execute
periodicamente, conforme um tempo predefinido [40].
• Wire: esta biblioteca permite realizar a comunicação por protocolo I 2C pelas
interfaces SCL e SDA [7]. Permitindo até escolher qualquer pino da placa para
se transformar em uma interface I 2C e assim fazer comunicação com outros
componentes.
• ESP8266WiFi: biblioteca especifica para o ESP8266, oferece funções que permitem
escolher o modo de operação (AP ou STA), conectar a rede Wi-FI, mostrar endere-
çamento de rede local, verificar o status e oferecer diagnósticos para a conexão de
rede [44].
• WiFiClientSecure: biblioteca especifica para o ESP8266, permite a transmissão de
dados via protocolo HTTPS utilizando os métodos GET ou POST [41]. A transmis-
são de dados é feita de forma segura, utilizando criptografia e possibilitando até o
uso de certificados digitais.
• MPU6050: biblioteca voltada para uso do MPU6050, possui comunicação pelo
protocolo I 2C e oferece funções para ler dados do acelerômetro, giroscópio e
sensor de temperatura [52]. A biblioteca possui funções que realizam cálculos para
normalização dos dados coletados do modulo e outras funções extras que auxilia o
desenvolvimento.
O código 4.1 mostra como incluir as cinco bibliotecas descritas anteriormente.
Código 4.1 Inclusão das bibliotecas utilizadas no algoritmo do

sistema embarcado
1 #include <Ticker.h>
2 #include <Wire.h>
3 #include <ESP8266WiFi.h>
4 #include <WiFiClientSecure.h>
5 #include <MPU6050.h>
O sistema basicamente se utiliza de dois algoritmos para realizar suas operações.

O primeiro algoritmo é para a definir as funcionalidades, enquanto o segundo é o
algoritmo de interrupção. O primeiro sketch faz conexão com a rede Wi-Fi, leitura de
dados dos sensores e comunicação pela rede de Internet, sua execução é em loop, de
forma interrupta, enquanto o sistema estiver ligado. A coleta de dados ocorre em um
prazo de 1000 milissegundos, que é equivalente a 1 segundo, conferindo um atraso ao
sistema. A cada interação, antes do prazo de atraso definido é feito a leitura dos sensores
e o envio dos dados para a Web API. O segundo sketch, o de interrupção, funciona em
todo tempo, utilizando o Ticker, especificamente para o sensor de batimentos cardíacos,

que faz a verificação se há frequência cardíaca a ser medida.
O código é construído de forma estruturada, onde cada função deve executar ape-
nas uma tarefa, facilitando alterações que possam ser necessárias e o desenvolvimento de
novas funcionalidades. A função setup() que é mostrada no código 4.2, faz a inicialização
das configurações a serem utilizadas. Para facilitar, é criado três funções para essas tare-
fas, a primeira faz inicialização da rede Wi-Fi, a segunda do sensor de frequência cardíaca
e a terceira do acelerômetro, giroscópio e temperatura.
Código 4.2 Função para inicializar as confi-

gurações do sistema
1 void setup(){
2 setupWiFI();
3 setupPulseSensor();
4 setupMPU();
5 }
O código 4.3 faz a tarefa de inicialização da rede Wi-Fi. Nesta função é definido
a utilização da rede como STA, realiza a conexão com a rede Wi-Fi local, passando como
parâmetros nome e senha, por último verifica se a conexão foi realizada, caso contraria
tenta novamente a cada meio segundo até que seja estabelecida a conexão.
Código 4.3 Função para estabelecer a conexão com uma rede

Wi-Fi
1 void setupWiFI() {
2 WiFi.mode(WIFI_STA);
3 WiFi.begin(nome, senha);
4
5 while (WiFi.status() != WL_CONNECTED) {

6 delay(500);
7 }
8 }
A leitura dos dados pelo sensor de frequência cardíaca é realizada de forma ana-
lógica, apenas utilizando a função nativa analogRead. A leitura dos dados é realizada
dentro da função ticker, que executa de forma periódica a cada dois milissegundos, bus-
cando encontrar alguma alteração na frequência do led que se referencie como um sinal
de batimentos cardíacos. A função de forma resumida pode ser conferida a seguir 4.4.
Código 4.4 Função para realizar a leitura dos batimentos car-

díacos
1 void interrupcaoSetup(){
2 ticker.attach_ms(2, leituraSinalBPM);
3 }
4
5 void leituraSinalBPM(){
6 Sinal = analogRead(pinoPulseSensor);
7 }
A leitura do acelerômetro e giroscópio nos três eixos (X, Y e Z) é feita através

da biblioteca MPU6050, que traz funções com cálculos que normaliza os dados coletados
e tenta evitar as grandes oscilações que ocorrem quando utilizado este sensor. A função
para leitura do acelerômetro e giroscópio respectivamente é readNormalizeAccel e re-
adNormalizeGyro, que retorna um vetor contendo os valores dos eixos. A temperatura
também é coletada por esta biblioteca, pela função readTemperature que já converte de
o F em o C. O código 4.5 exemplifica como é realizado esta tarefa.
Código 4.5 Função para realizar a leitura do acelerômetro,

giroscópio e temperatura
1 void lerDadosMPU() {
2 aclNormalizado = mpu.readNormalizeAccel();
3 girNormalizado = mpu.readNormalizeGyro();
4 temperatura = mpu.readTemperature();
5 }
6
A biblioteca MPU6050 ainda possui uma função chamada readActivites(), onde

um dos seus objetivos é detectar quedas livres através dos valores do acelerômetro. O valor
de retorno é verdadeiro (true) em caso de queda e falso (false) para situações normais.
A função realiza cálculos de forma binária, fazendo deslocamento de bits no valor de
leitura do acelerômetro, verificando assim se houve uma aceleração nos eixos que seja
fora do padrão, o que pode caracterizar uma queda. Porém através de testes, foi verificado
que a função funciona para alguns casos, dependendo da posição em que se encontra o
acelerômetro, antes de ocorrer a aceleração provocada pela queda.
A Figura 4.7 ilustra a posição que é fixado o acelerômetro e como está disposto
os seus eixos no caso do protótipo deste trabalho. Para esta posição do MPU6050,
através das simulações de queda, a função readActivites() não obteve sucesso, não
identificando em nenhum momento uma queda sofrida. Com o intuito de resolver o
problema, sem o uso da biblioteca, foi analisado padrões de acelerações dos eixos X,
Y e Z, definido limites a ser comparados com cada valor retornado pelo acelerômetro,
buscando situações que caracterize uma queda. A responsabilidade de analisar os dados
e realizar as comparações dos intervalos, foi passada para a Web API, pelo fato de conter
maior poder de processamento no servidor que em um microcontrolador, além da questão
de padronizar as tarefas a serem realizadas por cada componente do sistema.
Figura 4.7: Figura ilustrativa da posição do MPU6050 no corpo

do paciente
Os dados dos sensores são enviados para a Internet utilizando o método GET,
onde é construído um link com todos os dados coletados e a informação de destino, que é
a URL. Assim após montar a URL os dados são enviados por HTTPS, utilizando a porta
443 para a Web API através da biblioteca WiFiClientSecure. O código 4.7 mostra como
é feito a montagem da URL concatenando diversas strings. E o código 4.6 exemplifica
como são enviados os dados.
Código 4.6 Função para enviar os dados para o servidor Web

API
1 void enviarDadosAPI() {
2 if (!client.connect(urlAPI, apiPorta)) {
3 //reconectando ao servidor em caso de falha
4 }
5 String url = montaURL();
6 client.print(url);
7 }
Código 4.7 Função para realizar a montagem da URL com os

dados
1 String montaURL() {
2 String msg;
3
4 msg.concat("GET /api/monitoramento/salvar?");
5 msg.concat("bpm=");
6 msg.concat(BPM);
7 msg.concat("&temperatura=");
8 msg.concat(temperatura);
9 msg.concat("&aclX=");
10 msg.concat(aclNormalizado.XAxis);
11 msg.concat("&aclY=");
12 msg.concat(aclNormalizado.YAxis);
13 msg.concat("&aclZ=");
14 msg.concat(aclNormalizado.ZAxis);
15 msg.concat("&girX=");
16 msg.concat(girNormalizado.XAxis);
17 msg.concat("&girY=");
18 msg.concat(girNormalizado.YAxis);
19 msg.concat("&girZ=");
20 msg.concat(girNormalizado.ZAxis);
21 msg.concat(" HTTP/1.1\r\nHost: ");
22 msg.concat(urlAPI);
23 msg.concat("\r\nConnection: close\r\n\r\n");
24
25 return msg;
26 }
A função loop() mostrada no código 4.8, possui a tarefa de chamar as outras

funções a serem executadas, realizando de forma dedicada a coleta de dados dos sensores
e o envio para a Web API enquanto o sistema estiver em funcionamento. Possui o atraso
de 1000 milissegundos, com o objetivo de pausar o sistema durante este tempo, para que
os dados sejam recebidos pela Web API e gravados no banco de dados em tempo real,
evitando assim a sobrecarga dos demais componentes do sistema.
4.5 Configuração do Firebase 54
Código 4.8 Função para chamar a execução das outras funcio-

nalidades do sistema
1 void loop(){
2 lerDadosPulso();
3 lerDadosMPU();
4 enviarDadosAPI();
5
6 delay(1000);
7 }
4.5 Configuração do Firebase

Para a utilização dos serviços oferecidos pelo Firebase, primeiramente é neces-
sário possuir uma conta Google e logo após acessar o site oficial da plataforma [51]. Com
acesso configurado o próximo passo é adicionar um novo projeto. O nome do projeto
criado para este trabalho foi MIRSI (Monitoramento Inteligente e Remoto da Saúde do
Idoso).
Como os recursos a serem utilizados serão acessados por um aplicativo móvel,
é necessário configurar um novo aplicativo na plataforma, assim a integração entre as
tecnologias se torna mais transparente. O nome do aplicativo seguindo os padrões da
Google foi definido como com.mirsi.app.
Figura 4.8: Tela inicial de um projeto criado no Firebase
Após a criação do aplicativo no Firebase, é necessário ativar os serviços que se

deseja utilizar. Para esse projeto, são utilizados o banco de dados em tempo real (Realtime
Database) para salvar os dados do monitoramento, autenticação (Authentication) para
integrar a Web API e o aplicativo móvel com plataforma e as notificações (Notificarions)
para enviar alertas ao dispositivo móvel quando necessário.
O banco de dados em tempo por ser NoSQL, vai fornecer o armazenamento dos
dados na estrutura de JSON. O modelo de dados é simplificado e facilmente expandido,
não possuindo uma estrutura fixa, o que possibilita adicionar outros campos de dados
facilmente, sem perca de informação ou alterações em configurações da base de dados.
A autenticação oferece criação de usuário com senha para se conectar aos
serviços da plataforma. Para este projeto foi criado um usuário com permissões para
gravar e recuperar dados no Firebase. Apenas este usuário pode manipular os dados
contidos na plataforma.
As notificações fornecem uma interface para smartphones, possibilitando rece-
ber alertas através do aplicativo, que deve conter o mesmo nome de projeto definido nas
configurações iniciais do Firebase.
A Figura 4.9 exemplifica a estrutura de como os dados são gravados no banco de
dados em tempo real do Firebase.
Figura 4.9: Estrutura de armazenamento dos dados no bando de

dados em tempo real do Firebase
4.6 Desenvolvimento da Web API

A Web API faz o meio entre o dispositivo de monitoramento, que é o sistema
embarcado e a plataforma Firebase, que contém o banco de dados a ser utilizado.
O desenvolvimento é com a linguagem de programação Python na versão 3.5.2 e o
microframework Flask na versão 0.12.2. Além de utilizar as bibliotecas padrões que a
linguagem oferece, outras externas como Pyrebase [17] e PyFCM[1] foram agregadas ao
projeto.
A Pyrebase é uma biblioteca utilizada para realizar a integração com o banco de
dados do Firebase. Fornece funções que conectam através de autenticação, salva, edita,
atualiza e apaga dados do banco de dados e ainda conta com consultas personalizadas
para recuperar informação da base de dados. A versão utilizada do Pyrebase é a 3.0.27.
Quanto a biblioteca PyFCM também oferece uma interface com o Firebase, porém neste
caso com o serviço FCM, que é utilizado para o envio de notificações ao aplicativo móvel.
A versão utilizada neste trabalho é a 1.4.3.
A instalação das bibliotecas referenciadas anteriormente é feita através do ge-
renciado de pacotes do Python, o pip [33]. Um gerenciador de pacote é executado por
linha de comando, e pode instalar ou remover programas, no caso do Python as bibliote-
cas. A versão do pip utilizada é a 9.0.1 e os comandos para instalação são encontrados na
Tabela 4.3.
Tabela 4.3: Comandos para instalar pacotes no Python utilizando
o pip
Comando Pacote Descrição
pip install pyrebase Pyrebase Instalação da biblioteca
pip install pyfcm PyFCM Instalação da biblioteca
pip install flask Flask Instalação do microframework
Com todos os pacotes necessários instalados, é preciso definir as rotas (routes).

Uma rota é a terminologia utilizada em desenvolvimento de API que define a URL
onde um serviço pode ser acessado de forma direta por uma outra aplicação [75]. Neste
projeto apenas duas rotas são definidas. A primeira definida como rota principal, que é
apenas para validar se o serviço está online e a outra para receber os dados enviados pelo
dispositivo embarcado e assim salva-los no banco de dados.
A forma de declaração da rota conforme utilizando o Flask e sua respectiva
descrição é mostrada na Tabela 4.4.
Tabela 4.4: Declaração das rotas utilizando o Python e Flask

Rota Descrição
Rota principal, apenas para verificar se a
@app.route("/", methods=’GET’)
Web API está funcionando.
Rota para receber os dados coletados pelos
@app.route("/api/monitoramento/salvar")
sensores e salvar no banco de dados.
Os dados do monitoramento recebidos pela rota de salvar seguem um padrão de

estrutura JSON, possibilitando serem salvos no banco de dados do Firebase. A estrutura
basicamente é composta por uma lista de valores definidos por chave-valor. O código 4.9
mostra a função definida na Web API com o nome retorna_json, responsável por receber
os dados enviados pelo sistema embarcado, estruturar no formato JSON e retorna-los para
outra função gravar no banco de dados. Para simplificar o nome das chaves dos dados,
foram feitas abreviações. A Tabela 4.5 descreve o que significa o nome de cada chave.
Código 4.9 Função para estruturação dos dados na Web API

em JSON
1 def retorna_json(bpm, temp, aclX, aclY, aclZ,
2 girX, girY, girZ, situacaoSaude,
3 data, timestamp):
4 json = {
5 "bpm": bpm,
6 "temp": temp,
7 "aclX": aclX,
8 "aclY": aclY,
9 "aclZ": aclZ,
10 "girX": girX,
11 "girY": girY,
12 "girZ": girZ,
13 "situacaoSaude": situacaoSaude,
14 "data": data,
15 "timestamp": timestamp
16 }
17
18 return json
Tabela 4.5: Descrição do JSON com os dados de monitoramento

da Web API
Chave Descrição
bpm Batimento por minuto
temp Temperatura corporal
aclX Acelerômetro do eixo X
aclY Acelerômetro do eixo Y
aclZ Acelerômetro do eixo Z
girX Giroscópio do eixo X
girY Giroscópio do eixo Y
girZ Giroscópio do eixo Z
data Data atual
timestamp Data e hora atual
situacaoSaude Situações conforme análise da saúde
Além de salvar os dados recebidos, é necessário realizar o processo de analise

dos dados, com o objetivo de verificar situações com possíveis quedas, frequência car-
díaca e temperatura acima ou abaixo do normal. Os dados relacionados ao acelerômetro
são analisados para identificar situações de quedas, o do sensor de pulso para anormalida-
des na frequência cardíaca e o do sensor de temperatura para temperatura corporal acima
ou abaixo do normal. A Tabela 4.6 exemplifica como é feito a analise por intervalos dos
dados.
Tabela 4.6: intervalos de comparação para definir situações da
saúde
Intervalo de
Variável analisada Situação da Saúde
Comparação
BPM Maior ou igual a 160 Frequência cardíaca acima do normal
Menor ou igual a 40 Frequência cardíaca abaixo do normal
Igual a 0 Frequência cardíaca não detectada
Temperatura Maior ou igual a 37,4 Temperatura Corporal acima do normal
Menor ou igual a 34 Temperatura Corporal abaixo do normal
Além das comparações mencionadas que são feitas por intervalos, é realizado
o cálculo da mediana dos últimos 60 dados anteriores relacionados ao BPM, e feito
a comparação com cada valor capturado da frequência cardíaca. Os últimos 60 BPM
são relacionados a cerca de 3 minutos de monitoramento, pois os dados são gravados
no banco em média a cada 3 segundos, ou seja, são cerca de 20 dados gravados por
minuto, considerando o atraso que pode ocorrer entre a captura dos dados pelo dispositivo
embarcado, o envio para Internet e o armazenamento no banco de dados. Com essa
comparação é possível verificar se o BPM está acima ou abaixo da mediana considerando
a própria pessoa, buscando uma análise que indique possíveis riscos, com o intuito de
gerar alertas para complicações cardíacas. A mediana é escolhida nesta situação, pois
diferentemente da média, ela não é influenciada por anomalias nos dados.
Caso haja algum problema identificado nessa analise que foi exposta anterior-
mente, em cada um dos casos é gerado uma notificação de alerta para o usuário, podendo
gerar mais de uma ao mesmo tempo, pois são feitas de forma individual.
4.6.1 Adicionando a Web API na Plataforma Heroku

A utilização do Heroku tem o intuito de armazenar o código da Web API em
nuvem e assim disponibilizar o acesso de forma online, excluindo a necessidade de haver
um servidor local para se comunicar com o dispositivo de monitoramento, simplificando
a infraestrutura do sistema e rompendo barreiras na questão da mobilidade e abrangência
de localidade para o seu funcionamento. Com a API funcionando em nuvem, o seu acesso
pode ser realizado em qualquer lugar com Internet disponível, o que não acontece com
um servidor configurado localmente em alguns casos.
A principio é necessário ter uma conta no Heroku [20] e criar um novo projeto.
Para este trabalho o nome do projeto escolhido foi mirsi-server. Após isso, é necessário
adicionar o código no servidor oferecido pela plataforma. Para esta tarefa, foi utilizado o
Toolbet CLI em conjunto com o Git.
Com as ferramentas Heroku CLI e Git, é possível disponibilizar o código da

Web API no servidor, mas antes é necessário definir um arquivo chamado requirements
no formato de texto, na mesma pasta que contém o código fonte do projeto em Python. O
arquivo deve conter todas as bibliotecas externas e suas respectivas versões utilizadas no
projeto, conforme foram listadas na seção 4.6. A Figura 4.10 mostra como ficou o arquivo
requirements deste projeto.
Figura 4.10: Conteúdo do arquivo requirements da Web API
Os comandos utilizados para adicionar o código em Python no Heroku são

descritos em sequencia de execução na Tabela 4.7. É importante destacar que a plataforma
reconhece a linguagem utilizada e as bibliotecas listadas no arquivo requirements são
instaladas automaticamente, assim todo o ambiente é preparado para executar a aplicação.
Tabela 4.7: Comandos executados para adicionar projeto ao He-

roku
Comando Executado Descrição
Realiza login na plataforma com usuário e
heroku login
senha.
Criação do arquivo requirements de forma
pip freeze >requirements.txt
automática.
git init Inicialização para utilizar o Git no projeto
Adiciona todos os arquivos a serem enviados
git add *
para o servidor na nuvem.
Confirma os arquivos a serem adicionados
git commit -m "mensagem" e atribui uma mensagem a essa ação no
controle de versão.
Faz o upload de todos os arquivos adicionados
git push heroku master
para a plataforma do Heroku.
Com a aplicação devidamente armazenada no Heroku, a plataforma ainda ofe-

rece uma URL personalizada, que contém o nome do projeto e o domínio do serviço
em nuvem. O link gerada para este projeto e utilizado para enviar os dados pelo sis-
tema embarcado é https://mirsi-server.herokuapp.com/. As rotas definidas na aplicação,
estão disponíveis a partir deste link, como por exemplo a rota de salvar https://mirsi-
server.herokuapp.com/api/monitoramento/salvar. A Figura 4.11 apresenta a rota inicial
da Web API e a mensagem emitida quando acessada.
Figura 4.11: Mensagem emitida pela rota principal da Web API

quando acessada
4.7 Desenvolvimento do Aplicativo Móvel

Com o intuito de facilitar as atividades envolvidas no desenvolvimento deste
aplicativo, a Figura 4.12 expressa um diagrama de atividade contendo todas os passos
para criação do aplicativo. Cada um dos passos serão descritos no decorrer desta seção
com detalhes.
Figura 4.12: Diagrama de atividades com a etapas de desenvolvi-

mento do aplicativo
4.7.1 Estruturação do Projeto

A principio é necessário planejar e gerar a documentação que venha deixar claro
quais funcionalidades serão desenvolvidas na aplicação. Por ser tratar de um aplicativo
simples, foi gerado o diagrama casos de uso, que expressa todas as funcionalidades e
interações que o usuário terá com o aplicativo.
Na Figura 4.13 é apresentado o diagrama casos de uso, desenvolvido no Astah
que é descrito logo abaixo.
• Preencher formulário: será apresentado um formulário, onde o usuário deve infor-

mar os dados do idoso em monitoramento.
• Visualizar monitoramento: visualizar em tempo real e acompanhar as informações

sobre a saúde coletadas pelos sensores do dispositivo embarcado.
• Visualizar histórico: visualizar o histórico do monitoramento de forma ampla,
abrangendo vários dias e diversas informações.
• Visualizar batimentos cardíacos: será a primeira opção visualizada quando aces-
sado o histórico, mostrando os batimentos por minutos de todos os dias de monito-
ramento.
• Visualizar temperatura: opção que pode ser acessada em histórico, mostrando a
medição da temperatura corporal de todos os dias de monitoramento.
• Visualizar situações: poderá ser acessada em histórico, contendo as situações da
saúde, como quedas, aumento ou diminuição da frequência cardíaca ou da tempe-
ratura e outras.
• Visualizar perfil: visualizar os dados que foram cadastrados no fomulário.
• Alterar foto do perfil: a foto de perfil do paciente poderá ser alterada para persona-
lizar o aplicativo.
• Visualizar notificações: visualizar as notificações que chegam por meio do aplica-
tivo, quando houver alguma alteração na saúde do idoso em monitoramento.
Figura 4.13: Diagrama de Casos de Uso do aplicativo móvel
Quando criado um novo projeto no Ionic, por padrão deve-se escolher uma
estrutura para as páginas e o nome do projeto. Para este projeto a estrutura definida foi a
tabs e o nome como mirsi-app. A Figura 4.14 mostra a estrutura padrão do Ionic que será
seguida para desenvolvimento deste aplicativo.
A próxima atividade é criar as páginas que contém as interações com o usuário,

onde cada página é uma classe do projeto em Ionic. Conforme os padrões do framework, o
projeto é estruturado de forma parecido com websites, onde se tem uma ou mais páginas
para cada funcionalidade. Foram criadas quatro páginas neste projeto. O nome de cada
uma com respectiva descrição estão na Tabela 4.8.
Figura 4.14: Estrutura padrão do tipo tabs no Ionic
Tabela 4.8: Descrição das páginas que compõem o aplicativo

Página Descrição
Página inicial, onde são mostrados gráficos e informações em tempo real,
dashboard
conforme a funcionalidade visualizar monitoramento.
Esta página é mostrada apenas na primeira utilização do aplicativo, para
formulário que o usuário preencha o formulário com os dados: nome, sexo, peso,
data de nascimento, tipo sanguíneo e altura do idoso.
Página que mostra de forma agrupada por data, todo o histórico dos dados,
histórico
nos grupos de BPM, temperatura corporal e situações da saúde.
Página que mostra informações do paciente e também é possível inserir
perfil
uma foto para personalizar o aplicativo.
Depois da criação das páginas no projeto, como ficou a estrutura pode ser
conferido na Figura 4.15. Cada nível principal do projeto é uma pasta, que contém
arquivos ou subpastas.
A pasta app é a principal, contém os arquivos de configuração inicial da aplicação
e as declarações de todas bibliotecas e plugins utilizados no desenvolvimento. A assets
é direcionada para armazenamento de imagens que são utilizadas no aplicativo. A pasta
domain é uma pasta criada com a finalidade de armazenar arquivos referente as principais
funcionalidade da aplicação, onde podem ser utilizados por vários outros arquivos, uma
forma de centralizar e reaproveitar código. A pasta pages contém as páginas que compõem
a aplicação, conforme descrito anteriormente, com exceção para a pasta tabs que é
referente ao design que é usado pelas outras páginas.
Figura 4.15: Estrutura do projeto visualizada pelo Visual Studio

Code
4.7.2 Instalações e Implementação

A função principal do aplicativo é realizar a conexão com o Firebase, conforme
descrito na seção 4.1, os dados armazenados no banco de dados em tempo real devem
ser recuperados e mostrados ao usuário. A próxima atividade é instalar as bibliotecas e
plugins. A primeira é a biblioteca AngularFire2, que possui funções para automatizar a
criação de aplicações em TS que conectam com o Firebase, sendo possível salvar, editar,
excluir e recuperar dados na plataforma [29].
Para esta aplicação foi utilizado as funções relacionadas ao Realtime Database,
como a autenticação na plataforma, recuperação de dados e busca por dados de forma
personalizada, como ocorre na funcionalidade de mostrar histórico, onde os dados são
agrupados por categoria e data. Como os dados devem ser recuperados de forma instantâ-
nea, em tempo real, a biblioteca por padrão usa o objeto Observable do JS.
O Observable que está contido em uma biblioteca nativa do Ionic a RxJS, é
uma coleção de funções que funciona de forma unidirecional, ou seja, abre uma conexão
HTTP com o webservice e emite notificações sempre que ocorre mudança em alguma
das pontas [68]. Assim o Observable permite atualizar os dados do aplicativo sempre que
houver alguma modificação no banco de dados do Firebase.
Outra biblioteca externa utilizada neste projeto é o ChartJS, que fornece funções
para a criação de gráficos. É uma biblioteca JS, com gráficos simples, fácil implementação
e com uma visualização que se adapta ao tamanho de tela para cada dispositivo [67]. Os
tipos dos gráficos são os mais variados, porém para este projeto, foi escolhido o gráfico
de linha para mostrar o BPM e para a temperatura corporal o de barra, os dois possuem
uma boa visualização e compreensão dos dados.
O resumo das bibliotecas instaladas e utilizadas no projeto pode ser conferido na
Tabela 4.9.
Tabela 4.9: Resumo das bibliotecas utilizadas no projeto
Biblioteca Versão Descrição
AngularFire2 5.0.0 Manipulação de dados com o Firebase.
ChartJS 2.7.1 Criação de gráficos personalizados.
Para a utilização de recursos nativos do sistema operacional dos dispositivos

móveis no desenvolvimento deste projeto, foram instalados alguns plugins que são
gerenciados pelo Cordova e descritos na Tabela 4.10.
Tabela 4.10: Todos os plugins nativos utilizados na aplicação
Plugin Versão Descrição
O Firebase Cloud Messaging é utilizado para
FCM 2.1.2 receber notificações através do Firebase e
mostrar ao usuário.
Possibilita o acesso a câmera do dispositivo
Camera 4.0.2 para tirar e salvar fotos, como pode ser
feito na página de perfil do paciente.
Utilizado em formulários para formatar a
data e oferecer uma interação com o usuário
DataPicker 0.8.2
facilitada. É utilzado no formulário de
cadastro do paciente.
Possibilita o acesso ao vibracall do aparelho.
Vibration 3.0.1 Utilizado para alertar o usuário no momento
que recebe notificações.
Para o desenvolvimento do aplicativo é utilizado a linguagem TS e o IDE Visual

Studio Code, seguindo os padrões do framework. Ao realizar os testes o Ionic oferece uma
ferramente chamada lab, de laboratório. Um laboratório que simula dispositivos móveis
com o sistema operacional iOS e Android, possibilitando validar as funcionalidades
desenvolvidas de forma instantânea. A Figura 4.16 mostra como são realizados os testes
com o simulador do Android a direita e do iOS a esquerda.
O aplicativo é construído de forma modular, conforme padrão do AngularJS,
o que facilita alterações e modificações no código fonte do aplicativo. Pensando em
possibilitar a expansão das funcionalidades da aplicação, o desenvolvimento ocorreu de
forma que, adicionar um novo gráfico na página do dashboard e visualizar os dados na
de histórico seja algo simples e rápido. Caso seja adicionado um novo sensor no sistema,
mostrar seus dados no aplicativo é algo rápido de codificar.
Figura 4.16: Laboratório do Ionic com iOS e Android
O código 4.10 mostra como adicionar um gráfico utilizando HTML e as notações

relacionadas ao Ionic. Este código é inserido na página onde se quer montar o gráfico,
neste caso é relacionado ao gráfico de BPM na página dashboard. A função em TS
utilizada para construir um gráfico de linha é mostrada no código 4.11, onde é preciso
informar três parâmetros. O primeiro e o segundo são arrays contendo os valores a serem
plotados no gráfico e o terceiro o titulo a ser mostrado.
Código 4.10 Código em HTML para mostrar gráfico na página

1 <ion-card>
2 <ion-item>
3 <ion-icon ios="ios-pulse" md="md-pulse"></ion-icon>
4 FrequÃa ncia Cardiaca
5 <h2 item-right> <b>{{ bpmAtual }} bpm</b></h2>
6 </ion-item>
7 <ion-card-content>
8 <canvas #graficoBPM></canvas>
9 </ion-card-content>
10 </ion-card>
Código 4.11 Código em TS para criar gráfico de linha na

página
1 criaGraficoLinha(arrayBpm, arrayHoras, titulo) {
2 this.graficoLinha = new Chart(this.graficoBPM
3 .nativeElement, {
4 type: ’line’,
5 data: {
6 labels: arrayTime,
7 datasets: [
8 {
9 label: titulo,
10 backgroundColor: "rgba(75,192,192,0.4)",
11 borderColor: "rgba(75,192,192,1)",
12 borderCapStyle: ’butt’,
13 pointBorderColor: "rgba(75,192,192,1)",
14 pointBackgroundColor: "#fff",
15 pointHoverBackgroundColor: "rgba(75,192,192,1)",
16 pointHoverBorderColor: "rgba(220,220,220,1)",
17 pointRadius: 1,
18 data: arrayBpm,
19 spanGaps: false
20 }
21 ]
22 }
23 });
24 }
Na construção da página de perfil é necessário armazenar dados no dispositivo,

com isso é utilizado o banco de dados SQLITE. Por se tratar de uma estrutura simples,
o seu uso é facilitado e o Ionic oferece uma biblioteca para manipulação dos dados. O
código 4.12 mostra como inicializar o banco de dados, neste caso com o nome mirsi_db
e criar a tabela usuario, que é destinada para salvar os dados do perfil.
Código 4.12 Código em TS para criar um banco de dados no

dispositivo móveç
1 function iniciaBancoDados() {
2 return new Storage({
3 name: ’mirsi_db’,
4 storeName: ’usuario’
5 });
6 }
Para salvar as informações no banco de dados, é preciso informar os dados em

um objeto. Também é necessário gerar uma chave única no momento de salvar. Como o
aplicativo tem apenas um perfil é gerado uma chave fixa, que servirá para recuperar os
dados quando necessário.
Código 4.13 Código em TS para salvar dados do usuário no

banco de dados
1 salva(usuario: Usuario) {
2 return this.storage.set(KEYUSUARIO, usuario);
3 }
A última atividade do desenvolvimento é a instalação no dispositivo móvel real.

Por questões de acesso a equipamentos, o aplicativo foi instalado apenas para smartpho-
nes que executam o sistema operacional Android. A versão mínima para executar o aplica-
tivo deve ser o Android 5.0 (Lollipop). Apenas dispositivos com essa versão ou superior
conseguem instalar e executar o aplicativo. Em 2017, a versão 5.0 é a que mais possui
usuários conforme a documentação oficial do Google para Android [38].
Para poder criar uma versão do aplicativo e executar em um aparelho com
Android é necessário a utilização do Ionic CLI, seguindo alguns passo que são mostrados
logo a seguir.
1. Adicionar plataforma: é necessário adicionar qual sistema se deseja trabalhar,

Android ou iOS, neste caso o primeiro. Para isto deve ser executado ionic cordova
platform add android.
2. Criar executável: para Android é criado uma APK (Android Package), com o
comando ionic cordova build android.
3. Executar no aparelho: e por fim para executar a aplicação no smartphone o comando
é o ionic cordova run android.
Com esses procedimentos a aplicação é executada diretamente no smartphone,

se houver algum erro de codificação é informado, mostrando o que deve ser corrigido,
caso contrário a instalação é concluída e a aplicação executada no dispositivo.
CAPÍTULO 5
Resultados
O objetivo deste capitulo é apresentar os resultados obtidos com o sistema

finalizado e através dos estudos de casos em ambiente real analisar se os objetivos
propostos para este trabalho foram alcançados.
5.1 Aplicativo Móvel

O aplicativo possui quatro páginas conforme mencionado na seção 4.7. A pri-
meira é a tela inicial, com o nome de dashboard, a segunda histórico, a terceira perfil e a
quarta cadastro.
A página cadastro é apresentado apenas na primeira vez em que é usado o
aplicativo, com objetivo de coletar dados do paciente que podem ser usados futuramente.
A página também é destinada a montar o perfil do paciente e assim personalizar o
aplicativo. A pagina é simples, mostra apenas o fomulário para preenchimento e depois
um botão para salvar os dados informados. A Figura 5.1 mostra como ficou a página
cadastro depois de finalizada.
A página dashboard como mostrado na Figura 5.2, apresenta os dados relacio-
nados ao monitoramento em tempo real da saúde do idoso. O primeiro componente da
tela, mostra a foto do paciente com a situação da saúde atual logo ao lado. Abaixo pode
ser conferido a data em que foi realizado o monitoramento. Na sequencia é apresentado
o gráfico no formato de linha da frequência cardíaca, com as últimas cinco medições re-
alizadas, sendo que no eixo X contém o horário e no Y os valores dos dados. Ao lado é
exibido o valor do BPM atual ou da última medição. O próximo gráfico logo abaixo, é
relacionado a temperatura corporal, que segue a mesma lógica do anterior, montado com
as últimas cinco medições e o valor em graus celsius referente a última medição ao lado.
Na próxima página, a de histórico é apresentado detalhes do monitoramento,
divido por dados, agrupado por datas e apresentado por horários. As variáveis mostradas
são BPM, temperatura corporal e situações, onde a primeira mostra o valor da frequência
cardíaca, a segunda temperatura corporal e a terceira as situações da saúde que são
5.1 Aplicativo Móvel 69
indicadas conforme análise dos dados, todas apresentadas com os respectivos horários
da medição. A figura 5.3 mostra com detalhes a página de histórico.
A última página do aplicativo, é o perfil de usuário, que apresenta os dados
do paciente que foram cadastrados anteriormente e tem a possibilita de personalizar o
aplicativo, através de uma imagem. É possível realizar a captura da imagem com a câmera
do smartphone e salvar no aplicativo. É a mesma foto que pode ser visualizada na página
dashboard. A figura 5.4 mostra a tela de perfil com os dados cadastrado e foto adicionada.
Figura 5.1: Página com formulário para preenchimento das infor-

mações do paciente
Figura 5.2: Página inicial do aplicativo mostrando os dados do

monitoramento
5.2 Estudos de Casos 70
Figura 5.3: Página de histórico mostrando as três opções de visu-

alização dos dados
Figura 5.4: Página de perfil do usuário com a visualização dos

dados salvos
5.2 Estudos de Casos

Para coletar dados e apresentar os resultados, foi realizado dois estudos de casos
em ambiente real, com o objetivo de apresentar a viabilidade do sistema desenvolvido.
O primeiro estudo de caso (EC1), foi realizado em 2 dias, por uma pessoa do
sexo masculino, com 22 anos de idade, 1,83 metros de altura e peso de 87 quilogramas,
com objetivo de validar o funcionamento do sistema, corrigir erros e realizar possíveis
ajustes. O segundo estudo de caso (EC2), realizado por cerca de 1 hora, com uma pessoa
do sexo masculino, 77 anos de idade, 1,60 metros de altura e peso de 68 quilogramas, com
o objetivo de realizar validação do sistema em ambiente real sendo utilizado por pessoa
idosa. Validando assim a viabilidade do sistema proposto. As informações de altura, peso

e idade são relevantes, pois a frequência cardíaca se diferencia por idade e o acelerômetro
pode ser afetado pelo peso corporal no momento de detectar quedas.
Figura 5.5: Pessoa Utilizando o protótipo em ambiente real para

estudo de caso
5.3 Análise dos Estudos de Casos

Nesta seção serão apresentados os resultados dos estudos de casos realizados. As
apresentações juntamente com as análises serão feitas na forma de gráficos, que foram
criados utilizando a linguagem de programação Python juntamente com a biblioteca
destinada para plotar gráficos, PyPlot [54]. Os dados coletados para estas análises estavam
armazenados na plataforma Firebase, que foram exportados no formato CSV (Comma-
Separated Values). Todos os gráficos estão na forma de linha, facilitando a compreensão
e visualização.
5.3.1 Análise do EC1

O EC1 teve duração aproximada de três horas no dia 1 e trinta minutos no dia
2, onde o dispositivo de monitoramento foi utilizado por este período contendo alguns
minutos de intervalos para ajustes. Ao todo foram salvos 513 linhas de dados no dia 1 e
246 no dia 2, totalizando 759 linhas de dados relacionados a saúde do paciente.
A Figura 5.6 mostra o gráfico com os dados do BPM. Através dele é possível
verificar que em alguns instantes o sensor de frequência cardíaca apresenta algumas
inconsistência em suas medições, contendo dados muito acima do 150 BPM e outros
abaixo do 40 BPM, o que não mostra a realidade para o momento dos testes. Porém é
observado que essa margem de erro está relacionada ao sensor estar mal posicionado ou
não totalmente encostado ao corpo da pessoa em monitoramento, o que prejudica seu
funcionamento correto. Toda vez que o sensor é retirado e logo após colocado novamente
em contato com o corpo é necessário um tempo, com cerca de 10 segundos, para que seja
estabilizado e assim volte a fazer leituras corretamente.
Apesar de alguns dados que estão acima ou abaixo da média, é fácil notar que
a maior parte do tempo o sensor faz a leitura entre 50 e 100 BPM, o que corresponde a
dados aceitáveis para as condições no momento do teste. Uma característica importante é
que o sistema respondeu rapidamente as alterações dos dados do sensor, gerando alertas
para os casos.
Figura 5.6: Gráfico do BPM no dia 1 do estudo de caso 1
No mesmo dia, ainda é possível realizar a análise dos dados da temperatura cor-
poral. O gráfico da Figura 5.7 mostra os dados coletados durante o período de monitora-
mento. Nota-se que o valor da temperatura permanece constante em cerca de 36 o C em
todo o tempo. Valores menores ocorreram quando o sensor não estava totalmente em con-
tato com o corpo, como observado é um fato que está ligado diretamente a eficiência dos
sensores. É possível concluir que mesmo o sensor tratando-se especificamente para de-
tectar a temperatura ambiental, quando em contato com o corpo corretamente, consegue
realizar de forma satisfatória a leitura da temperatura corporal de uma pessoa.
Figura 5.7: Gráfico da temperatura corporal no dia 1 do estudo de

caso 1
No dia 2 do EC1, após realizar uma correção na fixação dos sensores no corpo,
é possível notar um ganho na leitura dos dados da frequência cardíaca. Neste dia os
batimentos ficaram entre 40 e 100 BPM. Um grande ganho é observado, conforme
mostrando na Figura 5.8. Os dados ficaram dentro do limite real dos batimentos de uma
pessoa, notando pouca interferência e inconsistências no momento da leitura por parte do
sensor.
Figura 5.8: Gráfico do BPM no dia 2 do estudo de caso 1
O próximo gráfico, mostrado na Figura 5.9, realizado também com os dados do

dia 2, auxiliou na construção do algoritmo que detecta quedas, desenvolvido conforme
descrito na seção 4.4. O gráfico de linha mostra os dados do acelerômetro nos eixos X
(aclX), Y (aclY) e Z (aclZ). Para coleta destes dados, foram simuladas diversas situações
de queda, buscando encontrar padrões de aceleração nos eixos do acelerômetro. Como
resultado é notado que quando em movimento, o eixo Y apresenta valores altos, enquanto
X e Z valores baixos, chegando a casa do 0. Quando há uma situação de queda conforme
simulação, percebe o inverso, onde os valores do eixo X e Y normalmente sobem juntos
chegando ao valor de 30 ou mais, enquanto o valor de Y diminui. Em algumas situações,
dependendo da posição que houve a queda, apenas o X ou Z aumentam de valores e o
outro permanece constante, porém em todos os casos um ou outro detecta uma aceleração
maior, caracterizando uma queda.
Figura 5.9: Gráfico do acelerômetro com os dados do dia 2 no

estudo de caso 1
Ainda foi plotado o gráfico com todos os dados do dia 1 e 2, onde no dia 1 é
simulado as quedas buscando testar a biblioteca que não obteve sucesso na detecção das
quedas, que também foi descrita na seção 4.4 e no dia 2 com intuito de encontrar padrões
na aceleração dos eixos do acelerômetro que caracterizassem uma queda. É possível
notar no gráfico da Figura 5.10 que o comportamento ocorre conforme mencionado
anteriormente com a análise dos dados apenas no dia 2, confirmando que há um padrão
de comportamento do acelerômetro para esta situação.
Figura 5.10: Gráfico do acelerômetro com os dados do dia 1 e 2

no estudo de caso 1
O último gráfico desta análise, é a união de todos os dados do EC1 relacionados

ao BPM e temperatura corporal, como mostrado na Figura 5.11. O objetivo da análise
foi identificar alguma relação possível entre os dois dados, porém nesta situação, apenas
com as informações deste estudo de caso, não é possível indicar alguma relação entre as
variável.
Figura 5.11: Gráfico do BPM com temperatura corporal do estudo

caso 1
5.3.2 Análise do EC2

O EC2 teve 154 linhas de dados coletados, em um período de quase uma hora
de realização. O teste é executado em um idoso, com o objetivo de validar se o protótipo
exerce suas funções corretamente em ambiente real. O mesmo se mostrou confortável ao
ser vestido, sem afetar ou incomodar o idoso ao andar ou se sentar. Apesar de funcionar
corretamente para coletar os dados da temperatura e frequência cardíaca, em alguns
momentos com movimentos bruscos, os dados apresentam inconsistências, pelo fato do
sensor perder o contato direto com o corpo por um período de tempo, as vezes sendo
necessário o idoso corrigir a posição dos sensores. Por questões de segurança ao idoso,
não foram simuladas quedas neste estudo de caso.
O gráfico da Figura 5.12 mostra as oscilações que ocorreram nos dados da
frequência cardíaca. Em maior parte ficou acima de 40 e abaixo de 120 BPM, porém em
alguns momentos foi detectado batimentos abaixo dos 40, o que pode ser considerado um
outlier, que é um dado atípico, que não condiz com a realidade considerando o momento
do teste. Foi possível observar que essas variações ocorreram no momento em que o idoso
se movimenta, o que pode prejudicar o contato direto do sensor com a pele por alguns
segundos, prejudicando o comportamento do sensor.
Figura 5.12: Gráfico do BPM do estudo de caso 2
No caso da temperatura corporal, também houve algumas oscilações e dados que

podem ser considerados outliers, porém na maior parte do tempo a temperatura ficou entre
34 e 36 ◦ C o que pode ser considerado normal para este estudo de caso. A Figura 5.13
mostra com detalhes como ficou o gráfico da temperatura corporal com os dados coletados
no EC2.
Com relação as situações de saúde, foi possível observar que foram informadas
corretamente. Em momentos que a frequência cardíaca ficou abaixo dos 40 BPM, houve
o aviso de "BPM Muito Baixo", em relação a temperatura abaixo de 34 o C, foi indicado
como "Temperatura Muito Baixa", e quando não houve nenhum destes casos indicado
como "Situação Regular". A Figura 5.14 mostra como ficou a tela de modo parcial das
situações na página de histórico do aplicativo móvel no momento da realização do EC2.
Figura 5.13: Gráfico da temperatura corporal do estudo de caso 2
Figura 5.14: Página de histórico mostrando as situações do estudo

de caso 2
5.4 Notificações
O objetivo desta seção é mostrar os resultados obtidos com as notificações que
chegam para o usuário do aplicativo móvel em situações adversas da saúde do idoso.
Para cada situação como frequência cardíaca alta ou baixa conforme intervalo, acima ou
abaixo da mediana e ainda a sua ausência, temperatura corporal alta ou baixa e quedas
detectadas é gerado uma notificação para o usuário, com o objetivo de alertar o familiar
ou cuidador, para que possa tomar alguma providencia relacionado a situação. Em toda
notificação que é chegada no smartphone pelo aplicativo móvel, há um alerta do vibracall,
chamando a atenção e reforçando a chegada da notificação. Para se chegar ao resultado de
cada notificação, com o objetivo de validar os resultados, foram simulados alguns dados
como teste.
A Figura 5.15 mostra a notificação relacionada à frequência cardíaca, são três
notificações diferentes. A primeira quando o BPM esta muito baixo, outra para muito alto
e a última quando não é detectado BPM no paciente.
Figura 5.15: Notificações relacionadas ao batimento por minuto
A próxima notificação é gerada ao analisar os dados da temperatura corporal,

podendo ser alta ou baixa, conforme a Figura 5.16 que demonstra a notificação para estes
casos.
Figura 5.16: Notificações relacionadas a temperatura corporal

A notificação mostrada na Figura 5.17 é gerada quando se detecta uma queda,

ou seja, assim que algum dado caracterizar a queda é encaminhada para o usuário a
notificação apresentada.
Figura 5.17: Notificação relacionada a detecção de queda
A última notificação implementada é relacionada a mediana do BPM, podendo

ser acima ou abaixo, dependendo da situação. Mesmo que o cálculo seja realizado
pela mediana dos valores, é apresentado para o usuário como média, para facilitar a
interpretação da informação. A Figura 5.18 mostra como é apresentado essas notificações
para o usuário.
Figura 5.18: Notificações relacionadas a média do batimento por

minuto
CAPÍTULO 6
Conclusão e Trabalhos Futuros
O projeto desenvolvido neste trabalho de graduação teve como objetivo principal

desenvolver um sistema de monitoramento a saúde do idoso que possa ser realizado de
forma remota por familiares ou cuidadores, acompanhando os dados por um smartphone,
oferendo monitoramento da frequência cardíaca, temperatura corporal e capaz de detectar
quedas. Oferecendo ainda uma análise dos dados coletados e assim gerar notificações
de alertas em caso de alguma alteração que ofereça risco a saúde do idoso. Desta forma
poder contribuir com a qualidade de vida dos idosos, aumentando a sua independência e
aos familiares acompanhamento da saúde de forma remota.
O sistema possui custo consideravelmente acessível na montagem do dispositivo
embarcado, com característica de um sistema em tempo real. Destacando as tecnologias
utilizadas como o banco de dados em tempo real, que possibilita realizar o monitoramento
com pouco atraso, em média de três segundos a cada coleta de dados. A não necessidade
de um servidor local para a análise e armazenamento dos dados. E a rápida resposta à
alterações das situações de saúde que são quase de modo instantâneo.
O equipamento apresentou precisão satisfatória nos seus objetivos de monitorar
frequência cardíaca e temperatura corporal, apresentando algumas inconsistências na co-
leta dos dados em alguns momentos, porém com efetividade na maior parte do período
testado. Em relação ao algoritmo para detectar quedas, apresentou algumas falhas, ge-
rando falsos positivos e falsos negativos, porém com acertos consideráveis. A análise dos
dados pela Web API foram satisfatória, gerando notificações corretamente para todos os
casos. O aplicativo móvel apresentou desempenho satisfatório, mesmo recebendo uma
quantidade grande de dados por minuto, possibilita o acompanhamento personalizado e o
recebimento de notificações quando necessário. O sistema ainda é facilmente expansível,
desenvolvido de forma modular, fácil de agregar novos sensores e novas funcionalida-
des que contribuam para o monitoramento ao idoso. Todas as tenologias utilizadas são
gratuitas e a maioria com código aberto.
O código completo desenvolvido neste trabalho, incluindo o sistema embarcado,
Web API e aplicativo móvel, pode ser encontrado no GitHub [25], plataforma de reposi-
tórios para códigos fontes gratuita.
80
Como trabalhos futuros, deseja-se agregar novos sensores ao sistema, como

o sensor de pressão arterial e oxigenação do sangue, ainda podendo agregar novos
módulos, como 3G/GPRS para possibilitar o monitoramento fora de ambiente domestico,
sem rede Wi-Fi e GPS para identificar a localização do idoso. É possível melhorar as
análises dos dados coletados, aplicando técnicas que possam prever situações de riscos
e gerar avisos de forma preditiva com a utilização de Inteligência Artificial. Conseguir
detectar movimentos bruscos do idoso, reduzindo assim os ruídos na leitura dos sensores
relacionado ao contato com o corpo. Ainda deseja-se implementar maior segurança na
transmissão dos dados entre dispositivo embarcado e servidor em nuvem, usando o
protocolo HTTPS. O estudo dos sensores, módulos e técnicas devem ser considerados,
agregando ainda o consumo de energia do sistema, que deve aumentar quando adicionado
novas funcionalidades.
Referências Bibliográficas
[1] A DEGBITE , E. Pyfcm: Python client for fcm - firebase cloud messaging (android,
ios and web). https://github.com/olucurious/PyFCM, 2018. [Acesso em 19
de janeiro de 2018].
[2] A KYILDIZ , I. F.; WANG , X. A survey on wireless mesh networks. IEEE Communi-
cations magazine, 43(9):S23–S30, 2005.
[3] A MBROS , L. Diferença entre aplicativos nativos, híbridos

e mobile web apps. http://www.luisaambros.com/blog/
diferenca-entre-aplicativos-nativos-hibridos-e-mobile-web-apps,
2014. [Acesso em 14 de dezembro de 2017].
[4] A MINI , A.; B ANITSAS , K.; C OSMAS , J. A comparison between heuristic and
machine learning techniques in fall detection using kinect v2. In: Medical
Measurements and Applications (MeMeA), 2016 IEEE International Symposium on,
p. 1–6. IEEE, 2016.
[5] A MPED, P. S. Pulse Sensor Amped - Project. https://pulsesensor.com/

products/pulse-sensor-amped, 2017. [Acesso em 09 de novembro de 2017].
[6] A MPED, P. S. The Best Way to Get Started with your PulseSen-
sor and Arduino. https://github.com/WorldFamousElectronics/
PulseSensorStarterProject, 2017. [Acesso em 09 de novembro de 2017].
[7] A RDUINO. Wire library. https://www.arduino.cc/en/Reference/Wire, 2014.

[Acesso em 24 de janeiro de 2018].
[8] A RDUINO. MPU-6050 Accelerometer + Gyro. https://playground.arduino.

cc/Main/MPU-6050, 2016. [Acesso em 11 de novembro de 2017].
[9] B ANULEASA , S.; M UNTEANU, R.; RUSU, A.; TON Ţ , G. Iot system for monitoring
vital signs of elderly population. In: Electrical and Power Engineering (EPE), 2016
International Conference and Exposition on, p. 059–064. IEEE, 2016.
[10] B ATISTA DE G ÓIS , A. L.; P EIXOTO V ERAS , R. Informações sobre a morbidade

hospitalar em idosos nas internações do sistema único de saúde do brasil.
Ciência & Saúde Coletiva, 15(6), 2010.
[11] B ENCH , H. Powering the esp-12e nodemcu de-

velopment board. http://henrysbench.capnfatz.
com/henrys-bench/arduino-projects-tips-and-more/
powering-the-esp-12e-nodemcu-development-board/, 2016.
[12] B ERNARDO, A. M. Proposta de sistema embarcado para auxílio e monitora-

mento do idoso.
[13] B ERSCH , R. Introdução à tecnologia assistiva. Porto Alegre: CEDI, 2008.
[14] B ORGES , R. W. Aplicabilidade de sistemas operacionais de tempo real (RTOS)

para sistemas embarcados de baixo custo e pequeno porte. PhD thesis,
Universidade de São Paulo, 2011.
[15] B OURKE , A. K.; K LENK , J.; S CHWICKERT, L.; A MINIAN , K.; I HLEN , E. A.; M ELLONE ,
S.; H ELBOSTAD, J. L.; C HIARI , L.; B ECKER , C. Fall detection algorithms for real-
world falls harvested from lumbar sensors in the elderly population: a machine
learning approach. In: Engineering in Medicine and Biology Society (EMBC), 2016
IEEE 38th Annual International Conference of the, p. 3712–3715. IEEE, 2016.
[16] BRASIL, P. D. R. Dados sobre ebvelhecimento no brasil. http:

//www.sdh.gov.br/assuntos/pessoa-idosa/dados-estatisticos/
DadossobreoenvelhecimentonoBrasil.pdf, 2012.
[17] C HILDS -M AIDMENT, J. Pyrebase: A simple python wrapper for the firebase api.
https://github.com/thisbejim/Pyrebase, 2017. [Acesso em 19 de janeiro de
2018].
[18] C HIUCHISAN , I.; C HIUCHISAN , I.; D IMIAN , M. Internet of things for e-health: An
approach to medical applications. In: Computational Intelligence for Multimedia
Understanding (IWCIM), 2015 International Workshop on, p. 1–5. IEEE, 2015.
[19] C OLON , L. N. V.; D E L A H OZ , Y.; L ABRADOR , M. Human fall detection with

smartphonese. In: Communications (LATINCOM), 2014 IEEE Latin-America Confe-
rence on, p. 1–7. IEEE, 2014.
[20] C OMPANY, S. Heroku Dev Center. https://devcenter.heroku.com/, 2017.

[Acesso em 14 de novembro de 2017].
[21] C ONSERVANCY, S. F. Git: Documentation. https://git-scm.com/book/pt-br/

v1/Primeiros-passos-Sobre-Controle-de-Vers%C3%A3o, 2018. [Acesso em
22 de janeiro de 2018].
[22] DAVIS , M.; A LLEMANG , D.; C OYNE , R. Wonderweb deliverable d25: Evaluation
and market report. IST Project, 33052, 2001.
[23] DE C AMARGO, M. G.; F URLAN , M. M. D. P. Resposta fisiológica do corpo às tem-

peraturas elevadas: exercício, extremos de temperatura e doenças térmicas.
Saúde e Pesquisa, 4(2), 2011.
[24] D E D IANA , M.; G EROSA , M. A. Nosql na web 2.0: Um estudo comparativo

de bancos não-relacionais para armazenamento de dados na web 2.0. In: IX
Workshop de Teses e Dissertações em Banco de Dados, volume 9, 2010.
[25] DE M OURA , C. J. M. Mirsi - repositório no github. https://github.com/

cicerojmm/mirsi/, 2018.
[26] D EVELOPERS , A. Android: Java and kptlin. https://developer.android.com/

index.html, 2017. [Acesso em 14 de dezembro de 2017].
[27] D EVELOPERS , A. Swift 4: The powerful programming language that is also

easy to learn. https://developer.apple.com/swift/, 2017. [Acesso em 14
de dezembro de 2017].
[28] DOS R EIS , V. R. I2c: Protocolo de comunicação. http://www.arduinobr.com/

arduino/i2c-protocolo-de-comunicacao/, 2014.
[29] E AST, D. Angularfire: The official library for firebase and angular. https:
//github.com/angular/angularfire2, 2017. [Acesso em 27 de janeiro de 2018].
[30] FABRÍCIO, S. C. C.; R ODRIGUES , R. A. P.; DA C OSTA J UNIOR , M. L. Causas e

conseqüências de quedas de idosos atendidos em hospital público. Revista de
saúde Pública, 38(1):93–99, 2004.
[31] F ECHINE , B. R. A.; T ROMPIERI , N. O processo de envelhecimento: as principais

alterações que acontecem com o idoso com o passar dos anos. InterScience-
Place, 1(20), 2015.
[32] F OUNDATION , P. S. Python: Documentation. https://www.python.org/doc/,

[33] F OUNDATION , P. S. Pip: Quickstart. https://pip.pypa.io/en/stable/

quickstart/, 2018. [Acesso em 19 de janeiro de 2018].
[34] F OUNDATION , T. A. S. Cordova documentation. http://cordova.apache.org/

docs/en/latest/, 2017. [Acesso em 30 de dezembro de 2017].
[35] F RAMEWORK , I. Ionic framework: Docs. https://ionicframework.com/docs/

intro/installation/, 2017. [Acesso em 30 de dezembro de 2017].
[36] G ASPAROTTO, L. P. R.; FALSARELLA , G. R.; C OIMBRA , A. M. V. As quedas no

cenário da velhice: conceitos básicos e atualidades da pesquisa em saúde.
Revista Brasileira de Geriatria e Gerontologia, 17(1):201–209, 2014.
[37] G OOGLE . Angular get started. https://angular.io/, 2017. [Acesso em 30 de

dezembro de 2017].
[38] G OOGLE . Android: Painéis.

https://developer.android.com/about/
dashboards/index.html?hl=pt-br, 2018.
[39] G RISS , M. L. Software reuse architecture, process, and organization for busi-
ness success. In: Computer systems and software engineering, 1997., proceedings
of the eighth israeli conference on, p. 86–89. IEEE, 1997.
[40] G ROKHOTKOV, I. Ticker.

http://arduino-esp8266.readthedocs.io/en/
latest/libraries.html?highlight=ticker, 2014. [Acesso em 24 de janeiro
de 2018].
[41] G ROKHOTKOV, I. Client secure.

http://arduino-esp8266.readthedocs.
io/en/latest/esp8266wifi/client-secure-examples.html?highlight=
WiFiClientSecure, 2017. [Acesso em 24 de janeiro de 2018].
[42] G ROKHOTKOV, I. Esp8266 arduino core documentation. Release 2.4.0, 2017.
[43] G ROKHOTKOV, I. Esp8266: Installing. http://arduino-esp8266.readthedocs.

io/en/latest/installing.html, 2017. [Acesso em 23 de janeiro de 2018].
[44] G ROKHOTKOV, I. Esp8266wifi library. http://arduino-esp8266.readthedocs.

io/en/latest/esp8266wifi/readme.html?highlight=ESP8266WiFi, 2017.
[Acesso em 24 de janeiro de 2018].
[45] GSTI, P. O que é sqlite? https://www.portalgsti.com.br/sqlite/sobre/,

201.
[46] G UBBI , J.; B UYYA , R.; M ARUSIC, S.; PALANISWAMI , M. Internet of things (iot): A
vision, architectural elements, and future directions. Future generation computer
systems, 29(7):1645–1660, 2013.
[47] G UIDE , A. Getting started with the lilypad arduino, lilypad arduino sim-
ple and lilypad arduino simple snap. https://www.arduino.cc/en/Guide/
ArduinoLilyPad, 2017.
[48] IBGE. Tábua Completa de Mortalidade para o Brasil de 2012. www.ibge.gov.

br/home/estatistica/populacao/tabuadevida/2012/, 2012. [Acesso em 24
de maio de 2017].
[49] IN R EADMOND, M. Typescript. https://www.typescriptlang.org/, 2017.
[50] I NC, G. Firebase by Platform. https://firebase.google.com/docs, 2017.

[51] I NC, G. Firebase. https://console.firebase.google.com, 2018. [Acesso em

17 de janeiro de 2018].
[52] J ARZ Ä TM BSKI , K. Arduino-mpu6050. https://github.com/jarzebski/

Arduino-MPU6050, 2017. [Acesso em 24 de janeiro de 2018].
[53] J ET B RAIN . PyCharm IDE. https://www.jetbrains.com/pycharm/, 2017.

[54] J OHN H UNTER , DARREN DALE , E. F. M. D. Matplotlib: pyplot. https://

matplotlib.org/api/pyplot_api.html, 2012.
[55] JSON. Introdução ao json. https://www.json.org/, 2018. [Acesso em 21 de

janeiro de 2018].
[56] L EITE , E. R.; L IMA , R. A. Sistema não invasivo de monitorização da pressão

arterial. Anais da Mostra de Extensão, Inovação e Pesquisa, 4, 2017.
[57] L I , Q.; YAO, C. Real-time concepts for embedded systems. CRC Press, 2003.
[58] L OYOLA F ILHO, A. I. D.; L EITE M ATOS , D.; G IATTI , L.; A FRADIQUE , M. E.; V IANA P EI -
XOTO, S.; L IMA -C OSTA , M. F. Causas de internações hospitalares entre idosos
brasileiros no âmbito do sistema único de saúde. Epidemiologia e serviços de
saúde, 13(4):229–238, 2004.
[59] M ADUREIRA , D. Aplicativo nativo, web app ou aplicativo híbrido?

http://usemobile.com.br/aplicativo-nativo-web-hibrido/#hibrido,
[60] M ALHEIROS , L. Sistema de detecção de quedas e de posicionamento corporal

com monitoramento de batimentos cardíacos. 2016.
[61] M ANN , S. Definition of wearable computer. International Conference on Wearable

Computing ICWC-98, Fairfax VA, May 1998, 1998.
[62] M ELL , P.; G RANCE , T.; OTHERS . The nist definition of cloud computing. 2011.
[63] M ENEZES , N. N. C. Introdução à programação com Python–2a edição: Algorit-

mos e lógica de programação para iniciantes. Novatec Editora, 2016.
[64] M ICROCHIP. Esp8266 serial esp01 wifi wireless. http://www.microchip.ua/

wireless/esp01, 2017.
[65] M ICROSOFT. Visual studio code: Getting started. https://code.

visualstudio.com/docs, 2017. [Acesso em 30 de dezembro de 2017.
[66] M ITCHELL , T. Machine Learning, Ed. Science/Engineering/Math, Portland, OR.

USA: McGraw Hill, 1997.
[67] M ORONY, J. Adding responsive charts graphs to io-

nic 2 3 applications.
https://www.joshmorony.com/
adding-responsive-charts-graphs-to-ionic-2-applications/, 2018.
[68] N ASCIMENTO, W. Entendendo rxjs observa-

ble com angular. https://medium.com/tableless/
entendendo-rxjs-observable-com-angular-6f607a9a6a00, 2017.
[69] N O SQL. ORG . Your Ultimate Guide to the Non-Relational Universe! http:
//nosql-database.org/, 2017. [Acesso em 14 de dezembro de 2017].
[70] O LIVEIRA , S. Internet das coisas com esp8266, arduino e raspberry pi. São
Paulo: Novatec, 2017.
[71] OWENS , M.; A LLEN , G. SQLite. Springer, 2010.
[72] P ERRACINI , M. R.; OTHERS . Prevenção e manejo de quedas no idoso. Ramos

LR, Toniolo Neto J. Geriatria e Gerontologia. Guias de Medicina Ambula torial e
Hospitalar/Unifesp-Escola Paulista de Medicina. São Paulo: Editora Manole, 2005.
[73] P INTO, S.; C ABRAL , J.; G OMES , T. We-care: An iot-based health care system for
elderly people. In: Industrial Technology (ICIT), 2017 IEEE International Conference
on, p. 1378–1383. IEEE, 2017.
[74] Q UATRANI , T.; E VANGELIST, U. Introduction to the unified modeling language. A

technical discussion of UML, 6(11):03, 2003.
[75] R ONACHER , A. Flask: Routing. flask.pocoo.org/docs/0.12/quickstart/

#routing, 2017. [Acesso em 21 de janeiro de 2018].
[76] R ONACHER , A. Welcome to flask. http://flask.pocoo.org/docs/0.12/, 2017.

[Acesso em 30 de dezembro de 2017].
[77] S ANTOS , R. Getting started with esp8266 wifi trans-

ceiver (review). https://randomnerdtutorials.com/
getting-started-with-esp8266-wifi-transceiver-review/, 2015.
[78] S ILVA , D. O que Ã

c computaÃ§Ã£o em nuvem? https://www.
estudopratico.com.br/o-que-e-computacao-em-nuvem/, 2010.
[79] S ILVA , V. A. P. D.; B OTTARO, M.; J USTINO, M. A.; R IBEIRO, M. M.; L IMA , R. M.;
DE O LIVEIRA , R. J. Freqüência cardíaca máxima em idosas brasileiras: uma
comparação entre valores medidos e previstos. Arq Bras Cardiol, 88(3):314–20,
2007.
[80] S OUSA , F. R.; M OREIRA , L. O.; M ACHADO, J. C. Computação em nuvem:

Conceitos, tecnologias, aplicações e desafios. II Escola Regional de Computação
Ceará, Maranhão e Piauí (ERCEMAPI), p. 150–175, 2009.
[81] S OUZA , F. Arduino - comunicação serial. https://www.embarcados.com.br/

arduino-comunicacao-serial/, 2014.
[82] S UGATHAN , A.; R OY, G. G.; K IRTHYVIJAY, G.; T HOMSON , J. Application of arduino
based platform for wearable health monitoring system. In: Condition Assessment
Techniques in Electrical Systems (CATCON), 2013 IEEE 1st International Conference
on, p. 1–5. IEEE, 2013.
[83] S YSTEMS , E. Datasheet: Espressif smart connectivity platform: Esp8266. Copy-

right 2013 Espressif Systems Inc. All rights reserved, 2013.
[84] V IEGA , S. Lista de batimentos cardíacos normais

por idade. https://saude.umcomo.com.br/artigo/
lista-de-batimentos-cardiacos-normais-por-idade-28323.html, 2017.
[85] V IEIRA , M. R.; FIGUEIREDO, J. M. D.; L IBERATTI , G.; V IEBRANTZ , A. F. M.

Bancos de dados nosql: conceitos, ferramentas, linguagens e estudos de
casos no contexto de big data. Simpósio Brasileiro de Bancos de Dados, 2012.
[86] V IEIRA , N. Ententendo um pouco mais so-

bre protocolo http. https://nandovieira.com.br/
entendendo-um-pouco-mais-sobre-o-protocolo-http, 2007.
[87] V IN Ã CIUS , M. Temperatura corporal. http://www.enfermagemesquematizada.

com.br/temperatura-corporal/, 2017.
[88] Z ABADAL , B. M.; DE C ASTRO, B. F. L. M. Iot e seus principais desafios. Revista

Interdisciplinar de Tecnologias e Educação, 3(1), 2017.

Protótipo de Monitoramento Remoto Da Saúde Do Idoso

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Protótipo de Monitoramento Remoto Da Saúde Do Idoso

Hochgeladen von

Copyright:

Verfügbare Formate

I NTITUTO F EDERAL DE G OIÁS

D EPARTAMENTO DE Á REAS ACADÊMICAS IV

C ÍCERO J OASYO M ATEUS DE M OURA

Protótipo de Monitoramento Remoto da

AUTORIZAÇÃO PARA P UBLICAÇÃO DE T RABALHO DE

Na qualidade de titular dos direitos de autor, AUTORIZO o Departamento de

Título: Protótipo de Monitoramento Remoto da Saúde do Idoso

Autor(a): Cícero Joasyo Mateus de Moura

Goiânia, 09 de Março de 2018.

Cícero Joasyo Mateus de Moura – Autor

Me. Otávio Calaça Xavier – Orientador

Protótipo de Monitoramento Remoto da

Trabalho de Conclusão apresentado à Coordenação do

Protótipo de Monitoramento Remoto da

Trabalho de Conclusão apresentado à Coordenação do Curso de Siste-

Prof. Me. Otávio Calaça Xavier

Prof. Me. Sanderson Oliveira de Macedo

Prof. Me. Ariel Cardoso Mendes

de Moura, Cícero Joasyo Mateus. Protótipo de Monitoramento Remoto da

de Moura, Cícero Joasyo Mateus. Intelligent and Remote Health Monitoring

API Application Programming Interface

Lista de Códigos de Programas 15

6 Conclusão e Trabalhos Futuros 79

2.1 Figura ilustrativa mostrando o funcionamento do protocolo I 2C [28] 23

3.1 Figura ilustrativa da arquitetura do sistema de monitoramento proposto 33

4.1 Diagrama de Atividade do Sistema de Monitoramento 43

5.1 Página com formulário para preenchimento das informações do paciente 69

3.1 Lista de materiais utilizados para a construção do sistema de monitoramento 34

4.1 Tabela com a descrição das atividades 44

4.1 Inclusão das bibliotecas utilizadas no algoritmo do sistema embarcado 49

1.3.1 Objetivo Geral

1.3.2 Objetivos Específicos

• Desenvolver uma solução em dispositivo embarcado para monitoramento da saúde

• Realizar a análise dos dados coletados pelos sensores, em busca de respostas a

1.4 Estrutura do Trabalho

2.1 Frequência Cardíaca

2.2 Temperatura Corporal

2.3 Tecnologia Assistiva

2.4 Computação Vestível

2.5 Internet das Coisas

2.5.1 Arquitetura básica da Internet das Coisas

a comando e produzindo alguma ação, como envio de mensagens, movimento e

2.6 Protocolos de Comunicação

2.6.1 Protocolo I2C

Figura 2.1: Figura ilustrativa mostrando o funcionamento do pro-

A distância normal de trabalho no barramento com a comunicação utilizando o

2.6.2 Protocolo Serial

2.6.3 Protocolo HTTP

2.7 Sistemas Embarcados

2.7.2 Microcontrolador ESP8266

Figura 2.2: Alguns módulos que possuem o ESP8266 [77]

2.8 Computação em Nuvem

• Serviços sob demanda: o usuário pode adquirir recursos computacionais conforme

Figura 2.3: Figura ilustrativa do modelo de computação em nuvem

A computação em nuvem ainda é composta por três modelos de arquitetura, que

1. Software como um Serviço (SaaS): este modelo proporciona sistemas de software

2. Plataforma como um Serviço (PaaS): neste caso é oferecido uma infraestrutura de

Pela praticidade que a arquitetura em nuvem oferece, neste trabalho serão

2.9 Banco de Dados NoSQL

2.10 Banco de Dados SQLite

2.11 Linguagem Python

1 Traduzido como Interface de Programação de Aplicativos, representa um conjunto de rotinas, funções

2.12 Linguagem TypeScript